New BIP32 structure

> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we
> brainstormed to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
>   * cointype:  This is zero for Bitcoin. This is here to support two
>     things, one is supporting alt coins based off the same root seed.
>     Right now nobody seemed very bothered about alt coins but sometimes
>     feature requests do come in for this. Arguably there is no need and
>     alt coins could just use the same keys as Bitcoin, but it may help
>     avoid confusion if they don't.
>
>     More usefully, cointype can distinguish between keys intended for
>     things like multisig outputs, e.g. for watchdog services. This means
>     if your wallet does not know about the extra protocol layers
>     involved in this, it can still import the "raw" money and it will
>     just ignore/not see the keys used in more complex transactions.
>
>   * reserved is for "other stuff". I actually don't recall why we ended
>     up with this. It may have been intended to split out multisig
>     outputs etc from cointype. Marek, Thomas?
>
>   * account is for keeping essentially wallets-within-a-wallet to avoid
>     mixing of coins. If you want that.
>
>   * change is 0 for receiving addresses, 1 for change addresses.
>
>   * n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw
> v1 so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet
> all the users needs, whilst still allowing some drift between what
> wallets support.
>
> Pieter made the I think valid point that you can't really encode how
> keys are meant to be used into just an HDW hierarchy and normally you'd
> need some metadata as well. However, I feel interop between wallets is
> more important than arriving at the most perfect possible arrangement,
> which feels a little like bikeshedding, so I'm happy to just go with the
> flow on this one.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>>   /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>>   * cointype:  This is zero for Bitcoin. This is here to support two
>>     things, one is supporting alt coins based off the same root seed.
>>     Right now nobody seemed very bothered about alt coins but sometimes
>>     feature requests do come in for this. Arguably there is no need and
>>     alt coins could just use the same keys as Bitcoin, but it may help
>>     avoid confusion if they don't.
>>
>>     More usefully, cointype can distinguish between keys intended for
>>     things like multisig outputs, e.g. for watchdog services. This means
>>     if your wallet does not know about the extra protocol layers
>>     involved in this, it can still import the "raw" money and it will
>>     just ignore/not see the keys used in more complex transactions.
>>
>>   * reserved is for "other stuff". I actually don't recall why we ended
>>     up with this. It may have been intended to split out multisig
>>     outputs etc from cointype. Marek, Thomas?
>>
>>   * account is for keeping essentially wallets-within-a-wallet to avoid
>>     mixing of coins. If you want that.
>>
>>   * change is 0 for receiving addresses, 1 for change addresses.
>>
>>   * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
>    - cointype:  This is zero for Bitcoin. This is here to support two
>    things, one is supporting alt coins based off the same root seed. Right now
>    nobody seemed very bothered about alt coins but sometimes feature requests
>    do come in for this. Arguably there is no need and alt coins could just use
>    the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
>    More usefully, cointype can distinguish between keys intended for
>    things like multisig outputs, e.g. for watchdog services. This means if
>    your wallet does not know about the extra protocol layers involved in this,
>    it can still import the "raw" money and it will just ignore/not see the
>    keys used in more complex transactions.
>
>    - reserved is for "other stuff". I actually don't recall why we ended
>    up with this. It may have been intended to split out multisig outputs etc
>    from cointype. Marek, Thomas?
>
>    - account is for keeping essentially wallets-within-a-wallet to avoid
>    mixing of coins. If you want that.
>
>    - change is 0 for receiving addresses, 1 for change addresses.
>
>    - n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1
> so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all
> the users needs, whilst still allowing some drift between what wallets
> support.
>
> Pieter made the I think valid point that you can't really encode how keys
> are meant to be used into just an HDW hierarchy and normally you'd need
> some metadata as well. However, I feel interop between wallets is more
> important than arriving at the most perfect possible arrangement, which
> feels a little like bikeshedding, so I'm happy to just go with the flow on
> this one.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
>    - cointype:  This is zero for Bitcoin. This is here to support two
>    things, one is supporting alt coins based off the same root seed. Right now
>    nobody seemed very bothered about alt coins but sometimes feature requests
>    do come in for this. Arguably there is no need and alt coins could just use
>    the same keys as Bitcoin, but it may help avoid confusion if they don't.

>  This might be tangential, but the comment about "refund" chains reminded
> me.  Armory will be implementing multi-sig/linked wallets where a each
> device has a parallel HDW branch and produces P2SH addresses.  For those
> types of wallets, I plan to allocate two chains *per signing authority*.
> If you have a shared 2-of-2 wallet split between your phone and your
> spouse's phone, your phone would distribute addresses on P2SH chain 0 and
> generate change addresses on P2SH chain 1.  Your spouse's phone would use
> chains 2 and 3.
>
> So if you and your spouse switch to a new app that supports M-of-N linked
> wallets, it should search for coin history along the first 2*N chains.
>

