Let's consider following situation:

  1. Vendor owns address X.
  2. Adversary sends transaction T1 to X with hash Y and receives product from vendor.
  3. Adversary sends transaction T2 to address which he owns with the same hash Y to other nodes.
  4. Vendor receives transaction T2 with same hash as T1, so from his point of view this is the same transaction. He ignores it.
  5. Other nodes receives transaction T1 after T2 so they ignores T1.
  6. Transaction T2 was sent to majority, so probability that T2 will be included in next block is higher than probability of inlcuding T1.
  7. According to probabilty, the transaction T2 was included in next block.

Is this scenario of double-spend correct?


The scenario your tried to imagine is almost correct.

The point is that the "attacker" will generate two identical transaction coming from the same unspent outputs of his address X to "Vendor" address Y. He will generate T1 and T2 at the same time, taking funds to send from the same source but he will attach to each transaction a different fee. Of course one of the two transactions will have an higher fee.

The transaction with the higher fee (i.e. the tx which the "attacker" sends back to his owned address, as you called T2) will be the one ACCEPTED by the network. T1 will be rejected because it comes from the same unspent outputs than T2 but it has a lower fee, so after a while it gets pruned by mempool of Bitcoin network.

In conclusion, pseudo double spending, it's a matter of fees and not tx timestamps.

Hope this helped.


Becuase transaction T2 has different contents (address adversary owns rather than address vendor owns) it will have a different hash.

  • Sorry, I haven't written in my question, but I meant that T2 has same hash because adversary found second pre-image of hash function. – Some One Mar 31 '18 at 9:21
  • Okay, the adversary has super-human reverse hashing power? Some kind of superhero? – Willtech Mar 31 '18 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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