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