On 2015-03-12 03:28 AM, Andreas Schildbach wrote:
That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for
Thanks Thomas, for sharing your experience!
I'd like know why you think it's a problem that BIP43 is tied to BIP32?
I understand we all agreed at least on the BIP32-derivation spec
(excluding the BIP32-hierarchy spec)?
Hi Andreas,
I don't think it's a problem that BIP43 is tied to BIP32.
What I don't like is that you have to explore branches of the derivation
tree, in order to know if there is a wallet. As a result, it is not
possible for the software to give a negative answer, like this wallet
is empty,
For reasonably skilled users your points are valid, but I'm sure you
also – like me – encountered the kind of user who has absolutely no clue
but thinks he understands. S/he will ignore warnings and run into
troubles. This generates a huge amount of support cases and likely tears
about lost coins.
Thy, your message threading is broken. Can you make sure your mail
program uses the correct message ID when replying?
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and
That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for privacy reasons. In any case, practical
multisig is still a
On 03/12/2015 01:11 AM, Gregory Maxwell wrote:
Ultimately, the most fundamental compatibility is guaranteed: you can
always send your funds to another wallet. This always works and
guarantees that you are never locked in to a single wallet. It is well
tested and cannot drive any software in
b) Creation date is just a short-term hack.
I agree, but we need things to be easy in the short term as well as the
long term :)
The long term solution is clearly to have the 12 word seed be an encryption
key for a wallet backup with all associated metadata. We're heading in that
direction
Den 12 mar 2015 19:52 skrev Andreas Schildbach andr...@schildbach.de:
I'm afraid this will never fly. Wallets are just too different and
that's a good thing! For example, by design choice Bitcoin Wallet and
bitcoinj doesn't support multiple accounts. How would it ever import
wallets from
Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net:
b) Creation date is just a short-term hack.
I agree, but we need things to be easy in the short term as well as the
long term :)
The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with
On 03/12/2015 07:27 PM, Natanael wrote:
Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net
mailto:m...@plan99.net:
b) Creation date is just a short-term hack.
I agree, but we need things to be easy in the short term as well as
the long term :)
The long term solution is clearly to
On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
For an emergency transition the user is probably better off with an
explicit unstructured mass private key export, and a sweep function;
and guaranteeing compatibility with that is much easier; and because
it moves
2015 06:51:37 -0500
From: nei...@thecodefactory.org
To: thashizn...@yahoo.com.au
CC: Bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Ok, I see your point here, and I was referring to rebuilding from
entropy -- which as you noted
Ok, I see your point here, and I was referring to rebuilding from
entropy -- which as you noted is not a real world usage. It is a
useful implementation test though and at the very least the existing
test vectors would need to be regenerated with each word list change.
I recently added BIP39 to
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
Great to see Electrum 2.0 tagged !
It's been a long road I know.
Congratulations to ThomasV and all the other Electrum contributors.
:-)
Jim
--
http://bitcoin-solutions.co.uk
On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote:
Congrats Thomas! Glad to see Electrum 2 finally launch.
*
Congrats on the release! Electrum is a very nice wallet.
On 03/01/2015 04:23 PM, Thomas Voegtlin wrote:
Dear Bitcoin devs,
I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0
The electrum.org website will be updated later today. The release
notes are a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Bitcoin devs,
I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0
The electrum.org website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in
36 matches
Mail list logo
