This notwithstanding, an unbinding summary is that the miner-node divisioniv is both an unintended consequence of the poor design and inept implementation of Bitcoin by its original author as well as the single known possible threat to its continued survival. This measure heals that rift, by making it impossible for miners to mine without nodesv) ; and by giving nodes a directly valuable piece of information they can sell.vi
The Vatican's Armored Divisionsvii :
I won't bother with parading for your benefit, nor will I recount the sad story of "what happens when you don't do what MP says". If you've done any reading worth the mention you should know all that by now ; if you need any explanation as to why my pronouncements are binding, you necessarily have no clue about Bitcoin-anything. See here instead.
I will however say that detailsviii are negotiable, on one hand, and that I am open to considering other changes be bundled with this change, possibly including an increase of the blocksize. I will however, attack and sink any other change whatsoever, without regard to who proposes it, who supports it, or what it contains. The only way to make any alteration whatsoever is to make an alteration that includes this one.
And now that we understand each other, back to your regularly scheduled program.———
- The principal consideration is that unlike the rest of the SHA "family", the keccak function takes unlimited input. Bitcoin is forever after all.
The political importance of not using NSA/NIST crapolade is a secondary concern, even if it makes a very valid, muchly needed statement, namely that the United States has no future in technology just like it has no future in political geography. [↩]
- Exempli gratia : if the fourth block is added to a blockchain consisting of
- 60 bd e7 67 77 70 20 b2 e6 7c 46 c3 (12 bytes)
- 75 80 d2 b0 6e 6c 6d a9 5d 12 98 fe bf (13 bytes)
- df fc 22 5f 2a 4d 50 d6 f3 fc c3 (11 bytes)
Then should that block use a nonce of 17, it must include a field equal to sha3-512(70 6e 50), whereas should that block use a nonce of 11, it must include a field equal to sha3-512(c3 fe df).
- The notion that you might be participating in Bitcoin in any capacity or to any degree without keeping up with the logs is not unlike the notion that you're participating in the political process through "reading newspapers" or whatever it is you do. [↩]
- There's multiple aspects to the issue.
One aspect is that while nodes - no, not "full" nodes, simply nodes ; everything else is not a node at all - do provide useful service, they have no way to extract payment in exchange. This takes us to the present, sad situation where the network barely consists of a few hundred nodes, and on the strength of that alone could be toppled by a fart. (Yes, supposedly significant reserve capacity exists. Let's just hope nobody actually gives this a run for its money.)
Another aspect is that new blocks are mined by one group (miners) but have to be stored in perpetuity by another group (nodes). This creates a situation where X (users) pay Y (miners) to inconvenience Z (nodes), which is unsustainable not to mention sheer nonsense.
It is true that so called "solutions" to this fundamental problem have been pluriously presented by Bitcoin's enemies in sheep's clothing. Nevertheless, they all reduce to attempts, more or less blatant, to leverage this weakness of the protocol into further damage - not a single one of them is to any degree an actual solution or even vaguely addresses the problem at all. [↩]
- For reasons that I think obvious, mining will continue on ASICs, even if this change will require new ASICs be baked. Nevertheless, for technological reasons it will be impossible to include the generation of this bitfield in the ASICS in question - instead, they will have to depend on importing it from outside.
Whether miners will run their own nodes or allow a decentralized market of "subscription information services" to spawn up will remain to be seen, but if you do believe in the economic superiority of decentralization then you're stuck believing this will happen necessarily.
In any case, a word to the wise : if you are designing ASIC chips, and you are not including the possibility of feeding a bitfield like this in blocks, you are deliberately ensuring failure not just for yourself, but for your customers as well. This change WILL eventually come in, start planning accordingly, today. [↩]
- Logically what you'd do as a node operator is create KNBs (known nonce blocks) every time a new block is found. Depending how fast your machine goes, you should be able to output thousands of these per second. A miner that has to feed its rigs something will then buy these blocks from you and proceed to use them (and possibly announce them afterwards too, to protect other miners from being scammed with the same nonce block).
This forces a minimum population of nodes to exist in order for mining to even be possible - what use is more hashing if there's nothing to hash ? [↩]
- Is there any сталин in the house ? [↩]
- Probably the most important of which, shifting the nonce before taking the nonce-th element. Taking the nonce as-is requires strict parity between each hash and the calculated digest, which would require 64 MB of information be available to the miner for each Mhash. This is perhaps not practical - although it does have the marked advantage of making ASICs altogether impractical for mining, and returning that process to more traditional computers. A rather generous eight bit shift would mean the miner needs 64 bytes every Mhash, meaning that each Phash chip must have 64 GB/s worth of data to work its magic. [↩]