Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-06 📝 Original message: Good morning list, There ...

📅 Original date posted:2021-12-06
📝 Original message:
Good morning list,

There was a great recent post on the mailing list detailing how we could
do PTLCs on lightning with a lot of other goodies [0]. This proposal
contained heavy changes to the transaction structure and the update
protocol. While it's certainly something we'll want to do in the long
run, I wanted to explore the minimal set of changes we would need to be
able to deploy PTLCs as soon as possible.

The current result is a somewhat high-level article, where each section
could be a separate update of the lightning protocol [1].

I tried to make PTLCs work with minimal changes to the transaction
structure and the update protocol, but they introduce a fundamental
change which forces us to make more changes than I'd like.

With HTLCs, the payment secret (the preimage of the payment hash) was
directly revealed in the witness of a spending transaction.

With PTLCs, this isn't the case anymore. The payment secret is a private
key, and a spending transaction only reveals that key if you have a
matching adaptor signature. This forces us to make two changes:

1. We must obtain adaptor signatures before sending our commit_sig
2. We must use a pre-signed HTLC-success transaction not only with our
local commit, but also with the remote commit

This means that we will need more round-trips whenever we update our
commitment. I'd like to find the right design trade-off where we don't
introduce too many changes in the protocol while minimizing the number
of additional round-trips.

We currently exchange the following messages:

Alice Bob
update_add_htlc
--------------------------->
update_add_htlc
--------------------------->
update_add_htlc
--------------------------->
commit_sig
--------------------------->
revoke_and_ack
<---------------------------
commit_sig
<---------------------------
revoke_and_ack
--------------------------->

It works well because the commit_sig sent by Alice only contains signatures
for Bob's transactions (commit and htlc transactions), and the commit_sig
sent by Bob only contains signatures for Alice's transactions, and Alice
and Bob don't need anything else to spend outputs from either commitment.

But with PTLCs, Bob needs a signature from Alice to be able to fulfill a
PTLC from Alice's commitment. And Alice needs Bob to provide an adaptor
signature for that transaction before she can give him her signature.
We don't have the clean ordering that we had before.

The designs I came up with that keep the current messages and just insert
new ones are either too costly (too many additional round-trips) or too
complex (most likely broken in some edge cases).

I believe we need to change the commit_sig / revoke_and_ack protocol if
we want to find the sweet spot I'm looking for. I'd like to collect ideas
from this list's participants on how we could do that. This is probably
something that should be bundled with option_simplified_commitment [2]
(or at least we must ensure that option_simplified_commitment is a first
step towards the protocol we'll need for PTLCs). It's also important to
note that the protocol changes must work for both HTLCs and PTLCs, and
shouldn't change the structure of the transactions (not more than the
simple addition of PTLC outputs done in [1]).

Cheers,
Bastien

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
[1] https://github.com/t-bast/lightning-docs/pull/16
[2] https://github.com/lightning/bolts/pull/867
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/c474a332/attachment-0001.html>;