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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1Ysi0J-0000Hq-KF
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 01:32:03 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.171 as permitted sender)
client-ip=209.85.216.171; envelope-from=voisine@gmail.com;
helo=mail-qc0-f171.google.com;
Received: from mail-qc0-f171.google.com ([209.85.216.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Ysi0I-0002al-Gz
for bitcoin-development@lists.sourceforge.net;
Thu, 14 May 2015 01:32:03 +0000
Received: by qcvo8 with SMTP id o8so32535115qcv.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 May 2015 18:31:57 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.17.21 with SMTP id b21mr3585860qkh.71.1431567117070; Wed,
13 May 2015 18:31:57 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Wed, 13 May 2015 18:31:56 -0700 (PDT)
In-Reply-To: <CAPg+sBjs_y6Q7YAQjH1vd=WaRvObp+yuv-OcFFjg6umQ2=UCMQ@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>
Date: Wed, 13 May 2015 18:31:56 -0700
Message-ID: <CACq0ZD6hDN0AY7jza46SuSA=-TqEii99oqR1gQyPt_vA+PqQgw@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113fe0fe7c36ed051600b1ea
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: 1Ysi0I-0002al-Gz
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 01:32:03 -0000
--001a113fe0fe7c36ed051600b1ea
Content-Type: text/plain; charset=UTF-8
> 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
>
>
--001a113fe0fe7c36ed051600b1ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-size:13px">by people and bus=
inesses deciding to not use on-chain settlement.</span><div><span style=3D"=
font-size:13px"><br></span></div><div>I completely agree. Increasing fees w=
ill 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 t=
o the user than the actual fee. The higher the costs of using the system, t=
he lower=C2=A0the adoption as a store-of-value. The lower the adoption as s=
tore-of-value, the lower the price, and the lower the value of bitcoin to t=
he world.</div><div><span style=3D"font-size:13px"><br></span></div><div><s=
pan style=3D"font-size:13px">>=C2=A0</span><span style=3D"font-size:13px=
">That only measures miner adoption, which is the least relevant.</span></d=
iv><div><span style=3D"font-size:13px"><br></span></div><div>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 o=
f mining power.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><di=
v><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v><br>Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://bread=
wallet.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:19 PM, Pieter Wuil=
le <span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=
=3D"_blank">pieter.wuille@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wed, May 13, 2015 at =
6:13 PM, Aaron Voisine <span dir=3D"ltr"><<a href=3D"mailto:voisine@gmai=
l.com" target=3D"_blank">voisine@gmail.com</a>></span> wrote:<br></span>=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">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, dra=
stic as it is, is the more conservative choice.</div></blockquote><div><br>=
</div></span><div>Transactions are already being dropped, in a more indirec=
t way: by people and businesses deciding to not use on-chain settlement. Th=
at 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 transaction=
s as the only means for doing payments, and that is already not the case. I=
ncreasing the block size allows for more utility on-chain, but it does not =
fundamentally add more use cases - only more growth space for people alread=
y invested in being able to do things on-chain while externalizing the cost=
s to others.<br>=C2=A0<br></div><span class=3D""><blockquote class=3D"gmail=
_quote" 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=
when some specific large supermajority of the pervious 1000 blocks indicat=
e they have upgraded, as a safer alternative to a simple flag date, but I&#=
39;m sure I wouldn't have to point out that option to people here.</div=
></blockquote><div><br></div></span><div>That only measures miner adoption,=
which is the least relevant. The question is whether people using full nod=
es will upgrade. If they do, then miners are forced to upgrade too, or beco=
me irrelevant. If they don't, the upgrade is risky with or without mine=
r adoption.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>-- <br></=
font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div>Piete=
r<br><br></div></font></span></div></div></div>
</blockquote></div><br></div>
--001a113fe0fe7c36ed051600b1ea--
|