>
> -Alan
>
>
>
>
> On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
>
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>
>  Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we
> brainstormed to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
>   * cointype:  This is zero for Bitcoin. This is here to support two
>     things, one is supporting alt coins based off the same root seed.
>     Right now nobody seemed very bothered about alt coins but sometimes
>     feature requests do come in for this. Arguably there is no need and
>     alt coins could just use the same keys as Bitcoin, but it may help
>     avoid confusion if they don't.
>
>     More usefully, cointype can distinguish between keys intended for
>     things like multisig outputs, e.g. for watchdog services. This means
>     if your wallet does not know about the extra protocol layers
>     involved in this, it can still import the "raw" money and it will
>     just ignore/not see the keys used in more complex transactions.
>
>   * reserved is for "other stuff". I actually don't recall why we ended
>     up with this. It may have been intended to split out multisig
>     outputs etc from cointype. Marek, Thomas?
>
>   * account is for keeping essentially wallets-within-a-wallet to avoid
>     mixing of coins. If you want that.
>
>   * change is 0 for receiving addresses, 1 for change addresses.
>
>   * n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw
> v1 so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet
> all the users needs, whilst still allowing some drift between what
> wallets support.
>
> Pieter made the I think valid point that you can't really encode how
> keys are meant to be used into just an HDW hierarchy and normally you'd
> need some metadata as well. However, I feel interop between wallets is
> more important than arriving at the most perfect possible arrangement,
> which feels a little like bikeshedding, so I'm happy to just go with the
> flow on this one.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge•nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>  ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge•nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure our BIP32 wallet structures would be compatible - and I discovered that only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between wallets with regards to importing 12-words paper wallets, we brainstormed to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
> cointype:  This is zero for Bitcoin. This is here to support two things, one is supporting alt coins based off the same root seed. Right now nobody seemed very bothered about alt coins but sometimes feature requests do come in for this. Arguably there is no need and alt coins could just use the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
> More usefully, cointype can distinguish between keys intended for things like multisig outputs, e.g. for watchdog services. This means if your wallet does not know about the extra protocol layers involved in this, it can still import the "raw" money and it will just ignore/not see the keys used in more complex transactions.
>
> reserved is for "other stuff". I actually don't recall why we ended up with this. It may have been intended to split out multisig outputs etc from cointype. Marek, Thomas?
>
> account is for keeping essentially wallets-within-a-wallet to avoid mixing of coins. If you want that.
>
> change is 0 for receiving addresses, 1 for change addresses.
>
> n is the actual key index
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1 so I would just set the first three values all to zero and that is a perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all the users needs, whilst still allowing some drift between what wallets support.
>
> Pieter made the I think valid point that you can't really encode how keys are meant to be used into just an HDW hierarchy and normally you'd need some metadata as well. However, I feel interop between wallets is more important than arriving at the most perfect possible arrangement, which feels a little like bikeshedding, so I'm happy to just go with the flow on this one.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet),
> Jan Moller, Andreas  Petersson (Mycelium), Thomas V (Electrum), Tamas
> Blummer, Tamas Bartfai (Bits of Proof)
> at the Inside Bitcoin Conference in Berlin.
>
> I remember that there were different opinions on how to use a hierarchy
> and it did seem to me they could eventually be "standardized" for the
> retail customer but definitelly not for corporate use,
> where hierarchy will certainly map to organisational hierarchy or cost
> centres.
>
> A notable suggestion was to instead of building a directory of magic
> numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word
> "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 26.03.2014, at 21:49, Mike Hearn <mike@plan99•net> wrote:
>
> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
> our BIP32 wallet structures would be compatible - and I discovered that
> only I was planning to use the default structure.
>
> Because I'm hopeful that we can get a lot of interoperability between
> wallets with regards to importing 12-words paper wallets, we brainstormed
> to find a structure acceptable to everyone and ended up with:
>
>   /m/cointype/reserved'/account'/change/n
>
> The extra levels require some explanation:
>
>    - cointype:  This is zero for Bitcoin. This is here to support two
>    things, one is supporting alt coins based off the same root seed. Right now
>    nobody seemed very bothered about alt coins but sometimes feature requests
>    do come in for this. Arguably there is no need and alt coins could just use
>    the same keys as Bitcoin, but it may help avoid confusion if they don't.
>
>    More usefully, cointype can distinguish between keys intended for
>    things like multisig outputs, e.g. for watchdog services. This means if
>    your wallet does not know about the extra protocol layers involved in this,
>    it can still import the "raw" money and it will just ignore/not see the
>    keys used in more complex transactions.
>
>    - reserved is for "other stuff". I actually don't recall why we ended
>    up with this. It may have been intended to split out multisig outputs etc
>    from cointype. Marek, Thomas?
>
>    - account is for keeping essentially wallets-within-a-wallet to avoid
>    mixing of coins. If you want that.
>
>    - change is 0 for receiving addresses, 1 for change addresses.
>
>    - n is the actual key index
>
> For bitcoinj we're targeting a deliberately limited feature set for hdw v1
> so I would just set the first three values all to zero and that is a
> perfectly fine way to be compatible.
>
> The goal here is that the same seed can be written down once, and meet all
> the users needs, whilst still allowing some drift between what wallets
> support.
>
> Pieter made the I think valid point that you can't really encode how keys
> are meant to be used into just an HDW hierarchy and normally you'd need
> some metadata as well. However, I feel interop between wallets is more
> important than arriving at the most perfect possible arrangement, which
> feels a little like bikeshedding, so I'm happy to just go with the flow on
> this one.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>

> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.

> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.

>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>>    /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>>    * cointype:  This is zero for Bitcoin. This is here to support two
>>      things, one is supporting alt coins based off the same root seed.
>>      Right now nobody seemed very bothered about alt coins but sometimes
>>      feature requests do come in for this. Arguably there is no need and
>>      alt coins could just use the same keys as Bitcoin, but it may help
>>      avoid confusion if they don't.
>>
>>      More usefully, cointype can distinguish between keys intended for
>>      things like multisig outputs, e.g. for watchdog services. This means
>>      if your wallet does not know about the extra protocol layers
>>      involved in this, it can still import the "raw" money and it will
>>      just ignore/not see the keys used in more complex transactions.
>>
>>    * reserved is for "other stuff". I actually don't recall why we ended
>>      up with this. It may have been intended to split out multisig
>>      outputs etc from cointype. Marek, Thomas?
>>
>>    * account is for keeping essentially wallets-within-a-wallet to avoid
>>      mixing of coins. If you want that.
>>
>>    * change is 0 for receiving addresses, 1 for change addresses.
>>
>>    * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

>
>   * reserved is for "other stuff". I actually don't recall why we ended
>     up with this. It may have been intended to split out multisig
>     outputs etc from cointype. Marek, Thomas?
>

> A notable suggestion was to instead of building a directory of magic numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.

>    - cointype:  This is zero for Bitcoin. This is here to support two
>    things, one is supporting alt coins based off the same root seed. Right now
>    nobody seemed very bothered about alt coins but sometimes feature requests

>
> One issue that I have is bandwidth: Electrum (and mycelium) cannot
> watch as many addresses as they want, because this will create too
> much traffic on the servers. (especially when servers send utxo merkle
> proofs for each address, which is not the case yet, but is planned)
>

> My opinion, as far as Electrum is concerned, is that merchant accounts
> should behave differently from regular user accounts: While merchants
> need to generate an unlimited number of receiving addresses, it is also
> acceptable for them to have a slightly more complex wallet recovery
> procedure
>

> but also because we want fully automated synchronization between different
> instances of a wallet, using only no other source of information than
> the blockchain.
>

> Ah, I forget to two things, which should be into the BIP as well:
>
> a) Gap factor for addresses; as Thomas mentioned, although some software
> can watch almost unlimited amount of unused addresses, this is serious
> concern for lightweight or server-based wallets like Electrum or
> myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
> experience so far) quite sane for most of users.

>
>
> Le 27/03/2014 12:30, Marek Palatinus a écrit :
> > Ah, I forget to two things, which should be into the BIP as well:
> >
> > a) Gap factor for addresses; as Thomas mentioned, although some software
> > can watch almost unlimited amount of unused addresses, this is serious
> > concern for lightweight or server-based wallets like Electrum or
> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
> > experience so far) quite sane for most of users.
>
>
> Yes, I was planning to increase the number of available unused addresses
> to 10 or 20 in the bip32 version of Electrum.
>
> Related to this, here is another idea I would like to submit:
>
> Instead of using a "gap limit" (maximal number of consecutive unused
> addresses), I think we should get rid of the topology, and simply count
> the number of unused addresses since the beginning of the sequence.
> Indeed, the topology of the sequence of addresses is of no interest to
> the user. Users often misinterpret "gap limit" as the "number of unused
> addresses available", so I think we should just give them what they want
> :) This is easier to understand, and it makes things more predictable,
> because the wallet will always display the same number of unused
> addresses (except when it is waiting for confirmations).
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> By the way, I just noticed that greenaddress.it is creating seeds that
> have 24 words instead of 12. Does anyone know what's up with that? They
> claim to be using BIP32 wallets so I wanted to see if they were using the
> default structure and if so, whether bitcoinj was compatible with it
> (before I switch to the one discussed here). But it seems we fall at the
> first hurdle ...
>
>
> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
>
>>
>>
>> Le 27/03/2014 12:30, Marek Palatinus a écrit :
>> > Ah, I forget to two things, which should be into the BIP as well:
>> >
>> > a) Gap factor for addresses; as Thomas mentioned, although some software
>> > can watch almost unlimited amount of unused addresses, this is serious
>> > concern for lightweight or server-based wallets like Electrum or
>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>> > experience so far) quite sane for most of users.
>>
>>
>> Yes, I was planning to increase the number of available unused addresses
>> to 10 or 20 in the bip32 version of Electrum.
>>
>> Related to this, here is another idea I would like to submit:
>>
>> Instead of using a "gap limit" (maximal number of consecutive unused
>> addresses), I think we should get rid of the topology, and simply count
>> the number of unused addresses since the beginning of the sequence.
>> Indeed, the topology of the sequence of addresses is of no interest to
>> the user. Users often misinterpret "gap limit" as the "number of unused
>> addresses available", so I think we should just give them what they want
>> :) This is easier to understand, and it makes things more predictable,
>> because the wallet will always display the same number of unused
>> addresses (except when it is waiting for confirmations).
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>

> By the way, I just noticed that greenaddress.it is creating seeds that have 24
> words instead of 12. Does anyone know what's up with that? They claim to be
> using BIP32 wallets so I wanted to see if they were using the default structure
> and if so, whether bitcoinj was compatible with it (before I switch to the one
> discussed here). But it seems we fall at the first hurdle ...
>

> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.

> Ah, BIP32 allows for a range of entropy sizes and it so happens that they
> picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedom?
>
>
> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike@plan99•net> wrote:
>
>> By the way, I just noticed that greenaddress.it is creating seeds that
>> have 24 words instead of 12. Does anyone know what's up with that? They
>> claim to be using BIP32 wallets so I wanted to see if they were using the
>> default structure and if so, whether bitcoinj was compatible with it
>> (before I switch to the one discussed here). But it seems we fall at the
>> first hurdle ...
>>
>>
>> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
>>
>>>
>>>
>>> Le 27/03/2014 12:30, Marek Palatinus a écrit :
>>> > Ah, I forget to two things, which should be into the BIP as well:
>>> >
>>> > a) Gap factor for addresses; as Thomas mentioned, although some
>>> software
>>> > can watch almost unlimited amount of unused addresses, this is serious
>>> > concern for lightweight or server-based wallets like Electrum or
>>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>>> > experience so far) quite sane for most of users.
>>>
>>>
>>> Yes, I was planning to increase the number of available unused addresses
>>> to 10 or 20 in the bip32 version of Electrum.
>>>
>>> Related to this, here is another idea I would like to submit:
>>>
>>> Instead of using a "gap limit" (maximal number of consecutive unused
>>> addresses), I think we should get rid of the topology, and simply count
>>> the number of unused addresses since the beginning of the sequence.
>>> Indeed, the topology of the sequence of addresses is of no interest to
>>> the user. Users often misinterpret "gap limit" as the "number of unused
>>> addresses available", so I think we should just give them what they want
>>> :) This is easier to understand, and it makes things more predictable,
>>> because the wallet will always display the same number of unused
>>> addresses (except when it is waiting for confirmations).
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge•net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Isn't the length of the seed arbitrary anyway? Once decoded using whatever
> mnemonic implementation (electrums, or BIP0039) the bytestream is
> immediately passed to HMAC-SHA256 to generate the master key. No matter
> what your initial entropy is, it would be hashed anyway.
>
>
> On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike@plan99•net> wrote:
>
>> Ah, BIP32 allows for a range of entropy sizes and it so happens that they
>> picked 256 bits instead of 128 bits.
>>
>> I'd have thought that there is a right answer for this. 2^128 should not
>> be brute forceable, and longer sizes have a cost in terms of making the
>> seeds harder to write down on paper. So should this be a degree of freedom?
>>
>>
>> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike@plan99•net> wrote:
>>
>>> By the way, I just noticed that greenaddress.it is creating seeds that
>>> have 24 words instead of 12. Does anyone know what's up with that? They
>>> claim to be using BIP32 wallets so I wanted to see if they were using the
>>> default structure and if so, whether bitcoinj was compatible with it
>>> (before I switch to the one discussed here). But it seems we fall at the
>>> first hurdle ...
>>>
>>>
>>> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1@gmx•de>wrote:
>>>
>>>>
>>>>
>>>> Le 27/03/2014 12:30, Marek Palatinus a écrit :
>>>> > Ah, I forget to two things, which should be into the BIP as well:
>>>> >
>>>> > a) Gap factor for addresses; as Thomas mentioned, although some
>>>> software
>>>> > can watch almost unlimited amount of unused addresses, this is serious
>>>> > concern for lightweight or server-based wallets like Electrum or
>>>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>>>> > experience so far) quite sane for most of users.
>>>>
>>>>
>>>> Yes, I was planning to increase the number of available unused addresses
>>>> to 10 or 20 in the bip32 version of Electrum.
>>>>
>>>> Related to this, here is another idea I would like to submit:
>>>>
>>>> Instead of using a "gap limit" (maximal number of consecutive unused
>>>> addresses), I think we should get rid of the topology, and simply count
>>>> the number of unused addresses since the beginning of the sequence.
>>>> Indeed, the topology of the sequence of addresses is of no interest to
>>>> the user. Users often misinterpret "gap limit" as the "number of unused
>>>> addresses available", so I think we should just give them what they want
>>>> :) This is easier to understand, and it makes things more predictable,
>>>> because the wallet will always display the same number of unused
>>>> addresses (except when it is waiting for confirmations).
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists•sourceforge•net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

>     One issue that I have is bandwidth: Electrum (and mycelium) cannot
>     watch as many addresses as they want, because this will create too
>     much traffic on the servers. (especially when servers send utxo merkle
>     proofs for each address, which is not the case yet, but is planned)
>
>
> This is surprising and the first time I've heard about this. Surely your
> constraint is CPU or disk seeks? Addresses are small, I find it hard to
> believe that clients uploading them is a big drain, and mostly addresses
> that are in the lookahead region won't have any hits and so won't result
> in any downloads?

