path: root/fa/3bc83e82d0cc8374fc212a45ce9a42dda2563b

Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C886089F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 11:15:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com
	[209.85.217.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 642DF110
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 11:15:49 +0000 (UTC)
Received: by lbbtg9 with SMTP id tg9so882351lbb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 04:15:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=CNEPd4lZDy9biua4cUzJx21ZWM2GLBJmo3erv6el88M=;
	b=awm9A5E2Zm5buMop0Z5C2g6/HvGBrS8nOSStEYpZBnnge2PEg/Xdyq8t9lmOxczBi7
	aEjfapQA/8foZH1XcA0uQpQS1EhO1pf2LuZxnueIkxK5pp0AoS5XyP1+Pr/yzYmgf18N
	1CZOc/xsu0f0en1FkxO/9BJcsImFlPwSbjXPYLtURb58ceHSbOy+OeEw9BSYfYvDKeox
	1rIjmhqFZPIJ+E1fBS/PUrokZktE3aQ+e2SZU0AwX2M47aqCqq59vUqhAwwpgyMKEeEb
	k2HYVnxyt7+I3NL2a04B3XJyUrtkZOO/pZiuZxGQUdajeU6u/v49oLOSzzUUFZo/i9QU
	YRJw==
X-Received: by 10.152.30.100 with SMTP id r4mr10578825lah.92.1439982947751;
	Wed, 19 Aug 2015 04:15:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Wed, 19 Aug 2015 04:15:28 -0700 (PDT)
From: Hector Chu <hectorchu@gmail.com>
Date: Wed, 19 Aug 2015 12:15:28 +0100
Message-ID: <CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0158cba0155eed051da828d3
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] A solution to increase the incentive of running a node
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2015 11:15:50 -0000

--089e0158cba0155eed051da828d3
Content-Type: text/plain; charset=UTF-8

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.

--089e0158cba0155eed051da828d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Bitcoin is imploding due to a failure of consensus. T=
here has been a failure of consensus on how to fix the design flaw evinced =
by the block size fiasco.</div><div><br></div><div>On 15 August 2015 at 18:=
43, Satoshi Nakamoto via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:</div><div>&gt; I suspect we need a better incentive for =
users to run nodes instead of relying solely on altruism.</div><div><br></d=
iv><div>This is the root cause of the disagreement. Not on what value the b=
lock size should be set to, a symptom and red herring. The whole argument a=
gainst a block size increase is the further reduction in the node count.</d=
iv><div><br></div><div>Therefore it makes sense to focus all energies on so=
lving the root cause if we are to save Bitcoin in the short and long run. I=
t is tempting to toy with the idea that a superior cryptocurrency which fix=
es the flaws can supplant Bitcoin while it dies, but there is significant m=
erit in the suspicion that if Bitcoin fails the whole idea of cryptocurrenc=
ies will die with it for another generation.</div><div><br></div><div>Below=
 I will outline my thoughts on how Bitcoin can be improved so that more peo=
ple will be incentivised to run nodes.</div><div><br></div><div>1. The curr=
ent incentive is run like a lottery.</div><div><br></div><div>Mining become=
s more and more of a lottery the more value that Bitcoin acquires. Prudent =
and rational people don&#39;t partake in lotteries as the expected payoff i=
s negative. Due to rewards at the block level, this leads to a winner-takes=
-all situation, which leads to centralisation.</div><div><br></div><div>2. =
Decentralised proof-of-work is equivalent to value.</div><div><br></div>On =
15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev=C2=A0<span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>=C2=A0wrote=
:<br><div>&gt; Nearly everyone has to agree on a change, and they have to d=
o it without being forced or pressured into it.</div><div><br></div><div>Pr=
oof-of-work is the basis of Bitcoin&#39;s security, which contributes to Bi=
tcoin&#39;s value. Further, the more decentralised that proof-of-work is, t=
he greater the value proposition of Bitcoin as a currency resistant to chan=
ge by coercion.</div><div><br></div><div>3. Importance of a public technica=
l forum.</div><div><br></div><div>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 communit=
y, and no censorship or ignorance of others no matter their past contributi=
ons. However, it stands to reason that those who are more educated and expe=
rienced should be taken more seriously than those who are not.</div><div><b=
r></div><div>4. Stronger ties between transaction validation and proof-of-w=
ork.</div><div><br></div><div>As pointed out, mining in the pooled sense ca=
n be done without doing any validation whatsoever. By tying mining with tra=
nsaction validation, the two must become inseparable.</div><div><br></div><=
div>The logical conclusion of this is that instead of mining blocks per se,=
 transactions must be mined individually.</div><div><br></div><div>5. Fees =
to be paid to nodes.</div><div><br></div><div>The incentive to run nodes sh=
all be made monetary. All the reward is currently going to those who do not=
 really support the network.</div><div><br></div><div>50% of a transaction&=
#39;s fee should go to the node that mined the transaction.</div><div><br><=
/div><div>6. The timechain.</div><div><br></div><div>Currently it is diffic=
ult to envisage anything other than grouping transactions into blocks and t=
imestamping them. The POW timestamping service must have sufficient time ga=
p between blocks.</div><div><br></div><div>Therefore as transactions are mi=
ned 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.</div><div><br></div><div>This also r=
equires every mined transaction to contain a block header, in case it becom=
es a new block in the block chain. It will contain a prev block hash, a mer=
kle tree of mined transactions in the mempool, a nonce and two separate coi=
nbase addresses. One coinbase output will be used to pay the miner of the t=
ransaction, and the other will also pay the miner the (50%) transaction fee=
s of the other transactions in the block, if the POW on the transaction als=
o satisfies the POW difficulty of a block.</div><div><br></div><div>7. Tran=
saction POW difficulty.</div><div><br></div><div>Block POW difficulty can r=
emain as it currently does, to produce blocks at approximately 10 minute in=
tervals.</div><div><br></div><div>Transaction POW difficulty affects the ra=
te at which mined transactions are produced.</div><div><br></div><div>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 immedia=
te 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 pre=
vious ancestor in the main chain.</div><div><br></div><div>If the former, t=
hen any transactions which don&#39;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.</div><div><br></div><div>The =
rate at which transactions are mined and included in blocks is obviously pr=
oportional to the block size. The transaction POW difficulty can be adjuste=
d periodically so that the transaction rate or block size follows a smooth =
trajectory and does not make any sudden jumps.</div><div><br></div><div>Gre=
ater decentralisation of POW leads to increased mined transaction rate (giv=
en sufficient unmined transaction rate production). The inverse is also tru=
e. Hence transaction rate and block size is proportional to degree of decen=
tralisation.</div><div><br></div><div>8. Miscalleneous observations.</div><=
div><br></div><div>Nodes only need work on transactions if they are valid.<=
/div><div><br></div><div>Mined transactions are a weak guarantee that they =
will be accepted by the network.</div><div><br></div><div>The originator of=
 a transaction may self-mine his own transaction to avoid paying some of th=
e fee.</div><div><br></div><div>Transactions with higher fees and smaller s=
ize will be mined in preference.</div><div><br></div><div>Large block spam =
attack is expensive due to the POW needed to mine the gigantic number of tr=
ansactions.</div><div><br></div><div>Decentralisation of nodes is encourage=
d to be close to the location of real transaction origination i.e. consumer=
s. Unmined transactions may not be relayed by a node if it chooses to work =
on it, if the fee is high enough.</div><div><br></div><div>Block-level rewa=
rd 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 minin=
g transactions that need to be individually compensated, and not miners min=
ing only block headers.</div><div><br></div></div>

--089e0158cba0155eed051da828d3--