Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.175 as permitted sender)
	client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com;
	helo=mail-we0-f175.google.com; 
Received-SPF: pass (google.com: domain of gavinandresen@gmail.com designates
	10.180.102.35 as permitted sender) client-ip=10.180.102.35; 
MIME-Version: 1.0
In-Reply-To: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com>
References: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com>
Date: Mon, 20 Feb 2012 12:17:07 -0500
Message-ID: <CABsx9T0hCAtJnA9YnmVAMjjSPB5W30e=cp8BX2mO--cWEzuSNQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=f46d044517f3c4fb5504b96876d2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP-13
Precedence: list

--f46d044517f3c4fb5504b96876d2
Content-Type: text/plain; charset=ISO-8859-1

RE:
> base58-encode: [one-byte network ID][20-byte hash][one-byte address
class][3-byte checksum]

How will the code distinguish between the old scheme:
[one-byte-version][20-byte-hash][4-byte-checksum]
and the new?

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:

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

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.

RE: should it be a BIP:  The BIP process is described in BIP
0001<https://en.bitcoin.it/wiki/BIP_0001#BIP_Work_Flow>,
and you're following it perfectly so far:

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

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.

-- 
--
Gavin Andresen

--f46d044517f3c4fb5504b96876d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

RE:<br>&gt; base58-encode: [one-byte network ID][20-byte hash][one-byte add=
ress class][3-byte checksum]<br><br>How will the code distinguish between t=
he old scheme:<br> [one-byte-version][20-byte-hash][4-byte-checksum]<br>
and the new?<br><br>1 in 256 old addresses will have a first-byte-of-checks=
um that matches the new address class; I guess the code would do something =
like:<br><br>a) If the 4-byte checksum matches, then assume it is a singles=
ig address (1 in 2^32 multisig addresses will incorrectly match)<br>
b) If the one-byte-address-class and 3-byte checksum match, then it is a va=
lid p2sh<br>c) Otherwise, invalid address<br><br>The 1 in 2^32 multisig add=
resses also being valid singlesig addresses makes me think this scheme won&=
#39;t work-- an attacker willing to generate 8 billion or so ECDSA keys cou=
ld generate a single/multisig collision. =A0I&#39;m not sure how that could=
 be leveraged to their advantage, but I bet they&#39;d find a way.<br>
<br>RE: should it be a BIP: =A0The BIP process <a href=3D"https://en.bitcoi=
n.it/wiki/BIP_0001#BIP_Work_Flow">is described in BIP 0001</a>, and you&#39=
;re following it perfectly so far:<div><br></div><div>1) Post a rough draft=
 of the idea here to see if there&#39;s any chance it&#39;ll be adopted</di=
v>
<div>2) Assuming a positive response and no major flaws: write up a draft B=
IP</div><div>3) Post the draft BIP here, where it can be picked apart.</div=
><div>4) Assuming no major flaws, ask the BIP editor (Amir) for a BIP numbe=
r</div>
<div><br></div><div>I&#39;d also encourage you to actually implement your i=
dea 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 f=
law.<br>
<br>-- <br>--<br>Gavin Andresen<br></div>

--f46d044517f3c4fb5504b96876d2--