Good morning t-bast,
> 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). This can be assured today with HTLC-like constructions, similar to what we use in HTLC-success / HTLC-timeout in BOLT 3. Channel opening *instead* goes this way: * Alice receives a payment request to Bob with a specific payment hash. * Alice creates a transaction from its onchain funds, paying out to an HTLC-like construction with logic `(hash_preimage && A && B) || (timelock && A)`. * Call this the pre-funding transaction. * Alice does **not** sign and broadcast this *yet*! * The timelock could reuse the same timelock as indicated in the final hop to the incoming payment. * Alice gives the txid of the pre-funding to Bob. * Alice and Bob create a transaction that spends the above output to the logic `A && B`. * Call this the funding transaction. * Alice and Bob create commitment transactions spending the above funding transaction as per usual flow, and exchange signatures, completing up to `funding_signed`. * Have it `push_msat` the payment amount to Bob minus the fee to open. * Alice and Bob exchange signatures for funding transaction, spending using the hashlock branch of the pre-funding transaction HTLC. * Alice signs and broadcasts the pre-funding transaction. * Once the pre-funding is sufficiently confirmed as per Bob security parameter, Bob then broadcasts the funding transaction. * To do so, Bob has to add the preimage to the witness stack in order to make-valid the funding transaction. * Alice sees the preimage from the broadcasted funding transaction and can now continue claiming the incoming HTLC. > > 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? Above procedure probably fixes this as well? It sets things up so that the funder cannot double-spend the funds that will eventually get into the channel after it is capable of receiving the preimage. Funder can double-spend, but then is unable to learn the preimage and cannot steal the payment (and is indistinguishable from any other payment failure). The above procedure makes Alice vulnerable to Bob aborting after the pre-funding is confirmed, thus onchain fees are paid by Alice to pay for the pre-funding and the timelock branch. This can be fixed by forcing Bob to provide funds to the pre-funding, which get returned to the channel on Bob side, and having the timelock branch be `(A && B && timelock)` and pre-signing a backout that returns the funds back to Alice and Bob, with Bob paying all onchain fee, but I believe the desired use-case here is when Bob has absolutely 0 millisatoshi...? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
