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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1Ysiyr-0002qq-Vt
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 02:34:37 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.181 as permitted sender)
client-ip=209.85.220.181; envelope-from=voisine@gmail.com;
helo=mail-qk0-f181.google.com;
Received: from mail-qk0-f181.google.com ([209.85.220.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ysiyo-0000qe-KS
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 02:34:37 +0000
Received: by qkp63 with SMTP id 63so4221894qkp.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 19:34:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.31.40 with SMTP id f40mr4081391qkf.49.1431570869222; Wed,
13 May 2015 19:34:29 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Wed, 13 May 2015 19:34:29 -0700 (PDT)
In-Reply-To: <CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<CABm2gDoQ-atjWKB0c6AC1ZQ9fy22ceFtHHwpLmnX8DLW4DAgYA@mail.gmail.com>
<CACq0ZD4_zxhm=qWrP+Nr+fQER4s2R8i7qRjX4HsBWN46uOP2MA@mail.gmail.com>
<CAPg+sBjxXe0spytGsP1BUzNZhJFDYu_yacdhTy5F+O-X8EG7NQ@mail.gmail.com>
<CACq0ZD7qF0oEYHfQFxLMn3OOD=ibVAfE-U5YURLrtmWVMzDpgQ@mail.gmail.com>
<CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@mail.gmail.com>
<CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
Date: Wed, 13 May 2015 19:34:29 -0700
Message-ID: <CACq0ZD41uSuLibsSCLfgbhT2qrryZuZvE1oUBfLgYnWpr3WBWw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a114780b821833d05160191e2
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(voisine[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Ysiyo-0000qe-KS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
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 May 2015 02:34:38 -0000
--001a114780b821833d05160191e2
Content-Type: text/plain; charset=UTF-8
> I concede the point. Perhaps a flag date based on previous observation of
network upgrade rates with a conservative additional margin in addition to
supermajority of mining power.
It occurs to me that this would allow for a relatively small percentage of
miners to stop the upgrade if the flag date turns out to be poorly chosen
and a large number of non-mining nodes haven't upgraded yet. Would be a
nice safety fallback.
Aaron Voisine
co-founder and CEO
breadwallet.com
On Wed, May 13, 2015 at 6:31 PM, Aaron Voisine <voisine@gmail.com> wrote:
> > by people and businesses deciding to not use on-chain settlement.
>
> I completely agree. Increasing fees will cause people voluntary economize
> on blockspace by finding alternatives, i.e. not bitcoin. A fee however is a
> known, upfront cost... unpredictable transaction failure in most cases will
> be a far higher, unacceptable cost to the user than the actual fee. The
> higher the costs of using the system, the lower the adoption as a
> store-of-value. The lower the adoption as store-of-value, the lower the
> price, and the lower the value of bitcoin to the world.
>
> > That only measures miner adoption, which is the least relevant.
>
> I concede the point. Perhaps a flag date based on previous observation of
> network upgrade rates with a conservative additional margin in addition to
> supermajority of mining power.
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, May 13, 2015 at 6:19 PM, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
>
>> On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine@gmail.com> wrote:
>>
>>> Conservative is a relative term. Dropping transactions in a way that is
>>> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
>>> increasing the blocksize, drastic as it is, is the more conservative choice.
>>>
>>
>> Transactions are already being dropped, in a more indirect way: by people
>> and businesses deciding to not use on-chain settlement. That is very sad,
>> but it's completely inevitable that there is space for some use cases and
>> not for others (at whatever block size). It's only a "things don't fit
>> anymore" when you see on-chain transactions as the only means for doing
>> payments, and that is already not the case. Increasing the block size
>> allows for more utility on-chain, but it does not fundamentally add more
>> use cases - only more growth space for people already invested in being
>> able to do things on-chain while externalizing the costs to others.
>>
>>
>>> I would recommend that the fork take effect when some specific large
>>> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
>>> safer alternative to a simple flag date, but I'm sure I wouldn't have to
>>> point out that option to people here.
>>>
>>
>> That only measures miner adoption, which is the least relevant. The
>> question is whether people using full nodes will upgrade. If they do, then
>> miners are forced to upgrade too, or become irrelevant. If they don't, the
>> upgrade is risky with or without miner adoption.
>>
>> --
>> Pieter
>>
>>
>
--001a114780b821833d05160191e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:13px">I concede the poi=
nt. Perhaps a flag date based on previous observation of network upgrade ra=
tes with a conservative additional margin in addition to supermajority of m=
ining power.</span><div><span style=3D"font-size:13px"><br></span></div><di=
v>It occurs to me that this would allow for a relatively small percentage o=
f miners to stop the upgrade if the flag date turns out to be poorly chosen=
and a large number of non-mining nodes haven't upgraded yet. Would be =
a nice safety fallback.</div></div><div class=3D"gmail_extra"><br clear=3D"=
all"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"=
ltr"><div><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http=
://breadwallet.com" target=3D"_blank">breadwallet.com</a></div></div></div>=
</div></div></div>
<br><div class=3D"gmail_quote">On Wed, May 13, 2015 at 6:31 PM, Aaron Voisi=
ne <span dir=3D"ltr"><<a href=3D"mailto:voisine@gmail.com" target=3D"_bl=
ank">voisine@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><span class=3D"">>=C2=A0<span style=3D"font-size:13=
px">by people and businesses deciding to not use on-chain settlement.</span=
><div><span style=3D"font-size:13px"><br></span></div></span><div>I complet=
ely agree. Increasing fees will cause people voluntary economize on blocksp=
ace by finding alternatives, i.e. not bitcoin. A fee however is a known, up=
front cost... unpredictable transaction failure in most cases will be a far=
higher, unacceptable cost to the user than the actual fee. The higher the =
costs of using the system, the lower=C2=A0the adoption as a store-of-value.=
The lower the adoption as store-of-value, the lower the price, and the low=
er the value of bitcoin to the world.</div><span class=3D""><div><span styl=
e=3D"font-size:13px"><br></span></div><div><span style=3D"font-size:13px">&=
gt;=C2=A0</span><span style=3D"font-size:13px">That only measures miner ado=
ption, which is the least relevant.</span></div><div><span style=3D"font-si=
ze:13px"><br></span></div></span><div>I concede the point. Perhaps a flag d=
ate based on previous observation of network upgrade rates with a conservat=
ive additional margin in addition to supermajority of mining power.</div></=
div><div class=3D"gmail_extra"><span class=3D""><br clear=3D"all"><div><div=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aaron Voisine</div><div>co=
-founder and CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">br=
eadwallet.com</a></div></div></div></div></div></div>
<br></span><div><div class=3D"h5"><div class=3D"gmail_quote">On Wed, May 13=
, 2015 at 6:19 PM, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pi=
eter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Wed=
, May 13, 2015 at 6:13 PM, Aaron Voisine <span dir=3D"ltr"><<a href=3D"m=
ailto:voisine@gmail.com" target=3D"_blank">voisine@gmail.com</a>></span>=
wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Conservative is a relati=
ve term. Dropping transactions in a way that is unpredictable to the sender=
sounds incredibly drastic to me. I'm suggesting increasing the blocksi=
ze, drastic as it is, is the more conservative choice.</div></blockquote><d=
iv><br></div></span><div>Transactions are already being dropped, in a more =
indirect way: by people and businesses deciding to not use on-chain settlem=
ent. That is very sad, but it's completely inevitable that there is spa=
ce for some use cases and not for others (at whatever block size). It's=
only a "things don't fit anymore" when you see on-chain tran=
sactions as the only means for doing payments, and that is already not the =
case. Increasing the block size allows for more utility on-chain, but it do=
es not fundamentally add more use cases - only more growth space for people=
already invested in being able to do things on-chain while externalizing t=
he costs to others.<br>=C2=A0<br></div><span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"gmail_extra">I would recommend that the fork take effect whe=
n some specific large supermajority of the pervious 1000 blocks indicate th=
ey have upgraded, as a safer alternative to a simple flag date, but I'm=
sure I wouldn't have to point out that option to people here.</div></b=
lockquote><div><br></div></span><div>That only measures miner adoption, whi=
ch is the least relevant. The question is whether people using full nodes w=
ill upgrade. If they do, then miners are forced to upgrade too, or become i=
rrelevant. If they don't, the upgrade is risky with or without miner ad=
option.<span><font color=3D"#888888"><br><br>-- <br></font></span></div><sp=
an><font color=3D"#888888"><div>Pieter<br><br></div></font></span></div></d=
iv></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
--001a114780b821833d05160191e2--
|
