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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D8DA5F2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 19:04:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com
[209.85.218.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84D39174
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 19:04:02 +0000 (UTC)
Received: by mail-oi0-f44.google.com with SMTP id l9so46380259oia.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 11:04:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=cauaKz+Di6gaSJd7oHljbQFq/eyoiKqOP+1TDSAY3D8=;
b=WwJMT68za9Jz6+dJWsZbul0Ez8mxfUr4Pg/7XZSe3ZYkUHRY5wOWkdbiOPbdBmeyc3
XW4Zqgvl+2w7Zq0hBbIp1rfBpK9cYYtA6HXAFRKUpPgyLz/E35rwffJEZYnCJM4VVBC7
ILcyF+Ar9b8uEehnPMB+OtX2Uf5yU1dGiTWJJEV8/aZRZ1JxXtNQ3DWlWB5GsGIe6zix
nRRgwt1LPZDErQcE+Qq+85k7gh+th7aUFA878dVrwjXbp1YiIkknh6sMJ06U9ZHiccXP
zWwzF2lJj2uSLruqXBQoYbRlIWDw4nCPwNIeX4EYOWlwPbFsHx+LpmNXkkF/IO1/yiI6
GWMw==
MIME-Version: 1.0
X-Received: by 10.202.227.199 with SMTP id a190mr3683984oih.35.1450551841919;
Sat, 19 Dec 2015 11:04:01 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.135.101 with HTTP; Sat, 19 Dec 2015 11:04:01 -0800 (PST)
In-Reply-To: <CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
<CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
<CA+c4Zozac8=aMrAJ1N_6SR9eBD+w0e70cEnk9CG_2oZ72AS-8g@mail.gmail.com>
<CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.com>
Date: Sat, 19 Dec 2015 11:04:01 -0800
X-Google-Sender-Auth: E0AnX19iTTCDy3sGxoCiO-ljvyc
Message-ID: <CAGLBAhejrg=xgjeSy4UJLt92hUz8H0=a7sO859weX3=+p+hD6Q@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11407c8c441b05052744ebb1
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
moral hazard
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: Sat, 19 Dec 2015 19:04:04 -0000
--001a11407c8c441b05052744ebb1
Content-Type: text/plain; charset=UTF-8
I've already publicly declared that I offer one bitcoin to "those who
suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way
too sloppy. Here's a better idea that transmits the economic power of
merchants and customers (well, anyone with bitcoin) to the miners on whom
they must rely for confirmations:
The bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be
pledged to a miner. Here is how that miner earns the reward:
1. Wait until a core dev signs a release of bitcoin core in which the
limit is double it's current level.
2. Use the new release to mine, but use a soft limit on the blocksize to
produce only blocks that are valid according to the old software.
3. Wait until May 5th, 2016.
4. Remove the soft limit on blocksize.
5. Create a block that breaks the old limit and is valid according to
the new signed release.
6. Wait for the new large block to be orphaned.
Hopefully, the reward will be greater than 25 bitcoins and therefore cover
the transaction fees. Of course, if they wait until after the halving in
step 3, then they will get twice the (new, 12.5 btc) reward if they can
arrange for the orphaning of their own block.
Any core dev could do this but I guess it would be playing with fire. So
maybe Satoshi will do it. He played with fire (right?) and look how that
worked out. Come on, someone, be a hero. Mike and Gavin tried, but I
think they went a little overboard.
Another way to do this is to identify the position in each binary where the
hard limit is stored, and write a little script that will (check the date
first, and then) alter the data at that position so that currently running
bitcoin software can be hot-patched on May 5th without the help of any core
devs (if that would work). Obviously, the little script should be signed
by a competent programmer whom the user trusts, a slightly less stringent
requirement than being an actual core dev.
notplato
On Fri, Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Dec 18, 2015 2:13 AM, "sickpig@gmail.com" <sickpig@gmail.com> wrote:
> > 1.75 x 0.5 + 1 x 0.5 = 1.375
> >
> > after six month.
> >
> > An hard-fork on the others side would bring 1.75 since the activation,
> am I right?
>
> Yes.
>
> However, SW immediately gives a 1.75 capacity increase for anyone who
> adopts it, after the softfork, instantly. They don't need to wait for
> anyone else.
>
> A hard fork is an orthogonal improvement, which is also needed if we don't
> want to be stuck with a constant maximum ultimately.
>
> Hardforks can however only be deployed at a time when all full node
> software can reasonably have agreed to upgrade, while a softfork can be
> deployed much earlier.
>
> They are independent improvements, and we need both. I am however of the
> opinion that hard forks need a much clearer consensus and much longer
> rollout timeframes to be safe (see my thread on the security of softforks).
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--001a11407c8c441b05052744ebb1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've already publicly declared that I offer one b=
itcoin to "those who suffer from a <span tabindex=3D"0" class=3D""><sp=
an class=3D"">May 5, 2016</span></span> hardfork to 2MB blocks" but th=
at's probably way too sloppy.=C2=A0 Here's a better idea that trans=
mits the economic power of merchants and customers (well, anyone with bitco=
in) to the miners on whom they must rely for confirmations:<br><br></div>Th=
e bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be p=
ledged to a miner.=C2=A0 Here is how that miner earns the reward:<br><ol><l=
i>Wait until a core dev signs a release of bitcoin core in which the limit =
is double it's current level.</li><li>Use the new release to mine, but =
use a soft limit on the blocksize to produce only blocks that are valid acc=
ording to the old software.</li><li>Wait until May 5th, 2016.</li><li>Remov=
e the soft limit on blocksize.<br></li><li>Create a block that breaks the o=
ld limit and is valid according to the new signed release.</li><li>Wait for=
the new large block to be orphaned.</li></ol><p>Hopefully, the reward will=
be greater than 25 bitcoins and therefore cover the transaction fees.=C2=
=A0 Of course, if they wait until after the halving in step 3, then they wi=
ll get twice the (new, 12.5 btc) reward if they can arrange for the orphani=
ng of their own block.</p><p>Any core dev could do this but I guess it woul=
d be playing with fire.=C2=A0 So maybe Satoshi will do it.=C2=A0 He played =
with fire (right?) and look how that worked out.=C2=A0 Come on, someone, be=
a hero.=C2=A0 Mike and Gavin tried, but I think they went a little overboa=
rd.</p><p>Another way to do this is to identify the position in each binary=
where the hard limit is stored, and write a little script that will (check=
the date first, and then) alter the data at that position so that currentl=
y running bitcoin software can be hot-patched on May 5th without the help o=
f any core devs (if that would work).=C2=A0 Obviously, the little script sh=
ould be signed by a competent programmer whom the user trusts, a slightly l=
ess stringent requirement than being an actual core dev.</p><p>notplato<br>=
</p></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri,=
Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"><br>
On Dec 18, 2015 2:13 AM, "<a href=3D"mailto:sickpig@gmail.com" target=
=3D"_blank">sickpig@gmail.com</a>" <<a href=3D"mailto:sickpig@gmail=
.com" target=3D"_blank">sickpig@gmail.com</a>> wrote:<br>
> 1.75 x 0.5 + 1 x 0.5 =3D 1.375<br>
><br>
> after six month.=C2=A0<br>
><br>
> An hard-fork on the others side would bring 1.75 since the activation,=
am I right?</p>
</span><p dir=3D"ltr">Yes.</p>
<p dir=3D"ltr">However, SW immediately gives a 1.75 capacity increase for a=
nyone who adopts it, after the softfork, instantly. They don't need to =
wait for anyone else.</p>
<p dir=3D"ltr">A hard fork is an orthogonal improvement, which is also need=
ed if we don't want to be stuck with a constant maximum ultimately.</p>
<p dir=3D"ltr">Hardforks can however only be deployed at a time when all fu=
ll node software can reasonably have agreed to upgrade, while a softfork ca=
n be deployed much earlier.</p>
<p dir=3D"ltr">They are independent improvements, and we need both. I am ho=
wever of the opinion that hard forks need a much clearer consensus and much=
longer rollout timeframes to be safe (see my thread on the security of sof=
tforks).</p><span class=3D"HOEnZb"><font color=3D"#888888">
<p dir=3D"ltr">--=C2=A0<br>
Pieter<br>
</p>
</font></span><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature"><div dir=3D"ltr">I like to provide some work at no charge to pr=
ove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.l=
itmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.m=
emeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm th=
e webmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">T=
he Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=
=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>=
.<br>"He ought to find it more profitable to play by the rules" -=
Satoshi Nakamoto</div></div>
</div>
--001a11407c8c441b05052744ebb1--
|
