1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1WwagK-0001RZ-3p
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 17:26:56 +0000
X-ACL-Warn:
Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WwagI-0001W2-Dx for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 17:26:56 +0000
Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72])
by qmta10.westchester.pa.mail.comcast.net with comcast
id Ezgm1o0011ZXKqc5A5Sp2a; Mon, 16 Jun 2014 17:26:49 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
by omta21.westchester.pa.mail.comcast.net with comcast
id F5So1o00V4VnV2P3h5SoEL; Mon, 16 Jun 2014 17:26:49 +0000
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"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [76.96.62.17 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WwagI-0001W2-Dx
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incentivizing the running of full nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2014 17:26:56 -0000
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.
|
