Yeah, but another flaw is that the protocol does not enforce alternation of PoW and PoS. Say an attacker somehow manages to make a chain that 100% alternates between PoW and PoS - it WILL have higher trust score and WILL overwrite the old chain. Also note that this type of attack will have lower energy cost than the network spent on its non-perfect chain. Perfect chain costs less (!!) than imperfect one.

However, if we were to actually enforce such alternation, pools will be starving when PoS block should be generated.

Nah, his problem is that he closed the wallet before it connected to irc (failed on first try, 71s delay before next attempt and then he closed it).

Not neccessarily true with eg. 50% PoS blocks in the attacker's chain.
Relying of PoW difficulty itself might be ok, though - see the pastebin a few posts higher.

What we need is a proper way to calculate the chain trust.

I had a similar idea a while ago (with no-consecutive-PoS rule, though): http://pastebin.com/L8THNBZ4
Not sure if lowering the PoS interval would help us much.

You can generate PoS blocks without even trying and as it is now, they can "overwrite history", which is bad.
For PoW, however, you must spend a lot of electricity so it actually costs you something (quite a lot) trying to change history.

If it's cryptsy's cold storage with YAC trading still disabled and some people too lazy to withdraw, though...

Could be an exchange, maybe.

Yup.

Anybody investigated where the coins came from? Still haven't finished blockparser for YAC and I'm too lazy to do it manually.

It's just an additional measure to prevent (well, lower the risk) the live nodes from being fooled, so they can continue building on top of the valid chain.


Yeah, but exactly HOW can you make a valid chain that's LONGER than the previous valid chain in SHORTER time while spending considerably LESS energy to do it?

And now the same with hard checkpoints enabled.

Err, WTF?
https://en.wikipedia.org/wiki/Yacoin
(page deleted)

https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Yacoin

I've added a small fix that preserves the old block trust model for blocks <400k (oops). https://github.com/saironiq/yacoin-cc/commit/2a394a39c2133aa600b81580f587733b2498a01d

I've also been thinking abount the issue Balthazar found (generating lower-difficulty fork from last checkpoint). The only way it can be achieved (the lower diff) is by faking the timestamps in the blocks (to keep diff low) and generating a longer chain than the current main chain. By faking the timestamps to be more distant from each other the difficulty is kept low. This, however, results in the attacker's fake longer chain to have a timestamp from the future - possibly more than the allowed clock-drift (depends on the length of the faked chain. If the timestamp is higher than "now + allowed drift", then such block is rejected by the client - thus fixing this issue.

The only open question is how long can the fake chain be to fit into the allowed clock-drift window.

One solution is reducing the nMaxClockDrift parameter in the code from the current 2 hours (!!!). I'd personally go for something like 15 minutes or so, as your system time needs to be faily accurate to even use HTTPS sites. Hell, even time-based one-time pads (TOTP) need clock accuracy to be within 1 minute (this is the thing you use for two-factor auth, eg. with Google's Authenticator)! And most operating systems keep the time updated for you automatically, anyway.

It's just a simple change, see:
https://github.com/saironiq/yacoin-cc/commit/ad5533d015ea910f4ebfb569f3065186b8923ae6

Fair enough. This will need to be changed, thanks.

Maybe, but your solution actually forces the whole network into running their own modified client in order to maximize profits - which, honestly, sucks hard. The non-programmer folk have a huge disadvantage here.

EDIT: Assuming that you actually publicly release such modified client, it essentially becomes enforced (who would intentionally lower their profits?). Also, it definitely does not solve the orphaning issue we're facing now. As I stated before, PoS is useless without there actually being something in stake...


59% yearly interest for early adopters, sure. Screw the later-coming big investors when the PoS difficulty gets higher and interest lowers significantly. Good way to discourage promotion of the coin and thus adoption.

Even Bitcoin isn't that harsh - and it was designed with huge early-adopter rewards to encourage fast adoption.

Don't get me wrong, I'm not calling Novacoin an outright scam. Just don't agree with the economic model behind it.

The same is true for Bitcoin. That's what the hardcoded checkpoints are for.

Thanks, much appreciated!

Just noticed the donation progressbar on yacexplorer ain't updating (guess that's because YAC is disabled on cryptsy, gah).

You're welcome.
A pool?

