Topic: please delete (Read 384 times)

That's exactly how things are currently working when running a full node. All unspent outputs are stored in the chainstate once an output is spent it's removed from the chainstate. This basically means when trying to spent an output from an earlier transaction a check will be done on the chainstate to see if it is indeed unspent.

That being said I don't agree with you stating unspent transactions are just old data nobody needs. Sure they might not be needed for validating anymore but they still are needed for example to be able to get an overview of all transactions to and from an address.

Right, but those were mostly edge cases and implementation issues, or require spending lots of hash power and Sybil constructions in order to deceive SPV, which is not practical for most purposes. I was just answering OP's question in terms of SPV concept itself. If we find probabilistic SPV security to be acceptable, we don't *have* to check *any* inputs for validity either, if they were included in the block that is built upon many times by others. Although I do agree with you that only the fully validating node can provide the best level of guarantees, if you require it. Even then, gmaxwell just explained that full nodes don't have to store any transactions except UTXO, even their inputs. Makes sense.

Nodes already know the prior transactions were valid they don't need to check them again.  They just need to track the currently unspent outputs, just as you are thinking.

The Bitcoin software can run with pruning that makes it forget old transactions.  With pruning the security and behavior is generally indistinguishable from other nodes-- but when running in that mode your node just can't help new nodes come up because they need to see the history and you don't have it.

See also Section 7 of the Bitcoin whitepaper.

While this might be correct, you still need to trust the client and server to show you correct information.
With a non-malicious full node you can always be sure to have the correct information, since you are directly attached to the bitcoin network itself.

There are multiple attacks on SPV clients possible which do not work for full nodes (by design).

But you have ways to verify this information to be correct. SPV wallet doesn't just trust whatever data is sent its way. It verifies the merkle path of the transactions it cares about, the block headers back to genesis, the proof of work on each block, etc. And while the full node would have completely verified the whole chain of inputs back to the coinbase, SPV wallet doesn't have to dig too deep, by reasoning that if the block has been built upon by other miners several times, it's valid, your transaction inside the block is valid as well. You don't really need to follow the history of your transaction inputs.

SPV wallets just descibes a type of wallets where no full blockchain is needed to be stored locally.
These SPV wallets (also called 'lightweight clients') rely on an online server to retrieve information about blocks/transactions and do only download certain parts of the blocks (block header).

It is a handy way to use a wallet without having to sync the blockchain each time. But you are trusting a server to give you correct information regarding your transaction/addresses.
Additionally your privacy is being compromised since your IP will only 'forward' your transactions, while with a full node client you are relaying thousands of transactions a day where those from you won't stand out.

Both have its pros and cons.

You can kinda infer security from the fact that if a transaction was included in the blockchain, and enough blocks are built on top of that, then the conclusion is that it had to be valid, otherwise miners wouldn't bother spending so much electricity mining the chain that the network of fully validating nodes would reject. But this is game theory based conclusion, not a 100% guarantee. I think SPV wallets do that.

Same difference. You can't delete a transaction without deleting its block and vice versa.



A blockchain is secured by both its length and the total hash rate of the network. Otherwise you wouldn't have a difference in security between 1 confirmation and 100 confirmations.




I might be wrong, but if I recall correctly you need to reproduce the Merkle root when validating a block. Problem being, when a block is invalid, each subsequent block in the blockchain is invalid as well.



I respectfully disagree -- I personally definitely would neither like to see (1) bitcoins with expiration dates and (2) a change of the coin supply.

In my opinion both would be a violation of what everyone signed up for when buying into Bitcoin. To add to that, expiration dates would hinder people and exchanges to store their coins safely (ie. in cold storage) and add unnecessary network load by forcing people to send their coins to new addresses on a regular basis. Especially the latter would get worse over time as the userbase holding "old" coins increases and more users have to "recycle" their coins. Sooner or later you'd reach a point where the recycling transactions alone would already fill up block after block, as all of these transaction would have to take place on-chain.

So no, I don't think so. I guess it would make for an interesting alt though -- at least for an observer, without any actual skin in the game.

Nodes (usually) don't keep copies of multiple, ie. competing blockchain states. If that were the case every single node would also propagate multiple competing blockchain states. This means that in case of an impending chain split (or orphaned branch) each different node stores a different blockchain state. It is only after one chain has become longer than the other that the nodes that used to follow the now orphaned branch are acknowledging the differing version of history and reorganize their blockchain state accordingly.

And that's ignoring cases where competing branches may be intentionally withheld (ie. selfish mining).



Deleting old unnecessary transaction requires deleting old "unnecessary" blocks leading to a shorter blockchain that is significantly easier to attack than a full blockchain.

Additionally, and more importantly, you have the problem of old coins that haven't been moved since the early days. Since you can't delete singular transactions from a block without invalidating the whole block, even following the proposal of keeping only the latest movement of a coin you still have to keep every block until the youngest block with the oldest unspent transaction -- which happens to be the Genesis block, I'm afraid.

Looking at the way Bitcoin transactions work this approach comes with the following problems:

1) Nodes only know in hindsight that there were competing branches.

2) Your whole security scheme would now hinge on a single block (ie. the one containing the most recent transaction of a particular set of coins). If you can't trace a coin back to its coinbase transaction you can't verify whether it has been mined or falsely conjured out of thin air.


In other words, applying this concept on Bitcoin would result in a loss of both security and reliability. You may be interested in MimbleWimble's Cut-throughs [1], however. MimbleWimble has supposedly found a way to securely get rid of intermediate, historic transactions that are no longer needed. This is enabled however by a transaction concept that is vastly different from Bitcoin -- and any other alt, for that matter (at least as far as I'm aware of, if there are other alts applying this method I'd love to hear about them).

[1] https://github.com/mimblewimble/grin/blob/master/doc/intro.md

If you just have to check a particular transaction then you can just check the tx of transactions referenced.


True. The sync would take forever if you delete anything.
As far as I know, if you have to edit or delete something in the blockhain, all the rest after it are going to be broken that the network has to re-mine the rest to rearrange the hashes again.

Well, you could do that for yourself.


Well, I wouldn't say nobody needs that information. Even you would need that information when you sync/catch up your Blockchain. How else would you verify that the inputs in a "unspent transaction" (i assume you mean a transaction with at least one unspent output here) actually belong to a valid old "spent transaction" if you never receive this "old unuseful data"?

nothing to see