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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
