Hi Rusty, > Timestamps are replaced with block heights.
This is a conceptually small change, but would actually make things like rate limiting updates for implementations easier and more uniform. A simple rule would be only allowing an update per block, which cuts down a lot on potential chatter traffic, but maybe it's _too_ restrictive? Based on my network observations, these days some many power user nodes more aggressively update their fee schedules in response to liquidity imbalances or as an attempt to incentive usage of some channels vs others. > 1. Nodes send out weekly node_announcement_v2, proving they own some > UTXOs. If a node doesn't send out this announcement, then will others start to ignore their "channels"? > 3. This uses UTXOs for anti-spam, but doesn't tie them to channels > directly. As I hinted a bit in prior discussion, and also my recent ML [1] post outlining a possible "do most of the same things" stop gap, this has the potentially undesirable effect of allowing parties on the network to utilize _existing_ outputs to advertise false channels and inflate the "total network capacity" metric. We'd effectively be moving away from "Alice and Bob have N BTC of bound capacity between them to", "Bob has N BTC he can use for signing these proofs". Also while we're at it, why not add a merkle proof here (independent of which direction we go with) which makes it possible for constrained/mobile nodes to more easily verify gossip data (could be an optional query flag). > FIXME: what about tapscripts? Yeah, one side effect of moving to nodes advertising how much BTC they can sign w/ vs the _actual_ BTC they have in "channels", is that to extend validation here, the verifiers would need to fully verify possible script path spends (assuming a scenario where a NUMs point is used as the internal key). > Legacy proofs are two signatures, similar to the existing > channel_announcement. Why not musig2? We'd be able to get away with just a single sig with this modified `node_announcement_v2` and if we go the `channel_announcement2` route, we'd be able to compress those 4 sigs into one. > - If two node_announcement_v2 claim the same UTXO, use the first seen, > discard any others. So then this would mean that nodes that _actually_ have a channel between them can't _individually_ claim the capacity? > - node_announcement_v2 are discarded after a week (1000 blocks). - Nodes > do not need to monitor existence of UTXOs after initial check (since they > will automatically prune them after a week). A side effect of this would be _continual_ gossip churn in order to keep channels alive. Today we do have the 2 week `channel_update` heart beat, but channel updates are relatively small compared to this `node_announcement_v2` message. > - The total proved utxo value (not counting any utxos which are spent) is > multiplied by 10 to give the "announcable_channel_capacity" for that node. I don't see how this is at all useful in practice. We'd end up with inflated numbers for the total node capacity, and path finding would be more difficult as it isn't clear exactly how large an HTLC I can send over the "channel". Sure there's the existence of max_htlc, but in that case why add this "leverage" factor in the first place? > 1. type: 273 (`channel_update_v2`) This seems to allow the advertisement of channels which aren't actually anchored in the chain, which I *think* is a cool thing to have? On the other hand, the graph at the _edge_ level would be far more dynamic than it is today (Bob can advertise an entirely distinct topology from one day to another). Would need to think about the implications here for path finding algorithms and nodes that want to maintain an update to date view of the network... > - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be > used in onion_messages, and a one bit stolen for the `claim` flag. Where would this `channel_id` be derived from? FWIW, using this value in the onion means we get a form of pubkey based routing [3] depending on how these are derived. > This simplifies gossip, requiring only two messages instead of three, > and reducing the UTXO validation requirements to per-node instead of > per-channel. I'm not sure this would actually _simplify_ gossip in practice, given that we'd be moving to a channel graph that isn't entirely based in the reality of what's routable, and would be far more dynamic than it is today. > We can use a convention that a channel_update_v2 with no `capacity` is a > permanent close. On the neutrino side, we tried to do something where if we see both channels be disabled, then we'd mark the channel as closed. But in practice if you're not syncing _every_ channel update every transmitted, then you'll end up actually missing them. > It also allows "leasing" of UTXOs: you could pay someone to sign their > UTXO for your node_announcement, with some level of trust. I'm not sure this is entirely a *good* thing, as the graph becomes more decoupled with the _actual_ on-chain relationships... -- Laolu [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html [2]: https://github.com/lightning/bolts/pull/814 On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell <ru...@blockstream.com> wrote: > Hi all, > > I've floated this idea before, but this is a more concrete > proposal for a "v2" gossip protocol. > > It assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses > modern TLVs for all optional or extensible fields. Timestamps are > replaced with block heights. > > 1. Nodes send out weekly node_announcement_v2, proving they own some > UTXOs. > 2. This entitles them to broadcast channels, using channel_update_v2; a > channel_update_v2 from both peers means the channel exists. > 3. This uses UTXOs for anti-spam, but doesn't tie them to channels > directly. > 4. Future ZKP proofs are could be added. > > 1. type: 271 (`node_announcement_v2`) > 2. data: > * [`bip340sig`:`signature`] > * [`point32`:`node_id`] > * [`u32`:`blockheight`] > * [`node_announcement_v2_tlvs`:`tlvs`] > > 1. `tlv_stream`: `node_announcement_v2_tlvs` > 2. types: > 1. type: 2 (`features`) > 2. data: > * [`...*byte`:`featurebits`] > 1. type: 3 (`chain_hash`) > 2. data: > * [`chain_hash`:`chain`] > 1. type: 4 (`taproot_utxo_proofs`) > 2. data: > * [`...*taproot_utxo_proof`:`proofs`] > 1. type: 6 (`legacy_utxo_proofs`) > 2. data: > * [`...*legacy_utxo_proof`:`proofs`] > 1. type: 127 (`ipv4_addresses`) > 2. data: > * [`...*ipv4`:`addresses`] > 1. type: 129 (`ipv6_addresses`) > 2. data: > * [`...*ipv6`:`addresses`] > 1. type: 131 (`torv3_addresses`) > 2. data: > * [`...*torv3`:`addr`] > # Maybe alias, color, etc? > > Taproot proofs are a signature of the v1 output over the `node_id`, > `utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig" > (using the tagged signatures as per BOLT12). (FIXME: what about > tapscripts?). > > Legacy proofs are two signatures, similar to the existing > channel_announcement. > > 1. subtype: `taproot_utxo_proof` > 2. data: > * [`short_channel_id`:`utxo`] > * [`signature`:`sig`] > > 1. subtype: `legacy_utxo_proof` > 2. data: > * [`short_channel_id`:`utxo`] > * [`point`:`bitcoin_key_1`] > * [`point`:`bitcoin_key_2`] > * [`signature`:`sig_1`] > * [`signature`:`sig_2`] > > - node_announcement_v2 are discarded after a week (1000 blocks). > - If two node_announcement_v2 claim the same UTXO, use the first seen, > discard any others. > - Nodes do not need to monitor existence of UTXOs after initial check > (since > they will automatically prune them after a week). > - The total proved utxo value (not counting any utxos which are spent) > is multiplied by 10 to give the "announcable_channel_capacity" for that > node. > > 1. type: 273 (`channel_update_v2`) > 2. data: > * [`bip340sig`:`signature`] > * [`point32`:`local_node_id`] > * [`point32`:`remote_node_id`] > * [`u32`:`blockheight`] > * [`u32`:`channel_id_and_claimant`] > * [`channel_update_v2_tlvs`:`tlvs`] > > 1. `tlv_stream`: `channel_update_v2_tlvs` > 2. types: > 1. type: 2 (`features`) > 2. data: > * [`...*byte`:`featurebits`] > 1. type: 3 (`chain_hash`) > 2. data: > * [`chain_hash`:`chain`] > 1. type: 4 (`capacity`) > 2. data: > * [`tu64`:`satoshis`] > 1. type: 5 (`cost`) > 2. data: > * [`u16`:`cltv_expiry_delta`] > * [`u32`:`fee_proportional_millionths`] > * [`tu32`:`fee_base_msat`] > 1. type: 6 (`min_msat`) > 2. data: > * [`tu64`:`min_htlc_sats`] > > - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be > used in onion_messages, and a one bit stolen for the `claim` flag. > - A channel is not considered to exist until both peers have sent a > channel_update_v2, at least one of which must set the `claim` flag. > - If a node sets `claim`, the capacity of the channel is subtracted from > the remaining announcable_channel_capacity for that node (minimum > 10,000 sats). > - If there is insufficient total `announcable_channel_capacity` for a > node, it is used by the lower `channel_id`s first. > > Implications > ------------ > > This simplifies gossip, requiring only two messages instead of three, > and reducing the UTXO validation requirements to per-node instead of > per-channel. We can use a convention that a channel_update_v2 with no > `capacity` is a permanent close. > > We might want to add a taproot_utxo_delegated_proof where UTXOs can > sign over to another key, so cold storage only needs to sign once, and > the other key can sign weekly. > > It also allows "leasing" of UTXOs: you could pay someone to sign their > UTXO for your node_announcement, with some level of trust. They could > spend the UTXO, which gives you a slow degredation as new nodes don't > accept your channels but existing nodes don't check until it's due for a > refresh). Or they could sign one UTXO for multiple node_announcements, > which is why preference is given to the first-seen. But it's a weekly > business so there's incentive for them not to. > > Between nodes there's the question of "who claims this new channel?", > which I didn't address here. Opener claims is logical, but leaks > information (though you could definitely pay for the peer to claim it). > With dual-funding, it's more complex (some kind of proportional coinflip > protocol is possible), but basically you can always wait for your peer, > and if they don't set the claim bit you can. > > Cheers! > Rusty. > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev