05:35 <rusty> aj: I only realized late last night that your point about downstream invalidation by third parties during a reorg is a bridge we've already crossed anyway, due to RBF.

05:44 <aj> rusty: RBF is due to "second parties" in my terminology (ie, people who can re-sign things), not completely unrelated third-parties (eg who malleate signatures by negating s)

05:45 <rusty> aj: No, the miner can well use an existing RBF alternative.

05:46 <rusty> aj: Just as in your argument, the miner can reattach an existing NOINPUT tx.

05:46 <aj> rusty: there's only an existing RBF alternative if a someone signed it

05:46 <rusty> aj: and honest people do that all the time.

05:48 <rusty> quote: aj: the bad case for lightning isn't for lightning users directly, it's for people receiving payments after eltoo-non-cooperative-closes; ie FUNDING->UPDATE1->UPDATE4->SETTLEMENT4->CLAIM->pay2exchange. reorg drops UPDATE1 from the chain, FUND->UPDATE4'->SETTLE4'->CLAIM' (all noinput, so all fine), but CLAIM->pay2exchange wasn't NOINPUT so is lost/doublespent

05:48 <rusty> Now, this scenario already exists. Anyone receiving payment from a tx which spends an RBF is now vulnerable on reorg.

05:49 <rusty> A completely honest miner may do this because they didn't see the original, or even had an RBF variant which paid higher fee and a lower-fee one got in-chain first.