Antoine Riard

If this is same than #27630 at least one benefit for second-layer and Bitcoin applications can be too document tx relay rate, see https://github.com/bitcoin/bitcoin/pull/27630#issuecomment-1548841340

https://github.com/lightning/bolts/pull/1136#issuecomment-2389806150

@rrybarczyk, this one should be a good first issue if you're looking for something to hack on :)

@varunsrin Yes this one is still relevant. You should check duplicate_htlc_test, test_duplicate_htlc_different_direction_onchain, test_duplicate_payment_hash_one_failure_one_success but IIRC they don't test this general case. Also you may have a look on https://github.com/rust-bitcoin/rust-lightning/issues/240, going...

See ongoing ML discussion : https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002505.html

@rustyrussell Can I ask you a simple question in a cold and polite fashion ? As I think you're still the older active contributor to the lightning protocol so far....

I think `mempoolfullrbf` could be left in core, if some users wishes to have first-seen of received transactions. E.g for lightning type `option_zeroconf` where double spend can only happen if...

@petertodd On the lightning side, in a world where as a node you have a scarcity of UTXO to allocate seeing locally a record of transaction-relay policy and consensus transaction,...

if one can go and publish on the mailing list in which core release this is expected to land and indicates the expected deployment timelines for the downstream softwares. learning...

There is one more item to check: - Ensure the level of fee-bumping reserves is correct for the channel exposure and reasonable worst-historical mempool (you can assign this one to...