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

[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

-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

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

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

[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

[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

[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

[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 :
> 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 deve

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

[Gregory Maxwell]

On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
 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] BIP for standard multi-signature P2SH addresses

[Gregory Maxwell]

On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin  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

[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 
wrote:

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

[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

[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  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 
> wrote:
>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>>  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] BIP for standard multi-signature P2SH addresses

[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)
  has the concept of 'Internet Drafts" (ID)
 and this looks like it
has worked for them so far.

m2c.

p.


On Thu, Mar 12, 2015 at 4:16 AM, Gregory Maxwell  wrote:

> On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin  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

[Gregory Maxwell]

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

[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  wrote:

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

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

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

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

[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

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

[Gregory Maxwell]

On Wed, Mar 11, 2015 at 11:50 PM, devrandom  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] Electrum 2.0 has been tagged

[devrandom]

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

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

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

[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

[devrandom]

On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
> On Wed, Mar 11, 2015 at 11:50 PM, devrandom  
> 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

[Bitcoin-development] Testnet3

[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

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

[Gregory Maxwell]

On Thu, Mar 12, 2015 at 2:41 AM, devrandom  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

[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 

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

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

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

[slush]

On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn  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

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

[Aaron Voisine]

On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle 
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

[Thy Shizzle]

  Why on earth would you want to derive the mnemonic from the wallet seed? Ever?
Remembering that as an attacker doesn't actually have to do any key stretching, 
they can just keep trying (what is it 64 bytes from memory?) at a time without 
any PBKDF2 to attack a seed, it seems that the PBKDF2 is just to slow down 
anyone attempting to attack through an interface such as a web service or to a 
TREZOR or whatever, in a real world attack you would not even be performing 
PBKDF2 you would just brute force the raw bytes and force them into the BIP32 
wallet as there is no Authentication scheme that hashes and compares against 
the result. It purely limits abuse through an online wallet provider or 
something like that by slowing down seed generation attempts THROUGH that API, 
it doesn't really add any security to the seed in a real world brute force 
attack! So yea I think the 2048 iteration count is sufficient for it's purpose 
because even if it only forces an extra 1ms per seed generation through the 
API, it is still slower than just brute forcing the 64 bytes straight up, and 
so they would have no reason to abuse your API that is all :)
"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] Testnet3

[Thy Shizzle]

Strangely enough, it has started to work properly and I didn't even touch my 
code just had it sitting there in the loop/ping circuit it was performing and 
capturing with wireshark.that is quite odd!

"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