smite-ir: back channel_announcement with a real funding output

[devvaansh]

ChannelAnnouncementGenerator now creates, broadcasts, and confirms a 2-of-2 P2WSH funding transaction, and announces the short_channel_id it lands at along with the bitcoin keys its witness script commits to. The messages can then pass the on-chain UTXO validation performed by CLN and LND.

#155 resolved the short_channel_id half of this, but nothing ever emitted the operation, and the generator picked its bitcoin keys with generate_fresh, unrelated to any funding output. Deriving the funding pubkeys from the announced private keys closes the gap. No new operations are needed, since DerivePoint, CreateFundingTransaction, BroadcastTransaction, MineBlocks, and LookupShortChannelId already compose.

funding_satoshis and feerate_per_kw are emitted directly instead of picked, since generate_fresh(Amount) draws from the full u64 range and exceeds MAX_MONEY essentially always, which fails coin selection and aborts the program before the announcement is sent. Only the maximums are bounded: the funding amount is capped at BOLT 2's non-wumbo limit and the feerate is capped so fees don't exhaust the wallet. Both may still go to zero, since sign_and_broadcast_tx already falls back to mining dust outputs and below-min-relay-feerate transactions directly. OperationParamMutator can widen both afterwards.

FundingFlowGenerator picks those same two values with pick_variable and has the same full-range exposure, which seems worth a follow-up.

Tested with unit tests covering the ordering of the funding sequence, that each announced bitcoin key is the one behind the corresponding funding pubkey, and that the generated amounts stay in range. Not yet fuzzed against the targets; I'll follow up with coverage once I've run a campaign.

Ref: #71

[NishantBansal2003]

I think we should update the existing channel announcement generator to only create, broadcast, and mine the tx, and then use that SCID only. Otherwise, there isn't much difference between the two, and we can always test all the other cases with the current set of mutators. WDYT?

Also, does it make sense to include a full gossip generator that creates a fully funded channel announcement, followed by a node announcement and then a channel update for it?

[devvaansh]

I think we should update the existing channel announcement generator to only create, broadcast, and mine the tx, and >then use that SCID only. Otherwise, there isn't much difference between the two, and we can always test all the other >cases with the current set of mutators. WDYT?

i think Keeping both generators preserves cheap bogus-SCID testing without block-mining overhead.
since in a funded-only program, the short_channel_id is structurally immutable - LookupShortChannelId has no direct parameters, and InputSwapMutator/InstructionDeleteMutator bail when no other SCID producer exists in scope.
Relying solely on GeneratorInsertionMutator to introduce SCIDs drops arbitrary and boundary SCID exploration.

Also, does it make sense to include a full gossip generator that creates a fully funded channel announcement, followed >by a node announcement and then a channel update for it?

Yes, worth doing - NodeAnnouncementGenerator and ChannelUpdateGenerator pick their signing key via pick_variable, and after a channel announcement the most recent key in scope is bitcoin_sk_2, so they almost never sign with an actual node key and the messages don't link up.

[morehouse]

Concept ACK. I have no strong feelings on whether we keep the existing channel_announcement generator or adapt it into this one -- either approach has tradeoffs. But if we do experiment with #199, that might benefit from having more generators to choose subsets from.

[morehouse]

After thinking about it more, I think we should merge this generator into ChannelAnnouncementGenerator as @NishantBansal2003 suggested, since it's less code overall. And in general we try to have the generators produce validish flows and then let mutators exercise the invalid flows. The valid flows are harder to produce by mutators alone; the invalid flows are generally easy.

[devvaansh]

After thinking about it more, I think we should merge this generator into ChannelAnnouncementGenerator as @NishantBansal2003 suggested, since it's less code overall. And in general we try to have the generators produce validish flows and then let mutators exercise the invalid flows. The valid flows are harder to produce by mutators alone; the invalid flows are generally easy.

Makes sense - merged it into ChannelAnnouncementGenerator and dropped the separate one. Ends up a fair bit smaller since generators.rs doesn't need to change at all. One knock-on: instr_reorder_returns_false_on_single_or_no_act relied on this generator producing a single Act, so I've pointed it at NodeAnnouncementGenerator instead.