[ANN][YAC] YACoin ongoing development

[Beave162]

Here is the idea:
Let's say every 10th block on average is PoS. Once there are 9 PoW blocks one after another, PoW difficulty readjusts to two minute target. If another PoW block comes difficulty adjusts to 3 minutes. And so on. Beave reminded me (good catch Beave) that higher difficulty also affects PoW reward, that means whoever will insist on PoW only chain will have to work harder and also make less profit.
I will need to make refactoring of code - whenever that happens nActualSpacing in GetNextTargetRequired() will need to be set to "min( 60,nActualSpacing )", simulating blocks were max 1 minute apart. We would not want difficulty to drop because PoW blocks were intentionally pushed apart.
Perhaps even GetBlockTrust() will need to take that into account - if one mines PoW only chain too long it's difficulty will skyrocket, but his chaintrust must not.

A few thoughts...

I like the idea of 'forcing' (perhaps 'strongly incentivising' is a better way to put it) PoS to be included in the chain; meanwhile the no-consecutive-PoS-rule, in itself, protects PoW.

senj, when you say "work harder," you actually (practically) mean work longer as difficulty increases. That sounds like a great idea, but allowing the block rewards to decrease with increasing difficulty makes me cringe (refer to centralized manipulation point). At the same time, I'm wondering how drastic the block rewards would change. I also think to myself that it should never happen anyway because PoS should never be ignored.

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

senj, I admire how you look long-term and strategically as well. YACoin/Bitcoin is a system, and as is the case with every system, there will always be people trying to 'game' the system at the expense of others. I think we need to examine more what will happen long-term in terms of PoS...

