1

Chain.com http://explorer.chain.com/transactions/a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

Chain.so https://chain.so/tx/BTCTEST/a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

hash of the transaction a4bfb8e21ae3d6232183dfb8ef5fcee8c9b8f223c2d25738e24765a75abd009b

Improve this question
4
  • Odd. Chain explorer doesn't seem to have any record of block 891a17... at all.
    – Nick ODell
    May 25, 2015 at 18:58
  • Possibly they are on two different forks?
    – Nate Eldredge
    May 25, 2015 at 20:11
  • I submitted to only one using blockcypher.com API
    – Igor Barinov
    May 25, 2015 at 20:18
  • May be Blockcypher submitted to two forks same transaction?
    – Igor Barinov
    May 25, 2015 at 20:23

1 Answer 1

Reset to default
1

That's pretty common. What happens is that the chain forks for whatever reason and some miners are on each side of the fork. They will both have your transaction in their transaction pool and so eventually include it in a block. So your transaction ends up on each fork.

Ultimately it doesn't matter though as the network will eventually agree on which fork is correct.

Note that recently, testnet has been pretty unmanageable, with regular difficulty resets creating situations where 100s of blocks get created per minute. This creates a lot of chain forks and some can be really long, like in your case. Also due to the high number of forks, some nodes may not have learned about a given block/fork at all if it ended up "losing".

On the mainnet, forks are somewhat infrequent (couple daily) and much shorter (very rarerly more than a block).

Improve this answer

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.