Yeah, if you use date/time instead of block height, the only way for dishonest nodes to wreak havoc is in the "time +- network-adjusted offset" period (a few hours at most) and it gets resolved pretty quickly after that. The block height method is less accurate, but more secure in this regard, that's why I've chosen it.

No need to add another signing as PoS works in a similar way, anyway. PoS was supposed to be a distributed check-pointing and look where it got us.



1) I assume that by "maximizing active weight" you mean the "number of coins participating in PoS * their coin-age". That's quite difficult to achieve with such little adoption and in this early stage of initial coin distribution. I think we're better off (at least temporarily until YAC economy grows enough) to enforce the rules I proposed. They're easier to implement the right way and have a much lower potential of screwing something up hard.

2) Enforcing a hybrid chain (with alternating PoW/PoS blocks) is IMO a bad idea as the protocol is set to 1-minute PoW and 10-minute PoS target. With my rules hybrid chain is the optimal way when trying to do 51% attack (as you can reduce the "51%" PoW hashing power needed by at most 50% if you have 100% active weight). Still, it would not be expensive enough to attempt, anyway - that's my justification of lowering PoS trust to the level of PoW (I'd lower it even more if only it didn't cause another sort of problems, which it would). It's all about finding the right balance, anyway.

Variable ROI isn't sufficient to prevent a malicious entity wanting to break the network entirely, anyway. As YAC uses a heavily CPU-friendly hashing algorithm, it would be a dumb idea to rely solely on PoW in the era of supercomputers and even the good ol' botnets. So the optimal attack scenario favors stake amount over hashing power to at least try to mitigate the motivation of breaking the netwrok entirely - by forcing the attacker to invest heavily into the coin beforehand, thus inflicting at least some sort of monetary costs to them (botnets are dirt-cheap novadays).

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c

Would you mind elaborating a bit?

If we allowed max 2 consecutive PoS blocks, then every PoS miner has the ability to deliberately orphan a single PoW block at the tip of the chain (assuming the last two blocks were both PoW). Thus all transactions in that block will be reversed and allowed to be double-spent (not that big of a deal, as they had just 1 confirmation anyway, but still - it would be incredibly easy to do this so we better avoid it).


Case #0 - as it is now:
I can choose any point in the blockchain that hasn't yet been checkpointed (hardcoded height and block hash in the source code) and place my chain of PoS blocks there. Should this new fork happen to have a higher trust value than the original, longer chain - it will be accepted as a new valid chain, orphaning millions of transactions in the process. This happens quite often and (I believe) accidentally - so you can see just how incredibly easy it is to abuse if you deliberately decide to do so.

Case #1 - only disallowing two consecutive PoS blocks:
Imagine the tip of the chain looks like this:
(whatever)-S-W-W-W-W-W-S-W-W-W-W-W
(S denotes PoS block, W is for PoW)

I can now orphan the last 4 blocks by placing my new PoS like follows:
(whatever)-S-W-W-W-W-W-S-W-S

So this is bad, too...

Case #2 - make only the trust value equal:
Again, we have a chain that looks like this:
(whatever)-S-W-W-W-W-W-S-W-W-W-W-W

Now I prepare a chain of PoS blocks that's one longer than the number of last N blocks I want to orphan. Eg. if I wanted to orphan last 10 blocks, I'd make a chain of 11 PoS blocks and hook it to the chain as follows:
(whatever)-S-W-S-S-S-S-S-S-S-S-S-S-S

Easy, isn't it?

Case #3 - the proposed solution:
None of the above flaws work here.

So far I've been able to come up with only one theoretical flaw to this system - lowering the "51%" attack hashrate threshold by PoW-mining in cunjunction with PoS-mining - however, I believe it's not much of an issue as the attacker would need to own a significant percentage of active stake in the PoS system. The worst-case is 25% attack - and the attacker then would need to own 100% of active stake (if my math is correct). So it's more like work-stake trade-off and not an outright vulnerability.

That's one more reason why we need more hoarders (and pools, too!). And remember - the way it is now costs a potential attacker near to nothing as he only needs some (very little) active stake.

Bottom line: I've come to a conclusion that the current hybrid PoW/PoS blockchain system is crap and needs a complete rehaul to actually do the core functions it promised to provide (like increasing chain security by PoS checkpointing with stake actually being something that's in stake - right now staking coins doesn't mean a sh*t).