Bitcoin Forum

Exact binary map of database blockchain?!

As far I can see its only "JAMES" who tried to document the EXACT structure of the blockchain.

"Bitcoin: 285 bytes that changed the world", 12:22AM, 12th January 2012

http://james.lab6.com/2012/01/12/bitcoin-285-bytes-that-changed-the-world/

Asking the experts:

1. Is JAMES' docu correct?
2. If yes, why is it not included in the "official" https://en.bitcoin.it/wiki/ ???

I looked everywhere, but found nowhere else so extremely important and needed things like that.

Blockchain = concatenation of blocks
Block structure: https://en.bitcoin.it/wiki/Protocol_specification

Yes, ok, "Block" or Blockchain. Just as you like it.

Yes, I know your wiki-link. But sorry, cannot use it at all.
Far away from useable, "normal" docus of databases like that one of James'

AFAIK there is no such thing as binary map of database blockchain. Every client uses it's own format to store blockchain (levelDB for example).

What I mean is an exact and comprehensive byte-by-byte description
such as provided by Armory for its wallets.

https://bitcoinarmory.com/armory-wallet-files/
https://bitcoinarmory.com/wp-content/uploads/2012/01/ArmoryWalletFile.png

Is there really nobody who can or will answer my question ??
I think for a developer its one of the most important infos to know.

As far as I can tell, Jamess account is correct. Reason that it's not on the wiki: nobody ever found it interesting enough to put there.. Feel free to create an account and put it there ;-)

As for you other remark.. I guess developers don't need a post like Jamess, they read it in the source if they find they need the information:
https://github.com/bitcoin/bitcoin (https://github.com/bitcoin/bitcoin)

The files have a loose format.  The files contain blocks (magic number, size, data), essentially the same format as the block network message.  The files should not contain other data, but all parsers should be careful to discard anything that isn't a valid block.

The data part of a block includes the header, a transaction count, and then transaction data.

All of this is on the wiki.  Start here (https://en.bitcoin.it/wiki/Blocks).  Don't miss the link (https://bitcointalk.org/index.php?topic=101514.0) near the bottom.

Yes.


Because it isn't "useful".

Those who have use of such information (developers), can get it reliably from source code.  Those who are unable to get what they need from source code, don't really have any useful need for the information.

Yeah! I am really sorry that an experienced banking developer is so silly.

Sorry, I really need these infos somehow on the lowest level.
Functions/APIs already working somehow with a database are much too high for me. :D :D
 

The blk*.dat files stored in the Bitcoin home directory are quite simple -- just a straight concatenation of blocks of the form:


The "BlockSizeBytes" field includes the BlockHeader and NumTx, so you only have to read that and skip that many bytes if you want to jump to the next block.  This is is also how blocks are serialized peer-to-peer. 

Yes, thank you.
But searching around I already saw your equal posting in the last year:
https://bitcointalk.org/index.php?topic=101514.msg1111214#msg1111214
Its not what I mean, namely something like the perfect description of your own Armory wallet.

Using a third party database developers must exactly know everything about its structure, each of its fields...

We get those infos from each normal Bank.
But in BTC this seems to be top secret. :D

The serialization of the headers and the transactions are documented on the protocol specification page (https://en.bitcoin.it/wiki/Protocol_specification).  What I wrote above is how those individual pieces come together in the blk*.dat files which contain the entire blockchain.  I did make an exact binary map of the transactions, though it was made before P2SH.  You can see it here (http://dl.dropboxusercontent.com/u/1139081/BitcoinImg/TxBinaryMap.png).  There's a few other nice inkscape drawings here (https://bitcointalk.org/index.php?topic=29416.0). 

The only caveat is that now the blk*.dat files are padded to 16MB chunks, so the end of the files may contain lots of zeros.  But this is easy to detect, because blocks are never split between files.  So you only have to check for (isEndOfFile() OR magicBytes==0x00000000) to determine that there are no more blocks in the file.

Because the block files are externally indexed, I usually tell people not to make assumptions about what is in them.  The -loadblocks code is a very good example of a parser that can tolerate all manners of garbage between blocks, corrupt blocks, etc.

That said, when I was ripping my files for the bootstrap torrent, I found exactly zero cruft in what my node had accumulated over the last few years.

I can vouch that they are extremely consistent.  Armory does a raw scan of them on every load (which will be changed soon, thank god).  Despite being used by thousands of people over the course of the last 12-18 months, there is rarely any problems with it.   Some of the recent Armory problems have actually had to do with memory usage on 32-bit architectures, and not due to actual blk*.dat corruption (switching to the 64-bit version solved it).

So far I could not use anything in the BTC wiki.
From the technical point of view we find quite a lot of more or less superficial descriptions of this and that.

But this for the transactions looks much better, thank you!
http://dl.dropboxusercontent.com/u/1139081/BitcoinImg/TxBinaryMap.png

Still missing an equally exact description of the "surrounding" "block".

And btw many thanks for your other good work, Alan.
Armory is definitely the best wallet I know.
Very well designed, very well explained and due to its even me :D convincingly explained "deterministic" architecture almost foolproof.

All the complaints of users having lost their money due to password problems with things like bitcoin-qt
https://bitcointalk.org/index.php?topic=85495.0;all
https://bitcointalk.org/index.php?topic=191401.0;all
have an end with Armory.

Thanks.  I did a lot of this because of the learning curve to get into this stuff.  Bitcoin is complicated.   But if you want to dig into it, you'll have to do a little messing around on your own.  I don't want to ruin all the fun for you :)

The rest of the serialization is trivial once you know the transactions.  The header is exactly 80 bytes, 6 values.  And you can look up how VAR_INTs are read from that protocol page.  The magic bytes are f9beb4d9.  The protocol page isn't pleasant, but it's not useless, either.

I reject your claim that nothing in the wiki is usable.  It really does contain everything that you need to understand a block.  Just takes some getting used to...  :)

