Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-01 📝 Original message: ZmnSCPxj <ZmnSCPxj at ...

📅 Original date posted:2019-10-01
📝 Original message:
ZmnSCPxj <ZmnSCPxj at 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: