Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-31 📝 Original message: Hi Z, Thanks as usual for ...
📅 Original date posted:2020-08-31
📝 Original message:
Hi Z,
Thanks as usual for your thoughtful comments
I agree with you that there is no improvement in complexity in the formal sense.
I do believe it is an improvement in conceptual complexity.
At least, I am able to keep all the moving parts in my head at the
same time whereas I struggle sometimes with the current BOLT spec.
Unfortunately, while thinking about the above statement I realised
there is worse storage complexity.
In order to punish a revoked commitment transaction efficiently you
need to extract the publication secret.
But in order to do that you need to keep around the encrypted
signature (a.k.a adaptor signature) **for that particular commitment
transaction**.
This means you have O(n) storage, unlike the present spec which has
O(1) by deriving the previously revealed revocation secret from the
present one (this can't be done with adaptor signatures).
This doesn't seem to be addressed in the original work.
Yikes! This might be a fatal flaw to this proposal unless it can be addressed.
> When we have "the same" transaction on both sides, however, we need to synchronize between the two sides.
Can you elaborate on this? I think you can carry on using the same
BOLT 2 update protocol within this channel system.
The txids being the same for both parties sometimes seems to be incidental.
It may be advantageous to use an alternative protocol that forces a
synchronization of the commitment transactions but I don't *think* it
is a requirement.
I guess you would need to sync in Decker-Russell-Osuntokun because it
needs an objective ordering of commitment transactions.
That is seemingly not the case here though
LL
On Tue, Aug 25, 2020 at 10:45 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Lloyd,
>
> I think this is excellent work overall.
>
> With that said...
>
>
> > - It is more elegant as there are half the number of possible transactions. I
> > expect this will follow through to reduced implementation complexity and maybe
> > make it easier to explain as well.
>
> I am not sure the complexity will be reduced all that much.
>
> Currently:
>
> * We provide a partial signature for the other side for their commitment transaction.
> * We keep our own commitment transaction and the partial signature we receive from the other side.
>
> The node never has to retain the commitment transaction of the other side.
>
> With this setup:
>
> * We provide a partial signature for the other side for their asymmetric signature.
> * We keep a copy of the shared commitment transaction and the partial signature we received for our own asymmetric signature from the other side.
>
> So storage complexity is still the same.
>
> An issue is that with asymmetric transactions, it is fairly easy to use TCP to communicate changes to the commitment txes.
> We send a bunch of HTLC changes we want to apply to the other side commitment tx, then send a signature for those changes.
> Since what we send applies to *their* transaction only, we do not have to consider what they sent to us, we just have to consider what we sent to them.
> Conversely, when keeping track of what our commitment transaction is, we only have to consider what they sent to us, in order, and then when we receive a signature we know it is for the commitment transaction with all the updates the other side sent.
>
> (This arguably just moves the complexity higher, however: we cannot forward an HTLC until both us and the other side have revoked the transactions that do not contain it i.e. the "irrevocably committed" state.)
>
> When we have "the same" transaction on both sides, however, we need to synchronize between the two sides.
> Suppose both participants want to forward HTLCs to one another.
> Without any kind of locking, both participants could send network packets containing the HTLCs they want to add to each other, and it becomes ambiguous whether the signature they *should* send contains one, or both.
>
> Basically, TCP only assures a global order for *one* direction of the communications, once we have two network nodes talking simultaneously, the order in which one writes and then reads is a lot more ambiguous.
>
> This issue also exists for Decker-Russell-Osuntokun, incidentally.
>
> One way to solve this would be to have a "token" that is passed alternately between the participants.
> At initial connection, they run a secure multiparty coinflip that indicates which one gets the token.
> Then, the one that holds the token can add more HTLCs, then tell the other "okay, now we sign" and they exchange signatures for a new version that involves only the HTLCs from the token-holder.
> Then the token-holder passes the token to the other side.
>
> If the current token-holder does not have any HTLCs it wants to send, it can wait for some time (in case it receives a request to forward), then if there are still no HTLCs, it can pass the token to the other side by sending a token-passing message.
>
> This solution requires a good amount of bandwidth in such token-passing messages, which can multiply with the number of channels a single node has.
> If token-passing is not done in short time frames (sub-second) then it potentially increases the latency of forwarding, thus this represents a latency vs bandwidth tradeoff.
>
> There may be better solutions for this race-condition problem.
> For example, it seems to me that we can still have different histories for both sides of the channel, i.e. different transactions on both sides, the same as in current Poon-Dryja BOLT.
> After all, the witnesses are asymmetric anyway.
> But that completely negates the stated goal of removing the different transactions on both sides and the hoped-for reduction in complexity, so an exercise in futility.
>
>
> Regards,
> ZmnSCPxj
📝 Original message:
Hi Z,
Thanks as usual for your thoughtful comments
I agree with you that there is no improvement in complexity in the formal sense.
I do believe it is an improvement in conceptual complexity.
At least, I am able to keep all the moving parts in my head at the
same time whereas I struggle sometimes with the current BOLT spec.
Unfortunately, while thinking about the above statement I realised
there is worse storage complexity.
In order to punish a revoked commitment transaction efficiently you
need to extract the publication secret.
But in order to do that you need to keep around the encrypted
signature (a.k.a adaptor signature) **for that particular commitment
transaction**.
This means you have O(n) storage, unlike the present spec which has
O(1) by deriving the previously revealed revocation secret from the
present one (this can't be done with adaptor signatures).
This doesn't seem to be addressed in the original work.
Yikes! This might be a fatal flaw to this proposal unless it can be addressed.
> When we have "the same" transaction on both sides, however, we need to synchronize between the two sides.
Can you elaborate on this? I think you can carry on using the same
BOLT 2 update protocol within this channel system.
The txids being the same for both parties sometimes seems to be incidental.
It may be advantageous to use an alternative protocol that forces a
synchronization of the commitment transactions but I don't *think* it
is a requirement.
I guess you would need to sync in Decker-Russell-Osuntokun because it
needs an objective ordering of commitment transactions.
That is seemingly not the case here though
LL
On Tue, Aug 25, 2020 at 10:45 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning Lloyd,
>
> I think this is excellent work overall.
>
> With that said...
>
>
> > - It is more elegant as there are half the number of possible transactions. I
> > expect this will follow through to reduced implementation complexity and maybe
> > make it easier to explain as well.
>
> I am not sure the complexity will be reduced all that much.
>
> Currently:
>
> * We provide a partial signature for the other side for their commitment transaction.
> * We keep our own commitment transaction and the partial signature we receive from the other side.
>
> The node never has to retain the commitment transaction of the other side.
>
> With this setup:
>
> * We provide a partial signature for the other side for their asymmetric signature.
> * We keep a copy of the shared commitment transaction and the partial signature we received for our own asymmetric signature from the other side.
>
> So storage complexity is still the same.
>
> An issue is that with asymmetric transactions, it is fairly easy to use TCP to communicate changes to the commitment txes.
> We send a bunch of HTLC changes we want to apply to the other side commitment tx, then send a signature for those changes.
> Since what we send applies to *their* transaction only, we do not have to consider what they sent to us, we just have to consider what we sent to them.
> Conversely, when keeping track of what our commitment transaction is, we only have to consider what they sent to us, in order, and then when we receive a signature we know it is for the commitment transaction with all the updates the other side sent.
>
> (This arguably just moves the complexity higher, however: we cannot forward an HTLC until both us and the other side have revoked the transactions that do not contain it i.e. the "irrevocably committed" state.)
>
> When we have "the same" transaction on both sides, however, we need to synchronize between the two sides.
> Suppose both participants want to forward HTLCs to one another.
> Without any kind of locking, both participants could send network packets containing the HTLCs they want to add to each other, and it becomes ambiguous whether the signature they *should* send contains one, or both.
>
> Basically, TCP only assures a global order for *one* direction of the communications, once we have two network nodes talking simultaneously, the order in which one writes and then reads is a lot more ambiguous.
>
> This issue also exists for Decker-Russell-Osuntokun, incidentally.
>
> One way to solve this would be to have a "token" that is passed alternately between the participants.
> At initial connection, they run a secure multiparty coinflip that indicates which one gets the token.
> Then, the one that holds the token can add more HTLCs, then tell the other "okay, now we sign" and they exchange signatures for a new version that involves only the HTLCs from the token-holder.
> Then the token-holder passes the token to the other side.
>
> If the current token-holder does not have any HTLCs it wants to send, it can wait for some time (in case it receives a request to forward), then if there are still no HTLCs, it can pass the token to the other side by sending a token-passing message.
>
> This solution requires a good amount of bandwidth in such token-passing messages, which can multiply with the number of channels a single node has.
> If token-passing is not done in short time frames (sub-second) then it potentially increases the latency of forwarding, thus this represents a latency vs bandwidth tradeoff.
>
> There may be better solutions for this race-condition problem.
> For example, it seems to me that we can still have different histories for both sides of the channel, i.e. different transactions on both sides, the same as in current Poon-Dryja BOLT.
> After all, the witnesses are asymmetric anyway.
> But that completely negates the stated goal of removing the different transactions on both sides and the hoped-for reduction in complexity, so an exercise in futility.
>
>
> Regards,
> ZmnSCPxj