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 5C433E6F for ; Wed, 8 May 2019 23:07:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 928A9196 for ; Wed, 8 May 2019 23:07:04 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id u199so463140oie.5 for ; Wed, 08 May 2019 16:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CpC13BLNdkyDec1uNdUlJrTeXZE/RihAvf6LjgqqVk4=; b=iYHdilWPcyFCGK9/XLupP+bdLcIa0KnbEALxs/AMgXLg1yRy/mCsGYpyjLCVIA5NE+ /3ZXcFIvSANIyK6i5y5Vp8pz8ua0dsMJGTsD2RTNU6e/Rt/o6Q2GmdlFi+3AMY7CcmfK hMyJGOvlu67u1TgN2PsI5Ef9Y5BLeuzBGJw6U12ZfoabF7Ze20awuVotsEgG+p3lJwWG 1qb9HFlSOziiVCaQ7iEtSD+NQA+nZXMWZsjxBFW2nWk2ka/sadfFWwtahgKDWskPhq+I Bcrf54bZFy4mrOqSA3VeDOSu25GCB6W513OOd7QXVo7X4j0MNIHkMVrjnywOoQAcATB1 eqzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CpC13BLNdkyDec1uNdUlJrTeXZE/RihAvf6LjgqqVk4=; b=lYmNAUbBk/H+zc/yyXr4h9ayOdlryaeE5+KDIrexqVM086hibwibe9a53iHR0eBoC0 AuU+MpRxWrv7Xh8nIoOVmlD8t2sROIBPEC2+Ge+/vwdRz4bGgmJTXBxH/+JB9kEl6e1J SoHcPVomXZ3XnEVnQ9Vfj2u5SQz3aVftIrG0X5kno1tcqaBemTxK8jR4nhR9PJUNVbmS T1F6UHXUnr2g4QB+rWo64qWos4fBWiPxeWTBd4CqxFdWPLrcows4WVbALuv2opCiWLGS BY8KIbpYVp2KZK27C5vtxA0hAYOLUeIuZNVeQU1sFKhuVGT6aXIp7YwsXNQqXXur8pZU mcjA== X-Gm-Message-State: APjAAAXptgCHrEgmsUhuFSFfXPDxGCWDqAdeUu7qQxmZD8V9X+gVzyg/ /VRezvbIbZ8ygipWpJXqF30YO2Gwus5Wuvb9/uw= X-Google-Smtp-Source: APXvYqyw4RJB25Wvj/S3KP4vd4UUO+giajVyW2DS88AowwYTnq/9Miv4+MZ5fx4nK8Pl8nrgHG7EWzgvQ3n3SYSxY2w= X-Received: by 2002:aca:db45:: with SMTP id s66mr215918oig.59.1557356823621; Wed, 08 May 2019 16:07:03 -0700 (PDT) MIME-Version: 1.0 References: <201905062017.11396.luke@dashjr.org> <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> In-Reply-To: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> From: Pieter Wuille Date: Wed, 8 May 2019 16:06:51 -0700 Message-ID: To: Sjors Provoost Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 09 May 2019 14:48:45 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Taproot proposal 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: Wed, 08 May 2019 23:07:05 -0000 Thanks for the comments so far! I'm going to respond to some of the comments here. Things which I plan to address with changes in the BIP I'll leave for later. On Mon, 6 May 2019 at 13:17, Luke Dashjr wrote: > Tagged hashes put the tagging at the start of the hash input. This means > implementations can pre-cache SHA2 states, but it also means they can't r= euse > states to produce data for different contexts. (I'm not sure if there is = a > use for doing so... but maybe as part of further hiding MAST branches?) It's true you can't cache/precompute things across tags, but I also think there is no need. The type of data hashed in a sighash vs a merkle branch/leaf vs a tweak is fundamentally different. I think this is perhaps a good guidance to include about when separate tags are warranted vs. simply making sure the input does not collide: there shouldn't be much or any shared data with things that are expected to be inputs under other tags. > Is there any way to use the Taproot construct here while retaining extern= al > script limitations that the involved party(ies) *cannot* agree to overrid= e? > For example, it is conceivable that one might wish to have an uncondition= al > CLTV enforced in all circumstances. Yes, absolutely - you can use a point with unknown discrete logarithm as internal key. This will result in only script path spends being available. For the specific goal you're stating an alternative may be using a valid known private key, using it to pre-sign a timelocked transaction, and destroying the key. > It may be useful to have a way to add a salt to tap branches. If you don't reuse public keys, effectively every branch is automatically salted (and the position in the tree gets randomized automatically when doing so, providing a small additional privacy benefit). >> Some way to sign an additional script (not committed to by the witness >> program) seems like it could be a trivial addition. > This would be especially useful for things like OP_CHECKBLOCKATHEIGHT: > https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki If you're talking about the ability to sign over the ability to spend to another script ("delegation"), there are lots of interesting applications and ways to implement it. But it overlaps with Graftroot, and doing it efficiently in general has some interesting and non-obvious engineering challenges (for example, signing over to a script that enforces "f(tx)=3Dy" for some f can be done by only storing f and then including y in the sighash). For the specific example of BIP115's functionality, that seems like a reasonable thing that could be dealt with using the annex construction in the proposed BIP. A consensus rule could define a region inside the annex that functions as a height-blockhash assertion. The annex is included in all sighashes, so it can't be removed from the input; later opcodes could include the ability to inspect that assertion even. On Tue, 7 May 2019 at 13:43, Sjors Provoost wrote: > One reason why someone would want to avoid a "everone agrees" branch, is = duress (or self-discipline, or limiting powers of a trustee). In particular= with respect to time-locks.> Indeed, though as I suggested above, you can also use timelocked transactions (but using only CLTV branches is more flexible certainly). > Can this "unknown discrete logarithm" be made provably unknown, so all si= gners are assured of this property? Bonus points if the outside world can't= tell. The exact mechanism could be outside the scope of the BIP, but knowi= ng that it's possible is useful. Yes, that's a TODO that's left in the draft, but this is absolutely possible (using a hash-to-curve operation). As ZmnSCPxj already suggested, there can even be a fixed known constant you can use for this. However, you get better privacy by taking this fixed known constant (call it C) and using as internal key a blinded version of it (C+rG, for some random value r, and G the normal secp256k1 generator); as long as the DL between G and C is unknown, this is safe (and does not reveal to the world that in fact no key-path was permitted when spending). > Regarding usage of Schnorr: do I understand correctly that the "everyone = agrees" internal key MUST use Schnorr, and that individual branches MAY use= Schnorr, but only if they're marked as tapscript spend? > > Why is tapscript not mandatory? Spending using the internal key always uses a single Schnorr signature and nothing else. When you spend using a script path, you must reveal both the script and its leaf version. If that leaf version is 0xc0, the script is interpreted as a tapscript (in which only Schnorr opcodes exist). If that leaf version is not 0xc0, the script is undefined, and is unconditionally valid. This is one of the included extension mechanisms, allowing replacing the whole script language with something else, but without revealing it unless a branch using it is actually used (different Merkle tree leaves can have a distinct leaf versions). So the reason that tapscript is not mandatory is because other leaf versions are undefined, and left for future extensions (similar to how future segwit versions at the output level are undefined). Cheers, --=20 Pieter