Add Github usernames

EIPS/eip-908.md

@@ -1,7 +1,7 @@
 ---
 eip: 908
 title: Reward full nodes and clients
-author: James Ray and Micah Zoltu
+author: James Ray (@jamesray1), Micah Zoltu (@MicahZoltu)
 discussions-to: https://gitter.im/ethereum/topics/topic/5ac8574227c509a774e7901a/eip-reward-full-nodes-and-clients
 status: Draft
 type: Standards Track
@@ -26,6 +26,8 @@ Alternatively, the full node validator could insert their address (or it could b
 
 The issuance can be prevented from increasing indefinitely with a supply cap as in [this EIP-issue](https://github.com/ethereum/EIPs/issues/960), which includes reducing the rewards for miners (or other participants as in [sharding](https://ethresear.ch/t/sharding-phase-1-spec/1407) and [Casper](https://github.com/ethereum/research/tree/master/papers)), and in the long-run having no block rewards and just transaction fees, with Ether burnt e.g. from slashing participants in sharding and Casper and [lost or stuck](https://github.com/ethereum/wiki/wiki/Major-issues-resulting-in-lost-or-stuck-funds) [funds](https://github.com/ethereum/EIPs/pull/867).
 
+Regarding rewards for full nodes, in the [draft phase 1 sharding spec](https://ethresear.ch/t/sharding-phase-1-spec/1407) proposers acting as full nodes have rewards for proposing blobs (without execution) or later in phase 3 transactions (with execution) to be included into collations/blocks. So that would help. However, full nodes that do not act as proposers and just verify transactions, or [full state nodes](https://ethresear.ch/t/incentivizing-full-state-nodes/1640), are still not incentivized.
+
 ## Rationale
 
 Discussion began at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239. [Micah stated](https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239/4):
@@ -50,6 +52,8 @@ Providing rewards to full node validators and to clients would increase the issu
 
 Another potential point of controversy with rewarding clients and full nodes is that the work previously done by them has not been paid for until now (except of course by the Ethereum Foundation or Parity VCs funding the work), so existing clients may say that this EIP gives an advantage to new entrants. However, this doesn't hold up well, because existing clients have the first mover advantage, with much development to create useful and well-used products.
 
+There is a tradeoff. Higher fees means you may cut out poor people and people who just don't want to pay fees. But if a laptop can run a full node and get paid for it then that would offset the fees through usage. Full nodes do provide a security benefit, so the total fees given could at least be some fraction of this benefit. Fees that go towards client development incentivise a higher quality client. To me, I think it makes more sense to internalize costs as much as possible: for computation, storage, bandwidth, I/O, client development, running full nodes, mining/validating, etc. You avoid a tragedy of the commons through externalizing costs. The more you internalize costs, the more sustainable it is, and the less you rely on rich people being generous, etc. (Although, getting philosophical, ultimately you can't force rich people to be generous, they have to do so out of the kindness of their hearts.)
+
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
 
 ## Backwards Compatibility