bitcoin protocol magic numbers and reason

Johnathan

newbie

Activity: 39

Merit: 0

Quote from: Abdussamad on July 28, 2013, 01:57:40 PM

One day people will infer all sorts of things from these numbers.

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.

Abdussamad

legendary

Activity: 3710

Merit: 1586

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.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: jl2012 on July 28, 2013, 12:20:04 PM

Quote from: piotr_n on July 28, 2013, 12:06:35 PM

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

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: piotr_n on July 28, 2013, 12:06:35 PM

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

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

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?

jl2012

legendary

Activity: 1792

Merit: 1111

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?

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: Sukrim on July 28, 2013, 09:32:28 AM

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

Sukrim

legendary

Activity: 2618

Merit: 1007

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...).

jgarzik

legendary

Activity: 1596

Merit: 1100

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

Sukrim

legendary

Activity: 2618

Merit: 1007

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...

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

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.

jl2012

legendary

Activity: 1792

Merit: 1111

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.

Topic: bitcoin protocol magic numbers and reason (Read 3865 times)