Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-17 📝 Original message: Good morning list, As ...
📅 Original date posted:2019-12-17
📝 Original message:
Good morning list,
As everyone who has ever used a Lightning wallet is well aware, the
onboarding process could be
made smoother. With Phoenix [1], we've been experimenting with pay-to-open
[2].
That works well in practice and provides a great UX for newcomers, but it
requires temporary trust
between the user and our node (until the funding tx confirms).
That trust relationship appears in two places:
a. The user releases the preimage, then we fund the channel [2]
b. The user trusts that we won't double-spend the funding transaction
We currently need (a) because we can't ensure that the user will reveal the
preimage once we've
funded the channel.
It's (somewhat) easy to fix that once Bitcoin supports Schnorr.
Let's assume that we're using PTLCs (where the secret is a private key) and
MuSig for channel
funding transactions.
When Alice receives a PTLC to forward to Bob, if she doesn't have a channel
to Bob and Bob supports
pay-to-open, she can initiate a tweaked channel opening flow. She can use
tlv extensions in the
`open_channel` message to tell Bob that this channel is linked to a PTLC
with point `X=x*G`.
Bob will tweak the MuSig nonce with `X` and provide Alice with a partial
signature for that nonce.
When Bob then provides the adaptor signature to finalize the funding
transaction, it reveals `x` to
Alice who can now fulfill the PTLC downstream.
Note that in this simple version, Alice knows the nonce tweak beforehand.
This may (or may not,
that will need to be investigated thoroughly) be a security issue.
Even if it turns out to be an issue, I'm pretty sure we can find a secure
protocol that will allow
this atomicity (let's just add another round of communication, that's
usually how we fix broken
cryptographic protocols).
I'm more concerned about fixing (b). As long as the funding transaction is
unconfirmed, there's a
risk of double-spending by the funder. I'm shamelessly trying to use this
mailing list's brainpower
to figure out possible solutions for that. Does someone have ideas that
could help? Can we setup
the incentives so that it's never rational for the funder to double-spend?
Cheers,
Bastien
[1] https://phoenix.acinq.co/
[2] https://medium.com/@ACINQ/phoenix-part-2-pay-to-open-4a8a482dd4d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/9529e2b6/attachment.html>;
📝 Original message:
Good morning list,
As everyone who has ever used a Lightning wallet is well aware, the
onboarding process could be
made smoother. With Phoenix [1], we've been experimenting with pay-to-open
[2].
That works well in practice and provides a great UX for newcomers, but it
requires temporary trust
between the user and our node (until the funding tx confirms).
That trust relationship appears in two places:
a. The user releases the preimage, then we fund the channel [2]
b. The user trusts that we won't double-spend the funding transaction
We currently need (a) because we can't ensure that the user will reveal the
preimage once we've
funded the channel.
It's (somewhat) easy to fix that once Bitcoin supports Schnorr.
Let's assume that we're using PTLCs (where the secret is a private key) and
MuSig for channel
funding transactions.
When Alice receives a PTLC to forward to Bob, if she doesn't have a channel
to Bob and Bob supports
pay-to-open, she can initiate a tweaked channel opening flow. She can use
tlv extensions in the
`open_channel` message to tell Bob that this channel is linked to a PTLC
with point `X=x*G`.
Bob will tweak the MuSig nonce with `X` and provide Alice with a partial
signature for that nonce.
When Bob then provides the adaptor signature to finalize the funding
transaction, it reveals `x` to
Alice who can now fulfill the PTLC downstream.
Note that in this simple version, Alice knows the nonce tweak beforehand.
This may (or may not,
that will need to be investigated thoroughly) be a security issue.
Even if it turns out to be an issue, I'm pretty sure we can find a secure
protocol that will allow
this atomicity (let's just add another round of communication, that's
usually how we fix broken
cryptographic protocols).
I'm more concerned about fixing (b). As long as the funding transaction is
unconfirmed, there's a
risk of double-spending by the funder. I'm shamelessly trying to use this
mailing list's brainpower
to figure out possible solutions for that. Does someone have ideas that
could help? Can we setup
the incentives so that it's never rational for the funder to double-spend?
Cheers,
Bastien
[1] https://phoenix.acinq.co/
[2] https://medium.com/@ACINQ/phoenix-part-2-pay-to-open-4a8a482dd4d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/9529e2b6/attachment.html>;