Jameson Lopp [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:On Wed, Aug 19, 2015 at ...
📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin is imploding due to a failure of consensus. There has been a
> failure of consensus on how to fix the design flaw evinced by the block
> size fiasco.
>
> I disagree, but this isn't a technical claim so let's move on.
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
> If you can actually come up with a technical solution that allows for a
node operator to prove to the rest of the network that they are running an
honest full node that hosts the entire blockchain, then you can move
forward with a direct monetary incentivization proposal. To my knowledge no
one has been successful in that endeavor. To be more clear, your proposal
would need to be able to differentiate between a full node and a
pseudonode. https://github.com/basil00/PseudoNode
The incentives for running a node may not be obvious to the average user,
but they are there. Rather than direct monetary incentives, they are
indirect. For one, it allows you to have a local copy of the blockchain
that you validated yourself - trustlessness is the entire point of this
system. Having local self-validated blockchain data is also essential for
any enterprise that needs to quickly access large volumes of it. The other
incentive is it supports the network. Users may feel that this is necessary
out of altruism or they may feel incentivized to protect their investments
in Bitcoin.
- Jameson
> This is the root cause of the disagreement. Not on what value the block
> size should be set to, a symptom and red herring. The whole argument
> against a block size increase is the further reduction in the node count.
>
> Therefore it makes sense to focus all energies on solving the root cause
> if we are to save Bitcoin in the short and long run. It is tempting to toy
> with the idea that a superior cryptocurrency which fixes the flaws can
> supplant Bitcoin while it dies, but there is significant merit in the
> suspicion that if Bitcoin fails the whole idea of cryptocurrencies will die
> with it for another generation.
>
> Below I will outline my thoughts on how Bitcoin can be improved so that
> more people will be incentivised to run nodes.
>
> 1. The current incentive is run like a lottery.
>
> Mining becomes more and more of a lottery the more value that Bitcoin
> acquires. Prudent and rational people don't partake in lotteries as the
> expected payoff is negative. Due to rewards at the block level, this leads
> to a winner-takes-all situation, which leads to centralisation.
>
> 2. Decentralised proof-of-work is equivalent to value.
>
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Nearly everyone has to agree on a change, and they have to do it without
> being forced or pressured into it.
>
> Proof-of-work is the basis of Bitcoin's security, which contributes to
> Bitcoin's value. Further, the more decentralised that proof-of-work is, the
> greater the value proposition of Bitcoin as a currency resistant to change
> by coercion.
>
> 3. Importance of a public technical forum.
>
> In order for there to be consensus, there must be a triumph of ideas over
> people. Ideas are immortal, people are not. Also, pragmatism over idealism.
> There must be no rank within the community, and no censorship or ignorance
> of others no matter their past contributions. However, it stands to reason
> that those who are more educated and experienced should be taken more
> seriously than those who are not.
>
> 4. Stronger ties between transaction validation and proof-of-work.
>
> As pointed out, mining in the pooled sense can be done without doing any
> validation whatsoever. By tying mining with transaction validation, the two
> must become inseparable.
>
> The logical conclusion of this is that instead of mining blocks per se,
> transactions must be mined individually.
>
> 5. Fees to be paid to nodes.
>
> The incentive to run nodes shall be made monetary. All the reward is
> currently going to those who do not really support the network.
>
> 50% of a transaction's fee should go to the node that mined the
> transaction.
>
> 6. The timechain.
>
> Currently it is difficult to envisage anything other than grouping
> transactions into blocks and timestamping them. The POW timestamping
> service must have sufficient time gap between blocks.
>
> Therefore as transactions are mined each one will have the possibility to
> become a block in the timechain. The POW difficulty for a block will
> obviously be much greater than the POW required to mine a single
> transaction.
>
> This also requires every mined transaction to contain a block header, in
> case it becomes a new block in the block chain. It will contain a prev
> block hash, a merkle tree of mined transactions in the mempool, a nonce and
> two separate coinbase addresses. One coinbase output will be used to pay
> the miner of the transaction, and the other will also pay the miner the
> (50%) transaction fees of the other transactions in the block, if the POW
> on the transaction also satisfies the POW difficulty of a block.
>
> 7. Transaction POW difficulty.
>
> Block POW difficulty can remain as it currently does, to produce blocks at
> approximately 10 minute intervals.
>
> Transaction POW difficulty affects the rate at which mined transactions
> are produced.
>
> Now, since each transaction contains a prev block hash an important
> decision to make is whether to mandate that all transactions within a block
> contain the same prev block hash, and that the prev block so referenced is
> the immediate previous ancestor block, or whether any transaction may be
> admitted into a block so long as the prev block referenced by the
> transaction is any previous ancestor in the main chain.
>
> If the former, then any transactions which don't make it into a block must
> be re-mined for inclusion in the next block. Hence this more closely
> enforces the rate at which transactions are mined and included.
>
> The rate at which transactions are mined and included in blocks is
> obviously proportional to the block size. The transaction POW difficulty
> can be adjusted periodically so that the transaction rate or block size
> follows a smooth trajectory and does not make any sudden jumps.
>
> Greater decentralisation of POW leads to increased mined transaction rate
> (given sufficient unmined transaction rate production). The inverse is also
> true. Hence transaction rate and block size is proportional to degree of
> decentralisation.
>
> 8. Miscalleneous observations.
>
> Nodes only need work on transactions if they are valid.
>
> Mined transactions are a weak guarantee that they will be accepted by the
> network.
>
> The originator of a transaction may self-mine his own transaction to avoid
> paying some of the fee.
>
> Transactions with higher fees and smaller size will be mined in preference.
>
> Large block spam attack is expensive due to the POW needed to mine the
> gigantic number of transactions.
>
> Decentralisation of nodes is encouraged to be close to the location of
> real transaction origination i.e. consumers. Unmined transactions may not
> be relayed by a node if it chooses to work on it, if the fee is high enough.
>
> Block-level reward is still a decentralised lottery. Transaction-level
> rewards go to those running the network. Fees will go up as it will be the
> nodes that are mining transactions that need to be individually
> compensated, and not miners mining only block headers.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/fbc4b6cd/attachment-0001.html>;
📝 Original message:On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin is imploding due to a failure of consensus. There has been a
> failure of consensus on how to fix the design flaw evinced by the block
> size fiasco.
>
> I disagree, but this isn't a technical claim so let's move on.
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
> If you can actually come up with a technical solution that allows for a
node operator to prove to the rest of the network that they are running an
honest full node that hosts the entire blockchain, then you can move
forward with a direct monetary incentivization proposal. To my knowledge no
one has been successful in that endeavor. To be more clear, your proposal
would need to be able to differentiate between a full node and a
pseudonode. https://github.com/basil00/PseudoNode
The incentives for running a node may not be obvious to the average user,
but they are there. Rather than direct monetary incentives, they are
indirect. For one, it allows you to have a local copy of the blockchain
that you validated yourself - trustlessness is the entire point of this
system. Having local self-validated blockchain data is also essential for
any enterprise that needs to quickly access large volumes of it. The other
incentive is it supports the network. Users may feel that this is necessary
out of altruism or they may feel incentivized to protect their investments
in Bitcoin.
- Jameson
> This is the root cause of the disagreement. Not on what value the block
> size should be set to, a symptom and red herring. The whole argument
> against a block size increase is the further reduction in the node count.
>
> Therefore it makes sense to focus all energies on solving the root cause
> if we are to save Bitcoin in the short and long run. It is tempting to toy
> with the idea that a superior cryptocurrency which fixes the flaws can
> supplant Bitcoin while it dies, but there is significant merit in the
> suspicion that if Bitcoin fails the whole idea of cryptocurrencies will die
> with it for another generation.
>
> Below I will outline my thoughts on how Bitcoin can be improved so that
> more people will be incentivised to run nodes.
>
> 1. The current incentive is run like a lottery.
>
> Mining becomes more and more of a lottery the more value that Bitcoin
> acquires. Prudent and rational people don't partake in lotteries as the
> expected payoff is negative. Due to rewards at the block level, this leads
> to a winner-takes-all situation, which leads to centralisation.
>
> 2. Decentralised proof-of-work is equivalent to value.
>
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Nearly everyone has to agree on a change, and they have to do it without
> being forced or pressured into it.
>
> Proof-of-work is the basis of Bitcoin's security, which contributes to
> Bitcoin's value. Further, the more decentralised that proof-of-work is, the
> greater the value proposition of Bitcoin as a currency resistant to change
> by coercion.
>
> 3. Importance of a public technical forum.
>
> In order for there to be consensus, there must be a triumph of ideas over
> people. Ideas are immortal, people are not. Also, pragmatism over idealism.
> There must be no rank within the community, and no censorship or ignorance
> of others no matter their past contributions. However, it stands to reason
> that those who are more educated and experienced should be taken more
> seriously than those who are not.
>
> 4. Stronger ties between transaction validation and proof-of-work.
>
> As pointed out, mining in the pooled sense can be done without doing any
> validation whatsoever. By tying mining with transaction validation, the two
> must become inseparable.
>
> The logical conclusion of this is that instead of mining blocks per se,
> transactions must be mined individually.
>
> 5. Fees to be paid to nodes.
>
> The incentive to run nodes shall be made monetary. All the reward is
> currently going to those who do not really support the network.
>
> 50% of a transaction's fee should go to the node that mined the
> transaction.
>
> 6. The timechain.
>
> Currently it is difficult to envisage anything other than grouping
> transactions into blocks and timestamping them. The POW timestamping
> service must have sufficient time gap between blocks.
>
> Therefore as transactions are mined each one will have the possibility to
> become a block in the timechain. The POW difficulty for a block will
> obviously be much greater than the POW required to mine a single
> transaction.
>
> This also requires every mined transaction to contain a block header, in
> case it becomes a new block in the block chain. It will contain a prev
> block hash, a merkle tree of mined transactions in the mempool, a nonce and
> two separate coinbase addresses. One coinbase output will be used to pay
> the miner of the transaction, and the other will also pay the miner the
> (50%) transaction fees of the other transactions in the block, if the POW
> on the transaction also satisfies the POW difficulty of a block.
>
> 7. Transaction POW difficulty.
>
> Block POW difficulty can remain as it currently does, to produce blocks at
> approximately 10 minute intervals.
>
> Transaction POW difficulty affects the rate at which mined transactions
> are produced.
>
> Now, since each transaction contains a prev block hash an important
> decision to make is whether to mandate that all transactions within a block
> contain the same prev block hash, and that the prev block so referenced is
> the immediate previous ancestor block, or whether any transaction may be
> admitted into a block so long as the prev block referenced by the
> transaction is any previous ancestor in the main chain.
>
> If the former, then any transactions which don't make it into a block must
> be re-mined for inclusion in the next block. Hence this more closely
> enforces the rate at which transactions are mined and included.
>
> The rate at which transactions are mined and included in blocks is
> obviously proportional to the block size. The transaction POW difficulty
> can be adjusted periodically so that the transaction rate or block size
> follows a smooth trajectory and does not make any sudden jumps.
>
> Greater decentralisation of POW leads to increased mined transaction rate
> (given sufficient unmined transaction rate production). The inverse is also
> true. Hence transaction rate and block size is proportional to degree of
> decentralisation.
>
> 8. Miscalleneous observations.
>
> Nodes only need work on transactions if they are valid.
>
> Mined transactions are a weak guarantee that they will be accepted by the
> network.
>
> The originator of a transaction may self-mine his own transaction to avoid
> paying some of the fee.
>
> Transactions with higher fees and smaller size will be mined in preference.
>
> Large block spam attack is expensive due to the POW needed to mine the
> gigantic number of transactions.
>
> Decentralisation of nodes is encouraged to be close to the location of
> real transaction origination i.e. consumers. Unmined transactions may not
> be relayed by a node if it chooses to work on it, if the fee is high enough.
>
> Block-level reward is still a decentralised lottery. Transaction-level
> rewards go to those running the network. Fees will go up as it will be the
> nodes that are mining transactions that need to be individually
> compensated, and not miners mining only block headers.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/fbc4b6cd/attachment-0001.html>;