My thoughts are as follows.

TimeCoin

Provide quality distributed timing system through a cryptocurrency and blockchain system. Possibly to be used as a marketplace or micropayment system for accurate low load NTP like services. Perhaps provide easy systems for other blockchains to reference the TimeCoin blockchain to allow difficulty adjustments with minimal block latency.

Main Chain
A standard blockchain with PoW system, along with the ability to lock a batch of coins under an address in order to become a Time Provider.

Clock Chain DAG

This is a sort of graph built between main chain blocks and summarized in the next block that records information about the propagation of the previous main chain block and the current Time Provider clocks.

Each time a Time Provider with a TimeCoin stake receives a new top main chain block, they immediately create a timestamp of when they received it. They then sign a message and sends it out to each of their Time Provider Peers, that peer immediately signs it and sends it back with their own timestamp included. The originator again signs it with a third timestamp when it returns. They can then submit this as an entry on the Clock Chain.

Only the lowest value for time a block is seen in the DAG is valid, normally DAG miners should not include new entries from a Time Provider if there is one in the DAG with a lower initial value, but a DAG block with such an entry with a valid proof of work will be valid, but only the valid minimum block time will be considered valid for future computations.

By taking these entries, one can build a directed graph that shows the links between the different time providers, and the latency between them and follow the block’s path through the providers. Lets consider the timestamp when a provider name Alice received a block as 1A, a remote client, Bob’s response timestamp as 2B, and finally the return time as 3A. While one way latency could be an issue, Timestamp B2 should be created about half way between A1 and A3. That can be used to calculate a clock offset between the two parties. Starting with the transaction with the lowest timestamp for receiving the block, one can step through all the nodes and calculate their average offset from all the nodes they are connected to. I am sure there is a lot of analysis you could do here beyond my immediate thoughts, but experementation would likely be required to find an ideal system, but the general idea is to find the median clock time a block was found weighted by the reputation of the Time Providers.

Ideally highly accurate offsets could be calculated along with a confidence +- for propogation times could be used to get times under a millisecond.

Finally, the reputation reward is calculated for the Time Providers and distributed based on their standard deviation from this median and their stake size and a summary is produced referencing the top block of this DAG. Larger total visible stake entries in the DAG means greater total reputation increase. The total stake of the entries, weighted by the reputation, along with the total amount of work shown in the DAG summary included with the block reduces it’s difficulty to incentivze miners to include the largest DAG in their blocks even if it means having to regenerate the block header.

The DAG proof of work is a very low difficulty, and the DAG is expected to grow quickly, each group of timing entries are passed to the peers and there is a rush to combine them into a larger graph, but the more total entries in that graph, the more work needs to be done to combine them. A miner can take two graphs that partially intersect and join them together, or add any number of other entries to the graph. When another main block is found summarizing the DAG, a proportion of the block reward is split among all DAG miners based on how much weighted entries they added to the graph. Nothing but work nodes are accepted as work, but are not rewarded. All the time providers are also rewarded for the entries they made and how close to the median time they were.

The full DAG information can be discarded after some number of blocks as long as the summary or database of Time Provider clock offsets and reputation remains valid.

A minimal client could be used that keeps only the last few blocks of the blockchain, and uses the time a peer reports a new top block and the time that block being reported seen by time providers on the DAG to set system time and pacing, perhaps as an NTP plugin.

Time Providers and the Start

The idea behind this is that as the blockchain grows, time providers will gain reputation for consistent accurate time. They could then present a message on the block chain listing their hostname or IP address for more traditional NTP service. There are several ways the system is protected against attack. First the Time Providers must have a stake. This limits their number to some extent, and they grow in reputation as long as their time is accurate. There is a lot of stake needed along with computing power to control the DAG, and since a small DAG means difficult main chain block, miners or pools will have difficulty hiding blocks or building up a private chain as they need the staked high reputation time providers to provide them DAG entries needed to reduce difficulty, and the network could reject blocks with timestamps more than a minute or so off the current time. Another thing is that if a high reputation time server is hacked and the private key stolen, if someone attempts to use that server to steer the network away from the proper time, if a backup of the key could be found it could blacklist itself making that private key unusable as a Time Provider (the coins would have to be sent to another address with no reputation to be used as a time provider again).

The difficulty adjustment function would be a lot faster and a lot more complex than other chains, incorporating the average timing entries in the DAG and the DAG hashrate which drives down the main chain difficulty, along with an estimate of main chain hashrate considering that hash power may switch between them depending on the payoff. Another thing is that with fairly accurate time estimate of when the last block was found, it could be left to pay the base block reward based on the DAG summary that includes when it was seen on the network meaning you could pay out exactly 24 TimeCoins a day or whatever for the emission curve you desire, and use some sort of PID function to control the longer term emission rate. Transaction fees for transferring TimeCoins would be paid out immediately such that block times would shorten as fees rose.

Scalability is a concern and would likely require testing and experementation. With large numbers of Time Providers connecting to each other, the number of DAG entries could be quite large, and even the summary could be large. Short main chain times could cause the full blockchain to grow very large very quickly, but that's a problem that's not stopping a lot of other coins. Individual Time Providers may be able to tag themselves in peer lists as private, which means that they should not be expected to be listening for connections and they may not relay blocks or other notices to the network in order to reduce load and latency to provide a more stable time by selectively choosing fast nodes in the system.

As for starting the system. There could be a few genesis nodes which are hard coded to be equivalent to high reputation medium stake nodes which are specifically created for getting the system started. These make sure that while the quantity of TimeCoin is low and reputations are low that the coin can have an accurate base to start with.

Economics

