Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

Thanks Thomas, for sharing your experience!

I'd like know why you think it's a problem that BIP43 is tied to BIP32?
I understand we all agreed at least on the BIP32-derivation spec
(excluding the BIP32-hierarchy spec)?



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thomas Voegtlin]

Hi Andreas,

I don't think it's a problem that BIP43 is tied to BIP32.

What I don't like is that you have to explore branches of the derivation
tree, in order to know if there is a wallet. As a result, it is not
possible for the software to give a negative answer, like "this wallet
is empty", because you do not know if you have explored all the possible
derivations; a new one may have been added after the software was written.

With a version number, you can answer "sorry this seed is not recognized
by me", and you do not need to be online to do that.
If you are online, you can answer "this wallet is empty" after exploring it.




Le 11/03/2015 16:31, Andreas Schildbach a écrit :
> Thanks Thomas, for sharing your experience!
> 
> I'd like know why you think it's a problem that BIP43 is tied to BIP32?
> I understand we all agreed at least on the BIP32-derivation spec
> (excluding the BIP32-hierarchy spec)?
> 
> 
> 
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for privacy reasons. In any case, practical
multisig is still a looong way off.


On 03/12/2015 12:50 AM, devrandom wrote:
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.  The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key.  The oracle
> would have different security thresholds for countersigning the mobile.
> 
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
> 
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling.
> 
> On 2015-03-11 04:22 PM, Mike Hearn wrote:
>> Users will want to have wallets shared between devices, it's as simple
>> as that, especially for mobile/desktop wallets. Trying to stop them from
>> doing that by making things gratuitously incompatible isn't the right
>> approach:  they'll just find workarounds or wallet apps will learn how
>> to import seeds from other apps. Better to just explain the risks and
>> help people mitigate them.
>>
>> On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine > > wrote:
>>
>> I'm not convinced that wallet seed interoperability is such a great
>> thing. There is a wide variability in the quality and security level
>> of wallet implementations and platforms. Each new device and wallet
>> software a user types their seed into increases their attack surface
>> and exposure to flaws. Their security level is reduced to the lowest
>> common denominator. I see the need for a "fire exit", certainly, but
>> we must also remember that fire exits are potential entrances for
>> intruders.
>>
>> Aaron Voisine
>> co-founder and CEO
>> breadwallet.com 
>>
>> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell
>> mailto:gmaxw...@gmail.com>> wrote:
>>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>> mailto:ricardojdfil...@gmail.com>>
>> wrote:
>> > i guess you look at the glass half full :)
>> > even though what you say is true, we should aim for wallets not to
>> > require those instructions, by standardizing these things in BIPs.
>> > let's hope bitcoin doesn't fail in standards as our industries 
>> have in
>> > the past...
>>
>> There are genuine principled disagreements on how some things should
>> be done. There are genuine differences in functionality.
>>
>> We cannot expect and should not expect complete compatibility.
>> If you
>> must have complete compatibility: use the same software (or
>> maybe not
>> even then, considering how poor the forward compatibility of some
>> things has been..).
>>
>> What we can hope to do, and I think the best we can hope to do,
>> is to
>> minimize the amount of gratuitous incompatibility and reduce the
>> amount of outright flawed constructions (so if there are choices
>> which
>> must be made, they're at least choices among relatively good
>> options).
>>
>> 
>> --
>> Dive into the World of Parallel Programming The Go Parallel
>> Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is
>> your hub for all
>> things parallel software development, from weekly thought
>> leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and
>> join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> 
>> --
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your
>> hub for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

On 03/12/2015 01:11 AM, Gregory Maxwell wrote:

> Ultimately, the most fundamental compatibility is guaranteed:  you can
> always send your funds to another wallet. This always works and
> guarantees that you are never locked in to a single wallet. It is well
> tested and cannot drive any software in to weird or confused states.

This.




--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

For reasonably skilled users your points are valid, but I'm sure you
also – like me – encountered the kind of user who has absolutely no clue
but thinks he understands. S/he will ignore warnings and run into
troubles. This generates a huge amount of support cases and likely tears
about lost coins.

The simple fact that someone elses broken RNG implementation/wrapper
could compromise the security of my software frightens me.


On 03/11/2015 08:04 PM, Jim wrote:
> The wallet words system isn't perfect for sure but it does help the user in 
> two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the 
> user knows they can recover their bitcoins using the same wallet software in 
> case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are 
> stored in Wallet X into Wallet Y. We need to give them guidance on how to do 
> this.
> 
> I think it is up to each wallet team to explain to their users clearly how 
> they can do this in their help. It's only good manners to show your guests 
> where the fire exits are.
> 
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do 
> this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on 
> myTrezor.com, do this, this and this."
> 
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about 
> keeping their bitcoins.
> 



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

Thy, your message threading is broken. Can you make sure your mail
program uses the correct message ID when replying?


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Broken Threading

[Thy Shizzle]

Yes apologies for the broken threading, it was the result of me auto forwarding 
between mail providers etc.

To fix this issue I have created this new dedicated outlook account 
(thyshiz...@outlook.com) that I shall use for all my subscriptions here and I 
am unsubscribing the yahoo address. This should solve this issue going forward 
:)
  --
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Neill Miller]

Ok, I see your point here, and I was referring to rebuilding from
entropy -- which as you noted is not a real world usage.  It is a
useful implementation test though and at the very least the existing
test vectors would need to be regenerated with each word list change.

I recently added BIP39 to libbitcoin and our implementation would fail
with an arbitrarily new word list because we validate the user
provided word list before converting it to a seed (i.e. we check that
the encoded entropy/checksum line up and warn the user if that's not
the case to distinguish a rubbish word list from a BIP39 mnemonic --
as referenced in the BIP).  You're correct that we could use rubbish
words, but at the moment it's not allowed there.  By removing that
validating 'restriction', I agree with you that word lists have no
need to be fixed.  But realistically, we still don't allow completely
arbitrary words to be used because I don't see the word lists changing
too often, nor implementations storing word lists of all words and
languages.

Thanks for clarifying,
-Neill.

On Thu, Mar 12, 2015 at 04:21:59AM +, Thy Shizzle wrote:
> "I agree that it's true that a static wordlist is
>  required once people have started using BIP39 for anything real and
>  changing the word lists will invalidate any existing mnemonics"
> ^ This is incorrect I think Neill, the reason is that the only thing that 
> happens when you change the wordlist is that entropy points to different 
> words. But remember, entropy is disposed. Yes in my code I allow for the 
> keeping of entropy etc, it also lets me "hot swap" between different language 
> wordlists etc but in real world implementation the entropy is forgotten and 
> not stored. So changing the wordlist merely allows new mnemonic phrases to be 
> generated but it has a nil impact on previously generated mnemonics UNLESS 
> you are trying to rebuild from entropy but you wouldn't do that. You would be 
> rebuilding from the Mnemonic in real world scenario. You really can have a 
> word list of total rubbish in BIP39 as long as it is 2048 words long that is 
> all! If you input the mnemonic made out of rubbish words so for e.g "uyuy 
> jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and 
> no matter what BIP39 implementation you put it in, it will always generate 
> the same seed bytes thus allowing for complete and universal seed derivation 
> without any reliance on word list. The word list is merely to generate a 
> mnemonic, after that it has no role in seed generation so you can change it 
> at anytime and it will never effect future mnemonics.
> 
> On Thu, Mar 12, 2015 at 02:16:38AM +, Thy Shizzle wrote:
> > That's disappointing the Electrum 2.0 doesn't use BIP39.
> 
> Agreed, but I don't know the full background on this.
> 
> > Changing the wordlist in the future has ZERO effect on derived seed, 
> > whatever mnemonic you provide will always generate the same seed, BIP39 is 
> > not mapping the words back to numbers etc to derive seed.
> 
> That's true for generating new mnemonics (i.e. same entropy can
> generate any combinations of words), but not for converting a mnemonic
> to a seed (i.e. a specific wordlist/passphrase should always generate
> the same seed).  I agree that it's true that a static wordlist is
> required once people have started using BIP39 for anything real and
> changing the word lists will invalidate any existing mnemonics (unless
> your 'new' wordlist simply substitutes one word for another and the
> index mapping is made public ... which means it's not really an
> arbitrary word list).
> 
> > Version is something that can be dealt with after the fact, hopefully 
> > standardised (curious why didn't you work with the BIP39 to insert version 
> > instead of do something different to BIP39?)
> > So most of what you are suggesting as problems are not.
> 
> I don't see how this can work given the BIP39 spec as it is today
> (there's simply no room for a version in the bits).  I do think
> versioning would be nice, but as of now, I'm in the camp that thinks
> complete wallet interoperability is a bit of a myth -- so long as you
> can fundamentally move into/out of wallets at will.
> 
> -Neill.
> 
> > As for the common words between languages, I have discussed this with the 
> > provider of the Chinese wordlists as they shared some words between 
> > simplified and traditional, but I found it easy to look for a word in the 
> > mnemonic that is unique to that language/wordlist and so straight away you 
> > can determine the language, remembering you get minimum 12 goes at doing 
> > that :)
> > Also then I asked myself, do we really care about detecting the language? 
> > Probably not because we don't need to use the wordlist ever again after 
> > creation, we literally accept the mnemonic, normalise it then hash it into 
> > a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it 
> > would take almost no effort to put it i

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

