Bitcoin Recapitulation

Monday, 15 July, Year 11 d.Tr. | Author: Mircea Popescu

To start off in style, let's revisit, explicitly, an important matter obliquely mentioned by yours truly with some regularity within the walls and by nobody outside the walls ever with any comprehension.

Contrary to "expert consensus" and other such "scientific" lulzi, Bitcoin is not fractionary.ii There are no Bitcoin digits. All Bitcoin sums are integers.

What you call "Bitcoin", as in "a Bitcoin" or "half a Bitcoin" is rather Indian numeration, a sort of lakh, or crore. In those terms, one Bitcoin'd be 10 crore, or a tenth of an arab (अरब) ; and no, I'm not implying genetic-driven cognitive inferiority with these statements. I'm outright saying it : the manner in which "you find it natural" to think betrays your appartenance to inferior genetic stock. Just like the Indians'.

Your genetic inferiority and the phenotypic sadness it drives aside, the interesting question would be "ten crore whats ?!?!" ; and the readily obvious answer follows in the same breath : one Bitcoin is just shorthand for a hundred million satoshi. That's the unit of account in Bitcoin, the satoshi. See ?

It's not that "there never will be more than 21 million Bitcoins ever issued". It's that there never will be more than 2099999997690000iii satoshis ever in existence. That's about 2.1e+15 in scientific notation, or roughly 1.865 peta in binary notationiv. This is an absolute, logical limit ; but there probably also exists a higher practical limit, because if the coinbase is fully fragmented (meaning -- all Bitcoin is held in individual single satoshi containing addresses) payment for mining will perhaps become somewhat awkward.v

Consider the implications of this harsh reality for the assortment of would-be & pretend sovereigns outside The Most Serene Republic : they're going to "track" bitcoin ? Reheheally ? Do some math, why don't you. Each output must reside in an address, that's 160 bitsvi or... 160 * 1.865 = 298.4 PetaBytes to merely store the collection of labels describing the worldstate at any given time.

Let's take a moment to put that 300 PetaBytes figure in context. The peak production of storage media in human history occured in year 2014, when roughly speaking 1.2 bn items were producedvii. This would then mean that the storage required to reflect the collection of labels describing the Bitcoin worldstate at one given moment represents about 0.0000025% of the total storage production during the one year to date humanity produced most storage media. Talk about a megawatt standard!

Talk, talk, but keep thinking : one snapshot's meaningless, you want these at least dailyviii, yes ? So then each year that's 365 * 298.4. Then you also want to retain the transactions involved, which, even with very careful pruningix, can readily average above 1kB per address per transactionx.

If you're snapshotting daily and each address transacts on average weekly, you're looking at the following beauty : (160 * 365 + 1024xi * 52) * 1.865 peta = 203.34 exabytes! Each year!

Now look again at those 2014 figures : are 1.2bn units enough ? To make the question easier : 203.34 exabytes split among 1.2bn units implies a 181.95 GB (gigabyte) average size per unit. Are hard drives larger on average than 181 GB as far as you've seen ? Well... that's good then! How many platters to the hard drive do you think ? Ever looked ?

Bitcoin fragmentationxii poses various problems to various other peoplexiii besides fiatist pretenders, of course, which is why my only otherxiv measure as Bitcoin's central bank and only financial, political and ideological authority -- besides killing an early rally back in 2013xv -- was killing "bitcoin as medium of exchange" nonsense back in ~2016.

Nevertheless, problems or no problems : Bitcoin prevails. It is, warts and all, still today the more interesting thing happening in the world, as it has been since forever.

That'd be all.

