Topic: Re: Why are transactions stored in a hash/merkle tree ? (Read 1323 times)

Consider the possibility of using SAT solvers for Bitcoin mining. I think double SHA-256 is unpenetrable for the current generation of solvers, but let's assume things will change BTW, if such progress will come from academic world, we can expect RSA challenge to be solved first, this will be a good warning for Bitcoin community. SAT solvers work by exploring 'easy' area of potential solution space first, postponing 'hard' part for latter. Now, imagine that there are many solutions for valid block hash - SAT solver will be more effective in such situation. But with current difficulty there are something like 67 required zeroes in resulting hash value and only, say, 32+10 free variables (32 bit nonce and may be lower part of time field), so there aren't many solution, on the average the equation system will be compatible once per 2^25 attempts. Straightforward way to use SAT solver for mining puts it into disadvantage. To provide more free variables one can use data bits inside or around transaction. Obvious candidate is input of coinbase transaction of an empty block (and nonce2 will be huge in such case), but sequential hashing allows using the last transaction of non-empty block for this purpose. Well, OK, that's rather a speculation right now, let's watch for a progress in SAT solvers development

To quickly change Merkle root value one can swap two children of some inner node, the only requirement is keeping coinbase transaction the first - instead of increasing nonce2 or adding new transaction. See, no need to actually change elements

I don't think the tree, as opposite to sequential hashing,  adds any security.
But it decreases number of steps you need to perform in order to recalculate the output hash value, when only one element is changing. If you're a miner and need to apply a new TX to a block - with the tree it can go faster.

Not the entire block. There are two hashes. The block hash that only covers the header and the merkle root that covers the transactions. The block hash is simply a hash over the bytes of header. The merkle root hash is more sophisticated.
All the transactions are put in a binary tree. Then the leaves (= the transactions) are hashed. Afterwards, the parents are hashes of the concatenation of the 2 children. And so on so forth until the root. With a merkle tree, one can replace part of the data by a hash while still proving that the remaining data hasn't been compromised.

As the block chain gets older, old transactions will become irrelevant because the money that were at these addresses is spent.
Today, a full node carries the entire block chain. A smart client could detect that these transactions are useless and remove them from their block. It will leave a 'hole'. When two holes are next to each other, they can be combined into a bigger hole. Finally, the hope is that the block chain becomes much smaller.

When Merkle tree root is calculated, hash function is applied to fixed length data (32+32 bytes). Possibly, Satoshi considered some variant of length extension attack. Possibly, something went wrong

I hope people could read the white paper before asking noob questions: https://bitcoin.org/bitcoin.pdf

The block *header* is hashed, not the transactions. The block header contains the merkel root, so you can't lie that a transaction was included when it wasn't.

SPV clients can be fooled by omission however.

If I understood correctly what you mean is that the entire block will be removed from the blockchain. Wouldn't that compromise the whole blockchain since each block includes the hash of the previous block, and therefore if one is removed then its reference in the next block will be not verifiable (as the block was removed).