>
>     This constraint is not so important for bloom-filter clients.
>
>
> Bloom filters are a neat way to encode addresses and keys but they don't
> magically let clients save bandwidth. A smaller filter results in less
> upload bandwidth but more download (from the wallets perspective). So
> I'm worried if you think this will be an issue for your clients: I
> haven't investigated bandwidth usage deeply yet, perhaps I should.
>
> FWIW the current bitcoinj HDW alpha preview pre-gens 100 addresses on
> both receive and change branches. But I'm not sure what the right
> setting is.

>
> We also have to consider latency. The simplest implementation from a
> wallets POV is to step through each transaction in the block chain one
> at a time, and each time you see an address that is yours, calculate the
> next ones in the chain. But that would be fantastically slow, so we must
> instead pre-generate a larger lookahead region and request more data in
> one batch. Then you have to recover if that batch ends up using all the
> pre-genned addresses. It's just painful.

>
>     My opinion, as far as Electrum is concerned, is that merchant accounts
>     should behave differently from regular user accounts: While merchants
>     need to generate an unlimited number of receiving addresses, it is also
>     acceptable for them to have a slightly more complex wallet recovery
>     procedure
>
>
> Maybe. I dislike any distinction between users and merchants though. I
> don't think it's really safe to assume merchants are more sophisticated
> than end users.

>
>     but also because we want fully automated synchronization between
>     different
>     instances of a wallet, using only no other source of information than
>     the blockchain.
>
>
> I think such synchronization won't be possible as we keep adding
> features, because the block chain cannot sync all the relevant data. For
> instance Electrum already has a label sync feature. Other wallets need
> to compete with that, somehow, so we need to build a way to do
> cross-device wallet sync with non-chain data.

>
> To be honest, I have not carried out a comprehensive examination of
> server performance. What I can see is that Electrum servers are often
> slowed down when a wallet with a large number (thousands) of addresses
> shows up, and this is caused by disk seeks (especially on my slow VPS).
>

> In terms of bandwidth, I am referring to my Android version of Electrum.
> When it runs on a 3G connection, it sometimes takes up to 1 minute to
> synchronize (with a wallet that has hundreds of addresses). However, I
> have not checked if this was caused by addresses or block headers.
>

> Yes, I was planning to increase the number of available unused addresses
> to 10 or 20 in the bip32 version of Electrum.

> Ah, BIP32 allows for a range of entropy sizes and it so happens that
> they picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedom?
>

> On 03/27/2014 01:06 PM, Thomas Voegtlin wrote:
>> Yes, I was planning to increase the number of available unused addresses
>> to 10 or 20 in the bip32 version of Electrum.
>
> Also, we'd need to specify a "gap limit" for accounts as well. In TREZOR
> we currently use 0, which means that the scan will stop as soon as we
> hit first account with no transaction history (meaning that its first
> X=10 addresses are unused).
>

>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :

> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2^128 should not
> > be brute forceable, and longer sizes have a cost in terms of making the
> > seeds harder to write down on paper. So should this be a degree of freedom?
> >
>
>
> Here is what I understand:
>
> 2^128 iterations is not brute forcable today, and will not be for the
> foreseeable future.
>
> An EC pubkey of length n can be forced in approximately 2^(n/2)
> iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> are 256 bits, would require 2^128 iterations. This is why unused
> addresses (160 bits hash) are better protected than already used ones.
>
> However, people tend to believe that a public key of size n requires 2^n
> iterations. This belief might have been spread by this popular image:
> https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> Note: Maybe we could just look at the first address of each account,
> instead of the first 10 ?

> Good to hear the bip32 wallet structure is _so_ close to being
> standardised.
> For MultiBit HD, we have put in support for 12/18/24 words but have the UI
> 'suggest' to use 12.
> You can see this on the wallet creation wizard Gary recently blogged about:
> https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html
>
> There's a little combo for the seed length, with 12 as the default.
>
>
> @Thomas. You mention gaps. We are creating new addresses on the UI in a
> panel marked 'Request' where the user also types in a QR code label and a
> note to themselves. This gets stored away as a first class
> 'PaymentRequest'. The UI 'suggests' that each address is used once. There
> will be some gaps (where the payment request is never paid) but we aren't
> bulk creating addresses. I am hoping this shouldn't cause Electrum a
> problem.
>
> We are also storing a timestamp (the number of days since the genesis
> block) to help wallet restore but that is SPV specific.
>
>
> On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
> >
> >
> > Le 27/03/2014 13:49, Mike Hearn a écrit :
> IP32 allows for a range of entropy sizes and it so happens that
> > > they picked 256 bits instead of 128 bits.
> > >
> > > I'd have thought that there is a right answer for this. 2^128 should
> not
> > > be brute forceable, and longer sizes have a cost in terms of making the
> > > seeds harder to write down on paper. So should this be a degree of
> freedom?
> > >
> >
> >
> > Here is what I understand:
> >
> > 2^128 iterations is not brute forcable today, and will not be for the
> > foreseeable future.
> >
> > An EC pubkey of length n can be forced in approximately 2^(n/2)
> > iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> > are 256 bits, would require 2^128 iterations. This is why unused
> > addresses (160 bits hash) are better protected than already used ones.
> >
> > However, people tend to believe that a public key of size n requires 2^n
> > iterations. This belief might have been spread by this popular image:
> > https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge•net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

>
>     Related to this, here is another idea I would like to submit:
>
>     Instead of using a "gap limit" (maximal number of consecutive unused
>     addresses), I think we should get rid of the topology, and simply count
>     the number of unused addresses since the beginning of the sequence.
>     Indeed, the topology of the sequence of addresses is of no interest to
>     the user. Users often misinterpret "gap limit" as the "number of unused
>     addresses available", so I think we should just give them what they want
>     :) This is easier to understand, and it makes things more predictable,
>     because the wallet will always display the same number of unused
>     addresses (except when it is waiting for confirmations).
>
>
> I'm not convinced that it is either simpler to implement nor simpler to
> understand. I considering every "account" as completely independent
> structure (except that it has been derived from master seed). Because of
> this, I don't see a reason why number of generated addresses in one
> account should affect available addresses of other account.

>
>
> Le 27/03/2014 13:49, Mike Hearn a écrit :
> > Ah, BIP32 allows for a range of entropy sizes and it so happens that
> > they picked 256 bits instead of 128 bits.
> >
> > I'd have thought that there is a right answer for this. 2^128 should not
> > be brute forceable, and longer sizes have a cost in terms of making the
> > seeds harder to write down on paper. So should this be a degree of freedom?
> >
>
>
> Here is what I understand:
>
> 2^128 iterations is not brute forcable today, and will not be for the
> foreseeable future.

