From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2945C1A07 for ; Mon, 30 Sep 2019 16:00:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 965A78A6 for ; Mon, 30 Sep 2019 16:00:43 +0000 (UTC) Date: Mon, 30 Sep 2019 16:00:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1569859241; bh=6QrWX1ziWDKGKwDBqfH/NWSO3oXXU5bae7kTsb+BNlY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=RoqjCefwb+84ES8ejlJ2TnS8DkBSL7jZ5IdojFBx0Oss7odN0fP6h/POAI5SK0lRJ MoDMSUzD+fKAPQO6WzIDsDwFvV4Fu/vkK2vuQ8Cc9MALd8pLsqthaBMcBo3s4OWuek G56Dfn2f1OwuhsDNgJ+xlI99Wx7Y0Q688IW9rQls= To: Christian Decker , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj 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 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 16:00:45 -0000 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