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.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.
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.
