Bitcoin Forum

Here are some magic numbers in bitcoin protocol. Do I miss any?

• Average block interval: 10 minutes. Reason: long enough for network convergence, short enough for practical use
• Difficulty adjustment: 2016 blocks, ~2 weeks. Reason: long enough to avoid manipulation of difficulty, short enough to adjust in case of hashing power loss
• Reward halve: 210000 blocks, ~4 years. Reason: To limit total amount of bitcoin. But why 4 years and why decrease by 50%?
• Initial reward: 50BTC. Reason: ? (if I were Satoshi, I would start with a power of 2, like 2^32 satoshi = 42.94967296 BTC, to avoid loss of reward in latter years)
• Bitcoin divisibility: 8 decimal places. Reason: more than enough even bitcoin becomes the only currency in the world.
• Block size: 1MB. Reason: anti-DOS, limited block size for higher transaction fee. (But I don't think this is the optimal number for long term)
• Max script size: 10000bytes. Why need a limit on top of block size? Why 10000?
• Max pushed size: 520bytes. Why need a limit on top of max script size? Why 520?
• Max 'expensive' OP codes in script: 201. Why 201 but not 200 or something else?
• Max sig check in OP_CHECKMULTISIG: 20. Reason: Anti-DOS.
• Max sig check in a block: 20000. Reason: Anti-DOS.
• Max stake elements: 1000. Reason: Anti-DOS. Why 1000?

I think there is a new magic number related to the May 2013 hard-fork.

I guess you forgot the actual magic number: {0xF9,0xBE,0xB4,0xD9}

You ask why such numbers were chosen here and there - valid questions.
But take your car, for example. Get it to the guy who engineered it and start asking him why he chose this screw to have such a shape, why the wheels are in such a size, or why such a type of brakes, not like they have in that other car...?
I guess you could think of thousands of question to annoy a guy who once engineered your car.
But you don't really want to do it, do you? Because it servers no purpose.

Maximum increase in difficulty over 2016 blocks: 4-fold (e.g. from 100 to 400)
Maximum decrease in difficulty over 2016 blocks: 1/4th (e.g. from 100 to 25)

About 8 decimal places:
My guess is that it allows to have microBTC with still 2 places after the decimal seperator (microBTC-cents), these 1/100th of a currency unit are historically quite widely used and just from thinking about it, 21 million "coins" would have to be split eventually if Bitcoin gained any traction.

A lot of these numbers probably just evolved from "gut feeling" and maybe sometimes necessity or easier computability (e.g. why are SHA256 hashes 256 bits long and there's no SHA254? Because 256 bits are a power of 2 and are easier to handle by computers). To stay with piotr's example: If you just have phillips screws lying around, you're probably just going to use these, if you have torx screws, maybe you're more likely to use them. Also if you have the feeling that it might be more aesthetic or useful to have a better headlight, you might make it a bit brighter, but won't be really able to explain with very detailled arguments why now a headlight with 100 watts and not 95 watts...

While 8 decimal places could be considered a magic number, it is one we may expand later, without impacting the total money supply.

Depending on the implementation it might get hard to do so though, arbitrary precision for example would be awesome (miners then would just ignore transactions below a certain individual dust value) but as far as I understand it, currently "bitcoins" are defined as 10^8 atomic units ("Satoshis"), adding more than 3 places might become quite hard (21 million * 10^8 Satoshis * 10000 > 64 bit number), though as any change like this would anyways require a hard fork, that would be a long planned change anyways.

Nearly all of these values CAN be changed, the question is rather if they WILL be changed or SHOULD be changed. Some should but likely never will, some should and will and according to some people there will be some values changed that shouldn't be changed (just look at the max_block_size threads...).

Relaxing any of these values are hardforks

I'm particularly interested in the following numbers:

Max script size: 10000bytes.
Why do we need a script size limit on top of block size limit? Miners already have the power to put anything data in a block, as long as the total size is below 1MB. I can't see the reason to limit individual script size. (Interestingly, we don't have a hard max tx size, so a transaction could be as large as 1MB - block header size)

Max pushed size: 520bytes.
Again, why do we need this limit on top of script size limit and block size limit? This also effectively obsoletes OP_PUSHDATA4 because people will never need to use it. And why 520, instead of 512 or 500?

Max 'expensive' OP codes in script: 201.
Why 201 but not 200?

max tx size is 100kb, not 10000 - and why would any sane person need more?
even 4kb seems too much.
there are no economically justified reasons to complicate the protocol allowing a 100GB transactions or a TB blocks.
why would anyone even whant that?

there is no hard max tx size. The 100kb is just a soft limit like the 5430 satoshi policy

so what?
it works like it does - if you would like to improve something, I guess there are better ways than just complaining about arbitrary numbers

One day people will infer all sorts of things from these numbers. I know people who study religion do this. There is 786 in Islam for example and Christians consider 666 to be synonymous with the devil. Stuff like that.

Anyway I think some of these numbers could be changed in the future as the OP also points out.

This highlights an issue with "code as documentation".  It fails to distinguish between implementation decisions that were arbitrary and those implementation choices that are crucial for correctness.

Someone writing a new bitcoin implementation could focus their energy on what is important to get right vs. something that "just happened" to be done that way and could have been done otherwise to no ill effect.

I'm aware of the argument that reimplementations must match the Satoshi client bug for bug in order to prevent a divergence of consensus, and that such divergence can carry a high economic price.  However, unless the reasons for any given behavior are written down, as the original developers move on, this tribal knowledge gets lost.  It is replaced by the guesswork of future developers.

The consensus of the development team seems to be that even if a well-written protocol specification were completed, they would not feel bound to consider it authoritative.

So be it.  But as bitcoin implementations need to go beyond traditional "software on PC" (think POS terminals, embedded systems, smartcards, dedicated silicon nodes, etc.), without a specification to test against, it is very difficult to assure quality and correctness.