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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
