Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1S0F55-00088S-LG for bitcoin-development@lists.sourceforge.net; Wed, 22 Feb 2012 16:30:15 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49] helo=mail.ceptacle.com) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1S0F51-0003a5-0c for bitcoin-development@lists.sourceforge.net; Wed, 22 Feb 2012 16:30:15 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 445A717C2154; Wed, 22 Feb 2012 17:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+Nwn9XnTgoT; Wed, 22 Feb 2012 17:29:59 +0100 (CET) Received: from [10.0.1.28] (2508ds5-oebr.0.fullrate.dk [95.166.54.49]) by mail.ceptacle.com (Postfix) with ESMTPSA id E229417C2143; Wed, 22 Feb 2012 17:29:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Wed, 22 Feb 2012 17:29:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com> To: Gavin Andresen X-Mailer: Apple Mail (2.1257) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1S0F51-0003a5-0c Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP-13 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: Wed, 22 Feb 2012 16:30:15 -0000 Hi Gavin / Luke, BIP-13 again... I started to implement a bitfield based parsing of the = version byte using the description I got from Luke, but I then = discovered that it does not hold: Network class: 00xxxxxx - main network 01xxxxxx - reserved 10xxxxxx - reserved 11xxxxxx - test network Network: xx00xxxx - bitcoin xx01xxxx - reserved xx10xxxx - OTHER (next octet) xx11xxxx - Namecoin Network specific: xxxx000y - PubKeyHash xxxx001y - reserved xxxx010y - p2sh xxxx011y - public key (raw) xxxx100y - signature xxxx101y - reserved xxxx110y - private key (raw) xxxx111y - OTHER (next octet) However, the definitions en base58.h are: PUBKEY_ADDRESS =3D 0, (00000000) SCRIPT_ADDRESS =3D 5, (00000101) PUBKEY_ADDRESS_TEST =3D 111, (01101111) !!! SCRIPT_ADDRESS_TEST =3D 196, (11000100) !!! [as a side note litecoin is 48 (00110000) and namecoin is 52 (00110100)] So there is no logic ?? I have searched the mailing list and the forum = for discussions on this but found it hard to find any. If I overlooked = something please direct me. Cheers, M PS: I have said so before, but it would *really* be nice if discussions = / conclusions / irc-summaries were taking place at one place - e.g. at = the bitcoin-dev mailing list, not at 5-10 different threads in = bitcointalk or in bip notes or solely on IRC... On 20/02/2012, at 18:17, Gavin Andresen wrote: > RE: > > base58-encode: [one-byte network ID][20-byte hash][one-byte address = class][3-byte checksum] >=20 > How will the code distinguish between the old scheme: > [one-byte-version][20-byte-hash][4-byte-checksum] > and the new? >=20 > 1 in 256 old addresses will have a first-byte-of-checksum that matches = the new address class; I guess the code would do something like: >=20 > a) If the 4-byte checksum matches, then assume it is a singlesig = address (1 in 2^32 multisig addresses will incorrectly match) > b) If the one-byte-address-class and 3-byte checksum match, then it is = a valid p2sh > c) Otherwise, invalid address >=20 > The 1 in 2^32 multisig addresses also being valid singlesig addresses = makes me think this scheme won't work-- an attacker willing to generate = 8 billion or so ECDSA keys could generate a single/multisig collision. = I'm not sure how that could be leveraged to their advantage, but I bet = they'd find a way. >=20 > RE: should it be a BIP: The BIP process is described in BIP 0001, and = you're following it perfectly so far: >=20 > 1) Post a rough draft of the idea here to see if there's any chance = it'll be adopted > 2) Assuming a positive response and no major flaws: write up a draft = BIP > 3) Post the draft BIP here, where it can be picked apart. > 4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP number >=20 > I'd also encourage you to actually implement your idea between steps 3 = and 4. But in this particular case, I think an attacker being able to = create singlesig/p2sh address collisions counts as a major flaw. >=20 > --=20 > -- > Gavin Andresen Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: gronager@ceptacle.com Web: http://www.ceptacle.com/