Re: [Bitcoin-development] BIP-13
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: 00xx - main network 01xx - reserved 10xx - reserved 11xx - test network Network: xx00 - bitcoin xx01 - reserved xx10 - OTHER (next octet) xx11 - Namecoin Network specific: 000y - PubKeyHash 001y - reserved 010y - p2sh 011y - public key (raw) 100y - signature 101y - reserved 110y - private key (raw) 111y - OTHER (next octet) However, the definitions en base58.h are: PUBKEY_ADDRESS = 0, () SCRIPT_ADDRESS = 5, (0101) PUBKEY_ADDRESS_TEST = 111, (0110) !!! SCRIPT_ADDRESS_TEST = 196, (11000100) !!! [as a side note litecoin is 48 (0011) 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: grona...@ceptacle.com Web: http://www.ceptacle.com/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP-13
However, the definitions en base58.h are: PUBKEY_ADDRESS = 0, () SCRIPT_ADDRESS = 5, (0101) PUBKEY_ADDRESS_TEST = 111, (0110) !!! SCRIPT_ADDRESS_TEST = 196, (11000100) !!! [as a side note litecoin is 48 (0011) 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 -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP-13
On Wednesday, February 22, 2012 11:29:59 AM Michael Grønager wrote: SCRIPT_ADDRESS_TEST = 196, (11000100) !!! 11xx - test network xx00 - bitcoin 010y - p2sh This fits... PUBKEY_ADDRESS_TEST = 111, (0110) !!! What Gavin said. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP-13
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) -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP-13
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 0001https://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 -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
