slush wrote :
Two years ago I proposed exactly this and you refused to add extra
information to mnemonic, because it isn't necessary and it makes it
longer to mnemonization. What changed since then?
I was wrong, and I fully acknowledge it.
My concern was that adding extra information would
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.
Also, I can imagine that bip32 itself might be superseeded in
Le 31/10/2013 12:18, slush a écrit :
Oh, I forgot to one practical aspect; the way how the mnemonic is
mined in Thomas proposal prevents usage in embedded devices, because
difficulty of generating proper mnemonic is simply too high for
embedded microcontrollers. Maybe this can be solved
Le 03/11/2013 07:41, Timo Hanke a écrit :
No. You mean the computer would use B for this check? (k,K) could be
rigged by Trezor, who computes b as k-a. Timo
I was just asking a question, in order to understand how this device
works, and what are its requirements.
if you think you can help,
Le 03/11/2013 08:40, Timo Hanke a écrit :
I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor. Trezor makes r :=
Hello and happy new year to this mailing list!
Thank you Mark for the incredible work you've been doing on this.
I am following this very closely, because it is of primary importance
for Electrum.
I have written a Python-levelDB implementation of this UTXO hashtree,
which is currently being
Le 07/01/2014 01:21, Mark Friedenbach a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/06/2014 10:13 AM, Peter Todd wrote:
On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
I have written a Python-levelDB implementation of this UTXO
hashtree, which is currently
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.
IMO the right approach is to implement checksums that do not
Le 24/01/2014 10:05, Peter Todd a écrit :
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions
Trezor and Electrum may be earlier than this.
Sorry for not joining the discussion earlier.
I have postponed the release of bip32 features in Electrum due to
ongoing discussions with Trezor and bitcoinj developers.
I planned to post a summary in a separate thread, but this info is also
I am happy to announce the release of Electrum 1.9.8.
This release includes some features initially planned for version 2.0.
Packages are available on https://electrum.org/download.html (signed by me)
Binaries for windows and mac will be available in the coming days
enjoy
Thomas
thanks for your feedback!
I was not aware that that implementation was flawed.
I will see how I can fix that code and get back to you.
Thomas
Le 16/03/2014 14:54, Gregory Maxwell a écrit :
On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin thoma...@gmx.de wrote:
The encryption algorithm
Thanks again for having a look.
Given these problems, I have decided to remove
the encryption methods from the current release.
I retagged 1.9.8 and updated the packages.
Thomas
Le 16/03/2014 15:39, Gregory Maxwell a écrit :
On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin thoma...@gmx.de
Le 27/03/2014 00:37, Andreas Schildbach a écrit :
Thanks for starting the discussion on finding a better structure.
For me, the most important thing is either we're 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still
Le 26/03/2014 21:49, Mike Hearn a écrit :
* reserved is for other stuff. I actually don't recall why we ended
up with this. It may have been intended to split out multisig
outputs etc from cointype. Marek, Thomas?
yes, this was intended to create multisig addresses from the same
Le 27/03/2014 12:30, Marek Palatinus a écrit :
Ah, I forget to two things, which should be into the BIP as well:
a) Gap factor for addresses; as Thomas mentioned, although some software
can watch almost unlimited amount of unused addresses, this is serious
concern for lightweight or
Le 27/03/2014 12:39, Mike Hearn a écrit :
One issue that I have is bandwidth: Electrum (and mycelium) cannot
watch as many addresses as they want, because this will create too
much traffic on the servers. (especially when servers send utxo merkle
proofs for each address,
Le 27/03/2014 13:49, Mike Hearn a écrit :
Ah, BIP32 allows for a range of entropy sizes and it so happens that
they picked 256 bits instead of 128 bits.
I'd have thought that there is a right answer for this. 2^128 should not
be brute forceable, and longer sizes have a cost in terms of
Le 27/03/2014 14:44, Pavol Rusnak a écrit :
On 03/27/2014 01:06 PM, Thomas Voegtlin wrote:
Yes, I was planning to increase the number of available unused addresses
to 10 or 20 in the bip32 version of Electrum.
Also, we'd need to specify a gap limit for accounts as well. In TREZOR
we
+1
I would prefer that solution...
Le 08/04/2014 15:53, Pieter Wuille a écrit :
I see the cause of our disagreement now.
You actually want to share a single BIP32 tree across different
currency types, but do it in a way that guarantees that they never use
the same keys.
I would have
Le 09/04/2014 17:54, Gregory Maxwell a écrit :
Sadly today Electrum requires more than a full node, it requires a
number of large additional indexes over what a full node has and
pruning is precluded. I don't think that increasing the resource
utilization of the node is a good way to go there
Let me make a sacrilegious proposal: keep using the name bitcoin, and
shift the decimal point.
There would be a short adaption period, where people will need to talk
about new bitcoins and old bitcoins in order to disambiguate them.
However, Bitcoin users are techies, so I don't think that the
Le 24/04/2014 09:10, Pieter Wuille a écrit :
To clarify:
BIP64 has a much stricter definition for accounts than BIP32.
In BIP32, it is not well specified what accounts are used for. They
can be used for subwallets, receive accounts (as in bitcoind's
account feature), recurring payments,
Le 24/04/2014 09:21, Gregory Maxwell a écrit :
It doesn't appear to me that reoccurring payments, receive accounts,
multisig addresses, etc can be used with this proposal, but instead
you must use a different purpose code and another BIP and are not
compatible with the draft here.
Am I
Le 26/04/2014 11:43, Mike Hearn a écrit :
I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all,
I totally agree with gmaxwell here. The cost of interoperability is too
high. It would force us to freeze all features, and to require a broad
consensus everytime we want to add something new.
In addition, some partial level of compatibility would probably lead to
users not able to recover all
Le 24/06/2014 11:44, Wladimir a écrit :
But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
work without any special servers, so why require a 'close binding' to
a trusted bitcoin core?
To clarify (and not piss off ThomasV :-): I do not think the idea of
having servers with
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
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,
-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
Le 11/05/2015 00:31, Mark Friedenbach a écrit :
I'm on my phone today so I'm somewhat constrained in my reply, but the key
takeaway is that the proposal is a mechanism for miners to trade subsidy
for the increased fees of a larger block. Necessarily it only makes sense
to do so when the
Le 08/05/2015 22:33, Mark Friedenbach a écrit :
* For each block, the miner is allowed to select a different difficulty
(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
and this miner-selected difficulty is used for the proof of work check. In
addition to adjusting
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep
Le 12/05/2015 18:10, Gavin Andresen a écrit :
Added back the list, I didn't mean to reply privately:
Fair enough, I'll try to find time in the next month or three to write up
four plausible future scenarios for how mining incentives might work:
1) Fee-supported with very large blocks
Thank you for your answer.
I agree that a lot of things will change, and I am not asking for a
prediction of technological developments; prediction is certainly
impossible. What I would like to have is some sort of reference scenario
for the future of Bitcoin. Something a bit like the Standard
Hello Mike,
Are you aware of my proposal for network assurance contracts?
Yes I am aware of that; sorry for not mentioning it. I think it is an
interesting proposal, but I would not rely on it today, because it
includes a large share of unproven social experiment.
(Bitcoin too is a social
36 matches
Mail list logo