The "surrounding block" is described exactly above.  There is some confusion on exactly what parts are block and which parts are message.  Most people consider the block proper to be "header + NumTx + TX_0...NumTx".  In practice, you'll pretty much never find those stored or communicated without the magic number and the size, except when using the RPC calls that return block bodies.

Keep in mind that bitcoin is nested, and a lot of the complicated bits are in the interactions.  The block itself is very simple, a short header followed by a list of transactions.  Transactions are simple too, a header (really just the version field), a list of inputs, a list of outputs, and a footer (just the locktime field).  Inputs and outputs are where things start getting strange, but even those are pretty simple in representation.

@kjj
If its really all so "simple" - why isn't it likewise simply explained?

Ah!
What do you mean with "bitcoin is nested" ????? What do you mean with "a lot of the complicated bits are in the interactions"???
To begin with: what exactly is that "interaction"?
So far I only heard from transfers/transactions.
If you mean the same, what exactly do you mean with "complicated bits" (bits?)?

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.

LvM - the point was that you are going to have to put in some elbow grease like the rest of us and figure out the minutiae.  Once you look at some binary maps and match them up against the serializations described on the protocol page, it will seem a lot simpler.  Only so much of it can be spelled out for you.  Trying to spell it out even further isn't all that productive, because you're not going to "get it" until you dive in anyway, and then those documents will seem entirely sufficient.  

100% of the details may not be there.  But most of them are.  It's accurate.  Ask questions.  Look at other implementations.  

Open blocks/blk00000.dat and read the first 300 bytes.  Then match it up against the protocol page and what I wrote above.  You'll see the magic bytes, the numBytes, the 80-byte header, the numTx, then a list of Tx.  You can then jump to an arbitrary block.  Jump to block 170 which has the first real transaction (it has two tx: a coinbase tx and then are regular pay-to-address transaction).  

