Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-25 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-31 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-02 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Thomas Voegtlin
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,

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-11-03 Thread Thomas Voegtlin
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 :=

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2014-01-05 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2014-01-06 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] BIP0039: Final call

2014-01-24 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Thomas Voegtlin
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

[Bitcoin-development] Electrum 1.9.8 release

2014-03-16 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Electrum 1.9.8 release

2014-03-16 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Electrum 1.9.8 release

2014-03-16 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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,

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-27 Thread Thomas Voegtlin
Related to this, here is another idea I would like to submit: Instead of using a gap limit (maximal number of consecutive unused addresses), I think we should get rid of the topology, and simply count the number of unused addresses since the beginning of the sequence.

Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread Thomas Voegtlin
+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

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] bits: Unit of account

2014-04-21 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Thomas Voegtlin
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,

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

2014-04-26 Thread Thomas Voegtlin
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,

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Thomas Voegtlin
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

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

2015-03-11 Thread Thomas Voegtlin
Thanks Mike, and sorry to answer a bit late; it has been a busy couple of weeks. You are correct, a BIP39 seed phrase will not work in Electrum, and vice versa. It is indeed unfortunate. However, I believe BIP39 should not be followed, because it reproduces two mistakes I did when I designed the

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

2015-03-12 Thread Thomas Voegtlin
Hi Andreas, I don't think it's a problem that BIP43 is tied to BIP32. What I don't like is that you have to explore branches of the derivation tree, in order to know if there is a wallet. As a result, it is not possible for the software to give a negative answer, like this wallet is empty,

[Bitcoin-development] Electrum 2.0 has been tagged

2015-03-01 Thread Thomas Voegtlin
-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

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-10 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-10 Thread Thomas Voegtlin
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

[Bitcoin-development] Long-term mining incentives

2015-05-11 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Long-term mining incentives

2015-05-12 Thread Thomas Voegtlin
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

Re: [Bitcoin-development] Long-term mining incentives

2015-05-26 Thread Thomas Voegtlin
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