Topic: Ultimate blockchain compression w/ trust-free lite nodes - page 6. (Read 87932 times)

@Pieter Wuille

I would rather say, that "accounting systems" and "currencies" are completely different things.
They cannot be compared or treated/used somehow alternatively as you insinuate.

Accounting is for all currencies including BTC exactly the same!
For details see GAAP, not even mentioned once in the whole wiki.

https://en.bitcoin.it/w/index.php?search=GAAP&button=&title=Special%3ASearch

In BTC its really easy.
We have to deal only with a very tiny and very easy partition of GAAP,
i.e the logically really quite simple payment system only.

A ==>> B, B ==> C etc.

But basics forgotten, totally ignored at lowest levels can hardly be repaired on higher levels, here the level of users/clients.
Going that way the self inflicted basic problems are perpetuated and increased, see the endless exploding blockchain (which easily could have been avoided by carry-overs not even thought about, see GAAP).

So I can't help but hope and insist that all efforts are concentrated and invested in the BTC level itself and not wasted in workarounds installing a complicated parallel system for things that should and could much easier be done on the lower level.

Muck out all stuff and bestow BTC itself (not the clients) with a small and professionel, fast working payment system, simply and quickly usable by each client and THEIR accounting/bookkeeping systems !!

Brevity is the soul of wit.
The more code and stuff the worse.

Small is beautiful !!

Yes, bitcoin can have a lot of complex transactions which falls in 2 categories (not exclusively):
- things that are needed by 0.00001% of users
- things that must be blocked because it would bloat blockchain too much

Also the "accounting solution" only helps as long as there are transactions like "1..n inputs pay to 1..n outputs". Bitcoin can have vastly more complex standard transactions and even more complex nonstandard transactions.

If you want to have a good accounting system, please start by improving ABE (the alternative block explorer) to actually even handle all currently existing transactions on the block chain and assign an account to each of them. Good luck with that.

Bitcoin at its core is not an accounting system, it is a currency. It implements this through its own ledger-like mechanism, though one that doesn't quite exactly match what we expect from a ledger. And I believe that doesn't matter.

Accounting is something you do at the "payment level", not at the "currency level". Dollars have no built-in way to track historical balances, and I don't think anyone considers that a shortcoming. We can keep track of credits and debits regardless.

I'm sure that with all developments at the wallet software (multiple clients, payment protocol, ...), it's perfectly possible to create a GAAP-conformant system, or at least one that easily integrates with accounting systems.

I don't think discussion about that belongs in this thread though - this is about solving a low-level scalability problem, not about how we manage high-level use of it.

@maaku

Will be very interesting if the result of your efforts is more than just a workaround, making things even more confusing,
not really solving the underlying fundamental problems I gratis explained solely from the financial point of view.

As normal in those superficially solved workaround and muddle through cases the same or equal problems will arise.

I made this experience again and again with my own code.
So this could become a lifetime job for you!
Congratulations!

@maaku

You did not even try to understand what I wrote?
The fact that BTC has no GAAP conform accounts is exactly the problem I mean and explained.

But do what you like or better:
do what you have todo after collecting thanks mainly @evoorhees >156 BTC for the first 3 months of your adventurous efforts.
Around 15.000,00 USD. Bravo!

https://bitcointalk.org/index.php?topic=204283.0;all
http://blockexplorer.com/address/13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

LvM, I suggest you reread this proposal and contemplate it's structure. It is much closer to what you are proposing than I think you understand it to be. I suggest you also look into why bitcoin is structured the way it is (addresses != accounts), as there are good reasons for that too. Then I suggest that you make another thread detailing your proposal, as we are wandering significantly off topic.

So we cannot but hope, that BTC will very soon be improved basically.

As BTC newbie having still enormous problems to understand the really weird details I cannot help to rewrite the code, sorry.

But an expert like Etotheipi (author of Armory, the best BTC client at all) certainly could do it almost alone
(instead of wasting his precious time with his proposed workarounds for clients only).

The main problem for experts seems IMHO not the code, but the "community",
esp. "markets" like MtGox etc. and services like blockchain.info, blockexplorer.com... having to readjust their codes accordingly.

But the new GAAP-conform code would be much shorter and clearer than the present one, a clumsy mess already at the lowest level.

@Jtimon, aaan

Ripple indeed seems (at least as they describe it) to be MUCH better structured than BTC.
Could be taken as model or prototype for a new BTC!!

Like any other accounting system Ripple also does not need and have these "blocks" and their "miners".
They instead produced all their 100 billion Ripples aka XRP in advance and kept them for themselves.

"The Ripple founders created the initial Ripple ledger with 100 billion XRP. The founders gifted a for profit company called Opencoin 80 billion XRP. Opencoin intends to give away over 50 billion XRP. The remainder will be used to fund Opencoin operations, which include contributing code to the open source network and promoting the network."

https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners

But that's also just another reason why I do not really trust the Ripplers in the moment.
See also glitch003: https://bitcointalk.org/index.php?topic=179677.0;all

@galambo
Yes. Its really important that everybody understands what you write about accounting!

But the Bitcoiners don't know anything about accounting, nothing about the balance of money payed and received. So they ignored from the very beginning all basic GAAP obstinately.

Instead all is filled with and buried behind the jargon and lingo of cryptologists, i.e. logically secondary questions.

They don't even know how to manage the Size of the ever growing BTC blockchain in the future  
https://bitcointalk.org/index.php?topic=109467.0;all


Correct! That's also called "carry-over".

Carry-overs need just ONE entry to transfer the last balance of each account into a new database,
leaving all previous (thousands or millions!) transactions in an "archiv"
(where there can easily be found if really needed - normally almost never again).

Normally this year-end closing and "carry-overs" are done annually (and legally prescribed).

In BTC this could be done more often, i.e. always if there are "too many" transactions in the database making it too large for effective usage by clients.

Using this everywhere quite normal way of bookkeeping the actual "blockchain" could easily be kept small and handy and would not be bloated ad infinitum.

Impossible, complete nonsens, to keep all transfers over say 5, 10, 100, 200... years in ONE always transferred and read database.
But I see in BTC nowhere any usable solution for this from the very inception foreseeable issue.

For a correct and efficient GAAP-conform accounting only the (slightly changed) transaction records are needed
Details decribed here: https://bitcointalksearch.org/topic/btc-violates-gaap-result-a-mess-211835

"Blocks"

Another, but smaller problem are the "blocks" and their "miners" wanting more and more undefined amounts of money also for transactions.

First designed to produce new BTC the creation of blocks indeed is thought to continue ad infinitum!! Even if all 21 Mio BTC are created.
Might be due to the present but in the long run totally unusable database structure,
not easy but unavoidable to change!!

Well it is how bitcoin works, but if you consider making major changes anyway (I was referring to jtimon post) I think this should be changed too because it is not optimal system architecture.

What doesn't make sense?  Outputs and scripts is how bitcoin works.

You can simply use block number of last account operation. There is no way you get same sequence twice this way.

As for ledger vs. UXTO I think all this concept of outputs and scripts doesn't make sense and should be dropped and replaced with account balances and account types (EG. multisig accounts)

I got confused following your logic, but the conclusion is right. Miners must validate everything or the whole system falls apart.

As for ledger vs. UTXO, these UTXO indices give the advantages of a ledger (being able to look up final balances, for example), while maintaining an underlying block structure. But that connection to the underlying system is important - you still need it if you are going to create new transactions, for example. Does that make sense?

I'm really interested. If the indexes are enforced by the protocol I see no problem.


I don't understand.
If I validate the full chain leaving out the ones that nobody says still exist and only download the hashes of the transactions involved...
Never mind. Once a death asset appears with living assets in the same transaction you have also to validate the full asset, recursively.
So probably miners need to validate death assets anyway, am I thinking this straight or did I got lost on recursion?

Anyway, asking for the full proofs on the whole current UTXO would let you mine at level 1.

1) You ask for the longest header chain.

