Commit 0d658e9

EIP: Reward for clients and full nodes validating transactions (#908) * Create eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update eip-Reward-full-nodes-validating-tx.md * Update and rename eip-Reward-full-nodes-validating-tx.md to eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Update eip-Reward-full-nodes-and-clients.md * Quotes for Micah * The amount of computation to validate a transaction will be the same as a miner... * Add comments on Micah's suggestions and give further specification details * Further commentary on transaction fee amount for full nodes vs miner tx fees * Add "One problem with this is that a miner could run a full node validator using a different address with the same computer, and just cache the result of their execution and use it for the full node validator. I'm not sure how you would prevent this, but perhaps you could using IP address tracking (similarly asserting that the IP address of a full node validator isn't the same as the miner) which would add additional complexity to the protocol, but this could also be hacked with dynamic IPs and VPNs." * he user agent would contain the information needed to send an amount of ETH to the full node and the client, which are the addresses of these parties and the amounts to add. I think full nodes would need to add to their set up to add the address to receive ETH after validating transactions. These fields could be read-only, or immutable, so that someone can't overwrite them with another address, thus preventing one possible attack. * Add a missing T * Update frontmatter * Comment out implementation, add backwards incompatibility * Update the specification, rewording and moving content * Update the header, Test Cases and Implementation * Update eip-Reward-full-nodes-and-clients.md * Chamge the category to Core * to be assigned => <to be assigned> * discussions-to: https://gitter.im/ethereum/topics/topic/5ac8574227c509a774e7901a/eip-reward-full-nodes-and-clients * Move around fields in the header * Add an extra line to see if that will get the build to pass * Assign eip number 908 * Rename eip-Reward-full-nodes-and-clients.md to eip-908.md

GitHub Diff