Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 243E77A9 for ; Tue, 5 Sep 2017 19:00:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52592406 for ; Tue, 5 Sep 2017 19:00:47 +0000 (UTC) Received: by mail-lf0-f46.google.com with SMTP id q132so12872357lfe.5 for ; Tue, 05 Sep 2017 12:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samouraiwallet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=4Uubnw5g/fKdrvobW0iF3B/+m/zy1sh0p95+QaHiguw=; b=OdO0y7XGzM2Bq3OIz6XAFPaTZ2w/1a2xW3dCu9W9+E/FqWn5VDUfDBgLtfkb0to+N7 FTOZzlgguB4EXBMr4VsswqrbY/dXt1RLFjEpniL5xbD7/HiJP8VYTkPbYftlSopoeSgd +nmTq75vQZ/3e8uGBGIZaFoW4cXpQTcrkWAokJlOzTuxylmYJK4bITzmL60Oxf4HbLy0 zj2GLQAiWnxShjA/wGKtiDfGJ6efSe+ny91ZSGu4jI5HACEB27jb/1UMZJG/eW/N0LdM bVpsp5HWKhVnQaX1KOsJVuuppQ9ATHTvZKKmsfVrRJRyO277pmm9r+TmCcR/ByAwXEqX t5PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4Uubnw5g/fKdrvobW0iF3B/+m/zy1sh0p95+QaHiguw=; b=ZmdjSfs8rSmiGSwKNe5DY2bOR27lRi3jpZkk7numoSx07bqx5mUAh2Oq5betl/V7CN pNektHRg5KaijznOa14svRsOQxjh5y+RtprOckif1b05chPEgDMdtkDgWP6y9QT6VSOg nRRXhKO+Q+3qr4warsXXvZE6NkX0CoyMpFcsAUMVxAW1hP6e1IDSgYK07Sauo3QdhvIE iu5UKYoUMZTSWfk15rhx0kIRwCdJTmKXI9qKva0M/oLBFK3nqnbOB5jXQN8J/futT+of 9trVsQBW3r0rVv2HBQsczA/s8EUfT31jTjb4ELoLpevanRgwgxXU69qRWBsMWLsiCIEz pqww== X-Gm-Message-State: AHPjjUjDLRzedzjr5jRHbn4zEahrsEA5H2WCLgjM88kO7Ff14FYr87Wr A5cIqldOavDb021oJFFhu70EY354PxID X-Google-Smtp-Source: ADKCNb5nfxXyEfMyzNVwVJrdsN+aX2nH4GPrsxlPNNMFxuKFX+nUofxB2BEI9xS/+a/6sCRrLFaRqc0jvgqS9Luc6qw= X-Received: by 10.46.69.134 with SMTP id s128mr11200lja.161.1504638045509; Tue, 05 Sep 2017 12:00:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.148.23 with HTTP; Tue, 5 Sep 2017 12:00:04 -0700 (PDT) From: Kabuto Samourai Date: Tue, 5 Sep 2017 14:00:04 -0500 Message-ID: To: Thomas Voegtlin , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114b0f8e37efcc055875d899" 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: Tue, 05 Sep 2017 23:47:33 +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: Tue, 05 Sep 2017 19:00:48 -0000 --001a114b0f8e37efcc055875d899 Content-Type: text/plain; charset="UTF-8" We support a change to the version bits of the HD serialization that will inform the receiving utility of the exact derivation method used for the pubkeys. Third-parties handling xpubs must not require additional information from the user about the derivation path or serialization format of the addresses under that xpub. When you have to ask, "Is this a SegWit xpub?" then you've already lost. Avoiding a total UX nightmare is in everyone's interests. I think Luke and Thomas may be talking past one another. When exporting a root master HD seed, encoding the {x,y,z}{pub,prv} distinctions makes no sense, as the root seed should derive all paths for all coins. Wallets may need additional code to discover which paths have been used when importing a root seed. But when exporting / importing an account-level seed for watch-only and receive address generation, changing the serialization version bytes is appropriate and (in our view) essential to avoid loss of funds. 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? On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On 05.09.2017 19:03, Luke Dashjr wrote: > > > It seems desirable to use the same seed for all different script > formats... > > That does not seem desirable to everybody. > > If you want to guarantee that users will be able to recover all their > funds from their mnemonic seed (and that is what they expect), then > wallets must implement all script formats, even the ones that are > deprecated. In addition, the list of script formats that must be > supported is not defined in advance, but it keeps growing. This makes > wallet implementation increasingly difficult. In the long run, seed > portability is guaranteed to fail in such a system. > > > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It > > really doesn't make sense to differentiate segwit specifically. > > That's not a reason. The fact that xpub/xprv can be used for both P2PKH > and P2SH has already resulted in users receiving coins on addresses they > do not control. > _______________________________________________ > 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 --001a114b0f8e37efcc055875d899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We support a change to the version bits of the HD ser= ialization that will inform the receiving utility of the exact derivation m= ethod used for the pubkeys. Third-parties handling xpubs must not require a= dditional information from the user about the derivation path or serializat= ion format of the addresses under that xpub. When you have to ask, "Is= this a SegWit xpub?" then you've already lost.

=
Avoiding a total UX nightmare is in everyone's interests.

I think Luke and Thomas may be talking past one anot= her. When exporting a root master HD seed, encoding the {x,y,z}{pub,prv} di= stinctions makes no sense, as the root seed should derive all paths for all= coins. Wallets may need additional code to discover which paths have been = used when importing a root seed. But when exporting / importing an account-= level seed for watch-only and receive address generation, changing the seri= alization version bytes is appropriate and (in our view) essential to avoid= loss of funds.

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?=


On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<= br>


On 05.09.2017 19:03, Luke Dashjr wrote:

> It seems desirable to use the same seed for all different script forma= ts...

That does not seem desirable to everybody.

If you want to guarantee that users will be able to recover all their
funds from their mnemonic seed (and that is what they expect), then
wallets must implement all script formats, even the ones that are
deprecated. In addition, the list of script formats that must be
supported is not defined in advance, but it keeps growing. This makes
wallet implementation increasingly difficult. In the long run, seed
portability is guaranteed to fail in such a system.

> As you note, xpub\xprv are already being used for both P2PKH and P2SH.= It
> really doesn't make sense to differentiate segwit specifically.
That's not a reason. The fact that xpub/xprv can be used for both P2PKH=
and P2SH has already resulted in users receiving coins on addresses they do not control.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--
-Kabuto

PGP Fingerprint:=C2=A01A83 4= A96 EDE7 E286 2C5A =C2=A0B065 320F B934 A79B 6A99
<= /div>
--001a114b0f8e37efcc055875d899--