Mined a Terracoin block, but I haven't been paid. Whats gonig on?

[skeeterskeeter]

I posted this on terracoin talk http://www.terracointalk.org/index.php/topic,443.0.html

I have BFGMiner solo mining terracoins for me with the following arguments

Code:

F:\bfgminer.exe -G -o http://localhost:18332 -u user-p pass--coinbase-addr 15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s

I also have TerracoinQt opened in server mode.

Code:

server=1
rpcuser=user
rpcpassword=pass
rpcallowip=127.0.0.1
rpcport=18332

It seems that I found a block


But I have not been paid in TerracoinQt. Is there a delay on the reward? Do so many users need to confirm it before TerracoinQt pays me (itself)?

[1713881163]

1713881163

[1713881163]

1713881163

[1713881163]

1713881163

[Eli0t]

check listtransactions in the debug window in the qt, probably an orphan or if not needs more confirms

[skeeterskeeter]

Anyway to tell for sure if it has become orphaned? listtransactions shows the same thing as the transactions tab, no reward.

Is there a way to tell if it has been received by others? I'm not sure how to find a log of it from terracoinQt though

[Eli0t]

listtransactions should say if its orphaned or immature

[skeeterskeeter]

listtransactions should say if its orphaned or immature

listtransactions does not show any transaction amounting to a reward (20TRC).

[aa]

.

[skeeterskeeter]

Is your most recent block orphaned or immature? It isn't that hard. If there's no transaction at all, start the client with -rescan.

