[bitcoin-dev] BIP49 Derivation scheme changes

Discussion:

shiva sitamraju via bitcoin-dev

2017-08-30 07:24:13 UTC

Hi,

I wanted to discuss few changes in BIP49

*- Breaking backwards compatibility *
The BIP talks about breaking this, and but it really doesn't. I really
feel it should completely break this. Here is why

What would happen if you recover a wallet using seed words ?
1. Since there is no difference in seed words between segwit/non segwit,
the wallet would discover both m/44' and m/49' accounts
2. Note that we cannot ask the user to choose an account he wants to
operate on (Segwit/Non segwit). This is like asking him the HD derivation
path and a really bad UI
3. The wallet now has to constantly monitor both m/44' and m/49' accounts
for transactions

Basically we are always stuck with keeping compatibility with older seed
words or always asking the user if the seed words came from segwit/non
segwit wallet !

Here is my suggestion :
1. By default all new wallets will be created as segwit m/49' without
asking user anything. I think you would agree with me that in future we
want most wallet to be default segwit (unless user chooses a non segwit
from advanced options)!

2. Segwit wallet seed words have a different format which is incompatible
with previous wallet seed words. This encodes the information that this
wallet is segwit in the seed words itself. We need to define a structure
for this

*- XPUB Derivation*
This is something not addressed in the BIP yet.

1. Right now you can get an xpub balance/transaction history. With m/49'
there is no way to know whether an xpub is from m/44' or m/49'

2. This breaks lots of things. Wallets like electrum/armory/mycelium
<https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954>support
importing xpub as a watch only wallet. Also services like blockonomics/
blockchain.info use xpub for displaying balance/generating merchant
addresses

Looking forward to hearing your thoughts

Thomas Voegtlin via bitcoin-dev

2017-09-03 05:19:12 UTC

Permalink

Post by shiva sitamraju via bitcoin-dev
2. Segwit wallet seed words have a different format which is incompatible
with previous wallet seed words. This encodes the information that this
wallet is segwit in the seed words itself. We need to define a structure
for this

That is what Electrum does.
See http://docs.electrum.org/en/latest/seedphrase.html

shiva sitamraju via bitcoin-dev

2017-09-05 07:10:15 UTC

Permalink

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

Let me know your thoughts

On Tue, Sep 5, 2017 at 12:12 AM, <

Send bitcoin-dev mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
1. Re: Horizontal scaling of blockchain (Cserveny Tamas)
2. Re: Horizontal scaling of blockchain (Thomas Guyot-Sionnest)
3. Re: Horizontal scaling of blockchain (Tom Zander)
4. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
5. Re: Fwd: "Compressed" headers stream (Peter Todd)
6. Re: "Compressed" headers stream (Peter Todd)
----------------------------------------------------------------------
Message: 1
Date: Fri, 01 Sep 2017 18:15:53 +0000
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
<CACY+MSOPWhTnR-ZR67T1a5ZU2w4pWa6FkXsGF3_C+
Content-Type: text/plain; charset="utf-8"
Yes. I meant the single thread as an analogy, if a block is found, other
blocks are worthless. (more or less) Longest chain wins.
My line of though was, that currently the only way to scale with the
traffic (and lowering the fees) is increasing the block size (which is hard
as I learned from recent events), or reducing the complexity which is less
secure (most likely more controversial)
Splitting the chain is effectively increasing the block size, but without
the increased hashing and validation overhead.
The usage growth seems to be more of exponential rather than linear. Sooner
or later the block size will need to be 4 mb then 40 mb, then what is the
real limit? Otherwise waiting times and thus the fees will just grow
rapidly. I don't think that it is desirable.
With splitting the ledger, the block size can remain 1-2 mb for long time,
only new partitions needs to be added on a schedule. This would also make
better use of the hashing capacity.
Cheers,
Tamas

The current chain is effectively single threaded.
This is not true, since xthin/compactblocks have been introduced we
completely removed this bottle-neck.
The transactions will be validated continuously, in parallel and not

just

