You seem to be right- at least for current nFactor:
I mostly get Hardware Errors on my GPUs. Rarely there is a accepted share, but with hashrates of 3Hash/s (on R7 240 4GB GPU), which equates performance of one modern CPU core.

Would it be possible to modify OpenCL code so that it would verify block hashes in parallel?
I presume if a GPU has 6 compute units and 2GB of memory it should be possible to do at least 6 parallel scrypt-jane block hashes (while one hash consumes 128MB of memory). The goal would be to offload CPU with chain validation.
I tried to dig into it, but it's a big bite for me.

Since yesterday (aug . 8th), yacoin network is on nFactor 19 where each hash consumes 128MB of memory.
Next switch is after three years - in october 2020.
My CPU hashing speed has fallen from 6->2 hashes/second (per CPU thread).

I am waiting for new GPU platform so currently I am unable to test GPU mining speed.
Can any of you comment how are GPU cards doing (compared to nFactor 18)?

In the past.

It depends on PoW hash rate (consequently PoW reward), PoS block count (influences PoW emission rate), new features ...
I'd say from 150-350M.

http://forecast.yacoin.net

It seems folks who kindly produced blockchain lately have either given up or are mining in background. Last couple of days blocks produced by community are getting excepted. Reward is high and hashrate is low. Join in if you dare.

In response to Old C coder's messages.


Yes and no. Increasing PoW diff after PoS block hasn't changed from peercoin. You need a way to push one type of blocks apart (PoW) in order to accommodate more blocks of a different type (PoS). And if community had enough hashpower, higher diff would not be a problem, since block mined like that would get more trust due higher difficulty.


In a way, that is what one of the fixes accomplishes - but so that it does not hurt chaintrust of "community" blockchain.


NO NO NO.
If you have a chain with one week of mixed PoW-PoS-PoW-PoS blocks, PoW target spacing then amounts to two! minutes.
Time is later considered in equation as difference from two previous blocks of same type. If those two previous PoW blocks from example are less than 2 minutes apart, difficulty is raised.

PoS is always fixed at 1 minute so the chain wants to "become" like this :
PoS-PoS-PoS-PoS...
(by having algorithm push PoW blocks apart by raising difficulty after each new PoS block arrived)


That is what chaintrust (sum of GetBlockTrust values of each block in a branch) is all about. This is a tricky part for any hybrid. A quick overview is here, but a lot more has been talked about on yacoin dev thread.



Regarding "lower hash" it's easy to compare two blocks at the tip of a chain for lower hash. But when you have two block branches of 20(or 2000) mixed blocks each you need to quantify those "differences" with some non-exploitable formula.
Then you can also have two mixed type block branches mined on lower difficulty - and you need to compare against them too somehow.

I agree figuring out what the code does can be difficult. I've been analyzing it for almost a year, since I was made aware of it's flaws.
Perhaps it would make more sense if I mentioned method's signature:


Second input parameter also determines block type on which pIndexPrev and pIndexPrevPrev point. When you generate nBits for PoW block, you pass false. pIndexPrev then points to PoW block as does pIndexPrevPrev.

That is why I've written:


That really means: "Just pass true for fProofOfStake"   



Time is taken into account later in the same function. First nTargetSpacing is calculated. Then real time difference is thrown into equation. If those two blocks pointed by pIndexPrev and pIndexPrevPrev are less than nTargetSpacing apart, difficulty is raised (nBits get's lowered).


Chaintrust is what I had in mind. It's all over there.

GetNextTargetRequired method is used to generate nBits (target in compact format) twice:

1. when creating new block
2. when checking if nBits of a block (could be any block in a tree) conforms to algorithm


When creating PoW block (1), pIndexPrev is a pointer to last PoW block in best chain. If there is PoW block at the tip of the chain, then pIndexPrev = pIndexLast, otherwise we have to search for it backwards with GetLastBlockIndex method. pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.


When checking if nBits of a PoW block conforms to block generation rule (2) then pIndexPrev is a pointer to PoW block preceeding it. And as before, pIndexPrevPrev is a pointer to PoW block preceeding pIndexPrev.


The same principle is used for PoS blocks. Just replace all occurences of PoW with PoS in text above.



What "(60 seconds)*(1 + pindexLast->nHeight - pindexPrev->nHeight)" does in case of proof-of-work blocks, it multiplies number of PoS blocks between last PoW block and the one before with 1 minute. If there are no PoS blocks between, then
pindexLast = pindexPrev and height difference in equation equals 0. PoW target spacing is then set to 1 minute.


Yacoin has 1 minute PoS block target spacing.
But PoW block target spacing always was dynamic and it get's wider (PoW difficulty gets higher) in proportion to PoS blocks between last two PoW blocks. It stops growing when 12 sequential PoS blocks are let in.

After PoS block is accepted, target of next PoW block gets adjusted towards 2 minute. Change in difficulty is incremental (exponential retargeting). Nevertheless, selfish miner can mine on lower PoW difficulty if he ignores PoS blocks.


Overall, setting block spacing is only one part of operation. In essence it prescribes block targets for a valid branch.
Currently there are bigger problems with chaintrust calculation - giving correct score to multiple valid branchees thus making possible for peers to choose the best one.

Such type of block spacing calculation is already coded. Again, Link. It's just that blocks sequences with fair, community composition don't score enough chaintrust to be considered "main" by peers.


Cooking can be referred to mining or minting. We could also proof-of-stake cook more often, if our blocks wouldn't be ignored.
And what if main chef decides to ignore transactions?


Described here. I am just not sure if presumption about PoS blocks with more stake ever got more trust than those with small stake.

Yacoin is based on Novacoin and that means fast proof-of-stake algorithm - the goal was to eventually accomodate as many PoS blocks as possible kept one minute apart on average. But also to keep PoW blocks at 10 minute spacing. That would one day accomplish ultimate decentralization with proof-of-work "checkpointing" every 10 minutes.
If I am not mistaken, here is how pocopoco's source basically controls it and that didn't change from launch.

Fixes I made also strive towards that goal.

Last time I checked there were near 11x more PoW blocks than PoS blocks. Making PoW-PoS-PoW-PoS order mandatory would probably cause long delays while waiting for PoS block.
There could be other problems too, depending on addressing issues with small PoS blocks.



Yes, hard fork is needed. I am certain we can't fix all problems without it.

Changing how particular peer mines blocks does not change much - bad miners can edit code, build their own release and produce blocks as they please.
True fix has to be implemented in rules peers use for filtering and accepting those blocks.

My commits do that in two ways (will be three eventually):

• by sharply raising expected difficulty after consecutive PoW block count exceeds ( I refer to this event as overstep ) adjusted PoW/PoS ratio. Here.
• by giving PoW blocks after PoS block higher trust value - higher than currently here (not implemented yet, but it should be only a small change)
• by cutting each overstepped block's trust value in half. Here.

That means branch with less PoS blocks not only scores less chaintrust, but it will be also harder to mine.

All three main fixes I made address this issue, each in it's way.
However if someone holds enough currency and has enough hash power he can produce alternate branch with higher trust even after upgrade.
Currently our selfish miner sits on more than enough hash power and each minute he is gaining future stake.

p.s. While importing data in previously announced release(EDIT:code,not release), I found a bug after block 420000 and made a correction here and than I rebased that branch.
currently I am importing again and nearing block 500000 and it looks ok so far.

Could you please post optimal configuration for this card?

old c coder, I considered your comments and realized you made very substantial arguments.
Therefore I've made changes:

GetPoWPoSRatio() function now returns double, and there is new GetSpacingThreshold() function that adjusts, rounds and converts that ratio to integer.
Now Proof Of Work target moving average does not get stored in PoS block's nonce attribute. I've added to CBlockIndex class new member nBitsMA for that purpose. Like you said - having it in PoS block's nonce was not needed, and second: I think it is even better, if we can keep PoS nonce at 0 and force PoW blocks have nonce>0. That is how we will be able to easily differentiate blocks in future and derive chaintrust only from headers.

Next I've managed to complete code upgrade. I've split github commits into logical contexts. I suggest you start scrutinizing from oldest one on, because that functionality get's reused in later commits.

Last commit will need to be explained, but in short: it deals with small value ProofOfStake blocks in a way Balthazar mentioned more than a year ago (the need to make attack energy expensive). I had a complex solution for that, but then I came up with a better one: reuse scrypt-jane and transform stake kernel hash operation to use memory(scrypt-jane) for hash, and stakeNfactor used gets calculated from stake kernel value. I also introduced new higher dynamic threshold - you now need more than 20 coins (in one input) to generate stake and that value is incrementally increasing. Again, a lot of explaining needed here, also regarding optimizations...

First, I need proficient eyes to take a look and raise flags on possible obvious errors.
Unfortunately I do not have resources to test this, so this is done kind of Beethoven style (after he went deaf).
But I think we can make it work.

here:
https://github.com/senadj/yacoin/commits/smallpos

I hope it will give a lot of hash power - this was couple of hours ago:

Updated GetNextTargetRequired function, this one takes care of "resetting" difficulty after PoS blocks.
Also updated code for raising difficulty of overstepped PoW blocks. In color:

http://yacoin.net/NewPreventPosIgnore3.htm

Thanks Ron, that looks much better than I expected. I hope this will get into new release.

instantiated only from CBlock::AddToBlockIndex()  is my comment - I've made it while I've been checking constructor usage. And I forgot to delete it. It has no higher purpose. Sorry.



If you mean pIndexBest - perhaps you also need to check current testing version source from github to make more sense. But yes, best chain is a valid one with highest chain trust.



Having nPoSBlockCount stored only with PoS blocks takes less disk space (10 times less PoS blocks now). Besides if ratio would be 9.9999 at PoS block (rounded down to 9 due integral type) and after long sequence of PoW blocks back to 10 - and after next PoS block 9 again - that I did not want - I was considering removing noTwoConsecutivePoSBlocks rule when ratio hits 3 and I did not want that to float back to 4. This is only theory anyway, I might have missed the point completely.



This value later dictates number of consequent PoW blocks after PoS block, after which difficulty jumps and trust falls.
Having it truncated also forces PoW blocks window to "shrink" a bit sooner than real ratio would, thereby stimulating PoS block inclusion.
Decimal value would cause unnecessary conversions in calculations later.




I wasn't sure what you get if you call GetLastBlockIndex( *, true ) before first PoS block or when a bug was present. I did not want to allow division with zero so I returned 0 before next step. GetPoWPoSRatio() should always be called only on PoS blocks. And not before we switch to new version. Feel free to advise on best correction.



Are you asking, why we need that ratio?
As you know PoS blocks can be ignored by PoW miners. My fix goes like this:

1. Take the current PoW/PoS block ratio
2. Count PoW blocks after PoS block and if it gets over that ratio, incrementally raise difficulty and lower trust.



I would not swap order. I would swap their content.
In my code, PoW block target moving average is now stored in PoS block nNonce (instead of current 0).
If it would be stored in PoS block nBits, we could later calculate approximate chaintrust from block headers only.
Currently PoS block nBits attribute holds PoS block difficulty and that would need to be moved and code changed. But moved where? nNonce is the only candidate left.


The problem is, you can only partly differentiate PoW block from PoS block if you do not have transaction data, only headers (because there are some PoW blocks with nNonce=0 and there are some PoS blocks with target < bnProofOfWorkLimit). And you can not mix and aggregate their targets (nBits) to arrive at final chaintrust value without knowing what "type" of nBits you are operating with.




Headers-only method has a well documented purpose. The need for it will be even more aparent with Yacoin than with Bitcoin.
There could be other and better solutions, that is why I wanted feedback.



I don't know how to quickly and repeatedly get PoW/PoS ratio now without scanning and processing ever growing now 1M+ items long hash map. Please let me know.



We'd like that to change one day. Wouldn't we?



No, you are not different. This is just not industry anymore. I am learning C++ while fixing yacoin. Imagine how much I am getting paid for extensive analysis design and documentation.

Thanks for your input. You are welcome to elaborate.

Regarding your version with integrated explorer: I do not have QT installed and haven't programmed with it ever. Would you mind posting a screenshot or two?
Another thing I wanted to ask - why not use http://msinttypes.googlecode.com/svn/trunk/ in MSVC release? Wouldn't that cut down number of ifdefs and make a code more compatible?

Speaking of new code:
I updated GetBlockTrust and added GetNextTargetRequired changes.

That encompasses two (out of three) major changes we need to patch yacoin.

What I would like to do next is talk about my next goal: Before these changes go in effect, I would like to do more refactoring (prepare, this might hurt a bit) and swap PoS block nNonce and nBits.
And the reason has to do with what I believe will be one of next major yacoin issues - future implementation of Headers-first method. Hard fork is the only right time to do such things. This way we can make it possible to determine chain trust from headers only (once you understand the changes I linked to), otherwise all clients will need to download and process full blockchain. This will become very time and resource consuming with each next block - and yacoin system generates a lot of them.

However, before I start,  I need some feedback from community - do I have your support? Will I get any help? Opposition?
And please check out two links above.

Yes, few consecutive PoS blocks got so much trust together they could overwrite hours of PoW blocks if they were not released immediately. But that only because each PoS block got a lot of trust in a first place.


I wasn't describing that, although I think it wouldn't be bad if we'd get rid of this rule eventually. Besides, new code does not prevent them.

Remember that unreasonably high PoS block trust value was the reason why we needed Sairon's fix.
I thing it should be higher than now (prevPoWBlockTrust+1), but less than 2*prevPoWBlockTrust.
If higher, then mischievous PoS miner can withold each block, wait for receival of two new PoW blocks and then broadcast his with certainty that it would kick out both of them. That by itself is a small weakness.
But PoW after PoS block should keep it's trust doubled as it is now. This amplifies previous PoS block value in more "democratic" way.

I have been thinking a lot about this and my conclusion is that the more we try to award particular block/combination, bigger the chance someone will abuse it in his favor.

Here is more completed new functionality:
http://yacoin.net/NewGetBlockTrust2.htm