From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D15B7C013E for ; Tue, 18 Feb 2020 23:29:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id B3D1220489 for ; Tue, 18 Feb 2020 23:29:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-QOxWTZfjIv for ; Tue, 18 Feb 2020 23:29:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by silver.osuosl.org (Postfix) with ESMTPS id CC08F2000F for ; Tue, 18 Feb 2020 23:29:33 +0000 (UTC) Received: by mail-ot1-f44.google.com with SMTP id p8so21268849oth.10 for ; Tue, 18 Feb 2020 15:29:33 -0800 (PST) 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; bh=5/97wtlfX8NqBsDRxFd9+C7VBzycha10rdee7psFiPA=; b=hkc0K/Wq82lO3pTNevNsWozN7tqfNC1fxoxnY2gPVCkkGOOsi/DNH8jftjZ63CBSSx sd4kH+JhKETG+qdPyqM/I7eQhGLvDOan16G8VLZpdeXYj8jNu0QOaD5DOnbXeTXzL94a b21g4JAptbdINNqCORJVufmxv18tv4YnBsg9wc02UAoZRP8tri+4kIJDNi5MLIL2YqvC GPjWfDMBx7u4W7bmtqKNIdmzrckXAdi4e3p18kfe5pduIgUnOgY7aP99WzAz4wdAX50x rDK1qZyja6XSzN/xxDJRFROQrkjs5VncedThABoUi6BsQgEMg40bwyOWGYXTDeerUPNg fDVQ== 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; bh=5/97wtlfX8NqBsDRxFd9+C7VBzycha10rdee7psFiPA=; b=RGCWNvqyE3g87RSG2MJcNP+plehXGaz2ChpmamikwYFbHXnY4SsytB83Vuy2hIDeA/ e6dUOM6asZgdrshs+Cv4W/7CjMLbrQoM20fq6haS1oz+ctU6b4gy8IOLL0r2LO7Nw2qe 8vFUhnoh0w4tAKWgmBFZ+19qqjaAgbO7fBrSxv4zPaHKRWw6kh51QcGWaZLxTJpiLFlp KMbqldm7c+oYOh2TG5s+83jYgMvMOg+9x2paznAS8ddfnNvTMwioRjkthYaGIxxLdJUi 4Zxp+lbefMVbXWELi1GbxJ4btJYWAxzD4Zt7PnnNymdOFYJa8+EltHXNAZQtp1uU0lk+ zsgA== X-Gm-Message-State: APjAAAVaMcylbyJwyaJWxrvs5A1GffYNA1bSM6LF8AYeYxjoHIHIcMp6 u+0FGTSwykpvz3PHq2akJspCnOyhrdFjUpwA+FU= X-Google-Smtp-Source: APXvYqwGSAgDo0VzphW6gfaofOIYvS7ZD3m+2qI3g++k59Ra2d/D0YrMvwJSBSFQ+tkAWMvZfZj8d1NtJULpULp+lDI= X-Received: by 2002:a9d:7357:: with SMTP id l23mr16929425otk.10.1582068572805; Tue, 18 Feb 2020 15:29:32 -0800 (PST) MIME-Version: 1.0 References: <20200214223642.djdvosj7t7e6nrdz@ganymede> In-Reply-To: <20200214223642.djdvosj7t7e6nrdz@ganymede> From: Pieter Wuille Date: Tue, 18 Feb 2020 15:29:21 -0800 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 23:29:37 -0000 On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev wrote: > > On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote: > > Is the same if Schnorr + Merkle Branch without Taproot optimization, unless > > I'm missing something in one of the cases? > > That's fair. However, it's only true if everyone constructs their > merkle tree in the same way, with a single ` OP_CHECKSIG` as > one of the top leaves. Taproot effectively standardizes the position > of the all-parties-agree condition and so its anonymity set may contain > spends from scripts whose creators buried or excluded the the all-agree > option because they didn't think it was likely to be used. > > More importantly, there's no incentive for pure single-sig users to use a > merkle tree, since that would make both the scriptPubKey and the witness > data are larger for them than just continuing to use v0 segwit P2WPKH. > Given that single-sig users represent a majority of transactions at > present (see AJ Towns's previous email in this thread), I think we > really want to make it as convenient as possible for them to participate > in the anonymity set. Right, I think we shouldn't just see Taproot as adding a possibility of a cheap single-key branch to Merkle tree. It is actively choosing to incentivize protocols and implementations that can use the key path, making sure that the cheapest way spending of spending is also the most private one - as we can assume that it indeed will be the most frequent one. I don't believe having a separate MAST-no-Taproot spending type (through whatever mechanism) is beneficial to that. Taproot effectively gives everyone a "key path spend is included in the price", making it maximally appealing even to those who don't care about privacy. I don't think this is an unreasonable angle. There are plenty of other options that exists if we just want to make verification constructions cheap but disregard incentives for privacy. For example, why don't we research account-based state/payments? Being able to avoid change would make simple payments significantly cheaper (both in terms of block space and computation). Of course, the reason (or at least one of them) is that it would result in a discount for those willing to reduce their privacy (use accounts = reuse address = don't pay for change), and this hurts everyone (and indirectly the fungibility of the system as a whole). This is true even when there are use cases that would legitimately benefit from having this option. This is of course a much weaker case, but I think it is similar. Having no-Taproot available would reduce the incentives for those who don't care about spending policy privacy to put the engineering effort into building key-path-spendable protocols and implementations - and I think such protocols, wherever possible, should be the goal. There probably are some use cases where key path spending is truly not an option, but I suspect they're rare, or sufficiently high value that 8 vbyte differences don't matter to them. If that turns out to be wrong, it remains possible to add a new output type/witness version that does support them. This does mean distinguishable outputs, but only for things that would be distinguishable at spending time anyway, and that's a cost we'll have to pay anyway for future structural script improvements (like cross-input aggregation or graftroot). Cheers, -- Pieter