[bitcoin-dev] A solution to increase the incentive of running a node

[bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu]

[-- Attachment #1: Type: text/plain, Size: 6244 bytes --]

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.

On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I suspect we need a better incentive for users to run nodes instead of
relying solely on altruism.

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@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.

[-- Attachment #2: Type: text/html, Size: 7380 bytes --]

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 7948 bytes --]

On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <
bitcoin-dev@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@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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 9799 bytes --]

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu]

On 19 August 2015 at 12:42, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> 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 proof is in the validation of transactions. How can a node
reliably validate transactions unless it has the past history of
transactions? Entire blockchain not required or necessary, but that's
a plus.

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

If operating as an SPV node then it can check the transactions by querying
other nodes.

On an unrelated note, it sounds like your proposal will significantly
increase the data size of every transaction, which will create even more
contention for block space.

- Jameson

On Wed, Aug 19, 2015 at 7:48 AM, Hector Chu <hectorchu@gmail.com> wrote:

> On 19 August 2015 at 12:42, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> > 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 proof is in the validation of transactions. How can a node
> reliably validate transactions unless it has the past history of
> transactions? Entire blockchain not required or necessary, but that's
> a plus.
>

[-- Attachment #2: Type: text/html, Size: 1707 bytes --]

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu]

On 19 August 2015 at 13:08, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> If operating as an SPV node then it can check the transactions by querying
> other nodes.

SPV is for checking validity of transactions that have already entered
the blockchain, as I understand it. My proposal requires nodes to
validate transactions that are unconfirmed, and to commit to the
validation by doing a POW on it.

> On an unrelated note, it sounds like your proposal will significantly
> increase the data size of every transaction, which will create even more
> contention for block space.

If we stipulate that the coinbase fields only hold space for a single
pubkey, then the entire block header including the two coinbases
should only take an extra 100 bytes or so. Transactions are already
routinely 250 bytes+. So an increase of roughly 33%.

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu <hectorchu@gmail.com> wrote:

> On 19 August 2015 at 13:08, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I understand it. My proposal requires nodes to
> validate transactions that are unconfirmed, and to commit to the
> validation by doing a POW on it.
>
> It's possible to check that a transaction is cryptographically valid
without having any blockchain data available; are you referring to a
different type of validation?

If you're running an SPV node that is listening to full nodes on the
network, you can request an unconfirmed transaction from connected peers
after receiving the inventory message they send - that's how unconfirmed
transactions propagate through the node network. This is not 100% proof
that the transaction is valid for inclusion in the blockchain, but it's a
very good indicator.

- Jameson


> > On an unrelated note, it sounds like your proposal will significantly
> > increase the data size of every transaction, which will create even more
> > contention for block space.
>
> If we stipulate that the coinbase fields only hold space for a single
> pubkey, then the entire block header including the two coinbases
> should only take an extra 100 bytes or so. Transactions are already
> routinely 250 bytes+. So an increase of roughly 33%.
>

[-- Attachment #2: Type: text/html, Size: 2180 bytes --]

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu]

On 19 August 2015 at 13:44, Jameson Lopp <jameson.lopp@gmail.com> wrote:
> It's possible to check that a transaction is cryptographically valid without
> having any blockchain data available; are you referring to a different type
> of validation?

It seems laborious to enumerate all the validations that are performed
on a transaction before it can be mined into a block, but for starters
we need to check it isn't a double-spend, and that its signatures
satisfy the outputs' pubkeys.

> If you're running an SPV node that is listening to full nodes on the
> network, you can request an unconfirmed transaction from connected peers
> after receiving the inventory message they send - that's how unconfirmed
> transactions propagate through the node network. This is not 100% proof that
> the transaction is valid for inclusion in the blockchain, but it's a very
> good indicator.

If you as an SPV node are waiting for unconfirmed transactions to be
relayed to you, you are going to have a slow start in mining those
transactions, decreasing the likelihood of receiving the mining
reward. Nodes should accept the first POW for a transaction and
discard any subsequent ones received.

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

Jameson,

I like your thinking about the implicit reward of full nodes. It was not perceived as sufficient by many, hence full node counts were falling.

This might reverse now as the implicit value of validating yourself however becomes higher in a heterogenous environment, that is if there are hard forks in the wild.

Actually pooled mining became an option through the homogenous nature of the network.

Tamas Blummer

> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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.


[-- Attachment #1.2: Type: text/html, Size: 2669 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

Hector,
 I can only say 2 things in the brief time I have now:

1. There is a solution that I proposed for proving you own a copy of the
block-chain. It's using aymmetric-time functions:

https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

2. I'm finishing a paper on a transaction system (DAGCoin) which relies on
proof-of-work per transactions, and no per blocks. Actually it has no
blocks.

This has been explored in the past, but I came up with some basic ideas
that make this work a few months ago. I will forward a draft to you while
at the same time I try to analyze your proposal. Or I may publish the draft
altogether.

Best regards,
 Sergio






On Fri, Aug 21, 2015 at 5:50 PM, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Jameson,
>
> I like your thinking about the implicit reward of full nodes. It was not
> perceived as sufficient by many, hence full node counts were falling.
>
> This might reverse now as the implicit value of validating yourself
> however becomes higher in a heterogenous environment, that is if there are
> hard forks in the wild.
>
> Actually pooled mining became an option through the homogenous nature of
> the network.
>
> Tamas Blummer
>
> On Aug 19, 2015, at 13:42, Jameson Lopp via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3897 bytes --]