Why does store all inputs and outputs, instead of “account/balance” ledger?

[ranger.shi]

Why does Bitcoin store all transaction inputs and outputs, instead of just an “account/balance” ledger?
I think ,that will reduce the blocksize very much.
and reduce the program diffcluty.
at the same time it is easy to protect the block chain

but why not?

[bornil267645]

it's might make it simpler but there has to be a explanation otherwise they would've done it already.

[ranger.shi]

it's might make it simpler but there has to be a explanation otherwise they would've done it already.

I don't think have any explanation .
I have researched  bitcoin code for a long time, I sure that  is safe.
Is anything i don't kown?

[giszmo]

outputs are well defined with an amount. addresses are rather implicit and depend on the ordering of transactions to get an implicit balance. As transactions are only ordered by a miner, things are stricter if you spend from outputs rather than from addresses.

Also in the original concept address reuse was not really a big thing, so it wouldn't matter if you spend from the one output or from the address, so the blockchain should not really be smaller or bigger with such a scheme.

[ranger.shi]

outputs are well defined with an amount. addresses are rather implicit and depend on the ordering of transactions to get an implicit balance. As transactions are only ordered by a miner, things are stricter if you spend from outputs rather than from addresses.

Also in the original concept address reuse was not really a big thing, so it wouldn't matter if you spend from the one output or from the address, so the blockchain should not really be smaller or bigger with such a scheme.

is any explanation with the scheme?  
I want to design a altcoin , one function have to use this scheme, I am afraid of safe case, but current I can not find any leaks  ....

[ranger.shi]

Is any one can help me?

[Relnarien]

Why does Bitcoin store all transaction inputs and outputs, instead of just an “account/balance” ledger?
I think ,that will reduce the blocksize very much.
and reduce the program diffcluty.
at the same time it is easy to protect the block chain

but why not?

It will not make the blockchain smaller. In fact, it will make it much larger. There are 2^160 possible Bitcoin addresses, which means that keeping an account database rather than an account ledger would require maintaining an accurate representation of the balance contained in 2^160 Bitcoin addresses. If you do that per block, then you would need stacks of servers just to keep the blockchain running. It is also not secure to store exact balances instead of input-output transactions because it would be difficult, if not impossible, to verify if the indicated balance was maliciously altered.

[Dabs]

Transactions contain the details about the "accounts" and if you add them all up, you get the "balance" of whatever addresses you are looking at.

[kjj]

Imagine a global account and balance ledger...

Now imagine the ledger changing as a batch of transactions are confirmed.  You need to ship the new ledger to thousands of nodes on the internet.  How do you do it?

Option 1 is to transfer the new ledger intact.  This can be push or pull, but it needs to flood the network.  I hope it isn't necessary to explain what's wrong with option 1.

Option 2 is to create some sort of delta or diff.  This is what we actually do.  The blockchain is just a list of diffs starting from an empty ledger and ending with the current state.

[ranger.shi]

Imagine a global account and balance ledger...

Now imagine the ledger changing as a batch of transactions are confirmed.  You need to ship the new ledger to thousands of nodes on the internet.  How do you do it?

Option 1 is to transfer the new ledger intact.  This can be push or pull, but it needs to flood the network.  I hope it isn't necessary to explain what's wrong with option 1.

Option 2 is to create some sort of delta or diff.  This is what we actually do.  The blockchain is just a list of diffs starting from an empty ledger and ending with the current state.

we only transfer a batch of transactions which in a block,all nodes will verify the  block and update related all account view, just like bitcoin.
maybe you will think account view will very large, in fact  coin view in bitcoin have the same problem ,
on the other way system can gather same fees to control the account total munber.

[Sergio_Demian_Lerner]

My best guess is that Satoshi preferred the input/output model because it makes very easy preventing transaction spam on the network (before inclusion into the blockchain).

When you adopt the account/balance model, you must choose one of the following design decisions to be able to detect double-spends (which can be used to DoS the network):

1. Require transactions to include a proof-of-work
2. Predict the balance of each account every time you receive a transaction
3. Reduce the block interval to a value so small that allowing a single transaction per block is enough for the user (e.g. 5 seconds). Then you forward a single transaction per account between blocks.

There are surely more solutions, but probably more complicated.

The simplest solution (for a 10 minute block interval) is the one Satoshi choose, because it does not require additional temporary data structures.

Sergio.

[kjj]

Using a nonce has problems in a global system.

[gmaxwell]

First, the entire privacy model for Bitcoin is predicated on users not reusing keys. Without that, bitcoin is obscenely non-private, and gravely disadvantaged compared to any other store of value or transaction system in wide use.  This alone immediately would destroy any value an 'account' system would have, and so you can basically stop at this point and think no more.

Though there are other reasons, beyond the increased difficulty of evaluating zeroconf transactions Sergio mentioned above—

Then the account model has major problems with corner cases... e.g. You have problems with determinism in conflict situations:  e.g. Alice has 2 BTC and pays Bob 0.9 BTC, then Alice pays Carol 1 BTC.  Later Bob gets angry the transaction hasn't confirmed and demands Alice reissue with a fee. Alice does but then Bob gets paid twice and Carol not at all.

Even just anti-replay you need an random access lookup to see if the nonce has been used already, and the nonce is per input if you ar eto have conflict control. You have more data (the list of nonces) is unprunable (or difficult to make prunable)... and so any space you saved by not having extra outputs is lost in abundance by having to store nonces forever— even after an account goes to zero value, since if it were funded again someone could replay a years old spend— once the spending actually does happen.

In short, account like setups _seem_ simpler and more intuitive, but they have ugly edge conditions that are difficult to get right and create overhead that wipes out the possible gains. When you consider that the privacy model precludes that kind of use in any case, there really is no upside and a lot of downside.

[Dabs]

Some donation addresses are constantly re-used, as well as some game addresses, like dice.

But with all the transactions coming into those addresses and going out, doesn't that sort of "mix" who did what, and some times you can even claim you had no direct link to them as someone else did it and paid you after, or something.

And then there are those who do the Coin Join thing, or the Shared Send.

And then there is that "trusted escrow/mixer/tumbler" who combines a bunch of unspent outputs into one, then splits it out later.

I think it is a good idea to almost always include the minimum transaction fee, even if it is not requested or required by the bitcoin client.

[jl2012]

My best guess is that Satoshi preferred the input/output model because it makes very easy preventing transaction spam on the network (before inclusion into the blockchain).

When you adopt the account/balance model, you must choose one of the following design decisions to be able to detect double-spends (which can be used to DoS the network):

1. Require transactions to include a proof-of-work
2. Predict the balance of each account every time you receive a transaction
3. Reduce the block interval to a value so small that allowing a single transaction per block is enough for the user (e.g. 5 seconds). Then you forward a single transaction per account between blocks.

There are surely more solutions, but probably more complicated.

The simplest solution (for a 10 minute block interval) is the one Satoshi choose, because it does not require additional temporary data structures.

Sergio.

Just using an incrementing nonce for each account is sufficient to solve the issue.

Not so simple. All full nodes have to keep the nonce of all addresses, even for those with zero balance. No pruning is possible.

[ilpirata79]

This could be easily "done".

It is like keeping only the unspent outputs.

The problem is the trust. How can you be sure that the ledger that is being sent to you is the correct one?

That is because all the blockchains with all the transactions and hashes is needed.

Best regards,
ilpirata79