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
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com>)
id 1U5mxq-0005IY-9V for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 00:46:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
email.bitpay.com designates 198.37.155.136 as permitted sender)
client-ip=198.37.155.136;
envelope-from=bounces+404635-86d7-bitcoin-development=lists.sourceforge.net@email.bitpay.com;
helo=o19837155136.outbound-mail.sendgrid.net;
Received: from [198.37.155.136] (helo=o19837155136.outbound-mail.sendgrid.net)
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1U5mxm-00033X-6u for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 00:46:14 +0000
Received: by 10.37.4.219 with SMTP id mf79.22707.511C1D873
Wed, 13 Feb 2013 17:11:03 -0600 (CST)
Received: from mail-la0-f48.google.com (unknown [209.85.215.48])
by mi15 (SG) with ESMTP id 511c1d87.37ce.1a986f5
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Feb 2013 17:11:03 -0600 (CST)
Received: by mail-la0-f48.google.com with SMTP id fq13so1704168lab.21
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Feb 2013 15:11:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:mime-version:x-originating-ip:in-reply-to:references
:from:date:message-id:subject:to:cc:content-type:x-gm-message-state;
bh=qcVzQkEHz8m+SxHZWpLdkWnYR4H/2sdpiT8OXeYgV00=;
b=d39N24UZM3j80psrBoH1pCQ/N5NHFW1mbH81tVETTCKtFglYWC7l+1Kav2VGJikal0
3n7j4UVC9rjyKq3A+lyME4OFyvvpJwToz/jqvysjziKx3p20tmDyvlfjAt/qD0Nshw77
ujPq9iQLmlOzTYP666rFrHTCDN547YbRfCG+KoPlK8jBCHIzEKlUiPQC/u6CdjOD2jRz
jtlwy9neqVm/5QR/b8wPimn8AqzXmsXQZES2BaOLmz/LfwuWr/bw1VSaAmcJg24jh1yq
k/lVDmVrEXAsGJ0Gld7+MddFl/zaWkp7HrurqWX5h+V34nhcIIDzqbJC4BIqFGwULcWT
DHUQ==
X-Received: by 10.112.29.72 with SMTP id i8mr9550509lbh.33.1360797061355; Wed,
13 Feb 2013 15:11:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.1.47 with HTTP; Wed, 13 Feb 2013 15:10:21 -0800 (PST)
X-Originating-IP: [71.204.90.78]
In-Reply-To: <CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
From: Stephen Pair <stephen@bitpay.com>
Date: Wed, 13 Feb 2013 18:10:21 -0500
Message-ID: <CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04016997741b9304d5a341bd
X-Gm-Message-State: ALoCoQkucNyGDaGakTHxi8VzCHvXT6g7e5TtZYjLjBpKAnvOEDy1qmwFN7aCn989y1wS+6hUJb5E
X-Sendgrid-EID: MKV9IjI68is80Jqz/eG9wzL0RPGq34wm6zZKLyf9fV5O8HKFIs9vx7uQQ4ODbOsX7TBKgAJK1fxx+XzyEClnulgedJ97Fy0tAv28lwXLnCtcmCUvV7w4XodiHCPgFePvEDcWV6YUAjmFozq6CCurgQ==
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
1.0 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Headers-End: 1U5mxm-00033X-6u
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
modifications into the block chain
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: Thu, 14 Feb 2013 00:46:14 -0000
--f46d04016997741b9304d5a341bd
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 13, 2013 at 4:02 PM, Gavin Andresen <gavinandresen@gmail.com>wr=
ote:
> On Wed, Feb 13, 2013 at 10:42 AM, Gregory Maxwell <gmaxwell@gmail.com>wro=
te:
>
>> Since, in the long run,
>> Bitcoin can't meet its security and decenteralization promises without
>> blockspace scarcity to drive non-trivial fees and without scaling
>> limits to keep it decenteralized=97 it's not a change that could be made
>> more lightly than changing the supply of coin.
>>
>
> I disagree with Gregory on this. I believe that Bitcoin CAN meet its
> security and decentralization promises without any hard limit on block
> size.
>
> I had a fruitful discussion about this with an economist friend this
> weekend, and I'll eventually getting around to writing up why I believe
> raising the block size limit will not be a problem.
If you've already validated the majority of transactions in a block, isn't
validating the block not all that compute intensive? Thus, it's really not
blocks that should be used to impose any sort of scarcity, but rather it's
the costs associated with the validation and propagation of the
transactions themselves...which is the way it should be.
When I think about issues like this, I like to remind myself that the mesh
network isn't really an essential part of Bitcoin. It is a way to
disseminate transactions and blocks, but it's by no means the only possible
way and could certainly be improved in various ways. Nodes can at some
point start to charge fees to collect and distribute transactions and
blocks. Collectives of such nodes could pool together fees to ensure
connected nodes can propagate and hear about transactions and blocks.
These nodes would charge based on the bandwidth and the work required to
validate transactions. They would also charge for the propagation of
blocks based on the work required to validate them. Miners would of course
have a lot of incentive to pay for such services since they will want to
get access to as many fee bearing transactions as possible (and filter out
the transactions they don't want to include in blocks). They will also
want the blocks to ensure they're always building on the latest valid
block. That in turn would give these relay nodes a window into the fees
needed to ensure fast inclusion into the block chain (something that
wallets could use to automatically set fees on transactions).
Note, I think the bitcoin protocol might actually be ideally suited for
this type of thing...nodes would broadcast INV messages all day long, but
as soon as one of your peers wants the actual transaction or block, well,
then you have to pay up. Two relay nodes sending transactions between each
other would pay each other when they have to download the transaction
body...if they trade roughly equal amounts of transactions, they wouldn't
end up owing each other anything...for a given transaction they would pull
the data exactly, but would then turn around and provide that transaction
to many connected peers, earning a fee for each delivery.
P.S. such a fee structure would address the spam issue with economics
rather than rules about spammy transactions
P.P.S. micropayment channels could be used as the payment method for nodes
that validate and relay transactions...this would actually be a very good
first use of that technology (people have talked about micropayment
channels for renting bandwidth...why not use them to pay for the bandwidth
and CPU needed to validate and relay transactions)
--f46d04016997741b9304d5a341bd
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Wed, Feb 13, 2013 at 4:02 PM=
, Gavin Andresen <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmai=
l.com" target=3D"_blank">gavinandresen@gmail.com</a>></span> wrote:<br><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Feb 13, 2013 at 10=
:42 AM, Gregory Maxwell <span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gm=
ail.com" target=3D"_blank">gmaxwell@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div>=A0Since, in the long run,</div>
Bitcoin can't meet its security and decenteralization promises without<=
br>
blockspace scarcity to drive non-trivial fees and without scaling<br>
limits to keep it decenteralized=97 it's not a change that could be mad=
e<br>
more lightly than changing the supply of coin.<br></blockquote><div><br></d=
iv></div><div>I disagree with Gregory on this. =A0I believe that Bitcoin CA=
N meet its security and decentralization promises without any hard limit on=
block size.=A0</div>
</div><div><br></div>I had a fruitful discussion about this with an economi=
st friend this weekend, and I'll eventually getting around to writing u=
p why I believe raising the block size limit will not be a problem.</blockq=
uote>
</div><br>
</div><div class=3D"gmail_extra" style>If you've already validated the =
majority of transactions in a block, isn't validating the block not all=
that compute intensive? =A0Thus, it's really not blocks that should be=
used to impose any sort of scarcity, but rather it's the costs associa=
ted with the validation and propagation of the transactions themselves...wh=
ich is the way it should be.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>When =
I think about issues like this, I like to remind myself that the mesh netwo=
rk isn't really an essential part of Bitcoin. =A0It is a way to dissemi=
nate transactions and blocks, but it's by no means the only possible wa=
y and could certainly be improved in various ways. =A0Nodes can at some poi=
nt start to charge fees to collect and distribute transactions and blocks. =
=A0Collectives of such nodes could pool together fees to ensure connected n=
odes can propagate and hear about transactions and blocks. =A0These nodes w=
ould charge based on the bandwidth and the work required to validate transa=
ctions. =A0They would also charge for the propagation of blocks based on th=
e work required to validate them. =A0Miners would of course have a lot of i=
ncentive to pay for such services since they will want to get access to as =
many fee bearing transactions as possible (and filter out the transactions =
they don't want to include in blocks). =A0They will also want the block=
s to ensure they're always building on the latest valid block. =A0That =
in turn would give these relay nodes a window into the fees needed to ensur=
e fast inclusion into the block chain (something that wallets could use to =
automatically set fees on transactions).</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
>Note, I think the bitcoin protocol might actually be ideally suited for th=
is type of thing...nodes would broadcast INV messages all day long, but as =
soon as one of your peers wants the actual transaction or block, well, then=
you have to pay up. =A0Two relay nodes sending transactions between each o=
ther would pay each other when they have to download the transaction body..=
.if they trade roughly equal amounts of transactions, they wouldn't end=
up owing each other anything...for a given transaction they would pull the=
data exactly, but would then turn around and provide that transaction to m=
any connected peers, earning a fee for each delivery.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>P.S. =
such a fee structure would address the spam issue with economics rather tha=
n rules about spammy transactions</div><div class=3D"gmail_extra" style><br>
</div>
<div class=3D"gmail_extra" style>P.P.S. micropayment channels could be used=
as the payment method for nodes that validate and relay transactions...thi=
s would actually be a very good first use of that technology (people have t=
alked about micropayment channels for renting bandwidth...why not use them =
to pay for the bandwidth and CPU needed to validate and relay transactions)=
</div>
<div class=3D"gmail_extra"><br></div></div>
<img src=3D"http://email.bitpay.com/wf/open?upn=3DFPVR34OW0iTCykNVpPzODvIQt=
2S-2BzCNFBszsV6r9gX31pUdL7Qn-2Be1uVJ4jTNxzgk7joAZEPEbmT0NG0jGPrrSSCg1uO2ESz=
CdDx15N3yrbY7ab-2Batve0xlTPVtkLR8E0iNvfECqptv6jcGd3dIoMJI6phxD9kP2LtiTsp5uJ=
tRp0zHP9n-2FGC6qozbNUvCm6GzwuCnzFmv0OKXTj6Mc5Yg-3D-3D" alt=3D"" width=3D"1"=
height=3D"1" border=3D"0" style=3D"height:1px !important;width:1px !import=
ant;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !impo=
rtant;margin-right:0 !important;margin-left:0 !important;padding-top:0 !imp=
ortant;padding-bottom:0 !important;padding-right:0 !important;padding-left:=
0 !important;"/>
--f46d04016997741b9304d5a341bd--
|
