path: root/2e/3b572ac23d1a2eb04b30eb50099b85d39d5ec6

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 2D97CFF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 17:22:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com
	[209.85.217.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC8E31F2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  3 Aug 2015 17:22:18 +0000 (UTC)
Received: by lbbud7 with SMTP id ud7so77653847lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 03 Aug 2015 10:22:17 -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=6A0EVEFVMh/2OQ3434rqrqWKCo0TpFp3CQmsp5NBfwI=;
	b=PreN/MNj9Mt9Rvbm6/rkT4kAbRsPODKz11FJsKA34+Zq0EstT3amnYl66I9bSF/15L
	RCtrqhYpTPKLj+U27uJtCaIzRYqHMLxVJ9MxiEzXNqZd9w5iDBxs0z5lYCigEruF29kQ
	7ZHQkDOHL8CC9ZTo072d3JCYmTMYv8gAwYLHtejTBRSGhn5am/f2OPzE6rjOnsK7PMxP
	yHP9HKKkVq9dzDHsaZ7myY6hrD+3fb0N6FB160R2eDJMWLNeYX5stq/bpVY3GIWYpv8x
	oHaoBQad9N+vGq66k8LCKBuxebVNYT3T5leQ1cz7DW/asqJWfFZ3SGR0008bOd8pfKN1
	JbDQ==
MIME-Version: 1.0
X-Received: by 10.112.162.70 with SMTP id xy6mr18401939lbb.122.1438622536954; 
	Mon, 03 Aug 2015 10:22:16 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 3 Aug 2015 10:22:16 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 3 Aug 2015 10:22:16 -0700 (PDT)
In-Reply-To: <BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>
References: <BLU172-W18766B61EF807ACC5F3DBCC2770@phx.gbl>
	<BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>
Date: Mon, 3 Aug 2015 10:22:16 -0700
Message-ID: <CABr1YTdvd9wy-ypzKgJvyPt6NB_EB8c0epq9pUGsQk0Eh4AjAA@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Luv Khemani <luvb@hotmail.com>
Content-Type: multipart/alternative; boundary=089e0112d15e47fc80051c6b6971
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:22:20 -0000

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

I proposed something along these lines in the lightning-dev mailing list:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000088.html

It's probably a little off-topic there...but I'm very interested in
discussing such ideas.
On Aug 3, 2015 10:06 AM, "Luv Khemani via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> 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
>
>

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

<p dir=3D"ltr">I proposed something along these lines in the lightning-dev =
mailing list: <a href=3D"http://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2015-July/000088.html">http://lists.linuxfoundation.org/pipermail/li=
ghtning-dev/2015-July/000088.html</a></p>
<p dir=3D"ltr">It&#39;s probably a little off-topic there...but I&#39;m ver=
y interested in discussing such ideas.</p>
<div class=3D"gmail_quote">On Aug 3, 2015 10:06 AM, &quot;Luv Khemani via b=
itcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribut=
ion"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">


<div><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr">The current bl=
ock size debate has brought up an important, albeit often neglected observa=
tion. 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 incr=
ease, which will further reduce the number of full nodes . A few people hav=
e mentioned it in blogs or reddit, but the topic is generally quickly overs=
hadowed by posts along the lines of =C2=A0&quot;RAISE the blocksize already=
!&quot;.<div><br></div><div>Full nodes bear the full cost of=C2=A0validatin=
g/relaying/storing the blockchain and servicing SPV clients but gain nothin=
g financially from it, yet they serve an important role in validating trans=
actions and keeping miner dishonesty in check. If there were few independen=
t full nodes, it would be possible for 3-4 of the biggest mining pools to c=
ollude and do literally whatever they wanted with the protocol, including i=
nflating the money supply, freezing funds or even confiscating funds, becau=
se who would know? And even if someone running a full node did voice out, t=
he majority of users on SPV/Coinbase/etc.. would be powerless to do anythin=
g about it and would likely bear with the changes to protect status quo, ju=
st as is the case with current fiat regimes where people bear with QE/Infla=
tion/bail outs because they are so dependent on the current system that the=
y would rather tolerate any injustice than to have the system go down and b=
ring them with it.=C2=A0</div><div>This is the primary reason why many in t=
he technical community are against drastic blocksize increases, as this wil=
l only worsen the problem of decentralization as this cost increases. And a=
s long as full nodes are running on charity, i&#39;m fully in agreement wit=
h the conservative block size camp.=C2=A0</div><div><br></div><div>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 individual=
s around the globe.=C2=A0<span style=3D"font-size:12pt">The core issue in m=
y opinion is that of incentive, because at the end of the day, running a fu=
ll node is not free and at larger blocks costs will not be trivial. In my o=
pinion, its perhaps our insistence that full nodes cant be incentivised tha=
t contributes to centralization pressures and discourages increasing of blo=
cksize even though the technology exists to support it.</span><div><br>Tech=
nically, existing hardware is capable of validating/processing blocks in th=
e 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 y=
ou are not mining, as you can afford to wait a couple of minutes to downloa=
d your block. This is obviously not the case for miners who need to downloa=
d new blocks asap to avoid idle hash power or as has been seen in the recen=
t fork, SPV mining (which is extremely undesirable for the network). IBLT s=
hould 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 investi=
ng 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 minin=
g low.=C2=A0<br><br>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 l=
onger be an issue. A node could advertise it&#39;s rates to a SPV nodes upo=
n connection and the SPV could either agree or look for another node with l=
ower fees. If implemented, fees are likely to be trivial(few satoshis per r=
equest) 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 inc=
rease decentralization of the network.</div></div><div><br></div><div>I jus=
t wanted to float the idea and hear comments/feedback/critiques of this ide=
a.</div></div>
 		 	   		  </div></div> 		 	   		  </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>

--089e0112d15e47fc80051c6b6971--