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
|
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 056662C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Nov 2016 01:39:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
[209.85.216.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 747D814B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Nov 2016 01:39:46 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id w33so53603284qtc.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 24 Nov 2016 17:39:46 -0800 (PST)
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;
bh=TW16ZzIba7xOJiUTd0FeRZ3q3tUOSytpb+s/Dz2H4sU=;
b=oHd68xUQYygVZ2404igsHYnav9aAoFiWB4rk/emUf2RQw5JJFlnlYde+L89xxz8g4M
aKVFVWG6WRZDK38B4oaF7UjFXNB8y4wdOts/D2JhaPL94T15Hwoh8eIK+D7D0E6aNCXf
VqSI1THkoM/AMRhekun05DlBZDwmYP45e9NZeAi2IMPWLkgAlUVwJ+lOlDkMQmHOqVnd
AGc5DZnf72sG1QrWs+UQr2gbahK4KG993Sl1iLrfJFQUjarAaIvGHTleRppl82vZCzOo
AnNv5YgVsMrS84FwHI6pnqzYTX4tnSBOM7C6vyABEfuibs4gpWJcEomxtLpPYkM1hlCd
qlCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=TW16ZzIba7xOJiUTd0FeRZ3q3tUOSytpb+s/Dz2H4sU=;
b=VKM3CGXZz+PQtqI6baHrEECMECUw3HGJm4deUo11wanpC1+YrMb1H2neiStyRtZtT5
oInC98a0ZyDfAtaZ1y5FTuGgxWqDJfleW5TIBNkNY541KZlLaEpXUWMe+RcDvYiQxegM
sTuE8IKGlEYcJQZua8tDkW/569NGRV9UD1ZHlj5VlOACREMwhn/vHKK4FSNU8Q0j8kmg
cUOA2WpANcRClAMWRR7uMjYiS//SN2nfJDxiHHsvtCJkMEBpHuIY/MK9D+s3UvTbF9/p
fFoPHqYk/EQQkudu8hueVb34qcCOnbmirADCZWl1ObQAXt16nwUx7T/3YdZ67w06kRtm
+uNA==
X-Gm-Message-State: AKaTC004einVo3bjwm5pxqHst4vKYNXBNWDyvl/XOlcpUVHgR2NcToKdZzI21ys+Dxas2B6Z2Sx2Bg4LI1FKIw==
X-Received: by 10.200.42.170 with SMTP id b39mr4914210qta.55.1480037985625;
Thu, 24 Nov 2016 17:39:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.35.13 with HTTP; Thu, 24 Nov 2016 17:39:05 -0800 (PST)
In-Reply-To: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com>
References: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 24 Nov 2016 22:39:05 -0300
Message-ID: <CAKzdR-r7or+DF64qxT=HLUvrtdkSQD0hpO43kUjfWS-397+yHA@mail.gmail.com>
To: Peter R <peter_r@gmx.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1137d72e632a910542163294
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 25 Nov 2016 11:53:09 +0000
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited
Node Deals With Large Blocks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 25 Nov 2016 01:39:47 -0000
--001a1137d72e632a910542163294
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Peter,
How would a person or exchange decide to accept a payment in BU if it does
not know the gate policy of 51% of the miners?
Suppose that the exchange receives B1,S2,S3,S4 (a big block at height 1,
and 3 small blocks at height 2, 3 and 4), and an alternate chain A1,A2,A3
(three small blocks). The first is the longest, but the second may be the
one 51% of the miners will extend.
Without knowing the policy of at least 51% of the miners (the maximum
acceptance depth) it's unclear if the exchange has to obey the longest
chain or the chain with higher probability of being extended.
If the maximum acceptance depth of the majority of miners is higher than 6
blocks, accepting a transaction with 6 confirmations is risky.
So BU would set a lower bound on the number of confirmations equal to the
maximum acceptance depth of the majority of miners.But miners do not
publish their acceptance depth, so basically users are clue-less. I think
miners should at least advertise their gate block size and acceptance depth
in their coinbase field.
Is there a game-theoretic analysis of confirmation blocks and their
probabilities in BU ?
Without a detailed analysis, unlimited block size seems a risky change to
Bitcoin, to me.
Regards, Sergio.
On Tue, Nov 22, 2016 at 1:31 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Dear all,
>
> Bitcoin Unlimited=E2=80=99s market-based solution to the block-size limit=
is
> slowly winning support from node operators and miners. With this increas=
ed
> attention, many people are asking for a better explanation of how Bitcoin
> Unlimited actually works. The article linked below describes how Bitcoin
> Unlimited=E2=80=99s excessive-block logic works from the perspective of a=
single
> node. (I=E2=80=99m hoping to do a follow-up article that describe how thi=
s
> =E2=80=9Cnode-scale=E2=80=9D behavior facilitates the emergence of a flui=
d and organic
> block size limit at the network scale.)
>
> https://medium.com/@peter_r/the-excessive-block-gate-how-
> a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4
>
> Best regards,
> Peter R
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1137d72e632a910542163294
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Hi Peter,<br><br>How would a person or exch=
ange decide to accept a payment in BU if it does not know the gate policy o=
f 51% of the miners?<br><br></div>Suppose that the exchange receives B1,S2,=
S3,S4 (a big block at height 1, and 3 small blocks at height 2, 3 and 4), a=
nd an alternate chain A1,A2,A3=C2=A0 (three small blocks). The first is the=
longest, but the second may be the one 51% of the miners will extend.<br><=
br>Without knowing=C2=A0 the policy of at least 51% of the miners (the maxi=
mum acceptance depth) it's unclear if the exchange has to obey the long=
est chain or the chain with higher probability of being extended. <br>If th=
e maximum acceptance depth of the majority of miners is higher than 6 block=
s, accepting a transaction with 6 confirmations is risky.<br></div>So BU wo=
uld set a lower bound on the number of confirmations equal to the maximum a=
cceptance depth of the majority of miners.But miners do not publish their a=
cceptance depth, so basically users are clue-less. I think miners should at=
least advertise their gate block size and acceptance depth in their coinba=
se field.<br></div><div><br></div><div>Is there a game-theoretic analysis o=
f confirmation blocks and their probabilities in BU ?<br></div><div>Without=
a detailed analysis, unlimited block size seems a risky change to Bitcoin,=
to me.<br><br>Regards, Sergio.<br></div><div><br></div><div><div><div><br>=
</div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Tue, Nov 22, 2016 at 1:31 PM, Peter R via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>De=
ar all,</div><div><br></div><div>Bitcoin Unlimited=E2=80=99s market-based s=
olution to the block-size limit is slowly winning support from node operato=
rs and miners.=C2=A0 With this increased attention, many people are asking =
for a better explanation of how Bitcoin Unlimited actually works.=C2=A0 The=
article linked below describes how Bitcoin Unlimited=E2=80=99s excessive-b=
lock logic works from the perspective of a single node. (I=E2=80=99m hoping=
to do a follow-up article that describe how this =E2=80=9Cnode-scale=E2=80=
=9D behavior facilitates the emergence of a fluid and organic block size li=
mit at the network scale.)</div><div><br></div><a href=3D"https://medium.co=
m/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with=
-large-blocks-22a4a5c322d4" target=3D"_blank">https://medium.com/@peter_r/<=
wbr>the-excessive-block-gate-how-<wbr>a-bitcoin-unlimited-node-<wbr>deals-w=
ith-large-blocks-<wbr>22a4a5c322d4</a><div><br></div><div>Best regards,</di=
v><div>Peter R</div></div><br>______________________________<wbr>__________=
_______<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a1137d72e632a910542163294--
|
