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 <zmnsc...@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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
