EIPS/eip-908.md:16 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Simple Summary"]

EIPS/eip-908.md:19 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Abstract"]

EIPS/eip-908.md:24 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Motivation"]

EIPS/eip-908.md:45 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Specification"]

EIPS/eip-908.md:104 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "### Security"]

EIPS/eip-908.md:113 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Test Cases"]

EIPS/eip-908.md:116 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Implementation"]

Failed with exit code: 1

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/upload-artifact@65d862660abb392b8c4a3d1195a2108db131dd05. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f, DavidAnson/markdownlint-cli2-action@f5cf187ef11bd3a68a127321b794aa252ff23019. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` --> EIPS/eip-908.md | 82 | <!--There are more than 5552465 blocks and counting. With a reward of 0.001 ETH for each block, a full state node that verified every block would receive 5552.465 ETH. However, the difficulty of verifying blocks increases over time, so--> | = help: see https://ethereum.github.io/eipw/markdown-html-comments/

warning[markdown-link-status]: proposal `eip-1011.md` is not stable enough for a `status` of `Withdrawn` --> EIPS/eip-908.md | 25 | Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with [Casper FFG](./eip-1011.md), then full PoS with [CBC Casper](https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf). | = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant` = help: see https://ethereum.github.io/eipw/markdown-link-status/

warning[markdown-link-status]: proposal `eip-1015.md` is not stable enough for a `status` of `Withdrawn` --> EIPS/eip-908.md | 43 | Note that with a supply cap (as in [EIP-960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP-1015](./eip-1015.md), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders. | = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`

warning[markdown-link-status]: proposal `eip-1015.md` is not stable enough for a `status` of `Withdrawn` --> EIPS/eip-908.md | 58 | 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](./eip-1015.md), 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.eth.limo/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. | = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`

warning[markdown-order-section]: body has extra section(s) --> EIPS/eip-908.md | 12 | ## A reward for running a full node is deprecated, but the proposal for a reward for clients remains | ::: EIPS/eip-908.md | 16 | ## Simple Summary | ::: EIPS/eip-908.md | 116 | ## Implementation | = help: see https://ethereum.github.io/eipw/markdown-order-section/

warning[markdown-refs]: unable to read file `eip-960.md`: Io: JsValue(Error: ENOENT: no such file or directory, open 'EIPS/eip-960.md' Error: ENOENT: no such file or directory, open 'EIPS/eip-960.md' at async open (node:internal/fs/promises:636:25) at async readFile (node:internal/fs/promises:1246:14)) --> EIPS/eip-908.md | 43 | Note that with a supply cap (as in [EIP-960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP-1015](./eip-1015.md), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders. | = help: see https://ethereum.github.io/eipw/markdown-refs/

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-908.md | 14 | While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. [Pocket Network](https://www.pokt.network/) is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is [VIPnode](https://github.com/vipnode/vipnode.org) which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: [shasper](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to [here](https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921). | = help: see https://ethereum.github.io/eipw/markdown-rel-links/

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-908.md | 14 | While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. [Pocket Network](https://www.pokt.network/) is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is [VIPnode](https://github.com/vipnode/vipnode.org) which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: [shasper](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to [here](https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921). |

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-908.md | 14 | While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. [Pocket Network](https://www.pokt.network/) is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is [VIPnode](https://github.com/vipnode/vipnode.org) which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: [shasper](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to [here](https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921). |

warning[markdown-rel-links]: non-relative link or image --> EIPS/eip-908.md | 14 | While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. [Pocket Network](https://www.pokt.network/) is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that [Rocket Pool](https://github.com/rocket-pool/rocketpool) is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is [VIPnode](https://github.com/vipnode/vipnode.org) which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: [shasper](https://notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ#)): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to [here](https://github.com/ethereum/EIPs/commit/97e235d0ba4a88b4ce29834aa2b94107b8d91e12#diff-9a43a8739b5a9e1dec427324cb264921). |

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.