I have no idea of the economics behind the coin itself. Theororetically this sort of blockchain could be used to buy access to premium time sources, perhaps through creating a lightning network like payment channel and then paying for individual NTP queries to high performance servers, or of course more generally be traded on exchanges and the like. I know that many other utility blockchains like NameCoin never really went anywhere, (err. I must have mixed it up with something else, but NameCoin is doing decently at some 60 million market cap, but there is less demand for decentralization of NTP since it's more about providing accuracy than the rules and regulations around it). I also know that well configured NTP clients communicating with centralized NTP servers are highly accurate these days, the blockchain would create a self selecting self correcting time system that could be used as a reference for distributed systems like other blockchains that need a good decentralized time system.

Anyways, any thoughts on this would be appreciated.

So my understanding is this is not really mining in the traditional cryptocurrency sense, but rather a tokenization of effort on a distributed computing platform similar to GIMPS or BOINC. Like how GIMPS lists your Ghz days, but in that service they are just a status symbol or badge to show how much work your computers have done.

I cannot find however what blockchain the tokens are on however. Are they going to be part of a contract on the Ethereum blockchain where your group has the crytographic keys required to generate new tokens to send to people who make withdrawals? Or is it on some other blockchain?

Thanks

Yeah sure: https://1drv.ms/x/s!AoILQjreP68U6kpd-5eG5Dya6CNW

I had some problem where the file disappeared somehow, so the old link became stale, but I had a copy on my local machine so copied it onto the web again.

Cron @reboot or a service description are your best options under linux.

If you are solomining, you have to wait for 60 blocks before the balance is unlocked. So you need to until after block 2300. Same as how the pools cannot pay out anything until 60 blocks later. With the slow blocks lately, the most recent blocks to be unlocked have been around 10 hours ago, and you can expect recent ones to take 6-8 with the split network hash rates.

If you still have a locked balance matching an early payout from xao.miningpool.host, check your wallet under: list_transfers . There should be a replacement transaction for the same amount as the failed transfer around 2018-01-04 06:40:00 placed in a block around 1440 or so. If that is the case then that payment made it to your wallet balance, and you can do a reset to clear your wallet's cache of the old failed transaction with id: d521f792c1b086b20973f9e0908f9a006bec4470fd8d52cd981a502ec0bc2c2f or ec2e9f954832b2a82edaf15781fe8f3c62c60716f2e32315da24ab5c13164531 and get rid of the locked balance.

I have been watching difficulty and block times, and while there is a little added hash rate every once in a while, things seem pretty tame. My charts are here: https://1drv.ms/x/s!AoILQjreP68U6j_Vq3KFcPl63ci6  Check the tabs at the bottom for hash rate charts.

Difficulty is based on the average observed hashrate for a 360 block window that lags the current blocks by about 60. The blocks themselves come in as a Poisson distribution which is very difficult to analyze accurately due to the high randomness. At least one of the pools still has a target block time of 120 causing a 50% higher network hash rate to be displayed, but that should not affect the local hash rate. You can only expect 1 - (1/e) or about 63% of the blocks to come in under the expected time listed by the pool, and you can regularly expect ones to come in much later than that. You can take a look at my charts here for more detailed block times and hash rates: https://1drv.ms/x/s!AoILQjreP68U6j_Vq3KFcPl63ci6 (Check the Hash Rate charts sheet at the bottom for shorter average network hash rates).

As for pool payouts, you can expect it to take 2-6 hours (a little over 4 hours at the time of this writing), depending on block times for a mined block to get 60 confirmations and show up in Pending Balance, and that's only after the pool finds a block after you start mining there.

PS: The other thing to note about the "Block Found: 3 Minutes Ago" display on the mining pools is that it often shows when the block before the last one was found since it uses the last blocks timestamp. Because when a new block is found, the template for the next block is created and sent to the miners, including a timestamp; it shows when work started on that block not when the work finished on that block.

Here is a graph of difficulty and block time. If anyone finds it useful.

https://1drv.ms/x/s!AoILQjreP68U6j_Vq3KFcPl63ci6

I think a lot of that was folks jumping in before the difficulty could meet the hash rate. I expect this coin will run into the same problem as sumokoin did as described under "Old Code, New Problem" here: https://medium.com/sumokoin/sumokoin-development-path-2c5e0fd1b0fa

Make sure you set block maturity depth to 60 so that your pool does not try to payout coins that are still locked. Also if you have any control over it, limit the payout transaction size to 20Kb or 20480 bytes. PS: Not sure if the coinbase and headers is counted in blocksize, but it might be safer to set it to 10KB or 10240 to be on the safe side.

The first two big payouts from your pool:

id:
blobSize: 35462
fee: 0.000100000000
keptByBlock: F
max_used_block_height: 854
max_used_block_id: <6a6111f8f87319e2084fe7b047f625439fc960e8262c6692636d9264222112d0>
last_failed_height: 0
last_failed_id: <0000000000000000000000000000000000000000000000000000000000000000>
received: Tue Jan  2 17:45:08 2018

id:
blobSize: 39382
fee: 0.000100000000
keptByBlock: F
max_used_block_height: 789
max_used_block_id: <5296a88392ec5819b5403cd843d77d17362152e805a0aa82847a4b27f5ed7161>
last_failed_height: 0
last_failed_id: <0000000000000000000000000000000000000000000000000000000000000000>
received: Tue Jan  2 17:03:50 2018

Both sitting on the transaction pool. Both too large to be put in a block at current blocksize limits which are very close to the initial block size limit of 20480. I think it's unlikely for it to grow before the transaction timeout of 24 hours.