Antoine Riard

Thanks for the review. Fixed all comments, if you have suggestions for the wording happy to take them!

Many thanks for the edit. Updated the local branch with it at 5fb0b5c. Still happy if we can get in, as we might have to reconsider our per-implementation `max_dust_htlc_exposure_msat` if...

@t-bast on E2E issues with a sender requiring multiples invoices you may bound through some utxo-pinning stuff, like if we adopt Poodle (or any confidential-utxo declaration scheme) for dual-funding we...

Still reviewing the current state of the discussion, though here some initial thoughts. In the multi-party setup (N > 2), I think there is a concern of a "miner harvesting"...

> I don't think we can, otherwise what we'll see in practice is that channel open attempts will deadlock because each peer is waiting for the other to start. I...

> However, the time window where that can happen is in the range of seconds: in practice you probably won't often open multiple channels per second, and even if you...

I do think there are multiple issues that this SECURITY.md may try to address: * Process disclosure for spec issue or base layer affecting all implementations, i.e who to contact...

Already thought a lot about a potential `SIGHASH_ANYAMOUNT` to do just-in-time fee management for off-chain contracts. And thus spare us the pitfalls around useless locked liquidity you're mentioning. I've never...

How smart we can be with new sighash/covenant proposals we'll hit a fundamental LN design issue. The chain can't guess a state commitment was honest until the justice period is...

Lightning legacy channel types (before BOLT9's `option_anchors_output` / `option_anchors_zero_fee_htlc_tx`) presents the issue of counterparty's second-stage HTLC transactons malleable enough to opt-out from BIP125 replacement rules (the preimage path on the...