MIME-Version: 1.0
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
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
Precedence: list

--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">&gt;&gt; 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&gt;o upgrade.</span><br></div><div><br></div=
></span><div style=3D"font-size:12.8px">&gt; 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 &quot;any inv=
alid blocks they produce&quot; 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&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<w=
br>linuxfoundation.org</a>&gt;</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--