Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-10-26 📝 Original message: Rusty Russell <rusty at ...
📅 Original date posted:2020-10-26
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
>> This is in stark contrast to the leader-based approach, where both
>> parties can just keep queuing updates without silent times to
>> transferring the token from one end to the other.
>
> You've swayed me, but it needs new wire msgs to indicate "these are
> your proposals I'm reflecting to you".
>
> OTOH they don't need to carry data, so we can probably just have:
>
> update_htlcs_ack:
> * [`channel_id`:`channel_id`]
> * [`u16`:`num_added`]
> * [`num_added*u64`:`added`]
> * [`u16`:`num_removed`]
> * [`num_removed*u64`:`removed`]
>
> update_fee can stay the same.
>
> Thoughts?
So this would pretty much be a batch-ack, sent after a whole series of
changes were proposed to the leader, and referenced by their `htlc_id`,
correct? This is one optimization step further than what I was thinking,
but it can work. My proposal would have been to either reflect the whole
message (nodes need to remember proposals they've sent anyway in case of
disconnects, so matching incoming changes with the pending ones should
not be too hard), or send back individual acks, containing the hash of
the message if we want to safe on bytes transferred. Alternatively we
could also use reference the change by its htlc_id.
The latter however means that we are now tightly binding the
linearization protocol (in which order should the changes be applied)
with the internals of these changes (namely we look into the change, and
reference the htlc_id). My goal ultimately is introduce a better
layering between the change proposal/commitment scheme, and the
semantics of the the individual changes ("which order" vs. "what").
I wonder what the performance increase of the batching would be compared
to just acking each update individually. My expectation would be that in
most cases we'd be acking a batch of size 1 :-)
Personally I think just reflecting the changes as a whole, interleaving
my updates with yours is likely the simplest protocol, with the least
implied state that can get out of sync, and cause nodes to drift apart
like we had a number of times ("bad signature" anyone ^^). And looking
(much much) further it is also a feasible protocol for multiparty
channels with eltoo or similar constructions, where the leader
reflecting my own changes back to me is more of a special case than the
norm.
Cheers,
Christian
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> writes:
>> This is in stark contrast to the leader-based approach, where both
>> parties can just keep queuing updates without silent times to
>> transferring the token from one end to the other.
>
> You've swayed me, but it needs new wire msgs to indicate "these are
> your proposals I'm reflecting to you".
>
> OTOH they don't need to carry data, so we can probably just have:
>
> update_htlcs_ack:
> * [`channel_id`:`channel_id`]
> * [`u16`:`num_added`]
> * [`num_added*u64`:`added`]
> * [`u16`:`num_removed`]
> * [`num_removed*u64`:`removed`]
>
> update_fee can stay the same.
>
> Thoughts?
So this would pretty much be a batch-ack, sent after a whole series of
changes were proposed to the leader, and referenced by their `htlc_id`,
correct? This is one optimization step further than what I was thinking,
but it can work. My proposal would have been to either reflect the whole
message (nodes need to remember proposals they've sent anyway in case of
disconnects, so matching incoming changes with the pending ones should
not be too hard), or send back individual acks, containing the hash of
the message if we want to safe on bytes transferred. Alternatively we
could also use reference the change by its htlc_id.
The latter however means that we are now tightly binding the
linearization protocol (in which order should the changes be applied)
with the internals of these changes (namely we look into the change, and
reference the htlc_id). My goal ultimately is introduce a better
layering between the change proposal/commitment scheme, and the
semantics of the the individual changes ("which order" vs. "what").
I wonder what the performance increase of the batching would be compared
to just acking each update individually. My expectation would be that in
most cases we'd be acking a batch of size 1 :-)
Personally I think just reflecting the changes as a whole, interleaving
my updates with yours is likely the simplest protocol, with the least
implied state that can get out of sync, and cause nodes to drift apart
like we had a number of times ("bad signature" anyone ^^). And looking
(much much) further it is also a feasible protocol for multiparty
channels with eltoo or similar constructions, where the leader
reflecting my own changes back to me is more of a special case than the
norm.
Cheers,
Christian