From: Hector Chu <hectorchu@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] A solution to increase the incentive of running a node
Date: Wed, 19 Aug 2015 12:15:28 +0100 [thread overview]
Message-ID: <CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2015-08-19 11:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 11:15 Hector Chu [this message]
2015-08-19 11:42 ` [bitcoin-dev] A solution to increase the incentive of running a node Jameson Lopp
2015-08-19 11:48 ` Hector Chu
2015-08-19 12:08 ` Jameson Lopp
2015-08-19 12:15 ` Hector Chu
2015-08-19 12:44 ` Jameson Lopp
2015-08-19 12:51 ` Hector Chu
2015-08-21 20:50 ` Tamas Blummer
2015-08-21 21:12 ` Sergio Demian Lerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com' \
--to=hectorchu@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox