Ultimate blockchain compression w/ trust-free lite nodes

[aaaxn]

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

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.

[1714039862]

1714039862

[1714039862]

1714039862

[1714039862]

1714039862

[LvM]

I think its important that everybody understand this and I didn't see anyone explaining it in general terms.

The Blockchain is a distributed computer file system containing a double entry accounting ledger. Each transaction has two sides which you may be familiar with from accounting: input and output OR debits and credits. However, a major difference is that bitcoin forces a debit(input) to exist for every credit(output).  Storing all of this takes a lot of space. extra explaination

This proposal will continously "balance the books." In accounting, when you close out the books for the quarter all of the debits and credits are summed, and the difference between the two is entered as a "balance" transaction. Because we know that bitcoin forces every credit(output) to have a debit(input), we only have to keep track of all credits(outputs) that are not claimed by a debit(input) to obtain the balance of each address.

The proposal is for a system to store the references to these unspent outputs in a data structure for quick downloading. It doesn't suggest how this tree would be updated efficiently, or how you would quickly grab all of the unspent outputs belonging to one address. This is under discussion.

@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

In accounting, when you close out the books for the quarter all of the debits and credits are summed, and the difference between the two is entered as a "balance" transaction.

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://bitcointalk.org/index.php?topic=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!!

[LvM]

@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

[LvM]

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.

[maaku]

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.

[LvM]

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.

@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]

@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!

[Pieter Wuille]

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.

[Sukrim]

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.

[aaaxn]

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.

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

[LvM]

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.

@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 !!

[Pieter Wuille]

I completely disagree.

Yes, Bitcoin is exactly the same as other currencies in this respect. But we don't track serial numbers of dollar bills we get, do we? So why would we do accounting based on the currency?

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".

[aaaxn]

I completely disagree.

Yes, Bitcoin is exactly the same as other currencies in this respect. But we don't track serial numbers of dollar bills we get, do we? So why would we do accounting based on the currency?

Gold coin doesn't need serial number, does it?

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".

So why exactly simulate things that nobody cares about?

[maaku]

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".

So why exactly simulate things that nobody cares about?

That may be a valid discussion to have. But it's best done elsewhere: we are now very off topic.

[LvM]

@maaku: We are not "off topic" at all.
Proposed workarounds are the place to discuss the reasons for their (wrongly assumed) necessity.

[LvM]

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

[aaaxn]

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

I think it is pointless trying to convince fellow bitcoiners that their baby is poorly designed. Maybe you should support one of alt coins which plans to do exactly as you say?

https://bitcointalk.org/index.php?topic=195275.0
or
https://bitcointalk.org/index.php?topic=169204.0

[LvM]

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

I think it is pointless trying to convince fellow bitcoiners that their baby is poorly designed. Maybe you should support one of alt coins which plans to do exactly as you say?

https://bitcointalk.org/index.php?topic=195275.0
or
https://bitcointalk.org/index.php?topic=169204.0

@aaaxn
Thank you! Will check it when my time allows.

[jtimon]

While still talking about the ledger vs UTXO, I'll try to stay close to the context of this proposal, maybe the ones that prefer a ledger can be statisfied with little changes.
Let's try.
Let's look, for example, at this transaction: http://cryptocoinexplorer.com:4750/tx/8b1afc9aa2ca96c846dce3a47d577068e5f722961eff036b5792756eef28e2a0
The full public key of 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd and the signature is repeated in this transaction, isn't it?
We can modify the UTXO dictionary to avoid this redundancy.

The UTXO dictionary stores (scriptPubKey, balance)

But if he stored a ledger (address/scriptPubKey, balance), you would only need to sign once for 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd in the tx above.
Note that I'm considering an UTXO enforced by the chain and not an altchain.
The "default script" of just showing the public key

Code:

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Could be assumed and ommitted, replaced by this:

Code:

scriptPubKey: <pubKeyHash>
scriptSig: <sig> <pubKey>

But then you would need to indicate explicitly how much you want to spend from the address in the input.
The transaction above would not have had to reference each input individually, it would only have included the address, an amount to substract, the public key and signature. Well, and the sequence number or equivalent for that address. I prefer a hash of the last transaction spending from that address. Otherwise you need to remember empty addresses ast sequence numbers forever.

Basically, this (paying to an address substracting from another address) would be the general case and the "pay to script" or contract, would be the special case. I think Ripple must do something like this for their ledger and their contract scripts.

Does this make technical sense before we start discussing whether a currency is in itself an accounting system and other philosophical matters?

[etotheipi]

While still talking about the ledger vs UTXO, I'll try to stay close to the context of this proposal, maybe the ones that prefer a ledger can be statisfied with little changes.
Let's try.
Let's look, for example, at this transaction: http://cryptocoinexplorer.com:4750/tx/8b1afc9aa2ca96c846dce3a47d577068e5f722961eff036b5792756eef28e2a0
The full public key of 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd and the signature is repeated in this transaction, isn't it?
We can modify the UTXO dictionary to avoid this redundancy.

The UTXO dictionary stores (scriptPubKey, balance)

But if he stored a ledger (address/scriptPubKey, balance), you would only need to sign once for 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd in the tx above.
Note that I'm considering an UTXO enforced by the chain and not an altchain.
The "default script" of just showing the public key

Code:

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Could be assumed and ommitted, replaced by this:

Code:

scriptPubKey: <pubKeyHash>
scriptSig: <sig> <pubKey>

But then you would need to indicate explicitly how much you want to spend from the address in the input.
The transaction above would not have had to reference each input individually, it would only have included the address, an amount to substract, the public key and signature. Well, and the sequence number or equivalent for that address. I prefer a hash of the last transaction spending from that address. Otherwise you need to remember empty addresses ast sequence numbers forever.

Basically, this (paying to an address substracting from another address) would be the general case and the "pay to script" or contract, would be the special case. I think Ripple must do something like this for their ledger and their contract scripts.

Does this make technical sense before we start discussing whether a currency is in itself an accounting system and other philosophical matters?

I was a little conflicted on this topic.  I see the "elegance" of just using raw scripts.  But I didn't like the idea that multiple forms of the same "effective" address required separate lookups.  For instance, the same address can be used in the "DUP HASH160 <Addr160> EQUAL CHECKSIG" as well as "<PubKey> CHECKSIG".  And maybe "<message> DROP <pubKey> CHECKSIG".  Or "<message> DROP DUP HASH <Addr160> EQUAL CHECKSIG".  In fact, I don't even have a good way to go search for those message scripts unless I know the message in advance.  It would require a good old-fashioned full-UTXO-set-search, which was something we were hoping to avoid with this whole discussion.

But it's also not feasible to capture all script types that are single-sig spendable.  Adding new "standard" script type representations to the UTXO tree later will require a hard-fork.  Perhaps this is a reason not to have things like "<message> OP_DROP", or it's a reason to be more intelligent about how we represent scripts in this tree.  This is why I was conflicted...