From: Matt Whitlock <bip@mattwhitlock.name>
To: Justus Ranvier <justusranvier@gmail.com>
Date: Mon, 16 Jun 2014 13:26:48 -0400
Message-ID: <1801389.9PVWAZniMG@crushinator>
User-Agent: KMail/4.13.1 (Linux/3.12.20-gentoo; KDE/4.13.1; x86_64; ; )
In-Reply-To: <539F244C.2090009@gmail.com>
References: <87aaf81b20e17332175a3fbcd091c317.squirrel@fulvetta.riseup.net>
	<53959513.H7tOyQYvqT@crushinator> <539F244C.2090009@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
Precedence: list

On Monday, 16 June 2014, at 5:07 pm, Justus Ranvier wrote:
> On 06/16/2014 04:25 PM, Matt Whitlock wrote:
> > How can there be any kind of lottery that doesn't involve proof of
> > work or proof of stake? Without some resource-limiting factor,
> > there is no way to limit the number of "lottery tickets" any given
> > individual could acquire. The very process of Bitcoin mining was
> > invented specifically to overcome the Sybil problem, which had
> > plagued computer scientists for decades, and now you're proposing a
> > system that suffers from the same problem. Or am I wrong about
> > this?
> 
> If you allow the solution set to include pay-to-play networks, and not
> just free P2P networks, then it's easier to find a solution
> 
> Imagine every node is competing with its peers in terms of relevancy.
> Relevancy is established by delivering newly-seen transactions first.
> 
> Each node keeps track of which of its peers send it transactions that
> it hadn't seen and forwarded to them yet (making sure that the
> transactions do make it into a block) and uses that information to
> determine whether or not it should be paying that peer, or if that
> peer should be paying it, or if they are equal relevancy and no net
> payment is required.
> 
> Once any given pair of nodes can establish who, if anyone, should be
> paying they could use micropayment channels to handle payments.
> 
> Nodes that are well connected, and with high uptimes would end up
> being net recipients of payments. Mobile nodes and other low-uptime
> nodes would be net payers.
> 
> Now that you've established a market for the service of delivering
> transaction information, you can rely on price signals to properly
> match supply and demand.
> 
> People who hate market-based solutions could always run these nodes
> and configure them to refuse to pay anyone, and to charge nothing to
> their peers, if that's what they wanted.

This is a cool idea, but doesn't it generate some perverse incentives? If I'm running a full node and I want to pay CheapAir for some plane tickets, I'll want to pay in the greatest number of individual transactions possible, to maximize the rewards that I'll receive from my connected peers. This maybe would not be a problem if transaction fees were required on all transactions, but as it is (e.g., while fee-free transactions can be accepted into blocks if they have high enough priority), I can "preload" my wallet with hundreds of small-ish outputs, let them sit there for a few months to accumulate coin age, and then spend each little piece in a separate transaction when it comes time to pay for a big-ticket purchase. It's more lucrative for me to pay for my plane ticket in 100 separate, low-value transactions than in one high-value transaction. So you're incentivizing greater consumption of bandwidth and storage.