From: Dan Libby <dan@osc•co.cr>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] how to disable segwit in my build?
Date: Thu, 13 Jul 2017 09:13:04 -0700 [thread overview]
Message-ID: <4a4d74b0-c55b-239d-5563-9c964ecd61b6@osc.co.cr> (raw)
In-Reply-To: <20170713014826.GA12388@erisian.com.au>
On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:
> I think that terminology isn't quite precise. I think your options are:
>
> - if you're a miner or run a mining pool, you can *signal* (or not
> signal) support for segwit activation; you do this by controlling
> the block version
I wish to NOT signal for segwit if mining.
> - if you're running a node, you can choose to *enforce* (or not
> enforce) the additional consensus rules associated with segwit
I wish to NOT enforce segwit consensus rules.
>
> I think it's the latter you're talking about. "Activation" is different:
> it's the collective action of the bitcoin ecosystem to start enforcing
> the segwit consensus rules after a sufficient majority of miners are
> signalling support. That's not something you as an individual can control.
good point, thanks for clarifying.
> If you want to disable enforcement of segwit rules, even if a majority of
> mining power signal activation, you can change the code and recompile to
> do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT
> from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).
> This is probably a bad idea, in that it will cause you to risk accepting
> blocks that nobody else in the network will accept, opening you up
> to higher risk of double spends, and may cause you to be unable to
> peer with segwit enabled nodes after segwit is activated if your node
> is rejecting blocks with witness data because you think segwit is not
> enabled while they think it is enabled. To avoid that you would also need
> to stop setting the NODE_WITNESS p2p bit, which you might be able to do
> by setting the nTimeout above to 0 instead of just a date in the past? I
> believe a timeout of 0 gets treated as automatically FAILED. There might
> be other complexities too though.
I've set the nTimeout to 0 already. I will look into the NODE_WITNESS
p2p bit.
I think that logically, if coded correctly, my node would have no more
risks than any other legacy (pre-segwit) node on the network...
>
>> I'm not looking for reasons NOT to do it, only HOW to do it without
>> unwanted side-effects.
>
> The unwanted side-effects are precisely the reasons not to do it. If you
> don't understand what they are, you won't be able to avoid them. :)
fair enough. But these are the same risks as running any pre-segwit
node, correct? For example bitcoin-core 0.13.0, or any version of
btcd to date...
--
Dan Libby
Open Source Consulting S.A.
Santa Ana, Costa Rica
http://osc.co.cr
phone: 011 506 2204 7018
Fax: 011 506 2223 7359
next prev parent reply other threads:[~2017-07-13 16:13 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 16:50 [bitcoin-dev] Updating the Scaling Roadmap Paul Sztorc
2017-07-11 16:03 ` Chris Stewart
2017-07-11 16:49 ` Adam Back
2017-07-11 20:01 ` Pieter Wuille
2017-07-11 20:36 ` Paul Sztorc
2017-07-11 21:40 ` Pieter Wuille
2017-07-11 22:49 ` Paul Sztorc
2017-07-11 21:16 ` CryptAxe
2017-07-11 20:18 ` Paul Sztorc
2017-07-11 21:31 ` Gregory Maxwell
2017-07-11 22:27 ` Paul Sztorc
2017-07-11 21:11 ` Gregory Maxwell
2017-07-11 21:40 ` Gregory Maxwell
2017-07-11 22:17 ` Paul Sztorc
2017-07-11 22:41 ` Tao Effect
2017-07-11 22:57 ` Paul Sztorc
2017-07-11 23:12 ` Tao Effect
2017-07-12 0:21 ` Paul Sztorc
2017-07-12 7:27 ` Jacob Eliosoff
2017-07-12 19:19 ` Chris Stewart
2017-07-12 19:24 ` Tao Effect
2017-07-12 19:34 ` Chris Stewart
2017-07-12 19:42 ` Tao Effect
2017-07-12 19:54 ` CryptAxe
2017-07-12 21:55 ` Tao Effect
2017-07-12 22:07 ` CryptAxe
2017-07-11 23:36 ` Bryan Bishop
2017-07-12 0:07 ` Gregory Maxwell
2017-07-12 1:40 ` Paul Sztorc
2017-07-12 2:48 ` Bryan Bishop
2017-07-12 3:33 ` Gregory Maxwell
2017-07-12 6:17 ` [bitcoin-dev] how to disable segwit in my build? Dan Libby
2017-07-13 1:04 ` Gregory Maxwell
2017-07-13 13:11 ` Federico Tenga
2017-07-13 13:39 ` Hampus Sjöberg
2017-07-13 16:19 ` Dan Libby
2017-07-13 16:35 ` Jameson Lopp
2017-07-13 21:58 ` Dan Libby
2017-07-13 22:50 ` Hampus Sjöberg
2017-07-13 23:20 ` Dan Libby
2017-07-14 8:52 ` Hampus Sjöberg
2017-07-14 9:03 ` Tier Nolan
2017-07-13 23:19 ` Lucas Clemente Vella
2017-07-13 16:05 ` Dan Libby
2017-07-14 21:11 ` Troy Benjegerdes
2017-07-13 1:48 ` Anthony Towns
2017-07-13 16:13 ` Dan Libby [this message]
2017-07-12 1:22 ` [bitcoin-dev] Updating the Scaling Roadmap Karl Johan Alm
2017-07-12 9:37 ` Tom Zander
2017-07-12 9:02 ` Tom Zander
2017-07-11 23:28 ` Anthony Towns
2017-07-17 17:13 ` [bitcoin-dev] Updating the Scaling Roadmap [Update] Paul Sztorc
2017-07-17 18:49 ` Alex Morcos
2017-07-17 20:13 ` Paul Sztorc
2017-07-17 21:50 ` Peter Todd
[not found] ` <20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
2017-07-17 22:04 ` Paul Sztorc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a4d74b0-c55b-239d-5563-9c964ecd61b6@osc.co.cr \
--to=dan@osc$(echo .)co.cr \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox