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

<div class="post-metadata">

**Author:** ![ajtowns](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/ajtowns/32/417_2.png) [@ajtowns](https://delvingbitcoin.org/u/ajtowns)\
**Post date:** [January 18, 2024, 5:12am UTC](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/15 "2024-01-18T05:12:05Z")

</div>

> [@instagibbs](#):
>
> Huh! I hadn’t considered the fact that _revoked_ states would allow _HLTC-Timeout paths_ to create pins.

One option might be to have two versions of the `HTLCClaimB` txs:

- one signed with ACP|SINGLE, but with nSequence = delay so that the honest party can claim revoked outputs
- one signed with SIGHASH\_ALL and no delay, which creates an ephemeral anchor output and prevents pinning

Doubles the number of HTLC signatures you need to do, though, which sucks.

---

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