* [Bitcoin-development] BIP-13
@ 2012-02-20 11:17 Michael Grønager
2012-02-20 14:18 ` Luke-Jr
2012-02-20 17:17 ` Gavin Andresen
0 siblings, 2 replies; 8+ messages in thread
From: Michael Grønager @ 2012-02-20 11:17 UTC (permalink / raw)
To: Bitcoin Dev
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)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-20 11:17 [Bitcoin-development] BIP-13 Michael Grønager
@ 2012-02-20 14:18 ` Luke-Jr
2012-02-20 15:47 ` Michael Grønager
2012-02-20 17:17 ` Gavin Andresen
1 sibling, 1 reply; 8+ messages in thread
From: Luke-Jr @ 2012-02-20 14:18 UTC (permalink / raw)
To: bitcoin-development
On Monday, February 20, 2012 6:17:01 AM Michael Grønager wrote:
> 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...
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-20 14:18 ` Luke-Jr
@ 2012-02-20 15:47 ` Michael Grønager
0 siblings, 0 replies; 8+ messages in thread
From: Michael Grønager @ 2012-02-20 15:47 UTC (permalink / raw)
To: Luke-Jr; +Cc: bitcoin-development
>
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-20 11:17 [Bitcoin-development] BIP-13 Michael Grønager
2012-02-20 14:18 ` Luke-Jr
@ 2012-02-20 17:17 ` Gavin Andresen
2012-02-20 21:29 ` Michael Grønager
2012-02-22 16:29 ` Michael Grønager
1 sibling, 2 replies; 8+ messages in thread
From: Gavin Andresen @ 2012-02-20 17:17 UTC (permalink / raw)
To: Michael Grønager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1776 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-20 17:17 ` Gavin Andresen
@ 2012-02-20 21:29 ` Michael Grønager
2012-02-22 16:29 ` Michael Grønager
1 sibling, 0 replies; 8+ messages in thread
From: Michael Grønager @ 2012-02-20 21:29 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
> 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!
>
> 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...
> 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
>
> --
> --
> Gavin Andresen
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-20 17:17 ` Gavin Andresen
2012-02-20 21:29 ` Michael Grønager
@ 2012-02-22 16:29 ` Michael Grønager
2012-02-22 16:40 ` Gavin Andresen
2012-02-22 16:43 ` Luke-Jr
1 sibling, 2 replies; 8+ messages in thread
From: Michael Grønager @ 2012-02-22 16:29 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
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:
> 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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-22 16:29 ` Michael Grønager
@ 2012-02-22 16:40 ` Gavin Andresen
2012-02-22 16:43 ` Luke-Jr
1 sibling, 0 replies; 8+ messages in thread
From: Gavin Andresen @ 2012-02-22 16:40 UTC (permalink / raw)
To: Michael Grønager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
>
> 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?)
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1618 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] BIP-13
2012-02-22 16:29 ` Michael Grønager
2012-02-22 16:40 ` Gavin Andresen
@ 2012-02-22 16:43 ` Luke-Jr
1 sibling, 0 replies; 8+ messages in thread
From: Luke-Jr @ 2012-02-22 16:43 UTC (permalink / raw)
To: bitcoin-development
On Wednesday, February 22, 2012 11:29:59 AM Michael Grønager wrote:
> SCRIPT_ADDRESS_TEST = 196, (11000100) !!!
> 11xxxxxx - test network
> xx00xxxx - bitcoin
> xxxx010y - p2sh
This fits...
> PUBKEY_ADDRESS_TEST = 111, (01101111) !!!
What Gavin said.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-02-22 16:44 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-20 11:17 [Bitcoin-development] BIP-13 Michael Grønager
2012-02-20 14:18 ` Luke-Jr
2012-02-20 15:47 ` Michael Grønager
2012-02-20 17:17 ` Gavin Andresen
2012-02-20 21:29 ` Michael Grønager
2012-02-22 16:29 ` Michael Grønager
2012-02-22 16:40 ` Gavin Andresen
2012-02-22 16:43 ` Luke-Jr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox