pull down to refresh

In a hypothetical scenario, if OP_CTV activation happens today, what you would do being a node runner?
Accept40.0%
Reject 13.3%
Neutral 46.7%
15 votes \ 17h left
0 sats \ 5 replies \ @ek 3h
I think as a node runner, you don't accept or reject a soft fork. You don't have to do anything except upgrade if you want to use OP_CTV in your transactions. If you don't upgrade, you can still follow the chain since it's a soft fork.
I think the question should be what miners would do if activation happens today. Would they mine blocks with OP_CTV codes (including on top of them) or reject them and split the chain?
Remember, for taproot, we used "Speedy Trial" and miners were signalling, not nodes:
BIP9 and Speedy Trial is a softfork deployment method where the miners and mining pools help to coordinate the deployment of a softfork. They do so by signalling for deployment of the softfork in their mined blocks. To lock in the softfork for activation, 90% of the blocks have to signal.
The signalling method works in periods of 2016 blocks, meaning that within a 2016 block period, 90%, or 1815 of the 2016 blocks have to signal for readiness.
reply
The last word are node runners, beyond miners. Both define ‘final consensus’. Have CUSF and others forms of soft forks, but this is a kind of thing for another discussion.
reply
0 sats \ 3 replies \ @ek 3h
Do you mean with "reject as a node runner" to upgrade my node to something that rejects blocks with OP_CTV in it and thus creates a hard fork? I think that's what bcashers did with their nodes but I am not sure. I wasn't around at that time.
reply
That’s the point I’m leveraging here. I wanna see what nodes would do in this hypothetical scenario.
reply
0 sats \ 1 reply \ @ek 3h
Okay, so "accept" means to do nothing? Isn't that the same as "neutral"?
Or "accept" = "upgrade node to version with OP_CTV" and "neutral" = "do nothing"?
reply
100 sats \ 0 replies \ @Rsync25 OP 3h
Yes! Second option.
reply
0 sats \ 0 replies \ @Roll 7h
OP_CHECKTEMPLATEVERIFY (CTV) is a proposed new opcode that takes a commitment and requires any transaction executing the opcode to match the commitment in the following fields: its version, locktime, signature scripts, number of inputs, sequences, number of outputs, outputs, and the location of the input being spent within the spending transaction. This allows an output to specify how its funds may be spent—a design known in Bitcoin as a covenant.
reply