📅 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.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:10:07
in reply to nevent1q…x8dd
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 18:10:07Event JSON
{
"id": "14bfb94ed79e882204b76807dc2bb4ae08d16fefc46bd0f67360e81cdd12b538",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161407,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"2bb6920046516a388e81f2a4b52285905096da968e749a7df65ccfe3d4108d05",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2018-01-23\n📝 Original message:On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e The issue with that approach without support for the privacy-encouraging\n\u003e wrapper proposed by Greg here is that it encourages adoption halfway and\n\u003e destroys a lot of the value of the apparent-script monoculture for privacy\n\u003e preservation. Greg's proposal here doesn't change the format of any specific\n\u003e MAST implementation, but instead adds the privacy wrapper that I always felt\n\u003e was missing in existing proposals, without any real additional overhead in\n\u003e many use-cases!\n\u003e\n\u003e Indeed, permissionless innovation is important, but the huge advantage of\n\u003e providing the privacy wrapper by default here is absolutely massive to the\n\u003e ecosystem and should not be handwaved away for vague possibly-advantages.\n\nEven if to someone who didn't care about anyone's privacy at all,\nnon-taproot is simply inefficient. In the (I argue) overwhelmingly\ncommon case of everyone-agrees simple hash based branching requires a\n30% overhead to communicate the commitment to the untaken branch (and\nworse in the case of extensive aggregation). I don't think an\nargument can be sustained in favor of that kind of communications\noverhead.",
"sig": "6a31c164ade43b69798f85bd71af4247d9c5c8a571ce35b52a6f2ee1eb486c523509bc086f751ceca3486733361fac55943cef0466e762f9c461cec87f9423b1"
}