Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Mike Hearn
bitcoinj also uses this convention.
--
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

2015-03-11 Thread Thomas Voegtlin
Thanks Mike, and sorry to answer a bit late; it has been a busy couple
of weeks.

You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.

The first problem I have with BIP39 is that the seed phrase does not
include a version number.

Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.

However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.

BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, having to explore the branches of the BIP32 tree in order to
determine the type of wallet attached to a seed might be somewhat
inefficient.

The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without
including the wordlist in the standard.

There are two ways to derive a master key from a mnemonic phrase:
 1. A bidirectional mapping between words and numbers, as in old
Electrum versions. Pros: bidirectional means that you can do Shamir
secret sharing of your seed. Cons: It requires a fixed wordlist.
 2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
required. Cons: the mapping isn't bidirectional.

Electrum v1 uses (1). Electrum v2 uses (2).

Early versions of BIP39 used (1), and later they switched to (2).
However, BIP39 uses (2) only in order to derive the wallet keys, not for
its checksum. The BIP39 checksum uses (1), and it does requires a fixed
wordlist. This is just plainly inconsistent. As a result, you have
neither wordlist flexibility, nor Shamir secret sharing.

Having a fixed wordlist is very unfortunate. First, it means that BIP39
will probably never leave the 'draft' stage, until all languages of the
world have been added. Second, once you add a wordlist for a new
language, you cannot change it anymore, because it will break existing
seed phrases; therefore you have to be extremely careful in the way you
design these wordlists. Third, languages often have words in common.
When you add a new language to the list, you should not use words
already used by existing wordlists, in order to ensure that the language
can be detected. It leads to a first come first served situation, that
might not be sustainable in the future.

In order to support the old Electrum v1 seeds, all future versions of
Electrum will have to include the old wordlist. In addition, when
generating new seed phrases, Electrum now has to avoid collisions with
old seed phrases, because the old ones did not have a version number.
This is painful enough, I will not repeat the same errors twice.

Electrum v2 derives both its private keys and its checksum/version
number using a hash of the seed phrase. This means that wordlists can be
added and modified in the future, without breaking existing seed
phrases. It also means that it will be very easy for other wallets to
support Electrum seedphrases: it requires about 20 lines of code, and no
wordlist is required.


Thomas


Le 02/03/2015 16:37, Mike Hearn a écrit :
 Congrats Thomas! Glad to see Electrum 2 finally launch.
 
 
 * New seed derivation method (not compatible with BIP39).
 
 
 Does this mean a 12 words wallet created by Electrum won't work if
 imported into some other wallet that supports BIP39? Vice versa? This seems
 unfortunate. I guess if seeds are being represented with 12 words
 consistently, people will expect them to work everywhere.
 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your 

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

2015-03-11 Thread Mike Hearn
Sigh. The wallet words system is turning into kind of a mess.

I thought the word list is in fact not a fixed part of the spec, because
the entropy is a hash of the words. But perhaps I'm misunderstanding
something.

The main problem regular SPV wallets have with BIP39 is that there is no
birth time included in the data. Therefore we must ask users to write down
a timestamp as well, so we know where to start rescanning the chain. It
sounds like the Electrum version doesn't fix this, so now we have at least
FIVE incompatible results from a 12 word list:

   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some
   seeds I believe are now being generated with 24 words instead of 12.
   - MultiBit HD with no version and a date in a custom form that creates
   non-date-like codes you are expected to write down. I think BIP32 and BIP44
   are both supported (sorta).
   - GreenAddress with no version, no date and BIP32
   - Other bitcoinj based wallets, with no version and a date written down
   in normal human form, BIP32 only.

I really hope we can recover from this somehow because otherwise all
wallets will have to provide the user with a complicated matrix of
possibilities and software combinations, and in practice many won't bother
so these word combinations will actually end up being wallet specific for
no particularly good reason, just very minor details like the presence or
absence of single fields.

It feels like we somehow fell flat on our faces just before the finishing
line. This is deeply unfortunate. Compatibility and UX consistency is
important!

Currently, I don't have any bright ideas for how to get everyone back onto
the same page with a fully compatible system that is acceptable to all. If
anyone else has suggestions, I'm all ears.
--
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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote:
 I used BIP0090 as a place-holder, but I would like to request a BIP number
 for this now.

