[Bitcoin-segwit2x] SegWit2x Hard Fork Testing Update

[Jared Lee Richardson]

There are reasons for and against.  Since currently there isn't a plan for
replay protection, and it appears that the legacy chain is going to starve
for lack of blocks and be forced to change the POW.  If that happens,
changing the version bit would mean more work for wallets and spv clients
for no gain and be the wrong move.

Fundamentally segwit2x is not changing an attribute that spv clients
concern themselves with, ergo there is no need to change the version bit
for them and add extra work to the upgrade.  There is no need to change the
version bit for regular clients due to the big block requirement.

Jared

On Jul 12, 2017 11:58 AM, "Peter Todd via Bitcoin-segwit2x" <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

On Wed, Jul 12, 2017 at 11:26:10AM -0400, Jeff Garzik wrote:
> For tracking and discussion purposes, this was filed by James H at
> https://github.com/btc1/bitcoin/pull/46
>
> tl;dr   It appears to introduce compatibility risk with deployed,
> in-the-field wallets.

One of your arguments against soft-forks has been that they "fool nodes"(1)
by
changing the rules in undetectable ways. One of the counter arguments to
your
argument is we explicitly ensure that soft fork mechanisms use nVersion
signalling to ensure all nodes are given an opportunity to learn that the
fork
is happening; malicious soft-forks of course don't do this, but the fact
they're possible is an unavoidable by-product of Bitcoin's design.

>From the point of view of a headers only lite client, segwit2x is a soft
fork
with no nVersion signalling mechanism.

Now, to be secure all wallets, lite clients or not, will need updating in
the
event of a hard fork to - for instance - ensure they're getting seed nodes
from
appropriate places and the like, and to ensure funds aren't lost in replay
attacks. I'm unclear as to why something that can be fixed in a line or two
of
code - code that needs to be changed anyway to safely support the hard fork
-
trumps these important issues of user consent that you have brought up
before
yourself.

1) https://twitter.com/jgarzik/status/861656643918069760

--
https://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
Bitcoin-segwit2x mailing list
Bitcoin-segwit2x at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170712/86f81781/attachment-0001.html>