{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-13\n📝 Original message:\nHi all,\n\n        I've floated this idea before, but this is a more concrete\nproposal for a \"v2\" gossip protocol.\n\nIt assumes x-only pubkeys (aka point32) and BIP-340 signatures, and uses\nmodern TLVs for all optional or extensible fields.  Timestamps are\nreplaced with block heights.\n\n1. Nodes send out weekly node_announcement_v2, proving they own some\n   UTXOs.\n2. This entitles them to broadcast channels, using channel_update_v2; a\n   channel_update_v2 from both peers means the channel exists.\n3. This uses UTXOs for anti-spam, but doesn't tie them to channels\n   directly.\n4. Future ZKP proofs are could be added.\n\n1. type: 271 (`node_announcement_v2`)\n2. data:\n    * [`bip340sig`:`signature`]\n    * [`point32`:`node_id`]\n    * [`u32`:`blockheight`]\n    * [`node_announcement_v2_tlvs`:`tlvs`]\n\n1. `tlv_stream`: `node_announcement_v2_tlvs`\n2. types:\n    1. type: 2 (`features`)\n    2. data:\n        * [`...*byte`:`featurebits`]\n    1. type: 3 (`chain_hash`)\n    2. data:\n        * [`chain_hash`:`chain`]\n    1. type: 4 (`taproot_utxo_proofs`)\n    2. data:\n        * [`...*taproot_utxo_proof`:`proofs`]\n    1. type: 6 (`legacy_utxo_proofs`)\n    2. data:\n        * [`...*legacy_utxo_proof`:`proofs`]\n    1. type: 127 (`ipv4_addresses`)\n    2. data:\n        * [`...*ipv4`:`addresses`]\n    1. type: 129 (`ipv6_addresses`)\n    2. data:\n        * [`...*ipv6`:`addresses`]\n    1. type: 131 (`torv3_addresses`)\n    2. data:\n        * [`...*torv3`:`addr`]\n# Maybe alias, color, etc?\n\nTaproot proofs are a signature of the v1 output over the `node_id`,\n`utxo` and `blockheight` with prefix \"lightingtaproot_utxo_proofsig\"\n(using the tagged signatures as per BOLT12). (FIXME: what about\ntapscripts?).\n\nLegacy proofs are two signatures, similar to the existing\nchannel_announcement.\n\n1. subtype: `taproot_utxo_proof`\n2. data:\n    * [`short_channel_id`:`utxo`]\n    * [`signature`:`sig`]\n\n1. subtype: `legacy_utxo_proof`\n2. data:\n    * [`short_channel_id`:`utxo`]\n    * [`point`:`bitcoin_key_1`]\n    * [`point`:`bitcoin_key_2`]\n    * [`signature`:`sig_1`]\n    * [`signature`:`sig_2`]\n\n- node_announcement_v2 are discarded after a week (1000 blocks).\n- If two node_announcement_v2 claim the same UTXO, use the first seen,\n  discard any others.\n- Nodes do not need to monitor existence of UTXOs after initial check (since\n  they will automatically prune them after a week).\n- The total proved utxo value (not counting any utxos which are spent)\n  is multiplied by 10 to give the \"announcable_channel_capacity\" for that node.\n\n1. type: 273 (`channel_update_v2`)\n2. data:\n    * [`bip340sig`:`signature`]\n    * [`point32`:`local_node_id`]\n    * [`point32`:`remote_node_id`]\n    * [`u32`:`blockheight`]\n    * [`u32`:`channel_id_and_claimant`]\n    * [`channel_update_v2_tlvs`:`tlvs`]\n\n1. `tlv_stream`: `channel_update_v2_tlvs`\n2. types:\n    1. type: 2 (`features`)\n    2. data:\n        * [`...*byte`:`featurebits`]\n    1. type: 3 (`chain_hash`)\n    2. data:\n        * [`chain_hash`:`chain`]\n    1. type: 4 (`capacity`)\n    2. data:\n        * [`tu64`:`satoshis`]\n    1. type: 5 (`cost`)\n    2. data:\n       * [`u16`:`cltv_expiry_delta`]\n       * [`u32`:`fee_proportional_millionths`]\n       * [`tu32`:`fee_base_msat`]\n    1. type: 6 (`min_msat`)\n    2. data:\n        * [`tu64`:`min_htlc_sats`]\n\n- `channel_id_and_claimant` is a 31-bit per-node channel_id which can be\n  used in onion_messages, and a one bit stolen for the `claim` flag.\n- A channel is not considered to exist until both peers have sent a\n  channel_update_v2, at least one of which must set the `claim` flag.\n- If a node sets `claim`, the capacity of the channel is subtracted from\n  the remaining announcable_channel_capacity for that node (minimum\n  10,000 sats).\n- If there is insufficient total `announcable_channel_capacity` for a\n  node, it is used by the lower `channel_id`s first.\n\nImplications\n------------\n\nThis simplifies gossip, requiring only two messages instead of three,\nand reducing the UTXO validation requirements to per-node instead of\nper-channel.  We can use a convention that a channel_update_v2 with no\n`capacity` is a permanent close.\n\nWe might want to add a taproot_utxo_delegated_proof where UTXOs can\nsign over to another key, so cold storage only needs to sign once, and\nthe other key can sign weekly.\n\nIt also allows \"leasing\" of UTXOs: you could pay someone to sign their\nUTXO for your node_announcement, with some level of trust.  They could\nspend the UTXO, which gives you a slow degredation as new nodes don't\naccept your channels but existing nodes don't check until it's due for a\nrefresh).  Or they could sign one UTXO for multiple node_announcements,\nwhich is why preference is given to the first-seen.  But it's a weekly\nbusiness so there's incentive for them not to.\n\nBetween nodes there's the question of \"who claims this new channel?\",\nwhich I didn't address here.  Opener claims is logical, but leaks\ninformation (though you could definitely pay for the peer to claim it).\nWith dual-funding, it's more complex (some kind of proportional coinflip\nprotocol is possible), but basically you can always wait for your peer,\nand if they don't set the claim bit you can.\n\nCheers!\nRusty."}