We have had repeated problems in the past with people working on and
circulating prior draft proposals squatting on each others numbers,
and each demanding access to the same numbers. As a matter of
procedure I will not assign squatted numbers, but also discussion
should come in advance of number assignment; general subject here
seems reasonable but many proposals are withdrawn by the party
tendering them after further discussion shows the effort to be without
public interest or actually subsumed by other functionality. :)

Proposals should not be called BIP[nn] until they're actually a BIP.
  Feel free to call it bip-kerin-multisignature or any other
placeholder name that won't be confused with a finished BIP for
drafting.

If there is any public documentation on the process which caused you
specific confusion, please feel free to point me at it and I'll be
sure to fix it! Sorry for any confusion there.

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

2015-03-11 Thread Jim
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.

-- 
http://bitcoin-solutions.co.uk

On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
 Sigh. The wallet words system is turning into kind of a mess.
 
 I thought the word list is in fact not a fixed part of the spec, because
 the entropy is a hash of the words. But perhaps I'm misunderstanding
 something.
 
 The main problem regular SPV wallets have with BIP39 is that there is no
 birth time included in the data. Therefore we must ask users to write down
 a timestamp as well, so we know where to start rescanning the chain. It
 sounds like the Electrum version doesn't fix this, so now we have at least
 FIVE incompatible results from a 12 word list:
 
- Electrum v2 with a version number but no date
- myTREZOR with no version and no date and BIP44 key derivation. Some
seeds I believe are now being generated with 24 words instead of 12.
- MultiBit HD with no version and a date in a custom form that creates
non-date-like codes you are expected to write down. I think BIP32 and BIP44
are both supported (sorta).
- GreenAddress with no version, no date and BIP32
- Other bitcoinj based wallets, with no version and a date written down
in normal human form, BIP32 only.
 
 I really hope we can recover from this somehow because otherwise all
 wallets will have to provide the user with a complicated matrix of
 possibilities and software combinations, and in practice many won't bother
 so these word combinations will actually end up being wallet specific for
 no particularly good reason, just very minor details like the presence or
 absence of single fields.
 
 It feels like we somehow fell flat on our faces just before the finishing
 line. This is deeply unfortunate. Compatibility and UX consistency is
 important!
 
 Currently, I don't have any bright ideas for how to get everyone back onto
 the same page with a fully compatible system that is acceptable to all. If
 anyone else has suggestions, I'm all ears.
 --
 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

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
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


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

2015-03-11 Thread Ricardo Filipe
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...

2015-03-11 19:04 GMT+00:00 Jim jim...@fastmail.co.uk:
 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.

 --
 http://bitcoin-solutions.co.uk

 On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
 Sigh. The wallet words system is turning into kind of a mess.

 I thought the word list is in fact not a fixed part of the spec, because
 the entropy is a hash of the words. But perhaps I'm misunderstanding
 something.

 The main problem regular SPV wallets have with BIP39 is that there is no
 birth time included in the data. Therefore we must ask users to write down
 a timestamp as well, so we know where to start rescanning the chain. It
 sounds like the Electrum version doesn't fix this, so now we have at least
 FIVE incompatible results from a 12 word list:

- Electrum v2 with a version number but no date
- myTREZOR with no version and no date and BIP44 key derivation. Some
seeds I believe are now being generated with 24 words instead of 12.
- MultiBit HD with no version and a date in a custom form that creates
non-date-like codes you are expected to write down. I think BIP32 and 
 BIP44
are both supported (sorta).
- GreenAddress with no version, no date and BIP32
- Other bitcoinj based wallets, with no version and a date written down
in normal human form, BIP32 only.

 I really hope we can recover from this somehow because otherwise all
 wallets will have to provide the user with a complicated matrix of
 possibilities and software combinations, and in practice many won't bother
 so these word combinations will actually end up being wallet specific for
 no particularly good reason, just very minor details like the presence or
 absence of single fields.

 It feels like we somehow fell flat on our faces just before the finishing
 line. This is deeply unfortunate. Compatibility and UX consistency is
 important!

 Currently, I don't have any bright ideas for how to get everyone back onto
 the same page with a fully compatible system that is acceptable to all. If
 anyone else has suggestions, I'm all ears.
 --
 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

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

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

