[Bitcoin-development] Proposal to replace BIP0039

2013-10-24 Thread thomasV1
I would like to propose a new BIP, that replaces BIP0039.

My initial problem was that BIP0039 is not backward compatible with Electrum. 
When trying to solve that, I realized that the seed encoding used in Electrum 
does not help, because it does not contain a version number information. 
However, BIP0039 suffers the same shortcoming: it does nothing to help a future 
replacement, it wants to be final. My first recommendation is to allocate a few 
bits of the mnemonic, in order to encode a version number along with the 
checksum bits.

The second problem is the wallet structure. There are multiple ways to use a 
BIP32 tree, and each client will certainly handle this differently. For 
Electrum, it is important to be able to recover an entire wallet from its 
mnemonic, using no extra information. Thus, the client needs to know which 
branches of the BIP32 tree are populated by default. This means that the 
version number I mentioned will not only be about the seed encoding, but it 
should also give some information about the wallet structure, at least in the 
case of Electrum.

The third problem is the dictionary. I do not like the dictionary proposed in 
BIP0039, because it contains too many short words, which are bad for 
memorization (I explained here how I designed the dictionary used by Electrum: 
https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I had 
some discussions with slush about this, but I do not think it will ever be 
possible to find a consensus on that topic. 

BIP0039 also suggests to use localized dictionaries, with non-colliding word 
lists, but it is not clear how that will be achieved; it seems to be difficult, 
because languages often have words in common. It looks like a 
first-come-first-served aproach will be used. 

For these reasons, I believe that we need a dictionary-independent solution. 
This will allow developers to use the dictionary they like, and localization 
will be easy.

I would like to suggest the following solution:

1. Define a target of k bits: this target contains the metadata (version 
number), plus some extra bits for the checksum. For example, with k=16, we can 
allocate 8 bits for the version number, and 8 bits for checksum.

2. Pick a random number of length n+k bits, where n is the desired entropy of 
the seed, and k is the number of bits needed for the metadata (checksum, 
version number)

3. Translate this random number to a mnemonic string, using a dictionary.

4. Compute a hash of the mnemonic string (utf8 encoded).

5. Repeat steps 2, 3 and 4 until the k first bits of the hash are equal to the 
target defined in 1.

6. Use the final hash as input for bip32 (as the master seed)

This means that we mine for the seed, until the desired metadata is obtained 
in the hash. This mining also adds a bit of difficulty to the process of 
finding a seed (on average, it will require 2^k iterations). The entropy of the 
final hash is n, the number of unconstrained bits.

This solution makes it possible for developers to define new dictionaries, 
localized or adapted to a particular need. 
The resulting mnemonics will always be usable with other clients, even if they 
do not know the dictionary. 

I am willing to write a new BIP where this proposal is specified in detail.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP22/getmemorypool

2012-06-11 Thread thomasV1

 discussion back here.  The executive summary:  Pieter and I feel like
 BIP 22 is overly complicated, and would like it to be simpler. I'd
 especially like to hear what people think will be the will be used by
 lots of pool customers features and what are the will be used by
 less than 5% of pool customers features.
 

will be used by Electrum servers 

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 21 (modification BIP 20)

2012-01-30 Thread thomasV1

 Regarding the idea of a signed URI, it is appealing, however, it may not
 work. If I understand it correctly, the main idea appears to be to protect
 a URI from malicious replacement 

No. The main idea is to protect the consumer against a malicious seller 
pretending that he has not been paid. Please read the forum.

 If a Bitcoin URI is served up from a
 trusted source (e.g. a merchant site over HTTPS) then there is no need for
 signing. It should be assumed that the merchant will offer a clean room
 payment area so that no untrusted JavaScript will creep into the final
 page
 and wreak havoc.
 
 It would seem that in any situation where the attacker has complete
 control
 over the content of the URI they will be able to successfully swab it to
 match their own fraudulent address. Imagine attempting to protect a QR
 code
 posted against a pole attempting to get BTC donations for a charity. How
 long before that was replaced by a different version operated by the
 thieves with good signatures all round?
 
 Of course, I may have misunderstood so I would welcome further discussion.

The bitcoin address that is used to sign URIs will establish the online 
reputation of the merchant. If a merchant has received a payment and pretends 
not to have received it, the signed URI will prove him wrong. 

In principle it would be possible to use HTTPS signatures for that purpose, but 
this is not really the way HTTPS is supposed to work, and it has disadvantages:
- HTTPS is not always available; there are other communication channels.
- A website, even a single page, may contain URIs posted by various merchants; 
we need to distinguish the identity of the merchant from the identity of the 
website.
- with signed URIs, a Bitcoin client can easily keep track of the signatures 
for all the payments it made. if we used the HTTPS signature of the webpage as 
receipts, then users would need to save them manually. To my knowledge, nobody 
does that.



 One field that the MultiBit team would like to add to the BIP 21 proposal
 is expires which would contain an ISO8601 formatted date/time in UTC
 (e.g. 2000-01-01T23:59:59Z). This would allow merchants to issue Bitcoin
 URIs that would expose them to a currency/inventory risk for a defined
 period of time.

yes, that too. see my proposal here: 
https://bitcointalk.org/index.php?topic=60828.0;topicseen

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development