<p>Preventing unknown parties to directly waste nodes resources is only one of the goals of <a href="https://bitcoin.stackexchange.com/q/120269/101498">mempool policy</a>. Some other goals are:</p>
<ul>
<li>Providing miners with an efficient way of building profit-maximizing templates. Some policy rules are necessary to achieve this. For instance, a restriction on the size of transaction chains (or <a href="https://bitcoinops.org/en/topics/cluster-mempool/" rel="nofollow noreferrer">clusters</a>). Because it is in the interest of the non-mining nodes (and the network at large) to have a mempool approximately in sync with miners', this policy applies to them as well.</li>
<li>Discouraging some types of transactions. Some transactions are more harmful than others. In extreme cases, transactions with large &quot;negative externalities&quot; might need to be soft forked out. In less extreme cases when there is not a large demand for this specific type of transaction, making them non-standard may be enough to disincentivize their use. One example of such a rule is how in 2013 demand for storing data onchain was funneled into a less harmful way of achieving it by making large bare multisigs non-standard and standardizing an <code>OP_RETURN</code> output type, which could be pruned from the UTxO set. See discussion <a href="https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25015747" rel="nofollow noreferrer">here</a> for instance.</li>
<li>Upgrade hook for soft forks. A major concern when considering a soft fork is to be careful not to make invalid anything (harmless) that anybody may be using. Only invalidating non-standard behaviour helps to substantially increase confidence in the safety of rolling out a soft fork. One example of such a rule is how it is non-standard to spend a Script containing an <code>OP_NOP</code>.</li>
</ul>
<p>For all these use cases just requiring a PoW be attached to a broadcast unconfirmed transaction would not help.</p>

CC BY-SA 4.0
2024-12-16T16:19:17.130Z
PoW-policy could help non-mining nodes improve their mempools by relaying transactions that would otherwise go only directly to miners due to non-standardness.

Can you give an example of transactions soft-forked out? Shouldn't that be handled at the consensus level, not via policy?

PoW difficulty could reflect how 'harmful' a tx is, acting as a dimmer rather than a switch, disincentivizing but still allowing propagation if sufficiently motivated (as we know he can go directly to miners regardless of policy).

On soft forks, couldn't PoW achieve a similar effect by adjusting difficulty?
jgmontoya
CC BY-SA 4.0
2024-12-16T16:37:20.627Z
Heh, that's a lot of followup questions. :) I guess for the examples of rules i could update my answer here to give an example for each category, as i did for the first one. For the other questions how about you create a new question linking to this answer as a follow-up? I think it would be clearer than using the comment section to answer or editing my answer to answer questions from the comments.
Antoine Poinsot
CC BY-SA 4.0
2024-12-16T16:47:50.407Z
Edited my answer to add an example of a policy rule for each category i listed.
Antoine Poinsot
CC BY-SA 4.0
2024-12-16T15:29:51.580Z
2024-12-16T16:47:13.627Z
2024-12-16T16:47:13.627Z
Antoine Poinsot
<p>Interesting approach. It could be in a similar way as PoW for mail spam. But I think it is the same as asking them to pay more fees (than the required ones to enter a block, maybe remove SegWit discount?). At the end PoW just increases the economic cost of doing such a transaction by burning electricity and time.</p>
<p>I think that changes would be a soft-fork and I guess it will be easier to convince miners to charge more for non-standard tx than to simply accept money-burning tx in the form of PoW.</p>

CC BY-SA 4.0
2024-12-16T15:31:08.567Z
You seem to be confused between policy and consensus.
Antoine Poinsot
CC BY-SA 4.0
2024-12-16T15:37:20.787Z
> _But I think it is the same as asking them to pay more fees (than the required ones to enter a block, maybe remove SegWit discount?)._

I like that idea as well, for non-standard transactions only relay them if the fee rate makes it highly likely that it will be included in the next block or something like that.


> _I think that changes would be a soft-fork and I guess it will be easier to convince miners to charge more for non-standard tx than to simply accept money-burning tx in the form of PoW._

I don't think this is a soft-fork really. I don't see it being a part of consensus.
jgmontoya
CC BY-SA 4.0
2024-12-16T15:58:58.793Z
@jmontoya > _I don't think this is a soft-fork really. I don't see it being a part of consensus._ It should be part of the consensus as if not it could be ignored in the same way that policy can be ignored now and get transactions into the blocks without relaying on the p2p network.
polespinasa
CC BY-SA 4.0
2024-12-16T15:59:31.267Z
@AntoinePoinsot what makes you think that?
polespinasa
CC BY-SA 4.0
2024-12-16T16:25:05.077Z
@polespinasa Yes, as is it could be ignored in the same way any policy rule can be.

If something like this is eventually implemented, and if it does work well it could eventually be part of consensus I guess. But it doesn't need to be. I'm not even sure we actually want it to be, policy exists as a different thing than consensus for a reason.
jgmontoya
CC BY-SA 4.0
2024-12-16T14:25:09.887Z
2024-12-16T14:25:09.887Z
polespinasa
<p>As I understand it, policy rules in Bitcoin are primarily designed to prevent other users from abusing node resources.</p>
<p>However, what if we introduced a proof-of-work requirement for transactions that are currently considered non-standard?</p>
<p>The idea is that requiring PoW for such transactions would impose a cost on users attempting to relay them, potentially reducing abuse.</p>
<p>Would this approach be feasible or beneficial?</p>
<p>The goal would be to create a more accurate and inclusive mempool view. Currently, non-standard transactions are sometimes included in blocks, but because regular nodes don't relay them, they aren't visible in most mempools. Could a PoW requirement help standard nodes relay these transactions while still deterring abuse?</p>