Maybe you would be better off asking specific questions.  All of the information has been provided, but we are apparently unable to translate our answers into a form that is simple enough for you.  :(

The question is specific, absolutely precise, simple, quite normal and most important if third party datas must be used.
I would and could answer the same question regarding my datas/databases within minutes.

The blockchain must be used by each client, by all users of BTC.
So I can't help but assume: the details are unknown or hidden deliberately.
Top secret ???

LvM, I don't know what the problem is.  That protocol page very precisely lays out all of the serializations of block data and messages.  And it's accurate.  Everyone who has developed any Bitcoin software has used the information on that page, and errors subsequently flushed out if they were found.  It's not 100% complete, but it's accurate in what it says, even if it's not the most visually pleasing/organized descriptions possible. 

What kjj was alluding to was that there's deeper meanings to a lot of these things.  And while documentation could be improved, a lot of you just get from experience.  If the documentation is lacking, help fix it.  But for where you're at, there is more than enough there. It describes the binary maps exactly as you wanted.  Like I said, just open blocks/blk00000.dat and look at the first 300 bytes in a hex editor and compare against the data on that page.  You'll get it.  But it can't be spoon-fed to you.

Ahh, fuck it.  I was trying to cut you some slack because I figured english wasn't your first language, but you found it out.

All of it is top secret.  The published source code is fake, the extensive documentation on the wiki is all fake, even the posts on the forum and to the mailing list are fake.  Blocks are really just incomprehensible blocks of random data

Lvm, what bank do u work for? And what is your job there? I expect you do functional maintenance or something similar? I work at a bank as well, and I develop software as well. I concur that the bitcoin specs aren't anything near to the specs for like a SEPA transfer, but you forget one thing: because banks all have their own software (most still written in cobol :-p), banks have a need for perfect specs. Bitcoin is bitcoin. One client which uses the wallet and blockchain. There can never be discussion between bitcoin and itself, it simply works.

Thats what I, kjj and ethotheipi tried to explain, ethotheipi even went much farther than that giving you the closest thing to specs I've ever seen on the subject (thanks for that btw!)

Bottom line, if you want exact specs, read the code, bitcoin is not a bank and is not by any means "required" to hand out specs or api's. If you have a specific question (other than gimme the specs) because of a project you are working on, ask the questions instead of the specs.

Lastly, don't try harder, try different ;-)

@etotheipi

Be 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_specification
the 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.pdf
has 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. :D

Nakamoto/BTC vs. bookkeeping
As I wrote

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. Conclusion
We 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.

Ahh, good.  Specific questions.

Transactions don't have timestamps, but blocks do.  The timestamp on a block is considered to be the time that all of the transactions inside it happened.

Lock_time is indeed something else.  A transaction is not allowed to be included in a block until the lock_time has expired.  If lock_time is less than 500,000,000, it is considered to be a block index.  If greater, a UNIX timestamp.

The header network message is different from the header that gets hashed.  The first 80 bytes get hashed.  The network message includes that 80 bytes, plus a variable length integer transaction count.  I think I mentioned in an earlier post that the exact spot where the block header ends and the block body begins was a bit fuzzy.

P.S.  Your commentary on the whitepaper is wrong, deeply wrong.  You may know a bit about banking, but you don't seem to know anything about the history of cryptocurrencies.  Bitcoin is the solution to problems that you don't seem to even understand as problems.

OH LORD! Why did you write it publicly??  >:(
I thought all Hero Members had to sign the Biggest Lie Of All-Time Non-Disclosure!!

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:

@kjj


In reality all transactions even in the same block differ in time.
Nonetheless they all use the same timestamp? Can't really believe that.
Nonetheless that exactly the chronological order of transfers avoids double-spending?

Armory restored date+time of all my different transactions (as it seems correctly)
Was this something like a trick? Visionary power ???


Why ???

Sorry, modesty is my middle name. But I can assure that I know more than "a bit" about banking and money, legally, economically, logically.
"History" and/or renaming money to "cryptocurrencies" changes what??

Be sure:
the basic logic I talk/ed about, was, is and will always be the same - since 100thousand years, forever. :D

Proofed very well in the other only aggressive comments, totally free of any arguments. :D

But might be that anybody understands "OH LORD" or "Funny" as an argument.
ROFL!

@LvM

I suggest you stop posting this non-sense, you are only embarassing yourself. By now nobody in the community will take you seriously and your "(unbelievable !!)" irritating comments on the whitepapers just demonstrate you fail to grasp the very basis of bitcoin.

Please no
That's too funny to stop now

@LvM

I presume that you are German and because you title yourself PROFESSIONAL you hold a Dipl.Ing. certificate or some such.

As a holder of such certificate you have some ethical obligations, e.g.

a) do not consult outside of your area of expertise
b) continuously educate yourself on the progress in your area.

You failed on both counts.

Germany has a long history of an effective regulation, most famously the German Beer Purity Law from 1516. Violations of that law were punished by burning all the tools used to brew and/or sell beer in a negligent way. The repeated offenders were publicly whipped at a pillory.

Here you are getting off easy: nobody's going to burn your computers and you will be subject just to the some ridicule, not a corporal punishment.

If you need inspiration on how to fuse the Bitcoin technology with the traditional banking and finance technology take an example from grau and his bitsofproof.

https://bitcointalk.org/index.php?topic=122013.msg1350149#msg1350149

Edit: corrected the spelling of Dipl.Ing. (Diplom-Ingenieur, German equivalent of Master of Science)

Please post more, LvM! You're making us laugh.

If falsificaton of clearly analyzed facts is impossible the word "nonsens" certainly is a very strong argument also.

So far we have:
"OH LORD"
"Funny"
"Nonsens"

Forgotten something? Any other strong or even stronger arguments?
:D :D :D :D :D

Today I had an opportunity to open the first edition of Bruce Schneier's "Applied Cryptography" from 1994. The second paragraph of the "Digital Cash" chapter explains double-spends in his rare style that is both highly entertaining and highly educational. Since we now have year 2013 this marks nearly two decades of you being out of touch with the progress in your claimed field of expertise.

No, really.  As far as bitcoin is concerned, all of the transactions in a block happen at the exact same moment, in the order listed in the block.  They may have been created years ago and published days ago, but that doesn't matter.  They are deemed to have happened at the time listed in the block header's timestamp field.  For extra amusement, keep in mind that the block's timestamp can be in the future or the past.  It is a rare block indeed that actually happened exactly when it claims it happened.

Your belief in this is not required.  I'm telling you how it really is.

