Two of the RGB extensions in this fork are applied unconditionally, so a channel carrying no RGB data still diverges from upstream rust-lightning. A node built on it cannot open or accept a plain BTC channel with a peer running stock LDK — the funding signature is rejected in both opener directions.
commitment_tx_base_weight in lightning/src/ln/chan_utils.rs adds the RGB OP_RETURN weight to every commitment transaction, so the two peers derive different initial commitment transactions. The OP_RETURN only exists on colored commitment transactions, so on a plain channel this is also just overpaying.rgb_payment is written as a mandatory suffix on every update_add_htlc, so a stock peer's vanilla HTLC is rejected as too short.
Both can be gated on the channel actually being colored, keyed off the rgb_asset already on FundingScope, leaving RGB behaviour unchanged.
Reproduced on regtest through rgb-lightning-node against ldk-node at rev 16eaa6f, in both directions — see RGB-Tools/rgb-lightning-node#148 for the node-level report and the original signet evidence.
Patch in #36. One open question there: rgb_payment needs a TLV type, and we picked an odd one outside the range the BOLTs may assign, following the convention already used here for skimmed_fee_msat (65537) and hold_htlc (75537). If RGB has a preferred allocation, we will match it.
Note the fix is breaking on the wire for deployed nodes — plain channels between mixed versions force-close, and RGB channels cannot parse each other's HTLCs — so it needs a coordinated upgrade.
Two of the RGB extensions in this fork are applied unconditionally, so a channel carrying no RGB data still diverges from upstream
rust-lightning. A node built on it cannot open or accept a plain BTC channel with a peer running stock LDK — the funding signature is rejected in both opener directions.commitment_tx_base_weightinlightning/src/ln/chan_utils.rsadds the RGB OP_RETURN weight to every commitment transaction, so the two peers derive different initial commitment transactions. The OP_RETURN only exists on colored commitment transactions, so on a plain channel this is also just overpaying.rgb_paymentis written as a mandatory suffix on everyupdate_add_htlc, so a stock peer's vanilla HTLC is rejected as too short.Both can be gated on the channel actually being colored, keyed off the
rgb_assetalready onFundingScope, leaving RGB behaviour unchanged.Reproduced on regtest through
rgb-lightning-nodeagainstldk-nodeat rev16eaa6f, in both directions — see RGB-Tools/rgb-lightning-node#148 for the node-level report and the original signet evidence.Patch in #36. One open question there:
rgb_paymentneeds a TLV type, and we picked an odd one outside the range the BOLTs may assign, following the convention already used here forskimmed_fee_msat(65537) andhold_htlc(75537). If RGB has a preferred allocation, we will match it.Note the fix is breaking on the wire for deployed nodes — plain channels between mixed versions force-close, and RGB channels cannot parse each other's HTLCs — so it needs a coordinated upgrade.