@Neill, Indeed supplying entropy is necessary for testing etc, that's the main 
reason why I put this in my .NET implementation, the test vectors require us to 
supply entropy and build the mnemonic from the supplied wordlist and you are 
correct that changes to the word list will null and void the test vectors. Also 
it allows us to do fun things like swap between languages so one entropy set 
can have many seeds based on many languages etc, just novel little things like 
that. I'm not at all against a standard wordlist. The point I want to get 
across is that people seem to think that BIP39 is restricted by its word list 
but not at all. As long as you give a BIP39 implementation 12 words or more (in 
3 word increments) it will always derive the same seed bytes, independent of 
any word list and this is the most important message to realise.

@Thomas V if you must record a version, why don't you just put an integer at 
the end of your mnemonic or something? I can't understand why you have 
disregarded BIP39 when designing Electrum 2.0?  12 - 24 words plus a version 
integer tacked on the end, tell the user to omit the version integer if they 
want to import to multibit HD or whatever, job done!

I really think you need to rethink the use of BIP39 with Electrum Thomas! If 
you want to maintain a version field and/or date independent of the BIP39 spec 
then do so because at least the seed can still be recreated from anyone else 
utilising BIP39!!!

Thy

> Date: Thu, 12 Mar 2015 06:51:37 -0500
> From: nei...@thecodefactory.org
> To: thashizn...@yahoo.com.au
> CC: Bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
> 
> 
> Ok, I see your point here, and I was referring to rebuilding from
> entropy -- which as you noted is not a real world usage.  It is a
> useful implementation test though and at the very least the existing
> test vectors would need to be regenerated with each word list change.
> 
> I recently added BIP39 to libbitcoin and our implementation would fail
> with an arbitrarily new word list because we validate the user
> provided word list before converting it to a seed (i.e. we check that
> the encoded entropy/checksum line up and warn the user if that's not
> the case to distinguish a rubbish word list from a BIP39 mnemonic --
> as referenced in the BIP).  You're correct that we could use rubbish
> words, but at the moment it's not allowed there.  By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed.  But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.
> 
> Thanks for clarifying,
> -Neill.
> 
> On Thu, Mar 12, 2015 at 04:21:59AM +, Thy Shizzle wrote:
> > "I agree that it's true that a static wordlist is
> >  required once people have started using BIP39 for anything real and
> >  changing the word lists will invalidate any existing mnemonics"
> > ^ This is incorrect I think Neill, the reason is that the only thing that 
> > happens when you change the wordlist is that entropy points to different 
> > words. But remember, entropy is disposed. Yes in my code I allow for the 
> > keeping of entropy etc, it also lets me "hot swap" between different 
> > language wordlists etc but in real world implementation the entropy is 
> > forgotten and not stored. So changing the wordlist merely allows new 
> > mnemonic phrases to be generated but it has a nil impact on previously 
> > generated mnemonics UNLESS you are trying to rebuild from entropy but you 
> > wouldn't do that. You would be rebuilding from the Mnemonic in real world 
> > scenario. You really can have a word list of total rubbish in BIP39 as long 
> > as it is 2048 words long that is all! If you input the mnemonic made out of 
> > rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds 
> > uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you 
> > put it in, it will always generate the same seed bytes thus allowing for 
> > complete and universal seed derivation without any reliance on word list. 
> > The word list is merely to generate a mnemonic, after that it has no role 
> > in seed generation so you can change it at anytime and it will never effect 
> > future mnemonics.
> > 
> > On Thu, Mar 12, 2015 at 02:16:38AM +, Thy Shizzle wrote:
> > > That's disappointing the Electrum 2.0 doesn't use BIP39.
> > 
> > Agreed, but I don't know the full background on this.
> > 
> > > Changing the wordlist in the future has ZERO effect on derived seed, 
> > > whatever mnemonic you provide will always generate the same seed, BIP39 
> > > is not mapping the words back to numbers etc to derive seed.
> > 
> > That's true for generating new mnemonics (i.e. same entropy can
> > generate any combinations of words), but not for converting a mnemonic
> >

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

