{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-12-17\n📝 Original message:\nHi ZmnSCPxj,\n\nThanks for your response.\n\n* Once the pre-funding is sufficiently confirmed as per Bob security\n\u003e parameter\n\u003e\n\nThis is the part I'm trying to avoid. If we're ok with waiting for\nconfirmation, then it's easy to do indeed (and let's just wait for the\nfunding tx to confirm, I believe we don't even need that pre-funding step).\nBut if we have to wait for confirmations we're hodling the incoming HTLC\nfor a few blocks, which I'd like to avoid.\n\nDo you have a smart construction that would allow us to build safely on\nthat unconfirmed transaction?\nIs there maybe a smart trick that would allow us the pay-to-open server to\nprovably lock some UTXO in advance to prevent\nitself from double-spending them?\n\nCheers,\nBastien\n\n\n\nLe mar. 17 déc. 2019 à 10:31, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e\n\u003e Good morning t-bast,\n\u003e\n\u003e \u003e Good morning list,\n\u003e \u003e\n\u003e \u003e As everyone who has ever used a Lightning wallet is well aware, the\n\u003e onboarding process could be\n\u003e \u003e made smoother. With Phoenix [1], we've been experimenting with\n\u003e pay-to-open [2].\n\u003e \u003e\n\u003e \u003e That works well in practice and provides a great UX for newcomers, but\n\u003e it requires temporary trust\n\u003e \u003e between the user and our node (until the funding tx confirms).\n\u003e \u003e\n\u003e \u003e That trust relationship appears in two places:\n\u003e \u003e\n\u003e \u003e a. The user releases the preimage, then we fund the channel [2]\n\u003e \u003e b. The user trusts that we won't double-spend the funding transaction\n\u003e \u003e\n\u003e \u003e We currently need (a) because we can't ensure that the user will reveal\n\u003e the preimage once we've\n\u003e \u003e funded the channel.\n\u003e \u003e\n\u003e \u003e It's (somewhat) easy to fix that once Bitcoin supports Schnorr.\n\u003e \u003e Let's assume that we're using PTLCs (where the secret is a private key)\n\u003e and MuSig for channel\n\u003e \u003e funding transactions.\n\u003e \u003e When Alice receives a PTLC to forward to Bob, if she doesn't have a\n\u003e channel to Bob and Bob supports\n\u003e \u003e pay-to-open, she can initiate a tweaked channel opening flow. She can\n\u003e use tlv extensions in the\n\u003e \u003e `open_channel` message to tell Bob that this channel is linked to a PTLC\n\u003e with point `X=x*G`.\n\u003e \u003e Bob will tweak the MuSig nonce with `X` and provide Alice with a partial\n\u003e signature for that nonce.\n\u003e \u003e When Bob then provides the adaptor signature to finalize the funding\n\u003e transaction, it reveals `x` to\n\u003e \u003e Alice who can now fulfill the PTLC downstream.\n\u003e \u003e\n\u003e \u003e Note that in this simple version, Alice knows the nonce tweak\n\u003e beforehand. This may (or may not,\n\u003e \u003e that will need to be investigated thoroughly) be a security issue.\n\u003e \u003e Even if it turns out to be an issue, I'm pretty sure we can find a\n\u003e secure protocol that will allow\n\u003e \u003e this atomicity (let's just add another round of communication, that's\n\u003e usually how we fix broken\n\u003e \u003e cryptographic protocols).\n\u003e\n\u003e This can be assured today with HTLC-like constructions, similar to what we\n\u003e use in HTLC-success / HTLC-timeout in BOLT 3.\n\u003e\n\u003e Channel opening *instead* goes this way:\n\u003e\n\u003e * Alice receives a payment request to Bob with a specific payment hash.\n\u003e * Alice creates a transaction from its onchain funds, paying out to an\n\u003e HTLC-like construction with logic `(hash_preimage \u0026\u0026 A \u0026\u0026 B) || (timelock\n\u003e \u0026\u0026 A)`.\n\u003e   * Call this the pre-funding transaction.\n\u003e   * Alice does **not** sign and broadcast this *yet*!\n\u003e   * The timelock could reuse the same timelock as indicated in the final\n\u003e hop to the incoming payment.\n\u003e * Alice gives the txid of the pre-funding to Bob.\n\u003e * Alice and Bob create a transaction that spends the above output to the\n\u003e logic `A \u0026\u0026 B`.\n\u003e   * Call this the funding transaction.\n\u003e * Alice and Bob create commitment transactions spending the above funding\n\u003e transaction as per usual flow, and exchange signatures, completing up to\n\u003e `funding_signed`.\n\u003e   * Have it `push_msat` the payment amount to Bob minus the fee to open.\n\u003e * Alice and Bob exchange signatures for funding transaction, spending\n\u003e using the hashlock branch of the pre-funding transaction HTLC.\n\u003e * Alice signs and broadcasts the pre-funding transaction.\n\u003e * Once the pre-funding is sufficiently confirmed as per Bob security\n\u003e parameter, Bob then broadcasts the funding transaction.\n\u003e   * To do so, Bob has to add the preimage to the witness stack in order to\n\u003e make-valid the funding transaction.\n\u003e * Alice sees the preimage from the broadcasted funding transaction and can\n\u003e now continue claiming the incoming HTLC.\n\u003e\n\u003e \u003e\n\u003e \u003e I'm more concerned about fixing (b). As long as the funding transaction\n\u003e is unconfirmed, there's a\n\u003e \u003e risk of double-spending by the funder. I'm shamelessly trying to use\n\u003e this mailing list's brainpower\n\u003e \u003e to figure out possible solutions for that. Does someone have ideas that\n\u003e could help? Can we setup\n\u003e \u003e the incentives so that it's never rational for the funder to\n\u003e double-spend?\n\u003e\n\u003e Above procedure probably fixes this as well?\n\u003e It sets things up so that the funder cannot double-spend the funds that\n\u003e will eventually get into the channel after it is capable of receiving the\n\u003e preimage.\n\u003e Funder can double-spend, but then is unable to learn the preimage and\n\u003e cannot steal the payment (and is indistinguishable from any other payment\n\u003e failure).\n\u003e\n\u003e The above procedure makes Alice vulnerable to Bob aborting after the\n\u003e pre-funding is confirmed, thus onchain fees are paid by Alice to pay for\n\u003e the pre-funding and the timelock branch.\n\u003e This can be fixed by forcing Bob to provide funds to the pre-funding,\n\u003e which get returned to the channel on Bob side, and having the timelock\n\u003e branch be `(A \u0026\u0026 B \u0026\u0026 timelock)` and pre-signing a backout that returns the\n\u003e funds back to Alice and Bob, with Bob paying all onchain fee, but I believe\n\u003e the desired use-case here is when Bob has absolutely 0 millisatoshi...?\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/91c9c1b1/attachment-0001.html\u003e"}