{"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:\nGood morning list,\n\nAs everyone who has ever used a Lightning wallet is well aware, the\nonboarding process could be\nmade smoother. With Phoenix [1], we've been experimenting with pay-to-open\n[2].\n\nThat works well in practice and provides a great UX for newcomers, but it\nrequires temporary trust\nbetween the user and our node (until the funding tx confirms).\n\nThat trust relationship appears in two places:\n\na. The user releases the preimage, then we fund the channel [2]\nb. The user trusts that we won't double-spend the funding transaction\n\nWe currently need (a) because we can't ensure that the user will reveal the\npreimage once we've\nfunded the channel.\n\nIt's (somewhat) easy to fix that once Bitcoin supports Schnorr.\nLet's assume that we're using PTLCs (where the secret is a private key) and\nMuSig for channel\nfunding transactions.\nWhen Alice receives a PTLC to forward to Bob, if she doesn't have a channel\nto Bob and Bob supports\npay-to-open, she can initiate a tweaked channel opening flow. She can use\ntlv extensions in the\n`open_channel` message to tell Bob that this channel is linked to a PTLC\nwith point `X=x*G`.\nBob will tweak the MuSig nonce with `X` and provide Alice with a partial\nsignature for that nonce.\nWhen Bob then provides the adaptor signature to finalize the funding\ntransaction, it reveals `x` to\nAlice who can now fulfill the PTLC downstream.\n\nNote that in this simple version, Alice knows the nonce tweak beforehand.\nThis may (or may not,\nthat will need to be investigated thoroughly) be a security issue.\nEven if it turns out to be an issue, I'm pretty sure we can find a secure\nprotocol that will allow\nthis atomicity (let's just add another round of communication, that's\nusually how we fix broken\ncryptographic protocols).\n\nI'm more concerned about fixing (b). As long as the funding transaction is\nunconfirmed, there's a\nrisk of double-spending by the funder. I'm shamelessly trying to use this\nmailing list's brainpower\nto figure out possible solutions for that. Does someone have ideas that\ncould help? Can we setup\nthe incentives so that it's never rational for the funder to double-spend?\n\nCheers,\nBastien\n\n[1] https://phoenix.acinq.co/\n[2] https://medium.com/@ACINQ/phoenix-part-2-pay-to-open-4a8a482dd4d\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/9529e2b6/attachment.html\u003e"}