Can't Signatures Be Discarded After Confirmation?

[SapphireSpire]

To validate new transactions, nodes need to:
1. identify the path of the output being spent by each input (i.e. block:txid:vout),
2. locate the output in the blockchain,
3. check every input in every transaction in every block after to make sure it isn't already spent
   3a. if spent, skip sig verification and discard new transaction without propagation.
   3b. if not spent, verify signature.
      3b1. If sig fails, discard new transaction without propagation.
      3b2. If sig succeeds, propagate.

Once confirmed in a block, signatures don't need to be checked again, even by new nodes, so it doesn't need to be saved.
Blocks only need to save output data and the path of the spent output for each input.
The output paths of inputs cannot be substituted with hashes because collisions will invalidate legitimate outputs.

[stwenhao]

What if blocks only contain TXIDs instead of full transaction data?

You can do that now in your own node. Merkle tree is constructed in a way, where you can discard transaction data, and keep only transaction IDs, if you want to.

Also, if you want to keep track of the UTXO set, then you can keep just "txid:vout", to uniquely identify each unspent coin.

[SapphireSpire]

The Merkle tree permits pruning, but doesn't improve TPS. It requires you to download full transaction data before pruning which is a waste of bandwidth. And VOUT is just an index value. OGH is a checksum.

[stwenhao]

The Merkle tree permits pruning, but doesn't improve TPS.

If you want to improve TPS, then you have to combine N transactions into a single one, which would be smaller, and which would do the same thing, as uncompressed version would do. Some example: https://bitcointalk.org/index.php?topic=281848.0

It requires you to download full transaction data before pruning which is a waste of bandwidth.

That's why many scaling solutions are focused on pushing off-chain things, which are currently on-chain. If you have sidechains, you download only the end result, not all sidechain-related transactions during Initial Blockchain Download. The same with Lightning Network. And the same with cut-through.

If you want to change the format of things on-chain instead, then of course you can, but then, only nodes running your code will enforce such changes. For example: you can have a node, which will keep only transaction IDs, and nothing else. It will work, and it will be compatible with the rest of the network, because then you will build all merkle trees in the same way, as other nodes. Also, you can attach "output group hash" or whatever, but only your nodes will be aware of it, and only your nodes will validate it, the rest of the network will just never hear that kind of traffic at all.

And VOUT is just an index value. OGH is a checksum.

Well, you can try to skip storing VOUT, but in many models, it is easier to keep it. But yes, if data behind OGH will contain it, then you can keep only transaction IDs, and check indexes later. However, in that case, you probably wouldn't need transaction IDs, if all data behind OGH will have everything you need.

[ABCbits]

Is it right to assume full node still need to store whole TX data or partial TX data (ones that contain UTXO) in order to verify all newer TX and block?

[stwenhao]

Is it right to assume full node still need to store whole TX data or partial TX data (ones that contain UTXO) in order to verify all newer TX and block?

No. You can check less things, than existing nodes, and stay compatible with the rest of the network. For example: if some client would handle only P2PK, and would mark everything else as valid, then it would successfully synchronize the whole chain. The same is true for a client, which would check the correctness of the merkle tree construction, without checking any underlying transaction data.

Also, you don't need the full UTXO set to check, if new blocks are valid or not. Instead, clients could require ZK-proofs for each transaction input, and never store the history, but only the proof, that it is correct. Which means, that the full chain is required only in the current full node implementation, and it can be changed in the future.

The same is true about data compression: if you have weak public key, which is reused hundreds of times, then you don't have to send it over and over again. The protocol does not require anyone to do anything like that. The whole historical chain can for example be passed in much more compressed form than today, and such nodes can stay compatible with existing ones.

An extreme example is header-only client: you can trace only block headers, and not much more than that. Then, everything else you can handle through ZK-proofs or other kind of proofs, and still check, if new blocks are valid or not. Maybe even going further is possible, but each proof comes with some cryptographic assumptions, so storing all headers is highly recommended, as long as we don't have many billions of blocks.

So, to sum up: things can be simplified in future versions, without affecting existing implementations. Then, current node runners can still process and store hundreds of gigabytes, while new, more lightweight nodes can be set up successfully, and be more resistant to spam, or allow processing more transactions per second, while being compatible with the rest of the network.

[Jibdeen]

Is it right to assume full node still need to store whole TX data or partial TX data (ones that contain UTXO) in order to verify all newer TX and block?

No. You can check less things, than existing nodes, and stay compatible with the rest of the network. For example: if some client would handle only P2PK, and would mark everything else as valid, then it would successfully synchronize the whole chain. The same is true for a client, which would check the correctness of the merkle tree construction, without checking any underlying transaction data.

Also, you don't need the full UTXO set to check, if new blocks are valid or not. Instead, clients could require ZK-proofs for each transaction input, and never store the history, but only the proof, that it is correct. Which means, that the full chain is required only in the current full node implementation, and it can be changed in the future.

The same is true about data compression: if you have weak public key, which is reused hundreds of times, then you don't have to send it over and over again. The protocol does not require anyone to do anything like that. The whole historical chain can for example be passed in much more compressed form than today, and such nodes can stay compatible with existing ones.

An extreme example is header-only client: you can trace only block headers, and not much more than that. Then, everything else you can handle through ZK-proofs or other kind of proofs, and still check, if new blocks are valid or not. Maybe even going further is possible, but each proof comes with some cryptographic assumptions, so storing all headers is highly recommended, as long as we don't have many billions of blocks.

So, to sum up: things can be simplified in future versions, without affecting existing implementations. Then, current node runners can still process and store hundreds of gigabytes, while new, more lightweight nodes can be set up successfully, and be more resistant to spam, or allow processing more transactions per second, while being compatible with the rest of the network.

This highlight the reasons why future blockchain nodes needs to operate without full storage of transactions history data.
I’m currently on a research to know how these innnovations could pave way for higher transactions and more adaptation of blockchain technology.
I found this article helpful

[stwenhao]

Can't Signatures Be Discarded After Confirmation?

No, because then, miners could steal it.

Once confirmed in a block, signatures don't need to be checked again, even by new nodes, so it doesn't need to be saved.

Imagine you have two groups of nodes: one, which confirmed Alice->Bob transaction in their chain, and another, which confirmed Alice->Charlie transaction in their chain. You have no access to any signatures, because they are discarded immediately. How do you know, which transaction is the real one? If you trust, that miners will never steal anything, and that signatures are not needed, then you don't have to use public key cryptography at all.

For example: you can lock your outputs on "OP_SIZE 32 OP_EQUALVERIFY OP_RIPEMD160 <yourHash> OP_EQUAL". Then, your private key is just a single 32-byte data push. No user will be able to move it upfront, because nobody would know the hash. And if you have existing public keys, then you can easily reuse them, by applying SHA-256 on them, and using that result as your private key.

So, you can already deploy your system on top of Bitcoin, or some test network, and see, how many coins will be stolen. Because nobody forces you to use OP_CHECKSIG, you can use any scripts without it, and that would also work.

[pooya87]

Once confirmed in a block, signatures don't need to be checked again, even by new nodes, so it doesn't need to be saved.

What you are describing can be dome but that contradicts the trustless principle of Bitcoin.

In Bitcoin the idea is that a full node only trusts itself so it verifies everything, that includes signature verification. If you just trust the other nodes and PoW, then you can no longer call your client a full [verifying] node and you might as well run a SPV client (eg. Electrum) which is so much easier to sync and consumes less bandwidth and disk space.

[SapphireSpire]

I'm not saying we stop checking signatures. Only that they not be include in blocks, to save space. Signatures are big and excluding them would save a lot of space. The next block is only valid if it respects original transaction data, which nodes still have in their mempools, so I don't see how miners can steal anything. New nodes, or nodes that have been offline for a while, would only need to trust that the tip of the blockchain is as good without signatures as it is now, which it would be because the confirmation process isn't changed.

[stwenhao]

Only that they not be include in blocks, to save space.

From the perspective of legacy node, Segwit doesn't exist. Which means, that you can strip all signatures from your own node, and stay on the same chain, but then, nobody would be able to sync his node through your connection (except also those, who will decide to trust you, and never check any signatures).

Signatures are big and excluding them would save a lot of space.

And it will require trusting, that all historical nodes processed the history correctly.

The next block is only valid if it respects original transaction data, which nodes still have in their mempools, so I don't see how miners can steal anything.

Because if you use legacy node, then it can potentially accept a block, which would spend Segwit inputs unconditionally. And the same is true for a node, which would strip signatures: it would accept a chain with Proof of Work, which would contain transactions without any signatures, moving coins, which never should be allowed to move from particular inputs.

New nodes, or nodes that have been offline for a while, would only need to trust that the tip of the blockchain is as good without signatures as it is now

And that assumption is quite big. Because then, why strip only signatures? You can strip much more. You can have transactions like that:

Code:

+--------------------------------------------------------------------+
| bc1pfeessrawgf   0.00000000 BTC -> bc1pfeessrawgf   0.00000000 BTC |
| bc1pfeessrawgf   0.00000000 BTC    bc1pfeessrawgf   0.00000000 BTC |
| bc1pfeessrawgf   0.00000000 BTC                                    |
+--------------------------------------------------------------------+

Because if you don't care about signatures, then why should you care about addresses and amounts? You can strip them too!

And then, address types, coin amounts, and many other things, can be put in a separate space, called "commitment space" or whatever, so your node could drop it instantly after checking.

[NotATether]

I'm not saying we stop checking signatures. Only that they not be include in blocks, to save space. Signatures are big and excluding them would save a lot of space. The next block is only valid if it respects original transaction data, which nodes still have in their mempools, so I don't see how miners can steal anything. New nodes, or nodes that have been offline for a while, would only need to trust that the tip of the blockchain is as good without signatures as it is now, which it would be because the confirmation process isn't changed.

There is an argument to be made that stripping signatures would make the transactions themselves impossible to verify, and would force software applications to collect entire blocks and verify those.

Storing the signatures ensures that nobody can find a vulnerability to manipulate the monetary supply in a way that other people cannot detect.

[gmaxwell]

Pruning already implements the subset of what you're thinking that isn't incompatible with the security model of bitcoin.