The raw transaction is too long to post, here's a link (click "show raw transaction" at the bottom of the page)
http://www.multifaucet.tk/index.php?blockexplorer=FIND&txid=0a50f8c9e5a4154e0f24ea45316cb3dbfe3e7504293c8f6c13ad0ad87ca70d45
Topic: Altcoin blockchain experts - can anyone explain this semi-missing transaction? - page 3. (Read 2317 times)
January 30, 2016, 08:13:21 AM
January 30, 2016, 08:11:42 AM
58236.37353502 FindCoins sent and confirmed in block 226766
Transaction ID 0a50f8c9e5a4154e0f24ea45316cb3dbfe3e7504293c8f6c13ad0ad87ca70d45
2 different block explorers agree that the transaction is confirmed:
http://www.multifaucet.tk/index.php?blockexplorer=FIND&block=226766
http://findcoin.dcredits.com/explorer.php?226774
But 2 different block explorers also agree that the receiving address is empty and has never seen any transactions:
http://findcoin.dcredits.com/search.php?id=FXKLahV8uhruHY6zPsE1cYVGj67aTXVots
http://www.multifaucet.tk/index.php?address=FXKLahV8uhruHY6zPsE1cYVGj67aTXVots&blockexplorer=FIND
The reason this transaction was noticed is because it was apparently sent to an exchange for a coin-swap:
Does that mean that the sender fooled the exchange into accepting a deposit that never arrived?
The exchange has confirmed that the receiving address is one of their deposit addresses.
Because they're running their own block explorer during the coin swap, someone has suggested that they could be masking their own staking activity on their explorer.
But this transaction is on both explorers, so that doesn't apply here.
The only theory so far is that maybe because the transaction ID starts with a 0, it is accepted as valid within the block, but when it scans a different way for wallet balance the 0 gets automatically dropped and isn't a valid transaction ID? It looks like there are some other transactions on the blockchain that begin with a 0, but this particular transaction was easily spotted as missing because the address "has never been seen". No other transactions have been noticed as missing.
Raw block:
Transaction ID 0a50f8c9e5a4154e0f24ea45316cb3dbfe3e7504293c8f6c13ad0ad87ca70d45
2 different block explorers agree that the transaction is confirmed:
http://www.multifaucet.tk/index.php?blockexplorer=FIND&block=226766
http://findcoin.dcredits.com/explorer.php?226774
But 2 different block explorers also agree that the receiving address is empty and has never seen any transactions:
http://findcoin.dcredits.com/search.php?id=FXKLahV8uhruHY6zPsE1cYVGj67aTXVots
http://www.multifaucet.tk/index.php?address=FXKLahV8uhruHY6zPsE1cYVGj67aTXVots&blockexplorer=FIND
The reason this transaction was noticed is because it was apparently sent to an exchange for a coin-swap:
Does that mean that the sender fooled the exchange into accepting a deposit that never arrived?
The exchange has confirmed that the receiving address is one of their deposit addresses.
Because they're running their own block explorer during the coin swap, someone has suggested that they could be masking their own staking activity on their explorer.
But this transaction is on both explorers, so that doesn't apply here.
The only theory so far is that maybe because the transaction ID starts with a 0, it is accepted as valid within the block, but when it scans a different way for wallet balance the 0 gets automatically dropped and isn't a valid transaction ID? It looks like there are some other transactions on the blockchain that begin with a 0, but this particular transaction was easily spotted as missing because the address "has never been seen". No other transactions have been noticed as missing.
Raw block:
Code:
Array
(
[hash] => 861903ec4ac45bf12d458f166dd28c89716ada3c7921b8e97c3a9594652ebdc6
[confirmations] => 334
[size] => 11607
[height] => 226766
[version] => 6
[merkleroot] => 2d1ebbf8f30085ed28b51fe030125b065b3b66046eb46784a6efbaf1c9876b82
[mint] => 1.02683232
[time] => 1454114178
[nonce] => 0
[bits] => 1d530820
[difficulty] => 0.0120434
[blocktrust] => 31549de
[chaintrust] => 13a8ce08c169
[previousblockhash] =>
98d699076795c64f4af435817b6303450f55fc699cd3a704fb377008c6498062
[nextblockhash] => 88da842a2db2fee84fd9ac1b2a24ef574ad77328c092932af4018b16939825c1
[flags] => proof-of-stake
[proofhash] => 0001c2f2d6fc43868123ba19281091b5af771421419ec51123a0f31a495b2f6c
[entropybit] => 0
[modifier] => 1e9ee79bd73677e0
[modifierchecksum] => 10979f05
[tx] => Array
(
[0] => 638d86d00c4c1f5e3ca31b7354067f900d9da5e33885ed80a09f2fe45d0dc9e8
[1] => 2dccc876dd7a07d38e4693b009556dc6a72e3c9ea1cd85bf24b02d5a81f77d15
[2] => 0a50f8c9e5a4154e0f24ea45316cb3dbfe3e7504293c8f6c13ad0ad87ca70d45
)
[signature] =>
304502210094289c479e456e3c86cd1805522db7cc8d1b1874184da018d9dad2cc781b724702206e6dd63325c4
7d429d79f4055010c935aa34e0eda6f6dce26c067cc7a5c39396
)
Jump to: