MIME-Version: 1.0
In-Reply-To: <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.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>
From: Alphonse Pace <alp.bitcoin@gmail.com>
Date: Sun, 26 Mar 2017 15:20:56 -0500
Message-ID: <CAMBsKS9YMeHUsSRkGU2ef5vFrFgOTSsAhkHApdnU9ygqX_qDNw@mail.gmail.com>
To: Peter R <peter_r@gmx.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0d9348df67a8054ba7f634
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
Precedence: list

--94eb2c0d9348df67a8054ba7f634
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem.  Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would.  If you wish to fork off, please do so responsibly.

-Alphonse

On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different.  It=E2=80=99s different because the future network =
upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set.  (BTW=E2=80=
=94this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> 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 hav=
e
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potenti=
al
> confusion.  The idea behind orphaning the blocks of non-upgraded miners w=
as
> to serve as a wake-up call to upgrade, to reduce the chances of a minorit=
y
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change.  If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing.  The Level 3 anti-split protection takes this idea one ste=
p
> further to ensure that if a minority branch does emerge, that transaction=
s
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high=
,
> 95%.
>
>
> I=E2=80=99m very confident that most people do NOT want a split, especial=
ly the
> miners.  The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miner=
s
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well.  I believe this
> mechanism (or perhaps a modified version of it) to increase the block siz=
e
> limit will likewise work well.  All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions a=
re
> being created.  The =E2=80=9Cblock-size-limit gene" of network nodes is s=
imply
> evolving to allow the network to continue to grow in the way it has alway=
s
> grown. (If you=E2=80=99re interested, here is my talk at Coinbase where I=
 discuss
> this: https://www.youtube.com/watch?v=3DpWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wid=
e
> community consensus and the intention is not to overrule anyone's choice =
to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade.  Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy.  But in the case of a proposed BU hard fo=
rk
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different.  I still have never talked with a person
> in real life who doesn=E2=80=99t want the block size limit to increase.  =
Indeed, I
> have met people who worry that Bitcoin Unlimited is =E2=80=9Ctrying to ta=
ke
> over=E2=80=9D=E2=80=94and thus they are worried for other reasons=E2=80=
=94but this couldn=E2=80=99t be
> further from the truth.  For example, what most people within BU would lo=
ve
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators =
to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about =E2=80=9CCore vs. BU=E2=80=9D; Bitcoin=E2=80=99=
s future is one of
> =E2=80=9Cgenetic diversity=E2=80=9D with multiple implementations, so tha=
t a bug in one
> doesn=E2=80=99t threaten the network as a whole.  To me it seems this is =
largely a
> fight about whether node operators should be easily able to adjust the si=
ze
> of blocks their nodes accept.  BU makes it easy for node operators to
> accept larger blocks; Core doesn=E2=80=99t believe users should have this=
 power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal.  I am writing about what I have come
> to learn over the past several weeks.  When I first heard about these
> ideas, I was initially against them too.  They seemed harsh and merciless=
.
> It wasn=E2=80=99t until I got out their and started talking to more peopl=
e in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the =E2=80=9Cethics=E2=80=9D here depend on the lens through w=
hich one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you=E2=80=
=99d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work?  This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> One of the purported benefits of a soft-forking change (a tightening of
>> the consensus rule set) is the reduced risk of a blockchain split compar=
ed
>> to a loosening of the consensus rule set.  The way this works is that
>> miners who fail to upgrade to the new tighter ruleset will have their
>> non-compliant blocks orphaned by the hash power majority.  This is a str=
ong
>> incentive to upgrade and has historically worked well.  If a minority
>> subset of the network didn=E2=80=99t want to abide by the new restricted=
 rule set,
>> a reasonable solution would be for them to change the proof-of-work and
>> start a spin-off from the existing Bitcoin ledger (
>> https://bitcointalk.org/index.php?topic=3D563972.0).
>>
>> In the case of the coming network upgrade to larger blocks, a primary
>> concern of both business such as Coinbase and Bitpay, and most miners, i=
s
>> the possibility of a blockchain split and the associated confusion, repl=
ay
>> risk, etc.  By applying techniques that are known to be successful for
>> soft-forking changes, we can likewise benefit in a way that makes a spli=
t
>> less likely as we move towards larger blocks.  Two proposed techniques t=
o
>> reduce the chances of a split are:
>>
>> 1. That miners begin to orphan the blocks of non-upgraded miners once a
>> super-majority of the network hash power has upgraded. This would serve =
as
>> an expensive-to-ignore reminder to upgrade.
>>
>> 2. That, in the case where a minority branch emerges (unlikely IMO),
>> majority miners would continually re-org that minority branch with empty
>> blocks to prevent transactions from confirming, thereby eliminating repl=
ay
>> risk.
>>
>> Just like after a soft forking change, a minority that does not want to
>> abide by the current ruleset enforced by the majority could change the
>> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
>> suggested by Emin.
>>
>> Best regards,
>> Peter R
>>
>>
>> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> >> I don't know what "Time is running short I fear" stands for and when
>> 50%
>> >> is supposed to be reached
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
>> > "Time is running short I fear" stands for and when 50% > is supposed
>> > to be reached
>> >
>> > According to current hashrate distribution tracking site coin.dance,
>> > very likely within less than four weeks according to current hashrate
>> > takeover rate.
>> >
>> > While a fork is very likely, that I dont really fear because worst
>> > case scenario is that bitcoin still survives and the invalid chain
>> > becomes an alt.  My fear is the centralized mining power being used
>> > to attack the valid chain with intentions on killing it. [1]
>> >
>> > Shouldn't this 50% attack they are threatening be a concern? If it
>> > is a concern, what options are on the table. If it is not a concern
>> > please enlightent me as to why.
>> >
>> >
>> > [1] Source:
>> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun
>> _tells_miners_to_force_a_hard_fork_by/
>> >
>> > Text:
>> >
>> > The attack quoted from his article:
>> > https://medium.com/@peter_r/on-the-emerging-consensus-regard
>> ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>> >
>> >    [Level 2] Anti-split protection Miners will orphan the
>> >    blocks of non-compliant miners prior to the first larger block
>> >    to serve as a reminder to upgrade. Simply due to the possibility
>> >    of having blocks orphaned, all miners would be motivated to
>> >    begin signalling for larger blocks once support definitively
>> >    passes 51%. If some miners hold out (e.g., they may not be
>> >    paying attention regarding the upgrade), then they will begin
>> >    to pay attention after losing approximately $15,000 of revenue
>> >    due to an orphaned block.
>> >
>> >    [Level 3] Anti-split protection In the scenario where Levels
>> >    1 and 2 protection fails to entice all non-compliant miners to
>> >    upgrade, a small-block minority chain may emerge. To address the
>> >    risk of coins being spent on this chain (replay risk), majority
>> >    miners will deploy hash power as needed to ensure the minority
>> >    chain includes only empty blocks after the forking point. This
>> >    can easily be accomplished if the majority miners maintain a
>> >    secret chain of empty blocks built off their last empty
>> >    block publishing only as much of this chain as necessary
>> >    to orphan any non-empty blocks produced on the minority chain.
>> >
>> >
>> >
>> >
>> > - --
>> > Cannon
>> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> > Email: cannon@cannon-ciota.info
>> >
>> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> > If this matters to you, use PGP.
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
>> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
>> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
>> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
>> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
>> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
>> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
>> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
>> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
>> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
>> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
>> > /T93MuZgmvSCry5MlccA
>> > =3DR71g
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c0d9348df67a8054ba7f634
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As a user, I would far prefer a split over any kind of man=
datory change that would drastically harm the ecosystem.=C2=A0 Many users f=
eel the same way.=C2=A0 Level 3 is a pure attack on users who do not confor=
m to your beliefs.=C2=A0 Please do not put words in people&#39;s mouths cla=
iming they wouldn&#39;t prefer a split when many would.=C2=A0 If you wish t=
o fork off, please do so responsibly.<div><br></div><div>-Alphonse</div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Mar 26=
, 2017 at 2:05 PM, Peter R via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div style=3D"word-wrap:break-word">Hello Alex,<div><br></div><div=
>Thank you for the thoughtful reply. =C2=A0</div><div><br><div><span class=
=3D""><blockquote type=3D"cite"><div><div dir=3D"ltr">Surely you are aware =
that what you are proposing is vastly different from the way soft forks hav=
e historically worked.=C2=A0</div></div></blockquote><div><br></div></span>=
<div>Yes, it is different.=C2=A0 It=E2=80=99s different because the future =
network upgrade to larger blocks includes a loosening of the consensus rule=
set whereas previous upgrades have included a tightening of the rule set. =
=C2=A0(BTW=E2=80=94this is not my proposal, I am describing what I have rec=
ently learned through my work with Bitcoin Unlimited and discussions with m=
iners and businesses). =C2=A0</div><div><br></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. =C2=A0</div><div><br=
></div><div>With a loosening of the consensus rule set, the situation is di=
fferent: a hash power minority that has not upgraded will produce a minorit=
y branch, that will also drag along non-upgraded node operators, leading to=
 potential confusion.=C2=A0 The idea behind orphaning the blocks of non-upg=
raded miners was to serve as a wake-up call to upgrade, to reduce the chanc=
es of a minority chain emerging in the first place, similar to what happens=
 automatically with a soft-forking change.=C2=A0 If one&#39;s worry is a ch=
ain split, then this seems like a reasonable way to reduce the chances of t=
hat worry materializing.=C2=A0 The Level 3 anti-split protection takes this=
 idea one step further to ensure that if a minority branch does emerge, tha=
t transactions cannot be confirmed on that branch.</div><span class=3D""><b=
r><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>First of all, the ba=
r for miners being on the new chain is extremely high, 95%.</div></div></di=
v></blockquote><div><br></div></span><div>I=E2=80=99m very confident that m=
ost people do NOT want a split, especially the miners.=C2=A0 The upgrade to=
 larger blocks will not happen until miners are confident that no minority =
chain will survive. =C2=A0</div><span class=3D""><br><blockquote type=3D"ci=
te"><div><div dir=3D"ltr"><div>Second of all, soft forks make rule restrict=
ions on classes of transactions that are already non-standard so that any n=
on-upgraded miners are unlikely to be including txs in their blocks which w=
ould violate the new rules and should not have their blocks orphaned even a=
fter the fork.</div></div></div></blockquote><div><br></div></span><div>I a=
gree that the soft-fork mechanism usually works well.=C2=A0 I believe this =
mechanism (or perhaps a modified version of it) to increase the block size =
limit will likewise work well.=C2=A0 All transactions types that are curren=
tly valid will be valid after the upgrade, and no new types of transactions=
 are being created.=C2=A0 The =E2=80=9Cblock-size-limit gene&quot; of netwo=
rk nodes is simply evolving to allow the network to continue to grow in the=
 way it has always grown. (If you=E2=80=99re interested, here is my talk at=
 Coinbase where I discuss this:=C2=A0<a href=3D"https://www.youtube.com/wat=
ch?v=3DpWnFDocAmfg" target=3D"_blank">https://www.youtube.com/<wbr>watch?v=
=3DpWnFDocAmfg</a>)</div><span class=3D""><br><blockquote type=3D"cite"><di=
v><div dir=3D"ltr"><div>Finally, soft forks are designed to only be used wh=
en there is a very wide community consensus and the intention is not to ove=
rrule anyone&#39;s choice to remain on the old rules but to ensure the secu=
rity of nodes that may have neglected to upgrade.=C2=A0 Obviously it is imp=
ossible to draw a bright line between users who intentionally are not upgra=
ding due to opposition and users that are just being lazy.=C2=A0 But in the=
 case of a proposed BU hard fork it is abundantly clear that there is a ver=
y significant fraction, in fact likely a majority of users who intentionall=
y want to remain on the old rules.</div></div></div></blockquote><div><br><=
/div></span><div>My read is completely different.=C2=A0 I still have never =
talked with a person in real life who doesn=E2=80=99t want the block size l=
imit to increase.=C2=A0 Indeed, I have met people who worry that Bitcoin Un=
limited is =E2=80=9Ctrying to take over=E2=80=9D=E2=80=94and thus they are =
worried for other reasons=E2=80=94but this couldn=E2=80=99t be further from=
 the truth.=C2=A0 For example, what most people within BU would love to see=
 is a simple patch to Bitcoin Core 0.14 that allows node operators to adjus=
t the size of blocks their nodes will accept, so that these node operators =
can follow consensus through the upgrade if they choose to. =C2=A0</div><di=
v><br></div><div>This is not a fight about =E2=80=9CCore vs. BU=E2=80=9D; B=
itcoin=E2=80=99s future is one of =E2=80=9Cgenetic diversity=E2=80=9D with =
multiple implementations, so that a bug in one doesn=E2=80=99t threaten the=
 network as a whole.=C2=A0 To me it seems this is largely a fight about whe=
ther node operators should be easily able to adjust the size of blocks thei=
r nodes accept.=C2=A0 BU makes it easy for node operators to accept larger =
blocks; Core doesn=E2=80=99t believe users should have this power (outside =
of recompiling from source, which few users can do). =C2=A0</div><span clas=
s=3D""><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>As a Bitcoi=
n user I find it abhorrent the way you are proposing to intentionally cripp=
le the chain and rules I want to use instead of just peacefully splitting.<=
/div></div></div></blockquote><div><br></div></span>Once again, this is not=
 my proposal.=C2=A0 I am writing about what I have come to learn over the p=
ast several weeks.=C2=A0 When I first heard about these ideas, I was initia=
lly against them too.=C2=A0 They seemed harsh and merciless.=C2=A0 It wasn=
=E2=80=99t until I got out their and started talking to more people in the =
community that the rationale started to make sense to me: the biggest conce=
rn people had was a chain split!</div><div><br></div><div>So I guess the =
=E2=80=9Cethics=E2=80=9D here depend on the lens through which one is looki=
ng. People who believe that an important outcome of the upgrade to larger b=
locks is to avoid a blockchain split may be more favourable to these ideas =
than people who want the upgrade to result in a split (or are OK with a spl=
it), as it sounds like you do (is this true that you=E2=80=99d rather split=
 than accept blocks with more than 1,000,000 bytes of transaction informati=
on in them? Sorry if I misunderstood). =C2=A0</div><div><br></div><div>But =
if one&#39;s intention is to split and not follow the majority hash power w=
hen blocks become larger, then why not change the proof-of-work?=C2=A0 This=
 would certainly result in a peaceful splitting, as you said you desire. =
=C2=A0</div><div><div class=3D"h5"><div><br></div><div>Best regards,</div><=
div>Peter R<br><div><br></div><div><br></div><br><blockquote type=3D"cite">=
<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Mar =
25, 2017 at 3:28 PM, Peter R via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">One of the purported benefits of a soft-forking change (a =
tightening of the consensus rule set) is the reduced risk of a blockchain s=
plit compared to a loosening of the consensus rule set.=C2=A0 The way this =
works is that miners who fail to upgrade to the new tighter ruleset will ha=
ve their non-compliant blocks orphaned by the hash power majority.=C2=A0 Th=
is is a strong incentive to upgrade and has historically worked well.=C2=A0=
 If a minority subset of the network didn=E2=80=99t want to abide by the ne=
w restricted rule set, a reasonable solution would be for them to change th=
e proof-of-work and start a spin-off from the existing Bitcoin ledger (<a h=
ref=3D"https://bitcointalk.org/index.php?topic=3D563972.0" rel=3D"noreferre=
r" target=3D"_blank">https://bitcointalk.org/index<wbr>.php?topic=3D563972.=
0</a>).<br>
<br>
In the case of the coming network upgrade to larger blocks, a primary conce=
rn of both business such as Coinbase and Bitpay, and most miners, is the po=
ssibility of a blockchain split and the associated confusion, replay risk, =
etc.=C2=A0 By applying techniques that are known to be successful for soft-=
forking changes, we can likewise benefit in a way that makes a split less l=
ikely as we move towards larger blocks.=C2=A0 Two proposed techniques to re=
duce the chances of a split are:<br>
<br>
1. That miners begin to orphan the blocks of non-upgraded miners once a sup=
er-majority of the network hash power has upgraded. This would serve as an =
expensive-to-ignore reminder to upgrade.<br>
<br>
2. That, in the case where a minority branch emerges (unlikely IMO), majori=
ty miners would continually re-org that minority branch with empty blocks t=
o prevent transactions from confirming, thereby eliminating replay risk.<br=
>
<br>
Just like after a soft forking change, a minority that does not want to abi=
de by the current ruleset enforced by the majority could change the proof-o=
f-work and start a spin-off from the existing Bitcoin ledger, as suggested =
by Emin.<br>
<br>
Best regards,<br>
Peter R<br>
<div class=3D"m_-102974887459783682HOEnZb"><div class=3D"m_-102974887459783=
682h5"><br>
<br>
&gt; On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote:<br>
&gt;&gt; I don&#39;t know what &quot;Time is running short I fear&quot; sta=
nds for and when 50%<br>
&gt;&gt; is supposed to be reached<br>
&gt;<br>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA512<br>
&gt;<br>
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote: &gt; I don&#39;t know wha=
t<br>
&gt; &quot;Time is running short I fear&quot; stands for and when 50% &gt; =
is supposed<br>
&gt; to be reached<br>
&gt;<br>
&gt; According to current hashrate distribution tracking site coin.dance,<b=
r>
&gt; very likely within less than four weeks according to current hashrate<=
br>
&gt; takeover rate.<br>
&gt;<br>
&gt; While a fork is very likely, that I dont really fear because worst<br>
&gt; case scenario is that bitcoin still survives and the invalid chain<br>
&gt; becomes an alt.=C2=A0 My fear is the centralized mining power being us=
ed<br>
&gt; to attack the valid chain with intentions on killing it. [1]<br>
&gt;<br>
&gt; Shouldn&#39;t this 50% attack they are threatening be a concern? If it=
<br>
&gt; is a concern, what options are on the table. If it is not a concern<br=
>
&gt; please enlightent me as to why.<br>
&gt;<br>
&gt;<br>
&gt; [1] Source:<br>
&gt; <a href=3D"https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizu=
n_tells_miners_to_force_a_hard_fork_by/" rel=3D"noreferrer" target=3D"_blan=
k">https://www.reddit.com/r/Bitco<wbr>in/comments/6172s3/peter_rizun<wbr>_t=
ells_miners_to_force_a_hard_<wbr>fork_by/</a><br>
&gt;<br>
&gt; Text:<br>
&gt;<br>
&gt; The attack quoted from his article:<br>
&gt; <a href=3D"https://medium.com/@peter_r/on-the-emerging-consensus-regar=
ding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8" re=
l=3D"noreferrer" target=3D"_blank">https://medium.com/@peter_r/on<wbr>-the-=
emerging-consensus-regard<wbr>ing-bitcoins-block-size-limit-<wbr>insights-f=
rom-my-visit-with-<wbr>2348878a16d8</a><br>
&gt;<br>
&gt;=C2=A0 =C2=A0 [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners w=
ill orphan the<br>
&gt;=C2=A0 =C2=A0 blocks of non-compliant miners prior to the first larger =
block<br>
&gt;=C2=A0 =C2=A0 to serve as a reminder to upgrade. Simply due to the poss=
ibility<br>
&gt;=C2=A0 =C2=A0 of having blocks orphaned, all miners would be motivated =
to<br>
&gt;=C2=A0 =C2=A0 begin signalling for larger blocks once support definitiv=
ely<br>
&gt;=C2=A0 =C2=A0 passes 51%. If some miners hold out (e.g., they may not b=
e<br>
&gt;=C2=A0 =C2=A0 paying attention regarding the upgrade), then they will b=
egin<br>
&gt;=C2=A0 =C2=A0 to pay attention after losing approximately $15,000 of re=
venue<br>
&gt;=C2=A0 =C2=A0 due to an orphaned block.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn the s=
cenario where Levels<br>
&gt;=C2=A0 =C2=A0 1 and 2 protection fails to entice all non-compliant mine=
rs to<br>
&gt;=C2=A0 =C2=A0 upgrade, a small-block minority chain may emerge. To addr=
ess the<br>
&gt;=C2=A0 =C2=A0 risk of coins being spent on this chain (replay risk), ma=
jority<br>
&gt;=C2=A0 =C2=A0 miners will deploy hash power as needed to ensure the min=
ority<br>
&gt;=C2=A0 =C2=A0 chain includes only empty blocks after the forking point.=
 This<br>
&gt;=C2=A0 =C2=A0 can easily be accomplished if the majority miners maintai=
n a<br>
&gt;=C2=A0 =C2=A0 secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt off t=
heir last empty<br>
&gt;=C2=A0 =C2=A0 block=E2=80=8A=E2=80=8Apublishing only as much of this ch=
ain as necessary<br>
&gt;=C2=A0 =C2=A0 to orphan any non-empty blocks produced on the minority c=
hain.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - --<br>
&gt; Cannon<br>
&gt; PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br>
&gt; Email: <a href=3D"mailto:cannon@cannon-ciota.info" target=3D"_blank">c=
annon@cannon-ciota.info</a><br>
&gt;<br>
&gt; NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<=
br>
&gt; BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br>
&gt; If this matters to you, use PGP.<br>
&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt;<br>
&gt; iQIcBAEBCgAGBQJY1pbaAAoJEAYDai<wbr>9lH2mwOO0QANOWqGzPNlifWguc+Y5U<wbr>=
QxQM<br>
&gt; eAiztAayQBoAyLcFE7/qdtSNlUxbIA<wbr>HG17fM+aNkehjYH2oN5ODJ+<wbr>j7E2Yt6=
EoUH<br>
&gt; h5t8MLhNRG/YGF1hJK8Io940Emdcju<wbr>NmohiZvrjIqEOYggmLU3hR6J4gsuGs<wbr>=
QQhu<br>
&gt; gY3sMS/TtT+gZNH8w53ePGrsVhuQR7<wbr>yEMMr91/vM4+<wbr>Q5abpwqLeYLnslaZDc=
d3XK<br>
&gt; VB9vyyK08r34J1GQt/H4UvTvGs28MF<wbr>KBkvueA/Sfyvnrih7+WSQLuSvhiFr+<wbr>=
cW1B<br>
&gt; TmSVYrB2DzyHN27jDCI2ty3ryNE4PM<wbr>YcaeLfI2TTbsD/MuVU5lK0kM/1JajP<wbr>=
4eRj<br>
&gt; j+P03OipuQiy/dNU63w0Uka2PbdKhD<wbr>C13hVtK/ttBbNppbjnGeB9PYSJCzOp<wbr>=
InGw<br>
&gt; NwAyz0rVS/llGsdctcII7Z6AUMGuJX<wbr>zsosY8vjUroU+<wbr>KFRDqIbDfC53sH7Da=
Ph7u<br>
&gt; YawwId5S5RnZsAGCUJ+qNcg0s728J1<wbr>eDjofN291IS5sOKMzpI7KhaOhFxjnk<wbr>=
1MpN<br>
&gt; ZAlQeTlvG+sAdn61QMQK1NbFt0km+j<wbr>cqyVh0+L01yB0K4VDi1YFJaSBOaYUE<wbr>=
LBXa<br>
&gt; 8a6WhZf5nrl5UIpH7rRcPzzqchcdYc<wbr>zy5VRZp2UsU+HYeqLXlcN0a03yPpVQ<wbr>=
ik9S<br>
&gt; /T93MuZgmvSCry5MlccA<br>
&gt; =3DR71g<br>
&gt; -----END PGP SIGNATURE-----<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></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>

--94eb2c0d9348df67a8054ba7f634--