On 2015-03-12 04:51 AM, Neill Miller wrote:
> 
> Ok, I see your point here, and I was referring to rebuilding from
> entropy -- which as you noted is not a real world usage.  It is a
> useful implementation test though and at the very least the existing
> test vectors would need to be regenerated with each word list change.
> 
> I recently added BIP39 to libbitcoin and our implementation would fail
> with an arbitrarily new word list because we validate the user
> provided word list before converting it to a seed (i.e. we check that
> the encoded entropy/checksum line up and warn the user if that's not
> the case to distinguish a rubbish word list from a BIP39 mnemonic --
> as referenced in the BIP).  You're correct that we could use rubbish
> words, but at the moment it's not allowed there.  By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed.  But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.

A good way to go about this from a UX point of view is warn the user
that their "phrase is non-standard", but allow them to insist.

> 
> Thanks for clarifying,
> -Neill.
> 
> On Thu, Mar 12, 2015 at 04:21:59AM +, Thy Shizzle wrote:
>> "I agree that it's true that a static wordlist is
>>  required once people have started using BIP39 for anything real and
>>  changing the word lists will invalidate any existing mnemonics"
>> ^ This is incorrect I think Neill, the reason is that the only thing that 
>> happens when you change the wordlist is that entropy points to different 
>> words. But remember, entropy is disposed. Yes in my code I allow for the 
>> keeping of entropy etc, it also lets me "hot swap" between different 
>> language wordlists etc but in real world implementation the entropy is 
>> forgotten and not stored. So changing the wordlist merely allows new 
>> mnemonic phrases to be generated but it has a nil impact on previously 
>> generated mnemonics UNLESS you are trying to rebuild from entropy but you 
>> wouldn't do that. You would be rebuilding from the Mnemonic in real world 
>> scenario. You really can have a word list of total rubbish in BIP39 as long 
>> as it is 2048 words long that is all! If you input the mnemonic made out of 
>> rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds 
>> uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put 
>> it in, it will always generate the same seed
 bytes thus allowing for complete and universal seed derivation without any 
