{"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-16\n📝 Original message:\nJoost Jager \u003cjoost.jager at gmail.com\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e Nice to see the proposal in more concrete terms. Few questions:\n\u003e\n\u003e - The total proved utxo value (not counting any utxos which are spent)\n\u003e\u003e   is multiplied by 10 to give the \"announcable_channel_capacity\" for that\n\u003e\u003e node.\n\u003e\u003e\n\u003e\n\u003e Could this work as a dynamic value too, similar to the minimum relay fee on\n\u003e L1?\n\nI made the number up, so I'm not very attached to it.  How would we\nchoose to scale it though?  If nodes don't use the same value it makes\nfor wasted gossip (and minisketch-based gossip much harder).\n\n\u003e\u003e 1. `tlv_stream`: `channel_update_v2_tlvs`\n\u003e\u003e\n\u003e 2. types:\n\u003e\u003e     1. type: 4 (`capacity`)\n\u003e\u003e     2. data:\n\u003e\u003e         * [`tu64`:`satoshis`]\n\u003e\u003e\n\u003e\n\u003e What does capacity mean exactly outside the context of a real channel? Will\n\u003e this be reduced to that maximum htlc amount that the nodes want to route,\n\u003e to save as much of the announceable budget as possible?\n\nYes, it's the old htlc_maximum_msat, but expressed in satoshis because\nmsat seems to finegrained?\n\n\u003e It is also the question of whether 10 x 10k channels should weigh as much\n\u003e on the budget as a 1 x 100k channel. A spammer may be able to do more harm\n\u003e with multiple smaller channels because there is more for the sender's\n\u003e pathfinding algorithms to explore. Maybe it doesn't matter as long as there\n\u003e is some mechanism to discourage spam.\n\nYes, I suggested a minimum cost to avoid 100k 1sat channels, I don't\nknow if we should be more sophisticated.\n\n\u003e\u003e     1. type: 5 (`cost`)\n\u003e\u003e     2. data:\n\u003e\u003e        * [`u16`:`cltv_expiry_delta`]\n\u003e\u003e        * [`u32`:`fee_proportional_millionths`]\n\u003e\u003e        * [`tu32`:`fee_base_msat`]\n\u003e\u003e     1. type: 6 (`min_msat`)\n\u003e\u003e     2. data:\n\u003e\u003e         * [`tu64`:`min_htlc_sats`]\n\u003e\u003e\n\u003e\u003e - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be\n\u003e\u003e   used in onion_messages, and a one bit stolen for the `claim` flag.\n\u003e\n\u003e If you'd increase the budget multiplier from 10 to 20, couldn't this be\n\u003e simplified to always applying the cost to both nodes?\n\nYes!  I forgot that capacity doesn't have to be symmetrical; if I open a\ngiant channel with you, and you don't want to expose more UTXOs, you\njust set your capacity to some lower value.\n\n\u003e\u003e - A channel is not considered to exist until both peers have sent a\n\u003e\u003e   channel_update_v2, at least one of which must set the `claim` flag.\n\u003e\u003e - If a node sets `claim`, the capacity of the channel is subtracted from\n\u003e\u003e   the remaining announcable_channel_capacity for that node (minimum\n\u003e\u003e   10,000 sats).\n\u003e\n\u003e Same question about magic value and whether it can be dynamic.\n\nYes, 10ksat might be giant one day?  We can change it naively with a\nfeature bit (\"I use v2 capacity calcs\"), or in some more finegrained\nway, but what do we base it on?\n\nCheers!\nRusty."}