MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <EC722F53-3D41-4309-8942-7B27E4DA6EAA@mattcorallo.com>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
	<61C1114D-A4E3-4628-AB7E-17C09EDDC2DE@mattcorallo.com>
	<285E52DF-04E8-4E03-85A0-764F54B3EED9@friedenbach.org>
	<EC722F53-3D41-4309-8942-7B27E4DA6EAA@mattcorallo.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 23 Jan 2018 21:38:13 +0000
Message-ID: <CAAS2fgSBQCov3YUSHXO6b8RX54382AH2_u_hAAZgivDqH3SHTA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.