Elias Rohrer
Elias Rohrer
I plan to pick this up eventually.
> I think the only real TODO here is to include channel capacities in RGS data. Hmm, right. I wonder if it would make sense to hold off on it...
> its not entirely clear to me what the right DoS limits are here, and we'll have to figure them out in a general sense, FWIW, given that we start...
> Played with this, I don't really actually think its worth it as we'd have to first split out all our TLV and serialization logic into some kind of lightning-ser...
> Turns out this it the only async -> sync -> (blocked) async inversion we have in `ldk-sample`, I'm not quite sure this is true, due to `ChangeDestinationSource` being used...
> Grr, right. I suppose we could fix that with `OutputSweeper` having a fixed payout address (or a list) that is pre-configured if users want to avoid that inversion. Still...
Just discussed offline that we try to prioritize this for 0.2, i.e., making `ChangeDestinationSource`/`WalletSource` async-optional and have the sweeper and `BumpTransactionEventHandler` driven by the `BackgroundProcessor`.
Seems this needs a rebase now.
Going ahead landing this since it has 3 ACKs.
As mentioned on Discord: Yes, this is likely due to our routing algorithm internally first collecting candidates. As we keep track of the overall used liquidity in the first step...