please delete

[SapphireSpire]

nothing to see here

[1715132086]

1715132086

[1715132086]

1715132086

[1715132086]

1715132086

[NeuroticFish]

The general idea here is to keep the blockchain as lean as possible by offloading as much data as possible without compromising security.

By storing our transaction details in our wallets instead of the blockchain, it would shrink the size of the blockchain and reduce its rate of growth.  To create new transactions, we include the details of the transactions we're spending, which can then be easily checked against the hashes in the blockchain.  There's no way to know exactly how much space this would save because transaction size varies, but I believe it would be huge.

The only issue I can imagine is the possibility of brute-forcing a valid transaction from a confirmed hash.  I have no idea how long that would take, but I can't imagine anyone doing it on modern hardware within a reasonable time frame.  But, just in case, we could generate two hashes for each transaction using two different hashing algorithms. It might be easy for someone to brute-force one hash or the other, but not both at once.  This would make the blockchain larger than having just one hash, but still much smaller than it is now.

1. This will make the wallets big.
2. This will make the wallets irreplaceable and unrecoverable. If somebody has lost his wallet he will not be able to recover from seed or private key.
3. Malicious actors will have more tools to try to tamper the data (i.e. forge wallets)
4. This is not backwards compatible, hence all the old bitcoiners (and collectors) who don't have the transactions in their wallets will lose any chance to spend their funds.

Is it me, or this creates way more problems than it would solve?
Plus, the size of the blockchain is not a real problem. You can get a big enough HDD for under 50$.

[PrimeNumber7]

Nodes can already disregard blocks that are more than x blocks deep. All that these nodes need to store is the UTXO set and the last x blocks.

the TXID itself does not allow for nodes to validate that the transaction is valid. I am also unaware of any way that a node would be able to update the UTXO set based on the various TXIDs of transactions included in a found block.

[hosseinimr93]

If you only store transactions hashes and you don't have database of all UTXOs, it won't be possible to verify the transactions that will be made in the future.
There is no way to derive the transactions details and UTXOs from the transaction hashes and the hashes you store are completely useless.

If you want to store smaller size of data, you can run a prune node. If pruning is enabled, old blocks are removed, so you don't require a big space for storage.
I think in this way you even store a smaller size of data than your proposal. Because, you store nothing from fully-spent transactions.

[hosseinimr93]

It doesn't invalidate older transactions, how is it incompatible.

The question is how you will be able to verify the transactions that will be made in the future. That's one of the main purposes of keeping a copy of blockchain.
For validating the future transactions, you need database of all UTXOs and they can't be derived from transaction hashes you have stored.

[NeuroticFish]

but the solution is the same- backup your wallet.
[~snip~]
It doesn't invalidate older transactions, how is it incompatible.

I have no backups of any wallet. I have only HD seed backed up from my hardware wallet. That can get me addresses and private keys, but I expect the transactions info come from the blockchain.
So I see it as incompatible with the current use of wallets for many of us.

What data is anyone going to tamper with?

If the transactions are in the wallet, if the number of coins of the transactions is in the wallet instead of many copies in the world, somebody may find a way to move things around and steal some money keeping the hash "seal" intact.


hosseinimr93 also had a very good point. The blockchain is supposed to store data, not hashes (i.e. only the seals for the data). A node, a miner, (an Electrum server, a block explorer) name it, will need to validate or see all the transactions for everybody, not only for his own wallet, so he will have to store all the data for all wallets without actually knowing them. So, in a way or another, they will still need to keep the whole blockchain. so your solution doesn't solve anything global. It may solve a local problem for a few users who don't want to buy a HDD and don't want to use pruned node, but with the cost of creating other problems.

[hosseinimr93]

But pruned nodes are unable to validate transactions.  The network benefits more from full nodes.

This is wrong.
Prune nodes validate every block and transaction they receive.

When a new transaction is created, it would include the details of the transactions it spends. All nodes would be able to see these details in the mempool and can validate them from there.  Once confirmed, the found block would only contain their txids, and it would be your choice whether to save or discard the details.  

