To: Peter R <peter_r@gmx.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Alex Morcos <morcos@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>
From: Eric Voskuil <eric@voskuil.org>
Message-ID: <b7ff549b-5ee8-172d-5a23-47ef8943533e@voskuil.org>
Date: Sun, 26 Mar 2017 15:15:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
Precedence: list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:

Peter,

> Yes, it is different.  It’s 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—this is not my proposal, I am describing what I
> have recently learned through my work with Bitcoin Unlimited and
> discussions with miners and businesses).

The repeated use of the term "network upgrade" in place of the
accepted technical term (hard fork) is misleading. This and the
presupposition that the hard fork is coming, and the claims that it's
not your proposal, make me feel like I'm shopping for a used car...
It's not used it's pre-owned, everyone's getting the warranty, let me
see what my manager has to say about the price - it's not my decision.

This is a development list. Avoidance of standardized terminology and
use of the presumptive close diminishes your message.

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

"tightening of the rule set" == soft fork

This implies that the minority hash power is producing blocks that are
valid according to rules in existence prior to the soft fork. You are
referring to these as invalid, but because this has already confused
one commentator, let's be clear. The blocks you are referring to are
valid blocks being orphaned because the majority hash power is
rejecting them because of soft fork activation. This of course
produces a minority chain, so this statement is incorrect.

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

"loosening of the consensus rule set" == hard fork

This is also incorrect. In the case of a hard fork old nodes reject
the new blocks that are invalid according to old rules and continue to
accept other old blocks. This produces a second distinct chain. It is
neither a majority nor a minority chain with respect to the original.
It is simply a new coin that happens to share history with the old
coin. This doesn't imply confusion, since both chains continue to
operate under the rules of their nodes. The only confusion arises from
people wanting to transaction across *both* chains. It is only in this
context that replay becomes an issue.

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

Stopping people from transacting on the old chain due to an ongoing
51% attack (again, using proper terminology) is one way to make it
hard for people to transact on both chains. But if you don't care that
people are able to transact on both chains, there's no reason to spend
the money on the attack.

So let me point to the elephant in the room. The proposed 51% attack
is more obviously an attempt to transfer economic activity from BTC to
BTU, not a benevolent measure to prevent confusion. It can clearly be
viewed as elimination of competition through an electronic attack on
BTC operations. Given that they are all regulated entities, I'm not
sure how the envisioned large miner collaborators (or others who might
fund it) will feel about participation in the scheme.

> This is not a fight about “Core vs. BU”; Bitcoin’s future is one
> of “genetic diversity” with multiple implementations, so that a bug
> in one doesn’t threaten the network as a whole

You are right that this is not about Core and BU. These are
implementations, not protocols. However, please do not presume that
other implementations are enlisted in your scheme, or that this is
about making the network more bug-resistant.

> 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’t believe users should have this power (outside
> of recompiling from source, which few users can do).

I feel like making the block size a configuration option in Libbitcoin
just to emphasize the gross error of this idea. It has never been
about the inability of users to compile the code. It's about the
purposeful difficulty in changing the rules when everyone has a say.

> 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’t until I got out their and started
> talking...

The idea was so powerful you were converted (another sales tactic).
Who's proposal is this? Can they not speak for themselves?

> So I guess the “ethics” here depend on the lens through which one
> is looking...

These are not ethical questions. These are development questions,
built on economic concepts, backed by individual financial decisions.
There is no equivalence of ideas based on one's arbitrary perspective.

> But if one's intention is to split and not follow the majority
> hash power when blocks become larger,

The "split" is always by the one that hard forks. The splitter is the
one who changes what exists and therefore creates something new.
Please fix your terminology.

> then why not change the proof-of-work? This would certainly result
> in a peaceful splitting, as you said you desire.

A hard fork, including changing the PoW algorithm, requires the
purposely improbable coordination of the economy in the creation of a
new coin and the abandonment of the old. This should be apparent from
the ongoing block size hard fork attempts.

e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY2D2SAAoJEDzYwH8LXOFO3r0H/R0PTi2x15Zj1oceOqcNpP4k
/TrTohFl/BRE4PaOqJ9n9DbJ6W8rnAjRnguOIgOB1CSIRCuy73AQ4aqRSTCBlHbe
VVrlKKFS8zh50Cjg8tlnomWeKe1YDO31R2Avises+Dr3kyqQ9+QYtOoqxvuvYrXo
B03fjPIL0eTQypA4KP/W7CxrlHN7oyN+PtehpI51JOGMxx6Xc0RDelGz1NTlQQ1f
90Axeey51tgAzJ8wsC+Vf22hZdU06VDdtG8PSHVcrELoicDnEjR4T+1XqA1hcAY2
hWBX5qpQYJqJv1ypfTH0ouh6QtLhJZGCWzKZnpH+T7d3FUG+AXn0UjTP3Nkh7NY=
=Cc8r
-----END PGP SIGNATURE-----