2015-03-11 Thread Aaron Voisine
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 gmaxw...@gmail.com
wrote:

 On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
 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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Pindar Wong
Hi,

Perhaps at some point consider introducing something akin to a
'Bitcoin-Draft' (BD) status with some autoexpiry period?

I understand that the Internet Engineering Task Force (IETF)
http://www.ietf.org  has the concept of 'Internet Drafts (ID)
http://www.ietf.org/ietf-ftp/1id-guidelines.txt and this looks like it
has worked for them so far.

m2c.

p.


On Thu, Mar 12, 2015 at 4:16 AM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote:
  I used BIP0090 as a place-holder, but I would like to request a BIP
 number
  for this now.

 We have had repeated problems in the past with people working on and
 circulating prior draft proposals squatting on each others numbers,
 and each demanding access to the same numbers. As a matter of
 procedure I will not assign squatted numbers, but also discussion
 should come in advance of number assignment; general subject here
 seems reasonable but many proposals are withdrawn by the party
 tendering them after further discussion shows the effort to be without
 public interest or actually subsumed by other functionality. :)

 Proposals should not be called BIP[nn] until they're actually a BIP.
   Feel free to call it bip-kerin-multisignature or any other
 placeholder name that won't be confused with a finished BIP for
 drafting.

 If there is any public documentation on the process which caused you
 specific confusion, please feel free to point me at it and I'll be
 sure to fix it! Sorry for any confusion there.


 --
 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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote:
 Perhaps at some point consider introducing something akin to a
 'Bitcoin-Draft' (BD) status with some autoexpiry period?

 I understand that the Internet Engineering Task Force (IETF)  has the
 concept of 'Internet Drafts (ID) and this looks like it has worked for them
 so far.

Thats more or less what posting to the list is supposed to be.
Creating a draft document requires no approval, beyond filling out the
right form.

Perhaps calling out that as a distinct step would be better, indeed.

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

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net wrote:
 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.

The fact remains that there are several apparently unresolvable
well-principled perspectives on this subject.

(And I can speak to this personally: There are several BIPs in this
space that I'd rather not see in product with my name on it.)

Unless two wallets have exactly the same feature set, cross importing
keys is going to confuse or break something. Even if you're trying to
be fairly generic the testing overhead for all possible strategies and
structures is large. Expecting compatibility here would be like
expecting two large commercial accounting packages to support the same
internal file formats. Compatibility is only straight forward when the
feature set is as limited as possible.

The space for weird behavior to harm users is pretty large... e.g. you
could load a key into two wallets, such that one can see all the funds
by the other, but not vice versa and and up losing funds by
incorrectly assuming you had no coins; or inadvertently rip of your
business partners by accounting for things incorrectly.

Even ignoring compatibility, most demanded use cases here are ones
that create concurrent read/write use of single wallet without some
coordinating service is inherently somewhat broken because you can
double spend yourself, and end up with stalled and stuck transactions
and causing people to think you tried ripping them off.

I certainly recognize the desirable aspects of just being able to load
a common wallet, and that inexperienced users expect it to just work.
But I don't think that expectation is currently very realistic except
within limited domains. It may be more realistic in the future when
the role of wallets is better established. I don't see any _harm_ in
trying to standardize what can be, I just don't expect to see a lot of
success.

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.

--
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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Pindar Wong
Understood... perhaps just add something like:

'After copy-editing and acceptance,* a BIP number is assigned* and it will
be published here.'?

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

p.


On Thu, Mar 12, 2015 at 7:34 AM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com
 wrote:
  Perhaps at some point consider introducing something akin to a
  'Bitcoin-Draft' (BD) status with some autoexpiry period?
 
  I understand that the Internet Engineering Task Force (IETF)  has the
  concept of 'Internet Drafts (ID) and this looks like it has worked for
 them
  so far.

 Thats more or less what posting to the list is supposed to be.
 Creating a draft document requires no approval, beyond filling out the
 right form.

 Perhaps calling out that as a distinct step would be better, indeed.

--
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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread devrandom
ACK.  CryptoCorp uses this method for our external signer service.

On 2015-03-11 04:45 AM, Thomas Kerin wrote:
 
 Hi all,
 
 I just created a PR on bitcoin/bips for a proposed standard for creating
 standard multisignature P2SH addresses given m, and a set of public keys.
 
 https://github.com/bitcoin/bips/pull/146
 
 I used BIP0090 as a place-holder, but I would like to request a BIP
 number for this now.
 
 All the best,
 
 
 
 
 --
 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
 

-- 
devrandom / Miron

-- 
devrandom / Miron

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

2015-03-11 Thread Mike Hearn

 I'd like to offer that the best practice for the shared wallet use case
 should be multi-device multi-sig.


Sure. But in practice people will want to have a pool of spending money
that they can spend when they are out and about, and also with one click
from their web browser on their primary computer, and maybe also on their
games console, etc etc.

I don't think we can realistically tell people to *always* use clever
multi-device wallets - there will always be a desire to have a convenient
hot wallet that's synchronised between different devices.
--
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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Thomas Kerin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

I just created a PR on bitcoin/bips for a proposed standard for creating
standard multisignature P2SH addresses given m, and a set of public keys.

https://github.com/bitcoin/bips/pull/146

I used BIP0090 as a place-holder, but I would like to request a BIP
number for this now.

All the best,

- -- 
Thomas Kerin
- -

My PGP key can be found here
http://pgp.mit.edu/pks/lookup?op=getsearch=0x3F0D2F83A2966155
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJVACrVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVkGgQAIUpyA3PsNjCA99W1HwFI7Ra
+g+JTtXBdhJSvVpv67TlaPZzp4LP7rRW/U1Nv0JYvhpQZTsV/xcMSKpy56d3S50M
Yvxwy51Aco1LEPC1vuiE2aJ8lDwCrXJMxJwfdBp6iNwf0huZNrsqZNKUHwMepePj
PYlGBkyfnp7QXo0ZkYBCJ2yerir5emKap3AibijRtkTrq6K1+YRk/9UZHllZSmmk
/B8n6xy/+v65uoAriVwKkX7H0bXmNTjleMzXbm/+Zhh9qfEnp2zqGmBIk5ooV5x4
3Flb76EYAMXibfAQ2+NPoCiPxCDIEWIsWqyzOC9zWX1QZN55qT3s/p7olYtaYheD
mf2xZ2pI/cIxpiYGfFEn4C/l0dOCNFLfElgsFcn4RsqRE41Grm+MGAPrf7S5bstp
TPIALOoVShucHaMvD/6sdK51hC54MKktNDtzTIumnWtOMwTy9qbELIcNvD8DaFe8
7FVZ7Vndj2FfXCNBF2EHzmy4D4+BE2YZ07pLQVUrc79oidUTs/099PsnUNOEYz0l
Y4IL/5qJMep9PJlj+IlbfXFX0zfTLJF7vJgjYMybr0iKP66iTtuHc46QFxTRyIhC
dMLXbSqm9X5zEc1j9Q50dSE5rqIT3/gkQe7nWFwf4xC7hlLAXSm8HuqwRSkZdP19
2byvsvoZ+4D4drXHXXpi
=QU8i
-END PGP SIGNATURE-

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

2015-03-11 Thread Thy Shizzle
Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it is 
not, it is unfortunate that Electrum did not go the route of BIP39. The 
wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually 
propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39  On 2015-03-11 06:21 PM, 
Thy Shizzle wrote:
 H I don't think it's fair to say that there has been a failure to
 standardise. From what I read earlier among the wallets, mostly it came
 down to if a version was noted and the date. Assuming no date is
 provided, it just means you are scanning the block chain from day 0 for
 transactions right? Hardly a big deal as you will still recover funds right?

Unfortunately there's more incompatibility than just the date issue:

* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own

So actually very few wallets are seed-compatible, even ignoring the date
question.

 
 Version right now is irrelevant as there is only one version of BIP39
 currently, probably this will change as 2048 iterations of HMACSHA512
 will likely need to be up scaled in the future, I thought about adding
 one extra word into the mnemonic to signify version, so if you have a 12
 word mnemonic then you have 12 words + 1 word version. Version 1 has no
 extra word, version 2 uses the first word on the list, version 3 uses
 the second word on the wordlist, so on and so forth. Least that's what I
 was thinking of doing if I ever had to record a version, won't effect
 anything because entropy increases in blocks of 3 words so one extra
 word can simply be thrown on the end.

That's a reasonable solution.

 
 So in summary I feel that date can be handled by assuming day 0, and
 version is not an issue yet but may become one and probably it is a good
 idea to think about standardising a version into BIP39, I have
 provided a seed idea for discussion.
 
 I don't think it is quite the doom and gloom I'm reading :)
 
 
 devrandom:
 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.