> An EC pubkey of length n can be forced in approximately 2^(n/2)
> iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which
> are 256 bits, would require 2^128 iterations. This is why unused
> addresses (160 bits hash) are better protected than already used ones.
>
> However, people tend to believe that a public key of size n requires 2^n
> iterations. This belief might have been spread by this popular image:
> https://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146

> A notable suggestion was to instead of building a directory of magic numbers
> (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.

> On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas@bitsofproof•com>
> wrote:
> > A notable suggestion was to instead of building a directory of magic
> numbers
> > (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word
> "Bitcoin",
> > "Litecoin", "Dogecoin", so collosion is unlikely and
> > cetral directory is not needed.
>
> +1 good idea
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> Don't most of these coins have a magic number already assigned that is
> unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
> Litecoin, etc...).  This seems like a good candidate for identifying coins,
> and also supports Testnet cases well.  Maybe there are some alts without
> such a magic number that might prevent that?

> Don't most of these coins have a magic number already assigned that is unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for Litecoin, etc...).  This seems like a good candidate for identifying coins, and also supports Testnet cases well.  Maybe there are some alts without such a magic number that might prevent that?
>
> -Allen
>
>
> On Thu, Mar 27, 2014 at 10:43 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas@bitsofproof•com> wrote:
> > A notable suggestion was to instead of building a directory of magic numbers
> > (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> > "Litecoin", "Dogecoin", so collosion is unlikely and
> > cetral directory is not needed.
>
> +1 good idea
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> On 03/27/2014 04:57 PM, Allen Piscitello wrote:
> > Don't most of these coins have a magic number already assigned that is
> > unique? (0xD9B4BEF9 for Bitcoin, 0x0709110B for Testnet, FBC0XB6DB for
> > Litecoin, etc...).  This seems like a good candidate for identifying
> coins,
> > and also supports Testnet cases well.  Maybe there are some alts without
> > such a magic number that might prevent that?
>
> That magic number is something I find very unfortunate and superflous in
> BIP-32 design. Its only purpose is to distinguish BIP-32 trees for
> various altcoins, but it doesn't make sense at all once you start
> storing various altcoins in the same tree using the proposed
> /m/cointype/reserved'/account'/change/n scheme.
>
> I would love to see that removed from BIP-32 and use always
> 0x0488B21E/0x0488ADE4 (xpub/xpriv), but that is for different discussion
> I guess.
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick@gk2•sk>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> That said, I'm not convinced about the extra layers. The "cointype" in
> my opinion isn't necessary inside the derivation. There is already
> support (4 bytes!) for magic bytes in the serialized form. Inside

> Cointype in path is for separation purposes, not for identification.

> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick@gk2•sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick@gk2•sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> I agree that 'version' field of bip32 is not necessary and xpriv/xpub
> should be enough for all cases; there's actually no need to use different
> BIP32 roots for different altcoins.
>
> I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
> having the "cointype" distinction in the bip32 path itself, I'm sure that I
> don't reuse the same pubkey across blockchains which may be a privacy issue
> otherwise.
>
> Marek
>
>
> On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
>
>> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick@gk2•sk> wrote:
>> > Cointype in path is for separation purposes, not for identification.
>>
>> I don't understand what that gains you.
>>
>> --
>> Pieter
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>

> After some off-list discussion about details with wallet developers, it
> seems that structure
>
> m/<cointype>'/<account>'/<change>/<n>
>
> fulfill requirements of all wallet developers around, including myTrezor,
> Electrum, Multibit, Wallet32 and other software is willing to adapt once
> anything will be standardized (i.e. they don't care).
>
> Because I think that everybody told their comments to the topic already and
> because it seems that there's quite wide agreement on that, I would like to
> close the discussion and finally implement these paths into our software.
>
> Cheers,
> Marek
>
>
> On Fri, Mar 28, 2014 at 3:59 PM, slush <slush@centrum•cz> wrote:
>>
>> I agree that 'version' field of bip32 is not necessary and xpriv/xpub
>> should be enough for all cases; there's actually no need to use different
>> BIP32 roots for different altcoins.
>>
>> I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
>> having the "cointype" distinction in the bip32 path itself, I'm sure that I
>> don't reuse the same pubkey across blockchains which may be a privacy issue
>> otherwise.
>>
>> Marek
>>
>>
>> On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille <pieter.wuille@gmail•com>
>> wrote:
>>>
>>> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick@gk2•sk> wrote:
>>> > Cointype in path is for separation purposes, not for identification.
>>>
>>> I don't understand what that gains you.
>>>
>>> --
>>> Pieter
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge•net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> I still don't understand the purpose of cointype. If you don't want to
> risk reusing the same keys across different currencies, just don't use
> the same seed or the same account? That is purely a client-side issue.
>
>

> If the consensus is to add the cointype anyway, can we fix it to be
> equal to the 4-byte magic in the serialization (after setting the high
> bit to true)? That way there aren't two 4-byte magic codes that need
> to be defined for each, and at the same time make it obvious from the
> serialized form what it is for.
>
>

>
> Serialization magic of bip32 seed is in my opinion completely unnecessary.
> Most of software does not care about it anyway; You can use xprv/xpub pair
> for main net, testnet, litecoin, dogecoin, whatevercoin.
>
> Instead using the same seed (xprv) and then separate the chains *inside*
> the bip32 path seems more useful to me.
>
> Marek
>

> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>

> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>
> This is in practice almost the same as your suggestion, except that
> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
> --
> Pieter
>
>
> On Tue, Apr 8, 2014 at 3:43 PM, slush <slush@centrum•cz> wrote:
>> tl;dr;
>>
>> It is dangerous to expect that other seed than "xprv" does not contain
>> bitcoins or that "xprv" contains only bitcoins, because technically are both
>> situations possible. It is still safer to do the lookup; the magic itself is
>> ambiguous.
>>
>> Marek
>>
>> On Tue, Apr 8, 2014 at 3:40 PM, slush <slush@centrum•cz> wrote:
>>>
>>>
>>> Serialization magic of bip32 seed is in my opinion completely unnecessary.
>>> Most of software does not care about it anyway; You can use xprv/xpub pair
>>> for main net, testnet, litecoin, dogecoin, whatevercoin.
>>>
>>> Instead using the same seed (xprv) and then separate the chains *inside*
>>> the bip32 path seems more useful to me.
>>>
>>> Marek
>>
>>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.

> After some off-list discussion about details with wallet developers, it
> seems that structure
>
> m/<cointype>'/<account>'/<change>/<n>
>
> fulfill requirements of all wallet developers around, including
> myTrezor, Electrum, Multibit, Wallet32 and other software is willing to
> adapt once anything will be standardized (i.e. they don't care).
>
> Because I think that everybody told their comments to the topic already
> and because it seems that there's quite wide agreement on that, I would
> like to close the discussion and finally implement these paths into our
> software.

> I see the cause of our disagreement now.
>
> You actually want to share a single BIP32 tree across different
> currency types, but do it in a way that guarantees that they never use
> the same keys.
>
> I would have expected that different chains would use independent
> chains, and have serializations encode which chain they belong to.
>
> Let me offer an alternative suggestion, which is compatible with the
> original default BIP32 structure:
> * You can use one seed across different chains, but the master nodes
> are separate.
> * To derive the master node from the seed, the key string "Bitcoin
> seed" is replaced by something chain-specific.
>

> * Every encoded node (including master nodes) has a chain-specific
> serialization magic.
>

> the m/cointype' in m/cointype'/account'/change/n is replaced by
> different masters. The only disadvantage I see is that you do not have
> a way to encode the "super master" that is the parent of all
> chain-specific masters. You can - and with the same security
> properties - encode the seed, though.
>
>

> While there is an agreement that a standard would be useful for sharing
> wallets, we certainly didn't agree on every aspect of a standard. At
> least not on this thread, and also not at the Berlin meeting.
>
>

> I understand each client will implement things a little bit different,
> for example the current plan is bitcoinj will hold all keys in memory
> and start reusing keys on low resources. Electrum uses a chain for their
> private purpose. Etc.
>
>

> If we cannot 100% agree on a standard and also agree it will not be
> extended in future, I think we should not even try. It's dangerous for
> the money of users.

>
>

> standardizing after each of us has a feel for the specific requirements.
>

>     I understand each client will implement things a little bit different,
>     for example the current plan is bitcoinj will hold all keys in memory
>     and start reusing keys on low resources. Electrum uses a chain for their
>     private purpose. Etc.
>
> It still doesn't mean that bitcoinj or Electrum cannot share the bare
> minimum of BIP XX. Of course if somebody will use Electrum for 2to3
> transactions and then move wallet to client which does not offer such
> feature, it won't work. But I don't see that as a problem.

> On 04/08/2014 05:46 PM, slush wrote:
>
> > It still doesn't mean that bitcoinj or Electrum cannot share the bare
> > minimum of BIP XX. Of course if somebody will use Electrum for 2to3
> > transactions and then move wallet to client which does not offer such
> > feature, it won't work. But I don't see that as a problem.
>
> There is no "bare minimum". Either you implement the "BIP" fully or not.
>

> I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin
> devs already, and after long discussion we've concluded that it is generally
> bad idea.
>
> When changing "Bitcoin seed" constant to something different, same *entropy*
> will produce different *master node*. That's actually the opposite what's
> requested, because xprv serialization format stores *node*, not *entropy*.
> By changing HMAC constant, you still won't be able to store one node and
> derive wallets for multiple coins at same time.

>> * Every encoded node (including master nodes) has a chain-specific
>> serialization magic.
>>
>> This is in practice almost the same as your suggestion, except that
>> the m/cointype' in m/cointype'/account'/change/n is replaced by
>> different masters. The only disadvantage I see is that you do not have
>> a way to encode the "super master" that is the parent of all
>> chain-specific masters. You can - and with the same security
>> properties - encode the seed, though.
>>
>
> Actually I don't understand why there's such disagreement about "cointype"
> level here, what it breaks? I see it as the cleanest solution so far. It is
> forward and backward compatible, does need any special extension to bip32
> (to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed"
> cannot be "bip32 compatible").

>
> Storing the seed is superior to storing the master node already
> (whether coin specific or not), as it is smaller.
>
>

>
> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
> *Bitcoin* improvement proposal, and not something that necessarily
> applies to other coins (they can adopt it of course, I don't care).
>
>

> What I dislike is that this removes the ability of using the magic in
> the serialization to prevent importing a chain from the wrong coin.
>

>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
>>
>> Storing the seed is superior to storing the master node already
>> (whether coin specific or not), as it is smaller.
>>
>>
> ...Except that you're loosing flexibility (serialization, deserialization)
> which gives you BIP32 node.
>
> I see "bip32 seed" as some transitional, internal state from raw entropy
> to bip32 master node and this seed should not be handled by the end user in
> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
> mnemonic format) can be used very widely and have no downsides against
> using raw "bip32 seed".
>
>
>>
>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>> *Bitcoin* improvement proposal, and not something that necessarily
>> applies to other coins (they can adopt it of course, I don't care).
>>
>>
> I also don't care too much about altcoins, but people want them so me, as
> infrastructure developer, need to think about it. And I don't see any
> reason for breaking compatibility between Bitcoin and other altcoins. I
> would be happier if there will be another sentence than "Bitcoin seed", but
> honestly, who cares. It is just some magic string for hashing the raw
> seed...
>
>
>> What I dislike is that this removes the ability of using the magic in
>> the serialization to prevent importing a chain from the wrong coin.
>>
>
> The truth is that even existing software which handle bip32 don't care
> about 'version' at all. I think that "xpub/xprv" distinction is the only
> useful feature of version, so user se if it stores public or private
> information.
>
> But using prefixes which doesn't enforce anything is even more dangerous.
> If somebody exports node "dogeblablabla", it creates false exceptations
> that there's only dogecoin stored.
>
>  Marek
>

> For those who don't follow github pull requests regularly; there's pull
> request for BIP64 defining HD wallet structure as discussed in this thread:
>
> https://github.com/bitcoin/bips/pull/52
>
>
>
> On Wed, Apr 23, 2014 at 8:01 PM, slush <slush@centrum•cz> wrote:
>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:
>>>
>>> Storing the seed is superior to storing the master node already
>>> (whether coin specific or not), as it is smaller.
>>>
>>>
>> ...Except that you're loosing flexibility (serialization,
>> deserialization) which gives you BIP32 node.
>>
>> I see "bip32 seed" as some transitional, internal state from raw entropy
>> to bip32 master node and this seed should not be handled by the end user in
>> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
>> mnemonic format) can be used very widely and have no downsides against
>> using raw "bip32 seed".
>>
>>
>>>
>>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>>> *Bitcoin* improvement proposal, and not something that necessarily
>>> applies to other coins (they can adopt it of course, I don't care).
>>>
>>>
>> I also don't care too much about altcoins, but people want them so me, as
>> infrastructure developer, need to think about it. And I don't see any
>> reason for breaking compatibility between Bitcoin and other altcoins. I
>> would be happier if there will be another sentence than "Bitcoin seed", but
>> honestly, who cares. It is just some magic string for hashing the raw
>> seed...
>>
>>
>>> What I dislike is that this removes the ability of using the magic in
>>> the serialization to prevent importing a chain from the wrong coin.
>>>
>>
>> The truth is that even existing software which handle bip32 don't care
>> about 'version' at all. I think that "xpub/xprv" distinction is the only
>> useful feature of version, so user se if it stores public or private
>> information.
>>
>> But using prefixes which doesn't enforce anything is even more dangerous.
>> If somebody exports node "dogeblablabla", it creates false exceptations
>> that there's only dogecoin stored.
>>
>>  Marek
>>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> A merchant could easily send 20 addresses in a row to customers and none of
> them bother to actually buy anything.

> Setting the gap limit to high is just a small extra cost in that case.

> Different users could have different gap limit requirements.  20 seems very low as the default.
>
> A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything.
>
> Setting the gap limit to high is just a small extra cost in that case.
>
> Bip-32 serialization doesn't have a way of adding meta data though.
>
>

>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>

> On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick@gk2•sk> wrote:
>
>>
>> > Setting the gap limit to high is just a small extra cost in that case.
>>
>> Not if you have 100 accounts on 10 different devices.
>>
>
> I meant for a merchant with a server that is handing out hundreds of
> addresses.
>
> The point is to have a single system that is compatible over a large
> number of systems.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick@gk2•sk> wrote:
>
> > Setting the gap limit to high is just a small extra cost in that case.
>
> Not if you have 100 accounts on 10 different devices.
>
> I meant for a merchant with a server that is handing out hundreds of addresses.
>
> The point is to have a single system that is compatible over a large number of systems.

> The point is to have a single system that is compatible over a large number
> of systems.

> On 04/23/2014 09:00 PM, Tier Nolan wrote:
> > The point is to have a single system that is compatible over a large
> > number of systems.
>
> There is such system and it is called BIP32.
>
> On the other hand, in BIP64 we try to put a set of restrictions and
> rules on top of BIP32. There will always be some special usecases where
> BIP64 is not a good fit and there's no reason why you cannot use BIP32
> in a different manner using a different "purpose" field.
>
> Examples: Electrum does not want to use accounts and they start to use
> scheme m/65'/change/address (where change = 0 or 1). Or Andreas
> Schildbach wants to have refunds chain so he uses m/66'/chain/address
> (where chain = 0, 1 or 2).
>
> We wanted to find one good solution that fits all, but unfortunately it
> turned out everyone wants something a little bit different.

> Pieter suggested in IRC couple of months ago to append key birth to key
> serialization in xprv....@unixtime format.
>
> What about picking this idea up in BIP64? It would greatly help the
> importing client.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
>
>

> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
> use accounts, then it can just use account 0 for everything. Refund chains are

> On 04/23/2014 09:44 PM, Luke-Jr wrote:
> > Why do clients need to use the features in BIP 64? If Electrum doesn't
> > want to use accounts, then it can just use account 0 for everything.
> > Refund chains are
>
> As Andreas wrote earlier in this thread: "There is no "bare minimum".
> Either you implement the "BIP" fully or not."
>
> What you suggest does not follow the principle of least surprise.
> Suppose user imports his BIP64 compatible wallet into Electrum, which
> claims it is BIP64 compatible, but actually implements just a subset of
> the spec (sticking account index to 0). The user now sees just a
> fraction of his coins and is puzzled.

> Any wallet should import all the coins just fine, it just wouldn't *use*
> any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the
> address or
> any other details of how they were received.
>

> On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr <luke@dashjr•org> wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any
> > account other than 0. Remember addresses are used to receive bitcoins;
> > once the UTXOs are in the wallet, they are no longer associated with the
> > address or
> > any other details of how they were received.
>
> Wallet don't see UTXO until it scans all branches/accounts on HD node
> import.

> Any wallet should import all the coins just fine, it just wouldn't *use* any
> account other than 0. Remember addresses are used to receive bitcoins; once
> the UTXOs are in the wallet, they are no longer associated with the address or
> any other details of how they were received.

> On 23.04.2014, at 21:55, Luke-Jr <luke@dashjr•org> wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any account other than 0. Remember addresses are used to receive
> > bitcoins; once the UTXOs are in the wallet, they are no longer
> > associated with the address or any other details of how they were
> > received.
>
> This is a bit idealistic.
> The wallet has to know how it got the UTXO in order to be able to spend it.

> Yes, it should scan all possible (under the BIP-defined structure) branches
> regardless of which features it supports.

> On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
>> On 23.04.2014, at 21:55, Luke-Jr <luke@dashjr•org> wrote:
>>> Any wallet should import all the coins just fine, it just wouldn't *use*
>>> any account other than 0. Remember addresses are used to receive
>>> bitcoins; once the UTXOs are in the wallet, they are no longer
>>> associated with the address or any other details of how they were
>>> received.
>>
>> This is a bit idealistic.
>> The wallet has to know how it got the UTXO in order to be able to spend it.
>
> No it doesn't... Just the assigned scriptPubKey and secret(s) required to
> satisfy it.
>

> On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
> > On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr <luke@dashjr•org> wrote:
> > > Any wallet should import all the coins just fine, it just wouldn't
> *use*
> > > any
> > > account other than 0. Remember addresses are used to receive bitcoins;
> > > once the UTXOs are in the wallet, they are no longer associated with
> the
> > > address or
> > > any other details of how they were received.
> >
> > Wallet don't see UTXO until it scans all branches/accounts on HD node
> > import.
>
> Yes, it should scan all possible (under the BIP-defined structure) branches
> regardless of which features it supports.
>
> Luke
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> On 04/23/2014 10:01 PM, Luke-Jr wrote:
> > Yes, it should scan all possible (under the BIP-defined structure)
> > branches regardless of which features it supports.
>
> So you suggest to scan for accounts, show balances but don't allow user
> to spend them? Does not seem right to me.

> On 23.04.2014, at 22:02, Luke-Jr <luke@dashjr•org> wrote:
> > On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
> >> The wallet has to know how it got the UTXO in order to be able to spend
> >> it.
> >
> > No it doesn't... Just the assigned scriptPubKey and secret(s) required to
> > satisfy it.
>
> To know the secret it needs to know which key coordinate to use that is
> logically the same as knowing the address it used to receive it.

> On 04/23/2014 10:01 PM, Luke-Jr wrote:
> > Yes, it should scan all possible (under the BIP-defined structure)
> branches
> > regardless of which features it supports.
>
> So you suggest to scan for accounts, show balances but don't allow user
> to spend them? Does not seem right to me.
>
> --
> Best Regards / S pozdravom,
>
> Pavol Rusnak <stick@gk2•sk>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> Scan all branches for UTXOs, then you have the balance for the wallet. Account
> balances are metadata, so cannot be known from the seed alone. If you want to
> have a way to restore accounts, you must define some more detailed wallet file
> format (which could be built on top of this).

> On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
>> On 04/23/2014 10:01 PM, Luke-Jr wrote:
>>> Yes, it should scan all possible (under the BIP-defined structure)
>>> branches regardless of which features it supports.
>>
>> So you suggest to scan for accounts, show balances but don't allow user
>> to spend them? Does not seem right to me.
>
> Scan all branches for UTXOs, then you have the balance for the wallet. Account
> balances are metadata, so cannot be known from the seed alone. If you want to
> have a way to restore accounts, you must define some more detailed wallet file
> format (which could be built on top of this).
>
> On Wednesday, April 23, 2014 8:04:35 PM you wrote:
>> On 23.04.2014, at 22:02, Luke-Jr <luke@dashjr•org> wrote:
>>> On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
>>>> The wallet has to know how it got the UTXO in order to be able to spend
>>>> it.
>>>
>>> No it doesn't... Just the assigned scriptPubKey and secret(s) required to
>>> satisfy it.
>>
>> To know the secret it needs to know which key coordinate to use that is
>> logically the same as knowing the address it used to receive it.
>
> Sure, it *knows* what address was used to receive it. But at the point it's a
> UTXO, that address is no longer relevant.
>

> On 04/23/2014 10:09 PM, Luke-Jr wrote:
> > Scan all branches for UTXOs, then you have the balance for the wallet.
> > Account balances are metadata, so cannot be known from the seed alone.
> > If you want to have a way to restore accounts, you must define some more
> > detailed wallet file format (which could be built on top of this).
>
> I think one of the following is happening:
>
> a) you have not read the document
> b) you don't understand what accounts are, because you have not read
>    the document
> c) you don't understand how restoring accounts work, because you
>    have not read the document
> d) you don't understand that accounts funds are not meant to be mixed
>    together, because you have not read the document
> e) I got your emails wrong because I am not a native speaker,
>    but please read the the document ;-)

