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 7B031EE4 for ; Tue, 23 Jan 2018 21:38:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E95C3CA for ; Tue, 23 Jan 2018 21:38:14 +0000 (UTC) Received: by mail-vk0-f42.google.com with SMTP id n132so1267000vke.2 for ; Tue, 23 Jan 2018 13:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=uTdKnxnHlDy14pDC2fmuZxljdx7k0pUmNws1jKviChQ=; b=U8SVO4zrnEChWrHjOdNR+dtDqWvKcUPlU5HKijdOMkUINzrTiNXuwq8n1ANtVMjvYr k7+cNG2/fgl1wOpOEQqjKrm8Or2Fe0zZMKsOfQtNZkB9LeqLIGRfYStar97v4z3J6uki a0h7Zkv7sn0wsUW9r+c1v5RuLgDIIEgsoHSasUhV+nkX2nQdh9qiMaJNWhNub0p7soI4 YodfPPKg44wRDxUtoJKQIoMvvctCEca+ovtp/FDEYCUM/ByZAtDbK72uy2owMkFcXzFy GVHrM7sNjlKzNThzCLq3sLqp9Vp38YtEu0/5nXoyvwRElMqYB9CUp7cEyBwE5kAmsaut CBoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=uTdKnxnHlDy14pDC2fmuZxljdx7k0pUmNws1jKviChQ=; b=J2rEcZb9TuSEU1O5fPL0KBwnUcHbJUCh/2p6fb2MB6wsNjrv80tL3V7hflX09nUw7v UitfITK93DHsmGsylNIcUspOvk+Yenz9nq/PGja0vWd2POcklekpqL0ky4l/OQt+RxE2 20bjg8yDA/lcA7fXsKUPh9BMout/G1EKbGETVu7+hRBNqBQT3BjIXpD/cLnYDY4zpm3g 9CZxfhvJaHGEp5ajjCXp6SDDiS3oqJ5jQ8EXACkVMl7yJkRNojyPB0Fpp8zh87Ro8nej 2vj2UF+hKuAqH+vo9UxEyGMiRggifJUkKw85VWMG5AaRRbELPvOXHDb/SmddNDd8ljTO TyhQ== X-Gm-Message-State: AKwxyteBsTNOrSjFvmwxABAV1OC60FnlC5rRGFGQxvc4wwgfl+fY/RjS spaCJ5RrxN1n7t3yw/4TXgQRF1pjLwVZg8yjR+U= X-Google-Smtp-Source: AH8x227+DZl8xNRYSQobL5U6unJW+U+d6zI/BlkvscbcCtJT4bvvBh9fZN/tv5nWbjoOYMNrXfbCtxEKEMkm9XZJcgk= X-Received: by 10.31.195.196 with SMTP id t187mr1703311vkf.182.1516743493998; Tue, 23 Jan 2018 13:38:13 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.78.155 with HTTP; Tue, 23 Jan 2018 13:38:13 -0800 (PST) In-Reply-To: References: <61C1114D-A4E3-4628-AB7E-17C09EDDC2DE@mattcorallo.com> <285E52DF-04E8-4E03-85A0-764F54B3EED9@friedenbach.org> From: Gregory Maxwell Date: Tue, 23 Jan 2018 21:38:13 +0000 X-Google-Sender-Auth: 0JqBP4Vt-jbcCJiBKVPMO1Al12k Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting 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: Tue, 23 Jan 2018 21:38:15 -0000 On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev wrote: > The issue with that approach without support for the privacy-encouraging > wrapper proposed by Greg here is that it encourages adoption halfway and > destroys a lot of the value of the apparent-script monoculture for privacy > preservation. Greg's proposal here doesn't change the format of any specific > MAST implementation, but instead adds the privacy wrapper that I always felt > was missing in existing proposals, without any real additional overhead in > many use-cases! > > Indeed, permissionless innovation is important, but the huge advantage of > providing the privacy wrapper by default here is absolutely massive to the > ecosystem and should not be handwaved away for vague possibly-advantages. Even if to someone who didn't care about anyone's privacy at all, non-taproot is simply inefficient. In the (I argue) overwhelmingly common case of everyone-agrees simple hash based branching requires a 30% overhead to communicate the commitment to the untaken branch (and worse in the case of extensive aggregation). I don't think an argument can be sustained in favor of that kind of communications overhead.