📅 Original date posted:2017-07-13
📝 Original message: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
Dan Libby [ARCHIVE] /
npub1hm…jk43d
2023-06-07 18:04:29
in reply to nevent1q…mt62
Author Public Key
npub1hm38d5dwxdq5zxlnv2qdfk3flecptqwl7g7u62ja0tr92d0hmrusejk43dPublished at
2023-06-07 18:04:29Event JSON
{
"id": "71c6450eab7955463e99f63369e06c620678f3bb3435e1a510a2dc1836cfb21b",
"pubkey": "bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9",
"created_at": 1686161069,
"kind": 1,
"tags": [
[
"e",
"c3417a9d5ad76947acf26c6783addd471ca3bcc5d3ed57deae65203b0eaf5238",
"",
"root"
],
[
"e",
"77466dc07aa3c11bae0c95b725ac717b00d3f52dcc546b8e7f2392fe523762a3",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2017-07-13\n📝 Original message:On 07/12/2017 06:48 PM, Anthony Towns via bitcoin-dev wrote:\n\n\u003e I think that terminology isn't quite precise. I think your options are:\n\u003e \n\u003e - if you're a miner or run a mining pool, you can *signal* (or not\n\u003e signal) support for segwit activation; you do this by controlling\n\u003e the block version\n\nI wish to NOT signal for segwit if mining.\n\n\u003e - if you're running a node, you can choose to *enforce* (or not\n\u003e enforce) the additional consensus rules associated with segwit\n\nI wish to NOT enforce segwit consensus rules.\n\n\u003e \n\u003e I think it's the latter you're talking about. \"Activation\" is different:\n\u003e it's the collective action of the bitcoin ecosystem to start enforcing\n\u003e the segwit consensus rules after a sufficient majority of miners are\n\u003e signalling support. That's not something you as an individual can control.\n\ngood point, thanks for clarifying.\n\n\u003e If you want to disable enforcement of segwit rules, even if a majority of\n\u003e mining power signal activation, you can change the code and recompile to\n\u003e do so, for example by changing the nTimeout setting for DEPLOYMENT_SEGWIT\n\u003e from 1510704000 (Nov 15 2017) to 1493596800 (May 1 2017, already expired).\n\u003e This is probably a bad idea, in that it will cause you to risk accepting\n\u003e blocks that nobody else in the network will accept, opening you up\n\u003e to higher risk of double spends, and may cause you to be unable to\n\u003e peer with segwit enabled nodes after segwit is activated if your node\n\u003e is rejecting blocks with witness data because you think segwit is not\n\u003e enabled while they think it is enabled. To avoid that you would also need\n\u003e to stop setting the NODE_WITNESS p2p bit, which you might be able to do\n\u003e by setting the nTimeout above to 0 instead of just a date in the past? I\n\u003e believe a timeout of 0 gets treated as automatically FAILED. There might\n\u003e be other complexities too though.\n\nI've set the nTimeout to 0 already. I will look into the NODE_WITNESS\np2p bit.\n\nI think that logically, if coded correctly, my node would have no more\nrisks than any other legacy (pre-segwit) node on the network...\n\n\u003e \n\u003e\u003e I'm not looking for reasons NOT to do it, only HOW to do it without\n\u003e\u003e unwanted side-effects.\n\u003e \n\u003e The unwanted side-effects are precisely the reasons not to do it. If you\n\u003e don't understand what they are, you won't be able to avoid them. :)\n\nfair enough. But these are the same risks as running any pre-segwit\nnode, correct? For example bitcoin-core 0.13.0, or any version of\nbtcd to date...\n\n\n-- \nDan Libby\n\nOpen Source Consulting S.A.\nSanta Ana, Costa Rica\nhttp://osc.co.cr\nphone: 011 506 2204 7018\nFax: 011 506 2223 7359",
"sig": "ea07ee345c12b589f5f6c77f7ff300a0a1139f37c08b82e087ad0e6978b1cac2a7297eda66efa42c51341a506fe8a8bef433805545ffb7fbbd9f32cee79e8d70"
}