# 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:** 40

<div class="post-metadata">

**Author:** ![sdaftuar](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/s/0ea827/32.png) [@sdaftuar](https://delvingbitcoin.org/u/sdaftuar)\
**Post date:** [February 13, 2024, 4:12pm UTC](https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/40 "2024-02-13T16:12:15Z")

</div>

> [@t-bast](#):
>
> The issue is that commitment transaction may be very large when filled with pending HTLCs. I believe that lnd for example allows up to 483 HTLCs in each direction in the commitment. When filled with 2 \* 483 HTLCs, it already costs a bit more than 800 000 sats in fees to reach 20 sat/byte! I would expect such a fee bump to require multiple wallet inputs (even though we have no idea what the utxo set of node operators looks like).

If the concern is really that you might have a very large commitment transaction (say 30k-40k vbytes) that may require a lot of UTXOs in order to CPFP, then it would seem that the downside from having to first consolidate your UTXOs down to 1 in a separate transaction, get that confirmed, and then use that to CPFP is not so large, in percentage terms?

The additional number of vbytes consumed to consolidate first would be something like 110 vbytes, if I’m calculating right (1 extra transaction’s overhead, plus one extra output created and one extra input spent).

Not ideal for a long run solution, but in thinking about tradeoffs, maybe minimizing pinning potential by going with a smaller child size is more valuable?

---

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