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 C14BDD48 for ; Wed, 18 Sep 2019 21:22:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53FEA81A for ; Wed, 18 Sep 2019 21:22:08 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id i16so918954oie.4 for ; Wed, 18 Sep 2019 14:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wsehmlN0K63bGpMD+skG/dUdV10uU2JiD5XrVdKMSkA=; b=tUxT+h9hLFz5qSFODPurrC90V0awoWml9gup3AHkeZHQdX+SC6wfeeFvS0rrAkVYkU dHeLHZxAp+OAlMwibocKIDPhYC5h16PK+JN5SmgWKsUGW1jYcP81NcfbgLtIXS4xZ6R+ KZBKbdWm//hJeWvUfAofY0acM7SQF8ZZ0+wsF2fvIwcfRjyJ9sbxHdXHWtqoZrI/wn/9 tw/RuijxMdwZJaoqHySv/NPaRLCGi1R3GveZCobR7/P1HuIaWQ8LZGmDE2YNUlpB/lkP nJwbjSPyv1GX7YTVrzaGumEY1W1luOpKkD6h3Xvr6deocZqBH8xe9p//gVGC1gil65wI FkDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wsehmlN0K63bGpMD+skG/dUdV10uU2JiD5XrVdKMSkA=; b=fwd87RuAlfYocm1Lgafx0ZEfwQU490SdJQ58gmBgNqPaAmZFlaHLdCCIfKGhrx+PwA 5/rkzsJpBkC0K7TcJ5Z1xLtVRsLtZ4qPExHD6r95SFaBtw8ydO+xjxxUpxQfYFBdBirN gK8xnLI2CzI9FmwlCj609sepclMNI6cZfBpaxmG5CFm/SF0kJNIOv0TAKgzZ3lkRtIOL hubx1CVgJVDw8FDtCcXfqzIZ/AXDjALuIDHJbNxRtPQlVaj2xPToYr1m0BcQDWRWbvZ1 b6BwA66Xt5lhMi7aAM3fjgeae5gACRQ6UZuqmOR/IhlafwCREZDkbqC3S+3yQmlq3w28 NBjw== X-Gm-Message-State: APjAAAUK/m6uEiVehOVt9FHyN/U1C9hG3IDN69lLs1KpIpi59mmZ9+Vk BIClDMrdeAdT89uCuBC/171OM/Pkf6t6QsT0x8LnLLvP X-Google-Smtp-Source: APXvYqxyDGQdpIQ+RH6aeBsg5+476GH4ZwzsFJl6tYhJSIUw3b/WG2xPpmcsehv5PFXmhnDd5RMPa57wi21cVu6mRZ0= X-Received: by 2002:aca:cd12:: with SMTP id d18mr3587901oig.140.1568841727258; Wed, 18 Sep 2019 14:22:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pieter Wuille Date: Wed, 18 Sep 2019 14:21:56 -0700 Message-ID: To: ZmnSCPxj via bitcoin-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 Cc: John Newbery , Greg Sanders Subject: Re: [bitcoin-dev] Taproot proposal 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: Wed, 18 Sep 2019 21:22:08 -0000 On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev wrote: > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for = segwit > > v0 for compatibility reasons. Most wallets/exchanges/services now suppo= rt sending > > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption)= and that > > will be even more true if Schnorr/Taproot activate in 12+ months time. > > > > Apologies for necroing an ancient thread, but I'm echoing my agreement = with John here. > > We still have plenty of time to have ecosystem upgrade by the time tapr= oot is likely to activate. > On the other hand, the major benefit of taproot is the better privacy and= homogeneity afforded by Taproot, and supporting both P2SH-wrapped and non-= wrapped SegWit v1 addresses simply increases the number of places that a us= er may be characterized and potentially identified. I'm starting to lean towards not allowing P2SH wrapped Taproot as well. Given the progress bech32 adoption has made in the past year or so, I don't think adding P2SH support would result in many more software authors deciding to implement receive-to-taproot functionality. And without that advantage, having the option of supporting P2SH wrapping actually risks degrading the privacy goals it aims for (see ZmnSCPxj's argument above). My main intuition for keeping P2SH is that Segwit was really designed to support both, and I expect that disallowing P2SH would actually require (very slightly) more complex validation code. I don't think this is a sufficiently strong reason, especially as keeping P2SH support does increase the number of combinations software needs to test (both in consensus code and wallets). Cheers, --=20 Pieter