Matt Corallo

Ugh, yea, thanks. This is because the fuzzer can build two transactions that differ but have the same txid.

Tagging 0.2 since we want to include both full async signing and v2 channel establishment in it.

We ultimately decided to push both dual funding and async signing to 0.3.

If we're just gonna include this once, should we include a proof that the given header is at the given height with a coinbase merkle path? I dunno maybe that...

Ah, okay, I understood this to be about `update_fee`, indeed, rather than channel open and splicing. Indeed, IMO we should drop the reference to `update_fee`. However, I still don't think...

> but also enforces the type signature of everything touching P2PGossipSync at compile time. I mean this is generally true of Rust? If you have non-dynamic dispatch you have to...

> When I leave the type signature dyn UtxoLookup + Send + Sync, the compiler will shout at me at the point where I actually try to construct the GossipVerifier...

With this diff upstream: ```diff diff --git a/lightning-block-sync/src/gossip.rs b/lightning-block-sync/src/gossip.rs index f075cf7b2..083156baa 100644 --- a/lightning-block-sync/src/gossip.rs +++ b/lightning-block-sync/src/gossip.rs @@ -144,7 +144,7 @@ pub struct GossipVerifier< { source: Blocks, peer_manager_wake: Arc, - gossiper:...

Honestly maybe we should just bite the bullet and move the outbound message queue into `NetworkGraph` from `P2PGossipSync` and we can remove all the passing around of a reference to...

I'm not quite sure why that would be confusing? It wouldn't change the public API at all (aside from removing the need for the reference back to the P2PGossip entirely).