This is not possible.
In this way, the node that wants to validate the transaction doesn't know whether the coin exists or not. The node doesn't know whether the coin has been spent before or not.
For validating the transactions, nodes need the full database of UTXOs.

[pooya87]

You can not reduce the blockchain size by getting rid of necessary data, you can only reduce the size by getting rid of data that is not necessary. For example the encoding used in the transactions could be changed (locally) to get rid of some bytes in each transaction like using a 1 byte tx version instead of 4. Anything more than that and you would be running a pruned node.

[NotATether]

In the interest of keeping the blockchain as small as possible, we should offload as much data as possible without compromising security.  I don't see any reason to store transaction details on the blockchain.  By storing transaction details in our wallets instead, it would shrink the size of the blockchain and reduce its rate of growth.

If the transactions are stored only in wallets, then they will be lost when someone moves between wallets, and inaccessible to people who don't have the wallet.

You can not reduce the blockchain size by getting rid of necessary data, you can only reduce the size by getting rid of data that is not necessary. For example the encoding used in the transactions could be changed (locally) to get rid of some bytes in each transaction like using a 1 byte tx version instead of 4. Anything more than that and you would be running a pruned node.

This can't be done either because it would definitely be a hardfork.

[ABCbits]

You can not reduce the blockchain size by getting rid of necessary data, you can only reduce the size by getting rid of data that is not necessary. For example the encoding used in the transactions could be changed (locally) to get rid of some bytes in each transaction like using a 1 byte tx version instead of 4. Anything more than that and you would be running a pruned node.

This can't be done either because it would definitely be a hardfork.

Not if the modification is only used to store the blockchain locally. The node software could reconstruct the data (e.g. decompress or add zero padding as needed) before sending it to another node.

[pooya87]

You can not reduce the blockchain size by getting rid of necessary data, you can only reduce the size by getting rid of data that is not necessary. For example the encoding used in the transactions could be changed (locally) to get rid of some bytes in each transaction like using a 1 byte tx version instead of 4. Anything more than that and you would be running a pruned node.

This can't be done either because it would definitely be a hardfork.

That is why I mentioned "locally" meaning such changes don't need to happen at the protocol level, only your software changing how it stores things. For example each time it wants to send the block data to another node, it simply converts those changes back to the correct way (eg. changing the 1 byte version to 4 bytes) before broadcasting it.

Another existing example is the scrambled values used in UTXO databse: https://bitcointalk.org/index.php?topic=5416061.msg61125420#msg61125420

[PrimeNumber7]

Nodes can already disregard blocks that are more than x blocks deep. All that these nodes need to store is the UTXO set and the last x blocks.

But pruned nodes are unable to validate transactions.  The network benefits more from full nodes.

A pruned node validates all transactions. All nodes (pruned, and non-pruned) will download the entire blockchain, and will keep track of the UTXO set. Pruned nodes will delete block data older than x blocks (more specifically, it will limit the total block data to x GB), while non-pruned nodes will retail all blocks. The main difference between the two types of full nodes is that one has access to all transaction data, and can serve new nodes all previous blocks, and the other cannot do either.

the TXID itself does not allow for nodes to validate that the transaction is valid.  I am also unaware of any way that a node would be able to update the UTXO set based on the various TXIDs of transactions included in a found block.

When a new transaction is created, it would include the details of the transactions it spends. All nodes would be able to see these details in the mempool and can validate them from there.  Once confirmed, the found block would only contain their txids, and it would be your choice whether to save or discard the details.  The only nodes who need to save transaction details are the owners.

I don't see how nodes would be able to validate if a block is valid or not under your proposal.

In order for a block to be valid, all consensus rules must be followed. I don't see how nodes would be able to validate that each transaction contains no inputs that have been previously spent, and that all inputs are valid.

Further, not all transactions that are included in blocks will be in all nodes' mempools for a variety of reasons. Some transactions have not even been broadcast publicly before a block is found. It is important to remember that each node has its own mempool, and the transactions that are stored in the mempool from node to node will vary.

[garlonicon]

