[Bitcoin-segwit2x] Wayniloans on SegWit2x

Sjors Provoost sjors at sprovoost.nl
Thu Sep 21 05:45:35 UTC 2017


On Thu, Sep 21, 2017, at 06:44, Will M via Bitcoin-segwit2x wrote:
> 
> On Sep 19, 2017, 3:09 AM -0600, Marcel Jamin via Bitcoin-segwit2x <bitcoin-
> segwit2x at lists.linuxfoundation.org>, wrote:> 
>> > The current Bitcoin rule is based on SegWit2X
>> 
>> I never agreed to SegWit2X and I will keep using the client I've been
>> using for the past 8 years. From my and more importantly my node's
>> point of view, SegWit activated via BIP141.> You aren’t using the same client you’ve been using for the past 8
> years. If you were, you would not be using the “Bitcoin” of today. You
> would be running a client predating 0.8 client and you would not sync
> to what you believe is the original bitcoin blockchain, but is not.
> There was a planned chain fork on August 16 2013 that forked unpatched
> nodes off the network. This event is described in the resolution
> section of BIP50[1] and is reproducible if you install 0.7.2 or
> earlier and try to sync up. You will fork off at block height 252,451.Slight nuance here: it only takes a trivial settings change to
make 0.7.2 follow the present majority hashpower chain, no upgrade
is required.
A more important reason to upgrade is performance. Where 0.15 can sync
todays chain in a few hours, 0.8.6 will take 5 days [0]. I didn’t try
0.7.2, but to get an idea, it takes v0.5 about 3 days to sync just to
the end of 2013, weeks to get to 2015 and I wasn’t able to sync is all
the way to the present.
It seems clear that everyone needs to upgrade at some point. From my
understanding the contention is primarily around how to plan such an
upgrade, secondarily about whether/when a size increase beyond SegWit is
desirable. Where SegWit2x and Spoonnet require picking a block and
coordinating the upgrade accross the ecosystem, softforks like SegWit
allow this to happen over a longer time period and with less
coordination. It even allows people to ignore it if they don’t want to
save on fees and such.
Sjors

[0]
https://medium.com/provoost-on-crypto/historical-bitcoin-core-client-performance-c5f16e1f8ccb
Links:

  1. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170921/cdcbdaa9/attachment.html>


More information about the Bitcoin-segwit2x mailing list