Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Dan Libby via bitcoin-dev]

On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:

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

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

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.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

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-requ...@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-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@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 withamount=0
>   (Jorge Tim?n)
>
>
> --
>
> Message: 1
> Date: Tue, 5 Sep 2017 17:41:37 +0200
> From: Pavol Rusnak <st...@satoshilabs.com>
> To: shiva sitamraju <sh...@blockonomics.co>,Bitcoin Protocol
> Discussion <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65...@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 <st...@satoshilabs.com>
> To: Thomas Voegtlin <thom...@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-b89f73e31...@satoshilabs.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> > == === ===
> > VersionPrefix  Description
> > == === ===
> > 0x0488ade4 xprvP2PKH or P2SH
> > 0x0488b21e xpubP2PKH or P2SH
> > 0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
> > 0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
> > 0x04b2430c zprvP2WPKH or P2WSH
> > 0x04b24746 zpubP2WPKH 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 <thom...@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <28d57503-c2b3-7736-bfea-46506636d...@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 05.09.2017 09:10, shiva sitamraju via

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Thomas Voegtlin via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Pavol Rusnak via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

>
> Message: 2
> Date: Fri, 1 Sep 2017 15:40:44 -0400
> From: Thomas Guyot-Sionnest <derm...@aei.ca>
> To: Cserveny Tamas <cserveny.tamas...@gmail.com>,   Bitcoin Protocol
> Discussion <bitcoin-dev@lists.linuxfoundation.org>, Lucas
> Clemente
> Vella <lve...@gmail.com>, Tom Zander <t...@freedommail.ch>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: <e9531342-db9b-ffdf-5ada-0c143eb89...@aei.ca>
> Content-Type: text/plain; charset=windows-1252
>
> On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:
> > 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
> From: Tom Zander <t...@freedommail.ch>
> To: Cserveny Tamas <cserveny.tamas...@gmail.com>
> Cc: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: <3416963.LpSpYe5DLS@strawberry>
> Content-Type: text/plain; charset="us-ascii"
>
> On Friday, 1 September 2017 20:15:53 CEST Cserveny Tamas wrote:
> > 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
> From: Thomas Voegtlin <thom...@electrum.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <5a27e555-173e-b5a7-8c05-5ee32e885...@electrum.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:
>
> >
> > 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
> From: Peter Todd <p...@petertodd.org>
> To: Gregory Maxwell <g...@xiph.org>,Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Fwd:  "Compressed" headers stream
> Message-ID: <20170904140644.GF1276@fedora-23-dvm>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, Aug 28, 2017 at 05:12:15PM +, Gregory Maxwell via bitcoin-dev
> wrote:
> > 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 

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Thomas Voegtlin via bitcoin-dev]

On 30.08.2017 09:24, shiva sitamraju via bitcoin-dev wrote:

> 
> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

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
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev