path: root/4c/5e6c4f5ffe335d630c758f674fd0f8c7a2a297

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E62A2279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 17:54:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
	[209.85.215.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 308C2150
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 17:54:14 +0000 (UTC)
Received: by labix3 with SMTP id ix3so5419828lab.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 10:54:12 -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=UdF6/wJIWspliSfhS6/4FLNyLpyuiFqpJiiaAJ+bpMM=;
	b=G9wbjNct4LQJbwhUOsuTEeIq+cqQfcM1omp9eSUs/jtlSmEnXrWF26tcaXXCiZu8JM
	wip1FOmPQzuHQlqyfyS5IsyxX4z1CmYYRLnpGbrFea1L3JRKRdUPT3P27oTxcb3eWa7Z
	9HFiesBolcDkJ+b/dIRsdmkTI2wmlKotJuo7DgXhgNXIIv2A66d3v9zc26Hje96XLOyJ
	xwav5LAI88lDqS9RjEQ7XjpTXY/R1bLnqoYSw7hSVgBzefpLyT8vMhsP3icrLeN8Bjq2
	RHgNjzUM2I+bFf/bsa/YYiIswB+m6UfBUdUTVH6iaXOmocvKNjVe+8Q3sNjPdQQPfydj
	cXjw==
MIME-Version: 1.0
X-Received: by 10.112.144.69 with SMTP id sk5mr18254373lbb.6.1438624452409;
	Mon, 03 Aug 2015 10:54:12 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 3 Aug 2015 10:54:12 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 3 Aug 2015 10:54:12 -0700 (PDT)
In-Reply-To: <55BFA507.9050902@voskuil.org>
References: <BLU172-W18766B61EF807ACC5F3DBCC2770@phx.gbl>
	<BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>
	<55BFA507.9050902@voskuil.org>
Date: Mon, 3 Aug 2015 10:54:12 -0700
Message-ID: <CABr1YTcX3-PFOkEos9xGxTRM6TRP-kM0GhmRaNf1BQ_gfmbViA@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary=047d7b3432f4737f18051c6bdbfe
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: Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to
 pay for data requests
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: Mon, 03 Aug 2015 17:54:16 -0000

--047d7b3432f4737f18051c6bdbfe
Content-Type: text/plain; charset=UTF-8

The point is that without concrete direct incentives, many might find it
rational to just leech off others...which might actually work for a
while...but this is obviously not stable equilibrium...and it's very hard
to do any game theory on it.

Current SPV implementations necessarily diverge from the p2p model and
strongly tend toward a client/server architecture. It was originally
thought that mining would provide an incentive to run servers...but we all
know that's not at all how things have turned out.

Using offchain protocols with blockchain settlement guarantees, it is
possible for clients to request proofs directly from servers without
requiring any additional authentication layers...and can perhaps even be
onion-routed to hide the client's identity.

Checking SPV proofs is cheap...it only requires downloading headers,
checking PoW, and constructing a lookup table mapping block hashes to
merkle roots. This structure can easily be stored entirely in RAM on
typical consumer devices (it's at most 80 bytes per block, or a little over
30MB right now and grows at a very manageable rate). The most expensive
step to prove inclusion of a specific transaction in the blockchain is then
O(log n) sha256 operations, where n is the number of transactions in the
block.

Using p2sh, we ensure the txout script is a mere 22 bytes. Full validation
nodes can fully prune the partial merkle tree structure when the output is
spent. SPV proof serving nodes would still need to store full blocks...but
as long as they are getting paid for this market forces could lead to a
stable balance between clients and servers...or at least adaptive dynamics
that prevent deficits or surpluses.

If I screwed something up in this analysis someone please correct me.

- Eric
On Aug 3, 2015 10:29 AM, "Eric Voskuil via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The typical interpretation of the "tragedy of the commons" scenario is
> based on the presumption that a limited resource is controlled by the
> state.
>
> In a free market there is no such idea, a limited resource becomes
> property and is therefore allocated by customer preference and
> maintained by self-interest.
>
> Validation is not a resource controlled by the state, which is of course
> the point of Bitcoin.
>
> It is inaccurate to think of Bitcoin validation a limited resource. The
> scenario in which fewer people validate does not reduce the amount of
> validation available. It increases the risk of loss to those who fail to
> validate. The gain to those who do validate comes from avoiding that loss.
>
> e
>
>
> On 08/03/2015 10:06 AM, Luv Khemani via bitcoin-dev wrote:
> > The current block size debate has brought up an important, albeit often
> > neglected observation. Full nodes suffer from a tragedy of the commons
> > problem and therefore are likely to continue decreasing as a percentage
> > of total Bitcoin nodes. This also results in a vicious circle as more
> > and more people use SPVs, the burden on existing full nodes will
> > increase even without a block size increase, which will further reduce
> > the number of full nodes . A few people have mentioned it in blogs or
> > reddit, but the topic is generally quickly overshadowed by posts along
> > the lines of  "RAISE the blocksize already!".
> >
> > Full nodes bear the full cost of validating/relaying/storing the
> > blockchain and servicing SPV clients but gain nothing financially from
> > it, yet they serve an important role in validating transactions and
> > keeping miner dishonesty in check. If there were few independent full
> > nodes, it would be possible for 3-4 of the biggest mining pools to
> > collude and do literally whatever they wanted with the protocol,
> > including inflating the money supply, freezing funds or even
> > confiscating funds, because who would know? And even if someone running
> > a full node did voice out, the majority of users on SPV/Coinbase/etc..
> > would be powerless to do anything about it and would likely bear with
> > the changes to protect status quo, just as is the case with current fiat
> > regimes where people bear with QE/Inflation/bail outs because they are
> > so dependent on the current system that they would rather tolerate any
> > injustice than to have the system go down and bring them with it.
> > This is the primary reason why many in the technical community are
> > against drastic blocksize increases, as this will only worsen the
> > problem of decentralization as this cost increases. And as long as full
> > nodes are running on charity, i'm fully in agreement with the
> > conservative block size camp.
> >
> > However, it is important to note that this seems to be an economic
> > problem instead of a technical one. I cannot deny the argument from the
> > big block side that technically, the hardware/bandwidth required to run
> > full nodes supporting considerably larger blocks (4MB-8MB) is not out of
> > reach of many individuals around the globe. The core issue in my opinion
> > is that of incentive, because at the end of the day, running a full node
> > is not free and at larger blocks costs will not be trivial. In my
> > opinion, its perhaps our insistence that full nodes cant be incentivised
> > that contributes to centralization pressures and discourages increasing
> > of blocksize even though the technology exists to support it.
> >
> > Technically, existing hardware is capable of validating/processing
> > blocks in the region of an order of magnitude larger than the current
> > limit. Bandwidth requirements for running a validating full node are
> > also not very high if you are not mining, as you can afford to wait a
> > couple of minutes to download your block. This is obviously not the case
> > for miners who need to download new blocks asap to avoid idle hash power
> > or as has been seen in the recent fork, SPV mining (which is extremely
> > undesirable for the network). IBLT should help greatly in reducing the
> > propagation time of new blocks and ease peak bandwidth requirements. But
> > im not worried about the miners, they are after all being financially
> > compensated for what they are doing and investing in more
> > bandwidth(either locally or running a full node remotely) can be seen as
> > a cost of the business as long as the cost of running a full node is
> > insignificant to the cost of hashing equipment to keep barriers to
> > mining low.
> >
> > Before the concept lightning, there did not seem to be any trustless way
> > of feasibly paying small micropayments to full nodes for their services.
> > However, with payment channels and lightning, this may no longer be an
> > issue. A node could advertise it's rates to a SPV nodes upon connection
> > and the SPV could either agree or look for another node with lower fees.
> > If implemented, fees are likely to be trivial(few satoshis per request)
> > as competition will drive down fees close to the cost of running a full
> > node. This should spur an increase in the number of full nodes and
> > increase decentralization of the network.
> >
> > I just wanted to float the idea and hear comments/feedback/critiques of
> > this idea.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<p dir=3D"ltr">The point is that without concrete direct incentives, many m=
ight find it rational to just leech off others...which might actually work =
for a while...but this is obviously not stable equilibrium...and it&#39;s v=
ery hard to do any game theory on it.</p>
<p dir=3D"ltr">Current SPV implementations necessarily diverge from the p2p=
 model and strongly tend toward a client/server architecture. It was origin=
ally thought that mining would provide an incentive to run servers...but we=
 all know that&#39;s not at all how things have turned out.</p>
<p dir=3D"ltr">Using offchain protocols with blockchain settlement guarante=
es, it is possible for clients to request proofs directly from servers with=
out requiring any additional authentication layers...and can perhaps even b=
e onion-routed to hide the client&#39;s identity.</p>
<p dir=3D"ltr">Checking SPV proofs is cheap...it only requires downloading =
headers, checking PoW, and constructing a lookup table mapping block hashes=
 to merkle roots. This structure can easily be stored entirely in RAM on ty=
pical consumer devices (it&#39;s at most 80 bytes per block, or a little ov=
er 30MB right now and grows at a very manageable rate). The most expensive =
step to prove inclusion of a specific transaction in the blockchain is then=
 O(log n) sha256 operations, where n is the number of transactions in the b=
lock.</p>
<p dir=3D"ltr">Using p2sh, we ensure the txout script is a mere 22 bytes. F=
ull validation nodes can fully prune the partial merkle tree structure when=
 the output is spent. SPV proof serving nodes would still need to store ful=
l blocks...but as long as they are getting paid for this market forces coul=
d lead to a stable balance between clients and servers...or at least adapti=
ve dynamics that prevent deficits or surpluses.</p>
<p dir=3D"ltr">If I screwed something up in this analysis someone please co=
rrect me.<br></p>
<p dir=3D"ltr">- Eric</p>
<div class=3D"gmail_quote">On Aug 3, 2015 10:29 AM, &quot;Eric Voskuil via =
bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribu=
tion"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">The typical interpretation of the &quo=
t;tragedy of the commons&quot; scenario is<br>
based on the presumption that a limited resource is controlled by the state=
.<br>
<br>
In a free market there is no such idea, a limited resource becomes<br>
property and is therefore allocated by customer preference and<br>
maintained by self-interest.<br>
<br>
Validation is not a resource controlled by the state, which is of course<br=
>
the point of Bitcoin.<br>
<br>
It is inaccurate to think of Bitcoin validation a limited resource. The<br>
scenario in which fewer people validate does not reduce the amount of<br>
validation available. It increases the risk of loss to those who fail to<br=
>
validate. The gain to those who do validate comes from avoiding that loss.<=
br>
<br>
e<br>
<br>
<br>
On 08/03/2015 10:06 AM, Luv Khemani via bitcoin-dev wrote:<br>
&gt; The current block size debate has brought up an important, albeit ofte=
n<br>
&gt; neglected observation. Full nodes suffer from a tragedy of the commons=
<br>
&gt; problem and therefore are likely to continue decreasing as a percentag=
e<br>
&gt; of total Bitcoin nodes. This also results in a vicious circle as more<=
br>
&gt; and more people use SPVs, the burden on existing full nodes will<br>
&gt; increase even without a block size increase, which will further reduce=
<br>
&gt; the number of full nodes . A few people have mentioned it in blogs or<=
br>
&gt; reddit, but the topic is generally quickly overshadowed by posts along=
<br>
&gt; the lines of=C2=A0 &quot;RAISE the blocksize already!&quot;.<br>
&gt;<br>
&gt; Full nodes bear the full cost of validating/relaying/storing the<br>
&gt; blockchain and servicing SPV clients but gain nothing financially from=
<br>
&gt; it, yet they serve an important role in validating transactions and<br=
>
&gt; keeping miner dishonesty in check. If there were few independent full<=
br>
&gt; nodes, it would be possible for 3-4 of the biggest mining pools to<br>
&gt; collude and do literally whatever they wanted with the protocol,<br>
&gt; including inflating the money supply, freezing funds or even<br>
&gt; confiscating funds, because who would know? And even if someone runnin=
g<br>
&gt; a full node did voice out, the majority of users on SPV/Coinbase/etc..=
<br>
&gt; would be powerless to do anything about it and would likely bear with<=
br>
&gt; the changes to protect status quo, just as is the case with current fi=
at<br>
&gt; regimes where people bear with QE/Inflation/bail outs because they are=
<br>
&gt; so dependent on the current system that they would rather tolerate any=
<br>
&gt; injustice than to have the system go down and bring them with it.<br>
&gt; This is the primary reason why many in the technical community are<br>
&gt; against drastic blocksize increases, as this will only worsen the<br>
&gt; problem of decentralization as this cost increases. And as long as ful=
l<br>
&gt; nodes are running on charity, i&#39;m fully in agreement with the<br>
&gt; conservative block size camp.<br>
&gt;<br>
&gt; However, it is important to note that this seems to be an economic<br>
&gt; problem instead of a technical one. I cannot deny the argument from th=
e<br>
&gt; big block side that technically, the hardware/bandwidth required to ru=
n<br>
&gt; full nodes supporting considerably larger blocks (4MB-8MB) is not out =
of<br>
&gt; reach of many individuals around the globe. The core issue in my opini=
on<br>
&gt; is that of incentive, because at the end of the day, running a full no=
de<br>
&gt; is not free and at larger blocks costs will not be trivial. In my<br>
&gt; opinion, its perhaps our insistence that full nodes cant be incentivis=
ed<br>
&gt; that contributes to centralization pressures and discourages increasin=
g<br>
&gt; of blocksize even though the technology exists to support it.<br>
&gt;<br>
&gt; Technically, existing hardware is capable of validating/processing<br>
&gt; blocks in the region of an order of magnitude larger than the current<=
br>
&gt; limit. Bandwidth requirements for running a validating full node are<b=
r>
&gt; also not very high if you are not mining, as you can afford to wait a<=
br>
&gt; couple of minutes to download your block. This is obviously not the ca=
se<br>
&gt; for miners who need to download new blocks asap to avoid idle hash pow=
er<br>
&gt; or as has been seen in the recent fork, SPV mining (which is extremely=
<br>
&gt; undesirable for the network). IBLT should help greatly in reducing the=
<br>
&gt; propagation time of new blocks and ease peak bandwidth requirements. B=
ut<br>
&gt; im not worried about the miners, they are after all being financially<=
br>
&gt; compensated for what they are doing and investing in more<br>
&gt; bandwidth(either locally or running a full node remotely) can be seen =
as<br>
&gt; a cost of the business as long as the cost of running a full node is<b=
r>
&gt; insignificant to the cost of hashing equipment to keep barriers to<br>
&gt; mining low.<br>
&gt;<br>
&gt; Before the concept lightning, there did not seem to be any trustless w=
ay<br>
&gt; of feasibly paying small micropayments to full nodes for their service=
s.<br>
&gt; However, with payment channels and lightning, this may no longer be an=
<br>
&gt; issue. A node could advertise it&#39;s rates to a SPV nodes upon conne=
ction<br>
&gt; and the SPV could either agree or look for another node with lower fee=
s.<br>
&gt; If implemented, fees are likely to be trivial(few satoshis per request=
)<br>
&gt; as competition will drive down fees close to the cost of running a ful=
l<br>
&gt; node. This should spur an increase in the number of full nodes and<br>
&gt; increase decentralization of the network.<br>
&gt;<br>
&gt; I just wanted to float the idea and hear comments/feedback/critiques o=
f<br>
&gt; this idea.<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
<br>
<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>

--047d7b3432f4737f18051c6bdbfe--