reliance on word list. The word list is merely to generate a mnemonic, after 
that it has no role in seed generation so you can change it at anytime and it 
will never effect future mnemonics.
>>
>> On Thu, Mar 12, 2015 at 02:16:38AM +, Thy Shizzle wrote:
>>> That's disappointing the Electrum 2.0 doesn't use BIP39.
>>
>> Agreed, but I don't know the full background on this.
>>
>>> Changing the wordlist in the future has ZERO effect on derived seed, 
>>> whatever mnemonic you provide will always generate the same seed, BIP39 is 
>>> not mapping the words back to numbers etc to derive seed.
>>
>> That's true for generating new mnemonics (i.e. same entropy can
>> generate any combinations of words), but not for converting a mnemonic
>> to a seed (i.e. a specific wordlist/passphrase should always generate
>> the same seed).  I agree that it's true that a static wordlist is
>> required once people have started using BIP39 for anything real and
>> changing the word lists will invalidate any existing mnemonics (unless
>> your 'new' wordlist simply substitutes one word for another and the
>> index mapping is made public ... which means it's not really an
>> arbitrary word list).
>>
>>> Version is something that can be dealt with after the fact, hopefully 
>>> standardised (curious why didn't you work with the BIP39 to insert version 
>>> instead of do something different to BIP39?)
>>> So most of what you are suggesting as problems are not.
>>
>> I don't see how this can work given the BIP39 spec as it is today
>> (there's simply no room for a version in the bits).  I do think
>> versioning would be nice, but as of now, I'm in the camp that thinks
>> complete wallet interoperability is a bit of a myth -- so long as you
>> can fundamentally move into/out of wallets at will.
>>
>> -Neill.
>>
>>> As for the common words between languages, I have discussed this with the 
>>> provider of the Chinese wordlists as they shared some words between 
>>> simplified and traditional, but I found it easy to look for a word in the 
>>> mnemonic that is unique to that language/wordlist and so straight away you 
>>> can determine the language, remembering you get minimum 12 goes at doing 
>>> that :)
>>> Also then I asked myself, do we really care about detecting the language? 
>>> Probably not because 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

>
> b) "Creation date" is just a short-term hack.
>

I agree, but we need things to be easy in the short term as well as the
long term :)

The long term solution is clearly to have the 12 word seed be an encryption
key for a wallet backup with all associated metadata. We're heading in that
direction one step at a time. Unfortunately it will take time for wallets
to start working this way, and all the pieces to fall into place. Restoring
from the block chain will be a semi regular operation for users until then.

WRT version number I have no real strong feelings about this. But
representing short pieces of binary data as words is so convenient, it
seems likely that it could be similar to addresses: people find other uses
for this mechanism beyond just storing a raw private key. Bitcoin addresses
have versions and that's proven to be useful several times, even though in
theory an address is "just" a hash of a pubkey.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gary Rowe]

When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:

* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language variants provided by experts later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum
compatibility with other wallets
* including a date in the "wallet words" themselves is open to spoofing
since the generator cannot be sure the date is correct (local time drift,
provided externally by untrusted third party etc)
* a timestamp as optional external metadata is useful to reduce sync times
in SPV
* our experience verified that users will very often enter a timestamp
incorrectly (locale, fat fingers, bad memory etc) so we opted for "number
of days elapsed since Bitcoin genesis block with a modulo 97 checksum
appended" (e.g. 1850/07) to mitigate this
* if a user has no timestamp then blank is the only alternative (no
guessing) which is interpreted as "earliest possible BIP32 date"
* if restoring the user has to select where the "wallet words" came from
(e.g. MultiBit HD, Trezor, Mycelium etc)

Users will naturally assume that they can type their "wallet words" (a more
mainstream-friendly term than "seed phrase") into any wallet and with a bit
of fiddling about get their bitcoins back. As wallet developers it is
within our capability to make that happen and I think we're quite close
already.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gary Rowe]

When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:

* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language variants provided by experts later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum
compatibility with other wallets
* including a date in the "wallet words" themselves is open to spoofing
since the generator cannot be sure the date is correct (local time drift,
provided externally by untrusted third party etc)
* a timestamp as optional external metadata is useful to reduce sync times
in SPV
* our experience verified that users will very often enter a timestamp
incorrectly (locale, fat fingers, bad memory etc) so we opted for "number
of days elapsed since Bitcoin genesis block with a modulo 97 checksum
appended" (e.g. 1850/07) to mitigate this
* if a user has no timestamp then blank is the only alternative (no
guessing) which is interpreted as "earliest possible BIP32 date"
* if restoring the user has to select where the "wallet words" came from
(e.g. MultiBit HD, Trezor, Mycelium etc)

