From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D97CFF for ; 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 ; Mon, 3 Aug 2015 17:22:18 +0000 (UTC) Received: by lbbud7 with SMTP id ud7so77653847lbb.3 for ; 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: References: Date: Mon, 3 Aug 2015 10:22:16 -0700 Message-ID: From: Eric Lombrozo To: Luv Khemani 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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

It's probably a little off-topic there...but I'm ver= y interested in discussing such ideas.

On Aug 3, 2015 10:06 AM, "Luv Khemani via b= itcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
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"RAISE the blocksize already= !".

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
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'm fully in agreement wit= h the conservative block size camp.=C2=A0

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=A0The 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.

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

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

I jus= t wanted to float the idea and hear comments/feedback/critiques of this ide= a.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e0112d15e47fc80051c6b6971--