ZmnSCPxj <zmnsc...@protonmail.com> writes: > 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.
That is a bit reductive if you ask me. Taproot brings a number of improvements such as the reduction of on-chain footprint in the collaborative spend case, the hiding of complex logic in that case, and yes, the uniformity of UTXOs that you mentioned. I do agree that it'd be to make everything look identical to the outside observer, but saying that separating outputs into two coarse-grained domains is equivalent to throwing the baby out with the bath-water :-) That being said, I should clarify that I would prefer not having to make special accomodations on top of the raw sighash_noinput proposal, for some perceived, but abstract danger that someone might shoot themselves in the foot. I think we're all old enough not to need too much handholding :-) Output tagging is my second choice, since it minimizes the need for people to get creative to work around other proposals, and minimizes the on-chain footprint, and finally chaperone signatures are my least preferred option due to its heavy-handed nature and the increased cost. > 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. That is very much how I was planning to implement it anyway, using a trigger transaction to separate timeout start and the actual update/settlement pairs (cfr. eltoo paper Section 4.2). So for eltoo there shouldn't be an issue here :-) > 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. Exactly, why introduce the extra burden of chaperone signatures or output tagging if we're just going to sidestep it? > 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). While I do agree that we should keep outputs as unidentifiable as possible, I am starting to question whether that is possible for off-chain payment networks since we are gossiping about the existence of channels and binding them to outpoints to prove their existence anyway. Not the strongest argument I know, but there's little point in talking ideal cases when we need to weaken that later again. >> 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). Great, good to know that I'm not shouting into the void, and that I'm not just that crazy guy trying to get his hairbrained scheme to work :-) >> 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. Definitely agreed :+1: _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev