# Lamport signatures and other CAT tricks

**URL:** <https://delvingbitcoin.org/t/lamport-signatures-and-other-cat-tricks/236>\
**Category:** Protocol Design\
**Created:** [December 2, 2023, 11:15pm UTC](https://delvingbitcoin.org/t/lamport-signatures-and-other-cat-tricks/236 "2023-12-02T23:15:49Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![cguida](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/c/87869e/32.png) [@cguida](https://delvingbitcoin.org/u/cguida)\
**Post date:** [February 11, 2024, 10:42pm UTC](https://delvingbitcoin.org/t/lamport-signatures-and-other-cat-tricks/236/16 "2024-02-11T22:42:14Z")

</div>

@harding See the part of the draft spec [here](https://github.com/instagibbs/bolts/blob/a17b60f42077a785c625430e8f6e8e2828d4d898/XX-eltoo-transactions.md#rationale-1) where instagibbs uses the annex to store the tapleaf for the previous settlement transaction, inside the witness for the invalidated update transaction. Without the tapleaf for the old settlement transaction, there’s no way to spend the old update transaction into the new update transaction, without storing every old settlement transaction’s output amounts and htlcs (or, tapleaves) in the database, which Symmetry tries to avoid.

---

_[View the full topic](https://delvingbitcoin.org/t/lamport-signatures-and-other-cat-tricks/236)._