> f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> instead of what has traditionally been called "account" in Bitcoin.

> In that case, single-subwallet wallet software probably needs to have the user
> provide a subwallet number in addition to the seed.

> On 04/23/2014 10:32 PM, Luke-Jr wrote:
> > f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> > instead of what has traditionally been called "account" in Bitcoin.
>
> Ah, okay. The last time I saw Bitcoin-qt it was still using independent
> addresses.

> > In that case, single-subwallet wallet software probably needs to have the
> > user provide a subwallet number in addition to the seed.
>
> Which brings us back to my original complaint that the user can be
> confused because he doesn't see all his funds.

> I don't see how. The user knows he has money in different subwallets. As long
> as he has a way to specify which subwallet he is accessing in single-subwallet
> clients, there shouldn't be a problem.

> On 04/23/2014 10:41 PM, Luke-Jr wrote:
>> I don't see how. The user knows he has money in different subwallets. As long
>> as he has a way to specify which subwallet he is accessing in single-subwallet
>> clients, there shouldn't be a problem.
>
> Right. But these clients have no right to call themselves BIP64
> compatible then.

> On 04/23/2014 10:41 PM, Luke-Jr wrote:
> > I don't see how. The user knows he has money in different subwallets. As
> > long as he has a way to specify which subwallet he is accessing in
> > single-subwallet clients, there shouldn't be a problem.
>
> Right. But these clients have no right to call themselves BIP64
> compatible then.

> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64?

>
> Would you consider software which scans all accounts as specified by
> BIP64, but has no user interface option to distinguish them in any
> way, view them independently, and has no ability to keep the coins
> apart... compatible with BIP64?
>
>

> On 04/23/2014 10:54 PM, Pieter Wuille wrote:
> > Would you consider software which scans all accounts as specified by
> > BIP64, but has no user interface option to distinguish them in any
> > way, view them independently, and has no ability to keep the coins
> > apart... compatible with BIP64?
>
> This is not a desired behavior. Do you have any idea how to make it even
> more explicit in the spec? Currently we just have (in Account sectrion):
>
> "This level splits the key space into independent user identities, so
> the wallet never mixes the coins across different accounts."
>
>
> I would like to make it obvious from the spec that if you mix funds
> accross the accounts you are not doing a right thing and you are not
> compliant to the spec.

> How do you get the more expected/usual behaviour of mixing funds between
> accounts? Only a very niche user base needs funds isolated...

> Only a very niche user base needs funds isolated...

> Hopefully it would be clarified as only a MUST NOT do so silently...
> "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> sounds like a terrible user experience. :)

> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
>> Hopefully it would be clarified as only a MUST NOT do so silently...
>> "I have funds split across two wallets and it WONT LET ME SPEND THEM"
>> sounds like a terrible user experience. :)
>
> That is a subjective matter. To me it makes PERFECT SENSE that funds
> across accounts NEVER MIX. One can still send funds from one account to
> another and then perform another spend.

