Matt Morehouse

Concept ACK. > It represents the timeline of the block, maybe I should try a different graph, but the block is always sent by the `BlockBeat`. Yeah, the diagram is...

Cool. I think this could be used to implement https://github.com/lightningnetwork/lnd/issues/8166. We would just need to make sure that the initial block is distributed by `BlockBeat` before the peer manager starts.

Does `TxPublisher` need to process the block before `UtxoSweeper`? Suppose a conflicting transaction confirms at block `X` (e.g., https://github.com/lightningnetwork/lnd/issues/8737). If `UtxoSweeper` processes block `X` first, it won't know about any...

> The issue with `TxPublisher -> UtxoSweeper` means every tx will be broadcast at X+1. I don't think so? `TxPublisher.Broadcast` will still do the initial broadcast immediately. > Meanwhile, once...

> Would you be interested in rebasing it and then I can add it to my review queue? Eventually, maybe. It's been awhile, so I probably need to self-review it...

I'm not sure I understand the motivation for this change. It seems like the goal is to simplify `readHandler`, but then this new abstract message router seems to increase complexity...

> So with #8345 we _should_ no longer be attempting to _publish_ (which may lock up UTXOs in the wallet) anything that violates default policy rules. Keeping the UTXOs unlocked...

I'm not opposed to reducing the scope of `Brontide`, but I'm not sure this PR is a good tradeoff. The switch statement in `readHandler` is currently ~100 lines of simple...

@yyforyongyu Is this something we can add to https://github.com/lightningnetwork/lnd/pull/8424, or would you rather make this change separately?

> I don't think we need polling for `minfeefilter`, just like we don't poll for `mempoolminfee`. By the time we broadcast the tx, two scenarios may exist, > > *...