To create new transactions, we include the details of the transactions we're spending, which can easily be checked against the hashes in the blockchain.

It won't work. You would need at least rollups to get there: https://bitcoinrollups.org/
And even then, it will work only in a LN-like way or sidechain-like way: you will be able to compress only things from the second layer. If there is no upper layer, then you cannot delete it permanently.

This is a very interesting topic.  If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.

Originally, a coin can be just a chain of signatures.  With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations.  It's the need to check for the absence of double-spends that requires global knowledge of all transactions.

The challenge is, how do you prove that no other spends exist?  It seems a node must know about all transactions to be able to verify that.  If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before.  Do you have any ideas on this?

It's hard to think of how to apply zero-knowledge-proofs in this case.

We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.

Here, Satoshi pointed out some very important thing: you need to prove that no other spends exist. You can use the hash of the previous transaction to create a spending transaction, but then, you still need the content of the previous transaction to prove it. And then, it goes recursively: to know if the previous transaction is valid, you need the "previous previous" transaction. And even if you will reach the coinbase transaction, then still, you need to check all transactions in a given block to check if the coinbase amount is valid. And if you want to verify everything from scratch, then nothing can be permanently deleted, so in the network there is a need to have enough nodes, where you can ask about that data, up to the Genesis Block.

[tromp]

And if you want to verify everything from scratch, then nothing can be permanently deleted

Except with Mimblewimble, you can permanently delete all spent outputs ....

[BlockChainMentor]

I don't think size of blockchain is very big problem because there is a Layer 2 solution available . I was reading about this layer 2 theorem . U can also explore this ...Read from this link
https://www.quora.com/What-happens-when-the-blockchain-becomes-too-large

[garlonicon]

Except with Mimblewimble, you can permanently delete all spent outputs ....

...and you know that such outputs are spent, because...?

That's the problem. If your answer is "because they have many confirmations", then it is not enough, because then new users cannot verify everything from scratch. They have to trust that outputs were joined correctly.

If there is any upper layer, then you can permanently delete some data, because you have to validate it only from the point where funds were moved to the second layer. But if there is no upper layer, then you have to validate everything. If you don't, then there is a risk that some malicious actor created some fake data, and mined that, to fool some nodes during initial block download. In any second layer, "initial" means "up to the point where it was moved from the mainchain". If there is no mainchain, then it means "everything".

I don't think size of blockchain is very big problem because there is a Layer 2 solution available .

If by "Layer 2" you mean "Lightning Network", then it is only partially true. LN is still strongly connected with the mainchain. You cannot give someone coins, when no channel is opened. You cannot transact LN<->LN without a channel, if some user is new. Adding and removing users require on-chain interaction. So, it is a layer "one and a half", rather than the true second layer, like for example sidechains (and sidechains are not truly decentralized, as long as sidechain miners are not selected by checking Proof of Work and nothing else).

[NotATether]

I don't think size of blockchain is very big problem because there is a Layer 2 solution available . I was reading about this layer 2 theorem . U can also explore this ...Read from this link
https://www.quora.com/What-happens-when-the-blockchain-becomes-too-large

That will only help us if a Layer 2 network is invented that's actually scalable... Lightning Network is private but it's not scalable to the capacity needed to accommodate as many users as VISA's.

[tromp]

Except with Mimblewimble, you can permanently delete all spent outputs ....

new users cannot verify everything from scratch.

That's exactly how Mimblewimble works. You sync from scratch by downloading the UTXO set
and the kernel history (~100 byte per tx) and verifying these. Not any spent output.

[n0nce]

In the interest of keeping the blockchain as small as possible, we should offload as much data as possible without compromising security.

I understand that maybe optimizing transaction sizes could be interesting for slight improvements in on-chain scaling, but with current demand and hardware prices, I don't feel like the blockchain necessarily needs to be much smaller / grow slower in size.

If you check online, a 1TB SATA SSD (not that HDDs wouldn't work in a pinch) starts at around $65 USD / 65€; I think most people can set that aside to buy a drive for their node easily. And it will last a good while.