-- 
devrandom / Miron--
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

2015-03-11 Thread Gregory Maxwell
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@niftybox.net wrote:
 I think there are some important advantages to not being forced to use
 the old wallet to send coins when switching wallets. The three I can
 think of right now are: maintaining transaction history,

Just loading a key doesn't keep transaction history however, if the
loading wallet can't understand or infer metadata about the
transactions. You get some mass of data but to tell actually what the
transactions are, or what they were for, forensic accounting is
required and some data will be potentially unrecoverable.

The best way to preserve historical information is to use reporting
from the wallet in question; which will accurately record the best
available output for this. (E.g. Bitcoin-qt has a CSV export or you
can take a json list-transactions out of it).

 emergency transition when a wallet has a serious (e.g. money losing) bug

This cuts both ways, we've seen significant losses for users in
Bitcoin Core where they've used the console to import keys that they
also used in other insecure clients.

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.

 and web
 wallet with server down.

I suppose it would be too much to ask that these web wallets actually
not be totally centrally controlled and have the potential of just
having someone else stand up a server. I guess not. :(

Emergencies being what the are you do with what you can... indeed, I
agree thats a reason that better compatibility is better. (But perhaps
best is that its insane to use software to handle your money that can
just be taken away from you like that...)

 Another important reason to standardize is to reduce the roll your own
 crypto temptation on the wallet creator part, where the wallet-specific
 algorithm is more likely to contain weaknesses.
 I do agree that trying to come up with one uber standard will likely
 fail and is probably counter productive.

Careful with this line of thinking: We have no mechanism in the BIP
process to exclude weak cryptography.

A BIP is not a measure of cryptographic integrity. There are existing
BIPs which I consider flawed and would not use or recommend.

It result in some level of review, maybe, and so it can be productive
to at least have more eyes on fewer things; which is a reason I
wouldn't say don't bother trying.

And indeed, I do think that what can be standardized should be, my
words weren't intended to dismiss anyone's efforts, only to encourage
realistic (I think) expectations around what will come of it.

And while I hope for no gratuitous incompatibility, I also hope that
no one working on a wallet hesitates for a minute to offer a new and
interesting functionality just because it doesn't fit into a prefab
shape.

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

2015-03-11 Thread Mike Hearn
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 vois...@gmail.com 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 gmaxw...@gmail.com
 wrote:

 On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
 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
 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

2015-03-11 Thread Thy Shizzle
That's disappointing the Electrum 2.0 doesn't use BIP39.
From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between 
wallet providers. There is some recommendations regarding the wordlists to 
help with things such as predictive text, so mobile apps can easily predict 
the word being typed in after a few chars etc. This would seem to be the 
reasoning for the reference word lists. Now there is nothing stopping one from 
implementing a wordlist of say profanities or star wars terms or whatever and 
still accepting a mnemonic from another provider. Remember if you have a 
mnemonic from a different wordlist, simply Normalization of the words occurs 
and then the hashing the mnemonic to derive the seed bytes. It is not really a 
restriction at all! BIP39 was designed such that the mnemonic generation is 
decoupled from seed derivation, just like what you are saying Electrum 2.0 can 
do! The wordlist is only needed for mnemonic generation NOT seed derivation, 
so Electrum DOES NOT need a copy of the BIP39 word lists to generate the seed 
from the phrase, there is really not much reason for Electrum not to accept 
BIP39 mnemonics at the moment! it requires bugger all code! Here is my seed 
generation code



//literally this is the bulk of the decoupled seed generation code, easy.byte[] 
salt = 
Utilities.MergeByteArrays(UTF8Encoding.UTF8.GetBytes(cSaltHeader),_passphraseBytes);return
 
Rfc2898_pbkdf2_hmacsha512.PBKDF2(UTF8Encoding.UTF8.GetBytes(Utilities.NormaliseStringNfkd(MnemonicSentence)),
 salt);

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.
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.
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 in and I think you should do that :) I don't 
have any interest in BIP39 other than it being a standard. I think TREZOR may 
have an interest in it?
Thomas V:
Thanks Mike, and sorry to answer a bit late; it has been a busy couple
of weeks.

