lightningdevkit
Some `Listen` implementations assert that each block is exactly after the previous
I think at least the sweeper, but we're supposed to allow back-to-back connections of the same block with more txn.
but we're supposed to allow back-to-back connections of the same block with more txn.
Not sure I follow what this means. Aren't we supposed to always give the full block in Listen?
No? https://docs.rs/lightning/latest/lightning/chain/trait.Listen.html#tymethod.filtered_block_connected
No? https://docs.rs/lightning/latest/lightning/chain/trait.Listen.html#tymethod.filtered_block_connected
But the API contract so far still has been that you supply all relevant transactions of a block as defined by Filter in one go, no?
Sure, but the Filter may update during a block-connected call, and then the call has to be made again with what is now the relevant transaction set. This has always been the case (with the one exception that if you provide all dependencies of matched transactions recursively you don't need to worry about it).
Sure, but the
Filtermay update during a block-connected call, and then the call has to be made again with what is now the relevant transaction set. This has always been the case (with the one exception that if you provide all dependencies of matched transactions recursively you don't need to worry about it).
Hmm, probably best to resume the discussion over on https://github.com/lightningdevkit/rust-lightning/pull/3876#discussion_r2174900665 then, because if that's the case IMO we should see how we can fix that. To me this requirement seems to complicate the Filter/Listen implementations quite a bit, i.e., you can't process the subscribed txids/outputs in rounds anymore, but you'd constantly have to double-check if something changed mid-processing, which likely would also have some performance impact?
I don't see why we need to block #3876 on making an unrelated further change to Filter/Listen? But I also don't see how we can possibly change this requirement. We could only document the "provide all dependencies of matched transactions in a block recursively" option, but that isn't practical in some cases, and will lead to re-scanning anyway, so we might as well tell them they can rescan based on Filter.
Sure, but the Filter may update during a block-connected call, and then the call has to be made again with what is now the relevant transaction set. This has always been the case (with the one exception that if you provide all dependencies of matched transactions recursively you don't need to worry about it).
Can't we address this by making sure a transaction matching a filter isn't broadcast until the filter is updated? AFAICT there shouldn't be a need to match on a transaction that previously confirmed in an already-connected block (i.e., doing a rescan/historical scan). So even if it gets updated mid block-connected, a transaction broadcast after the fact can only be included in the next block.
There's a tradeoff between Filter size and this requirement - if we want to register everything that we might want to hear about, we'd have to register most of the outputs of every possible commitment transaction with the Filter. I don't think its reasonable to go that far.
Doesn't this tradeoff only exist on non-anchor channels then? Since those are the only ones that allow a commitment and HTLC transaction confirm in the same block.
Mmm, that's a good point, yes. Not 100% sure "lightning commitment txn will only ever have outputs that are 1 CSV" is a great assumption to make at the API layer, but we definitely could for anchor channels.
This is gonna have to be an 0.2.1 thing. Its a bug but not a regression so we'll backport it anyway.