when a block is found.

If I understood correctly, OP was not talking about the process inside a
node being single threaded, but instead that the whole bitcoin

distributed

system behaves as single threaded computation. OP seems to be describing

system closer to what IOTA uses, by distributing among the miners the

task

of validating the transactions. Although, without more specific details,

is hard to judge the benefits.
--
Lucas Clemente Vella

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20170901/d908e965/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 1 Sep 2017 15:40:44 -0400
Clemente
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Content-Type: text/plain; charset=windows-1252

Yes. I meant the single thread as an analogy, if a block is found,
other blocks are worthless. (more or less) Longest chain wins.
My line of though was, that currently the only way to scale with the
traffic (and lowering the fees) is increasing the block size (which is
hard as I learned from recent events), or reducing the complexity
which is less secure (most likely more controversial)

It wouldn't be less secure as long as you adjust the confirmation
accordingly. If we decided to mine one block every minute, then your
usual 6 confirmation should become 60 confirmation. In the end, the same
amount of work will have been done to prove the transaction is legit and
so it's just as secure... Actually, one could argue since the average
hash rate over 60 block is more accurate than over 6, it's actually more
secure if you also pay attention to hash rate variation as part of the
confirmation... That help in the scenario a very large pool goes dark to
mine a sidechain.
--
Thomas
------------------------------
Message: 3
Date: Sat, 02 Sep 2017 23:13:57 +0200
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
Content-Type: text/plain; charset="us-ascii"

The usage growth seems to be more of exponential rather than linear.
Sooner or later the block size will need to be 4 mb then 40 mb, then what
is the real limit? Otherwise waiting times and thus the fees will just
grow rapidly. I don't think that it is desirable.

The real limit is set by the technology. Just like in 1990 we could not
fathom having something like YouTube and high-res video streaming
(Netflix),
the limits of what is possible continually shifts.
This is basically how any successful product has ever grown, I think that
it
is not just desirable, it is inevitable.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
------------------------------
Message: 4
Date: Sun, 3 Sep 2017 07:19:12 +0200
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
Content-Type: text/plain; charset=utf-8

2. Segwit wallet seed words have a different format which is incompatible
with previous wallet seed words. This encodes the information that this
wallet is segwit in the seed words itself. We need to define a structure
for this

That is what Electrum does.
See http://docs.electrum.org/en/latest/seedphrase.html
------------------------------
Message: 5
Date: Mon, 4 Sep 2017 10:06:44 -0400
Subject: Re: [bitcoin-dev] Fwd: "Compressed" headers stream
Content-Type: text/plain; charset="us-ascii"
On Mon, Aug 28, 2017 at 05:12:15PM +0000, Gregory Maxwell via bitcoin-dev

You are leaving a lot of bytes on the table.
The bits field can only change every 2016 blocks (4 bytes per header),
the timestamp can not be less than the median of the last 11 and is
usually only a small amount over the last one (saves 2 bytes per
header), the block version is usually one of the last few (save 3
bytes per header).
But all these things improvements are just a constant factor. I think
you want the compact SPV proofs described in the appendix of the
sidechains whitepaper which creates log scaling proofs.

Note that I'm already planning on OpenTimestamps having infrastructure for
trusted validity attestations; log scaling proofs alone only prove total
work,
not validity. Timestamping has all kinds of very dubious security
properties
when done via proof-of-work, due to various ways that miners can get away
with
inaccurate block times. In particular, setting a block time backwards is
something that miners can do, particularly with majority hashing power,
which
is the exact thing we're trying to prevent in a timestamp proof.
This all makes me dubious about risking further weakening of this already
weak
security with compact SPV proofs; we'd need a lot more analysis to
understand
what we're risking. Also note that we can ship a known-good
sum-merkle-tree tip hash with the software, which further reduces initial
download bandwidth needed to get the block headers on top of this obviously
safe eliding of redundant hashes.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20170904/8be560f7/attachment-0001.sig>
------------------------------
Message: 6
Date: Mon, 4 Sep 2017 10:10:17 -0400
Discussion
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Content-Type: text/plain; charset="us-ascii"
On Mon, Aug 28, 2017 at 12:26:48PM -0400, Greg Sanders via bitcoin-dev