Users will naturally assume that they can type their "wallet words" (a more
mainstream-friendly term than "seed phrase") into any wallet and with a bit
of fiddling about get their bitcoins back. As wallet developers it is
within our capability to make that happen and I think we're quite close
already.

On 12 March 2015 at 16:47, Mike Hearn  wrote:

> b) "Creation date" is just a short-term hack.
>>
>
> I agree, but we need things to be easy in the short term as well as the
> long term :)
>
> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall into
> place. Restoring from the block chain will be a semi regular operation for
> users until then.
>
> WRT version number I have no real strong feelings about this. But
> representing short pieces of binary data as words is so convenient, it
> seems likely that it could be similar to addresses: people find other uses
> for this mechanism beyond just storing a raw private key. Bitcoin addresses
> have versions and that's proven to be useful several times, even though in
> theory an address is "just" a hash of a pubkey.
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Bitcoin Solutions Ltd provides bespoke software and consultancy. Find us at
bitcoin-solutions.co.uk.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Natanael]

Den 12 mar 2015 17:48 skrev "Mike Hearn" :
>>
>> b) "Creation date" is just a short-term hack.
>
>
> I agree, but we need things to be easy in the short term as well as the
long term :)
>
> The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.

This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.

We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).

A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.

And so on... I think you get my point by now.

The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.

I think it should be referred to as an import/export format, more than as a
backup format.

You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

On 03/12/2015 07:27 PM, Natanael wrote:
> 
> Den 12 mar 2015 17:48 skrev "Mike Hearn"  >:
>>>
>>> b) "Creation date" is just a short-term hack.
>>
>>
>> I agree, but we need things to be easy in the short term as well as
> the long term :) 
>>
>> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall
> into place. Restoring from the block chain will be a semi regular
> operation for users until then.
> 
> This have been mentioned a few times before, and what I think is
> necessary is to create a common file format that can be interpreted by a
> library which all wallets can use. I see it as similar as the work to
> create libconsensus for parsing the blockchain.


I'm afraid this will never fly. Wallets are just too different and
that's a good thing! For example, by design choice Bitcoin Wallet and
bitcoinj doesn't support multiple accounts. How would it ever import
wallets from MultiBit or Mycelium?

Bitcoinj-based wallets could probably share the bitcoinj protobuf wallet
format (or whatever format we will be at the time of the "merge" – we
already have tons of requirements piling up!). This would mean bitcoinj
is the "consensus library equivalent" you were mentioning.



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Bryan Bishop]

On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell  wrote:
> For an emergency transition the user is probably better off with an
> explicit unstructured mass private key export, and a sweep function;
> and guaranteeing compatibility with that is much easier; and because
> it moves funds in one direction there is much less chance of going
> from secure to insecure.

I haven't looked at the existing sweep implementations, but it would
be unfortunate if sweep functions were not available that create at
least the same number of keys, or possibly more, for the purposes of
sweeping. I suppose there are different levels of emergency, where
perhaps you want to sweep all at once in a single transaction and lose
out on (already nebulous) privacy benefits. I say nebulous because
broadcasting a bunch of transactions all at the same time during the
sweep can compromise privacy even when the transactions have no common
ancestor outputs.

- Bryan
http://heybryan.org/
1 512 203 0507

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Natanael]

Den 12 mar 2015 19:52 skrev "Andreas Schildbach" :
>
> I'm afraid this will never fly. Wallets are just too different and
> that's a good thing! For example, by design choice Bitcoin Wallet and
> bitcoinj doesn't support multiple accounts. How would it ever import
> wallets from MultiBit or Mycelium?

I think I covered that with the "importing wallet says what sections it
supports" part. Then you'd only ask for the library to give you the
addresses from the first branch in the main HD wallet. The user would be
told that you by design can't manage the other parts. The user would be
alerted and get the recommendation to send the funds over manually if they
want to switch their wallet. The user might however just want to export
that one single branch if he's a "power user", so he would proceed to use
it that way.

