From: Matt Whitlock <bip@mattwhitlock•name>
To: Justus Ranvier <justusranvier@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
Date: Mon, 16 Jun 2014 13:26:48 -0400 [thread overview]
Message-ID: <1801389.9PVWAZniMG@crushinator> (raw)
In-Reply-To: <539F244C.2090009@gmail.com>
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.
next prev parent reply other threads:[~2014-06-16 17:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 8:12 Odinn Cyberguerrilla
2014-06-16 11:35 ` Mike Hearn
2014-06-16 16:25 ` Matt Whitlock
2014-06-16 17:07 ` Justus Ranvier
2014-06-16 17:26 ` Matt Whitlock [this message]
2014-06-16 17:59 ` Mike Hearn
2014-06-16 18:10 ` Matt Whitlock
2014-06-16 19:00 ` Justus Ranvier
2014-06-16 20:55 ` Justus Ranvier
2014-06-17 17:47 ` Odinn Cyberguerrilla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1801389.9PVWAZniMG@crushinator \
--to=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=justusranvier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox