Date: Mon, 30 Sep 2019 16:00:35 +0000
To: Christian Decker <decker.christian@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
In-Reply-To: <87wodp7w9f.fsf@gmail.com>
References: <87wodp7w9f.fsf@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
	anyprevout
Precedence: list

Good morning Christian,

> The concern with output tagging is that it hurts fungibility, marking out=
puts
> used in a contract as such and making them identifiable. But maybe it wou=
ld 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 ho=
w outputs look like, so that unspent Taproot outputs look exactly like othe=
r 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 chaperon=
e 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 out=
puts getting spent to further bip-schnor/Taproot SegWit v1 addresses, to in=
crease 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-explore=
r-revealed address for current, existing Poon-Dryja channels is unsafe to s=
end 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 decis=
ions 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 partic=
ipants,
> > but they don't cross-independent domains where you see a wallet or a pr=
otocol
> > 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 ar=
e
> > things that are protected and I can give to anyone, you don't want to r=
euse
> > 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, imp=
roving their privacy while unspent.

I submit also that a Taproot whose internal Taproot point is an n-of-n of a=
ll participants, with script branches enforcing particular modes, are simil=
arly "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 amo=
ng 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 implem=
ent 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 tha=
t
>     these proposals a useful, also beyond eltoo, not everybody could be
>     there. I'd therefore like to elicit some feedback from the wider comm=
unity.

I strongly agree that `NOINPUT` is useful, and I was not able to attend Cor=
eDev (at least, not with any human fleshbot already known to you --- I chec=
ked).

>
> 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 p=
rivate key to use for all chaperone signatures, since all the important sec=
urity is in the `NOINPUT` signature anyway.

>
> 3.  The same for output tagging / explicit opt-in. What are the advantage=
s and
>     disadvantages?

Strongly oppose, see above about my argument.

>
> 4.  Shall we merge BIP-118 and bip-anyprevout. This would likely reduce t=
he
>     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