Johnson Lau <jl2...@xbt.hk> writes: >> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes: >>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev >>> wrote: >>>> And is it worthwhile doing the mask complexity, rather than just >>>> removing the commitment to script with NOINPUT? It *feels* safer to >>>> restrict what scripts we can sign, but is it? >>> >>> If it's not safer in practice, we've spent a little extra complexity >>> committing to a subset of the script in each signature to no gain. If >>> it is safer in practice, we've prevented people from losing funds. I'm >>> all for less complexity, but not for that tradeoff. >> >> There are many complexities we could add, each of which would prevent >> loss of funds in some theoretical case. > > Every security measures are overkill, until someone get burnt. If these > security measures are really effective, no one will get burnt. The inevitable > conclusion is: every effective security measures are overkill. > >> >> From practical experience; reuse of private keys between lightning and >> other things is not how people will lose funds[1]. > > So you argument seems just begging the question. Without NOINPUT, it is just > impossible to lose money by key reuse, and this is exactly the topic we are > debating.
I think we're getting confused here. I'm contributing my thoughts from the lightning implementer's point of view; there are other important considerations, but this is my contribution. In *lightning* there are more ways to lose funds via secret reuse. Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous property; with OP_MASK the danger is limited to reuse-on-the-same-script (ie. if you use the same key for a non-lightning output and a lightning output, you're safe with OP_MASK. However, this is far less likely in practice). I state again: OP_MASK doesn't seem to gain *lightning* any significant security benefit. > It does not need to be something like > GetMaskedScript(GetScriptCodeForMultiSig()). After all, only a very small > number of script templates really need NOINPUT. A GetMaskedScript() in a > wallet is just an overkill (and a vulnerability if mis-implemented) Our current transaction signing code is quite generic (and, if I may say so, readable and elegant). We could, of course, special case GetMaskedScript() for the case we need (the Eltoo examples I've seen have a single OP_MASK at the front, which makes it trivial). > It’s also about functionality here: as I mentioned in another reply, > OP_CODESEPARATOR couldn’t function properly with NOINPUT but without > OP_MASKEDPUSH The mailing list seems a bit backed up or something; I replied to that in the hope you can clear my confusion on that one. > This debate happens because NOINPUT introduces the third way to lose fund > with key reuse. And once it is deployed, we have to support it forever, and > is not something that we could softfork it away. A would use the same words to encourage you to create the simplest possible implementation? I don't think we disagree on philosophy, just trade-offs. And that's OK. Cheers, Rusty. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
