BIP-13
8 messages, 20 to 22 Feb 2012. Started by Michael Gronager.
Michael Gronager (4), Luke Dashjr (2), Gavin Andresen (2)
Just posted this on the wiki BIP-13 discussion - should I make it into a BIP of its own ?
--- The "version" portion of the address has so far been labeled "network id", and indicates from which network and which chain the address can be used for. I think that this change from network id to version is much more fundamental and should not just be squeezed in along with bip16/17. The right way to do this is to structure the bitcoin address into:
base58-encode: [one-byte network ID][20-byte hash][one-byte address class][3-byte checksum]
This will move the possibility of using a faulty address from 1 to 4bill to 1 to 24mio. Recall that for most other payment systems this checksum is 1 to 9! So it should be sufficient. An old client will then render the new addresses as useless and they will still maintain their old familiar 1xxx look - the whole point in multisig is that it should not be a matter of the paying party to worry about securing wallet of the receiver, hence he should not be bothered with a new "3" kind of address now... --Michael Gronager/libcoin 10:49, 20 February 2012 (GMT)
On Monday, February 20, 2012 6:17:01 AM Michael Grønager wrote:
Quoted text (2 lines)
> Just posted this on the wiki BIP-13 discussion - should I make it into a > BIP of its own ?
If you must. However, BIP 13 has been pretty much undisputed, and only held back by BIP 16/17 so far...
Quoted text (3 lines)
> The "version" portion of the address has so far been labeled "network id", > and indicates from which network and which chain the address can be used > for.
Where do you see this? It has always been "version" as far as I am aware, and we discussed formalizing the details of the bits in it a few months back. In any case, it was certainly originally intended as "version" as can be observed in Satoshi's reference implementation.
Quoted text (9 lines)
> >> The "version" portion of the address has so far been labeled "network id", >> and indicates from which network and which chain the address can be used >> for. > > Where do you see this? It has always been "version" as far as I am aware, and > we discussed formalizing the details of the bits in it a few months back. > In any case, it was certainly originally intended as "version" as can be > observed in Satoshi's reference implementation.
See: https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
And the attached graphics - here it is defined as network byte and network id.
Anyway - can probably live with some bit level subdivision into network id and address class.
/M
RE:
Quoted text (1 line)
> 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.
Quoted text (9 lines)
> 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
Exactly!
Quoted text (2 lines)
> > 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.
Nope - its almost like calling the version:0+5 possible collision with new evil, say "ponzicoin" with version=5 a possible flaw that could be exploited... And you can already create non-existing addresses with a matching checksum...
Quoted text (1 line)
> 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.
I will rest my case, not due to the "flaw", but I got some info on the bitfields of the "version" (thanks Luke!) - this makes the +5 less arbitrary, however, I don't think the bitfield interpretation is that well known, so there might already be "version"-collisions...:
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)
y = 0/1 depending on aesthetics (I guess to force the address to be either 1 or 3).
This also opens up for extensions - (if xx10xxxx or xxxx111x) the next byte will be part of the version.
/M
Quoted text (4 lines)
> > -- > -- > Gavin Andresen
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 = 0, (00000000)
SCRIPT_ADDRESS = 5, (00000101)
PUBKEY_ADDRESS_TEST = 111, (01101111) !!!
SCRIPT_ADDRESS_TEST = 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:
Quoted text (27 lines)
> 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, 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
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/
Quoted text (14 lines)
> > However, the definitions en base58.h are: > > PUBKEY_ADDRESS = 0, (00000000) > SCRIPT_ADDRESS = 5, (00000101) > PUBKEY_ADDRESS_TEST = 111, (01101111) !!! > SCRIPT_ADDRESS_TEST = 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. >
PUBKEY_ADDRESS_TEST is/was supposed to change (the logic for it being 111 was "eleven is Gavin's favorite number"), but I have higher priority things to do than make all the necessary code changes to upgrade testnet wallets (unfortunately the address:account mappings in the wallet store the address base58-encoded) and the testnet faucet and get theymos to change the blockexplorer.com/testnet site to change the version number and publicize the change so anybody else who has created testnet infrastructure changes.
If you'd like to spearhead that effort, be my guest, but it is not as trivial as just changing the definition.
Luke can explain why SCRIPT_ADDRESS_TEST is 196, my memory is fuzzy about that (it always decodes to the same digit in base58 maye?)
On Wednesday, February 22, 2012 11:29:59 AM Michael Grønager wrote:
Quoted text (4 lines)
> SCRIPT_ADDRESS_TEST = 196, (11000100) !!! > 11xxxxxx - test network > xx00xxxx - bitcoin > xxxx010y - p2sh
This fits...
Quoted text (1 line)
> PUBKEY_ADDRESS_TEST = 111, (01101111) !!!
What Gavin said.