please delete

[SapphireSpire]

nothing to see

[Evil-Knievel]

Well, you could do that for yourself.

The tx referenced by that tx is just old data that nobody really needs

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"?

[target]

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

Well, you could do that for yourself.

The tx referenced by that tx is just old data that nobody really needs

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"?

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.

[HeRetiK]

When a new transaction is being verified, is it sufficient to only check the transactions referenced by the inputs or is it necessary to check the entire chain of transaction going all the way back to the genesis block?

[...]

The utx is only referencing the previous tx. The tx referenced by that tx is just old data that nobody really needs, especially if it's contained in a block on the main chain, i.e. there are no competing branches.

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

[HeRetiK]

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

Miners are aware of all competing branches because they sometimes have to stop mining on one and start mining on another when it becomes the longest branch.

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).

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).

Deleting old unnecessary transactions doesn't change the security scheme. It's the blockchain that secures transactions, not the other way around.

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.

[HeRetiK]

Deleting old unnecessary transaction requires deleting old "unnecessary" blocks

It permits blocks to be deleted, it doesn't require it.

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

a shorter blockchain is significantly easier to attack than a full blockchain.

Length only matters when resolving branches. The main chain is secured, not by it's length but, by the total hash rate of the network.

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.

you can't delete singular transactions from a block without invalidating the whole block

You can when the block is already on the blockchain. The only reason to retain old transaction data is to be able to reproduce the Merkle root but there's no reason to reproduce the Merkle root.

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.

[...]

However, like you pointed out, a lot of old unspent transactions will never be spent. In order to keep the blockchain size small and portable, it's necessary to limit it's length and that means blocks have to be deleted after a certain period of time- i.e they have to expire. Of course that puts the oldest unspent transactions at risk but, knowing this, every user will have to make it a top priority to recycle their coins before they expire and wallet apps will do this automatically as long as they're running and connected to the network. That encourages users to stay connected which helps keep the network strong.

At this point you only know some idiots are going to lose their coins despite all warnings and advice. That's deflationary so, in order to maintain a target supply of coins, the block reward should increase to compensate. This creates a more useful and sustainable coin, don't you think?

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.

[Kallisteiros]

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.

[bob123]

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.

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.

[Kallisteiros]

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.

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.

[bob123]

But you have ways to verify this information to be correct. SPV wallet doesn't just trust whatever data is sent its way.

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).

[gmaxwell]

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.

[Kallisteiros]

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

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.

[TheArchaeologist]

When a new transaction is being verified, is it sufficient to only check the transactions referenced by the inputs or is it necessary to check the entire chain of transaction going all the way back to the genesis block?

If it's sufficient to only check the referenced transactions, would it not be a problem then to delete older transaction data that is no longer referenced by the inputs of unspent transactions? For example:

tx <-- tx <-- utx

tx = spent transaction
utx = unspent transaction

The utx is only referencing the previous tx. The tx referenced by that tx is just old data that nobody really needs

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.