2) You ask for the UTXO

3) You ask for the full proofs of all outputs, not just yours. Maybe starting with yours.

4) Maybe in parallel, or only with wifi, or whatever, you download the whole chain from the in-chain signed torrent.
You validate everything until "your checkpoint" independenlty.

What happens when there's a reorg?

1) You change "your checkpoint" to the last common block so you ask for the that block's UTXO

2) You ask for the new UTXO at the top

3) You ask for the missing proofs you lack for the new UTXO.

Hummh, maybe GAAP is also better for reorgs...
And in fact I already solved the "immortal accounts" on the new Ripple forum by substituting the sequence number for the hash of the previous transaction from that account.
LvM is right, GAAP and a ledger instead of the UTXO like Ripple would make things much simpler.
Is there any obvious arguments in favor of the change-like design I am missing?
Is there anything that makes the UTXO cooler than a simple ledger?
Anyway, that's too big of a change, but since nobody answered in LvM's thread and I'm doubting...

Actually we should let gmaxwell respond to this, as I was really just relaying his concerns expressed to me at the conference. I think perhaps he is considering the case where the information is included in the bitcoin coinbase, but not actually enforced as a protocol rule?


True except for the miner part. You can fork the blockchain just as easily with invalid asset transactions.

@maaku, you said yesterday we left an open conversation more or less here:

maaku: Metachain miners could get lazy and not maintain the indexes properly.
jtimon: If the indexes are in the main chain there wouldn't be such a problem.
maaku: In the main chain the thing gets worse.
jtimon: How that's possible? blocks with wrong indexes will be orphaned.

Also, about socrates proposal. I think it's also useful for custom assets that can be issued, used and destroyed. New miners (or users) don't really care about these destroyed assets.

@LvM
I think the purpose of the "change" approach is to make obfuscation easier. You could do GAAP and maintain a sequence number for the transactions from each account like Ripple does.
You claim that would reduce the size of the chain by half. But how do you know how many keypairs will people create to obfuscate their finances?
Another problem is that you have to maintain a list of "existent accounts" forever. If miners forget about them and then the users uses it again (not a good idea on his part), the sequence for that keypair would be reset and anyone can "replay" the old transactions if he has them. That's why you can't destroy accounts (funded keypairs) in Ripple. You may say "there's no replay, all BTC funds will be gone". Well, I'm thinking about people reissuing custom assets from "resurrected" accounts.
Well, probably we should go to your thread to discuss this anyway...

The big value of validation-without-the-blockchain seems to me to be when it's combined with the fraud proof/challenge idea, where an SPV node can reject invalid blocks upon receiving a short proof or challenge that proves the block was formed incorrectly (e.g. nonexistent txin, double spend, invalid coinbase).   It turns out all important cases of fraudulently formed blocks can be covered by these - including cheating on the block reward, after a simple change to the way the Merkle trees are constructed.  This would greatly increase the trust model of an SPV node, under the assumption that it's connected to at least one well-connected, honest peer.

The more honest nodes there are auditing blocks and forming these fraud proofs/challenges, the better chance SPV nodes will promptly and reliably receive them.  This is where the validation-without-the-blockchain idea really shines IMO, since it allows resource constrained nodes to contribute to overall network security, but without biting off more than they can chew - they only partially validate blocks.  I tend to think of this as the "correct" way to preserve decentralization while scaling up block sizes.

@etotheipi:
Is it REALLY impossible for each client
"to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders."
...quickly and easily without your proposed complications with alt/meta-chains ?

I cannot believe that. If so, this seems besides the "Cash/Change" concept*) another remarkable bug at the lowest level.

*) CASH/CHANGE simulation vs. GAAP fundamentals
https://bitcointalksearch.org/topic/btc-violates-gaap-result-a-mess-211835

Sure, hardware wallets are an example. You could plug it in to an untrusted host computer that has already downloaded the proof data. Or even a mobile phone wallet, where you don't have much bandwidth during the day so it's SPV, but maybe it could sync up with the network overnight when it's around an untrusted wifi.