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
|
Return-Path: <trevinhofmann@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D84840C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 20:37:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com [74.125.83.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D83625D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 20:37:29 +0000 (UTC)
Received: by mail-pg0-f50.google.com with SMTP id 21so19940199pgg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 26 Mar 2017 13:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=u5HpRVQ1EOqvu/y8pM4YMRp54Jpn9u9kJImueHRUSqY=;
b=Olkhx0hEpxHilr3eQCfq5diDFRtzvaWm7tfKPH28vx5Dxpvkecfh+cLnPSUjlL6UnO
/zhr3mDAAZbw5hRsdMBYgSkF+nU2vkaIg3Ho4awpGsAnUKtC2Qw9Ew5hIwzN1rGnutLt
FnFEkJIXN3xQyOBWBzoIJNo0ba9GtHFzV3X7yL5GeTlEwRy0y6RbLEJMPOhCovH77iVX
jpNTdM1TbamQos0GA+RdG0JU5muxpOBPEQJai5vHYAxFWK97RzMUVO2XpQIBpQmZjySa
Qu4zLvhgbA3ljgBOaws33ZqYf3QpRn9rdUOMf22iXC7mhzUjTkr5KYExDwohWr+lKoay
22Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=u5HpRVQ1EOqvu/y8pM4YMRp54Jpn9u9kJImueHRUSqY=;
b=NYe7ymbyQW+yB6pJ7UgvOYNrcpuhQtPK0bTMdsYBGpmkpQhlhl8PjV/EwGcQgEMHWP
HhPuG7s4hsGyVy0Ke5+MGgf+7dSQ7V9mB+baEuzJj1G6bRqiABxY4j/86pTkCusqbUX7
GmuYTV6A4Jnsiy92c/w4QgqLNpEAHshEdyY9RhynX6a8sT9awQOz2LKk2IsSXriEv0f0
KONM660kkA2AMBCEZM8M5XGSMIiaoC0TArOMzX4JKNOxA7TqAhrcvCsnJqOzfG+uJ9qK
Z7tt5SwlSjzOoEn8P4yJ33BOHmPMc8Cb/aG4TJyu33P/XN4EXcT7Hl9UgFi5aLERJtrf
iH7g==
X-Gm-Message-State: AFeK/H11L4zQQ444pAdKtCM9aFqSy7RMHX/3Mln3Dp9ZhwuHyJAybjcsNp/X+47PmaI8zjrMll2rDbfWz/+jVQ==
X-Received: by 10.84.225.146 with SMTP id u18mr340113plj.86.1490560648649;
Sun, 26 Mar 2017 13:37:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.143.143 with HTTP; Sun, 26 Mar 2017 13:37:28 -0700 (PDT)
In-Reply-To: <CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
<35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com>
<f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info>
<9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com>
<CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
<9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com>
<CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com>
From: Trevin Hofmann <trevinhofmann@gmail.com>
Date: Sun, 26 Mar 2017 15:37:28 -0500
Message-ID: <CALd2G5dCLHDxV6Daq6q=AMuW8ytPGMKjAdXHxZzsUccJbKJKSg@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045ec540faa0ad054ba8315a
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Sun, 26 Mar 2017 20:48:21 +0000
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
malicious miner takeover?
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: Sun, 26 Mar 2017 20:37:29 -0000
--f403045ec540faa0ad054ba8315a
Content-Type: text/plain; charset=UTF-8
>> With a tightening of the rule set, a hash power minority that has not
upgraded will not produce a minority branch; instead they will simply have
any invalid blocks they produce orphaned, serving as a wake-up call t>o
upgrade.
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.
He stated that "any invalid blocks they produce" will be orphaned. This is
not false. If non-upgraded miners do not produce blocks that are invalid
per the new rules, their blocks will not be orphaned. This is consistent
with Peter's comment.
-Trevin
On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> With a tightening of the rule set, a hash power minority that has not
>> upgraded will not produce a minority branch; instead they will simply have
>> any invalid blocks they produce orphaned, serving as a wake-up call to
>> upgrade.
>>
>
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
> will not be orphaned unless they are intentionally segwit-invalid (which
> they currently are not). If you have told miners otherwise, let me know.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f403045ec540faa0ad054ba8315a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"gmail-im" style=3D"font-size:12.8px"><div><=
span style=3D"font-size:12.8px">>> With a tightening of the rule set,=
a hash power minority that has not upgraded will not produce a minority br=
anch; instead they will simply have any invalid blocks they produce orphane=
d, serving as a wake-up call t>o upgrade.</span><br></div><div><br></div=
></span><div style=3D"font-size:12.8px">> False. With bip9-based soft-fo=
rk-based activation of segwit, miner blocks will not be orphaned unless the=
y are intentionally segwit-invalid (which they currently are not). If you h=
ave told miners otherwise, let me know.<br><br>He stated that "any inv=
alid blocks they produce" will be orphaned. This is not false. If non-=
upgraded miners do not produce blocks that are invalid per the new rules, t=
heir blocks will not be orphaned. This is consistent with Peter's comme=
nt.</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:=
12.8px">-Trevin</div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <sp=
an dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wro=
te:<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 class=3D"gmail_=
extra"><div class=3D"gmail_quote"><span class=3D"">On Sun, Mar 26, 2017 at =
2:05 PM, Peter R via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<w=
br>linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div style=3D"word-wrap:break-word"><div><div><div>With a tightening of=
the rule set, a hash power minority that has not upgraded will not produce=
a minority branch; instead they will simply have any invalid blocks they p=
roduce orphaned, serving as a wake-up call to upgrade.</div></div></div></d=
iv></blockquote><div><br></div></span><div>False. With bip9-based soft-fork=
-based activation of segwit, miner blocks will not be orphaned unless they =
are intentionally segwit-invalid (which they currently are not). If you hav=
e told miners otherwise, let me know.</div><div><br></div></div><div class=
=3D"m_8979519589113278200gmail_signature" data-smartmail=3D"gmail_signature=
">- Bryan<br><a href=3D"http://heybryan.org/" target=3D"_blank">http://heyb=
ryan.org/</a><br><a href=3D"tel:(512)%20203-0507" value=3D"+15122030507" ta=
rget=3D"_blank">1 512 203 0507</a></div>
</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>
--f403045ec540faa0ad054ba8315a--
|
