Although it's not a test of the veracity of any given transaction, it's one measure of blockchain "state", being an aggregation of multiple substates. A valid transaction should therefore result in a movement in that "state variable" corresponding to the size of the transfer. The maintaining of and auditing of such values is just standard practice for all transaction oriented systems and something is just second nature to anyone with a background in them.
Yes. However, there is no such thing as the "block chain state" SEPARATE from the "list of valid transactions". The imaginary block chain state is a derived quantity from that list of transactions.
Think of it this way. You have a locker in a train station and an errand boy who collects donuts from people and puts them in the locker. We define some kind of failsafe "receipt" that the errand boy returns to you when your donut is deposited so you know your delivery definitely arrived.
The total number of donuts in the locker is a "state variable" of the system that can be calculated from the total number of valid transaction receipts held amongst all the disparate senders. That "state variable" is meaningful and adds to the perceived integrity of the system.
This is an excellent example to illustrate your mistake.
In the donut system you propose, there are indeed, TWO INDEPENDENT elements: there are the failsafe emissions of receipts, and there are the true donuts in the locker. As such, one could test the validity of the receipts, or the validity of the locker, by comparing the sum of receipts, with the counting of actual donuts in the locker. That would be a true double check.
But this is NOT what we have in bitcoin, nor any other crypto. There is no locker. We can DERIVE an *imaginary* locker by counting the failsafe receipts. Now, if we are going to compare this DERIVED quantity with, eh, the number of receipts, then OF COURSE we will find agreement. But that is not a check ; or at most, it is a check on our way of counting receipts.
Now, as with bitcoin, or with monero, there is only the block chain containing the "receipts", then there's no point in wanting to "see the locker" that is simply the sum of receipts, to test against, well, the sum of receipts.
This is what you are complaining about that this can be done by everybody in bitcoin, and only by persons holding the secret key in monero. But as you see, there's no point in doing so: it doesn't help anything.
Because nor in bitcoin, nor in monero, there is a donut locker. There is no independent bitcoin state, as there is no independent monero state. There's only a list of valid transactions, from which one can derive such a hypothetical state. But to use that state to verify the validity of the transactions, is of course ridiculous. So whether you can derive that state for everybody or not, doesn't add any "security".
In some ways it's like a digest hash that gets used to test if a document has changed since it was created. It also serves as a human-readable "control" on individual transactions because you can detect both blockchain errors and reporting errors by checking that the aggregate and granular interpretations agree.
Again, that is a good example. With a digest hash, you have the sender that calculates the hash, and sends you the document and the hash. On the receiving side, you redo the calculation of the hash, and if it doesn't fit, then or the document was altered, or the hash was altered, or the sender made a mistake. But you have TWO INDEPENDENT information sources: the document, and the hash.
However, the bitcoin/monero equivalent here, is that you only have the document. You can calculate a hash from it. And now you can take that document again, and re-calculate that hash. You check the first calculation of the hash against the second one. If it fits, you tell that there is more confidence in the document. It will always come out of course, unless you made a mistake in calculating a hash. That is about the equivalence of wanting to test balances from a list of transactions: the test tells you whether the balances are obtained from a list of transactions. Of course they are: that's how you obtained them in the first place.
You don't have two independent sources of information. You DERIVE two identical quantities (donut count, document hash....) from the one and single piece of data you have in any case: the single source of information which is the list of transactions. If you check these, the only thing that that proves, is that you did your calculations in a correct way, NOT that your list has an integrity.
The difference between Bitcoin and obscured blockchains is that bitcoin makes these blockchain aggregations auditable by all - not on condition of whether you happen to have a private key to a particular address. That gives it lots of advantages in terms of confidence, robustness, usability and perceived integrity because granular actions (individual transfers) can be controlled by aggregate observations in a way that they cannot be on an obscured chain.
The point is that those "audits" are mathematically always satisfied, unless you make a mistake in your "audit", because you are NOT confronting two independent sources of information. Now, an "audit' that always comes out as correct, is not an audit of anything, except of your capacity to do the correct calculations, nothing more.
Look at it this way:
you have a transaction in bitcoin that is {B is diminished by 2, A is augmented by 2}
Well, whatever is the state of bitcoin before that transaction, the state afterwards will be in agreement with your requirements if this transaction is correctly applied in that state calculation. But that doesn't give you ANY extra check or information.
If in monero you have a transaction that is {one of B, X, or Y is diminished by 2, and A is augmented by 2}, then you cannot calculate the state afterwards, or you can only calculate 3 possible states afterwards ; but they are ALL correct. The checking of any of these 3 possible states will give you satisfaction on your test. And again, it doesn't check anything that you didn't know already.
for 
)
