{"type":"rich","version":"1.0","title":"Joost Jager [ARCHIVE] wrote","author_name":"Joost Jager [ARCHIVE] (npub1as…wfqmx)","author_url":"https://yabu.me/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-15\n📝 Original message:\nHi Rusty,\n\nNice to see the proposal in more concrete terms. Few questions:\n\n- The total proved utxo value (not counting any utxos which are spent)\n\u003e   is multiplied by 10 to give the \"announcable_channel_capacity\" for that\n\u003e node.\n\u003e\n\nCould this work as a dynamic value too, similar to the minimum relay fee on\nL1?\n\n\n\u003e 1. `tlv_stream`: `channel_update_v2_tlvs`\n\u003e\n2. types:\n\u003e     1. type: 4 (`capacity`)\n\u003e     2. data:\n\u003e         * [`tu64`:`satoshis`]\n\u003e\n\nWhat does capacity mean exactly outside the context of a real channel? Will\nthis be reduced to that maximum htlc amount that the nodes want to route,\nto save as much of the announceable budget as possible?\n\nIt is also the question of whether 10 x 10k channels should weigh as much\non the budget as a 1 x 100k channel. A spammer may be able to do more harm\nwith multiple smaller channels because there is more for the sender's\npathfinding algorithms to explore. Maybe it doesn't matter as long as there\nis some mechanism to discourage spam.\n\n\n\u003e     1. type: 5 (`cost`)\n\u003e     2. data:\n\u003e        * [`u16`:`cltv_expiry_delta`]\n\u003e        * [`u32`:`fee_proportional_millionths`]\n\u003e        * [`tu32`:`fee_base_msat`]\n\u003e     1. type: 6 (`min_msat`)\n\u003e     2. data:\n\u003e         * [`tu64`:`min_htlc_sats`]\n\u003e\n\u003e - `channel_id_and_claimant` is a 31-bit per-node channel_id which can be\n\u003e   used in onion_messages, and a one bit stolen for the `claim` flag.\n\u003e\n\nIf you'd increase the budget multiplier from 10 to 20, couldn't this be\nsimplified to always applying the cost to both nodes?\n\n\n\u003e - A channel is not considered to exist until both peers have sent a\n\u003e   channel_update_v2, at least one of which must set the `claim` flag.\n\u003e - If a node sets `claim`, the capacity of the channel is subtracted from\n\u003e   the remaining announcable_channel_capacity for that node (minimum\n\u003e   10,000 sats).\n\u003e\n\nSame question about magic value and whether it can be dynamic.\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220215/1c100bd3/attachment.html\u003e"}