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
249
250
251
252
253
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rebroad@gmail.com>) id 1Z4SNg-0005Xh-LR
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 11:16:44 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174; envelope-from=rebroad@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4SNf-0007z0-3S
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 11:16:44 +0000
Received: by wigg3 with SMTP id g3so73784866wig.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 04:16:37 -0700 (PDT)
X-Received: by 10.194.77.179 with SMTP id t19mt32245029wjw.30.1434366997051;
Mon, 15 Jun 2015 04:16:37 -0700 (PDT)
MIME-Version: 1.0
Sender: rebroad@gmail.com
Received: by 10.194.47.237 with HTTP; Mon, 15 Jun 2015 04:16:16 -0700 (PDT)
In-Reply-To: <CANEZrP10gn+969d-oe-8Em9ipe4DOP9q0WkNtL6u-6V5aphkPQ@mail.gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
<CANEZrP0Z_EOmVgbvVmYDvegm6jfd1cKB52acXHocjRuM-qGEog@mail.gmail.com>
<CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
<CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com>
<CAPg+sBiPhhrBh8f3QxJLtoysfywtVFSo2RH0WXVR+vpX9z6+HQ@mail.gmail.com>
<CANEZrP10gn+969d-oe-8Em9ipe4DOP9q0WkNtL6u-6V5aphkPQ@mail.gmail.com>
From: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
Date: Mon, 15 Jun 2015 14:16:16 +0300
X-Google-Sender-Auth: E5tuoA9uucgVtHnthERj7LGg-v8
Message-ID: <CAFBxzAAExA-aE+8o-+HGQtnuwWuWpkt8Lbgxvh7hT64XkMKOPg@mail.gmail.com>
Content-Type: multipart/alternative; boundary=047d7bfced065652fe05188c9792
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
(rebroad[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
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: 1Z4SNf-0007z0-3S
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
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: Mon, 15 Jun 2015 11:16:44 -0000
--047d7bfced065652fe05188c9792
Content-Type: text/plain; charset=UTF-8
My understanding of this debate is that there are some people who want to
keep Bitcoin at 1MB block limit, and there are some who want to increase it.
I for one am curious to see how 1MB limited bitcoin evolves, and I believe
we can all have a chance to see this AND hard-fork bitcoin to remove the
block size restriction.
To remove the 1MB limit required a hard fork. This is not disputed. It's
what we do with the original (1MB limit) bitcoin that concerns me (and
other's I am sure).
What I would like to see is both being allowed to live. Harry Potter and
Voldermort! (Except neither are evil!)
The solution is to hard-fork and merge-mine. This way, both can live, and
mining power is not divided.
Dogecoin recently hardforked and this hardfork also involved switching to
merge-mining, so it's been done successfully.
So, simply, bitcoin as it is doesn't need to actually fork, but instead, at
a certain block size, a forked bitcoin with the blocksize lmit removed will
start to be merge-mined alongside bitcoin. Miners can be ready for this.
Wallets can be ready for this - in fact, for most wallets and merchants
they will possibly want to default to the bigger blocksize fork since this
caters for more transactions per block.
We still don't know how removing the block limit will pan out and what
other problems with scalability will arise in the future, so by preserving
the original bitcoin, we keep diversity, and people won't feel their
investments in bitcoin are being unnecessarily put at risk (as their
investments will stay in both the new and the old bitcoin).
The bitcoin core developers can implement a patch like the one recently
used for dogecoin, to allow the chain to fork at a set point, where at
which point, bitcoins will be split into the new and the old. Branding will
be an important issue here I think, so that there is as little confusion as
possible. I think this is a small price to pay in return for not killing
the original bitcoin (even if it's true that Satoshi did intend to remove
the 1MB limit at some point).
If I'm missing something obvious please let me know.
On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn <mike@plan99.net> wrote:
> The fact that using a centralized service is easier isn't a good reason
>> IMHO. It disregards the long-term, and introduces systemic risk.
>>
>
> Well sure, that's easy for you to say, but you have a salary :) Other
> developers may find the incremental benefits of decentralisation low vs
> adding additional features, for instance, and who is to say they are wrong?
>
>
>> But in cases where using a decentralized approach doesn't *add* anything,
>> I cannot reasonably promote it, and that's why I was against getutxos in
>> the P2P protocol.
>>
>
> It does add something though! It means, amongst other things, I can switch
> of all my servers, walk away for good, discard this Mike Hearn pseudonym I
> invented for Bitcoin and the app will still work :) Surely that is an
> important part of being decentralised?
>
> It also means that as the underlying protocol evolves over time, getutxos
> can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
> one more additional bit of security. If one day miners commit to UTXO sets,
> great, one more additional bit of security. When we start including input
> values in the signature hash, great ... one more step up in security.
>
> Anyway, I didn't really want to reopen this debate. I just point out that
> third party services are quite happy to provide whatever developers need to
> build great apps, even if doing so fails to meet some kind of perfect
> cryptographic ideal. And that's why they're winning devs.
>
> Now back to your regularly scheduled block size debates ...
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--047d7bfced065652fe05188c9792
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8000001907349px">My understand=
ing of this debate is that there are some people who want to keep Bitcoin a=
t 1MB block limit, and there are some who want to increase it.</span><div s=
tyle=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.=
8000001907349px">I for one am curious to see how 1MB limited bitcoin evolve=
s, and I believe we can all have a chance to see this AND hard-fork bitcoin=
to remove the block size restriction.</div><div style=3D"font-size:12.8000=
001907349px"><br></div><div style=3D"font-size:12.8000001907349px">To remov=
e the 1MB limit required a hard fork. This is not disputed. It's what w=
e do with the original (1MB limit) bitcoin that concerns me (and other'=
s I am sure).</div><div style=3D"font-size:12.8000001907349px"><br></div><d=
iv style=3D"font-size:12.8000001907349px">What I would like to see is both =
being allowed to live. Harry Potter and Voldermort! (Except neither are evi=
l!)</div><div style=3D"font-size:12.8000001907349px"><br></div><div style=
=3D"font-size:12.8000001907349px">The solution is to hard-fork and merge-mi=
ne. This way, both can live, and mining power is not divided.</div><div sty=
le=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.80=
00001907349px">Dogecoin recently hardforked and this hardfork also involved=
switching to merge-mining, so it's been done successfully.</div><div s=
tyle=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.=
8000001907349px">So, simply, bitcoin as it is doesn't need to actually =
fork, but instead, at a certain block size, a forked bitcoin with the block=
size lmit removed will start to be merge-mined alongside bitcoin. Miners ca=
n be ready for this. Wallets can be ready for this - in fact, for most wall=
ets and merchants they will possibly want to default to the bigger blocksiz=
e fork since this caters for more transactions per block.</div><div style=
=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.8000=
001907349px">We still don't know how removing the block limit will pan =
out and what other problems with scalability will arise in the future, so b=
y preserving the original bitcoin, we keep diversity, and people won't =
feel their investments in bitcoin are being unnecessarily put at risk (as t=
heir investments will stay in both the new and the old bitcoin).</div><div =
style=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12=
.8000001907349px">The bitcoin core developers can implement a patch like th=
e one recently used for dogecoin, to allow the chain to fork at a set point=
, where at which point, bitcoins will be split into the new and the old. Br=
anding will be an important issue here I think, so that there is as little =
confusion as possible. I think this is a small price to pay in return for n=
ot killing the original bitcoin (even if it's true that Satoshi did int=
end to remove the 1MB limit at some point).</div><div style=3D"font-size:12=
.8000001907349px"><br></div><div style=3D"font-size:12.8000001907349px">If =
I'm missing something obvious please let me know.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jun 15, 2015 at 1:5=
0 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" t=
arget=3D"_blank">mike@plan99.net</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>The fact that us=
ing a centralized service is easier isn't a good reason IMHO. It disreg=
ards the long-term, and introduces systemic risk.<br></div></div></div></di=
v></blockquote><div><br></div></span><div>Well sure, that's easy for yo=
u to say, but you have a salary :) Other developers may find the incrementa=
l benefits of decentralisation low vs adding additional features, for insta=
nce, and who is to say they are wrong?</div><span class=3D""><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div>But in cases where using a decentralized=
approach doesn't *add* anything, I cannot reasonably promote it, and t=
hat's why I was against getutxos in the P2P protocol.<br></div></div></=
div></div></blockquote><div><br></div></span><div>It does add something tho=
ugh! It means, amongst other things, I can switch of all my servers, walk a=
way for good, discard this Mike Hearn pseudonym I invented for Bitcoin and =
the app will still work :) Surely that is an important part of being decent=
ralised?</div><div><br></div><div>It also means that as the underlying prot=
ocol evolves over time, getutxos can evolve along side it. P2P protocol get=
s encrypted/authenticated? Great, one more additional bit of security. If o=
ne day miners commit to UTXO sets, great, one more additional bit of securi=
ty. When we start including input values in the signature hash, great ... o=
ne more step up in security.</div><div><br></div><div>Anyway, I didn't =
really want to reopen this debate. I just point out that third party servic=
es are quite happy to provide whatever developers need to build great apps,=
even if doing so fails to meet some kind of perfect cryptographic ideal. A=
nd that's why they're winning devs.</div><div><br></div><div>Now ba=
ck to your regularly scheduled block size debates ...=C2=A0</div></div></di=
v></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div>
--047d7bfced065652fe05188c9792--
|
