What happen if Merkle trees didn't include in blockchain?

[Abdulzuruku01]

In my recent research i have been learning about Merkle trees in blockchain, and during my study I read that it is data encrypted design used for data identification and stored all transaction data mined on the bitcoin network safely in blockchain. I also read that it helps miners identify whether transaction have been tempered with and it remove any duplicate transaction and that it has no delay when sending data across the network. They also total and stores all set of transaction in a block and produce digital fingerprint to all these transactions and allow efficient validation from user to check if it include a transaction in a block.

It clear to me from my research that Merkle trees are crucial in blockchain, but I'd like some assistance in understanding what would happen if merkle trees didn't included in the blockchain and what difficulties arise while using them. I would appreciate any corrections you may have so I may improve my research, because learning the technical aspects of bitcoin is my top goal here.

[ABCbits]

and during my study I read that it is data encrypted design used for data identification and stored all transaction data mined on the bitcoin network safely in blockchain.

1. Bitcoin itself doesn't use encryption cryptography.
2. I'm not sure what do you mean by data identification, since Bitcoin is pseudonymous.

It clear to me from my research that Merkle trees are crucial in blockchain, but I'd like some assistance in understanding what would happen if merkle trees didn't included in the blockchain and what difficulties arise while using them.

What would happen? SPV mechanism would be more difficult and less efficient, since it needs to download whole block which contain relevant TX.

[Mia Chloe]

Lack of usage of the Merkel tree would actually have a lot of negative effects on the network. One of them is that every transaction would need to be stored individually, leading to more space occupied in the blockchain. Also, without Merkle trees, verifying transactions would require checking every single transaction, making the process slower.

To a very large extent, merkle trees actually provide a way to efficiently verify transaction inclusion without revealing sensitive information. Without them, the blockchain would be more vulnerable to attacks, congestion and a less efficient proof of work system. Infact block propagation will be much slower.

Node prunning would not be possible since there would be no link to most data needed if everything is stored individually. Many things will be affected from congestion to high fee as a result of the fact that more computational power will be needed.

[ABCbits]

Lack of usage of the Merkel tree would actually have a lot of negative effects on the network. One of them is that every transaction would need to be stored individually, leading to more space occupied in the blockchain. Also, without Merkle trees, verifying transactions would require checking every single transaction, making the process slower.

To a very large extent, merkle trees actually provide a way to efficiently verify transaction inclusion without revealing sensitive information. Without them, the blockchain would be more vulnerable to attacks, congestion and a less efficient proof of work system. Infact block propagation will be much slower.

Node prunning would not be possible since there would be no link to most data needed if everything is stored individually. Many things will be affected from congestion to high fee as a result of the fact that more computational power will be needed.

I have several thought and question,
1. Full node (excluding pruned ones) actually verify/check and store all transaction. So what exactly do you mean by "Also, without Merkle trees, verifying transactions would require checking every single transaction, making the process slower." ?
2. I don't understand how it makes node pruning impossible. After all, pruned node just need to store recent block and UTXO in order to verify new block.
3. How exactly lack of merkle tree would lead to high fee when transaction size and block size limit remain not changed?

Do you mind explain it more clearly?

[Abdulzuruku01]

2. I'm not sure what do you mean by data identification, since Bitcoin is pseudonymous.

Because it easier to identify and verify a large body of information that are store in blockchain and help miners identify easily when any transaction have been tempered with.

[Mia Chloe]

~snip

You're right about  the aspect of full nodes storing and verifying all transactions. However without Merkle trees, verifying a transaction would require checking the entire block, not just the transaction itself. And that's because in a Merkle tree, transactions are hashed and combined in pairs, forming a tree-like structure and this actually allows nodes to efficiently verify a transaction by checking only the relevant branches of the tree. Now, without Merkle trees, nodes would need to verify the entire block by checking every transaction's signature, scripts, and other data. Just to verify it's POW stamp and origin.

Think of it like searching for a specific book in a library, with Merkle trees, you can quickly locate the book by checking the catalog (Merkle root) and then verifying the book's existence by checking only the relevant shelf (Merkle branch). And this kinda means that without Merkle trees, you'd need to search the entire library, checking every book individually.

As for the pruned nodes aspect,yes they actually store recent blocks and UTXOs. However, without Merkle trees, pruned nodes would struggle to efficiently verify new blocks, as they'll need to check every transaction in the block, not just the relevant ones. Meaning you will not only waste computational power but also if there is no Merkel tree some branches of data may be missing causing difficulties in a prunned node from getting the origin and POW data of a transaction since there is no branch like link and some data isn't present.

[ABCbits]

~snip

