Vertcoin - First Scrypt N | First Stealth Address

Regarding CPU miners being presently left out:

(and I'm writing this because I am one of them, or will be shortly as hash rate increases, but I certainly have not read earlier discussions of such designs).

Is there a testnet with a larger N-factor (call it N+K-factor)? People with fast CPU's and lots of memory (say, 32G) might be able to run the algorithm. Where is the N-factor specified in the vertcoind code?

The problem with using N+K-factor is that all network nodes seem to need to verify all the hashes. Is it really impossible for older CPU's to evaluate the NK-hash in a reasonable time? Or perhaps the NK design will be such that they only need to verify N-hashes.

The goal is to find something useful for N+K-factor miners (NK-miners) to do, and a way to reward them for doing it. One useful purpose is to make it adequately hard for the new generation of hardware to rewrite the early block chain, without depending on a central authority to set checkpoints.

Since the NK-hash is hard to calculate, we will specify say 50 NK-chains, each running 50 times slower than the N-chain. (Think of 50 as a parameter, named with digits instead of some Greek letter). Name the NK-chains NK₁ through NK₅₀, or NK_k for k in 1 to 50. The NK-blocks of NK₁ link to N-blocks 1, 51, 101, etc. The NK-blocks of NK_k link to N-blocks k, k+50, etc. Of course, block x of an NK-chain links back to block x-1 of that chain, but it also links to a block of each of the other NK-chains. The block is orphaned if any of these 51 linked blocks is orphaned, but conversely, the existence of the block may inhibit the orphaning of the linked blocks, since the height of each is increased.

NK-miners may work on whichever chain they think will be most profitable, but to extend NK_k to x blocks, the N-chain must be at least at block k+50*x, and the other NK-chains must be at most one or two blocks back. The miner would decide to link to the latest block on a chain if he mined that block, or because choosing later blocks raises the height of his working block, or he might pick an earlier one to avoid being orphaned should the other NK-block be orphaned.

Thus, when a new N- or NK- block arrives which extends one of the side-chains the miner is linking to, the miner might decide to link to it from his current block, or he might continue linking to the predecessor of the new block. If a block arrives extending his own NK-chain, he would probably switch unless it orphans an earlier block owned by the miner.

As usual, each NK-miner writes his own payout address into the NK-block he is working on, say block x of NK_k. This payout will not occur until an N-miner links back to NK-block x, and includes the transaction, but N-miners will want to do this for two reasons: they get part of the payout, and the height of their block increases because it extends the NK-chain as well as the N-chain. Balancing this is the risk that the NK-block could be orphaned. Each N-miner might want to consider this when deciding whether to switch to extending the new N-block, or to try to replace it.

Calculation of the height of a given N-chain branch includes any NK-chain blocks it links to. Conversely, an N-block is invalid if it links to an NK-chain containing any invalid NK-hashes. So N-miners need to check the NK-chain before they can safely accept the height increase and block reward arising from linking to it. If they cannot check it, or they decide to spend the time N-hashing instead, either they guess it is valid, or they forgo the height increase and extra block reward.

Clearly this can't be implemented quickly, but it could be a retrofit, and the NK-chains could start much later than the N-chain.

Meanwhile, it looks like I will receive 7.983990 vertcoins from ny.vertco.in and 2.962639 from la.vertcoin.org for about a day of mining.