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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5F78E273
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Aug 2015 17:29:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com
[209.85.220.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BFC0930
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 Aug 2015 17:29:20 +0000 (UTC)
Received: by pacgq8 with SMTP id gq8so29532098pac.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 03 Aug 2015 10:29:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=036NoyPGP8KQdTha1QYrj4dJlS7G7EeeAnvLo4ybCLM=;
b=ix4L/49IjbY/8dLVIQ11ncLYNCCKfAxsnb89hEkZvOvaXDCdt1h1OgguSC/JAJpRiI
WU2edvvOtzJzWEhpBsXbd04r/aSuL1D6VXcJeIooxud4dNbrdOyasne8cbxVo48lqn8J
HPq1TsEOtS8/CVw2otb18OlxeqwRAlBLF0M6qxd2b450HhLptO7+6GFcEhsVXXx95Jhw
D7cGRF4+WNvaYJHTLqIpN4OKIkOtLwwxh8Fs7VEhKtRrExFkip5s8O/nIMpHgHK8/v0/
hh8UJd4vmTy+9KVLZfTiFzc77mGpbSp6x/9m7iTnIRrUU0T9a8QCCi47LEkQzr2fY9Qt
ZUSw==
X-Gm-Message-State: ALoCoQmMLPrQzemgjb4J02mlB7MQUpOa7E1VozpTiqm25NkUppoYGyFnzyVM1cd7zK3N4AUs7DS1
X-Received: by 10.68.200.68 with SMTP id jq4mr26082407pbc.54.1438622960116;
Mon, 03 Aug 2015 10:29:20 -0700 (PDT)
Received: from [10.0.1.14] (c-67-161-88-20.hsd1.wa.comcast.net. [67.161.88.20])
by smtp.googlemail.com with ESMTPSA id
iu10sm8547641pbd.5.2015.08.03.10.29.18
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 03 Aug 2015 10:29:19 -0700 (PDT)
Message-ID: <55BFA507.9050902@voskuil.org>
Date: Mon, 03 Aug 2015 10:29:43 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Luv Khemani <luvb@hotmail.com>, "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
References: <BLU172-W18766B61EF807ACC5F3DBCC2770@phx.gbl>
<BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>
In-Reply-To: <BLU172-W348AAB2648B8D7D323A68DC2770@phx.gbl>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="h5jmPoXCGnSiUBEFbaCIErK4P0j8mOi0M"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Incentivising full nodes by having SPV nodes to
pay for data requests
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 17:29:21 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--h5jmPoXCGnSiUBEFbaCIErK4P0j8mOi0M
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The typical interpretation of the "tragedy of the commons" scenario is
based on the presumption that a limited resource is controlled by the sta=
te.
In a free market there is no such idea, a limited resource becomes
property and is therefore allocated by customer preference and
maintained by self-interest.
Validation is not a resource controlled by the state, which is of course
the point of Bitcoin.
It is inaccurate to think of Bitcoin validation a limited resource. The
scenario in which fewer people validate does not reduce the amount of
validation available. It increases the risk of loss to those who fail to
validate. The gain to those who do validate comes from avoiding that loss=
=2E
e
On 08/03/2015 10:06 AM, Luv Khemani via bitcoin-dev 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!".
>=20
> 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 fia=
t
> 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.=20
> 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.=20
>=20
> 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 o=
f
> reach of many individuals around the globe. The core issue in my opinio=
n
> is that of incentive, because at the end of the day, running a full nod=
e
> is not free and at larger blocks costs will not be trivial. In my
> opinion, its perhaps our insistence that full nodes cant be incentivise=
d
> that contributes to centralization pressures and discourages increasing=
> of blocksize even though the technology exists to support it.
>=20
> 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 cas=
e
> for miners who need to download new blocks asap to avoid idle hash powe=
r
> 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. Bu=
t
> 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 a=
s
> 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.=20
>=20
> Before the concept lightning, there did not seem to be any trustless wa=
y
> of feasibly paying small micropayments to full nodes for their services=
=2E
> 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=
=2E
> 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.
>=20
> I just wanted to float the idea and hear comments/feedback/critiques of=
> this idea.
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--h5jmPoXCGnSiUBEFbaCIErK4P0j8mOi0M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVv6UIAAoJEDzYwH8LXOFO1JwIAJ4Vq4yK9r1eOQDuat+7Mpo3
5N10wK6JfjT5fufrHbCN+afKdXjY1xVr2h7a0IBDJB+RWTz9kHu0iXccO6XRUBif
pwP+OE96Vyf5iMUpV8NpE12gKC/YZrStl27ZNg5qMxDnNNYfNPpC+1S+PaLJ1OTF
qneBSRamMlG3zlxYbClXAcLLIVVndKJ9L7q6ttWeZBoo2FPKsZrmqKKBu6FCaFQo
2zCHdvDLjfvoBY7DBh2JI+ad/iWBB+PgKW5Revk5irCZoPDhaZm6AJOrwRHC7Sp6
MdUFmExh4nibo3ptZvy99EuD+H7TpVKfdQReA4jrGrCJeIAvP4ADxcNBuZUm84s=
=rlrN
-----END PGP SIGNATURE-----
--h5jmPoXCGnSiUBEFbaCIErK4P0j8mOi0M--
|