This is my most recent block, its the only block I've ever found for any type of coin.
I think you kinda of just asked me my own question, I want to know how to tell if my block is orphaned (found hash to a stale piece of work?) or immature (which I'm guessing means does not have enough confirmations?) So that I can figure out why I have not been paid by TerracoinQt client, because if it is orphaned or immature I would not see payment as I am currently, is that correct thinking?

Order of events
1. Open TerracoinQt in server mode with the arguments listed in the OP
2. Start BFGMiner with the arguments listed in the OP.
4. Few seconds later a block is found, picture in the OP
5. No payment to the address listed in the arguments for BFGMiner in the OP has been about an hour since the block was mined

In the TerracoinQt client in the console typing

Code:

listtransactions

returns all of my transactions and none of them are valued at 20TRC, none of them even come close, they are all accounted for.

I have restarted the TerracoinQt client, but I will try it with rescan this time to see if anything changes.

[skeeterskeeter]

Using

Code:

-rescan

did not change anything.

[aa]

.

[skeeterskeeter]

Using

Code:

-rescan

did not change anything.

This time try -reindex.

same results.. 

[CoinEraser]

Are you sure, your wallet was sync, before you start mining?

[dreamwatcher]

Block explorers are great for tracking this stuff down: 

It looks like you are using a coin base address of : 15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s

http://trc.cryptocoinexplorer.com/address/15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s

The address does not show any coin-base transactions.



The new block being mined after your miner found a block was 197950, so lets assume the block your miner solved was 197949:

http://trc.cryptocoinexplorer.com/block/0000000000004167c0c73dd133fd04a97590e77d5e995861e1195519b27a5fa1

More then likely, the block you mined was orphaned (Somebody else solved the block just a short time before you, but it had not completely propagated throughout the network)

[skeeterskeeter]

Block explorers are great for tracking this stuff down: 

It looks like you are using a coin base address of : 15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s

http://trc.cryptocoinexplorer.com/address/15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s

The address does not show any coin-base transactions.



The new block being mined after your miner found a block was 197950, so lets assume the block your miner solved was 197949:

http://trc.cryptocoinexplorer.com/block/0000000000004167c0c73dd133fd04a97590e77d5e995861e1195519b27a5fa1

More then likely, the block you mined was orphaned (Somebody else solved the block just a short time before you, but it had not completely propagated throughout the network)

What do you mean by the address "15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s" has shown no coin-base transactions (do you mean Terracoin by coin-base)? I have used it many times.

So I mined a block a few seconds before/behind someone. But somehow theirs propagated to more people(nodes) faster thus making theirs the correct chain to follow?

Aww. My first block. Orphaned at such a young age. 

[dreamwatcher]

A coin base transaction generates coins. It is the only transaction type that can exist without an output TX(s) feeding it. It is also the only type of transaction that can be the first transaction in a block.

In other words, it is the transaction that creates the coins you mined. Since the block reward is 20 TRC, I can assume you have no coin base transactions at that address without looking into the individual transactions as you have no ~20 TRC transactions at that address.

The solved block with the earliest time stamp becomes the official block. Because we are dealing with a world-wide network, it can sometimes take a several to many seconds for the majority (including your local) daemon to see it and organize the chain accordingly. This was one of the biggest problems I faced writing CCE3, I would not discover a block was orphaned until a previous TXOUT was not valid on a current block. CCE3 now double checks every block every 60 blocks or so before committing the database to backup, and it finds a few orphans every day on every chain I have testing with CCE3.

[skeeterskeeter]

A coin base transaction generates coins. It is the only transaction type that can exist without an output TX(s) feeding it. It is also the only type of transaction that can be the first transaction in a block.

In other words, it is the transaction that creates the coins you mined. Since the block reward is 20 TRC, I can assume you have no coin base transactions at that address without looking into the individual transactions as you have no ~20 TRC transactions at that address.

The solved block with the earliest time stamp becomes the official block. Because we are dealing with a world-wide network, it can sometimes take a several to many seconds for the majority (including your local) daemon to see it and organize the chain accordingly. This was one of the biggest problems I faced writing CCE3, I would not discover a block was orphaned until a previous TXOUT was not valid on a current block. CCE3 now double checks every block every 60 blocks or so before committing the database to backup, and it finds a few orphans every day on every chain I have testing with CCE3.

Ok I see that makes sense now. Thank you for explaining that.

[RoadTrain]

A coin base transaction generates coins. It is the only transaction type that can exist without an output TX(s) feeding it. It is also the only type of transaction that can be the first transaction in a block.

In other words, it is the transaction that creates the coins you mined. Since the block reward is 20 TRC, I can assume you have no coin base transactions at that address without looking into the individual transactions as you have no ~20 TRC transactions at that address.

The solved block with the earliest time stamp becomes the official block. Because we are dealing with a world-wide network, it can sometimes take a several to many seconds for the majority (including your local) daemon to see it and organize the chain accordingly. This was one of the biggest problems I faced writing CCE3, I would not discover a block was orphaned until a previous TXOUT was not valid on a current block. CCE3 now double checks every block every 60 blocks or so before committing the database to backup, and it finds a few orphans every day on every chain I have testing with CCE3.

Really? I always thought that the client chooses the block which it received earlier, regardless of the timestamp. Then waits for the longest chain.

[dreamwatcher]

A coin base transaction generates coins. It is the only transaction type that can exist without an output TX(s) feeding it. It is also the only type of transaction that can be the first transaction in a block.

In other words, it is the transaction that creates the coins you mined. Since the block reward is 20 TRC, I can assume you have no coin base transactions at that address without looking into the individual transactions as you have no ~20 TRC transactions at that address.

The solved block with the earliest time stamp becomes the official block. Because we are dealing with a world-wide network, it can sometimes take a several to many seconds for the majority (including your local) daemon to see it and organize the chain accordingly. This was one of the biggest problems I faced writing CCE3, I would not discover a block was orphaned until a previous TXOUT was not valid on a current block. CCE3 now double checks every block every 60 blocks or so before committing the database to backup, and it finds a few orphans every day on every chain I have testing with CCE3.

Really? I always thought that the client chooses the block which it received earlier, regardless of the timestamp. Then waits for the longest chain.

It does, but will reorganize when it gets information to the contrary. The earliest time stamp has to win, otherwise the chain would be split constantly.

The client/daemon does not know it has an orphan block until it gets the block with the early time stamp or a longer chain appears. It will broadcast the orphan block out as the official block to other client/daemons that ask it for block information. So there can be few orphans on the network at a time, and all those daemons that are mining will be mining the wrong hash as the previous block hash is part of the header.

At any given time, depending on network conditions, a large chunk of the network could be working on an orphan chain. What happens if the next block between two chains also occurs at the same time? Both chains are the same length, which is the correct one?
The with the earlier times stamp where the split occurred is the correct chain.

Here is an example of a CCE3 log on a 30 second block target coin (GPL)

Code:

DEBUG:root:10-11 20:42:32  Sucessful Backup: 157482
DEBUG:root:10-11 21:45:24 Hash Mismatch: Database Restored 157515
DEBUG:root:10-11 21:46:03  Sucessful Backup: 157482
DEBUG:root:10-11 21:47:57  Sucessful Backup: 157608
DEBUG:root:10-11 22:46:19 Hash Mismatch: Database Restored 157615
DEBUG:root:10-11 22:47:06  Sucessful Backup: 157608
DEBUG:root:10-11 22:49:28  Sucessful Backup: 157733
DEBUG:root:10-11 23:42:31 Hash Mismatch: Database Restored 157749
DEBUG:root:10-11 23:42:57  Sucessful Backup: 157733
DEBUG:root:10-11 23:43:58  Sucessful Backup: 157858
DEBUG:root:10-12 00:48:37 Hash Mismatch: Database Restored 157903
DEBUG:root:10-12 00:48:58  Sucessful Backup: 157858
DEBUG:root:10-12 00:49:59  Sucessful Backup: 157983
DEBUG:root:10-12 01:47:26 Hash Mismatch: Database Restored 158012
DEBUG:root:10-12 01:48:56  Sucessful Backup: 157983
DEBUG:root:10-12 01:50:03  Sucessful Backup: 158110
DEBUG:root:10-12 02:58:15 Hash Mismatch: Database Restored 158126
DEBUG:root:10-12 02:58:46  Sucessful Backup: 158110
DEBUG:root:10-12 03:01:34  Sucessful Backup: 158234
DEBUG:root:10-12 04:16:34  Sucessful Backup: 158354
DEBUG:root:10-12 05:17:58  Sucessful Backup: 158474
DEBUG:root:10-12 06:18:31  Sucessful Backup: 158594
DEBUG:root:10-12 07:21:36  Sucessful Backup: 158714
DEBUG:root:10-12 10:09:25  Sucessful Backup: 158835
DEBUG:root:10-12 12:28:01  Sucessful Backup: 158960
DEBUG:root:10-12 13:16:55 Hash Mismatch: Database Restored 159019
DEBUG:root:10-12 13:17:17  Sucessful Backup: 158960
DEBUG:root:10-12 13:19:39  Sucessful Backup: 159088
DEBUG:root:10-12 14:20:22 Hash Mismatch: Database Restored 159133
DEBUG:root:10-12 14:21:17  Sucessful Backup: 159088
DEBUG:root:10-12 14:22:09  Sucessful Backup: 159212
DEBUG:root:10-12 15:13:51 Hash Mismatch: Database Restored 159255

Every time you see an entry of "Hash mismatch" is an occurrence where the daemon thought it had an official block, but it was really passing on information about an orphan block.

This is a log from XPM, an older coin then above with a minute target time:

Code:

DEBUG:root:10-02 17:45:19 Hash Mismatch: Database Restored 190508
DEBUG:root:10-02 17:47:35  Sucessful Backup: 190507
DEBUG:root:10-02 17:55:22  Sucessful Backup: 190805
DEBUG:root:10-02 18:39:35  Sucessful Backup: 190865
DEBUG:root:10-02 19:31:20  Sucessful Backup: 190925
DEBUG:root:10-02 20:11:28  Sucessful Backup: 190985
DEBUG:root:10-02 20:57:19  Sucessful Backup: 191046
DEBUG:root:10-02 22:13:05  Sucessful Backup: 191112
DEBUG:root:10-02 23:09:45  Sucessful Backup: 191172
DEBUG:root:10-03 00:05:22  Sucessful Backup: 191233
DEBUG:root:10-03 01:10:20  Sucessful Backup: 191293
DEBUG:root:10-03 01:57:54 Hash Mismatch: Database Restored 191340
DEBUG:root:10-03 01:59:16  Sucessful Backup: 191293
DEBUG:root:10-03 02:10:20  Sucessful Backup: 191353
DEBUG:root:10-03 03:10:06  Sucessful Backup: 191414
DEBUG:root:10-03 04:08:08  Sucessful Backup: 191474
DEBUG:root:10-03 05:25:07 Hash Mismatch: Database Restored 191494
DEBUG:root:10-03 05:25:40  Sucessful Backup: 191474
DEBUG:root:10-03 05:28:21  Sucessful Backup: 191539
DEBUG:root:10-03 06:40:46  Sucessful Backup: 191600
DEBUG:root:10-03 07:53:37  Sucessful Backup: 191661
DEBUG:root:10-03 08:46:06  Sucessful Backup: 191721
DEBUG:root:10-03 09:45:22  Sucessful Backup: 191782
DEBUG:root:10-03 10:50:54  Sucessful Backup: 191842
DEBUG:root:10-03 11:47:49  Sucessful Backup: 191905
DEBUG:root:10-03 13:02:39  Sucessful Backup: 191965
DEBUG:root:10-03 14:06:31  Sucessful Backup: 192027
DEBUG:root:10-03 15:13:22  Sucessful Backup: 192087
DEBUG:root:10-03 16:05:58  Sucessful Backup: 192148
DEBUG:root:10-03 17:14:22 Hash Mismatch: Database Restored 192171
DEBUG:root:10-03 17:16:30  Sucessful Backup: 192148
DEBUG:root:10-03 17:18:10  Sucessful Backup: 192214

Less often, but more often then one thinks.

Remember these are daemons that are not mining, and thus getting their info from the daemons they are connected to.

This is one daemon, think about the thousands and thousands of daemons running. The decision cannot be arbitrary, there has to be a solid constant to base the decision of which block is the official block and which is the orphan.