2023 Mar 27

• Review

  • What are temporary_channel_ids?

    • Channel id - 32 bytes, first 30 bytes are funding txid, last 2 bytes are output index (all big endian). This is created upon a funding_created message. Interesting to note this does not include the block height like short_channel_id as it’s created before the funding tx has been confirmed.

    • temporary_channel_id is used to identify a channel before the funding tx is signed, i.e. upon an open_channel message.

    • On a Channel object in rust-lightning, upon creation/channel opn channel_id is said to a temporary_channel_id, i.e. a random 32 bytes, and then upon the funding tx being signed, it gets changed to the actual channel_id.

  • What are user_channel_id and former_temporary_channel_id in Event::ChannelPending for?

    • user_channel_id: no special meaning and exists only to allow users to have a persistent identifier of a channel. Exists in other forms of channel data in rust-lightning. Makes it easier for the user to identify, makes sense to be included in this event.

    • former_temporary_channel_id: Why is this here?

  • Was confused by this comment that talked about pushing the event after the outbound channel end broadcasting/completing the channel monitor update. Still a little confused on the wording of waiting for the “broadcast" because I don’t think there’s any hook that would notify ChannelManager about seeing the transaction in the mempool or getting a message from the counterparty saying they broadcasted.

    • Generally I would imagine this would mean putting this in handle_monitor_update_completion? Actually there’s a function ChannelManager::handle_channel_resumption which is more general (that is used inside of handle_monitor_update_completion, but also in channel_reestablish) that does several checks (including broadcasting the funding tx ourselves) once a channel is resumed or a channel monitor update completes, which makes more sense to push the ChannelPending event here.

  • How do 0conf channels work in rust-lightning?

• Review

  • Summary

    • Currently as a part of the onion payload the user only exposed data that’s received is payment secret. We want to generalize this to also be able to include payment metadata, and eventually custom TLVs.

    • I remember coming across “contexts” in the repo and not knowing what they were. Just read BOLT 9 for the first time. Feature bits are communicated in certain messages where it makes sense as a part of the payload (mainly init messages, gossip announcements, and invoices - these are the different contexts for where certain feature bits are necessary). Bits are added to the protocol in pairs, documented in BOLT 9 (even bit means requires, odd means optional, similar to how TLV types work). This makes the protocol very flexible in allowing nodes to implement new features and signal to others their support without anything special.

    • Looked at the [InvoiceBuilder](https://docs.rs/lightning-invoice/0.22.0/lightning_invoice/struct.InvoiceBuilder.html) for the first time and it’s so cool. They use type parameters to conditionally expose functions to the user based on the state of the invoice, so for example, it won’t compile if you try to call .build() on an InvoiceBuilder that hasn’t had certain fields set.

      • PhantomData can be used inside of structs if you want to use lifetimes or type parameters for compile time checks without any of the struct’s fields actually using the lifetime/type parameter (as by default rust doesn’t allow unused lifetimes/type params).