Quote from: bitmover on June 23, 2022, 09:35:56 PM

Quote from: franky1 on June 19, 2022, 02:05:20 AM

he didnt choose 21m btc and then calculate backwards that over X years backwards means the base genesis has to release 50btc

I also agree with this, and it makes sense compared to the email posted above.

logic and common sense of decisions plays out as

wanting a currency that deflats(halfs its release amount every so often but not too quick to cause chaos and also not run out of coins once hitting total supply too quick

he chose 33bits where removing one bit off the end per sesion halves the amount of units it converts to in normal human readable numbers meaning 33 halving events.

then the next logic was the halviing events should be not weekly or monthly or yearly but ~4 yearly so that after 33 sessions it means it would take over 130years to get to total supply cut off

he then seen the binary conversion to of 33bits was a large number of units
8589934591 which seemed a huge number of units to offer. so decided on the decimal of 8 (/100,000,000)
85.89934591
but seen that the halving would cause issues right from the start of halving a 1 and next session halving a 9. where by some value is lost immediacy by by rounding
so decided a more even number to start so chose the 50btc as a nice number

by which point if working out that if he done the halving at 210k block intervals =21m coins.

it was then he decided how fast that would be by realising 210k intervals if 4 years was the goal per interval
would mean 52.5k per year, 2019.27 a fortnight (bad decimal amount(cant have .27 of a block))

so he then put in the 2 week adjustment(difficulty formula) to try to keep it to a nicer round number of 2016 blocks a fortnight, which then calculated down to a block ~10mins which seemed a reasonable amount of hard work time to create a block and send it around a network without causing issues with data broadcast delays between peers