Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-23 📝 Original message:On Tue, Jan 23, 2018 at ...
📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at 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.
📝 Original message:On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev at 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.