> Bob can craft a HTLC-preimage spend of the single offered output spending one
> of 0.1 BTC HTLC payout (and revealing its preimage) while burning all the
> value as fee. This replaces out Alice's honest HTLC-timeout out of network
> mempools, are they're concurrent spend. Bob can repeat this t
Hi Johan,
> Is this a concern though, if we assume there's no revoked state that
> can be broadcast (Eltoo)? Could you share an example of how this would
> be played out by an attacker?
Sure, let's assume no revoked state can be broadcast (Eltoo).
My understanding of the new covenant mechanism i
Hi, Antoine.
> The attack works on legacy channels if the holder (or local) commitment
> transaction confirms first, the second-stage HTLC claim transaction is fully
> malleable by the counterparty.
Yes, correct. Thanks for pointing that out!
> I think one of the weaknesses of this approach is
Hi Johan,
Few comments.
## Transaction recycling
The transaction recycling attack is made possible by the change made
to HTLC second level transactions for the anchor channel type[8];
making it possible to add fees to the transaction by adding inputs
without violating the signature. For the legac
Hi all,
After the transaction recycling has spurred some discussion the last
week or so, I figured it could be worth sharing some research I’ve
done into HTLC output aggregation, as it could be relevant for how to
avoid this problem in a future channel type.
TLDR; With the right covenant we can c