Well, if anything my question may bolster your use-case. If there's a
heavier chain that is invalid, I kind of doubt it matters for

timestamping

reasons.

Timestamping can easily be *more* vulnerable to malicious miners than
financial
applications for a number of reasons, including the fact that there's no
financial feedback loop of miners destroying the value of the coins they
produce - timestamping is a non-financial piggy-back application that
doesn't
directly interact with the Bitcoin economy, beyond a trival number of
timestamp
transactions.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20170904/818e9344/attachment.sig>
------------------------------
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 28, Issue 3
******************************************

Pavol Rusnak via bitcoin-dev

2017-09-05 15:41:37 UTC

Permalink

Post by shiva sitamraju via bitcoin-dev
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

Thomas Voegtlin via bitcoin-dev

2017-09-05 16:33:00 UTC

Permalink

Post by shiva sitamraju via bitcoin-dev
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,
0x042393df , sxpr , segwit mainnet private key
0x04239377 , sxpb , segwit mainnet public key
0x04222463 , stpb , segwit testnet public key
0x042224cc , stpr , segwit testnet private key

shiva sitamraju via bitcoin-dev

2017-09-06 05:20:31 UTC

Permalink

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, <

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
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Content-Type: text/plain; charset=windows-1252

Post by shiva sitamraju via bitcoin-dev
========== =========== ===================================
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
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
Content-Type: text/plain; charset=utf-8

possible

Post by shiva sitamraju via bitcoin-dev
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

Post by shiva sitamraju via bitcoin-dev
to differentiate segwit xpub/xprv. Below the list of new version bytes,
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
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Content-Type: Text/Plain; charset="iso-8859-1"
On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev

Post by shiva sitamraju via bitcoin-dev
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
Discussion
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification
of drivechains and spv proofs)
mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the longest

Post by shiva sitamraju via bitcoin-dev
chain to be valid if it is longer by the SPV proof required length. In

the

Post by shiva sitamraju via bitcoin-dev
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

Post by shiva sitamraju via bitcoin-dev
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
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
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Content-Type: text/plain; charset=utf-8

Post by shiva sitamraju via bitcoin-dev
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.

Post by shiva sitamraju via bitcoin-dev
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
Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with
amount=0
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 28, Issue 6
******************************************

Dan Libby via bitcoin-dev

2017-09-06 07:19:31 UTC

Permalink

Post by shiva sitamraju via bitcoin-dev
What would happen if you recover a wallet using seed words ?
1. Since there is no difference in seed words between segwit/non
segwit, the wallet would discover both m/44' and m/49' accounts
2. Note that we cannot ask the user to choose an account he wants to
operate on (Segwit/Non segwit). This is like asking him the HD
derivation path and a really bad UI
3. The wallet now has to constantly monitor both m/44' and m/49'
accounts for transactions

small nit with 3.

It seems to me that the wallet would perform initial discovery on m/44
and m/49, and then would find transactions at one or the other, so it
can then record the type somewhere and from then on need only monitor
one branch.

Still, I agree it is ugly, makes initial discovery up to 2x slower, etc.

Post by shiva sitamraju via bitcoin-dev
*- XPUB Derivation*
This is something not addressed in the BIP yet.
1. Right now you can get an xpub balance/transaction history. With m/49'
there is no way to know whether an xpub is from m/44' or m/49'
2. This breaks lots of things. Wallets like electrum/armory/mycelium
<https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954>support
importing xpub as a watch only wallet. Also services like
blockonomics/blockchain.info <http://blockchain.info> use xpub for
displaying balance/generating merchant addresses
Looking forward to hearing your thoughts

speaking as author of tools hd-wallet-addrs and hd-wallet-derive, I
agree this is problematic.

would be great if xpub/xprv could somehow encode their absolute path in
wallet for tools to read. Users cannot be expected to know.