From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C5FFC0171 for ; Sun, 9 Feb 2020 20:40:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 3B4B084D9F for ; Sun, 9 Feb 2020 20:40:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccPlm9r0aPK9 for ; Sun, 9 Feb 2020 20:40:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by whitealder.osuosl.org (Postfix) with ESMTPS id 8A82D84AB2 for ; Sun, 9 Feb 2020 20:40:44 +0000 (UTC) Received: from [10.233.42.100] (unknown [69.59.18.156]) by mail.as397444.net (Postfix) with ESMTPSA id 81F4419BEF7 for ; Sun, 9 Feb 2020 20:40:40 +0000 (UTC) To: Bitcoin Protocol Discussion References: From: Matt Corallo Message-ID: <2d9970d8-209d-7223-6564-ad858dce5981@mattcorallo.com> Date: Sun, 9 Feb 2020 20:40:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity 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: Sun, 09 Feb 2020 20:40:45 -0000 Responding purely to one point as this may be sufficient to clear up lots of discussion: On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote: > Is Taproot just a probability assumption about the frequency and > likelihood of > the signature case over the script case? Is this a good assumption?  The BIP > only goes as far as to claim that the advantage is apparent if the outputs > *could be spent* as an N of N, but doesn't make representations about > how likely > that N of N case would be in practice compared to the script paths. Perhaps > among use cases, more than half of the ones we expect people to be doing > could be > spent as an N of N. But how frequently would that path get used? > Further, while > the *use cases* might skew toward things with N of N opt-out, we might > end up in > a power law case where it's the one case that doesn't use an N of N opt > out at > all (or at a de minimis level) that becomes very popular, thereby making > Taproot > more costly then beneficial. Its not just about the frequency and likelihood, no. If there is a clearly-provided optimization for this common case in the protocol, then it becomes further more likely that developers put in the additional effort required to make this possibility a reality. This has a very significant positive impact on user privacy, especially those who wish to utilize more advanced functionality in Bitcoin. Further, yes, it is anticipated that the N of N case is possible to take in the vast majority of deployed use-cases for advanced scripting systems, ensuring that it is maximally efficient to do so (and thereby encouraging developers to do so) is a key goal in this work. Matt