You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.

The first problem I have with BIP39 is that the seed phrase does not
include a version number.

Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.

However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.

BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, having to explore the branches of the BIP32 tree in order to
determine the type of wallet attached to a seed might be somewhat
inefficient.

The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without

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

2015-03-11 Thread devrandom
On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
 On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net 
 wrote:
 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.
 
 The fact remains that there are several apparently unresolvable
 well-principled perspectives on this subject.
 
 (And I can speak to this personally: There are several BIPs in this
 space that I'd rather not see in product with my name on it.)
 
 Unless two wallets have exactly the same feature set, cross importing
 keys is going to confuse or break something. Even if you're trying to
 be fairly generic the testing overhead for all possible strategies and
 structures is large. Expecting compatibility here would be like
 expecting two large commercial accounting packages to support the same
 internal file formats. Compatibility is only straight forward when the
 feature set is as limited as possible.

You make some good points.  However, I still hope for standardization by
profile.  E.g. a consumer profile for wallets with just one account,
a business profile for small business wallets.  If an application
falls outside of the standardized profiles, they can roll their own or
try to promote a new standard.

I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history, emergency
transition when a wallet has a serious (e.g. money losing) bug and web
wallet with server down.

Another important reason to standardize is to reduce the roll your own
crypto temptation on the wallet creator part, where the wallet-specific
algorithm is more likely to contain weaknesses.

I do agree that trying to come up with one uber standard will likely
fail and is probably counter productive.

 
 The space for weird behavior to harm users is pretty large... e.g. you
 could load a key into two wallets, such that one can see all the funds
 by the other, but not vice versa and and up losing funds by
 incorrectly assuming you had no coins; or inadvertently rip of your
 business partners by accounting for things incorrectly.
 
 Even ignoring compatibility, most demanded use cases here are ones
 that create concurrent read/write use of single wallet without some
 coordinating service is inherently somewhat broken because you can
 double spend yourself, and end up with stalled and stuck transactions
 and causing people to think you tried ripping them off.
 
 I certainly recognize the desirable aspects of just being able to load
 a common wallet, and that inexperienced users expect it to just work.
 But I don't think that expectation is currently very realistic except
 within limited domains. It may be more realistic in the future when
 the role of wallets is better established. I don't see any _harm_ in
 trying to standardize what can be, I just don't expect to see a lot of
 success.
 
 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.
 

-- 
devrandom / Miron

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

2015-03-11 Thread slush
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn m...@plan99.net wrote:


- Electrum v2 with a version number but no date
- myTREZOR with no version and no date and BIP44 key derivation. Some
seeds I believe are now being generated with 24 words instead of 12.
- MultiBit HD with no version and a date in a custom form that creates
non-date-like codes you are expected to write down. I think BIP32 and BIP44
are both supported (sorta).
- GreenAddress with no version, no date and BIP32
- Other bitcoinj based wallets, with no version and a date written
down in normal human form, BIP32 only.

 To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD
uses BIP44 with first account only and GreenAddress uses another scheme
because it's multisig only wallet).

I disagree with the need of some version magic flags or creation date
stored in the mnemnonic, for those reasons:

a) If we fail in the way how mnemonic algo is defined, then some magic,
extra version flag won't save our asses, because we'll fail in meaning of
its meaning. Then it will be completely useless, as implementations cannot
rely on it. I know Thomas was sound proponent of this solution, but he was
unable to give any reasonable rules about who/how define meaning of version
flag.

