This is related/a follow up question to "If someone were to find a Proof of Work collision, could they pin the tail of the tangle to the head?"

Imagine two transactions that hash to the same value but have different trunks and branches. Like this:

enter image description here
* I used "3 tryte hashes" without MWM instead of 81 tryte hashes for the sake of lucidity. For your answer, please just pretend they are 81 tryte hashes with default MWM.

I know, that it's very difficult to find a CURL-P/CURL collision.

  1. Is it difficult enough for this to actually NEVER happen, even if someone tries to make it happen?

Let's assume, someone managed to find two JOEs, and they also manage to publish them to different places in the network so that approximately half of all nodes get the red JOE and the other half get the blue JOE.

This also means that half of the network does not get to see blue JOE and the other half does not get to see red JOE.

  1. What would happen, if none of the JOEs carry information like bundle signatures? i.e., they are just spam transaction;
  2. What would happen, if one of the JOEs carries a bundle signature (and the other one is just a spam transaction) or if they belong to two different bundles and both carry a signature for their bundle? The two bundles do not spend funds from the same address.
  3. What would happen, if the JOEs carry signatures for two different bundles that try to spend from the same address.

enter image description here

up vote 1 down vote accepted

I don't know what's the probability for this to occurs, but I guess that this something that some users try to produce since the early stages of the tangle, and AFAIK was never detected.

Anyway, let's imagine that such collision and synchronous propagation occurs...

I think that a distinction should be made between 2 different situations.

  1. JOE's transactions are zero value. (scenario 2)

In this situation: the hash collision may remains unnoticed. If you look at the tangle globally : the tangle will have a JOE transaction approving 4 transactions instead of 2. This is unusual, but not strictly illegal regarding fundaments of the protocol (approving 2 transactions is just the optimal number, and the only supported number according transaction syntax)

  1. JOE-red and JOE-blue are spending iotas from the same address.

Let's say that :

  • JOE-blue transfer 10 iotas from A to B
  • JOE-red transfer 10 iotas from A to C

For about 50% of the nodes : B holds 10 iotas and C holds 0 iotas. The other 50% of the nodes see the opposite. In this situation neither B, nor C will be able to spend.

It can be worse if the Coo is still active. Assume that the COO approve JOE-blue, and later COO approve a transaction of 10 iotas from B to D. 50% of the network will reject the milestone (the 50% seeing 0 iotas at address B).

If nobody tries to spend from B or C, then the problem will be detected with the snapshot : 50% of the network will disagree with the proposed snapshot.

(similar reasoning applies if JOE-red and JOE-blue are spending from a different address, or even if one of the 2 JOE is a zero value tx)

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.