path: root/52/113f3d6a02a2dc79b0ca4b34d90fdec47cd2c7

Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B766941C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 Mar 2017 19:05:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27FCF2A5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 26 Mar 2017 19:05:47 +0000 (UTC)
Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx003
	[212.227.17.184]) with ESMTPSA (Nemesis) id 0MYg42-1cfeit422E-00VQBc;
	Sun, 26 Mar 2017 21:05:42 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE"
From: Peter R <peter_r@gmx.com>
In-Reply-To: <CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com>
Date: Sun, 26 Mar 2017 12:05:38 -0700
Message-Id: <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>
To: Alex Morcos <morcos@gmail.com>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:q+1Zl1/R+ZBgXnGHxaheqex3lZpNK0iOhVBHwrGSR+onT/85j9u
	VDloCl5QWmFE2sryN9DPLKgZJwf70HHijKn5eulXmx+vJrhtBC2cA/Z9vEBE2J38W8iGR4n
	FmICsO3GsSEhGuG7Ck99w+v3EwvWoT2wRiCwp7hA22KtwCVdFend8bZ0NklUtvGzPtvcxga
	FjqPTZLXlhv6CpZUeefqw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:/SIuuA1SBh8=:B0+YJ/OdO+AcfEyFqf1Udw
	qC6WBYWFbF0mMn0L5Nuk3L/wCKM4iEc3dByPAbM1Z/cgYoZy+7Dj0IkNfOOic5iKAVfzJXt0q
	nCmKRy94sPpMZ9W0ZreCqC1zxHsiVYh3gjCek0ARZpvFrmqi3+W7rgEqLHgcznUsZ/m+cUnN5
	SA92232U2rHkT+T4BQh1rTQo3BxsRDLSxfOG1pX4HwI0a/yd+k6bqWZ70FxwwHXCHWE4YQSgM
	gZ9kGOR3jgQOo88wjFNT4nASFNOJ9kcliyjvhOEzhgWi6wa/2t33Z6LI1Wq8iieGIct+cjHfJ
	9HUhuVQTigo5fbfBzi+liXqlasd+WS6+M1yARDvMCMocVmJhuj2zwmiCRL47Zh4EoLxxL+uW/
	0QSMDJZQfSG4mcgD4kAzIjHLaSY6OPCckGUkuY0toXUvIFMWGXRjGqlkxqfv8na8x5TIOpAPe
	m3q0w0KIP0/JbYa0wGYfIcrx6VsAVghrebagL+leLTewFWAZzLqFinq689Vt1BVGFfQaupx9X
	G1IStQaczQz86tWGnf0r6aifI1ItYFyGaJWBpdILORX3yWYpER5EbaGTHSWmoFP8ttqvC1zjs
	rDswrDyT0YiMpXU16a3hJi+pheQmG0gWEsXGZdmCqIGMp3B4zD49Rcy+cVLndb72ptSmaZ2BV
	oHz4sXrzoHKBTfDTtsK1KQTGVlFcH/LmVrE7lC7jT7HBLE7jTe4gTVJd6VXtp/DtFtY/EJHBo
	4LsH+DWe1GGO4gyYfISgvOcXHH7/5Var5d4KXeRkV58xtCMQXIIo0WABY7HWJWzmCnMEl0GYB
	iznU6ek
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,LOTS_OF_MONEY,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,
	T_MONEY_PERCENT 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:16:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 19:05:50 -0000


--Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Alex,

Thank you for the thoughtful reply. =20

> Surely you are aware that what you are proposing is vastly different =
from the way soft forks have historically worked.=20

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). =20

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. =20

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 potential confusion.  The idea behind orphaning the blocks of =
non-upgraded miners was to serve as a wake-up call to upgrade, to reduce =
the chances of a minority 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 step further to ensure that if a minority branch =
does emerge, that transactions 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, =
especially the miners.  The upgrade to larger blocks will not happen =
until miners are confident that no minority chain will survive. =20

