# 0conf LN channels and v3 anchors

**URL:** <https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494>\
**Category:** Protocol Design\
**Tags:** mempool, lightning\
**Created:** [January 29, 2024, 10:29pm UTC](https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494 "2024-01-29T22:29:37Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![t-bast](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/t-bast/32/98_2.png) [@t-bast](https://delvingbitcoin.org/u/t-bast)\
**Post date:** [January 30, 2024, 10:24am UTC](https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494/2 "2024-01-30T10:24:58Z")

</div>

> [@MattCorallo](#):
>
> I’m not sure what the correct fix is for tweaking v3 to allow this, maybe the funding transaction could be restricted to no unconfirmed inputs and then we simply allow an A → B → {C, D, CPFP bump} topology.

I’m not sure that’s sufficient, because you usually want to allow having a chain of unconfirmed splices. The topologies that v3 would then need to support would probably be too complex to analyze before cluster mempool…

> [@MattCorallo](#):
>
> If the funding transaction confirms on its own (or via CPFP if B has a change output on it, though that’s certainly not a requirement we’d like to require) then we’re fine

My plan was to have a change output on the funding/splice transaction on B’s side to ensure that it could be CPFP-ed. This is indeed far from ideal, but that’s something we already need today if we want to protect against pinning, so v3 doesn’t make it worse?

---

_[View the full topic](https://delvingbitcoin.org/t/0conf-ln-channels-and-v3-anchors/494)._