Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTApD-0005RF-M0 for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 13:58:31 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of fastmail.co.uk designates 66.111.4.28 as permitted sender) client-ip=66.111.4.28; envelope-from=jim618@fastmail.co.uk; helo=out4-smtp.messagingengine.com; Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WTApB-0005Iz-4b for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 13:58:31 +0000 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C4D3521021 for ; Thu, 27 Mar 2014 09:58:19 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute2.internal (MEProxy); Thu, 27 Mar 2014 09:58:19 -0400 Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id A1675115A16; Thu, 27 Mar 2014 09:58:19 -0400 (EDT) Message-Id: <1395928699.5369.99593201.1CFF9238@webmail.messagingengine.com> X-Sasl-Enc: pcyhd+Vw9Ls2jtGaREc5zwlomMeOXbvBQHqAwrqKNM97 1395928699 From: Jim To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - ajax-8832fc58 In-Reply-To: <53342C6C.2060006@gmx.de> References: <53340999.807@gmx.de> <5334144A.9040600@gmx.de> <53342C6C.2060006@gmx.de> Date: Thu, 27 Mar 2014 13:58:19 +0000 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (jim618[at]fastmail.co.uk) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (jim618[at]fastmail.co.uk) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WTApB-0005Iz-4b Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:58:31 -0000 Good to hear the bip32 wallet structure is _so_ close to being standardised. For MultiBit HD, we have put in support for 12/18/24 words but have the UI = 'suggest' to use 12. You can see this on the wallet creation wizard Gary recently blogged about: https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html There's a little combo for the seed length, with 12 as the default. @Thomas. You mention gaps. We are creating new addresses on the UI in a pan= el marked 'Request' where the user also types in a QR code label and a note= to themselves. This gets stored away as a first class 'PaymentRequest'. Th= e UI 'suggests' that each address is used once. There will be some gaps (wh= ere the payment request is never paid) but we aren't bulk creating addresse= s. I am hoping this shouldn't cause Electrum a problem. We are also storing a timestamp (the number of days since the genesis block= ) to help wallet restore but that is SPV specific. On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote: >=20 >=20 > Le 27/03/2014 13:49, Mike Hearn a =E9crit : IP32 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 making the > > seeds harder to write down on paper. So should this be a degree of free= dom? > > >=20 >=20 > Here is what I understand: >=20 > 2^128 iterations is not brute forcable today, and will not be for the=20 > foreseeable future. >=20 > An EC pubkey of length n can be forced in approximately 2^(n/2)=20 > iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which= =20 > are 256 bits, would require 2^128 iterations. This is why unused=20 > addresses (160 bits hash) are better protected than already used ones. >=20 > However, people tend to believe that a public key of size n requires 2^n= =20 > iterations. This belief might have been spread by this popular image: > https://bitcointalk.org/index.php?topic=3D508880.msg5616146#msg5616146 >=20 >=20 > -------------------------------------------------------------------------= ----- > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --=20 http://bitcoin-solutions.co.uk