> In that case, maybe it makes sense to define another purpose id
> without accounts as well already.
>
> I believe many simple wallets will find multiple subwallets too
> burdening for the user experience, or not worth the technical
> complexity.

> In that case, maybe it makes sense to define another purpose id
> without accounts as well already.
>
> I believe many simple wallets will find multiple subwallets too
> burdening for the user experience, or not worth the technical
> complexity.

> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> > Hopefully it would be clarified as only a MUST NOT do so silently...
> > "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> > sounds like a terrible user experience. :)
>
> That is a subjective matter. To me it makes PERFECT SENSE that funds
> across accounts NEVER MIX. One can still send funds from one account to
> another and then perform another spend.

> That's what I consider a consistent and thus GOOD user experience.
> What's the purpose of Accounts if wallet mixes coins among them anyway?

> I know it's not good to use classic bank accounts as analogy, but that's
> exactly how they work. Or have you every done ONE transaction from two
> bank accounts simultaneously?

> On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
>>
>> Examples: Electrum does not want to use accounts [...]

> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
> use accounts, [...]

>> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
>> use accounts, [...]
>
> To clarify:
> Electrum plans to have bip32 accounts; Multibit will not, afaik.

> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
>>> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
>>> use accounts, [...]
>>
>> To clarify:
>> Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.

> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>

> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1@gmx•de> wrote:
> >> Why do clients need to use the features in BIP 64? If Electrum doesn't
> want to
> >> use accounts, [...]
> >
> > To clarify:
> > Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

>
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
>
> Am I misunderstanding it?   Will Electrum be limiting itself in this
> way?  I'd consider it a unfortunate loss of functionality if wallets
> couldn't implement reoccurring payment chains without making users
> generate entirely different wallets (which they couldn't share funds
> across) since addresses for recurring payments was one of the main
> motivations in BIP32.
>
>