skeeterskeeter (OP)
|
|
October 11, 2013, 07:19:51 PM |
|
I posted this on terracoin talk http://www.terracointalk.org/index.php/topic,443.0.htmlI have BFGMiner solo mining terracoins for me with the following arguments F:\bfgminer.exe -G -o http://localhost:18332 -u user-p pass--coinbase-addr 15uV6tXPZRPgVxUpKeshgUgnkLHM35pK5s I also have TerracoinQt opened in server mode. 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)?
|
|
|
|
|
|
|
"There should not be any signed int. If you've found a signed int
somewhere, please tell me (within the next 25 years please) and I'll
change it to unsigned int." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
Eli0t
|
|
October 11, 2013, 07:23:51 PM |
|
check listtransactions in the debug window in the qt, probably an orphan or if not needs more confirms
|
LTC: LKpJf3uk7KsHU73kxq8iFJrP1AAKN7Yni7 DGC: DKXGvEbj3Rwgrm2QQbRyNPDDZDYoq4Y44d XPM: AWV5AKfLFyoBaMjg9C77rGUBhuFxz5DGGL
|
|
|
skeeterskeeter (OP)
|
|
October 11, 2013, 07:39:31 PM |
|
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
|
|
October 11, 2013, 07:59:25 PM |
|
listtransactions should say if its orphaned or immature
|
LTC: LKpJf3uk7KsHU73kxq8iFJrP1AAKN7Yni7 DGC: DKXGvEbj3Rwgrm2QQbRyNPDDZDYoq4Y44d XPM: AWV5AKfLFyoBaMjg9C77rGUBhuFxz5DGGL
|
|
|
skeeterskeeter (OP)
|
|
October 11, 2013, 08:09:15 PM |
|
listtransactions should say if its orphaned or immature
listtransactions does not show any transaction amounting to a reward (20TRC).
|
|
|
|
aa
|
|
October 11, 2013, 08:25:59 PM Last edit: August 02, 2014, 09:44:50 PM by aa |
|
.
|
|
|
|
skeeterskeeter (OP)
|
|
October 11, 2013, 08:37:12 PM |
|
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 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 (OP)
|
|
October 11, 2013, 08:43:23 PM |
|
Using did not change anything.
|
|
|
|
aa
|
|
October 11, 2013, 08:58:20 PM Last edit: August 02, 2014, 09:44:53 PM by aa |
|
.
|
|
|
|
skeeterskeeter (OP)
|
|
October 11, 2013, 09:13:00 PM |
|
Using did not change anything. This time try -reindex. same results..
|
|
|
|
CoinEraser
Legendary
Offline
Activity: 1988
Merit: 1718
|
|
October 11, 2013, 09:34:11 PM |
|
Are you sure, your wallet was sync, before you start mining?
|
|
|
|
|
skeeterskeeter (OP)
|
|
October 12, 2013, 06:19:54 PM |
|
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
Legendary
Offline
Activity: 1064
Merit: 1000
|
|
October 12, 2013, 07:33:08 PM |
|
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 (OP)
|
|
October 12, 2013, 07:55:40 PM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
October 12, 2013, 08:56:22 PM |
|
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
Legendary
Offline
Activity: 1064
Merit: 1000
|
|
October 12, 2013, 09:35:29 PM |
|
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) 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: 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.
|
|
|
|
|