BitCoin Parameters

[Red]

There are certain constants in BitCoin that could have initially been set to any arbitrary value without conceptual changes to the network. I'm NOT contesting any of these parameter choices as ill conceived. However, there are a lot of curious numbers used in BitCoin and I have no idea why.

I think it would be interesting to document why these choices were made as they seem to be at the heart of many questions that get posted to this forum.

I'll start the list with the parameters I can think of off the top of my head. Please feel free to add to the list.

----------------------------

21,000,000 BTC - Why 21 million and not 10, 16, 20, 25, 32. Just seems like a very particular number that is not divisible by 10 or an obvious power of 2.

2016 - Why does the difficulty adjust every 2016 blocks? Why not 2000, or 2048?

2 weeks - Why does the block adjustment map to a two week period? Why not every week or everyday?

10 minutes - Why do we want to generate a block every 10 minutes? Did this drive the above choices or is it a result of them?



50 BTC - Why a 50 BTC reward for generating a block? Why not 100?  Or Why not a relative value like 0.X BTC for each BTC transaction in a block or even X% of the existing coin base?

4 years - Why does the block reward reset every 4 years? Why not every year or every 5 years? Why does it decrease at all?

1/2 - Why does the block reward diminish by half each time? Why not decrease by 1 or 5 coins?

"Golden years" - Why choose to give out half of all bitcoins to whomever happens to show up in the first 4 years? Why not give out 10% or 100%? Did this drive the above or is it the result of the above?


BitCoin Addresses - Why use the hash of a hash (good idea!) for an address, rather than simply using the full public key.

Certificates - Why not store public keys as part of standard 509 certificates, or in PGP format, The same for private keys.

Time stamps - How do we calculate when in UTC a transaction actually took place? When it was issued from the client, or when confirmed in a block list? Is there a shared consensus on BitCoin standard time?

(Everyone, add what you can think of. Answer what you know.)

[lachesis]

I'll answer the ones I can

2016 - Why does the difficulty adjust every 2016 blocks? Why not 2000, or 2048?

This is 2 weeks * 10 minutes / block.

2 weeks - Why does the block adjustment map to a two week period? Why not every week or everyday?

I think daily adjustments would be / have been better. Two weeks seems a bit arbitrary to me, and I see no disadvantages to making it happen more often. There isn't a low latency attack, since difficulty adjustments are tied to blocks and you can't successfully generate coins without the newest block.

10 minutes - Why do we want to generate a block every 10 minutes? Did this drive the above choices or is it a result of them?

I understand the trade off here; we're balancing speed of transaction confirmation with bandwidth usage and the risk of low latency advantage. If blocks were generated every 10 seconds, then people with a faster internet connection would have an advantage, which is against Satoshi's goal. However, if they were generated every hour, it would take at least an hour to confirm a transaction.

BitCoin Addresses - Why use the hash of a hash (good idea!) for an address, rather than simply using the full public key.

Addr = RIPEMD160( SHA256( public_key ) )
This makes addresses 160 bits long (shorter = better for usability) but also ensures that the input to the RIPEMD160 is an unpatterned 256-bit number (assuming there are no flaws in SHA256).

Certificates - Why not store public keys as part of standard 509 certificates, or in PGP format, The same for private keys.

I dunno - that's a good idea. I think there's a real advantage to being able to trade the keys independently of the Bitcoin network.

[Red]

Thanks! those are great answers!

I guess I slipped a couple of "design decision" questions into a list I intended to be purely about parameter settings.

Bitcoin addresses vs full public keys/certs
Certificates vs a key wallet

But if we add to the design decision list, I'm also interested in:

Coins - why the decision to not serialize them or otherwise uniquely identify individual coins? (This misconception seems to come up repeatedly)
Accounts - why the decision not to keep a running balance by bitcoin address in the block list.

I think I understand why, but if there was a FAQ, those two would probably belong in it somewhere.

[lachesis]

Coins - why the decision to not serialize them or otherwise uniquely identify individual coins? (This misconception seems to come up repeatedly)

Well, from the software's point of view, each 1.00BTC is actually 100,000,000 units. If you think the block list is big now, imagine how bad it would be if it were tracking 355,300,000,000,000 individual units!

Accounts - why the decision not to keep a running balance by bitcoin address in the block list.

It's redundant data. It would help clients to verify transactions without having to (worst-case) verify the entire block chain, but it would also take up space in the block list.

[Red]

Thanks lachesis!

That is what I concluded from reading the code. It makes perfect sense when you dig down to the details. It wasn't what I was expecting though from a system called bitcoin. Was kind of expecting objects representing coins which were somehow encrypted, signed and passed around between parties.


As a side note, can you imagine writing the FAQ for BitCoin for a new generation 20 years from now?  I mean far enough in the future that we have begun to cull the beginning of the block list.

Q: "How do I know that the bitcoins you are giving to me really exist?"
A: "Because the guy that gave them to me believed they existed! And the guy that gave them to him..."

It's really going to sound like the old joke that ends with, "You don't get it. It's turtles all the way down!"