Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-11 📝 Original message: Hey aj, This is awesome ...
📅 Original date posted:2021-10-11
📝 Original message:
Hey aj,
This is awesome work. My line of research on "witness asymmetric channels"
essentially ended up in a dead end because I couldn't see how they were
much better than naive PTLC lightning. The idea I really liked from it was
"revocable signatures". I hoped someone would eventually figure out what to
do with them. Looks like you've done that!
I also didn't make the connection to how revocable signatures actually
solves the constant size storage problem. I knew it could make the protocol
in "generalized payment channels" [1] only require constant size which was
the target of the idea but I hadn't considered that lightning already
suffers from this problem so it can be applied more generally.
The other big breakthrough you made is showing how you can do concurrent
non-interactive payment forwarding by using a refined version of Z's fast
forward idea. In my mind the most practical way to make FF work on
Poon-Dryja channels was to do it asymmetrically [3] but this meant that if
a payment was sent the other way you'd have to do a 3 phase commit first.
With your idea as long as you have balance to spare in your balance output
you can always forward a payment in one message. A nice speed boost for
busy routing nodes.
### Scorched earth punishment
Another thing that I'd like to mention is that using revocable signatures
enables scorched earth punishments [2]. The key you reveal when you post a
revoked state does not have to be limited to your channel -- it could be
used in multiple channels allowing the wronged party to take coins from all
their channels with the perpetrator. Furthermore, a lightning service
provider that offers channels with the same channel key to all their
customers is putting up all their coins in all their existing channels as
their good behaviour bond rather than just the coins they have in the
channels they have with you.
For many users this will be sufficient to go without a "watchtower" to do
punishments for them. They know if the LSP takes their coins with a revoked
state whenever they come back online they can punish the LSP by revealing
their static channel key to everyone. They can even do this weeks or months
after the theft assuming the LSP is still operating with the same key.
Some people feel this idea is too spicy but I prefer it to introducing a
trusted third party for people that cannot be online all the time.
[1] https://eprint.iacr.org/2020/476.pdf
[2]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html
Some queries below:
On Sat, 9 Oct 2021 at 12:12, Anthony Towns <aj at erisian.com.au> wrote:
>
> We will use "i" to represent the number of times a given inflight
> transaction has been updated for the nth update to the balance
> transaction.
>
> At any time Alice can update the inflight transaction spending her balance
> to transfer funds towards Bob, either by updating the balances directly,
> or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
> conversely for Bob)
>
> We will define RP=musig(A/2/n/i, RB2(n,i)).
>
> The inflight transaction spending Alice's balance can have multiple
> types of outputs:
>
> * Alice's remaining balance: pays directly to A/2/n/i
>
> * Bob's remaining balances: pays to RP/2 with script path
> "<B/2/n/i> CHECKSIGVERIFY <D> CSV"
>
> * An htlc paying to Bob: pays to RP/2/k with script paths:
> + "LENGTH 32 EQUALVERIFY HASH160 <X> EQUALVERIFY <B/2/n/i/k>
> CHECKSIGVERIFY <A/2/n/i/k> CHECKSIG"
> + "<A/2/n/i/k/1> CHECKSIGVERIFY <T> CLTV"
>
> * A ptlc paying to Bob: pays to RP/2/k with script paths:
> + "<B/2/n/i/k> CHECKSIG NOTIF <T> CLTV DROP ENDIF <A/2/n/i/k> CHECKSIG"
>
> Any outputs that would be zero or dust are not included.
>
> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
>
Can you expand on why "k" is needed in addition to "n" and "i". k sounds
like the same thing as i to me.
Also what does RP/2/k notation imply given the definition of RP you gave
above?
> * if the inflight transaction contains a ptlc output, then if Alice
> has not retained the old ptlc details (the point and the timeout)
> she will not trivially be able to reconstruct the script path,
> which includes the timeout. However, presuming the timeout was
> within 5000 blocks, then the only possible timeouts are the inflight
> tx's nlocktime+i with 0<i<=5000, and she will only need to calculate
> 5000*k cases and match the corresponding scriptPubKeys to exhaustively
> enumerate every possible ptlc output, which should take under a minute,
> and be easily achievable. In addition, if Bob attempts to claim the
> funds, he will reveal the script path, and Alice will be either able
> to claim the inflight output directly or the layered output.
>
What about just doing a scriptless PTLC to avoid this (just CSV input of
presigned tx)? The cost is pre-sharing more nonces per PTLC message.
This does not support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
>
This is rather big drawback but is this really the case? Can't "in-flight"
transactions send the balance of the remote party to their unencumbered
static remote key? Since there is no "in-flight" transaction just after you
create a new balance tx you can just sign a "good will" in-flight tx
whenever you create a new balance tx that sends all the coins to your
static key. Of course, your counterparty has no incentive to broadcast this
when they close the channel but we can just specify that as part of the
protocol you broadcast this anyway (even if it gives you nothing). It's no
skin off their back.
Ok so what about the fee for the "good will" tx? Well let's say it is a
special case and just pays for itself with a reasonable fee. The "good
will" tx is low time preference and can be CPFP easily if you haven't lost
your state. If you have lost your state then this is much better than
nothing.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/a619e4b8/attachment-0001.html>;
📝 Original message:
Hey aj,
This is awesome work. My line of research on "witness asymmetric channels"
essentially ended up in a dead end because I couldn't see how they were
much better than naive PTLC lightning. The idea I really liked from it was
"revocable signatures". I hoped someone would eventually figure out what to
do with them. Looks like you've done that!
I also didn't make the connection to how revocable signatures actually
solves the constant size storage problem. I knew it could make the protocol
in "generalized payment channels" [1] only require constant size which was
the target of the idea but I hadn't considered that lightning already
suffers from this problem so it can be applied more generally.
The other big breakthrough you made is showing how you can do concurrent
non-interactive payment forwarding by using a refined version of Z's fast
forward idea. In my mind the most practical way to make FF work on
Poon-Dryja channels was to do it asymmetrically [3] but this meant that if
a payment was sent the other way you'd have to do a 3 phase commit first.
With your idea as long as you have balance to spare in your balance output
you can always forward a payment in one message. A nice speed boost for
busy routing nodes.
### Scorched earth punishment
Another thing that I'd like to mention is that using revocable signatures
enables scorched earth punishments [2]. The key you reveal when you post a
revoked state does not have to be limited to your channel -- it could be
used in multiple channels allowing the wronged party to take coins from all
their channels with the perpetrator. Furthermore, a lightning service
provider that offers channels with the same channel key to all their
customers is putting up all their coins in all their existing channels as
their good behaviour bond rather than just the coins they have in the
channels they have with you.
For many users this will be sufficient to go without a "watchtower" to do
punishments for them. They know if the LSP takes their coins with a revoked
state whenever they come back online they can punish the LSP by revealing
their static channel key to everyone. They can even do this weeks or months
after the theft assuming the LSP is still operating with the same key.
Some people feel this idea is too spicy but I prefer it to introducing a
trusted third party for people that cannot be online all the time.
[1] https://eprint.iacr.org/2020/476.pdf
[2]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments
[3]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html
Some queries below:
On Sat, 9 Oct 2021 at 12:12, Anthony Towns <aj at erisian.com.au> wrote:
>
> We will use "i" to represent the number of times a given inflight
> transaction has been updated for the nth update to the balance
> transaction.
>
> At any time Alice can update the inflight transaction spending her balance
> to transfer funds towards Bob, either by updating the balances directly,
> or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And
> conversely for Bob)
>
> We will define RP=musig(A/2/n/i, RB2(n,i)).
>
> The inflight transaction spending Alice's balance can have multiple
> types of outputs:
>
> * Alice's remaining balance: pays directly to A/2/n/i
>
> * Bob's remaining balances: pays to RP/2 with script path
> "<B/2/n/i> CHECKSIGVERIFY <D> CSV"
>
> * An htlc paying to Bob: pays to RP/2/k with script paths:
> + "LENGTH 32 EQUALVERIFY HASH160 <X> EQUALVERIFY <B/2/n/i/k>
> CHECKSIGVERIFY <A/2/n/i/k> CHECKSIG"
> + "<A/2/n/i/k/1> CHECKSIGVERIFY <T> CLTV"
>
> * A ptlc paying to Bob: pays to RP/2/k with script paths:
> + "<B/2/n/i/k> CHECKSIG NOTIF <T> CLTV DROP ENDIF <A/2/n/i/k> CHECKSIG"
>
> Any outputs that would be zero or dust are not included.
>
> Note that we number each currently inflight transaction by "k",
> starting at 0. The same htlc/ptlc may have a different value for k
> between different inflight transactions.
>
Can you expand on why "k" is needed in addition to "n" and "i". k sounds
like the same thing as i to me.
Also what does RP/2/k notation imply given the definition of RP you gave
above?
> * if the inflight transaction contains a ptlc output, then if Alice
> has not retained the old ptlc details (the point and the timeout)
> she will not trivially be able to reconstruct the script path,
> which includes the timeout. However, presuming the timeout was
> within 5000 blocks, then the only possible timeouts are the inflight
> tx's nlocktime+i with 0<i<=5000, and she will only need to calculate
> 5000*k cases and match the corresponding scriptPubKeys to exhaustively
> enumerate every possible ptlc output, which should take under a minute,
> and be easily achievable. In addition, if Bob attempts to claim the
> funds, he will reveal the script path, and Alice will be either able
> to claim the inflight output directly or the layered output.
>
What about just doing a scriptless PTLC to avoid this (just CSV input of
presigned tx)? The cost is pre-sharing more nonces per PTLC message.
This does not support option_static_remotekey, but compensates for that
> by allowing balances to be recovered with only the channel setup data
> even if all revocation data is lost.
>
This is rather big drawback but is this really the case? Can't "in-flight"
transactions send the balance of the remote party to their unencumbered
static remote key? Since there is no "in-flight" transaction just after you
create a new balance tx you can just sign a "good will" in-flight tx
whenever you create a new balance tx that sends all the coins to your
static key. Of course, your counterparty has no incentive to broadcast this
when they close the channel but we can just specify that as part of the
protocol you broadcast this anyway (even if it gives you nothing). It's no
skin off their back.
Ok so what about the fee for the "good will" tx? Well let's say it is a
special case and just pays for itself with a reasonable fee. The "good
will" tx is low time preference and can be CPFP easily if you haven't lost
your state. If you have lost your state then this is much better than
nothing.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/a619e4b8/attachment-0001.html>;