You're right about  the aspect of full nodes storing and verifying all transactions. However without Merkle trees, verifying a transaction would require checking the entire block, not just the transaction itself. And that's because in a Merkle tree, transactions are hashed and combined in pairs, forming a tree-like structure and this actually allows nodes to efficiently verify a transaction by checking only the relevant branches of the tree. Now, without Merkle trees, nodes would need to verify the entire block by checking every transaction's signature, scripts, and other data. Just to verify it's POW stamp and origin.

Think of it like searching for a specific book in a library, with Merkle trees, you can quickly locate the book by checking the catalog (Merkle root) and then verifying the book's existence by checking only the relevant shelf (Merkle branch). And this kinda means that without Merkle trees, you'd need to search the entire library, checking every book individually.

As for the pruned nodes aspect,yes they actually store recent blocks and UTXOs. However, without Merkle trees, pruned nodes would struggle to efficiently verify new blocks, as they'll need to check every transaction in the block, not just the relevant ones. Meaning you will not only waste computational power but also if there is no Merkel tree some branches of data may be missing causing difficulties in a prunned node from getting the origin and POW data of a transaction since there is no branch like link and some data isn't present.

It's either i don't understand your statement or you didn't double check what you write, but
1. You admit that full node verify all transaction, but you also say that without merkle tree full node need to check whole block / every transaction in the block. That means it's not disadvantage of lack of merkle root.
2. Pruned node (at least for Bitcoin Core) doesn't even keep old merkle tree according to https://bitcoin.stackexchange.com/a/36101.

[ABCbits]

In my recent research i have been learning about Merkle trees in blockchain, and during my study I read that it is data encrypted design used for data identification and stored all transaction data mined on the bitcoin network safely in blockchain. I also read that it helps miners identify whether transaction have been tempered with and it remove any duplicate transaction and that it has no delay when sending data across the network. They also total and stores all set of transaction in a block and produce digital fingerprint to all these transactions and allow efficient validation from user to check if it include a transaction in a block.

It clear to me from my research that Merkle trees are crucial in blockchain, but I'd like some assistance in understanding what would happen if merkle trees didn't included in the blockchain and what difficulties arise while using them. I would appreciate any corrections you may have so I may improve my research, because learning the technical aspects of bitcoin is my top goal here.

I think many answers were given but I will like add this too,Although Merkle trees make it possible to improve the performance, security and scalability of the blockchain. Without them, blockchain would face the most serious problems leading to congestion, centralization and lower rates of adoption.

I think you need to explain further why lack of merkle trees leads to congestion, centralization and lower rates adaption. After all,
1. Merkle tree doesn't determine block size limit, which means total transaction which can fit in a block doesn't change.
2. Full nodes verify whole block, where lack of merkle tree wouldn't have such major impact on verification time.
3. Average user doesn't know or care about how Bitcoin works in details.

CMIIW.

[NotATether]

Merkle trees are for the transactions, and they are included in each block for its own transactions.

They allow the Core client to verify that all of the transactions in the block are valid and intended to be there. There's one for TXIDs and another for WTXIDs (to validate both legacy transactions and their segwit versions, if applicable).

There's a specific process described in a BIP somewhere that dictates how the transactions are supposed to be ordered before hashing them as leaves. That is because they are combined two at a time, unless the number of transactions is odd, in which case I think the last transaction skips a branch or something.

[Mia Chloe]

It's either i don't understand your statement or you didn't double check what you write, but
1. You admit that full node verify all transaction, but you also say that without merkle tree full node need to check whole block / every transaction in the block. That means it's not disadvantage of lack of merkle root.

Well it seems you haven't fully gotten my point. I don't know why but my telegram bot didn't display this mention if not I would have replied earlier I decided to check the thread while I was surfing and found you quoted me with some questions again. Firstly I think the problem is you are actually viewing the whole situation as if full nodes don't make use of the Merkel tree and that's not the case here.

Computers or rather ASIC mining wares are actually designed to carry out one particular task efficiently and that simply means that they would need to make use of Merkel trees to validate transactions so even in the case of a full node, for a faster and more efficient validation it would use the Merkel tree instead of individual scattered data.

2. Pruned node (at least for Bitcoin Core) doesn't even keep old merkle tree according to https://bitcoin.stackexchange.com/a/36101.

Yes but it still keeps the newest ones to show how important the Merkel tree is. You can't risk having ungrouped data (data without the Merkel tree) for a node without all the data since you could risk missing out some important data.

[bizeodal]

every transaction would need to be stored individually, leading to more space occupied in the blockchain. Also, without Merkle trees, verifying transactions would require checking every single transaction, making the process slower

