Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning t-bast, > Good points, these are good optimisations if we propose such a new opcode! > I'm still pondering whether this will be useful enough or if finney attacks > completely ruin all use-cases... It does indeed seem to ruin all use-cases, and even my suggestion to enforce RBF will not help against the Finney attack specifically, as the second signature broadcasted is the one that is already in a block. Further, if the amount in the single-show-signature UTXO being double-spent is greater than the expected block reward, then it may encourage competing miners to instead mine an alternate block at that blockheight instead of building on the block made by the Finney attacker. This is because they already know the privkey for that UTXO and can instead immediately redirect it to an address they control, and earn more from that block that replaces the Finney attacker block rather than builds on top of it. All miners will then compete on that block and the Finney attack is promoted from an attack on a single target to an attack on the entire Bitcoin ecosystem, for much justice and laughter. Thus, `OP_CAT` is too powerful and must not be enabled!!! Oh no. Regards, ZmnSCPxj > > Le jeu. 19 déc. 2019 à 07:24, ZmnSCPxj a écrit : > > > Good morning t-bast, > > > > > > - A script-path spend with the following script (and only that > > > > script): > > > > OP_SWAP OP_DUP OP_EQUALVERIFY OP_SWAP OP_CHECKSIG > > > > > > > > > > Why not this: > > > > > > OP_SWAP OP_CHECKSPLITSIG > > > > > > ? > > > > > > Since `R` is constrained to be fixed anyway, why repeat `R` twice, once > > > in the script and once in the witness stack? > > > > For that matter, since we are far more likely to have a constant `R` than a > > constant `s` maybe you should instead propose that `OP_CHECKSPLITSIG` be > > given ` OP_CHECKSPLITSIG`, so that a fixed-`R` single-show > > signature is just ` OP_CHECKSPLITSIG`. > > > > Regards, > > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good points, these are good optimisations if we propose such a new opcode! I'm still pondering whether this will be useful enough or if finney attacks completely ruin all use-cases... Le jeu. 19 déc. 2019 à 07:24, ZmnSCPxj a écrit : > Good morning t-bast, > > > > - A script-path spend with the following script (and only that > script): > > > OP_SWAP OP_DUP OP_EQUALVERIFY OP_SWAP OP_CHECKSIG > > > > > > > Why not this: > > > > OP_SWAP OP_CHECKSPLITSIG > > > > ? > > > > Since `R` is constrained to be fixed anyway, why repeat `R` twice, once > in the script and once in the witness stack? > > For that matter, since we are far more likely to have a constant `R` than > a constant `s` maybe you should instead propose that `OP_CHECKSPLITSIG` be > given ` OP_CHECKSPLITSIG`, so that a fixed-`R` single-show > signature is just ` OP_CHECKSPLITSIG`. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning t-bast, > > - A script-path spend with the following script (and only that script): > > OP_SWAP OP_DUP OP_EQUALVERIFY OP_SWAP OP_CHECKSIG > > > > Why not this: > > OP_SWAP OP_CHECKSPLITSIG > > ? > > Since `R` is constrained to be fixed anyway, why repeat `R` twice, once in > the script and once in the witness stack? For that matter, since we are far more likely to have a constant `R` than a constant `s` maybe you should instead propose that `OP_CHECKSPLITSIG` be given ` OP_CHECKSPLITSIG`, so that a fixed-`R` single-show signature is just ` OP_CHECKSPLITSIG`. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning t-bast, > * A script-path spend with the following script (and only that script): > OP_SWAP OP_DUP OP_EQUALVERIFY OP_SWAP OP_CHECKSIG Why not this: OP_SWAP OP_CHECKSPLITSIG ? Since `R` is constrained to be fixed anyway, why repeat `R` twice, once in the script and once in the witness stack? Also, would we want to support non-`SIGHASH_ALL` sighashes? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Thanks Ethan, I agree on that. Let me also share additional feedback I received on #bitcoin-wizards from gmaxwell [1]: * Changing the behavior of OP_CHECKSIG is a no-go because using two stack arguments instead of one increases the witness size * This is better done as a new opcode as you suggest * OP_CAT and friends were intentionally left out of Taproot (too general, needs more analysis) * But this OP_CHECKSPLITSIG is very constrained so may be ok? * It does NOT protect against a finney attack [2]: protocols leveraging that would need to take such attacks into account in the incentive analysis * It only protects against a double-spend if you disallow Patrick from "emptying" this UTXO via Lightning before double-spending I still believe there are good use-cases for this for off-chain protocols, so I'll keep fleshing it out. I am interested in more feedback about the scheme, potential other attack vectors, potential other use-cases, anything you may find relevant to the discussion. Cheers, Bastien [1] https://freenode.irclog.whitequark.org/bitcoin-wizards/2019-12-18 [2] https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack Le mer. 18 déc. 2019 à 15:35, Ethan Heilman a écrit : > Responding below > > The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading >> the >> signature as a single 64-bytes stack argument, let's add a small change >> to read >> the signature as two 32-bytes stack arguments: `R` first then `s`. >> Since Taproot already makes changes to this opcode, adding this small >> change >> seems to be quite simple and harmless (and this is the right time to >> propose >> such a change as we're still in the Taproot review process). >> > > I very much in favor of a mechanism to enable outputs to enforce ECDSA > nonce reuse. > > However I would argue against changing the behavior of OP_CHECKSIG. Subtly > changing the stack behavior of perhaps the most widely used and complex OP > code in Bitcoin is likely to result in bugs in systems that create and sign > transactions. Additionally making this new behavior only activate based on > context is even more likely to cause problems. > > It would likely be safer to have this as a new OP code, say > OP_CHECKSPLITSIG. > > Alternatively we could try to get OP_CAT approved. It is a very simple OP > code, which is easy to explain, generally useful and allows this feature > plus allows many other critical features. > >> ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
> > Responding below The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the > signature as a single 64-bytes stack argument, let's add a small change to > read > the signature as two 32-bytes stack arguments: `R` first then `s`. > Since Taproot already makes changes to this opcode, adding this small > change > seems to be quite simple and harmless (and this is the right time to > propose > such a change as we're still in the Taproot review process). > I very much in favor of a mechanism to enable outputs to enforce ECDSA nonce reuse. However I would argue against changing the behavior of OP_CHECKSIG. Subtly changing the stack behavior of perhaps the most widely used and complex OP code in Bitcoin is likely to result in bugs in systems that create and sign transactions. Additionally making this new behavior only activate based on context is even more likely to cause problems. It would likely be safer to have this as a new OP code, say OP_CHECKSPLITSIG. Alternatively we could try to get OP_CAT approved. It is a very simple OP code, which is easy to explain, generally useful and allows this feature plus allows many other critical features. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning list, Thanks again for all the good suggestions, this is awesome. David and ZmnSCPxj's proposals got me thinking (and I still need to dive into Antoine's suggestion as well), and I may have found a very interesting construction. It's either great or completely dumb. I hope you can help me figure out which of the two it's going to be. The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the signature as a single 64-bytes stack argument, let's add a small change to read the signature as two 32-bytes stack arguments: `R` first then `s`. Since Taproot already makes changes to this opcode, adding this small change seems to be quite simple and harmless (and this is the right time to propose such a change as we're still in the Taproot review process). This effectively lets us leverage nonce reuse as a feature to prevent double spending once a signature has been shared off-chain. Let's set the scene for this usecase. We have a service provider Patrick that wants to offer layer 2 services. Patrick prepares some of his UTXOs to have the following spending condition: * A provably unspendable key-path spend * A script-path spend with the following script (and only that script): OP_SWAP OP_DUP OP_EQUALVERIFY OP_SWAP OP_CHECKSIG * Notes: * The script could be more fancy (maybe we want to use hash(R) instead of R directly) but you get the idea * The OP_SWAP are needed because the spending stack will be * P is of course different for every UTXO This means that Patrick is committing to the nonce he'll be using to spend that output. Now comes our friend Alice. Patrick wants to open a channel to Alice and wants to start using this channel without waiting for on-chain confirmation. Alice and Patrick build the funding transaction as usual; once Alice sees the transaction in the mempool, she can verify that the inputs have the right format. Now Alice can be sure that Patrick will not double-spend the funding transaction's inputs: if he does, he will be signing a different message with the same nonce. That would allow Alice to extract the private key for `P` and spend the UTXO to herself. She has nothing to lose there because it's Patrick's UTXO so she has an incentive to use much higher fees than Patrick. It seems to me that this construction can be generalized for many off-chain protocols that don't want to wait for confirmation. I may be overly optimistic, but I think this could enable a whole lot of new use-cases and remove many pain points in Lightning. This is only a first draft, and there are things that can be improved. Let's list what comes to mind (you will probably identify other issues): * Patrick can't use RBF on transactions that spend this kind of UTXO because it would reveal his private key: that's probably ok in practice (we can add an output for CPFP instead like we're doing for anchor outputs [1]) * These UTXOs are easy to recognize on-chain once spent, which may indicate that this is spent for an off-chain protocol * It would be great to have a way to allow key-path spend, but revoke this capability once the script has been revealed (off-chain): that would allow Patrick to encumber all his UTXOs with such a script and only use it when needed for an off-chain scenario (and use normal key-path spend otherwise) Please let me know if this is completely broken, completely dumb or worth sharing to the bitcoin-dev mailing list to consider including this `OP_CHECKSIG` change in the Taproot soft-fork. Cheers, Bastien [1] https://github.com/lightningnetwork/lightning-rfc/pull/688 Le mer. 18 déc. 2019 à 05:49, Antoine Riard a écrit : > > Hi Bastien, > > The use case you're describing strikes me as similar to a slashing protocol for a LN node and a watchtower, i.e punishing > a lazy watchtower for not broadcasting a penalty tx on remote revoked state. In both case you want "if A don't do X > unlock some funds for B". > > Here a rough slashing protocol I've sketched out to someone else off-list, it may work for you use case if you replace the penalty tx > by the funding transaction as a way for the trusted channel funder to clear his liability. Though you will need onchain interactivity > before the fact but you may be able to reuse slashing outpoint for multiple channel funding. > > Slashing Protocol > -- > > Alice and Bob lock fund in channel outpoint X. They issue commitment tx N. Will the accountable watchtower locks fund > in a 2-of-2 slashing outpoint Y with Bob the client. > > When Alice and Bob update channels to N', Bob and Will use some output from commitment N (like upcoming anchor output) > to create an accountable tx M. M is paying to Bob after timelock+Bob sig or is paying to transaction success_penalty P > with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M and from J the justice tx than Bob has given > to Will. J is spending Alice's revoked commitment N. > > So this slashing protocol should avoid Bob making
Re: [Lightning-dev] Pay-to-Open and UX improvements
Hi Bastien, The use case you're describing strikes me as similar to a slashing protocol for a LN node and a watchtower, i.e punishing a lazy watchtower for not broadcasting a penalty tx on remote revoked state. In both case you want "if A don't do X unlock some funds for B". Here a rough slashing protocol I've sketched out to someone else off-list, it may work for you use case if you replace the penalty tx by the funding transaction as a way for the trusted channel funder to clear his liability. Though you will need onchain interactivity before the fact but you may be able to reuse slashing outpoint for multiple channel funding. Slashing Protocol -- Alice and Bob lock fund in channel outpoint X. They issue commitment tx N. Will the accountable watchtower locks fund in a 2-of-2 slashing outpoint Y with Bob the client. When Alice and Bob update channels to N', Bob and Will use some output from commitment N (like upcoming anchor output) to create an accountable tx M. M is paying to Bob after timelock+Bob sig or is paying to transaction success_penalty P with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M and from J the justice tx than Bob has given to Will. J is spending Alice's revoked commitment N. So this slashing protocol should avoid Bob making false claim, because you need a revoked broadcast to enable the claim and at same time we use a justice tx output as a proof than Will have done its monitoring+punishment job. Will shouldn't learn commitment balance if there is no channel breach and Alice and Bob wouldn't be able to collude against Will, if watchtower have a penalty tx on Alice non-revoked commitment tx, that's her concern. So topology would be: to_Bob / X <-- N <- J ^ ^ \ \ Y <--- M <-- P - to_Will \ to_Bob Main idea of the protocol is to use transactions topology of a first contract as proofs for a subsidiary contract. I'm quite sure it's insecure, just quick ideas, any thoughts ? (but would be really cool to have one accountable protocol to both watchtower and pay-to-open use cases to save engineering costs) Cheers, Antoine Le mar. 17 déc. 2019 à 16:08, Ethan Heilman a écrit : > From where I'm sitting the fact that OP_CAT allows people to build > more powerful constructions in Bitcoin without introducing additional > complexity at the consensus layer is a positive not a negative. Using > OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful > protocol tool for enforcing fairness in layer two protocols. > > On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev > wrote: > > > > Good morning t-bast, > > > > Further, we can enforce that RBF is signalled for every spend of the > output by: > > > > <0> OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CAT > OP_CHECKSIG > > > > Requiring that RBF is signalled gives a little more assurance. > > Suppose ACINQ becomes evil and double-spends the output. > > The transaction that is posted in the mempool must be marked by RBF due > to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as > RBF opt-in. > > Then anyone who notices the double-spend can RBF the double-spending > transaction to themselves rather than ACINQ. > > This also further publishes ACINQ private key, until the winning > transaction has an `OP_RETURN` output that pays the entire value as fees > and nobody can RBF it further. > > > > This is a minor increase in the assurability of the construction, by > making any output that is double-spent directly revocable in favor of the > miners. > > Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing > such powerful constructions. > > > > Regards, > > ZmnSCPxj > > > > > > > Thanks a lot David for the suggestion and pointers, that's a really > interesting solution. > > > I will dive into that in-depth, it could be very useful for many > layer-2 constructions. > > > > > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` > construction, > > > a lot of cool tricks coming up once (if?) we have such tools in the > future ;) > > > > > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj a > écrit : > > > > > > > Good morning David, t-bast, and all, > > > > > > > > > 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. > > > > > > > > With `OP_CAT`, we can enforce that a particular `R` is used, which > allows to implement single-show signatures. > > > > > > > > # Assuming
Re: [Lightning-dev] Pay-to-Open and UX improvements
From where I'm sitting the fact that OP_CAT allows people to build more powerful constructions in Bitcoin without introducing additional complexity at the consensus layer is a positive not a negative. Using OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful protocol tool for enforcing fairness in layer two protocols. On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev wrote: > > Good morning t-bast, > > Further, we can enforce that RBF is signalled for every spend of the output > by: > > <0> OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CAT OP_CHECKSIG > > Requiring that RBF is signalled gives a little more assurance. > Suppose ACINQ becomes evil and double-spends the output. > The transaction that is posted in the mempool must be marked by RBF due to > the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as RBF > opt-in. > Then anyone who notices the double-spend can RBF the double-spending > transaction to themselves rather than ACINQ. > This also further publishes ACINQ private key, until the winning transaction > has an `OP_RETURN` output that pays the entire value as fees and nobody can > RBF it further. > > This is a minor increase in the assurability of the construction, by making > any output that is double-spent directly revocable in favor of the miners. > Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing such > powerful constructions. > > Regards, > ZmnSCPxj > > > > Thanks a lot David for the suggestion and pointers, that's a really > > interesting solution. > > I will dive into that in-depth, it could be very useful for many layer-2 > > constructions. > > > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` > > construction, > > a lot of cool tricks coming up once (if?) we have such tools in the future > > ;) > > > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj a écrit : > > > > > Good morning David, t-bast, and all, > > > > > > > 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. > > > > > > With `OP_CAT`, we can enforce that a particular `R` is used, which allows > > > to implement single-show signatures. > > > > > > # Assuming signatures are the concatenation of (R,s) > > > OP_SWAP OP_CAT OP_CHECKSIG > > > > > > The above would then feed `s` only on the witness stack. > > > > > > Regards, > > > ZmnSCPxj > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning t-bast, Further, we can enforce that RBF is signalled for every spend of the output by: <0> OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CAT OP_CHECKSIG Requiring that RBF is signalled gives a little more assurance. Suppose ACINQ becomes evil and double-spends the output. The transaction that is posted in the mempool must be marked by RBF due to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as RBF opt-in. Then anyone who notices the double-spend can RBF the double-spending transaction to themselves rather than ACINQ. This also further publishes ACINQ private key, until the winning transaction has an `OP_RETURN` output that pays the entire value as fees and nobody can RBF it further. This is a minor increase in the assurability of the construction, by making any output that is double-spent directly revocable in favor of the miners. Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing such powerful constructions. Regards, ZmnSCPxj > Thanks a lot David for the suggestion and pointers, that's a really > interesting solution. > I will dive into that in-depth, it could be very useful for many layer-2 > constructions. > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction, > a lot of cool tricks coming up once (if?) we have such tools in the future ;) > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj a écrit : > > > Good morning David, t-bast, and all, > > > > > 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. > > > > With `OP_CAT`, we can enforce that a particular `R` is used, which allows > > to implement single-show signatures. > > > > # Assuming signatures are the concatenation of (R,s) > > OP_SWAP OP_CAT OP_CHECKSIG > > > > The above would then feed `s` only on the witness stack. > > > > Regards, > > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Thanks a lot David for the suggestion and pointers, that's a really interesting solution. I will dive into that in-depth, it could be very useful for many layer-2 constructions. Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction, a lot of cool tricks coming up once (if?) we have such tools in the future ;) Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj a écrit : > Good morning David, t-bast, and all, > > > > 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. > > With `OP_CAT`, we can enforce that a particular `R` is used, which allows > to implement single-show signatures. > > # Assuming signatures are the concatenation of (R,s) > OP_SWAP OP_CAT OP_CHECKSIG > > The above would then feed `s` only on the witness stack. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning David, t-bast, and all, > 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. With `OP_CAT`, we can enforce that a particular `R` is used, which allows to implement single-show signatures. # Assuming signatures are the concatenation of (R,s) OP_SWAP OP_CAT OP_CHECKSIG The above would then feed `s` only on the witness stack. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
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. signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
Good morning t-bast, > > 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? Unconfirmed transactions are only safe / trustless if they cannot be replaced. https://zmnscpxj.github.io/offchain/safety.html In offchain techniques, we ensure that pre-agreed offchain transactions cannot be replaced by requiring that all participants agree (n-of-n). With an n-of-n, replacement transactions are only possible if you cooperate in the attempt to steal from you, and thus no different from you voluntarily donating your funds to them anyway. So you need to pre-prepare some already-confirmed UTXOs that are 2-of-2 between you and the client. Of course, such 2-of-2 would *already* be channels themselves. Conversely, if you *do* find a solution to this problem, then that can be made an anchor / funding transaction output for a channel, and we would implement it directly into Lightning to remove the channel-opening confirmation delay. Given that there has been a lot of thinking regarding channel mechanisms, from the original broken Satoshi `nSequence` to Spilman to modern mechanisms like Decker-Wattenhofer, Poon-Dryja, and Decker-Russell-Osuntokun, all of which are still vulnerable to double-spending if you do not confirm the funding transaction deeply, it seems to me unlikely that such a technology could be derived. With current known cryptographic mechanisms, even if you consider that maybe you could pre-confirm some UTXOs that you can then subsequently allocate to clients immediately while ensuring that those UTXOs can only be spent in cooperation with the client, you need to somehow learn some public key before a client generates a private key for it, without knowing the private key yourself (or somehow be able to demonstrate that you can no longer access the private key). And if the client already gives you a pubkey, that is basically just you opening channels to them as soon as they arrive, and requires confirmation anyway. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-to-Open and UX improvements
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 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
Re: [Lightning-dev] Pay-to-Open and UX improvements
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Pay-to-Open and UX improvements
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). 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? Cheers, Bastien [1] https://phoenix.acinq.co/ [2] https://medium.com/@ACINQ/phoenix-part-2-pay-to-open-4a8a482dd4d ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
