Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-16 📝 Original message: Joost Jager <joost.jager ...
📅 Original date posted:2022-02-16
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> Hi Rusty,
>
> Nice to see the proposal in more concrete terms. Few questions:
>
> - 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.
>>
>
> Could this work as a dynamic value too, similar to the minimum relay fee on
> L1?
I made the number up, so I'm not very attached to it. How would we
choose to scale it though? If nodes don't use the same value it makes
for wasted gossip (and minisketch-based gossip much harder).
>> 1. `tlv_stream`: `channel_update_v2_tlvs`
>>
> 2. types:
>> 1. type: 4 (`capacity`)
>> 2. data:
>> * [`tu64`:`satoshis`]
>>
>
> What does capacity mean exactly outside the context of a real channel? Will
> this be reduced to that maximum htlc amount that the nodes want to route,
> to save as much of the announceable budget as possible?
Yes, it's the old htlc_maximum_msat, but expressed in satoshis because
msat seems to finegrained?
> It is also the question of whether 10 x 10k channels should weigh as much
> on the budget as a 1 x 100k channel. A spammer may be able to do more harm
> with multiple smaller channels because there is more for the sender's
> pathfinding algorithms to explore. Maybe it doesn't matter as long as there
> is some mechanism to discourage spam.
Yes, I suggested a minimum cost to avoid 100k 1sat channels, I don't
know if we should be more sophisticated.
>> 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.
>
> If you'd increase the budget multiplier from 10 to 20, couldn't this be
> simplified to always applying the cost to both nodes?
Yes! I forgot that capacity doesn't have to be symmetrical; if I open a
giant channel with you, and you don't want to expose more UTXOs, you
just set your capacity to some lower value.
>> - 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).
>
> Same question about magic value and whether it can be dynamic.
Yes, 10ksat might be giant one day? We can change it naively with a
feature bit ("I use v2 capacity calcs"), or in some more finegrained
way, but what do we base it on?
Cheers!
Rusty.
📝 Original message:
Joost Jager <joost.jager at gmail.com> writes:
> Hi Rusty,
>
> Nice to see the proposal in more concrete terms. Few questions:
>
> - 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.
>>
>
> Could this work as a dynamic value too, similar to the minimum relay fee on
> L1?
I made the number up, so I'm not very attached to it. How would we
choose to scale it though? If nodes don't use the same value it makes
for wasted gossip (and minisketch-based gossip much harder).
>> 1. `tlv_stream`: `channel_update_v2_tlvs`
>>
> 2. types:
>> 1. type: 4 (`capacity`)
>> 2. data:
>> * [`tu64`:`satoshis`]
>>
>
> What does capacity mean exactly outside the context of a real channel? Will
> this be reduced to that maximum htlc amount that the nodes want to route,
> to save as much of the announceable budget as possible?
Yes, it's the old htlc_maximum_msat, but expressed in satoshis because
msat seems to finegrained?
> It is also the question of whether 10 x 10k channels should weigh as much
> on the budget as a 1 x 100k channel. A spammer may be able to do more harm
> with multiple smaller channels because there is more for the sender's
> pathfinding algorithms to explore. Maybe it doesn't matter as long as there
> is some mechanism to discourage spam.
Yes, I suggested a minimum cost to avoid 100k 1sat channels, I don't
know if we should be more sophisticated.
>> 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.
>
> If you'd increase the budget multiplier from 10 to 20, couldn't this be
> simplified to always applying the cost to both nodes?
Yes! I forgot that capacity doesn't have to be symmetrical; if I open a
giant channel with you, and you don't want to expose more UTXOs, you
just set your capacity to some lower value.
>> - 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).
>
> Same question about magic value and whether it can be dynamic.
Yes, 10ksat might be giant one day? We can change it naively with a
feature bit ("I use v2 capacity calcs"), or in some more finegrained
way, but what do we base it on?
Cheers!
Rusty.