<p>The PR review club <a href="https://bitcoincore.reviews/25038#l-61" rel="nofollow noreferrer">notes</a> state:</p>
<blockquote>
<p>A “v3 transaction” refers to a transaction that has its nVersion field set to 3. These types of transactions are currently <strong>nonstandard</strong> in Bitcoin Core.</p>
</blockquote>
<p>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.</p>
<p>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 &quot;more relaxed&quot; means it is a hard fork but because SegWit v2 were previously anyone-can-spend (no consensus rules) applying <strong>any</strong> consensus rules to SegWit v2 outputs is adding restrictions and hence still a soft fork.</p>

CC BY-SA 4.0
2023-03-01T14:26:09.533Z
2023-03-01T14:32:23.607Z
2023-03-01T14:32:23.607Z
Michael Folkson
<p>In the PR review club on &quot;nVersion=3 and Package RBF&quot; (February 22nd 2023) glozow <a href="https://bitcoincore.reviews/25038#l-61" rel="nofollow noreferrer">stated</a>:</p>
<blockquote>
<p>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 &quot;hard forks&quot;.</p>
</blockquote>
<p>I was looking at the proposal for <code>nVersion=3</code> transactions and that seems to introduce a <a href="https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md#version-3-rules" rel="nofollow noreferrer">new set</a> of &quot;additional rules&quot; that don't seem to be relaxations. So is it the case that ideally this wouldn't be the case but the <code>nVersion=3</code> proposal is ignoring this principle because they are needed for Lightning and multiparty protocols?</p>

<consensus><mempool><p2p>
Is the nVersion=3 policy proposal introducing additional policy rules and going against the policy principle to only relax policy rules?
Michael Folkson
# Is the nVersion=3 policy proposal introducing additional policy rules and going against the policy principle to only relax policy rules?

(Asked by: username_0 on 2023-03-01)

In the PR review club on "nVersion=3 and Package RBF" (February 22nd 2023) glozow [stated](https://bitcoincore.reviews/25038#l-61):

> 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](https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md#version-3-rules) 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?

**Tags:** consensus, mempool, p2p


---

## 1 answers

### Answer by username_0 on 2023-03-01. Score: 1 | Accepted answer

The PR review club [notes](https://bitcoincore.reviews/25038#l-61) 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.


---

