Automatically merged updates to draft EIP(s) 908

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-908.md

@@ -36,9 +36,17 @@ Implementing this as a layer 2 solution may not ensure the sustainability of the
 Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node.
 
 ## Specification
-When a transaction is validated by a client, the client attaches a user agent to another transaction. The user agent is a vector with the txhash of the transaction that is validated, the index of a client address in an access list and the address of the verifying full node. To ensure that the verification of the transaction is valid, the vector could contain an optional field for a zk-SNARK, or you could have Truebit interactive verification of the verification. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage, and the full node address could also be read in a more user-friendly way (e.g. a GUI or command line prompt). 
+When a transaction is validated by a client, the client attaches a user agent to another transaction. The user agent is a vector with the txhash of the transaction that is validated, the index of a client address in an access list and the address of the verifying full node. To ensure that the verification of the transaction is valid, the vector could contain an optional field for a zk-SNARK, or you could have Truebit interactive verification of the verification. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage, and the full node address could also be read in a more user-friendly way (e.g. a GUI or command line prompt).
 
-The access list prevents anyone inserting any address to the first element of the vector, where there should be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to [EIP 1015](http://eips.ethereum.org/EIPS/eip-1015), which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract, as well as being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could `assert` that the address found at that index matches that which can be read by the client (where the latter would be a read-only address). To prevent the miner getting a double-dose of transaction fees, `assert` that the full node validator address is not the same as the miner's address. Some amounts of ETH (these amounts are not specified and would need further analysis as discussed qualitatively below) could be sent or added to the balance of the address in each vector, when the transaction is processed (similar to mining rewards). The amounts could include a proportion of transaction fees (while the miner would then receive less) as well as newly minted ETH.
+To prevent the miner getting a double-dose of transaction fees, `assert` that the full node validator address is not the same as the miner's address. Some amounts of ETH (these amounts are not specified and would need further analysis as discussed qualitatively below) could be sent or added to the balance of the address in each vector, when the transaction is processed (similar to mining rewards). The amounts could include a proportion of transaction fees (while the miner would then receive less) as well as newly minted ETH.
+
+### More details on the access list
+
+The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to [EIP 1015](http://eips.ethereum.org/EIPS/eip-1015), which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of [on-chain governance](https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) as well as of [plutocracy](https://vitalik.ca/general/2018/03/28/plutocracy.html). [Proof of Authority](https://en.wikipedia.org/wiki/Proof-of-authority) isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users.
+
+However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the [Ethereum test suite](https://github.com/ethereum/tests). However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by [Dogezer](http://dogezer.com/)). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list).
+
+Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could `assert` that the address found at that index matches that which can be read by the client (where the latter would be a read-only address).
 
 ## Rationale