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 64D93BBC for ; Wed, 6 Sep 2017 13:48:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEF1F127 for ; Wed, 6 Sep 2017 13:48:02 +0000 (UTC) Received: by mail-lf0-f45.google.com with SMTP id d17so17868147lfe.2 for ; Wed, 06 Sep 2017 06:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samouraiwallet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=1MuFQcexd84SHrikHUrcTcz/DcwcUJMEZU2XZEEDDPM=; b=cIRNmDWTBzwfQCiaVUeXS5NOtMtUszVofF6aRqZCzzSYAJPH5/R2KnUxDoYtcVHYX/ 4/84EhNkjoi4JP+SjftXSnn5/ONOo4T7U0xITZOdr5cIj+mF9sxx8Y5ngxGE4dS01eZH r5WE1udXh9X09yVPsTKFEcy91LNry9Bj+ZxPPVYtxI/qufFxMFowQlHXMMeKOpPcJiyx 9ub9Al0rvL3zI+kkEi2NyLyDkq9hUV5QqsR53uTN6vqgKDBGhe2WlxTjAE+JUA/ck3RB 7PrXjqseHrq9vkd99LMFKnmkIJaxtpv1HUcTvZFzbVsWvZTuzK18gFDS57EZJXFnwjRH 8gQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=1MuFQcexd84SHrikHUrcTcz/DcwcUJMEZU2XZEEDDPM=; b=swddJ6bKAUGZdoac0L29cZObuSt4oxBHcQsa20JmfiHaU60euovURUMF1NMRAdNFCY 9VXltdV5rrvPq/BWZWkrwirk4bNMK/CUgB/IrhwrlfaBN3jVqnjG+rr0QWzWEwxP8BCW BN79FSTwYCscaWXS5Eb5ArkSDcNpW+bsxq8NKBFzSecuY7C3cXLhkcLAweSOhp1+fvXH pzn3/S0ygTeVH2NDxvb+CT5BQu5DFi4KAvYDeITGlcqGHnBBUT8OyK+tGEs1uD3Wo6Mm 9miIO/xTXV0LrwLCJ4DzQnH4XmrOcWsg5isMGpt8qLCPGjC4UMTYV+m0kvceQ08k2im3 K5EA== X-Gm-Message-State: AHPjjUiBP48cGV/4tTe+ywg4IgEe51ef1AysVx8hgmYO69Xz4fWe91D7 Hwy7SVOO4aIcZbARqdpQNSJDUthN1MXDqZJD7Q== X-Google-Smtp-Source: ADKCNb5yN+KKo0HbTLqsUum2l6ccH6ImTjl+Szpp+0ZBddGIzig6VHyQTZMQT9G3zv8vLCddCQQOFCw/Zyi5kdSURfY= X-Received: by 10.46.86.4 with SMTP id k4mr1073460ljb.8.1504705681116; Wed, 06 Sep 2017 06:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.148.23 with HTTP; Wed, 6 Sep 2017 06:47:20 -0700 (PDT) In-Reply-To: <56a0c721-4bae-7b99-0ca3-d0834756fc31@electrum.org> References: <56a0c721-4bae-7b99-0ca3-d0834756fc31@electrum.org> From: Kabuto Samourai Date: Wed, 6 Sep 2017 08:47:20 -0500 Message-ID: To: Thomas Voegtlin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="94eb2c1a60069d891305588597e6" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 06 Sep 2017 15:18:39 +0000 Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts 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, 06 Sep 2017 13:48:06 -0000 --94eb2c1a60069d891305588597e6 Content-Type: text/plain; charset="UTF-8" > In addition, consensus might be more difficult to reach on that Let's move forward with the simplest solution that solves the problem and achieves consensus! Version bytes {x,y,z} fits the bill. On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On 05.09.2017 21:00, Kabuto Samourai wrote: > > > > The Electrum approach is nice but may not go far enough, as xpub and zpub > > both list "P2PKH or P2SH." Why not expand the number of version prefixes > to > > eliminate the ambiguity? > > > > I agree that this would make sense if we had done it from the start. > However, fixing that now might be difficult. > > My "xyz" proposal extends the current format in a way that is very easy > to deploy, because existing software will require minimal changes. > However, if we eliminate the p2sh ambiguity now, wallets will need to > add extra safeguards, in order to prevent scenarios that are currently > allowed, and they will need to handle legacy xpub/xprv differently than > ypub and zpub. This would take much more time to deploy. > > In addition, consensus might be more difficult to reach on that; I guess > not all developers will not agree that removing that ambiguity is > useful. Since there is an infinity of possible P2SH scripts, it will > never be possible to remove ambiguity from a master key associated to a > P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as > strong. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- -Kabuto PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A B065 320F B934 A79B 6A99 --94eb2c1a60069d891305588597e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0In addition, co= nsensus might be more difficult to reach on that

= Let's move forward with the sim= plest solution that solves the problem and achieves consensus! Version byte= s {x,y,z} fits the bill.

On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitc= oin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:


On 05.09.2017 21:00, Kabuto Samourai wrote:
>
> The Electrum approach is nice but may not go far enough, as xpub and z= pub
> both list "P2PKH or P2SH." Why not expand the number of vers= ion prefixes to
> eliminate the ambiguity?
>

I agree that this would make sense if we had done it from the start.=
However, fixing that now might be difficult.

My "xyz" proposal extends the current format in a way that is ver= y easy
to deploy, because existing software will require minimal changes.
However, if we eliminate the p2sh ambiguity now, wallets will need to
add extra safeguards, in order to prevent scenarios that are currently
allowed, and they will need to handle legacy xpub/xprv differently than
ypub and zpub. This would take much more time to deploy.

In addition, consensus might be more difficult to reach on that; I guess not all developers will not agree that removing that ambiguity is
useful. Since there is an infinity of possible P2SH scripts, it will
never be possible to remove ambiguity from a master key associated to a
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
strong.
______________________________= _________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--
=
-Kabuto

PGP Fingerprint:=C2=A01A83 4A96 EDE7 E286 2C5A =C2=A0B065= 320F B934 A79B 6A99
--94eb2c1a60069d891305588597e6--