Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-15 📝 Original message: Hi Rusty, Nice to see the ...
📅 Original date posted:2022-02-15
📝 Original message:
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?
> 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?
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.
> 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?
> - 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.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220215/1c100bd3/attachment.html>;
📝 Original message:
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?
> 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?
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.
> 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?
> - 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.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220215/1c100bd3/attachment.html>;