path: root/1e/aa89038e86db9319dcbac8260c264059e36854

Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D66C18D8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 11:42:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com
	[209.85.217.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40A85EA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 11:42:08 +0000 (UTC)
Received: by lbcbn3 with SMTP id bn3so1263586lbc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 19 Aug 2015 04:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=BVFyIVBJIcyK+fIk4/ecHbFVqd1CJFvVMc/cHEHvwVY=;
	b=hkKxiqfwsWpdYSisbA3E9otJp7sULfxziLkWeKf8HhZv0sSgiIcWSTjQTdi52T1P49
	JXZYL3R6t98ghq9HZQebcRmIQtz072OYDGmgfZyt0mmVsS9fCHW6gyHLdBXWtF222qpK
	Bs2It3iS1R02p7qzWPpIomY9vHDcSNddLLKZhAKHGGpahZJWIk+KDy/xnd40Qhp6iXu3
	xHNQ9UqZKklT2YuSoT1c/1TTqAvuR5UP+f8x0FGdS3A/h4rkhEDINorDqHclOJ1okqE8
	2hmx+YwYZYhJ3TBP1146NdaCQqG5IejK6wP6CSuSaRoAfQbyt+GJwFLCKi5yBECw+/XR
	vRKA==
MIME-Version: 1.0
X-Received: by 10.152.42.244 with SMTP id r20mr10892904lal.90.1439984526408;
	Wed, 19 Aug 2015 04:42:06 -0700 (PDT)
Received: by 10.25.150.84 with HTTP; Wed, 19 Aug 2015 04:42:06 -0700 (PDT)
In-Reply-To: <CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com>
References: <CAAO2FKGS9+0pMa_iF+TNc7nnAqniE7vjTHapvubdce7=aSyBEg@mail.gmail.com>
Date: Wed, 19 Aug 2015 07:42:06 -0400
Message-ID: <CADL_X_duSHosyMAfOXPv7WcWKTY19Q2i+_zFSuuGbGantbbmRw@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Hector Chu <hectorchu@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c303b22dc1f3051da886cc
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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:42:09 -0000

--001a11c303b22dc1f3051da886cc
Content-Type: text/plain; charset=UTF-8

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div><div>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.</div><div><br></div>=
</div></blockquote><div>I disagree, but this isn&#39;t a technical claim so=
 let&#39;s move on. <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div><div></div><div>On 15 August 2015 at 18:43, Satoshi Nakamoto via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=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 instea=
d of relying solely on altruism.</div><div><br></div></div></blockquote><di=
v><div>If you can actually come up with a technical solution that allows=20
for a node operator to prove to the rest of the network that they are runni=
ng an honest full node=20
that hosts the entire blockchain, then you can move forward with a=20
direct monetary incentivization proposal. To my knowledge no one has=20
been successful in that endeavor. To be more clear, your proposal would=20
need to be able to differentiate between a full node and a pseudonode.=20
<a href=3D"https://github.com/basil00/PseudoNode">https://github.com/basil0=
0/PseudoNode</a><br><br></div>The incentives for=20
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=20
allows you to have a local copy of the blockchain that you=20
validated yourself - trustlessness is the entire point of this system.=20
Having local self-validated blockchain data is also essential for any=20
enterprise that
 needs to quickly access large volumes of it. The other=20
incentive is it supports the network. Users may feel that this is=20
necessary out of altruism or they may feel incentivized to protect their
 investments in Bitcoin.

<br><br>- Jameson<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div><div></div><div>This is the root cause of the disagreement=
. Not on what value the block size should be set to, a symptom and red herr=
ing. The whole argument against a block size increase is the further reduct=
ion in the node count.</div><div><br></div><div>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, b=
ut there is significant merit in the suspicion that if Bitcoin fails the wh=
ole idea of cryptocurrencies 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 people will be incentivised to run nodes.</div><div><=
br></div><div>1. The current incentive is run like a lottery.</div><div><br=
></div><div>Mining becomes more and more of a lottery the more value that B=
itcoin acquires. Prudent and rational people don&#39;t partake in lotteries=
 as the expected payoff is negative. Due to rewards at the block level, thi=
s leads to a winner-takes-all situation, which leads to centralisation.</di=
v><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 bitc=
oin-dev=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;</span>=C2=A0wrote:<br><div>&gt; Nearly everyone has to agree on a cha=
nge, and they have to do it without being forced or pressured into it.</div=
><div><br></div><div>Proof-of-work is the basis of Bitcoin&#39;s security, =
which contributes to Bitcoin&#39;s value. Further, the more decentralised t=
hat proof-of-work is, the greater the value proposition of Bitcoin as a cur=
rency resistant to change by coercion.</div><div><br></div><div>3. Importan=
ce of a public technical forum.</div><div><br></div><div>In order for there=
 to be consensus, there must be a triumph of ideas over people. Ideas are i=
mmortal, people are not. Also, pragmatism over idealism. There must be no r=
ank within the community, and no censorship or ignorance of others no matte=
r their past contributions. However, it stands to reason that those who are=
 more educated and experienced should be taken more seriously than those wh=
o are not.</div><div><br></div><div>4. Stronger ties between transaction va=
lidation and proof-of-work.</div><div><br></div><div>As pointed out, mining=
 in the pooled sense can be done without doing any validation whatsoever. B=
y tying mining with transaction validation, the two must become inseparable=
.</div><div><br></div><div>The logical conclusion of this is that instead o=
f 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 in=
centive to run nodes shall be made monetary. All the reward is currently go=
ing to those who do not really support the network.</div><div><br></div><di=
v>50% of a transaction&#39;s fee should go to the node that mined the trans=
action.</div><div><br></div><div>6. The timechain.</div><div><br></div><div=
>Currently it is difficult to envisage anything other than grouping transac=
tions into blocks and timestamping them. The POW timestamping service must =
have sufficient time gap between blocks.</div><div><br></div><div>Therefore=
 as transactions are mined each one will have the possibility to become a b=
lock in the timechain. The POW difficulty for a block will obviously be muc=
h greater than the POW required to mine a single transaction.</div><div><br=
></div><div>This also requires every mined transaction to contain a block h=
eader, 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 non=
ce 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 th=
e (50%) transaction fees of the other transactions in the block, if the POW=
 on the transaction also satisfies the POW difficulty of a block.</div><div=
><br></div><div>7. Transaction POW difficulty.</div><div><br></div><div>Blo=
ck POW difficulty can remain as it currently does, to produce blocks at app=
roximately 10 minute intervals.</div><div><br></div><div>Transaction POW di=
fficulty affects the rate at which mined transactions are produced.</div><d=
iv><br></div><div>Now, since each transaction contains a prev block hash an=
 important decision to make is whether to mandate that all transactions wit=
hin a block contain the same prev block hash, and that the prev block so re=
ferenced is the immediate previous ancestor block, or whether any transacti=
on may be admitted into a block so long as the prev block referenced by the=
 transaction is any previous ancestor in the main chain.</div><div><br></di=
v><div>If the former, then any transactions which don&#39;t make it into a =
block must be re-mined for inclusion in the next block. Hence this more clo=
sely 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 proportional to the block size. The transaction POW di=
fficulty can be adjusted 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>Greater decentralisation of POW leads to increased mine=
d transaction rate (given sufficient unmined transaction rate production). =
The inverse is also true. Hence transaction rate and block size is proporti=
onal to degree of decentralisation.</div><div><br></div><div>8. Miscalleneo=
us observations.</div><div><br></div><div>Nodes only need work on transacti=
ons if they are valid.</div><div><br></div><div>Mined transactions are a we=
ak 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 the fee.</div><div><br></div><div>Transactions with hi=
gher fees and smaller size will be mined in preference.</div><div><br></div=
><div>Large block spam attack is expensive due to the POW needed to mine th=
e gigantic number of transactions.</div><div><br></div><div>Decentralisatio=
n of nodes is encouraged to be close to the location of real transaction or=
igination 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.</div><div><br></di=
v><div>Block-level reward is still a decentralised lottery. Transaction-lev=
el rewards go to those running the network. Fees will go up as it will be t=
he nodes that are mining transactions that need to be individually compensa=
ted, and not miners mining only block headers.</div><div><br></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div>

--001a11c303b22dc1f3051da886cc--