b) Creation date is just a short-term hack. Considering that mnemonic
words are kind of cold storage (longterm storage), it *really* does not
make much difference in 2020, if your wallet has been created in 02/2014 or
10/2016. If there's performance issue with scanning of the blockchain,
creation date don't save our asses. We need to find another solution, and
as a bonus, we don't need users to know some weird numbers on top of
mnemonic itself.

 From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed
between wallet providers. There is some recommendations regarding the
wordlists to help with things such as predictive text, so mobile apps can
easily predict the word being typed in after a few chars etc.

Exactly! After some community feedback, we changed BIP39 algo to be one-way
only, which means you can use *any* wordlist to create the mnemonic, and
any other implementation can derive BIP32 root node even without knowing
that particular wordlist. Namely this has been changed because of
constructive criticism of ThomasV, and from discussion on the mailing list
I had a feeling that we've found a consensus. I was *very* surprised that
Electrum 2.0 started to use yet another algo just because.

Shortly said, I think BIP39 does perfect job and there's no need to use
anything else.

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

2015-03-11 Thread Thy Shizzle
Yes I agree with this sentiment.
As for the version, don't forget we can kinda brute force our way to 
determine a version, because lets say there is 10 versions, we can generate the 
seed for all 10 versions and then check to see which seed was in use (has 
transacted) and then use that seed. If no transactions are found, we could 
restore the wallet with the seed of the latest and greatest version. Not really 
any need to store the version, sure it may save some time but as Marek rightly 
says, this is for restoration of a wallet from cold storage not an everyday 
thing so the extra time to brute force the version etc is acceptable as a trade 
off for not forcing the remembering of a version.
BIP39 is beautiful.
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn m...@plan99.net wrote:

   
   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some seeds 
I believe are now being generated with 24 words instead of 12.
   - MultiBit HD with no version and a date in a custom form that creates 
non-date-like codes you are expected to write down. I think BIP32 and BIP44 are 
both supported (sorta).
   - GreenAddress with no version, no date and BIP32
   - Other bitcoinj based wallets, with no version and a date written down in 
normal human form, BIP32 only.

To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just 
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses 
BIP44 with first account only and GreenAddress uses another scheme because it's 
multisig only wallet).
I disagree with the need of some version magic flags or creation date stored 
in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic, extra 
version flag won't save our asses, because we'll fail in meaning of its 
meaning. Then it will be completely useless, as implementations cannot rely on 
it. I know Thomas was sound proponent of this solution, but he was unable to 
give any reasonable rules about who/how define meaning of version flag.
b) Creation date is just a short-term hack. Considering that mnemonic words 
are kind of cold storage (longterm storage), it *really* does not make much 
difference in 2020, if your wallet has been created in 02/2014 or 10/2016. If 
there's performance issue with scanning of the blockchain, creation date don't 
save our asses. We need to find another solution, and as a bonus, we don't need 
users to know some weird numbers on top of mnemonic itself.
 From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between 
wallet providers. There is some recommendations regarding the wordlists to 
help with things such as predictive text, so mobile apps can easily predict 
the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way 
only, which means you can use *any* wordlist to create the mnemonic, and any 
other implementation can derive BIP32 root node even without knowing that 
particular wordlist. Namely this has been changed because of constructive 
criticism of ThomasV, and from discussion on the mailing list I had a feeling 
that we've found a consensus. I was *very* surprised that Electrum 2.0 started 
to use yet another algo just because.
Shortly said, I think BIP39 does perfect job and there's no need to use 
anything else.
Cheers,Marek--
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

2015-03-11 Thread Aaron Voisine
On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle thashizn...@yahoo.com.au
wrote:

 BIP39 is beautiful.

meh... the fact that you can't derive the seed phrase from the wallet seed,
and that the password key stretching is so weak as to be ineffectual
security theater bugs me. Feels like a pretty big compromise to work on
current generation low power embedded devices when the next generation will
be more than capable. But I understand the motivation for the compromise.

Aaron Voisine
co-founder and CEO
breadwallet.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] Electrum 2.0 has been tagged

