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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B53DD71
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 21:37:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com
[209.85.214.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19ED2107
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 21:37:41 +0000 (UTC)
Received: by obbop1 with SMTP id op1so88336141obb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Aug 2015 14:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=gZGDoknXTTEW1qWNmeIgZ7ouM/Kx+RHLhTSkPiTQb/A=;
b=ATlquBXJXhCejaeXUe42yq4EC+bAR9GmIEpfYTx1ACJ3kFHtva2K0Xt7M5C9ycVvej
itqfd97Bdz5KR4EvomRDm8PbCPN/hWGRCoPDIsiEHg0tJIvIjzwRpEPtU0axBM7YsK83
0a2n69OcqXMDTzxGSlWh1yOUrv1E/aU59GWODfzVnGSkNAR49GyU3KuM/5Fp1/EmS9Hv
Fr39GQ+ndBMC78DDnOP9hm/+KjopWjiN/wMYOGmG9tH6W0AUPOBt0hivWPO4ALDK+P3R
4dI3wvB9IKMsZfizOP/DruzouAUwZiUKsBukp1GwEeYOz5RclLEnWx8YgGm2KzpW8JHg
G+pA==
X-Received: by 10.60.76.69 with SMTP id i5mr8692860oew.42.1438983460563; Fri,
07 Aug 2015 14:37:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.116.207 with HTTP; Fri, 7 Aug 2015 14:37:01 -0700 (PDT)
In-Reply-To: <CAOG=w-sCULNw=C75iot=6q4Yb16VvYh=F4DahS3ZEkEpGLvu3w@mail.gmail.com>
References: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
<CAOG=w-sCULNw=C75iot=6q4Yb16VvYh=F4DahS3ZEkEpGLvu3w@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 7 Aug 2015 18:37:01 -0300
Message-ID: <CAKzdR-qpJzWoUVNUuhPh5sQQc2w-JZP9BqX4hRZG4c8_xujxQA@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b33d3480130a0051cbf7231
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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] If you had a single chance to double the
transactions/second Bitcoin allows...
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: Fri, 07 Aug 2015 21:37:41 -0000
--047d7b33d3480130a0051cbf7231
Content-Type: text/plain; charset=UTF-8
Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
Obviously this is not a technical response to the technical issues you
argue. But "minutes" is a time scale we humans use to measure time very
often.
:)
On Fri, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> Because halving the block interval comes with costs to SPV proofs (which
> double the number of headers) and mining centralization (doubles the
> selfish mining effect of latency) for the questionable benefit of a block
> expectation time that is still measured in minutes, not seconds.
>
> Doubling the block size is safer than halving the block interval, for the
> same effect in aggregate transactions per second.
>
> On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> What would you do?
>>
>> a. Double the block size
>> b. Reduce the block rate to a half (average 5 minute blocks)
>>
>> Suppose this is a one time hard fork. There no drastic technical problems
>> with any of them: "SPV" mining and the relay network has shown that block
>> propagation is not an issue for such as small change. Mining centralization
>> won't radically change for a 2x adjustment.
>>
>> So what would be best for Bitcoin?
>>
>> I suspect some (if not most of you) would choose b. Because reducing the
>> block interval saves us real time. Waiting 30 minutes for a 3-block
>> confirmation is... such a long time! Time that we value. Time that
>> sometimes we waste waiting. Time that makes a difference for us. Doubling
>> the block size does not change the user perception of Bitcoin in any way.
>>
>> Then why most discussions go around doubling the block size?
>>
>> Each change require less than 20 lines of code (*) in the reference code,
>> and minimum change in other wallets.
>>
>> Currently there is no idle mining hardware for hire, so the security of
>> six 10-minute block confirmation is equivalent to the security of six
>> 5-minute block confirmations, as described in Satoshi's paper (if there
>> were 51% spare mining hardware for hire, then obviously hiring that
>> hardware for 30 minutes would cost less than hiring it for 1 hour).
>>
>> Why we discuss a 2x block size increase and not a 1/2 block interval
>> reduction? Aren't we Bitcoin users after all?
>>
>> Best regards,
>> Sergio.
>>
>> (*) b requires increasing the transaction version number, to support the
>> old nLockTime rate.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--047d7b33d3480130a0051cbf7231
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mark,<div>It took you 3 minutes to respond to my e-mail. A=
nd I responded to you 4 minutes later. If you had responded to me in 10 min=
utes, I would be of out the office and we wouldn't have this dialogue. =
So 5 minutes is a lot of time.</div><div><br></div><div>Obviously this is n=
ot a technical response to the technical issues you argue. But "minute=
s" is a time scale we humans use to measure time very often.</div><div=
><br></div><div>:)</div><div><br></div><div><br></div><div><div><br></div><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri=
, Aug 7, 2015 at 6:27 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=3D=
"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>>=
;</span> 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"><div>Bec=
ause halving the block interval comes with costs to SPV proofs (which doubl=
e the number of headers) and mining centralization (doubles the selfish min=
ing effect of latency) for the questionable benefit of a block expectation =
time that is still measured in minutes, not seconds.<br><br></div>Doubling =
the block size is safer than halving the block interval, for the same effec=
t in aggregate transactions per second.<br></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Aug 7, 2015 =
at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>></span> wrote:<br></div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">What wou=
ld you do?<div><br></div><div>a. Double the block size</div><div>b. Reduce =
the block rate to a half (average 5 minute blocks)</div><div><br></div><div=
><div>Suppose this is a one time hard fork. There no drastic technical prob=
lems with any of them: "SPV" mining and the relay network has sho=
wn that block propagation is not an issue for such as small change. Mining =
centralization won't radically change for a 2x adjustment.=C2=A0</div><=
div><br></div><div>So what would be best for Bitcoin?</div></div><div><br><=
/div><div>I suspect some (if not most of you) would choose b. Because reduc=
ing the block interval saves us real time. Waiting 30 minutes for a 3-block=
confirmation is... such a long time! Time that we value. Time that sometim=
es we waste waiting. Time that makes a difference for us. Doubling the bloc=
k size does not change the user perception of Bitcoin in any way.</div><div=
><br></div><div>Then why most discussions go around doubling the block size=
?<br></div><div><br></div><div><div>Each change require less than 20 lines =
of code (*) in the reference code, and minimum change in other wallets.=C2=
=A0</div><div><br></div><div>Currently there is no idle mining hardware for=
hire, so the security of six 10-minute block confirmation is equivalent to=
the security of six 5-minute block confirmations, as described in Satoshi&=
#39;s paper (if there were 51% spare mining hardware for hire, then obvious=
ly hiring that hardware for 30 minutes would cost less than hiring it for 1=
hour).</div></div><div><br></div><div>Why we discuss a 2x block size incre=
ase and not a 1/2 block interval reduction? Aren't we Bitcoin users aft=
er all?</div><div><br></div><div>Best regards,</div><div>=C2=A0Sergio.</div=
><div><br></div><div>(*) b requires increasing the transaction version numb=
er, to support the old nLockTime rate.<br></div><div><br></div><div><br></d=
iv></div>
<br></div></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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></div>
</blockquote></div><br></div>
--047d7b33d3480130a0051cbf7231--
|
