{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-12-17\n📝 Original message:\nOn Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:\n\u003e With Phoenix [1], we've been experimenting with pay-to-open [2].\n\u003e\n\u003e That works well in practice and provides a great UX for newcomers, but\n\u003e it requires temporary trust between the user and our node (until the\n\u003e funding tx confirms).\n\u003e \n\u003e That trust relationship appears in two places:\n\u003e [...]\n\u003e b. The user trusts that we won't double-spend the funding transaction\n\u003e [...] \n\u003e I'm more concerned about fixing (b). As long as the funding\n\u003e transaction is unconfirmed, there's a risk of double-spending by the\n\u003e funder. \n\nThe typical proposed solution for this type of problem is a single-show\nsignature[1], a signature that will reveal the private key used to\ncreate it if it's combined with another signature from the same private\nkey.  In other words, if you sign two different spends of the same UTXO,\nsomeone who see both spends will be able to redirect all of that UTXO's\nvalue to themselves.  In that case, your change output becomes a form of\nfidelity bond---you get to keep it if you act honestly; otherwise,\nsomeone else gets it (most likely whoever mines the next block).\n\nI'm not aware of any way to currently force single-show signatures in\nBitcoin, so this is pretty theoretical.  Also, single-show signatures\nadd a lot of fragility to any setup and make useful features like RBF\nfee bumping unavailable.\n\nAs a less complete but more practical solution, you might want to\nconsider a signing federation.  This doesn't change the need for trust,\nbut it does allow spreading that trust around.  E.g. if spending your\nfunds requires three signatures each from one of five different\nrespected companies helping pioneer LN (perhaps all in different legal\njurisdictions), that might help mitigate user concerns about double\nspending.  Besides the extra communicating and signing, your existing\nworkflow wouldn't need to change. \n\n-Dave\n\n[1] Here's some math for single show signatures in ECDSA:\n\n        https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html\n\n    Probably a more practical way to enforce single-show in Bitcoin\n    would be something like OP_CHECKSIGFROMSTACK, e.g. as implemented in\n    Elements:\n\n        https://elementsproject.org/features/opcodes\n\n    Maybe SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT could also be used to\n    enforce single-show with the right script?  I'm not so sure about\n    that.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/dcd8987d/attachment.sig\u003e"}