2015-03-11 Thread Thy Shizzle
 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 in and I think you should do that :) I don't 
 have any interest in BIP39 other than it being a standard. I think TREZOR may 
 have an interest in it?
 Thomas V:
 Thanks Mike, and sorry to answer a bit late; it has been a busy couple
 of weeks.
 
 You are correct, a BIP39 seed phrase will not work in Electrum, and vice
 versa. It is indeed unfortunate. However, I believe BIP39 should not be
 followed, because it reproduces two mistakes I did when I designed the
 older Electrum seed system. Let me explain.
 
 The first problem I have with BIP39 is that the seed phrase does not
 include a version number.
 
 Wallet development is still in an exploratory phase, and we should
 expect even more innovation in this domain. In this context, it is
 unwise to make decisions that prevent future innovation.
 
 However, when we give a seed phrase to users, we have a moral obligation
 to keep supporting this seed phrase in future versions. We cannot simply
 announce to Electrum users that their old seed phrase is not supported
 anymore, because we created a new version of the software that uses a
 different derivation. This could lead to financial losses for users who
 are unaware of these technicalities. Well, at least, that is how I feel
 about it.
 
 BIP39 and Electrum v2 

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

2015-03-11 Thread Neill Miller
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 in and I think you should do that :) I don't 
 have any interest in BIP39 other than it being a standard. I think TREZOR may 
 have an interest in it?
 Thomas V:
 Thanks Mike, and sorry to answer a bit late; it has been a busy couple
 of weeks.
 
 You are correct, a BIP39 seed phrase will not work in Electrum, and vice
 versa. It is indeed unfortunate. However, I believe BIP39 should not be
 followed, because it reproduces two mistakes I did when I designed the
 older Electrum seed system. Let me explain.
 
 The first problem I have with BIP39 is that the seed phrase does not
 include a version number.
 
 Wallet development is still in an exploratory phase, and we should
 expect even more innovation in this domain. In this context, it is
 unwise to make decisions that prevent future innovation.
 
 However, when we give a seed phrase to users, we have a moral obligation
 to keep supporting this seed phrase in future versions. We cannot simply
 announce to Electrum users that their old seed phrase is not supported
 anymore, because we created a new version of the software that uses a
 different derivation. This could lead to financial losses for users who
 are unaware of these technicalities. Well, at least, that is how I feel
 about it.
 
 BIP39 and Electrum v2 have a very different ways of handling future
 innovation. Electrum v2 seed phrases include an explicit version number,
 that indicates how the wallet addresses should be derived. In contrast,
 BIP39 seed phrases do not include a version number at all. BIP39 is
 meant to be combined with BIP43, which stipulates that the wallet
 structure should depend on the BIP32 derivation path used for the wallet
 (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
 innovation in BIP43 is allowed only within the framework of BIP32. In
 addition, having to explore the branches of the BIP32 tree in order to
 determine the type of wallet attached to a seed might be somewhat
 inefficient.
 
 The second problem I see with BIP39 is that it requires a fixed
 wordlist. Of course, this forbids innovation in the wordlist itself, but
 that's not the main problem. When you write a new standard, it is
 important to keep this standard minimal, given the goal you want to
 achieve. I believe BIP39 could (and should) have been written without
 including the wordlist in the standard.
 
 There are two ways to derive a master key from a mnemonic phrase:
  1. A bidirectional mapping between words and numbers, as in old
 Electrum versions. Pros: bidirectional means that you can do Shamir
 secret sharing of your seed. Cons: It requires a fixed wordlist.
  2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not
 required. Cons: the mapping 

[Bitcoin-development] Testnet3

2015-03-11 Thread Thy Shizzle
 Hi, so I have my .NET node communicating on the P2P network just fine, so I 
figured as I'll now start looking at making and validating transactions etc I 
should probably migrate to test net. Now I see that we are up to the third 
generation testnet testnet3, and I am sending my messages now using packet 
magic 0x0b110907 and I'm using Wireshark and I can confirm that my messages are 
going out with that packet magic.
Now what is interesting is that when I try connect to a test node obtained from 
DNS seed testnet-seed.bitcoin.petertodd.org, I send it a version message with 
the testnet3 packet magic, yet I get no verack or version in response In 
fact, the only thing I get back is a ping and then the connection is severed by 
the remote node.
What is going on? Also, it works fine with the mainnet packet magic value of 
0x0f9beb4d9 and I am debuging my code and ensuring it is looking for the 
testnet3 packet magic, but I am not getting a response from the node?




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