rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2019-12-17 📝 Original message: On Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote: > 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: > [...] > b. The user trusts that we won't double-spend the funding transaction > [...] > 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. The typical proposed solution for this type of problem is a single-show signature[1], a signature that will reveal the private key used to create it if it's combined with another signature from the same private key. In other words, if you sign two different spends of the same UTXO, someone who see both spends will be able to redirect all of that UTXO's value to themselves. In that case, your change output becomes a form of fidelity bond---you get to keep it if you act honestly; otherwise, someone else gets it (most likely whoever mines the next block). I'm not aware of any way to currently force single-show signatures in Bitcoin, so this is pretty theoretical. Also, single-show signatures add a lot of fragility to any setup and make useful features like RBF fee bumping unavailable. As a less complete but more practical solution, you might want to consider a signing federation. This doesn't change the need for trust, but it does allow spreading that trust around. E.g. if spending your funds requires three signatures each from one of five different respected companies helping pioneer LN (perhaps all in different legal jurisdictions), that might help mitigate user concerns about double spending. Besides the extra communicating and signing, your existing workflow wouldn't need to change. -Dave [1] Here's some math for single show signatures in ECDSA: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html Probably a more practical way to enforce single-show in Bitcoin would be something like OP_CHECKSIGFROMSTACK, e.g. as implemented in Elements: https://elementsproject.org/features/opcodes Maybe SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT could also be used to enforce single-show with the right script? I'm not so sure about that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/dcd8987d/attachment.sig>