———
  1. Just five articles off that large TLP adnotation project in, I already have an excellent reference point, one of those shining jewels of great explanatory power that you know will just recur time and again. Add to this that no less than the adnotation required the involvement of twenty-five other Trilema articles (that's a factor of >5 per!) and all of a sudden it's pretty fucking obvious the digestion was a strictly fabulous idea. Go me. []
  2. Yes, I'm aware that most everyone's introduction to fractions came at their encounter with Bitcoin ; prior to that moment they were living a happy life made out of Baťa prices []
  3. Exact figue. Source. []
  4. Since the principal considerations have to do with disk space, and disk space is allocated in bytes, knowing what factor of 1024^5 the total satoshi count comes to is desirable. []
  5. This is entirely possible, though perhaps not likely -- a situation where one maintains off-blockchain relationships with a miner combine, and communicates their desired transactions as, say, a gpg dump, only to have them later introduced into the blockchain as "zero fee" (with an actual fee paid in kind in some manner, rather than in coin on the blockchain). Like so. []
  6. Provided the pretender isn't actually USGtarded, doing lulzy shit with excel etcetera, in which case a Bitcoin address is rather 25 to 33 base58 symbols stored as bytes.

    Judging by embedded girlies' reports, pretty much all all banking currently happens through java-on-Windows unexamined (and unexaminable) towers of chairs, so no, I don't expect much efficiency will be seen deployed by the celebrated makers of papier-mache boats. []

  7. Don't worry though -- there was hope to overtake this by 2020, back in early 2018. []
  8. Let's amuse ourselves for a moment considering what second-accurate snapshotting would do. []
  9. The absolute size of a Bitcoin transaction falls within a range centered on 180 bytes * count of inbound tx + 34 bytes * count of outbound tx + 10 and as wide as the count of inbound transactions.

    As a forinstance : if you move from 32 addresses into 64 addresses your transaction size will be between 7`914 and 7`978 byts (32 above or below 180 * 32 + 34 * 64 + 10) while if you contrariwise move from 64 addresses into 32 addresses, your transaction size will then be 12`554 to 12`682 bytes, ie 64 above or below 180 * 64 + 34 * 32 + 10.

    The significant differential, whereby the marginal input address adds a 180 byte weight to the transaction, whereas the marginal output address adds merely 34 bytes (18.9%, less than one fifth) creates a very heavy incentive towards coinbase fragmentation (moving from fewer to more addresses results in fewer average coins per address as a mathematical necessity) and against coinbase concentration. []

  10. Suppose you're tracking all the 64 addresses mentioned on the wide side of one of our foregoing examples. You may get away with storing each transaction only once, but you're storing a 8 to 12kB transaction, plus the set of indexes allowing you to link each of the addresses back to it. Figuring index overhead as equal to the data may well be an understatement, for which reason simply rounding to the unit appears a very defensible stance. Hence, 1kB. []
  11. You could, I suppose, replace this with a narrower 180 + 34 + 10 = 224, though I doubt the wisdom. []
  12. Here's some numbers, for the actuarially inclined. []
  13. It poses problems to them, yes ; it doesn't however outright kill them, like it does kill the fiatards and their insufferable regine. Which is, and always was, exactly the point : pentru unii muma, pentru altii ciuma. []
  14. Well, only big one, at any rate. Or maybe not. []
  15. You recall the "epic few days" era, the times of Karpeles and Keisers ? Look at all those coincidences, wooowee! []
Category: Bitcoin
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.

10 Responses

  1. Not finding it in this piece, I'll assume you left it as an exercise. Taking the 12554 byte tx min. figure, the 1e6 byte block houses at most 79 tx. With the avg. 10min. block, that's 87600 tx/yr. Sol burns out long before you get anywhere near the "house each satoshi in own addr" fragocalypse.

  2. Grr, posted this comment prematurely, you can make smaller tx naturally. So the "79" is really closer to 1000. Sol -- still burns out.

  3. Corrected ~figure : 6x24x365x1e6 , i.e. 5.245e10 byte/yr, no matter what. And I'ma lay off commenting before morning tea.

  4. Mircea Popescu`s avatar
    4
    Mircea Popescu 
    Monday, 15 July 2019

    :p

  5. Princess Rik`s avatar
    5
    Princess Rik 
    Tuesday, 16 July 2019

    As a theoretical alternative, each block can consist of one single splitting tx, 200 bytes in headers and output addresses for the remainder 999800 bytes, coming to exactly 29405 of them.

  6. Inspired by Princess Rik's comment, could not resist to actually calculate. Suppose objective were to frag ~one~ "whole btc" into 1sat. spendables.

    Block header: version (4 byte) + prevblockhash (32 byte) + merkleroothash (32 byte) + timestamp (4 byte) + timestamp (4 byte) + difficulty (4 byte) + nonce (4 byte) + txcount (3 byte, in our case, it's a 'varint', i.e. 0xFD then 2 byte unsigned int) == 83 byte, leaving 999917 for transactions.

    Then the mega-tx, considering all but the output-count and outputs themselves: version (4 byte) + inputcount (1 byte, varint, but we have 1 input) + the input (outpoint (32 byte tx hash) + index (4 byte) + signaturescript length (1 byte) + script itself (139 byte, afaik, minimal meaningful) + sequence (4 byte)) + locktime turd (4 byte) : 189 bytes; this leaves 999702 for the remaining data.

    Now an output wants 8 bytes for the value, 1 byte for script length, and 25 for script, i.e. 34 bytes per. (still ignoring the output-count.)

    999702 would hold 29403 outputs evenly. But! we also need output count (in this case, a 3-byte shitoshi 'varint' (i.e. 0xFD then 16 bits.)) So we can't have 29403, and must settle for 29402.

    So 29402*34 and then we add the 3byte count, 999671 byte block, cuts one input into 29402 outputs.

    Now taking one coin as 1e8 shitoshi, one such block can cut it among 29402 addrs, of which say each but the last will receive 3401 s., while the last gets 3798. Let's call this type of frag block 'a'.

    To actually frag a 'whole coin' into 1 s. per unique spendable addr, supposing someone were willing to mine this (let's suppose), you can do ~8 (for simplicity let's pessimistically ignore the 3798) of the above parcels in 1e6 block. This we can call 'b', the 2nd level of recursion. I.e. you need 1 'a' + ~(29402 / 8)=3675 'b' to properly pulverize 1 'whole coin', i.e. 3676 fraggism blocks. 21e6 coins, supposing they all started 'whole' (granted they are ~not~ whole in reality) would need 21e6 * 3676 == 77196000000 blocks.

    If block takes ~10min avg. to mine, then 77196000000 * 10 / 60 / 24 / 365 == 1468721 , ~1.5 mil. years, are needed. (again supposing there were no fraggage today to begin with, but the fraggage there is appears to be a droplet in the necessary ocean.) So in fact I stand corrected, Sol will ~not~ burn out!

    Who wants, can re-do this calc for larger frags (suppose 1000 sat. is already 'dust', and can leave off there.)

  7. *errata: listed in para. 2 'timestamp' twice, but the sum there is correct, i.e. 4 + 32 + 32 + 4 + 4 + 4 + 3 == 83.

  8. Mircea Popescu`s avatar
    8
    Mircea Popescu 
    Tuesday, 16 July 2019

    If 1k is already dust, and can leave there, it's 1468.721 year, ie less time than when Seneca walked the Earth.

    And Seneca did in fact walk the Earth, and he did in fact have a name, being both familiar with the concept equally as we are and also using it practically as we do. He'd even have spelled it, much like we spell things in general ; and he'd have done it exactly like we do it in practice, also : S E N E C A.

    There exist human artefacts, both of the material and of the ideal kind, which perdure past the millenia. Bitcoin isn't the first.

    Bitcoin merely is the greatest.

  9. 1468.721y. supposing no one ever again did anything but emit fragolade per given recipe. But indeed. (Before say "lasts like Seneca" though, really ought to fix the 2030s constant overflow, and other, subtler, protocol bugs.)

  10. Mircea Popescu`s avatar
    10
    Mircea Popescu 
    Tuesday, 16 July 2019

    Quite.

Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.