In the PR review club on "nVersion=3 and Package RBF" (February 22nd 2023) glozow stated:

But in policy we want to strictly loosen rules. Otherwise we could accidentally censor transaction relay for an application. So either we really really make sure nobody is using it currently, or just pick something that's nonstandard today. In a sense, we always want consensus changes to be soft forks, but policy changes to be "hard forks".

I was looking at the proposal for nVersion=3 transactions and that seems to introduce a new set of "additional rules" that don't seem to be relaxations. So is it the case that ideally this wouldn't be the case but the nVersion=3 proposal is ignoring this principle because they are needed for Lightning and multiparty protocols?

1 Answer 1


The PR review club notes state:

A “v3 transaction” refers to a transaction that has its nVersion field set to 3. These types of transactions are currently nonstandard in Bitcoin Core.

Because v3 transactions are currently nonstandard if you make them standard (even with a set of additional policy rules applied to them) then this is still essentially a relaxation as you are now accepting into your mempool (and relaying) a subset of transactions with the nVersion field set to 3 when you previously weren't at all.

The equivalent in consensus would be introducing a new SegWit version (e.g. SegWit v2) that had more relaxed consensus rules than SegWit v1. You might think "more relaxed" means it is a hard fork but because SegWit v2 were previously anyone-can-spend (no consensus rules) applying any consensus rules to SegWit v2 outputs is adding restrictions and hence still a soft fork.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.