rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 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>