I would love to maximize my PoS rewards as much as possible. It seems the best way to ensure I will get my 'interest' compounded optimally will be to consolidate all my coins on one input, so they stake right at the minimum of 30 days. There will be a risk for some doing that because if the price skyrockets, and one wants to sell even just a few coins, he will destroy a lot of coinage to do it, but he could miss the high price point (think Certificate of Deposit ladder). Either way, splitting my coins into as many inputs as possible will be best for the network but usually not best for my own self-interest. At the same time, the best of the network is in my own self-interest, and it seems we run into game theory's 'Prisoner's delemma' (https://en.wikipedia.org/wiki/Prisoner's_dilemma).

So how would we fix this issue of making sure PoS is healthy despite a possible opposing incentive to maximize profit. I'll throw out a crazy idea that would surely take advanced coding (although we do have Joe_Bauers, old c coder, senj, Groko): put limit on the amount of coins per input. The limit could be calculated based on the total coin supply. So assuming 60,000,000 YACoins (60,000,000/30 days/24 hours/60 minutes x 2), 2,777 YACoin would be the limit per input for PoS, and it would adjust as the total supply continues to rise, assuming 2 minutes per PoS block ideal. I'm sure I'm missing something that would make such a feature impossible, but please let me know!

Those are my ramblings for now...

[1715481061]

1715481061

[1715481061]

1715481061

[1715481061]

1715481061

[1715481061]

1715481061

[1715481061]

1715481061

[NineEleven]

I just to tel you that i finally get the pool right

Blocks are found , and accounted correctly

Unfortunately most of the orphan but thats another problem

It would be nice if the pool adress can go to the OP

Regards

[senj]

...
I just thought you were interested in the 1,129,123 blocks before Tue Jul 7 23:28:55 2015 EDT?  In addition to what for me will be future blocks.  I must have misunderstood your desire for some past block information?

I wasn't thinking about throwing away that 1 million + blocks. I don't know how you got that idea.
But you shouldn't count on them, if chaintrust issue remains intact.

...
The average block period is being adjusted now according to the past actual block periods and the PoW difficulty is in some sense inversely related to the block period.  That is, short past periods get higher difficulty.  At least that is my impression?  This is to "smooth" out the block period "fluctuations" around the desired one minute average.
Now your statement:  PoW difficulty readjusts to two minute target  seems to be at odds with the overall desire of YAC to maintain a one minute average block period?

My primary goal is to fix critical issues. Another goal is to keep PoS blocks in the chain and have them spaced apart at 1 minute and if we need to occasionally increase PoW block spacing in order to achieve that -  I have no problems with that.

And the function min( 60,nActualSpacing) can be much less than one minute if nActualSpacing is?

Yes, if blocks get to close, we still need to raise difficulty.

And  We would not want difficulty to drop because PoW blocks were intentionally pushed apart.  Seems to be getting more and more difficult to do this modification, and hence be able to understand the side effects?  It seems one should look for a simpler approach, at least to start with, that won't have so many conflicting effects on the basic operation of the code.

We've had two simple solutions that did not work. I wouldn't want another one like that. Especially if it requires a hard fork.
Complexity should be addressed with revisions, testing and simulation. But if you have a simple solution and it doesn't come with major shortcomings, I would love to hear about it.

Your first link on chain trust speaks of other coins using the chain length in considering/calculating the chain trust.  And YAC does not!  Perhaps we could take a page from NVC's book?  Isn't that what Joe is trying to do?  In any event,  I have no definition or even a clear idea what the terms chain trust and chain length are in the context above.  I would need good definitions in order to even be able to think about, much less opine on any solutions.

Chain trust is sum of GetBlockTrust() values for each branch. Branch with highest chaintrust is the main one. Follow first link pointing to peercoin wiki in document mentioned.
NVC's solution is not so strong as I'd wish. They give hybrid chain more trust (and perhaps higher rewards too). Sairon also acknowledged that some time ago.

[senj]

...
senj, when you say "work harder," you actually (practically) mean work longer as difficulty increases. That sounds like a great idea, but allowing the block rewards to decrease with increasing difficulty makes me cringe (refer to centralized manipulation point). At the same time, I'm wondering how drastic the block rewards would change. ...

We have block rewards decreasing with increased difficulty right now. That is how it works.
Rewards do not matter here. They are a side effect of fix. Chain that does not ignore PoS blocks will be most rewarded.

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

Did you not see my reply (in your messages):

As you can see, nbits value is directly set from GetNextTargetRequired function.


Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.

And while we are at confusion. I haven't received an answer to one of my previous questions. I wonder if anyone knows it:

Looking at code it seems that block reward calculation goes like the this:

Code:

nSubsidy = 100 / (diff ^ 1/6)

but wiki and other sites say it is like this:

Code:

nSubsidy = 25 / (diff ^ 1/6)

Here for example
https://yacoin.org/tech.html
http://coinwik.org/YaCoin
http://coinwiki.info/en/Yacoin


I can not figure out where did 25 came from. Can someone explain this or at least point me in right direction please?

As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.

[NineEleven]

in the last 4 hours
the orphan block disapear

[old c coder]

As you can see, nbits value is directly set from GetNextTargetRequired function.
Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.

And while we are at confusion. I haven't received an answer to one of my previous questions. I wonder if anyone knows it:

Looking at code it seems that block reward calculation goes like the this:

Code:

nSubsidy = 100 / (diff ^ 1/6)

but wiki and other sites say it is like this:

Code:

nSubsidy = 25 / (diff ^ 1/6)

Here for example
https://yacoin.org/tech.html
http://coinwik.org/YaCoin
http://coinwiki.info/en/Yacoin
I can not figure out where did 25 came from. Can someone explain this or at least point me in right direction please?

As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.

Hello Senj,

The "code"

Code:

nSubsidy = 100 / (diff ^ 1/6)

is seen in YAC 0.4.4 source, in main.cpp => GetProofOfWorkReward()

And it is Pseudo-code in a comment!  Nevertheless, it brings up points that I have made over and over again, for more than 30 years!

Whenever a MAGIC NUMBER (out of the blue, undocumented) appears in code, it brings understanding to a crashing halt.

Is it a REQUIRED value?  Is it ARBITRARY?  Is it DEPENDENT  upon some other value elsewhere in the program??  Is it a WILD ASS GUESS?

You get the idea.  Well, we have two (or three) in this pseudo code snippet!

Upon looking at the code (with the help of MSVC++ in Visual Studio) I found that the 100 actually was a constant!

There are literally hundreds of "naked" numbers in the YACoin (and Bitcoin  and all the others) sources.

Until every one is replaced by a MEANINGFUL name that truly represents what it is, no real understanding and improvement can come to this or any "open source" project, since the "open source" is so obfuscated by lack of clarity it is impossible to understand how the code is interrelated, etc. etc.

And it's worse.  Method/function names are so bad they may as well be numbers!  Ditto for properties/variables.

There has been no excuse for cryptic, short, vowel challenged, abbreviated names for classes, structures, methods, properties, etc. etc. since the 1980s, when memory and disk storage was expensive, and we had 32 character or less restrictions on names in C (back then).

Now students and adults today have studied from books and authors who came from that past and have perpetuated this ugliness of language in their books, and so it continues for another generation.

You shouldn't have to translate literally every word you see in a line of code, in your head, in order to understand it!  But the myth continues that that is how it must be.  I don't buy it, never have, never will.  In a commercial professional environment, one was required to write much clearer code.  And document it too!  Seems today, it is get it done fast, no documents, no nothing.

If you want to bring fresh eyes to a problem, the code must be clear, more clear, beyond clear.  No tricks, no assumptions...

The C++ compiler will optimize out everything anyway, so there is no point in trying to be "cute".

Here is the original:

Code:

int64 GetProofOfWorkReward(unsigned int nBits)
{
    CBigNum bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;
    CBigNum bnTarget;
    bnTarget.SetCompact(nBits);
    CBigNum bnTargetLimit = bnProofOfWorkLimit;
    bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());

    // ppcoin: subsidy is cut in half every 64x multiply of difficulty
    // A reasonably continuous curve is used to avoid shock to market
    // (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
    //
    // Human readable form:
    //
    // nSubsidy = 100 / (diff ^ 1/6)
    CBigNum bnLowerBound = CENT;
    CBigNum bnUpperBound = bnSubsidyLimit;
    while (bnLowerBound + CENT <= bnUpperBound)
    {
        CBigNum bnMidValue = (bnLowerBound + bnUpperBound) / 2;
        if (fDebug && GetBoolArg("-printcreation"))
            printf("GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", bnLowerBound.getuint64(), bnUpperBound.getuint64(), bnMidValue.getuint64());
        if (bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnTargetLimit > bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnTarget)
            bnUpperBound = bnMidValue;
        else
            bnLowerBound = bnMidValue;
    }

    int64 nSubsidy = bnUpperBound.getuint64();
    nSubsidy = (nSubsidy / CENT) * CENT;
    if (fDebug && GetBoolArg("-printcreation"))
        printf("GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", FormatMoney(nSubsidy).c_str(), nBits, nSubsidy);

    return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}

Study that for a while and notice that it raises more questions than it answers.  Long lines are stupid too, for many reasons.
Here is what I wrote for myself, in my MSVC++ project, and it is only a first pass:

Code:

int64 GetProofOfWorkReward(unsigned int nBits)
{
    CBigNum 
        bnSubsidyLimit = MAX_MINT_PROOF_OF_WORK;

    CBigNum 
        bnTarget;

    bnTarget.SetCompact(nBits);

    CBigNum 
        bnTargetLimit = bnProofOfWorkLimit;

    bnTargetLimit.SetCompact(bnTargetLimit.GetCompact());

    // ppcoin: subsidy is cut in half every 64x multiply of difficulty
    // 64 = 2 to the 6th power
    
    // A reasonably continuous curve is used to avoid shock to market
    // (nSubsidyLimit / nSubsidy) ** 6 == bnProofOfWorkLimit / bnTarget
    // what are these terms and how do they relate to the discussion, exactly??????
         
    //
    // Human readable form:
    //
    // nSubsidy = 100 / (diff ^ 1/6)

    // again, but worse!!!  Undefined magic numbers.  I think that 100 is the 
    // maximum subsidy in COINs ???????????
    // diff is ??????????????
    // 1/6 is 0 if we are talking integer divide, so obviously we are not?????????????
    // So what are we talking???????????????????
    // is ^ from GWBASIC??????????????
    // Do we mean power?????????????????

    // even so, after all of that, what does this code below actually do?????????

    CBigNum 
        bnLowerBound = CENT;            // this is 0.01 * COIN

    CBigNum 
        bnUpperBound = bnSubsidyLimit;  // seems that this is just 100* COIN

    while (bnLowerBound + CENT <= bnUpperBound)
    {
        CBigNum 
            bnMidValue = (bnLowerBound + bnUpperBound) / 2;

        if (fDebug && GetBoolArg("-printcreation"))
            printf(
                    "GetProofOfWorkReward() : lower=%"PRI64d" upper=%"PRI64d" mid=%"PRI64d"\n", 
                    bnLowerBound.getuint64(), 
                    bnUpperBound.getuint64(), 
                    bnMidValue.getuint64()
                  );
        if (
            bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * bnMidValue * 
            bnTargetLimit > 
            bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * bnSubsidyLimit * 
            bnTarget
           )
            bnUpperBound = bnMidValue;
        else
            bnLowerBound = bnMidValue;
    }

    int64 
        nSubsidy = bnUpperBound.getuint64();

    nSubsidy = (nSubsidy / CENT) * CENT;
    if (fDebug && GetBoolArg("-printcreation"))
        printf(
                "GetProofOfWorkReward() : create=%s nBits=0x%08x nSubsidy=%"PRI64d"\n", 
                FormatMoney(nSubsidy).c_str(), 
                nBits, 
                nSubsidy
              );

    return min(nSubsidy, MAX_MINT_PROOF_OF_WORK);
}

I just formatted it so I could read it!!  Can you swear that that while loop, with a test in an if statement is doing what the comment says?  I can't!  I think it is doing more but I haven't analyzed it, yet.

I have said this, in many Bitcoin forums, and more, but my words do not resonate with people who don't care about communicating their coding ideas clearly.  They most probably never took any writing or English courses, and have never read Joel Spolsky

Dismounting from high horse now...

Ron

[Beave162]

We have block rewards decreasing with increased difficulty right now. That is how it works.
Rewards do not matter here. They are a side effect of fix. Chain that does not ignore PoS blocks will be most rewarded.

I'm not sure why you iterated something I already know, and you know I already know. You didn't address my concern, but that is ok. I'm still debating it in my head and hoping for others to opine...

I'm still confused on the ratio, and how it could be enforced. Reading previous conversations, sairon said the ratio is 10:1 PoW:PoS. What determines that? Can you make it 1:1? Should you make it 1:1? Obviously, I am very code illiterate.

Did you not see my reply (in your messages):

As you can see, nbits value is directly set from GetNextTargetRequired function.


Looking at sources from peercoin, novacoin and original yacoin, you will notice similarity:

One parameter used differs though:

https://github.com/novacoin-project/novacoin/blob/master/src/main.cpp#L47
https://github.com/ppcoin/ppcoin/blob/master/src/main.h#L44
https://github.com/pocopoco/yacoin/blob/master/src/main.cpp#L42

I think sairon's mistake had to do with comments left from Novacoin source.

PoW difficulty after PoS block should fall back to "1 minute". My draft would probably need to be revised.

I saw your reply, and I went through your links, but I still don't understand. Perhaps, someone else can explain in 'simpler' terms on this thread...

As for the rest, soon I will put up my draft for fixing remaining security issue - small PoS blocks. In part it will resonate with what you write here.

My point was not about small PoS blocks--the opposite really. But yes we can have that discussion at a later time.

Ron, I love your point.

There has been no excuse for cryptic, short, vowel challenged, abbreviated names for classes, structures, methods, properties, etc. etc. since the 1980s, when memory and disk storage was expensive, and we had 32 character or less restrictions on names in C (back then).

It reminds me of useless acronyms used in many organizations where some acronyms have more syllables than the original phrase, and there are acronyms that could mean different things in the same context. I know it gives some people a sense of confidence by sounding 'cool' or 'smart'. Really, it is often a sign of an arrogant lack of intelligence and inability to communicate. YACoin can be a leader in this area of more transparent code.

Anyway, hopefully we can get more opinions on senj's proposed changes, and I hopefully I can get answers to my questions...

[senj]

...
If you want to bring fresh eyes to a problem, the code must be clear, more clear, beyond clear.  No tricks, no assumptions...
...

Ron, I share your frustrations regarding code readability. I guess you don't know where that 25 came from either:)
To find out what is going on, I help myself with wikis, forums, documentation sites, blogs, you name it ...

I am not sure it would be even possible to put all this information in code, but I agree 100% it should be more readable.
Perhaps one day someone brave will create libyacoin with design principles taken from libbitcoin

...
I'm not sure why you iterated something I already know, and you know I already know. ...
...

I misread your message. Sorry. I know now.

...
I saw your reply, and I went through your links, but I still don't understand. Perhaps, someone else can explain in 'simpler' terms on this thread...

That would be most welcome for all of us, and also for future yacoin developers. Perhaps I will put something together ....

[Joe_Bauers]

Perhaps one day someone brave will create libyacoin with design principles taken from libbitcoin

Yes!  I actually spent an hour or two a while ago seeing how much work that would be
 

Joe_Bauers, any update to the timeframe of the new wallet release?

Depends on all the items we're trying to work out over the past few pages.  There are 2 options as I see them. We could move to 0.4.5 now (soon) as it is, which is a refactoring to latest NovaCoin code, along with some enhancements that I added. As it moves us to LevelDB, it would require downloading the block-chain from 1, either doing the old fashioned way (this will take days!) or by downloading and importing a bootstrap.dat file that I would release. This will take about 12 hours. I've tested and run this client on the general network and it seems to work great. I did not test staking, and POW mining would need to be done using ThirtyBird's miner. Anyone not using this now anyway is losing out.  I would want some of you to test as well though, before releasing. Then for 0.4.6, we would have the hard fork required changes that Senj has proposed.   

Other option is to do everything for 0.4.5  This seems more risky to me, but is a little less of a pain I suppose because you get everything in one version.

[alenevaa]

I vote for step by step changes.

First - 0.4.5 release
Second - new version (0.5.1) with hard fork

[Beave162]

It's just a different kind of distribution.

YACoin is not widely used, it is still in distribution stage.

The issue as I see it is, someone with a LOT of resources is mining the shit out of YAC to make a profit.

Rewards do not matter here. They are a side effect of fix.

There is a recurring theme with these comments, and I agree with it. The block reward is meaningful only under the assumption of having value.

The changes/fork can be looked at, in one way, as a fresh release with a ~60M YACoin premine. The block reward structure may vary but only because of the tie to difficulty. I believe the reward aspect is insignificant--as implied by the comments quoted above--and is indeed an side effect as you said, senj.

The way I understand it, this fix of senj's will encourage those who are 'mining' to also be 'minting', and I think that is key for a PoW/PoS hybrid system.

If there isn't a release for the wallet soon, I'm afraid the price will continue to drop. But for what it's worth, my opinion is to do whatever makes senj's fixes happen quickest, which may be 'Option 2'. The issue with PoS inputs (small, large, whatever) can be fixed later as I don't think it will be a significant problem in the immediate future.

[NineEleven]

i anyone cares 
I vote for option B

Fork on the next release

[alenevaa]

While there is a problem with mining YAC everybody welcome to mine UltraCoin (NF16).
You can use the same miner's config as for YACoin with adding one parameter --starttime=1388361600

Code:

minerd-x64-avx.exe --starttime=1388361600 -a scrypt-chacha -o stratum+tcp://yacoin.club:3443 -O User.WorkerName:WorkerPassword

Welcome to utc.yacoin.club

[Beave162]

While there is a problem with mining YAC everybody welcome to mine UltraCoin (NF16).
You can use the same miner's config as for YACoin with adding one parameter --starttime=1388361600

Code:

minerd-x64-avx.exe --starttime=1388361600 -a scrypt-chacha -o stratum+tcp://yacoin.club:3443 -O User.WorkerName:WorkerPassword

Welcome to utc.yacoin.club

Thank you, alenevaa!

[caston]

So is this the end guys?

I got really excited when the price began to rise and made some optimistic predictions. Now it's all over red-rover?

I was planning to buy another million coins but maybe I would have better luck at the races?

[Beave162]

So is this the end guys?

I got really excited when the price began to rise and made some optimistic predictions. Now it's all over red-rover?

I was planning to buy another million coins but maybe I would have better luck at the races?

We are in a holding pattern until the new wallet is released with senj's changes, which could take some time (I'd guess another month). Keep in mind that there will probably be complications with Cryptsy updating their wallet when that happens. Not to mention, there will likely be a fork if the 'malicious miner' doesn't update his wallet, which i suspect will be the case

The bottom line is that YACoin is being attacked and the price will keep falling as a result of that attack. I'm surprised it is still as high as it is. There was no 'chain trust' mechanism that is in every other PoW/PoS hybrid coin. I don't know how that has been overlooked for so long but such is the case.

The short-term for YACoin is grim, but the long-term is still good. Joe_Bauers clearly has priorities outside of crypto and that is a good thing. I really hope senj's changes will make YAC completely self-sustaining, and any improvements from that point will just be more icing on the cake.

[caston]

I don't think we should invalidate blocks if this will screw with exchanges and innocent users that sent or received transactions. I know it really sucks for miners that got so many orphans but we also have to consider that changing the blockchain could damage the existing arrangements that Yacoin has with services. If say bter and crypsty were to delist Yacoin then we would be in a bad state. We have had so much trouble getting other exchanges to list Yacoin and although we have had the occasional success those exchanges quickly went under. We even had a merchant accept Yacoin once but then it went out of business!

The other possibility is that the exchanges might not update to the new wallet further fracturing the community.

[Beave162]

I don't think we should invalidate blocks if this will screw with exchanges and innocent users that sent or received transactions. I know it really sucks for miners that got so many orphans but we also have to consider that changing the blockchain could damage the existing arrangements that Yacoin has with services. If say bter and crypsty were to delist Yacoin then we would be in a bad state. We have had so much trouble getting other exchanges to list Yacoin and although we have had the occasional success those exchanges quickly went under. We even had a merchant accept Yacoin once but then it went out of business!

The other possibility is that the exchanges might not update to the new wallet further fracturing the community.

There will surely be a delay (until a specified number of blocks) for the changes to take place after updating to the new wallet. Joe_Bauers, correct me if I'm wrong...

Does Cryptsy or BTER even delist coins? I don't think there is a real chance of them removing YAC. UltraCoin has gone through a few forks and is still there. I'm afraid it will be 'under maintenance' on Cryptsy for longer than it should be, which has happened in the past.

[Joe_Bauers]

So is this the end guys?

I got really excited when the price began to rise and made some optimistic predictions. Now it's all over red-rover?

I was planning to buy another million coins but maybe I would have better luck at the races?

We are in a holding pattern until the new wallet is released with senj's changes, which could take some time (I'd guess another month). Keep in mind that there will probably be complications with Cryptsy updating their wallet when that happens. Not to mention, there will likely be a fork if the 'malicious miner' doesn't update his wallet, which i suspect will be the case

The bottom line is that YACoin is being attacked and the price will keep falling as a result of that attack. I'm surprised it is still as high as it is. There was no 'chain trust' mechanism that is in every other PoW/PoS hybrid coin. I don't know how that has been overlooked for so long but such is the case.

The short-term for YACoin is grim, but the long-term is still good. Joe_Bauers clearly has priorities outside of crypto and that is a good thing. I really hope senj's changes will make YAC completely self-sustaining, and any improvements from that point will just be more icing on the cake.

I'm pretty sure, everyone outside of Gavin and the few other folks that get their salary to work on *coin have priorities outside of crypto   Anyway, after reading the last few pages, it appears that there is still a huge amount of confusion on how Yacoin, or as Ron puts it *coin works.   

As long as *MINER is devoting more resources to mining than at least 50% of the rest of the network, there is nothing that can be done EXCEPT THE COMMUNITY DEVOTING MORE RESOURCES THAN *MINER, that will prevent *MINER from controlling the network. This is a universal truth for all *coin(s)  Senj's changes will not fix this, Gavin's changes will not fix this, Satoshi's changes will not fix this. The fact that many of you have now committed to no longer mine and/or stake while waiting for a wallet change that you think will fix the issue is certainly making it look like " all over red-rover" to me though.

If the community as a whole is unable to gather the resources to thwart *MINER, then possible the best move at this point, is to follow YbCoin's lead and move to POS only.

[birdvox]

Or increase the block reward, make it proportional to difficulty. Then the community can afford to mine this coin.