Antoine Riard

I think one more sub-category to track is the feedback collected on how package relay/nversion=3 are fitting multi-party applications and contracting protocols - Lightning: legacy channels / anchor output /...

If the state-of-art implementation of BIP331 can be linked here or in the BIP (Like there is https://github.com/glozow/bitcoin/pull/8 and https://github.com/glozow/bitcoin/pull/9) ? From a reviewer perspective, ideally it’s better to have...

From a reviewing standpoint on #27742, I think it would benefit if the release aim for current package version (BIP331 + nversion=3 policy regime) is explicitly bounded to Lightning time-sensitive...

Excerpt from #29319: > Replacing CPFP carveout (with a new sibling-replacement policy) > We can provide a way to achieve the goals of the CPFP carveout rule even if the...

@glozow @sdaftuar @instagibbs can you re-explain why this PR is needed given LN commitment transactions can achieve the same tx-relay propagation benefits without this change ? There is functional alternative...

> You only checked part of the code. What actually matters here is rather the "watch" we set of the funding outpoint, which makes us spend from whatever commit (local/remote/next-remote)...

Additionally, I did extend the `test_v3_sibling_eviction` new test here https://github.com/bitcoin/bitcoin/commit/04fdc0a77f70a998a433a3839c807422bc2e3bfa. Sibling eviction adds a new replacement cycling vector, where you can from now on throw out of network mempools your...

> Yes, but there are potentially 3 instances of that actor running in parallel, one for each commitment transaction. So one of them will match what is in our mempool...

> As the delving post says, it's beneficial to accept a new high feerate child of a v3 tx - without busting the descendant limits - instead of being stuck...

> Yes, as long as we see any commitment in our mempool, we'll spend it. If we don't see it in our mempool, we cannot do anything though. Better if...