[Bitcoin-segwit2x] August Status Report for SegWit2x

Peter Todd pete at petertodd.org
Wed Aug 23 18:35:11 UTC 2017


On Wed, Aug 23, 2017 at 08:45:52AM -0700, Mike Belshe wrote:
> > Equally, this shows that hash power signalling is not a good metric: miners
> > have proven that they follow money, not agreements.
> >
> > You and and all other S2X supporters need to stop making these dishonest
> > hashing power support statements.
> >
> 
> I believe your logic is incorrect.  We should concern ourselves with those
> that are mining Bitcoin, not those that are not mining Bitcoin.

Let's go back to the basics here:

BCH is a hard fork of Bitcoin that split from Bitcoin on Aug 1st, a date that
was set in advance. S2X is also a hard fork of Bitcoin, that is planned to
split from the Bitcoin chain as of block #494,784.

Multiple times on this list and on the btc1 github it has been argued that the
alleged hashing power superiority of S2X means that S2X does not need to
implement things like proper BCH-style mandatory replay protection, or lite
client protections like ensuring that lite clients can detect the hard fork via
block headers. For example, Jeff Garzik used that argument here(1) to argue
that the "one chain" outcome is likely, and thus replay protection is not
needed:

    5) It is *not* good to include a change that breaks all wallets (meaning,
    requires upgrade to continue working post-2M HF).  The likely case is that
    the NYA participants and 80+% hashpower will upgrade to 2M BBSI.  Thus, in
    the the likely "one chain" outcome, a break-all-wallets change would be
    unnecessarily disruptive to users (to make a large understatement).

Similarly, Jared Richardson:

    Right now between signalling and signatories, btc1 has ~95% of the
    hashpower.  ~5% of the hashpower is not enough to be viable without a
    hardfork, in which case it would be more appropriate and less damaging for
    the ecosystem for the non-majority hardfork to add replay protection.
    Thus, replay protection would be a net loss for everyone if added to btc1.

Or even your own statements(3):

    Our goal with segwit2x is to get massive miner support.  We'll see if we
    get there.  But if we do get 95+% support, its a better scenario than the
    very large chain split caused by requiring all application software to
    upgrade.

These arguments hinge on hashing power *not* mining Bitcoin, and mining S2X.
But as BCH proves, hashing power will mine whatever is profitable. In fact,
we're already in a situation where it's plausible that the the most-work
SHA256^2 chain may become BCH rather than Bitcoin at some point in the near
future - a serious problem for lite clients as BCH's header chain is consensus
compatible with from Bitcoin's.


> As you can see from the evidence provided above, those mining Bitcoin today
> are signaling for SegWit2x.

In fact, your line of argument raises an important question: do you think S2X
will be Bitcoin? On what basis? It's no different at a technical level than the
BCH hard-fork that you just claimed was *not* Bitcoin, so what makes S2X
Bitcoin?


# References

1) https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000246.html
2) https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-July/000197.html
3) https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-June/000037.html


-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170823/1491a2e1/attachment.sig>


More information about the Bitcoin-segwit2x mailing list