> Second of all, soft forks make rule restrictions on classes of =
transactions that are already non-standard so that any non-upgraded =
miners 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 =
size limit will likewise work well.  All transactions types that are =
currently valid will be valid after the upgrade, and no new types of =
transactions are being created.  The =E2=80=9Cblock-size-limit gene" of =
network 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: =
https://www.youtube.com/watch?v=3DpWnFDocAmfg =
<https://www.youtube.com/watch?v=3DpWnFDocAmfg>)

> Finally, soft forks are designed to only be used when there is a very =
wide 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 fork 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 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.  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 adjust =
the size of blocks their nodes will accept, so that these node operators =
can follow consensus through the upgrade if they choose to. =20

This is not a fight about =E2=80=9CCore vs. BU=E2=80=9D; Bitcoin=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.  To me it seems this is largely a fight about =
whether node operators should be easily able to adjust the size 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). =
=20

> 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 people 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 =
which 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). =20

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. =20

Best regards,
Peter R



>=20
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto: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 =
compared 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 strong 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 =
<https://bitcointalk.org/index.php?topic=3D563972.0>).
>=20
> 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, =
is the possibility of a blockchain split and the associated confusion, =
replay 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 split less likely as we move towards larger blocks.  Two =
proposed techniques to reduce the chances of a split are:
>=20
> 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.
>=20
> 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 =
replay risk.
>=20
> 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.
>=20
> Best regards,
> Peter R
>=20
>=20
> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto: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/ =
<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-regarding-bitcoins-b=
lock-size-limit-insights-from-my-visit-with-2348878a16d8 =
<https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-=
block-size-limit-insights-from-my-visit-with-2348878a16d8>
> >
> >    [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners 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=E2=80=8A=E2=80=8AIn 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=E2=80=8A=E2=80=8Abuilt off their =
last empty
> >    block=E2=80=8A=E2=80=8Apublishing 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 <mailto: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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20


--Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hello Alex,<div class=3D""><br class=3D""></div><div =
class=3D"">Thank you for the thoughtful reply. &nbsp;</div><div =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D"">Surely you are aware that what =
you are proposing is vastly different from the way soft forks have =
historically worked.&nbsp;</div></div></blockquote><div><br =
class=3D""></div><div>Yes, it is different. &nbsp;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. &nbsp;(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). =
&nbsp;</div><div><br class=3D""></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 =
produce orphaned, serving as a wake-up call to upgrade. =
&nbsp;</div><div><br class=3D""></div><div>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 potential confusion. =
&nbsp;The idea behind orphaning the blocks of non-upgraded miners was to =
serve as a wake-up call to upgrade, to reduce the chances of a minority =
chain emerging in the first place, similar to what happens automatically =
with a soft-forking change. &nbsp;If one's worry is a chain split, then =
this seems like a reasonable way to reduce the chances of that worry =
materializing. &nbsp;The Level 3 anti-split protection takes this idea =
one step further to ensure that if a minority branch does emerge, that =
transactions cannot be confirmed on that branch.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"">First of all, the bar for miners =
being on the new chain is extremely high, =
95%.</div></div></div></blockquote><div><br class=3D""></div><div>I=E2=80=99=
m very confident that most people do NOT want a split, especially the =
miners. &nbsp;The upgrade to larger blocks will not happen until miners =
are confident that no minority chain will survive. &nbsp;</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"">Second of all, soft forks make =
rule restrictions on classes of transactions that are already =
non-standard so that any non-upgraded miners 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.</div></div></div></blockquote><div><br class=3D""></div><div>I =
agree that the soft-fork mechanism usually works well. &nbsp;I believe =
this mechanism (or perhaps a modified version of it) to increase the =
block size limit will likewise work well. &nbsp;All transactions types =
that are currently valid will be valid after the upgrade, and no new =
types of transactions are being created. &nbsp;The =E2=80=9Cblock-size-lim=
it gene" of network 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:&nbsp;<a =
href=3D"https://www.youtube.com/watch?v=3DpWnFDocAmfg" =
class=3D"">https://www.youtube.com/watch?v=3DpWnFDocAmfg</a>)</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"">Finally, soft forks are designed =
to only be used when there is a very wide 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.&nbsp; 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.&nbsp; But in the case of a proposed BU hard =
fork 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.</div></div></div></blockquote><div><br =
class=3D""></div><div>My read is completely different. &nbsp;I still =
have never talked with a person in real life who doesn=E2=80=99t want =
the block size limit to increase. &nbsp;Indeed, I have met people who =
worry that Bitcoin Unlimited 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. &nbsp;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 adjust the size of blocks their nodes =
will accept, so that these node operators can follow consensus through =
the upgrade if they choose to. &nbsp;</div><div><br =
class=3D""></div><div>This is not a fight about =E2=80=9CCore vs. BU=E2=80=
=9D; Bitcoin=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. &nbsp;To me it seems this is largely a =
fight about whether node operators should be easily able to adjust the =
size of blocks their nodes accept. &nbsp;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). &nbsp;</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">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.</div></div></div></blockquote><div><br =
class=3D""></div>Once again, this is not my proposal. &nbsp;I am writing =
about what I have come to learn over the past several weeks. &nbsp;When =
I first heard about these ideas, I was initially against them too. =
&nbsp;They seemed harsh and merciless. &nbsp;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 concern people =
had was a chain split!</div><div><br class=3D""></div><div>So I guess =
the =E2=80=9Cethics=E2=80=9D here depend on the lens through which 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). =
&nbsp;</div><div><br class=3D""></div><div>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? &nbsp;This would certainly result =
in a peaceful splitting, as you said you desire. &nbsp;</div><div><br =
class=3D""></div><div>Best regards,</div><div>Peter R<br =
class=3D""><div><br class=3D""></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">On Sat, =
Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <span dir=3D"ltr" =
class=3D"">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-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 split compared =
to a loosening of the consensus rule set.&nbsp; 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.&nbsp; =
This is a strong incentive to upgrade and has historically worked =
well.&nbsp; 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 (<a =
href=3D"https://bitcointalk.org/index.php?topic=3D563972.0" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://bitcointalk.org/<wbr =
class=3D"">index.php?topic=3D563972.0</a>).<br class=3D"">
<br class=3D"">
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, =
is the possibility of a blockchain split and the associated confusion, =
replay risk, etc.&nbsp; 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 likely as we move towards larger blocks.&nbsp; =
Two proposed techniques to reduce the chances of a split are:<br =
class=3D"">
<br class=3D"">
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.<br class=3D"">
<br class=3D"">
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 =
replay risk.<br class=3D"">
<br class=3D"">
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.<br class=3D"">
<br class=3D"">
Best regards,<br class=3D"">
Peter R<br class=3D"">
<div class=3D"HOEnZb"><div class=3D"h5"><br class=3D"">
<br class=3D"">
&gt; On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>&gt; =
wrote:<br class=3D"">
&gt;<br class=3D"">
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote:<br class=3D"">
&gt;&gt; I don't know what "Time is running short I fear" stands for and =
when 50%<br class=3D"">
&gt;&gt; is supposed to be reached<br class=3D"">
&gt;<br class=3D"">
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br class=3D"">
&gt; Hash: SHA512<br class=3D"">
&gt;<br class=3D"">
&gt; On 03/24/2017 07:00 PM, Aymeric Vitte wrote: &gt; I don't know =
what<br class=3D"">
&gt; "Time is running short I fear" stands for and when 50% &gt; is =
supposed<br class=3D"">
&gt; to be reached<br class=3D"">
&gt;<br class=3D"">
&gt; According to current hashrate distribution tracking site =
coin.dance,<br class=3D"">
&gt; very likely within less than four weeks according to current =
hashrate<br class=3D"">
&gt; takeover rate.<br class=3D"">
&gt;<br class=3D"">
&gt; While a fork is very likely, that I dont really fear because =
worst<br class=3D"">
&gt; case scenario is that bitcoin still survives and the invalid =
chain<br class=3D"">
&gt; becomes an alt.&nbsp; My fear is the centralized mining power being =
used<br class=3D"">
&gt; to attack the valid chain with intentions on killing it. [1]<br =
class=3D"">
&gt;<br class=3D"">
&gt; Shouldn't this 50% attack they are threatening be a concern? If =
it<br class=3D"">
&gt; is a concern, what options are on the table. If it is not a =
concern<br class=3D"">
&gt; please enlightent me as to why.<br class=3D"">
&gt;<br class=3D"">
&gt;<br class=3D"">
&gt; [1] Source:<br class=3D"">
&gt; <a =
href=3D"https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells=
_miners_to_force_a_hard_fork_by/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://www.reddit.com/r/<wbr =
class=3D"">Bitcoin/comments/6172s3/peter_<wbr =
class=3D"">rizun_tells_miners_to_force_a_<wbr =
class=3D"">hard_fork_by/</a><br class=3D"">
&gt;<br class=3D"">
&gt; Text:<br class=3D"">
&gt;<br class=3D"">
&gt; The attack quoted from his article:<br class=3D"">
&gt; <a =
href=3D"https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bi=
tcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://medium.com/@peter_r/<wbr =
class=3D"">on-the-emerging-consensus-<wbr =
class=3D"">regarding-bitcoins-block-size-<wbr =
class=3D"">limit-insights-from-my-visit-<wbr =
class=3D"">with-2348878a16d8</a><br class=3D"">
&gt;<br class=3D"">
&gt;&nbsp; &nbsp; [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners =
will orphan the<br class=3D"">
&gt;&nbsp; &nbsp; blocks of non-compliant miners prior to the first =
larger block<br class=3D"">
&gt;&nbsp; &nbsp; to serve as a reminder to upgrade. Simply due to the =
possibility<br class=3D"">
&gt;&nbsp; &nbsp; of having blocks orphaned, all miners would be =
motivated to<br class=3D"">
&gt;&nbsp; &nbsp; begin signalling for larger blocks once support =
definitively<br class=3D"">
&gt;&nbsp; &nbsp; passes 51%. If some miners hold out (e.g., they may =
not be<br class=3D"">
&gt;&nbsp; &nbsp; paying attention regarding the upgrade), then they =
will begin<br class=3D"">
&gt;&nbsp; &nbsp; to pay attention after losing approximately $15,000 of =
revenue<br class=3D"">
&gt;&nbsp; &nbsp; due to an orphaned block.<br class=3D"">
&gt;<br class=3D"">
&gt;&nbsp; &nbsp; [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn =
the scenario where Levels<br class=3D"">
&gt;&nbsp; &nbsp; 1 and 2 protection fails to entice all non-compliant =
miners to<br class=3D"">
&gt;&nbsp; &nbsp; upgrade, a small-block minority chain may emerge. To =
address the<br class=3D"">
&gt;&nbsp; &nbsp; risk of coins being spent on this chain (replay risk), =
majority<br class=3D"">
&gt;&nbsp; &nbsp; miners will deploy hash power as needed to ensure the =
minority<br class=3D"">
&gt;&nbsp; &nbsp; chain includes only empty blocks after the forking =
point. This<br class=3D"">
&gt;&nbsp; &nbsp; can easily be accomplished if the majority miners =
maintain a<br class=3D"">
&gt;&nbsp; &nbsp; secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt =
off their last empty<br class=3D"">
&gt;&nbsp; &nbsp; block=E2=80=8A=E2=80=8Apublishing only as much of this =
chain as necessary<br class=3D"">
&gt;&nbsp; &nbsp; to orphan any non-empty blocks produced on the =
minority chain.<br class=3D"">
&gt;<br class=3D"">
&gt;<br class=3D"">
&gt;<br class=3D"">
&gt;<br class=3D"">
&gt; - --<br class=3D"">
&gt; Cannon<br class=3D"">
&gt; PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 =
E832<br class=3D"">
&gt; Email: <a href=3D"mailto:cannon@cannon-ciota.info" =
class=3D"">cannon@cannon-ciota.info</a><br class=3D"">
&gt;<br class=3D"">
&gt; NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP =
SHOULD<br class=3D"">
&gt; BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br class=3D"">
&gt; If this matters to you, use PGP.<br class=3D"">
&gt; -----BEGIN PGP SIGNATURE-----<br class=3D"">
&gt;<br class=3D"">
&gt; iQIcBAEBCgAGBQJY1pbaAAoJEAYDai<wbr =
class=3D"">9lH2mwOO0QANOWqGzPNlifWguc+<wbr class=3D"">Y5UQxQM<br =
class=3D"">
&gt; eAiztAayQBoAyLcFE7/<wbr class=3D"">qdtSNlUxbIAHG17fM+<wbr =
class=3D"">aNkehjYH2oN5ODJ+j7E2Yt6EoUH<br class=3D"">
&gt; h5t8MLhNRG/<wbr class=3D"">YGF1hJK8Io940EmdcjuNmohiZvrjIq<wbr =
class=3D"">EOYggmLU3hR6J4gsuGsQQhu<br class=3D"">
&gt; gY3sMS/TtT+<wbr class=3D"">gZNH8w53ePGrsVhuQR7yEMMr91/<wbr =
class=3D"">vM4+Q5abpwqLeYLnslaZDcd3XK<br class=3D"">
&gt; VB9vyyK08r34J1GQt/<wbr class=3D"">H4UvTvGs28MFKBkvueA/Sfyvnrih7+<wbr =
class=3D"">WSQLuSvhiFr+cW1B<br class=3D"">
&gt; TmSVYrB2DzyHN27jDCI2ty3ryNE4PM<wbr =
class=3D"">YcaeLfI2TTbsD/MuVU5lK0kM/<wbr class=3D"">1JajP4eRj<br =
class=3D"">
&gt; j+P03OipuQiy/<wbr class=3D"">dNU63w0Uka2PbdKhDC13hVtK/<wbr =
class=3D"">ttBbNppbjnGeB9PYSJCzOpInGw<br class=3D"">
&gt; NwAyz0rVS/<wbr class=3D"">llGsdctcII7Z6AUMGuJXzsosY8vjUr<wbr =
class=3D"">oU+KFRDqIbDfC53sH7DaPh7u<br class=3D"">
&gt; YawwId5S5RnZsAGCUJ+<wbr class=3D"">qNcg0s728J1eDjofN291IS5sOKMzpI<wbr=
 class=3D"">7KhaOhFxjnk1MpN<br class=3D"">
&gt; ZAlQeTlvG+sAdn61QMQK1NbFt0km+<wbr class=3D"">jcqyVh0+<wbr =
class=3D"">L01yB0K4VDi1YFJaSBOaYUELBXa<br class=3D"">
&gt; 8a6WhZf5nrl5UIpH7rRcPzzqchcdYc<wbr class=3D"">zy5VRZp2UsU+<wbr =
class=3D"">HYeqLXlcN0a03yPpVQik9S<br class=3D"">
&gt; /T93MuZgmvSCry5MlccA<br class=3D"">
&gt; =3DR71g<br class=3D"">
&gt; -----END PGP SIGNATURE-----<br class=3D"">
&gt;<br class=3D"">
&gt; ______________________________<wbr class=3D"">_________________<br =
class=3D"">
&gt; bitcoin-dev mailing list<br class=3D"">
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
&gt; <a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br =
class=3D"">
<br class=3D"">
______________________________<wbr class=3D"">_________________<br =
class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br =
class=3D"">
</div></div></blockquote></div><br class=3D""></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE--