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

It only means no one has spent these coins yet. Unless you tend to copy-paste someone else's addresses, I think you have the private key to this address somewhere (or it's an exchange deposit addr).

Double-check all your exchange accounts for deposits of 1371.497218 YAC.

Did you use more wallets? (Do you have more wallet.dat files?) If so, try to find these and see if the coins are there.

You could also try typing "validateaddress Y9MYeV2WcNbYJtMzE9Qs8dgS5yyAyvs9YF" into the debug window of YAC client. If you see something like "ismine: true" - then good news, the key to that address is in your wallet (but the client missed the transaction, somehow).

Other than that, dunno.

I don't really know how this happened, Sairon. I've got the YAC wallet locally, but my address is different. I'm guessing that the transaction is unredeemed means no-one is using that address. The coins were sent from Cryptsy, but the customer support there is not entirely helpful; they just closed the ticket with an "issue solved!" sort of message.

There ain't such thing as an invalid address... Is it your deposit address on some exchange? Your wallet's change address? Someone else's address?

Somehow during the time that YAC went down around Xmas I managed to send some YAC from cryptsy to an invalid address...anyone know if it's possible to rescue these coins? The transaction shows as unredeemed the blockchain. And apologies if this isn't the right place to post this, I'm assuming that my YAC are MIA, this is something of a last effort.

http://ec2-54-247-145-77.eu-west-1.compute.amazonaws.com/tx/d7d2e47942fc5732c37997cfca7aa468bd39d6e20c3fcc3d26171cdb21722e70#o1

How I see ilostcoins  http://www.youtube.com/watch?v=Erlw-ODVZxU

Good to know there is another point of reference in case performance issue does not entirely clear. Thanks. 

4.8 is purposed for compiler monkeys, it's not for production use until it has no /debian/stable/ packages.

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.