1

I made a quick study on blockchain yesterday. There is a question in my mind, When the block is distributed and everyone has a copy, Isn't possible to have a change bit and a counter in the node and just xor whole of block bits with a copy to find out which block has changed? instead of check all hashes?

{
  myBit: 0
  changeCount: autoInc
}

nodes | n1  |  n2  |  n3 |  n4  | ...node N
-------------------------------------------
myBit | 1   |  0   |  1  |  1   |

When everyone has a copy then myBits xor everyCopy bits and comprae counters, and a voting between them won't show changes?

Vahid Alimohamadi
  • 137
  • 6
  • 1
    Blockchains use hashes so that the hash of a block can be included in the next block, creating a chain (or a kind of simple Merkle tree). If a block were to be changed, the hashes change and all subsequently blocks would have to change as well, making forgery impractical. Any node can check *alone* whether the blocks it has form a valid blockchain. Your methods allows *multiple* nodes to find agreement on what the true block contents should be (→ consensus protocols). In practice there's not a large difference in security though (→ 51% attack). – amon Jul 03 '20 at 10:18
  • 1
    Voting doesn't work because I can just tell the network that my computer is a proxy server for a billion computers on Mars and they all voted my way. – user253751 Jul 03 '20 at 16:05

1 Answers1

3

I have only a very general understanding of blockchain. But I know sufficiently on XOR and cryptographic hashes to spot at least some flaws in your XOR approach:

  • XOR is nice for checksum. Checksums are good at spotting random changes such bitflips in network communication. But it’s insufficient for spotting intentional forgery.
  • So your algorithm would require to calculate the xor each time.
  • You’d then need to to it on every block of the chain, because xor has very predictable collisions. It would be easy to forge a change of in 2 blocks of the chain, so that the xoring combined for all the blocks remains unchanged.
  • your approach would then be suitable only for verifying integrity of past transactions, only if you already have a copy and if you trust the copy.
  • Your algorithm would also be proportional to the length of the blockchain. Slower and slower over time.
  • Only nodes that already have a copy of the chain could trust the integrity: the integrity is not verifiable for new nodes.
  • And your approach doesn’t address the integrity of new transactions.

Blockchains aim at decentralising trust and guaranteeing verifiable integrity decentrally. That’s why blockchains work with cryptographic hashes. The chained cryptographic hash allows you to limit the verification to a portion of the chain that you do not yet trust, without reverifying each time what was already verified.

Warning: To me, this explanation seems to make sense, at least when I wrote it. But both, cryptography and distributed computing make this a complex matter. I hope I expressed it sufficiently clearly; don’t hesitate the comments if you (or I) missed something ;-)

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • Thanks for your attention and explain. It seems i need study more. – Vahid Alimohamadi Jul 03 '20 at 08:57
  • 3
    @VahidAlimohamadi Thanks for the interesting question. I can only encourage you to continue to study topics with a such critical view: challenging an algorithm is the best way to either understand it or discover a flaw :-) – Christophe Jul 03 '20 at 10:04