[Bitcoin-development] Where to have discussions...
On Wed, Feb 22, 2012 at 11:29 AM, Michael Grønager wrote: > 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... I've been trying to move discussions to this mailing list, by starting conversations here and posting links to the mailing list archives in the discussion forums just so people know there is a conversation going on. IRC conversations are great for rapid back-and-forth brainstorming, so I expect a lot of work to continue getting done via IRC, but once there's general consensus there I expect issues to migrate here. -- -- 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
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
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