frndxyz commented 10 years ago

i notify in web ui block shows orphaned . but in deamon block shows in progress of confirmation. and after sometime it gets confirmed but in web UI still orphaned.

--- There is a **[$55 open bounty](https://www.bountysource.com/issues/5108856-some-blocks-are-marked-as-orphaned-where-they-aren-t-so-actually?utm_campaign=plugin&utm_content=tracker%2F401667&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F401667&utm_medium=issues&utm_source=github).

bonesoul commented 10 years ago

can you supply the details please so i can check thrm

frndxyz commented 10 years ago

actually it difficult to provide details because when block orphaned i though everything is ok. but after all pending payment complete i see many coins other then fees remain in my wallet and i send it manually to the miner. how it happens without error i dont have any idea.

artbatista commented 10 years ago

Sorry, I didn't see this before. Same as #566 I'll close that one.

Found a new block and submitted successfully:

10/13/2014 13:15:37 -04:00 [Information] [ShareManager] [Lottocoin] Found block [854019] with hash [49f75c4cb07d23c0babb4591951269dc972a637f862fa292fd7273baa48b5ab5] 10/13/2014 13:15:37 -04:00 [Verbose] [JobManager] [Lottocoin] As we have just found a new block, rebroadcasting new work

However, a few minutes later:

10/13/2014 13:16:28 -04:00 [Information] [BlockProcessor] [Lottocoin] Queried 1 pending blocks; 0 got confirmed, 1 got orphaned; took 0.034 seconds

But, the block was in fact accepted and confirmed, as can be seen here in the block crawler for lottocoin. Some times the block crawler takes a while to load, be patient.

http://coinbomb.biz/lotblocks/index.php?block_hash=49f75c4cb07d23c0babb4591951269dc972a637f862fa292fd7273baa48b5ab5

So the block was marked orphaned even though it was accepted by the network and the coins were credited to the wallet:

Status: 91 confirmations Date: 10/13/2014 13:15 Source: Generated Credit: 7529.625 LOT Net amount: +7529.625 LOT Transaction ID: 337ad6a7f30a0ff0fb61911497edc7776588e52dbd9fdf9ab4931c9c393b96e4 Transaction comment: Mined at http://lottocoin.artbatista.com/

Generated coins must mature 120 blocks before they can be spent. When you generated this block, it was broadcast to the network to be added to the block chain. If it fails to get into the chain, its state will change to "not accepted" and it won't be spendable. This may occasionally happen if another node generates a block within a few seconds of yours.

http://artbatista.com/pool/LOT/block/854019

artbatista commented 10 years ago

I don't think this is solved yet. #566 was closed as a dupe, but not this one.

bonesoul commented 10 years ago

also reported on digibyte;

as orphans.

bonesoul commented 10 years ago

seems we should also start using hex output of the getransaction against decoderawtransaction() as an improvement. - https://github.com/bitcoin/bitcoin/issues/4807

bonesoul commented 10 years ago

i suspect the reason is caused by;

though still need to see the output from server-coin daemon;

gettransaction 53a67d6d3ed3b55e2dc6b255e41079cd3af42e9ba1634b80aaebda5f10822075

digibyted gettransaction 53a67d6d3ed3b55e2dc6b255e41079cd3af42e9ba1634b80aaebda5f10822075
{
    "amount" : 0.00000000,
    "confirmations" : 93,
    "generated" : true,
    "blockhash" : "00000000000014670f8664836e8566f9d5263f876698cb8226752fb4d33096d6",
    "blockindex" : 0,
    "blocktime" : 1413758718,
    "txid" : "53a67d6d3ed3b55e2dc6b255e41079cd3af42e9ba1634b80aaebda5f10822075",
    "walletconflicts" : [
    ],
    "time" : 1413758718,
    "timereceived" : 1413758747,
    "details" : [
        {
            "account" : "sha256",
            "address" : "DTru79bzgffzV8xjwmiNUBwb3bBE5E6bcr",
            "category" : "immature",
            "amount" : 7164.51502364
        }
    ],
    "hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2603960604062f503253482f037e92150828000002081200000d2f436f696e69756d536572762f00000000021c59d6cfa60000001976a914f93ab1a4a0dd3bfd92c421183011c5fdb00b832488ac96155aaf010000001976a91477d451048c36555024165a6de428794ff1a681a888ac00000000"
}

getaccount DTru79bzgffzV8xjwmiNUBwb3bBE5E6bcr
digibyted getaccount DTru79bzgffzV8xjwmiNUBwb3bBE5E6bcr
sha256

seems all valid - need to debug the code now on.

477 is also contains a possible workaround

bonesoul commented 10 years ago

weird stuff going on here - block explorer will only mark a block as orphaned on 6 conditions;

when blocks generation transaction has -1 confirmations (https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L113)
when reported txhash doesn't match our generation-tx hash in records (https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L124)
when pool output doesn't exist in the generation transaction - https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L140
when pool output's category is set to orphan - https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L154
when block hash is reported as invalid - https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L184
when generation transaction hash is reported as invalid - https://github.com/CoiniumServ/CoiniumServ/blob/master/src/CoiniumServ/Blocks/BlockProcessor.cs#L225

in the above digibyte example, i don't see any conditions are met but somehow it's marked as so. I need to further debug the issue down to see the cause.

artbatista commented 10 years ago

Could this be related to #501 ?

In that ticket, the hash submitted does not match the actual found block hash.

bonesoul commented 10 years ago

https://github.com/Crypto-Expert/stratum-mining/commit/1cf5e15e05596ee4110ff1cdf38b4a1195bcefa2

bonesoul / CoiniumServ

some blocks are marked as orphaned where they aren't so actually [$55] #541

477 is also contains a possible workaround