path: root/a6/7d1ab881ef475a2927c4b88091ca54b35e1d08

Return-Path: <shiva@blockonomics.co>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C15618D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Sep 2017 05:20:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from blockonomics.co (blockonomics.co [52.10.115.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF37412A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Sep 2017 05:20:53 +0000 (UTC)
Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com
	[209.85.217.174])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by blockonomics.co (Postfix) with ESMTPSA id EE2971F1420
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  6 Sep 2017 05:20:52 +0000 (UTC)
Received: by mail-ua0-f174.google.com with SMTP id s15so11974457uag.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 05 Sep 2017 22:20:52 -0700 (PDT)
X-Gm-Message-State: AHPjjUjTIh2UBvSz9RviyjABjF2l+dDPENmxNZ0VRdB3wm42mdlD26WO
	ZeT+mOfG1LxVuFF6nG3GsJ5hK0BpYw==
X-Google-Smtp-Source: ADKCNb7NJAYAai7wYw0UrDHuFo2C27/kUnaAMr4/VbVs3XhhNi8gPFkdjq4gPj6E85y62DVTttublrp30U8xXInl4Dg=
X-Received: by 10.176.10.29 with SMTP id q29mr783866uah.133.1504675251812;
	Tue, 05 Sep 2017 22:20:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.75.9 with HTTP; Tue, 5 Sep 2017 22:20:31 -0700 (PDT)
From: shiva sitamraju <shiva@blockonomics.co>
Date: Wed, 6 Sep 2017 10:50:31 +0530
X-Gmail-Original-Message-ID: <CABuOfujTuZADkrb_zcWGy0Wx72nEuctMDge2yTXFNYPEzYRO3A@mail.gmail.com>
Message-ID: <CABuOfujTuZADkrb_zcWGy0Wx72nEuctMDge2yTXFNYPEzYRO3A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org, thomasv@electrum.org, 
	stick@satoshilabs.com
Content-Type: multipart/alternative; boundary="94eb2c0e9910e2fe9305587e81b3"
X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,RP_MATCHES_RCVD
	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 05:46:29 +0000
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 05:20:55 -0000

--94eb2c0e9910e2fe9305587e81b3
Content-Type: text/plain; charset="UTF-8"

Hi Thomas,

Can you explain why P2WPKH nested in BIP16 P2SH require a different version
than P2WPKH? It seems to me both would would generate same bitcoin address
in txout and hence would be in the same wallet account.

I am fine with your proposal too. Would be great if you can list all new
versions including testnet ones. I would prefer all testnet ones start with
t (easier to identify) instead of having t,u,v

Thanks



On Wed, Sep 6, 2017 at 3:21 AM, <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: BIP49 Derivation scheme changes (Pavol Rusnak)
>    2. Re: Proposal: bip32 version bytes for segwit scripts
>       (Pavol Rusnak)
>    3. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
>    4. Re: Proposal: bip32 version bytes for segwit scripts (Luke Dashjr)
>    5. Re: Sidechain headers on mainchain (unification of
>       drivechains and spv proofs) (Chris Stewart)
>    6. Re: Proposal: bip32 version bytes for segwit scripts
>       (Thomas Voegtlin)
>    7. SF proposal: prohibit unspendable outputs with    amount=0
>       (Jorge Tim?n)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Sep 2017 17:41:37 +0200
> From: Pavol Rusnak <stick@satoshilabs.com>
> To: shiva sitamraju <shiva@blockonomics.co>,    Bitcoin Protocol
>         Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65e44@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> > 0x042393df ,  sxpr ,   segwit mainnet private key
> > 0x04239377 , sxpb , segwit mainnet public key
> > 0x04222463 , stpb ,  segwit testnet public key
> > 0x042224cc ,  stpr ,  segwit testnet private key
>
> I am fine with both your proposal and proposal from Thomas
> ({x,y,z}{pub,prv}).
>
> Let's just decide ASAP which one we'll use.
>
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Sep 2017 17:44:01 +0200
> From: Pavol Rusnak <stick@satoshilabs.com>
> To: Thomas Voegtlin <thomasv@electrum.org>,     Bitcoin Protocol
>         Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <198be73d-4676-45e9-6e3d-b89f73e31702@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> > ========== =========== ===================================
> > Version    Prefix      Description
> > ========== =========== ===================================
> > 0x0488ade4 xprv        P2PKH or P2SH
> > 0x0488b21e xpub        P2PKH or P2SH
> > 0x049d7878 yprv        (P2WPKH or P2WSH) nested in P2SH
> > 0x049d7cb2 ypub        (P2WPKH or P2WSH) nested in P2SH
> > 0x04b2430c zprv        P2WPKH or P2WSH
> > 0x04b24746 zpub        P2WPKH or P2WSH
> > ========== =========== ===================================
> > (source: http://docs.electrum.org/en/latest/seedphrase.html)
> >
> > I have heard the argument that xpub/xprv serialization is a format for
> > keys, and that it should not be used to encode how these keys are used.
>
> I used this argument for mnemonic/seed, not xpub/xprv. I am fine with
> this proposal of yours, so don't worry.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Sep 2017 18:33:00 +0200
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <28d57503-c2b3-7736-bfea-46506636d999@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> > Hi,
> >
> > Thanks Thomas. The procedure described in
> > http://docs.electrum.org/en/latest/seedphrase.html is really what I was
> > looking for ! I really don't see any point of following BIP49, If
> possible
> > it would be great if you can propose an alternative to BIP49 that follows
> > similar structure to what is used in electrum.
> >
> > I have proposed following changes to BIP32 serialization format
> > https://github.com/bitcoin/bips/blob/master/bip-0032.
> mediawiki#serialization-format
> > to differentiate segwit xpub/xprv. Below the list of new version bytes,
> > resulting base58 prefix and network type:
> >
> > 0x042393df ,  sxpr ,   segwit mainnet private key
> > 0x04239377 , sxpb , segwit mainnet public key
> > 0x04222463 , stpb ,  segwit testnet public key
> > 0x042224cc ,  stpr ,  segwit testnet private key
> >
>
> I have proposed a similar idea, with letters z,y,z combined with pub/prv
> (see the electrum documentation page)
>
> The point is that we need 3 types of keys, not 2, because there are two
> types of segwit output scripts: native and nested in p2sh.
>
> We could use t,u,v for testnet.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 5 Sep 2017 13:03:39 -0400
> From: Luke Dashjr <luke@dashjr.org>
> To: bitcoin-dev@lists.linuxfoundation.org,      Thomas Voegtlin
>         <thomasv@electrum.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <201709051303.43410.luke@dashjr.org>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev
> wrote:
> > I have heard the argument that xpub/xprv serialization is a format for
> > keys, and that it should not be used to encode how these keys are used.
> > However, the very existence of version bytes, and the fact that they are
> > used to signal whether keys will be used on testnet or mainnet goes
> > against that argument.
> >
> > If we do not signal the script type in the version bytes, I believe
> > wallet developers are going to use dirtier tricks, such as the bip32
> > child number field in combination with bip43/bip44/bip49.
>
> I think it makes more sense to use a child number field for this purpose.
> It seems desirable to use the same seed for all different script formats...
>
> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> really doesn't make sense to differentiate segwit specifically.
>
> Luke
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Sep 2017 12:06:32 -0500
> From: Chris Stewart <chris@suredbits.com>
> To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,         Bitcoin Protocol
> Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification
>         of drivechains and spv proofs)
> Message-ID:
>         <CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ZmnSCPxj,
>
> Basically, in case of a sidechain fork, the mainchain considers the longest
> > chain to be valid if it is longer by the SPV proof required length.  In
> the
> > above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> > longer than the other sidechain fork that ended at d.
> >
> > Mainchain nodes can validate this rule because the sidechain headers are
> > embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes
> can
> > validate this part of the sidechain rule of "longest work chain".
> >
>
> What happens in the case that the provided merkle tree hash has a invalid
> transaction in it? Wouldn't this mean that the mainchain nodes would think
> the longest work chain is the valid chain, and it would kill off any
> consensus valid chain that sidechain miners are trying to construct? It
> seems that a malicious miner could extend the chain to whatever the SPV
> proof block height is and make it impossible for the chain to reorg after
> that. I guess if that is a sufficiently long block waiting period it may
> not be a realistic concern, but something to think about any way.
>
> Just a side note -- I think it should be highly recommended that the
> coinbase maturity period on the sidechain to be longer than 288 (or
> whatever we decide on the parameter). This incentivizes the s:miners to
> work together to extend the chain by working with other s:miners (otherwise
> they won't be able to claim their bribes). If they do not work together
> they will not be able to spend their s:coinbase_tx outputs until they
> extend their own sidechain by 288 blocks meaning they need to tie up a
> large amount of capital to go rogue on their fork.
>
> Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op
> code
> <https://github.com/ElementsProject/elements/blob/
> elements-0.14.1/src/script/interpreter.cpp#L1420>
> used in the elements project. Since the cannonical merkle root hashes are
> included in the mainchain, we can provide a merkle proof to the bitcoin
> blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
> post on how OP_WPV works here
> <https://medium.com/@Chris_Stewart_5/what-can-go-wrong-
> when-transferring-coins-into-a-sidechain-with-op-withdrawproofverify-
> b2f49b02ab60>.
> This allows us to prove that a transaction occurred on the sidechain to
> lock up those funds.
>
> -Chris
> ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> attachments/20170905/37b0bcbe/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 5 Sep 2017 20:09:19 +0200
> From: Thomas Voegtlin <thomasv@electrum.org>
> To: Luke Dashjr <luke@dashjr.org>,
>         "bitcoin-dev@lists.linuxfoundation.org"
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
>         scripts
> Message-ID: <41fb5a09-a964-a81b-497e-70a930b6923c@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> 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.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 5 Sep 2017 23:51:45 +0200
> From: Jorge Tim?n <jtimon@jtimon.cc>
> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with
>         amount=0
> Message-ID:
>         <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> This is not a priority, not very important either.
> Right now it is possible to create 0-value outputs that are spendable
> and thus stay in the utxo (potentially forever). Requiring at least 1
> satoshi per output doesn't really do much against a spam attack to the
> utxo, but I think it would be slightly better than the current
> situation.
>
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
> If not, I'm happy to create a BIP with its code, this should be simple.
>
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 28, Issue 6
> ******************************************
>

--94eb2c0e9910e2fe9305587e81b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Thomas,<br><div><br></div>Can you explain why P2WP=
KH nested in BIP16 P2SH require a different version than P2WPKH? It seems t=
o me both would would generate same bitcoin address in txout and hence woul=
d be in the same wallet account.<br></div><div><br></div><div>I am fine wit=
h your proposal too. Would be great if you can list all new versions includ=
ing testnet ones. I would prefer all testnet ones start with t (easier to i=
dentify) instead of having t,u,v <br></div><div><br></div><div>Thanks<br></=
div><div><br></div><div><br></div><div><div><div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Wed, Sep 6, 2017 at 3:21 AM,  <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send bit=
coin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org">bitcoin-dev-request@lists.<wbr>linuxfoundation.org</a><br=
>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org">bitcoin-dev-owner@lists.<wbr>linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. Re: BIP49 Derivation scheme changes (Pavol Rusnak)<br>
=C2=A0 =C2=A02. Re: Proposal: bip32 version bytes for segwit scripts<br>
=C2=A0 =C2=A0 =C2=A0 (Pavol Rusnak)<br>
=C2=A0 =C2=A03. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)<br>
=C2=A0 =C2=A04. Re: Proposal: bip32 version bytes for segwit scripts (Luke =
Dashjr)<br>
=C2=A0 =C2=A05. Re: Sidechain headers on mainchain (unification of<br>
=C2=A0 =C2=A0 =C2=A0 drivechains and spv proofs) (Chris Stewart)<br>
=C2=A0 =C2=A06. Re: Proposal: bip32 version bytes for segwit scripts<br>
=C2=A0 =C2=A0 =C2=A0 (Thomas Voegtlin)<br>
=C2=A0 =C2=A07. SF proposal: prohibit unspendable outputs with=C2=A0 =C2=A0=
 amount=3D0<br>
=C2=A0 =C2=A0 =C2=A0 (Jorge Tim?n)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>-----=
-----<br>
<br>
Message: 1<br>
Date: Tue, 5 Sep 2017 17:41:37 +0200<br>
From: Pavol Rusnak &lt;<a href=3D"mailto:stick@satoshilabs.com">stick@satos=
hilabs.com</a>&gt;<br>
To: shiva sitamraju &lt;<a href=3D"mailto:shiva@blockonomics.co">shiva@bloc=
konomics.co</a>&gt;,=C2=A0 =C2=A0 Bitcoin Protocol<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Discussion &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;=
<br>
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes<br>
Message-ID: &lt;<a href=3D"mailto:9da64df3-c6a9-c232-c801-f379a6d65e44@sato=
shilabs.com">9da64df3-c6a9-c232-c801-<wbr>f379a6d65e44@satoshilabs.com</a>&=
gt;<br>
Content-Type: text/plain; charset=3Dwindows-1252<br>
<br>
On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:<br>
&gt; 0x042393df ,=C2=A0 sxpr ,=C2=A0 =C2=A0segwit mainnet private key<br>
&gt; 0x04239377 , sxpb , segwit mainnet public key<br>
&gt; 0x04222463 , stpb ,=C2=A0 segwit testnet public key<br>
&gt; 0x042224cc ,=C2=A0 stpr ,=C2=A0 segwit testnet private key<br>
<br>
I am fine with both your proposal and proposal from Thomas<br>
({x,y,z}{pub,prv}).<br>
<br>
Let&#39;s just decide ASAP which one we&#39;ll use.<br>
<br>
<br>
--<br>
Best Regards / S pozdravom,<br>
<br>
Pavol &quot;stick&quot; Rusnak<br>
CTO, SatoshiLabs<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 5 Sep 2017 17:44:01 +0200<br>
From: Pavol Rusnak &lt;<a href=3D"mailto:stick@satoshilabs.com">stick@satos=
hilabs.com</a>&gt;<br>
To: Thomas Voegtlin &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@ele=
ctrum.org</a>&gt;,=C2=A0 =C2=A0 =C2=A0Bitcoin Protocol<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Discussion &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;=
<br>
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scripts<br>
Message-ID: &lt;<a href=3D"mailto:198be73d-4676-45e9-6e3d-b89f73e31702@sato=
shilabs.com">198be73d-4676-45e9-6e3d-<wbr>b89f73e31702@satoshilabs.com</a>&=
gt;<br>
Content-Type: text/plain; charset=3Dwindows-1252<br>
<br>
On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D<br>
&gt; Version=C2=A0 =C2=A0 Prefix=C2=A0 =C2=A0 =C2=A0 Description<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D<br>
&gt; 0x0488ade4 xprv=C2=A0 =C2=A0 =C2=A0 =C2=A0 P2PKH or P2SH<br>
&gt; 0x0488b21e xpub=C2=A0 =C2=A0 =C2=A0 =C2=A0 P2PKH or P2SH<br>
&gt; 0x049d7878 yprv=C2=A0 =C2=A0 =C2=A0 =C2=A0 (P2WPKH or P2WSH) nested in=
 P2SH<br>
&gt; 0x049d7cb2 ypub=C2=A0 =C2=A0 =C2=A0 =C2=A0 (P2WPKH or P2WSH) nested in=
 P2SH<br>
&gt; 0x04b2430c zprv=C2=A0 =C2=A0 =C2=A0 =C2=A0 P2WPKH or P2WSH<br>
&gt; 0x04b24746 zpub=C2=A0 =C2=A0 =C2=A0 =C2=A0 P2WPKH or P2WSH<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D<br>
&gt; (source: <a href=3D"http://docs.electrum.org/en/latest/seedphrase.html=
" rel=3D"noreferrer" target=3D"_blank">http://docs.electrum.org/en/<wbr>lat=
est/seedphrase.html</a>)<br>
&gt;<br>
&gt; I have heard the argument that xpub/xprv serialization is a format for=
<br>
&gt; keys, and that it should not be used to encode how these keys are used=
.<br>
<br>
I used this argument for mnemonic/seed, not xpub/xprv. I am fine with<br>
this proposal of yours, so don&#39;t worry.<br>
<br>
--<br>
Best Regards / S pozdravom,<br>
<br>
Pavol &quot;stick&quot; Rusnak<br>
CTO, SatoshiLabs<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 5 Sep 2017 18:33:00 +0200<br>
From: Thomas Voegtlin &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@e=
lectrum.org</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes<br>
Message-ID: &lt;<a href=3D"mailto:28d57503-c2b3-7736-bfea-46506636d999@elec=
trum.org">28d57503-c2b3-7736-bfea-<wbr>46506636d999@electrum.org</a>&gt;<br=
>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
<br>
<br>
On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; Thanks Thomas. The procedure described in<br>
&gt; <a href=3D"http://docs.electrum.org/en/latest/seedphrase.html" rel=3D"=
noreferrer" target=3D"_blank">http://docs.electrum.org/en/<wbr>latest/seedp=
hrase.html</a> is really what I was<br>
&gt; looking for ! I really don&#39;t see any point of following BIP49, If =
possible<br>
&gt; it would be great if you can propose an alternative to BIP49 that foll=
ows<br>
&gt; similar structure to what is used in electrum.<br>
&gt;<br>
&gt; I have proposed following changes to BIP32 serialization format<br>
&gt; <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0032.mediaw=
iki#serialization-format" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.com/bitcoin/<wbr>bips/blob/master/bip-0032.<wbr>mediawiki#serialization-=
format</a><br>
&gt; to differentiate segwit xpub/xprv. Below the list of new version bytes=
,<br>
&gt; resulting base58 prefix and network type:<br>
&gt;<br>
&gt; 0x042393df ,=C2=A0 sxpr ,=C2=A0 =C2=A0segwit mainnet private key<br>
&gt; 0x04239377 , sxpb , segwit mainnet public key<br>
&gt; 0x04222463 , stpb ,=C2=A0 segwit testnet public key<br>
&gt; 0x042224cc ,=C2=A0 stpr ,=C2=A0 segwit testnet private key<br>
&gt;<br>
<br>
I have proposed a similar idea, with letters z,y,z combined with pub/prv<br=
>
(see the electrum documentation page)<br>
<br>
The point is that we need 3 types of keys, not 2, because there are two<br>
types of segwit output scripts: native and nested in p2sh.<br>
<br>
We could use t,u,v for testnet.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 5 Sep 2017 13:03:39 -0400<br>
From: Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a=
>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>,=C2=A0 =C2=A0 =C2=A0 Thomas Voegtlin<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:thomasv@electrum.org">tho=
masv@electrum.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scripts<br>
Message-ID: &lt;<a href=3D"mailto:201709051303.43410.luke@dashjr.org">20170=
9051303.43410.luke@<wbr>dashjr.org</a>&gt;<br>
Content-Type: Text/Plain;=C2=A0 charset=3D&quot;iso-8859-1&quot;<br>
<br>
On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote=
:<br>
&gt; I have heard the argument that xpub/xprv serialization is a format for=
<br>
&gt; keys, and that it should not be used to encode how these keys are used=
.<br>
&gt; However, the very existence of version bytes, and the fact that they a=
re<br>
&gt; used to signal whether keys will be used on testnet or mainnet goes<br=
>
&gt; against that argument.<br>
&gt;<br>
&gt; If we do not signal the script type in the version bytes, I believe<br=
>
&gt; wallet developers are going to use dirtier tricks, such as the bip32<b=
r>
&gt; child number field in combination with bip43/bip44/bip49.<br>
<br>
I think it makes more sense to use a child number field for this purpose.<b=
r>
It seems desirable to use the same seed for all different script formats...=
<br>
<br>
As you note, xpub\xprv are already being used for both P2PKH and P2SH. It<b=
r>
really doesn&#39;t make sense to differentiate segwit specifically.<br>
<br>
Luke<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 5 Sep 2017 12:06:32 -0500<br>
From: Chris Stewart &lt;<a href=3D"mailto:chris@suredbits.com">chris@suredb=
its.com</a>&gt;<br>
To: ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@proton=
mail.com</a>&gt;,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin Protocol Discuss=
ion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of drivechains and spv proofs)<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CAGL6%2BmFHe_SfMea1oMZ3n-=
G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@mail.gmail.com">CAGL6+mFHe_SfMea1oMZ3n-<wbr>G3=
ey9yToAvTMTcfdxJ5qDD1dTXyQ@<wbr>mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Hi ZmnSCPxj,<br>
<br>
Basically, in case of a sidechain fork, the mainchain considers the longest=
<br>
&gt; chain to be valid if it is longer by the SPV proof required length.=C2=
=A0 In the<br>
&gt; above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E=
)<br>
&gt; longer than the other sidechain fork that ended at d.<br>
&gt;<br>
&gt; Mainchain nodes can validate this rule because the sidechain headers a=
re<br>
&gt; embedded in the mainchain block&#39;s coinbase.=C2=A0 Thus, mainchain =
fullnodes can<br>
&gt; validate this part of the sidechain rule of &quot;longest work chain&q=
uot;.<br>
&gt;<br>
<br>
What happens in the case that the provided merkle tree hash has a invalid<b=
r>
transaction in it? Wouldn&#39;t this mean that the mainchain nodes would th=
ink<br>
the longest work chain is the valid chain, and it would kill off any<br>
consensus valid chain that sidechain miners are trying to construct? It<br>
seems that a malicious miner could extend the chain to whatever the SPV<br>
proof block height is and make it impossible for the chain to reorg after<b=
r>
that. I guess if that is a sufficiently long block waiting period it may<br=
>
not be a realistic concern, but something to think about any way.<br>
<br>
Just a side note -- I think it should be highly recommended that the<br>
coinbase maturity period on the sidechain to be longer than 288 (or<br>
whatever we decide on the parameter). This incentivizes the s:miners to<br>
work together to extend the chain by working with other s:miners (otherwise=
<br>
they won&#39;t be able to claim their bribes). If they do not work together=
<br>
they will not be able to spend their s:coinbase_tx outputs until they<br>
extend their own sidechain by 288 blocks meaning they need to tie up a<br>
large amount of capital to go rogue on their fork.<br>
<br>
Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op cod=
e<br>
&lt;<a href=3D"https://github.com/ElementsProject/elements/blob/elements-0.=
14.1/src/script/interpreter.cpp#L1420" rel=3D"noreferrer" target=3D"_blank"=
>https://github.com/<wbr>ElementsProject/elements/blob/<wbr>elements-0.14.1=
/src/script/<wbr>interpreter.cpp#L1420</a>&gt;<br>
used in the elements project. Since the cannonical merkle root hashes are<b=
r>
included in the mainchain, we can provide a merkle proof to the bitcoin<br>
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog<br=
>
post on how OP_WPV works here<br>
&lt;<a href=3D"https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-t=
ransferring-coins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60=
" rel=3D"noreferrer" target=3D"_blank">https://medium.com/@Chris_<wbr>Stewa=
rt_5/what-can-go-wrong-<wbr>when-transferring-coins-into-<wbr>a-sidechain-w=
ith-op-<wbr>withdrawproofverify-<wbr>b2f49b02ab60</a>&gt;.<br>
This allows us to prove that a transaction occurred on the sidechain to<br>
lock up those funds.<br>
<br>
-Chris<br>
?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20170905/37b0bcbe/attachment-0001.html" rel=3D"noreferrer" targ=
et=3D"_blank">http://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<=
wbr>attachments/20170905/37b0bcbe/<wbr>attachment-0001.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 5 Sep 2017 20:09:19 +0200<br>
From: Thomas Voegtlin &lt;<a href=3D"mailto:thomasv@electrum.org">thomasv@e=
lectrum.org</a>&gt;<br>
To: Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>&=
gt;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 scripts<br>
Message-ID: &lt;<a href=3D"mailto:41fb5a09-a964-a81b-497e-70a930b6923c@elec=
trum.org">41fb5a09-a964-a81b-497e-<wbr>70a930b6923c@electrum.org</a>&gt;<br=
>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
<br>
<br>
On 05.09.2017 19:03, Luke Dashjr wrote:<br>
<br>
&gt; It seems desirable to use the same seed for all different script forma=
ts...<br>
<br>
That does not seem desirable to everybody.<br>
<br>
If you want to guarantee that users will be able to recover all their<br>
funds from their mnemonic seed (and that is what they expect), then<br>
wallets must implement all script formats, even the ones that are<br>
deprecated. In addition, the list of script formats that must be<br>
supported is not defined in advance, but it keeps growing. This makes<br>
wallet implementation increasingly difficult. In the long run, seed<br>
portability is guaranteed to fail in such a system.<br>
<br>
&gt; As you note, xpub\xprv are already being used for both P2PKH and P2SH.=
 It<br>
&gt; really doesn&#39;t make sense to differentiate segwit specifically.<br=
>
<br>
That&#39;s not a reason. The fact that xpub/xprv can be used for both P2PKH=
<br>
and P2SH has already resulted in users receiving coins on addresses they<br=
>
do not control.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 5 Sep 2017 23:51:45 +0200<br>
From: Jorge Tim?n &lt;jtimon@jtimon.cc&gt;<br>
To: Bitcoin Dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 amount=3D0<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:CABm2gDojDQWMhw8wW1UkRGKt=
dbby2%2B6AFFZLPuRcUb7WF_u5qQ@mail.gmail.com">CABm2gDojDQWMhw8wW1UkRGKtdbby<=
wbr>2+6AFFZLPuRcUb7WF_u5qQ@mail.<wbr>gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;UTF-8&quot;<br>
<br>
This is not a priority, not very important either.<br>
Right now it is possible to create 0-value outputs that are spendable<br>
and thus stay in the utxo (potentially forever). Requiring at least 1<br>
satoshi per output doesn&#39;t really do much against a spam attack to the<=
br>
utxo, but I think it would be slightly better than the current<br>
situation.<br>
<br>
Is there any reason or use case to keep allowing spendable outputs<br>
with null amounts in them?<br>
<br>
If not, I&#39;m happy to create a BIP with its code, this should be simple.=
<br>
<br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 28, Issue 6<br>
******************************<wbr>************<br>
</blockquote></div><br></div></div></div></div></div>

--94eb2c0e9910e2fe9305587e81b3--