Every transaction is stored individually. Bitcoin does not use the Merkle tree to delete transactions  
Every single transaction is verified

[bizeodal]

It clear to me from my research that Merkle trees are crucial in blockchain

They're not crucial. Are you sure you did any research?

It is crucial to have a commitment in the block header which represents all the transactions in a way that allows proof that the transactions have not been modified after the block was created. A hash (SHA2-256 is used) serves as a proof because it is not forgeable 

It is crucial to minimize the size of the block header, so that block-level chain proofs can be very fast. A hash is only 32 bytes. It serves as an efficient compression of several thousand transactions 

The hash commitment which represents the transactions could be calculated by serializing all the transactions in order and making a single hash calculation
The hash commitment which represents the transactions could be calculated by concatenating all the transactions' ID hashes in order and making a single hash calculation

Merkle trees have benefits for coders - a clearer separation between the function of a transaction and the hashing functions used to implement immutability in the chain. This benefit persists over the long term, reducing the possibility of bugs being created by future software maintenance

Not crucial, but very useful

[ABCbits]

It's either i don't understand your statement or you didn't double check what you write, but
1. You admit that full node verify all transaction, but you also say that without merkle tree full node need to check whole block / every transaction in the block. That means it's not disadvantage of lack of merkle root.

Well it seems you haven't fully gotten my point. I don't know why but my telegram bot didn't display this mention if not I would have replied earlier I decided to check the thread while I was surfing and found you quoted me with some questions again. Firstly I think the problem is you are actually viewing the whole situation as if full nodes don't make use of the Merkel tree and that's not the case here.

Computers or rather ASIC mining wares are actually designed to carry out one particular task efficiently and that simply means that they would need to make use of Merkel trees to validate transactions so even in the case of a full node, for a faster and more efficient validation it would use the Merkel tree instead of individual scattered data.

I still don't get your point.
1. I'm sure ASIC miner doesn't perform verification at all, since it's only designed to perform SHA-256.
2. Computer generally designed to perform general or all kinds of tasks.
3. Full node already verify all TX. In fact, it already verify most/all of them when it reached their mempool, before added in a block.

2. Pruned node (at least for Bitcoin Core) doesn't even keep old merkle tree according to https://bitcoin.stackexchange.com/a/36101.

Yes but it still keeps the newest ones to show how important the Merkel tree is. You can't risk having ungrouped data (data without the Merkel tree) for a node without all the data since you could risk missing out some important data.

That makes sense. Without merkle tree, there's no information on block header which can be used to know about whether you receive complete block data from other node.

[Mia Chloe]

That makes sense. Without merkle tree, there's no information on block header which can be used to know about whether you receive complete block data from other node.

Exactly now you get my point. This was the main reason why I said earlier on that without the implementation of Merkel trees , there would pretty much be no group data in an organised format to be able to select key ones to form a prunned node. It's like saying you want to confirm is a couple of books are not fake and available in a library when you don't even have the whole library and a catalogue (which is a Merkel tree in this case). In simple terms I'll just say the Merkel tree makes it possible for prunned nodes to summarise the block chain and save space.

I still don't get your point.
1. I'm sure ASIC miner doesn't perform verification at all, since it's only designed to perform SHA-256.
2. Computer generally designed to perform general or all kinds of tasks.
3. Full node already verify all TX. In fact, it already verify most/all of them when it reached their mempool, before added in a block.

As for this, ASIC mining wares carryout hashing, and if you agree to that then you will also recall that hashing is carried out multiple times on the block header during hashing and validation meaning without Merkel trees there wouldn't be data grouped so that you can have a head to hash on.

[ABCbits]

I still don't get your point.
1. I'm sure ASIC miner doesn't perform verification at all, since it's only designed to perform SHA-256.
2. Computer generally designed to perform general or all kinds of tasks.
3. Full node already verify all TX. In fact, it already verify most/all of them when it reached their mempool, before added in a block.

As for this, ASIC mining wares carryout hashing, and if you agree to that then you will also recall that hashing is carried out multiple times on the block header during hashing and validation meaning without Merkel trees there wouldn't be data grouped so that you can have a head to hash on.

I see. It seems your definition of verification is far more broad than mine, which caused some confusion.

[vjudeu]

what would happen if merkle trees didn't included in the blockchain

Then, instead of a single 256-bit number, you would have only the transaction counter in the block message, and all transactions after that.

SPV mechanism would be more difficult and less efficient, since it needs to download whole block which contain relevant TX.

