Topic: [ANN][YAC] YACoin ongoing development - page 94. (Read 380091 times)

Sure it was. Maybe even earlier.
Just saying that C++0x was already standardized (and renamed) as C++11.

I don't see the problem here. g++ 4.8 is already available even for that windoze crap.
BTW, libbitcoin has a much nicer/cleaner codebase. I'd like to see new alts based on that.

Bitcoin was written during 2008-2009.

C++11 doesn't work sometimes. Just because there are only a few compilers supports it and this support is still under active development. It's easy to write C++11 code for g++-4.8, which will be impossible to compile with 4.6, for example.

It's C++11 already.
Oh well, at least it works, somehow...

Maybe Satoshi need to learn some features from C99/C++0x/boost to write a readable code without portability issues. But it's definately not a crap.

Anyway, I have no problem with understanding a Bitcoin code.

Whatever. The whole Bitcoin codebase is crap anyway.

Hm... Just checked your sourcecode. It seems too overcomplicated for me, actually. This issue could be resolved with less than 10 additional lines of code. Maybe even 4-6 lines...

Already done.
Didn't know it was in NVC, though. Would have been easier to pull the changes rather than write it from scratch.

2 all

Guys, I suppose that you need block hashes caching , this approach would allow you to reduce startup time significantly (30x-100x times at least). This could be done through merging with NVC blockindex code and addition of your network rules.

I think this will resolve all your performance issues.

Here are my refined strategy concepts now partly borrowed from Satoshi:)


When PoW block arrives modulo operation is executed on last 4 bytes of the hash. If remainder equals zero, PoS window opens. Divisor would determine chance of that happening and it could be:

a) static (with optional hardcoded decrements on Nfactor change)

Miner gone bad would need to hash like crazy (even many times the same block EDIT: after one hash is found) in order to meet conditions that would allow him to pack more PoS blocks in the chain.

b) dynamic, derived from PoW block difficulty

Difficulty extracted from last PoW block combined with N factor,  both input into modulo operation would influence chance of PoS block window. Normally high difficulty and considering N would be set to produce a chain with more PoS blocks. This way the chain would balance itself through time ( more widespread yacoin usage -> high hashrate -> high difficulty -> higher chance of success for PoS blocks windows ). Determining N factor change implications would be challenging at least, since that lowers difficulty at first in spite of  more miners.

If longer chain fork is announced and it's blocks do not connect anywhere in the recent past chain is rejected. If it connects, the pattern of PoS windows is inspected and PoW blocks difficulty of both forks is compared.



I have another dynamic solution in mind, where delayed difficulty cumulative moving average (DCMA) would be used in PoS window calculation.

Record of delayed running DCMA would be calculated and kept up-to-date until the time of approx. now-2000 blocks. That number would be transformed and merged with last 4 bytes of PoW hash before modulo operation is executed. Effectively we would be "encoding" average PoW block difficulty from the past into the criteria for PoS block window.

It would be nearly impossible for the rogue miner to hash on low difficulty far in the future and then switch to high difficulty - he would need to guess DCMA at the publish time of his chain (minus 2000 blocks) in advance, because that is how chains would be compared if his fork signals to be longer. If new blocks start orphaning many of our blocks, "headers" call is invoked and latest 2000 headers are fetched, their start time determined, corresponding DCMA for that start time acquired from our records (or even calculated from history data if operation is not too expensive) and then PoS windows pattern checked if it fits the formula. To accomplish that we would also need to keep a small rolling window of delayed DCMAs.

This last method would sure need more analyzing, planning and discussion. It would be hardest to implement, but from my understanding would offer trustworthy chain compare method.


Independently from the chain trust concept just mentioned above I have been also considering higher number of PoS windows than average (or needed at specific time), but not making them all mandatory - some window criteria matches would just "award" incoming PoS blocks with desired trust score. This way it would be possible to impose minimum PoS block occurrence threshold while at the same time making possible for more PoS blocks to be accepted in the chain (when window opens). But that would at least to some degree mess with the concept explained above.


I hope my explanation is understandable -  I have looked at source code and tried to grasp the functioning but it's not that trivial for a rookie. Except for DCMA method, not a lot of code would need to be written but that wouldn't bring solution for chain trust either.

Well, the current system isn't safe from doublespends so that's the main motivation behind this.
Question will be how to fix this mess here, or if there's even an acceptable fix for it.

PS: A big part of the problem is that "there is hardly any POS at all"

I absolutely agree with the ratio of 10:1 and when you think about it, it's more like 20:1 at least. We do not have many POS in YAC now at all, I do not understand why the sudden rush and madness to "fix" POS when there is hardly any POS at all. Has anyone looked at the blockchains that we are comparing YAC to, meaning PPC and NovaCoin, they are 90% POS or more.

Is there are alternate motive behind all this?

I'd think you'd want the good chain to maximize as much as possible its score. So either 1:1 ratio, or the max score should be when ratio is 10:1. E.g. PoS score increases the more PoW ancestors it has, maxxing at 9, then PoW score decreases the further away it is from a PoS, up until 9.

If anyone can see some problems with the scheme, please post about it sooner rather than later.

I would leave the target spacing for PoW and PoS as is. It really doesn't matter anyway with this scheme, so why bother.

As far as I can see now, using difficulty as score for POW blocks, and let POS blocks inherit that score from the previous POW block is a good enough solution for the problem on hand. Whether one POS block following another POS block is explicitly ruled out or not, I think it should be ok either way.

The Novacoin solution of encouraging a hybrid chain only make sense because they have 1:1 POW:POS blocks ratio. YACoin is 10:1 with POW:POS. You'll need to check pretty deep into the past to encourage a 10:1 ratio. The score consistency problem I mentioned above could lurk in such schemes. Of course, we can also talk about the POW:POS ratio if people want to change it.

And none works well AFAIK, that's one of the reasons PPC is centrally checkpointed ATM. Please, correct me if I am wrong.

There are enough possible solutions and BCP is not a one of these. It's just a workaround.

Considering pools are a source of risk in themselves for little advantage to the network, that's not a problem.

Why not use centralized checkpointing ?? That's what PPC does because there is no solution to the problem (yet).

I didn't think forcing alternation was on the roadmap, just disallowing consecutive POS blocks.  If a chain that has both POW and POS blocks in it has a higher trust than a purely POW or a purely POS chain, doesn't that go a long way toward what we're trying to accomplish?