At export, I recommend the wallet will tell the user what extensions and
standards are in use (and which are necessary to recover how much of their
funds in the target wallet). The user would be asked to confirm that the
target wallet client supports these. The user should be given the option to
hand the list of supported functionality in the target wallet (like a list
of BIP numbers?), and tell the wallet to move the funds around so that the
target wallet can successfully import everything and recover all funds.

Actually, thinking about it I think what we really need first is a standard
synchronization / transition protocol. Right now we don't have more than
the address label syncing plugin for Electrum. We need something for
wallets to synchronize state, with the option for having one wallet tell
the other how to send over all funds (for when they use completely
different standards for managing funds). As the most simple option, the
target wallet would provide a list of addresses to the sending wallet when
you switch (this would satisfy Bryan's request).
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] BIP32 Index Randomisation

[Matias Alejo Garcia]

Hello everyone,

We are working on bitcore-wallet-server (BWS), a HD multisig wallet
'facilitator'. We have a couple of questions regarding BIP32 path usage,
and we would love to have feedback from you before moving forward.

Currently the BWS instances hold the set of extended public keys of the
wallet's peers to be able to derive  addresses.

Since this is a problem from the privacy point of view, we thought using
pseudo-random  BIP32 paths, with a seed only known be the peers, so the
server will be able to verify that addresses  submitted by peers belong to
the wallet, but will not be able to derive future wallet addresses.

The workflow would be something like:

```
Peer >   getCurrentIndex

< Server [index]

Peer:
  pathSeed = PRNG(seed, index);

Peer > createAddress(index, pathSeed);

Server:
  derives the address and add it to the wallet.

< Server  new address

Peer: Verifies the address and inform it the user.
```

This way, accessing server data won't reveal future wallet addresses. The
seed (only known by the peers) could
be derived from hashes of their xprivs, so wallet funds can still be
recover with:
  1) The complete set of xprivs
  2) The quorum of xprivs + the complete set of xpubs + the address seed.

Thanks a lot in advance for any comment on this schema.

matías

-- 
BitPay.com
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP32 Index Randomisation

[Gregory Maxwell]

This seems overly complicated to me, unless I'm missing something.

Instead, I think you should just give the server the master pubkey P
only without the chaincode.


Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user computes
as

iL = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i))[first 32
byes],  (per BIP 32).

and the server computes P + iL*G  and checks agreement with the address.

It would be inaccurate to call this private, as the server still
learns this particular relation. (and really users should _not_ be
using the same chaincode with different parties... as it exacerbates
the private key leak risk), but its certainly more private than giving
people the chain code.

The approach I suggest is also not gratuitously incompatible with
hardened derivation, which is what parties should be doing when they
don't actually need a third party to generate future addresses for
them without their cooperation (as appears to be the case here).










On Fri, Mar 13, 2015 at 3:48 AM, Matias Alejo Garcia  wrote:
>
> Hello everyone,
>
> We are working on bitcore-wallet-server (BWS), a HD multisig wallet
> 'facilitator'. We have a couple of questions regarding BIP32 path usage, and
> we would love to have feedback from you before moving forward.
>
> Currently the BWS instances hold the set of extended public keys of the
> wallet's peers to be able to derive  addresses.
>
> Since this is a problem from the privacy point of view, we thought using
> pseudo-random  BIP32 paths, with a seed only known be the peers, so the
> server will be able to verify that addresses  submitted by peers belong to
> the wallet, but will not be able to derive future wallet addresses.
>
> The workflow would be something like:
>
> ```
> Peer >   getCurrentIndex
>
> < Server [index]
>
> Peer:
>   pathSeed = PRNG(seed, index);
>
> Peer > createAddress(index, pathSeed);
>
> Server:
>   derives the address and add it to the wallet.
>
> < Server  new address
>
> Peer: Verifies the address and inform it the user.
> ```
>
> This way, accessing server data won't reveal future wallet addresses. The
> seed (only known by the peers) could
> be derived from hashes of their xprivs, so wallet funds can still be recover
> with:
>   1) The complete set of xprivs
>   2) The quorum of xprivs + the complete set of xpubs + the address seed.
>
> Thanks a lot in advance for any comment on this schema.
>
> matías
>
> --
> BitPay.com
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development