# Lightning transactions with v3 and ephemeral anchors

**URL:** <https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418>\
**Category:** Protocol Design\
**Tags:** mempool, lightning\
**Created:** [January 16, 2024, 5:28pm UTC](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "2024-01-16T17:28:44Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![murch](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/murch/32/139_2.png) [@murch](https://delvingbitcoin.org/u/murch)\
**Post date:** [January 17, 2024, 2:32pm UTC](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/11 "2024-01-17T14:32:34Z")

</div>

> What we _will_ want from Bitcoin Core (and other wallet libraries) is the ability to restrict coin selection to, at max, some total input weight.

We are basically 90% there. Our coin selection algorithms already take a `max_weight` parameter for us to be able to avoid exceeding the standardness limit for weight. Passing something through the transaction building RPCs should be fairly easy. CoinGrinder would be a big help though, since SRD only greedily searches for a solution below the weight limit by removing the lowest effective value input when it is overweight. BnB and CG should always find a solution if it exists.

Of course, CoinGrinder has been open since July and has seen only a modicum of review so far, so a few more people would have to take a look at it.

---

_[View the full topic](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418)._