ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-07 📝 Original message: Good morning LL, > Hi Z, ...
📅 Original date posted:2021-06-07
📝 Original message:
Good morning LL,
> Hi Z,
>
> I agree with your analysis. This is how I pictured eltoo fast forwards working as well.
>
> Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them.
> With the non-custodial LN phone apps there is this annoying UX where you have to keep the app open to receive a payment (because the pre-image is on my phone).
> I wouldn't mind letting the provider handle receiving payments on my behalf.
> Of course this means they would be able to steal the money in the FF state but this is a big reduction in risk from a full custodial solution.
> In other words, you should be able to get the seamless experience of a fully custodial wallet while only giving them custody of small amounts of coins for a short time.
Yes, that is indeed a good advantage and thank you for this.
> On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
> > At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
>
> I don't think you need to build up a long chain of HTLC txs for the Poon-Dryja fast forward in the "desync" approach. Each one just replaces the other.
Thinking about it more, this seems correct.
Referring back to the diagrams:
+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ +------------+-------------+
+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
On the *next* HTLC, Alice just gives s commitment tx *3* `SigA`, and a replacement HTLC Tx `SigA[0]` to the cashier of Bob.
+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx *2* |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ | +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
+--------------------------+
| Commitment tx *3* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
This is safe, because:
* If Alice publishes Commitment tx 1 of Alice, Bob has every incentive to publish the HTLC Tx *2*, not the older HTLC Tx.
* Alice cannot force publishing the *previous* HTLC Tx, because Alice has no `B` key and cannot force-publish it.
* If Bob wants to close unilaterally, it has every incentive to publish the latest Commitment tx ### of B, because that has the most HTLCs going to Bob.
Against the above we should note that the "HTLCs" we are talking about in Poon-Dryja are not simple contracts but are instead revocable HTLCs, which means additional dependent transactions.
So I think the above *is* doable, but *does* require additional complexity and care, in that every A->B HTLC has to have some signatures exchanged as well (which, as they are HTLCs "in flight", we can have the keys on the cashier).
---------------------
I also have another subtlety to bring up with the above.
In particular, for a set of *simplex* Alice-to-Bob payments, Bob should ***not*** provide the revocation keys of older "commitment transactions owned by Bob".
That is, the cashier should ***not*** have access to the revocation keys.
Notice the above example:
+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
Despite being the *2nd* commitment tx, it should have the ***same*** Bob-side revocation key `B[0]` instead of the next one in the series, `B[1]`.
My previous email was wrong in incrementing `B[1]` here.
To understand this subtlety, let us divide Bob into these characters:
* The "true" Bob, which represents the actual economic entity that is using this scheme for their improved economic efficiency (i.e. "because it is convenient for the user").
* Carol the cashier, who is in direct communication with Alice and is 100% online.
* This represents a piece of (hopefully open-source) software which acts as the 100%-online node.
* Kelly the keyholder, who holds the important private keys of Bob, and *only* connects to Carol (via a direct connection) if and only if Bob wills it.
* This represents a piece of hardware that keeps the keys offline.
Now, let us consider the below property:
* Bob has access to all the activity of Carol, including all communications between Carol and Alice.
* More to the point, Bob has a copy of every `SigA` received by Carol.
The above property is accurate to the real world, I think, because Carol is not a true economic sentient entity.
It is "just" a piece of software you install on a piece of hardware with 100% uptime, and presumably Bob either has personally audited the software, or has hired someone to do so on its behalf.
Of course, software is never perfect, and it is possible that a bug in the software will allow Alice to extract additional information from Carol the cashier-software.
We model this as Carol then cooperating with Alice to do as much economic damage to Bob as possible.
For example, Carol is the one who keeps the various `SigA`s from Alice.
Thus, in theory, if Carol is corrupted by Alice, Carol is capable of deleting all the `SigA`s coming from Alice, including that needed by every "commitment transaction owned by Bob".
Thus, a "signature-deletion" attack mounted by Alice and Carol on Bob can prevent Bob from unilaterally closing the channel, leading to hostage-taking of ***all*** the Bob-side funds in the channel, not just in-flight HTLCs.
However, remember that Carol is "really" just a piece of (potentially buggy) software.
Bob can mitigate signature deletion:
* Perhaps the backing datastore is really a copy-on-write structure, such that deletions are not actual overwrites of old data, and older version containing the signatures can be retained.
* Bob can take snapshots of the backing datastore periodically, which reduces the damage of deletions, as Bob has a copy of some of the older data before Carol deleted signatures.
* Perhaps the signature datastore is an append-only log, which is only periodically reaped of truly obsolete signatures by Bob.
As signatures are only 64 bytes, this is not an onerous amount of data for low-bandwidth Bobs.
* The Carol software could be structured so that the signature datastore is a separate process, thus enjoys some amount of protection (process isolation) from exploits on the "main" Carol software that is online and connected to Alice.
Thus, in our model, we have the property that Bob can always recover all signatures sent by Alice, even if Carol is corrupted by Alice --- we model the signature-deletion attack as impossible, by assumption.
(This is a strengthening of security assumptions, thus a weakening of the security of the scheme --- if Bob does not take the above mitigations, Bob ***is*** vulnerable to a signature-deletion attack and might have ***all*** funds in hostage).
Now, hostaging of the funds in a channel occurs because one participant loses the ability to unilaterally close.
If Bob is unable to unilaterally close, Alice can refuse to cooperate on channel closures unless Bob dontes some money to Alice.
Signature-deletion is only *one* way to lose this ability.
Another way is for a corrupted Carol to reveal all the revocation keys, including the latest revocation key, to Alice.
This prevents Bob from safely unilaterally closing the channel, as the latest transaction it has is revocable by Alice (because Carol has been corrupted and has leaked the latest revocation key).
Thus:
* Carol ***MUST NOT*** be given the entire set of revocation keys `B[0]`..`B[n]`.
Carol should only be given *previous* revocation keys by Bob, as a hardened derivation from the keys held by KElly.
Of course, since Carol has no access to the *current* revocation key, it cannot provide it once the *next* commitment is created.
This implies that, until Bob puts Kelly online and gets access to the entire sequence of revocation keys, Carol also **cannot** provide revocation keys for previous states.
Thus, as long as Kelly is offline, Alice and Carol have to reuse the same revocation key.
This is still safe, since later "commitment transaction owned by Bob" have more and more funds in HTLCs going to Bob.
Thus, Bob has every incentive to use only the latest "commitment transaction owned by Bob".
So:
* As long as all transfers are Alice->Bob direction, there is no need to update the revocation key (and Carol ***cannot*** provide this key anyway without Kelly).
* Once we have a Bob->Alice transfer (i.e. Bob sends out money), only then does the revocation key need to be exposed to Carol for sending to Alice.
* As the sequence of revocation keys are derived from the master privkey held by Kelly, Kelly is needed.
* We need Kelly to be online anyway for sends (to send the corresponding signatures as well), so this is *not* an *additional* requirement.
Regards,
ZmnSCPxj
📝 Original message:
Good morning LL,
> Hi Z,
>
> I agree with your analysis. This is how I pictured eltoo fast forwards working as well.
>
> Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them.
> With the non-custodial LN phone apps there is this annoying UX where you have to keep the app open to receive a payment (because the pre-image is on my phone).
> I wouldn't mind letting the provider handle receiving payments on my behalf.
> Of course this means they would be able to steal the money in the FF state but this is a big reduction in risk from a full custodial solution.
> In other words, you should be able to get the seamless experience of a fully custodial wallet while only giving them custody of small amounts of coins for a short time.
Yes, that is indeed a good advantage and thank you for this.
> On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do *not* build up a long chain of HTLC txes.
> > At the worst case, we have an old update tx that is superseded by a later update tx instead, thus the overhead is expected to be at most 1 extra update tx no matter how many HTLCs are offered while Bob has its privkey offline.
>
> I don't think you need to build up a long chain of HTLC txs for the Poon-Dryja fast forward in the "desync" approach. Each one just replaces the other.
Thinking about it more, this seems correct.
Referring back to the diagrams:
+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ +------------+-------------+
+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
On the *next* HTLC, Alice just gives s commitment tx *3* `SigA`, and a replacement HTLC Tx `SigA[0]` to the cashier of Bob.
+--------------------------+ +--------------------------+
| Commitment tx 1 of A | | HTLC Tx *2* |
+------------+-------------+ +------------+-------------+
| | (A[0] && B) |--->| SigA[0] | (A[0] && B) |
| |||(A && CSV) | | |||(A && CSV) |
| SigB +-------------+ | +-------------+
| | B | | | A->B |
| | | | | HTLC |
+------------+-------------+ | +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
+--------------------------+
| Commitment tx *3* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
This is safe, because:
* If Alice publishes Commitment tx 1 of Alice, Bob has every incentive to publish the HTLC Tx *2*, not the older HTLC Tx.
* Alice cannot force publishing the *previous* HTLC Tx, because Alice has no `B` key and cannot force-publish it.
* If Bob wants to close unilaterally, it has every incentive to publish the latest Commitment tx ### of B, because that has the most HTLCs going to Bob.
Against the above we should note that the "HTLCs" we are talking about in Poon-Dryja are not simple contracts but are instead revocable HTLCs, which means additional dependent transactions.
So I think the above *is* doable, but *does* require additional complexity and care, in that every A->B HTLC has to have some signatures exchanged as well (which, as they are HTLCs "in flight", we can have the keys on the cashier).
---------------------
I also have another subtlety to bring up with the above.
In particular, for a set of *simplex* Alice-to-Bob payments, Bob should ***not*** provide the revocation keys of older "commitment transactions owned by Bob".
That is, the cashier should ***not*** have access to the revocation keys.
Notice the above example:
+--------------------------+
| Commitment tx *2* of B |
+------------+-------------+
| SigA | A |
| | |
| +-------------+
| | (A && B[0]) |
| |||(B && CSV) |
| +-------------+
| | A->B |
| | HTLC |
+------------+-------------+
Despite being the *2nd* commitment tx, it should have the ***same*** Bob-side revocation key `B[0]` instead of the next one in the series, `B[1]`.
My previous email was wrong in incrementing `B[1]` here.
To understand this subtlety, let us divide Bob into these characters:
* The "true" Bob, which represents the actual economic entity that is using this scheme for their improved economic efficiency (i.e. "because it is convenient for the user").
* Carol the cashier, who is in direct communication with Alice and is 100% online.
* This represents a piece of (hopefully open-source) software which acts as the 100%-online node.
* Kelly the keyholder, who holds the important private keys of Bob, and *only* connects to Carol (via a direct connection) if and only if Bob wills it.
* This represents a piece of hardware that keeps the keys offline.
Now, let us consider the below property:
* Bob has access to all the activity of Carol, including all communications between Carol and Alice.
* More to the point, Bob has a copy of every `SigA` received by Carol.
The above property is accurate to the real world, I think, because Carol is not a true economic sentient entity.
It is "just" a piece of software you install on a piece of hardware with 100% uptime, and presumably Bob either has personally audited the software, or has hired someone to do so on its behalf.
Of course, software is never perfect, and it is possible that a bug in the software will allow Alice to extract additional information from Carol the cashier-software.
We model this as Carol then cooperating with Alice to do as much economic damage to Bob as possible.
For example, Carol is the one who keeps the various `SigA`s from Alice.
Thus, in theory, if Carol is corrupted by Alice, Carol is capable of deleting all the `SigA`s coming from Alice, including that needed by every "commitment transaction owned by Bob".
Thus, a "signature-deletion" attack mounted by Alice and Carol on Bob can prevent Bob from unilaterally closing the channel, leading to hostage-taking of ***all*** the Bob-side funds in the channel, not just in-flight HTLCs.
However, remember that Carol is "really" just a piece of (potentially buggy) software.
Bob can mitigate signature deletion:
* Perhaps the backing datastore is really a copy-on-write structure, such that deletions are not actual overwrites of old data, and older version containing the signatures can be retained.
* Bob can take snapshots of the backing datastore periodically, which reduces the damage of deletions, as Bob has a copy of some of the older data before Carol deleted signatures.
* Perhaps the signature datastore is an append-only log, which is only periodically reaped of truly obsolete signatures by Bob.
As signatures are only 64 bytes, this is not an onerous amount of data for low-bandwidth Bobs.
* The Carol software could be structured so that the signature datastore is a separate process, thus enjoys some amount of protection (process isolation) from exploits on the "main" Carol software that is online and connected to Alice.
Thus, in our model, we have the property that Bob can always recover all signatures sent by Alice, even if Carol is corrupted by Alice --- we model the signature-deletion attack as impossible, by assumption.
(This is a strengthening of security assumptions, thus a weakening of the security of the scheme --- if Bob does not take the above mitigations, Bob ***is*** vulnerable to a signature-deletion attack and might have ***all*** funds in hostage).
Now, hostaging of the funds in a channel occurs because one participant loses the ability to unilaterally close.
If Bob is unable to unilaterally close, Alice can refuse to cooperate on channel closures unless Bob dontes some money to Alice.
Signature-deletion is only *one* way to lose this ability.
Another way is for a corrupted Carol to reveal all the revocation keys, including the latest revocation key, to Alice.
This prevents Bob from safely unilaterally closing the channel, as the latest transaction it has is revocable by Alice (because Carol has been corrupted and has leaked the latest revocation key).
Thus:
* Carol ***MUST NOT*** be given the entire set of revocation keys `B[0]`..`B[n]`.
Carol should only be given *previous* revocation keys by Bob, as a hardened derivation from the keys held by KElly.
Of course, since Carol has no access to the *current* revocation key, it cannot provide it once the *next* commitment is created.
This implies that, until Bob puts Kelly online and gets access to the entire sequence of revocation keys, Carol also **cannot** provide revocation keys for previous states.
Thus, as long as Kelly is offline, Alice and Carol have to reuse the same revocation key.
This is still safe, since later "commitment transaction owned by Bob" have more and more funds in HTLCs going to Bob.
Thus, Bob has every incentive to use only the latest "commitment transaction owned by Bob".
So:
* As long as all transfers are Alice->Bob direction, there is no need to update the revocation key (and Carol ***cannot*** provide this key anyway without Kelly).
* Once we have a Bob->Alice transfer (i.e. Bob sends out money), only then does the revocation key need to be exposed to Carol for sending to Alice.
* As the sequence of revocation keys are derived from the master privkey held by Kelly, Kelly is needed.
* We need Kelly to be online anyway for sends (to send the corresponding signatures as well), so this is *not* an *additional* requirement.
Regards,
ZmnSCPxj