Topic: Historical question: (Read 2754 times)

Classic Freudian slip!

http://en.wikipedia.org/wiki/Freudian_slip

Dunno if anyone other than me noticed it (I was once a floating point nut; I contributed the compile-time host- and target-independent FP arithmetic that is in the Clang compiler) but the current usage of 21* 10^6 * 10^8 satoshis means that integer arithmetic in satoshi units (2100000000000000 of them) can be done perfectly within the pure integer part of a double-precision point number.  They have 52 explicit bits, 4503599627370496 possibilities, i.e. double-precision values can be used to do bitcoin arithmetic without fear of loss of precision, bigint or long long integer arithmetic is unnecessary.  Coincidence?  Who knows.

What was wrong was the assumption of this statement:

Should be... probably.
Are... certainly not today.

Wrong? I did not state anything about this. I ask you why you considered cash only, or better what you called cash? It looks more you don't know what I talk/think about. And thus set money = cash.

Regards
smtp

Image to go to a business bank in 50 years and asking for a credit. The bank offers you say 10 BTC.
Will you ask: do I get this as cash? :-)
Or if they offer you a 10 MBTC credit -- you are a well-known big-business man and you know that there (will) exists only 21 MBTC world-wide and it is almost the only used currency of importance -- what will you think then?

smtp

Wrong. Liabilities are certainly magnitudes higher than cash (M0).

http://en.wikipedia.org/wiki/Money_supply

A serious and more non-future aimed thought would e.g. result in:
start with say 2^16/1000 BTC half this every 210000 (or what ever fixed number) of blocks -- better choose the time interval 4 years and a certain distant of 10 mins for a new block, do this for 16*4 = 64 years, then we are at 1 mBTC and then hold this constant for ever! So you have a small linear growth in BTC total.  Then we need no (new/very artifically and arbitrary changable rules for) transaction-fees!

But we should retalk this topic in nearly 64-4 years!

smtp

The ugly thing is either 10 is no power of 2 or humans are not comfortable to think intuitively in powers of 2! ;-)

smtp

? What do you call cash? I tried to estimate official existing nominal money amount. And liabilities should be (far) less than existing money world-wide!

smtp

What would happen when the subsidy was 1 BTC? Half of that is 0.5 BTC and further dividing that by 2 doesn't lead to ... 2 satoshi, 1 satoshi, 0. For that to happen, the subsidy would need to start at 2^n/1e8 BTC, which at n=32 would be 42.94967296 BTC, which is as nerdy as ugly.

Bitcoin is cash not liabilities. The magnitude of cash floating around is much less than you calculate.

My two cents:
Currently the US-government has liabilities of a bit more than 15*10^12 $, say roughly 10^13 $.
Taken all of the other liabilities world wide, I guess their sum is limited by $ 10^14.
Moreover I believe all sums of every money availible (converted to US-$ units) is < 10^15 $ at every past point of time.
So if you like to be precise on the level of 0.01 US-cent, you need an integer range up to 10^19.
Hmm ... 2^64 = 1.84...*10^9. Wow, critical close if everybody would use BTC for his business! ;-)
smtp

I'm not talking about the protocol, I'm talking about accounting systems that also use 64 bit computers, and thus typically use 64 bit values.  You don't design an accounting package based on the money supply, you give it headroom.

Right now, bitcoins are worth about $13.50 each, and there will never be more than 21 million of them.  If we were using a scaling factor such that the entire 64 bit range was needed to exactly represent the fundamental units, we would need a 128-bit accounting package to deal with projects bigger than, say, a medium-sized office buildings.

That example is just a snapshot, of course.  In the past, 64 bits wasn't enough to feed a family of four, but in the future, it may very well be able to handle all global economic activity for a year.  The point is that having some room between the maximum number of currency units, and the maximum range of the native register size of common CPUs isn't a bad thing.

I'm talking about the largest exact integer in decimal64. Doing inexact math using decimal64 is nice because rational values stay rational.  I was also talking about having headroom for exact fixed point calculations, because while the discrepancy from rounding my be small, sum and difference not adding up _exactly_ (something which happens with any rounding mode you choose) or just getting different results depending on the rounding mode makes error checking hard and can permit subtle errors that slip trough. Not the end of the world, but there are qualities to the value we have.

