rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 Original date posted:2019-12-17 📝 Original message: Hi ZmnSCPxj, Thanks for your response. * Once the pre-funding is sufficiently confirmed as per Bob security > parameter > This is the part I'm trying to avoid. If we're ok with waiting for confirmation, then it's easy to do indeed (and let's just wait for the funding tx to confirm, I believe we don't even need that pre-funding step). But if we have to wait for confirmations we're hodling the incoming HTLC for a few blocks, which I'd like to avoid. Do you have a smart construction that would allow us to build safely on that unconfirmed transaction? Is there maybe a smart trick that would allow us the pay-to-open server to provably lock some UTXO in advance to prevent itself from double-spending them? Cheers, Bastien Le mar. 17 déc. 2019 à 10:31, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit : > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/91c9c1b1/attachment-0001.html>