Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to pay for data requests

From: Eric Lombrozo <elombrozo@gmail•com>
To: Luv Khemani <luvb@hotmail•com>
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
Date: Mon, 3 Aug 2015 10:22:16 -0700	[thread overview]
Message-ID: <CABr1YTdvd9wy-ypzKgJvyPt6NB_EB8c0epq9pUGsQk0Eh4AjAA@mail.gmail.com> (raw)
In-Reply-To: <BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 4926 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5639 bytes --]