Oh Lordy! Those are the best unintentionally funny posts in a long time. I just quote them for the future reference, when I have to retell the story of "professional code monkey contra Bitcoin". Not just plain, garden-variety, cowboy code monkey a
PROFESSIONAL code monkey.
When "Who moved my cheese?" was published and became an instant hit I keept saying that the book is so exagerrated that it becomes an unintentional comedy. Now I know that this book was not an exagerration.
I'm going to quote the signature too, because it makes the whole story even funnier:
@etotheipiBe sure, any halfway experienced developer having to communicate with other Computers/datas
first of all studies the BASICS, often called "protocols".
This was one of the first things I did, of course - weeks ago.
Spent hours and days searching usable, complete and reliable infos, starting with Satoshis paper (in this respect totally unusable).
I really couldn't and can't believe it.
I am working with databases since decades, first programming them myself (yes!), then using half a dozen of all the very similar DBMS (dBase, SQL, MySQL, BdB ...).
The basics are logically always the same: Headers, records, fields, indexfiles.
If variable field lens are used, we need delimiters or len specifiers for them.
Any encryption, hashes, Endianness, compression... are next to be explained.
I normally have no problem with all that. Normal electronic banking belongs to the easiest things I do.
Since databases never are loaded into memory they normally are not splitted as in BTC with its numerous blkxxx.dat + revxxx.dat
This and much more I would like to understand.
Seearching for infos about BTC I found a mess of superficial, inconstistent mixtures of this and that, advertising and promotion mixed with technical infos, even "Messages" and DB-structures -although complete different things- mixed together, nothing fully explained.
Why James, Bitrick, etotheipi tried to provide what I am searching for?
Thats why I asked my silly questions.
Where eg. is the date/time of transfers ? The "lock_time" is a different thing, mostly zero.
The block creation time might be interesting for miners or other internals, not for applications.
Just because you mentioned it above, lets take another example:
Above you write about "BlockHeader(80)"
whereas in the
https://en.bitcoin.it/wiki/Protocol_specificationthe field sizes of Block Headers are 81.
You know it yourself:
One byte difference on this level is enough to crash a complete app.
Satoshi Nakamoto, naming himself the "founder" of BTC might be an expert in cryptology.
This might explain that all what he writes in his basic article
"Bitcoin: A Peer-to-Peer Electronic Cash System"http://bitcoin.org/bitcoin.pdfhas NOTHING todo with basic knowledge of money and bookkeeping.
His main factual problem is his so called "prevent double-spending".
Normally "a trusted third party [bank] is required to prevent double-spending" he tells us.
Sorry.
Never heard that "double-spending" i.e. spending the same money (or other things) twice is possible at all.
In case of
real coins (and all other things) each child knows that, I hope.
In case of
cashless payments its exactly the same since each payment reduces my disposable fund.
Where no money, there no payment.Controlling that by software designed to manage whichever currency is normally the easiest thing at all.
Security and privacy are very important, but totally different questions.
They have as in all other cases (cars, gold or potatoes)
logically nothing todo with the things protected.
But Satoshi Nakamoto sees that quite different, stylizing prevent of "double-spending" of BTC to the main task BTC has to care for.
Talking about Bitcoins in its title the central topic BTC is mentioned in his paper not even ONCE.
Instead he only speaks about important but
secondary problems, about hashes, keys, "proof-of-work" etc.
But first comes the basic logic, then security and encryption - everywhere.
This might explain that even the basic logic of BTC is at least for me not understandable at all.
Perhaps he didn't understand it himself.
Nakamoto/BTC vs. bookkeeping
As I wrote
Bitcoins are money.
The basic logic of money transfers from A to B normally belongs to the easiest things in the world.
Technical things like encryption or the structure of involved databases change nothing in the very, very simple logic of money transfers.
In short:
A minus for the payer is a plus for the receiver.
At least time and reason of transfers are always added normally.
All is collected and balanced in the accounts of payers/receivers.
Easiest bookkeeping.
Some of these things either do not exist in BTC or simply are somehow hidden.
Where e.g. is the field for the transaction date/time?
I assume that there IS one, since Armory restored by the blockchain date and time of my transactions.
Lost after a restore were my manual "Comments" of transactions only.
BTC does indeed not have a field for the reason of transfers.
Other things like the strange "changings" not to mention....
Sorry, but even after reading quite a lot I am far away to understand that.
Satoshi Nakamoto writes:
Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.
We propose a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
...
In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest(??) nodes collectively control more CPU power than any cooperating group of attacker nodes.
9. Combining and Splitting Value (unbelievable!!))
Although it would be possible to handle coins individually (
), it would be unwieldy to make a SEPARATE TRANSACTION FOR EVERY CENT(
) IN A TRANSFER.
To allow value to be split and combined,(
) transactions contain multiple inputs and outputs. Normally there will be either a single input
from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs:
one for the payment, and one returning the change, if any, back to the sender.
?
(unbelievable!!)
12. ConclusionWe have proposed a system for electronic transactions without relying on trust.
[cmnt: misleading! we rely on trust. Trusted "party" is just like a bank the public blockchain!!]
We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending.
To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest(
?) nodes control a majority of CPU power.
The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can
leave and rejoin the network at will, accepting the proof-of-work chain as proof of what
happened while they were gone. They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on
them. Any needed rules and incentives can be enforced with this consensus mechanism.
========================
It might be a sacred cow, but I can't help it:
The basic logic of BTC as explained by Nakamoto himself, is wrong.This does not mean, BTC is not usable at all.
But most complications have nothing todo with encryption or the public peer-to-peer database/network.
These are secondary technical questions, used except the public database in all "normal" electronic banking.
The problems have todo with the fact, that Satoshi Nakamoto as cryptologist forgot to implement the basics of normal bookkeeping.
He ignored the fact, that his blockchain is
logically nothing else than a normal bank and should work like that, of course.
His main factual interest ("prevent double-spending") would be -since logically impossible- no special problem at all.