CC BY-SA 4.0
2024-12-16T15:30:33.467Z
Great question, thanks.
Antoine Poinsot
<proof-of-work><non-standard-transaction><mempool-policy>
Could proof-of-work be used to replace policy rules?
jgmontoya
# Could proof-of-work be used to replace policy rules?

(Asked by: username_0 on 2024-12-06)

As I understand it, policy rules in Bitcoin are primarily designed to prevent other users from abusing node resources.

However, what if we introduced a proof-of-work requirement for transactions that are currently considered non-standard?

The idea is that requiring PoW for such transactions would impose a cost on users attempting to relay them, potentially reducing abuse.

Would this approach be feasible or beneficial?

The goal would be to create a more accurate and inclusive mempool view. Currently, non-standard transactions are sometimes included in blocks, but because regular nodes don't relay them, they aren't visible in most mempools. Could a PoW requirement help standard nodes relay these transactions while still deterring abuse?

**Tags:** proof-of-work, non-standard-transaction, mempool-policy

> **Comments:**
> **username_1**: Great question, thanks.  

---

## 2 answers

### Answer by username_1 on 2024-12-16. Score: 2

Preventing unknown parties to directly waste nodes resources is only one of the goals of [mempool policy](https://bitcoin.stackexchange.com/q/120269/101498). Some other goals are:

* Providing miners with an efficient way of building profit-maximizing templates. Some policy rules are necessary to achieve this. For instance, a restriction on the size of transaction chains (or [clusters](https://bitcoinops.org/en/topics/cluster-mempool/)). Because it is in the interest of the non-mining nodes (and the network at large) to have a mempool approximately in sync with miners', this policy applies to them as well.
* Discouraging some types of transactions. Some transactions are more harmful than others. In extreme cases, transactions with large "negative externalities" might need to be soft forked out. In less extreme cases when there is not a large demand for this specific type of transaction, making them non-standard may be enough to disincentivize their use. One example of such a rule is how in 2013 demand for storing data onchain was funneled into a less harmful way of achieving it by making large bare multisigs non-standard and standardizing an `OP_RETURN` output type, which could be pruned from the UTxO set. See discussion [here](https://github.com/bitcoin/bitcoin/pull/2738#issuecomment-25015747) for instance.
* Upgrade hook for soft forks. A major concern when considering a soft fork is to be careful not to make invalid anything (harmless) that anybody may be using. Only invalidating non-standard behaviour helps to substantially increase confidence in the safety of rolling out a soft fork. One example of such a rule is how it is non-standard to spend a Script containing an `OP_NOP`.

For all these use cases just requiring a PoW be attached to a broadcast unconfirmed transaction would not help.

> **Comments:**
> **username_0**: PoW-policy could help non-mining nodes improve their mempools by relaying transactions that would otherwise go only directly to miners due to non-standardness.  Can you give an example of transactions soft-forked out? Shouldn't that be handled at the consensus level, not via policy?  PoW difficulty could reflect how 'harmful' a tx is, acting as a dimmer rather than a switch, disincentivizing but still allowing propagation if sufficiently motivated (as we know he can go directly to miners regardless of policy).  On soft forks, couldn't PoW achieve a similar effect by adjusting difficulty?  
> **username_1**: Heh, that's a lot of followup questions. :) I guess for the examples of rules i could update my answer here to give an example for each category, as i did for the first one. For the other questions how about you create a new question linking to this answer as a follow-up? I think it would be clearer than using the comment section to answer or editing my answer to answer questions from the comments.  
> **username_1**: Edited my answer to add an example of a policy rule for each category i listed.  

---

### Answer by username_2 on 2024-12-16. Score: 0

Interesting approach. It could be in a similar way as PoW for mail spam. But I think it is the same as asking them to pay more fees (than the required ones to enter a block, maybe remove SegWit discount?). At the end PoW just increases the economic cost of doing such a transaction by burning electricity and time.

I think that changes would be a soft-fork and I guess it will be easier to convince miners to charge more for non-standard tx than to simply accept money-burning tx in the form of PoW.

> **Comments:**
> **username_1**: You seem to be confused between policy and consensus.  
> **username_0**: > _But I think it is the same as asking them to pay more fees (than the required ones to enter a block, maybe remove SegWit discount?)._  I like that idea as well, for non-standard transactions only relay them if the fee rate makes it highly likely that it will be included in the next block or something like that.   > _I think that changes would be a soft-fork and I guess it will be easier to convince miners to charge more for non-standard tx than to simply accept money-burning tx in the form of PoW._  I don't think this is a soft-fork really. I don't see it being a part of consensus.  
> **username_2**: @jmontoya > _I don't think this is a soft-fork really. I don't see it being a part of consensus._ It should be part of the consensus as if not it could be ignored in the same way that policy can be ignored now and get transactions into the blocks without relaying on the p2p network.  
> **username_2**: @username_1 what makes you think that?  
> **username_0**: @username_2 Yes, as is it could be ignored in the same way any policy rule can be.  If something like this is eventually implemented, and if it does work well it could eventually be part of consensus I guess. But it doesn't need to be. I'm not even sure we actually want it to be, policy exists as a different thing than consensus for a reason.  

---

