Antoine Riard

> The alternative approach would be for early lightning adopters to update their channel on-chain to permanently invalidate any old states that might enable pinning (eg, by splicing some funds...

Looked on the proposed `doc/policy/version3_transactions.md` changes with other Lightning eyes on a whiteboard, and as far as I can tell it works well for Lightning usual flow and also upcoming...

i think there is @petertodd ’s https://petertodd.org/2024/one-shot-replace-by-fee-rate to weigh as a pinning solution. sounds to me slightly more robust than v3 policy as no malleability in the fee-bumping mechanism. however...

@petertodd > Can you give a bit more detail on what challenges you think that'll pose? from my memory: "How this new replacement rule would behave if you have a...

> Not sure what you mean by "threshold effect". So long as the N block threshold isn't too large, transactions that don't quite reach the threshold have a decent chance...

> It looks like removal of CPFP carve out is not a concern for you; you just don't think v3 is a good idea. If that's the case, there is...

So carve-out was introduced back by #15681 with motivation to allow one extra single ancestor tx. After testing https://github.com/bitcoin/bitcoin/commit/6337b978e77a4e1f93bb009958db7c9a619323df you can always replace a long-chain of transactions with a higher-fee...

@sdaftuar While I'm sharing your opinion on the lack of necessity to not break downstream users’s applications unnecessarily, I think you're missing my present observation on the lack of current...

I’m still very interested in Lightning security flaws, though this is not my responsibility if they’re not shared and fixed across the ecosystem.

> I’m still very interested in Lightning security flaws, though this is not my responsibility if they’re not shared and fixed across the ecosystem. While this is the responsibility of...