If you use a hash function like SHA-256, which is based on Merkle–Damgård construction, then things can be optimized, and then done in SPV way. For example: you can give someone the initialization vector, just before the latest SHA-256 internal block, and the last 512-bit chunk. It would be sufficient to verify, that the hash of the whole block was mined correctly.

The same about proving transaction inclusion: even if you hash all data, as a single SHA-256 call, then still: you can prove, that a chunk "X" is included, by giving the initialization vector, some chunks in-between, and a final SHA-256 result, for that specific chunk.

So, SPV would be of course harder, but still possible, because SHA-256 splits data into 512-bit chunks by definition.

Edit: With Merkle tree:

Code:

+---------------+------------------------------------------------------------------+
| version       | 01000000                                                         |
| prevBlockHash | 0000000000000000000000000000000000000000000000000000000000000000 |
| merkleRoot    | 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a |
| time          | 29ab5f49                                                         |
| difficulty    | ffff001d                                                         |
| nonce         | 1dac2b7c                                                         |
+---------------+------------------------------------------------------------------+
| transactions  | 01                                                               |
+---------------+------------------------------------------------------------------+
| version       | 01000000                                                         |
| inputs        | 01                                                               |
| prevTxHash    | 0000000000000000000000000000000000000000000000000000000000000000 |
| prevTxId      | ffffffff                                                         |
| scriptSize    | 4d                                                               |
| difficulty    | 04 ffff001d                                                      |
| extraNonce    | 01 04                                                            |
| genesisData   | 45                                                               |
|               | 5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72 |
|               | 206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f7220 |
|               | 62616e6b73                                                       |
| sequence      | ffffffff                                                         |
| outputs       | 01                                                               |
| amount        | 00f2052a01000000                                                 |
| scriptSize    | 43                                                               |
| publicKey     | 41 04                                                            |
|               | 678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6 |
|               | 49f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f |
|               | ac                                                               |
| locktime      | 00000000                                                         |
+---------------+------------------------------------------------------------------+

What is hashed, and how:

Code:

+-----------------------+-------------------------------------+
| initialization vector | 6a09e667 bb67ae85 3c6ef372 a54ff53a |
|                       | 510e527f 9b05688c 1f83d9ab 5be0cd19 |
+-----------------------+-------------------------------------+
| first chunk           | 01000000 00000000 00000000 00000000 |
|                       | 00000000 00000000 00000000 00000000 |
|                       | 00000000 3ba3edfd 7a7b12b2 7ac72c3e |
|                       | 67768f61 7fc81bc3 888a5132 3a9fb8aa |
+-----------------------+-------------------------------------+
| first hash            | bc909a33 6358bff0 90ccac7d 1e59caa8 |
|                       | c3c8d8e9 4f0103c8 96b18736 4719f91b |
+-----------------------+-------------------------------------+
| second chunk          | 4b1e5e4a 29ab5f49 ffff001d 1dac2b7c |
|                       | 80000000 00000000 00000000 00000000 |
|                       | 00000000 00000000 00000000 00000000 |
|                       | 00000000 00000000 00000000 00000280 |
+-----------------------+-------------------------------------+
| second hash           | af42031e 805ff493 a07341e2 f74ff581 |
|                       | 49d22ab9 ba19f613 43e2c86c 71c5d66d |
+-----------------------+-------------------------------------+

+-----------------------+-------------------------------------+
| initialization vector | 6a09e667 bb67ae85 3c6ef372 a54ff53a |
|                       | 510e527f 9b05688c 1f83d9ab 5be0cd19 |
+-----------------------+-------------------------------------+
| third chunk           | af42031e 805ff493 a07341e2 f74ff581 |
|                       | 49d22ab9 ba19f613 43e2c86c 71c5d66d |
|                       | 80000000 00000000 00000000 00000000 |
|                       | 00000000 00000000 00000000 00000100 |
+-----------------------+-------------------------------------+
| third hash            | 6fe28c0a b6f1b372 c1a6a246 ae63f74f |
|                       | 931e8365 e15a089c 68d61900 00000000 |
+-----------------------+-------------------------------------+

And without Merkle tree, it would be still possible to prove data inclusion. For example: if you share with anyone, that there is a chunk of data, which starts from "bc909a33 6358bff0 90ccac7d 1e59caa8 c3c8d8e9 4f0103c8 96b18736 4719f91b", and ends with "af42031e 805ff493 a07341e2 f74ff581 49d22ab9 ba19f613 43e2c86c 71c5d66d", then, the only matching in-between data, is equal to this "second chunk". And: the size of in-between data can be arbitrarily large, you will just share the starting 256-bit value, and the ending 256-bit value, and then, you can prove, that as long as SHA-256 is safe, nobody changed anything here.