I hope that the other posts in this thread have led you to do some research into what exactly a cryptocurrency is, and how it differs from a bank ledger.  Bitcoin is not just the same money that you know about under a different name.  It is something new.  Well, new-ish.

To clarify kjj's point a bit further: you must remember that Bitcoin is a consensus system.  Transactions are not "real" until there is some degree of consensus that it is valid.  This is done by including it in a block.  Therefore, broadcast time, while may be interesting for you, is irrelevant to the system.  The proof-of-work associated with each block is consensus-building feature of Bitcoin, and that transaction doesn't really "exist" until it's in a block.  

Therefore, you use the block timestamp to determine when the transaction first received any degree of "consensus".  The actual broadcast time would not only be a waste of space, not everyone has the same clock, or received it at the same time.  That's part of Bitcoin's charm, is that it can work with millions of users, many of whom are scammers, and some of which are behind slow internet connections and don't see all the traffic.  But it still works.

When Armory displays your transaction, it's only displaying the timestamp on the block in which that transaction was included.  From Bitcoin's perspective, all transactions in that block happened at that time.

@LvM: Like others have said before in this thread, you fail to see what Bitcoin really is, because you keep thinking in your own environment of bank accounts.
What Bitcoin tries to resolve is something completely different !

Let me try to explain the basics:

Centralized versus decentralized:

If a person A has a bank account with bank B and wants to send some money to person C that has a account at bank D, then this is what happens in your world LvM:
person A gives bank B (and only bank B) the authority to "send" the money to bank D. This involves central authorities (bank B and D) that have to be trusted: bank D trusts bank B (that the transaction is legit, that they are not double spending money or creating money out of thin air), and person C trusts bank D that he can get cash from his account that was credited.

I suppose you can understand the above (and probably better then I do).

Now LvM, ask you the following question: what happens if there are in the above scenario NO BANKS involved AND A and C don't trust each other (as they are strangers) ?
To put it in other words: person A wants to send some money to person C. (And afterwards, person C should be able to spend this money to another person E)

This is exactly the problem that bitcoin solves !

We have two problems:
 1. C will only accept the money if A can prove he "owns" the coins: that is why the transaction is signed cryptographically by A to prove he owned the coins. And with the transaction, all coins are transferred to an address "owned" by C (that is, only C can sign the spending, as he is the only one that knows how to), and "the change" to another (or the same) address "owned" by A.
Due to the crypto-magic, C does not have to trust A: he can easily verify (and everyone else looking at the transaction) that the signature is correct, and the signature is nearly impossible to compute by anyone else then A.

 2. A malicious user A could try to send his coins not only to person C, but at the same time send them to X (here is your impossible double-spending). Both C and X can verify the signature, which will be correct. But which of those transactions is the right one ? The solution that bitcoin offers here is the "proof-of-work" blockchain: the transaction that is recorded in the "best" blockchain will be recognized by everyone as the correct one. Nobody needs to trust anyone, no bank needs to authorize something. NICE, ISN'T IT ! The company you work for is not necessary anymore :)

So here you have it:
I want to spend Y coins I received (from mining or from others) to person Z: I make a transaction and send it to the network. After a while, it will be included in a block, and after some more time, it will be "buried" deep enough in a chain of blocks so that it becomes nearly impossible to change it: now everyone in the network will happily accept that person Z owns Y coins.

@bfever
Thank you for your kind explanations.
I understand most of it, except that the blockchain in my opinion certainly plays the role of a bank.
The receiver does not check ownership. I never did that, don't even know howtodo. :D

I know that. Saw it cited or as link in wikipedia, bitcoin.org or so, perhaps on Bruce Schneiers own website.
Could and can do nothing with that. You? Why?

As said, encryption is quite a different problem anyway. 
Bad idea to mix money transfers or (likewise) the content of emails or anything else with their encryption.
I am interested in the basics, encryption is another level.
Didn't even try to talk about encryption at all.

Can't agree, sorry.
And I am firmly convinced that there is no logical difference between ANY currencies at all.

Thank you!
So the block time is comparable with a bank working day, even the time.
Yes, fine! Have no problem with that!

Remains the problem of the "changings", but that seems to be a (self produced but anyhow solved) pure technical problem only.

That there is no field "reason of payment" remains as really significant disadvantage.

More fundamental, the 21 Mio. limit which almost alone makes BTC interesting for me is in my eyes not really guaranteed.

The so called "community" might change that some day, accepting a BIP concerning this matter if they like and are so silly. Technically it seems easy, enough to change just one public variable. But I am not sure, of course.

btw, this guy is trolling the bitcoin.de forum and the german subforum here for weeks now.
he is no expert in anything, he just seems to enjoy wasting other peoples time. dont let him.

Sure, but the discussion is sort of entertaining at least.  If he's a troll, he's one of the more entertaining trolls I've communicated with.