Good morning Christian, > The concern with output tagging is that it hurts fungibility, marking outputs > used in a contract as such and making them identifiable. But maybe it would be > a good idea to create two domains anyway: one for user-addressable > destinations which users can use with their general purpose wallets, and one > domain for contracts, which users cannot send to directly.
I rather strongly oppose output tagging. The entire point of for example Taproot was to reduce the variability of how outputs look like, so that unspent Taproot outputs look exactly like other unspent Taproot outputs regardless of the SCRIPT (or lack of SCRIPT) used to protect the outputs. That is the reason why we would prefer to not support P2SH-wrapped Taproot even though P2SH-wrapping was intended to cover all future uses of SegWit, including SegWit v1 that Taproot will eventually get. Indeed, if it is output tagging that gets into Bitcoin base layer, I would strongly suggest the below for all Decker-Russell-Osuntokun implementations: * A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction Output, confirmed onchain * A "translator transaction" spending the above and paying out to a SegWit v16 output-tagged output, kept offchain. * Decker-Russell-Osuntokun update transaction, signed with `SIGHASH_NOINPUT` spending the translator transaction output. * Decker-Russell-Osuntokun state transaction, signed with `SIGHASH_NOINPUT` spending the update transaction output. The point regarding use of a commonly-known privkey to work around chaperone signatures is appropriate to the above, incidentally. In short: this is a workaround, plain and simple, and one wonders the point of adding *either* chaperones *or* output tagging if we will, in practice, just work around them anyway. Again, the *more* important point is that special blockchain constructions should only be used in the "bad" unilateral close case. In the cooperative case, we want to use simple plain bip-schnorr-signed outputs getting spent to further bip-schnor/Taproot SegWit v1 addresses, to increase the anonymity set of all uses of Decker-Russell-Osuntokun and other applications that might use `SIGHASH_NOINPUT` in some edge case (but which resolve down to simple bip-schnorr-signed n-of-n cases when the protocol is completed successfully by all participants). We already have the issue in current Lightning where the blockchain-explorer-revealed address for current, existing Poon-Dryja channels is unsafe to send any amount to. Granted, we should work to make things safer; but I suggest that we should be willing to sacrifice some amount of safety against arguably-stupid decisions in order to have better privacy for larger sets of users. > > This also came up during the CoreDev meeting [ams-coredev]: > > > these sort of NOINPUT signatures are only things that are within some > > application or within some protocol that gets negotiated between > > participants, > > but they don't cross-independent domains where you see a wallet or a > > protocol > > as a kind of domain. You can't tell the difference, is this an address I can > > give to someone else or not? It's all scripts, no real addresses. There are > > types of outputs that are completely insecure unconditionally; there are > > things that are protected and I can give to anyone, you don't want to reuse > > it, but there's no security issue from doing so. This is an additional class > > that is secure perfectly but only when used in the right way. I submit that a Taproot whose internal Taproot point is a NUMS point (thus nobody knows its scalar) is similarly "secure perfectly but only when used in the right way". Yet the point of Taproot is to hide these outputs until they are spent, improving their privacy while unspent. I submit also that a Taproot whose internal Taproot point is an n-of-n of all participants, with script branches enforcing particular modes, are similarly "secure perfectly but only when used in the right way", and again the point of Taproot is to allow the n-of-n "everybody agrees" path to hide among the 1-of-1 whale HODLers. In short: I do not see how you can coherently argue for "we should separate `SIGHASH_NOINPUT` types to a new script type" while simultaneously arguing "we should merge all kinds of SCRIPT usage (and non-usage) together into a single script type". If we will separate `SIGHASH_NOINPUT`-enabled outputs, we should not implement Taproot, as the existing separation of P2WSH and P2WPKH is congruent to the proposed separation of `SIGHASH_NOINPUT`-enablement. > > Open questions > > --------------- > > The questions that remain to be addressed are the following: > > 1. General agreement on the usefulness of noinput / anyprevoutanyscript / > anyprevout. While at the CoreDev meeting I think everybody agreed that > these proposals a useful, also beyond eltoo, not everybody could be > there. I'd therefore like to elicit some feedback from the wider > community. I strongly agree that `NOINPUT` is useful, and I was not able to attend CoreDev (at least, not with any human fleshbot already known to you --- I checked). > > 2. Is there strong support or opposition to the chaperone signatures > introduced in anyprevout / anyprevoutanyscript? I think it'd be best to > formulate a concrete set of pros and contras, rather than talk about > abstract dangers or advantages. No opposition, we will just work around this by publishing a common known private key to use for all chaperone signatures, since all the important security is in the `NOINPUT` signature anyway. > > 3. The same for output tagging / explicit opt-in. What are the advantages and > disadvantages? Strongly oppose, see above about my argument. > > 4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the > confusion and make for simpler discussions in the end. Ambivalent, mildly support. > > 5. Anything I forgot to mention :-) Cats are very interesting creatures, and are irrelevant to `SIGHASH_NOINPUT` discussion, but are extremely cute nonetheless. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
