# V3 transaction policy for anti-pinning

**URL:** <https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340>\
**Category:** Protocol Design\
**Tags:** lightning, pinning, mempool\
**Created:** [January 2, 2024, 9:31am UTC](https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 "2024-01-02T09:31:41Z")\
**Posts on this page:** 1\
**Showing post:** 39

<div class="post-metadata">

**Author:** ![instagibbs](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/instagibbs/32/28_2.png) [@instagibbs](https://delvingbitcoin.org/u/instagibbs)\
**Post date:** [February 9, 2024, 6:28pm UTC](https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/39 "2024-02-09T18:28:27Z")

</div>

> [@morehouse](#):
>
> Then each use case could decide for themselves.

Primarily I think:

1. It still leaves the problem of deciding how many utxos your future self may need for fees for presigned contracts, though it does let you possibly scale this value along with sats-at-risk for the smart contract in question.
2. More bits used, more fingerprinting
3. We’ll likely learn(even more!) from working on and deploying V3 that we might want to apply forward. We might require expanded topologies which may make interaction between many bits weird. We might to upgrade V3 directly. We might decide we want a new bit to mean a policy for securing `SIGHASH_SINGLE|ACP` like constructs instead to cover more cases.

---

_[View the full topic](https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340)._