I would pick: Merkle for hashing and the tree, Zimmermann for PGP, Bernstein for his fight against restrictions on cryptography.

My point is that any such "headroom" would be unecessary and even using that headroom wouldn't be any more precise than simply making the protocol as precise as 64bit allows to begin with.

64bit allows 2^64 values.  So the minimium unit that can be represented is 1(2^64) of the "whole" (in this case 21M BTC).   You can't be more precise using 64bit integer.  So the idea that it would be better to make the protocol less precise in order to have headroom to allow greater precision up to (but not greater than the max 64bit allows is kinda silly .... if the protocol used the full range it would already be as precise as 64bit allows.   There would be no headroom but no headroom is possible regardless (without larger bit range).

64bit allows precision down to 11th digit (due to the 21M base units).   It doesn't matter how precise the protocol is you can't be more precise using 64bit integers off protocol.

So
1 satoshi = 1E-4  -> on protocol precision 4 digits -> off protocol precision 11 digits
1 satoshi = 1E-5  -> on protocol precision 5 digits -> off protocol precision 11 digits
1 satoshi = 1E-6  -> on protocol precision 6 digits -> off protocol precision 11 digits
1 satoshi = 1E-7  -> on protocol precision 7 digits -> off protocol precision 11 digits
1 satoshi = 1E-8  -> on protocol precision 8 digits -> off protocol precision 11 digits
1 satoshi = 1E-9  -> on protocol precision 9 digits -> off protocol precision 11 digits
1 satoshi = 1E-10  -> on protocol precision 10 digits -> off protocol precision 11 digits
1 satoshi = 1E-11  -> on protocol precision 11 digits -> off protocol precision 11 digits

Your saying yeah 1E-6 is great because we have 5 more digits of headroom off protocol.  I am saying 1E-11 is great because the protocol is as precise as possible (for 64bit).  We don't lose any precision because we don't have headroom.  We are still just as precise off protocol.

No, see headroom is the difference between the size of the register and the maximum number of fundamental units.  That's a definition.  If you have 2^64 units, and you use a 64 bit register to count them, then you either have no headroom, or you aren't exact.  (You can use a scaled format, but that just means that you have either headroom or exactness at any given step, but never both at the same time.)

I'm talking about accounting, and we generally don't limit our accounting systems to according to our money supply.  The notion of expanding the money supply is a different matter entirely.  We may expand to a 128-bit format in the future, and I'm strongly suspect that we will do so for aesthetic reasons (as in, "we have 128-bit registers, why are we still hauling these half-words around?") long before the fundamental unit becomes economically meaningful.  When we do that, if we do that, we will probably pick a scaling factor that provides even more than 12 or 13 bits of headroom at that time.

We named the smallest unit satoshi, and have BTC for 100,000,000 satoshis.

What about naming every second
magnitude inbetween honoring big chrypographers?

We would have three slots to fill.

Um the headroom would already exist if the bits were already used.

i.e.

use 64bits now = ~18,400 quadrillion units
vs
use 51 bits now = 2.1 quadrillion units expandable to ~18,400 quadrilion units if things take off.  


No it isn't.  The largest round unit would be 18,000 quadrillion.  Using 12 digits for precision that would make 1 satoshi = 1 nBTC (1E-12), total coinsupply = 18,000,000 BTC.

As far as losing precision?  On a 12 digit fixed precision format?   If the entire global money supply was represented by the 18M/12digit BTC (~$100T USD circa 2012) then 1 BTC = ~$5.6M.  Min precision would be ~1/2000th of 1 US cent.


Still it is nothing to lose sleep over just seem ineligent given how well thought out the rest of the protocol was.

I don't. the number used is the largest round number reward times the geometric decline amount that fits into a Decimal64.  There are other reasons to not use the full range of a signed 64 bit integer: if you do, there is no room to square a value without losing precision, which is very handy in doing prorated values without switching to infinite precision rational arithmetic.