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

It might make sense to have a window set for every day - basically like a company's batch file sent to a bank. For those in inconvenient time zones, they could just set their client up for POS mining before they go to bed.

Balthazar, obviously this would be a big change from what is already happening for NVC/PPC/YAC. Do you think something like this is even viable?

I thought it might complicate things for anyone planning scheduled attack with his own premined chain.
Also fixed times would affect people differently depending on where on Earth they dwell. If it would be time (exact hour) based that would have to drift anyway so that folks on some continents would not have to wake at 4am to collect interest.
Plus it might be preferred to have greater number of small PoS windows than ever expanding one.

What would be the benefit of making this POS window hard to predict? Wouldn't it be easier to have more people participate in POS if people know when they can collect their interest?

I will expand a concept a little bit so there are no fixed times:
Clients would utilize some function that would dynamically open PoS block acceptance windows, for example  "when (mod(last1000blocks.getTransactionCount(), 15) = 0)". This makes PoS acceptance time hard to predict but easy to calculate on the fly. Client software would offer an option so the user would enter password on demand and wallet would get unlocked during that period it there are any coins eligible for PoS minting. Or notification would be raised and users could unlock the wallet manually (notification in system tray icon during PoS windows?).
Software could also adjust PoS window duration according to currency amount generated during previous window (or average of last n PoS window periods). Or something else that would automatically adjust PoS block generation / PoS mechanism takeover.

Yet I do not know if any of this can be done at all. Feedback from other developers would be much appreciated.

Nope. This modification changes actually nothing, because attacker won't publish his chain during the generation time. It would affect you only if you are honest user with the wrong clock settings. That's much worse than checkpoints, because it provides a false sense of security.

Again... Don't listen to checkpointism adepts ever.   The main purpose of checkpoints is not a chain control, a block chain must be able to control itself. The main checkpoints purpose is to protect users against the compromised ISPs and enable some low-level signature checking optimizations. Checkpoints could be disabled or removed entirely and chain has to be able to continue working as usual.

YAC is missing the block trust calculation.

BTC calculates chain work as a function of difficulty and chain length;
PPC calculates chain trust as a function of PoS difficulty and chain length;
NVC calculates chain trust as a function of PoW and PoS difficulties and chain length;
YAC doesn't perform any calculations, all blocks has the same trust and chain trust depends only on chain length.

But actual reason of the problem and all those "fixes" is that YAC tries to use PoS:PoW ratio which wasn't foreseen in the original design.

This discussion has been a good lesson for me and I'm still trying to digest more of it. Too bad I don't have anything useful to offer. Thank you Balthazar for offering your expertise on the matter.


Scheduling a time period for POS and POW sound strange at first, but from the perspective of coin distribution with less waste in energy, shortening the time mining machines need to run is a good thing and a similar amount of coins can be handed out by adjusting the block reward. N changes are indeed obvious signposts that can help orchestrate any major shifts. I don't know about the security aspect though.


I think he means the recent proposed changes of YACoin but I could easily be wrong.

It looks like somebody prefers to ignore a basic math for ideological purposes rather than do some research. I seen this many times during the years of USSR.

OK, let's do some research...

1) The maximum proof-of-stake reward is 1 coin per coin*year, so even if reward and difficulty will be constant values, proof-of-stake is unable to introduce more than 100% increase of supply.
2) There are more than 650000 NVC generated, this means ~325% increase of supply for 8 months or ~487% for a year.
3) WHAAAT THE HELL IS THAT???!   How is it possible?

An answer is quite simple, proof-of-work generation is much more powerful inflation source even with NVC block rewards. And it's significantly more powerful in YAC, just compare proof-of-work rewards and do some extrapolation before trying to deny that.

And remember that difficulty is growing while the reward is dropping...

Would there be ramifications to changing the code to reject a newly published chain if the lowest height block is 24 hours older than the highest published block?  I honestly don't understand chain trusts, etc, and have not found the explanation that clicks for me yet, so this may just invalidate a bunch of things - I don't know any better, but want to.  I brought up cementing earlier, and everyone was vehemently against the concept, but it strikes me as just another form of checkpoints, which is what NVC and PPC are using.

second question - regarding bitcoin knowing the difference between a diff1 and diff2 block but YAC does not - could you elaborate on this Balthazar?  What is YAC missing?

Ha - I was actually thinking about this a few days ago, and still haven't been able to find an obvious exploit. 

If I understand correctly function of PoW mining is coin distribution and PoS was ment to later with enough honest nodes takes over coin production and other functions (but not distribution at least not directly).

Now the two (PoS&PoW) obviously do not go along too well in this form.

Would it be possible to implement alterations of blockchain sequences according to timestamp like this: only POW blocks would be accepted by clients every day except on saturday when one hour would be allowed for only PoS blocks sequence.
That one hour would be extended by another hour or similar every week, so gradually PoS would replace PoW along with coin being distributed to increasing number of people.

If people would like to collect PoS revenue they would have to open their wallets all at once and "flood" the net.
As yacoin gets distributed to more people this flooding time would get extended until it happens all the time and takes it's proper function.

I said 1 hour on saturday - but it could be any day and duration determined upfront, for example 15 minutes every day or every third day or when N increments...

I think Nfactor change should get used for any incremental phasing out of functionality not needed anymore - be it dynamic active weight calculation or something else temporarily needed.

This sounds like one basic modification to do, changing PoW and PoS targets so there's rarely more than one PoW block PoS can orphan, and shouldn't interfere much with further future improvements.

Chain has worked without that much drama until now, if an interim targets fix can make do for a while, it may buy time while more complex improvements are evaluated. No need to risk introducing bigger loopholes trying to fix a smaller bug.

Good thing I copied it all and added to yacoin.org before it was deleted  I also setup a redirect to your explorer page (explorer.yacoin.org) as was done on yacointalk.

1. I need some time to recalculate a difficulty, but once difficulty is recalculated I can generate as many blocks as I need. 100, 1000 or even 10000 blocks could be generated without any problem. The only thing I need is a modified software.

2. Actually I don't need do it in shorter time. I can use my wallet for payments as usual while alternate chain is generated. A week/month/year later I'm publishing a fake chain which removes all of my transactions during this period from the main chain.

Such attack is impossible in Bitcoin or Novacoin, because those networks are able to see the difference between diff1 and diff2 blocks. But your version of YACoin makes no difference between such blocks.

The purpose of checkpoints is not a chain consistency control, chain should be able to control itself. Those checkpoints are able to prevent such type of attack, but it's not a solution. It's just another workaround.

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.

Nope, this maxClockDrift condition is just a sanity checking threshold against the node with invalid time settings. It's not necessary to publish a chain immediately, real attacker will be able to publish his chain in any moment of the future. And clockdrift condition won't be able to prevent this.

I can generate chain and publish it a month or even year later... And it will overwrite the main chain if there are no checkpoints added. Just because there is no way to make a difference between valid or invalid timestamps if these timestamps are in the past.

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

I've read all of the recent posts (twice actually) and gave this a lot of thought...


I think Sairon's fix is the best solution at the moment.  It seems to be easy to implement and it will solve the immediate issue.  While there may need to be other 'tweeks' down the road, we need to get YAC back up and running.  The inconstancy on Cryptsy and other market charts / exchanges aren't helping improve YAC's reputation and community.  Without either of these, I don't think we will have a chance to face some of these other issues...


I am (personally) not in favor of this.  Nothing against Novacoin but; YAC was branched from PPC/NVC and there has been a lot of development work to make it a unique (and useful) coin.  And by copying NVC's PoS modifications, we begin to lose some of our uniqueness.  And YAC isn't another 'clone' coin.  If it was; it would have been named CAC - Clone Another Coin....

If we do decide to move forward with Sarion's hard-fork, I am in favor of doing it by Feb 1st.  This gives 4 weeks for all pools and miners to update their software.  I believe this is more than enough time to properly communicate to everyone.  Also, a few thoughts / questions about how POS after this hard-fork.

Our block target for YAC is one minute.  This would imply that there would be a maximum of 720 POS blocks per day.  As YAC continues to grow, this may not offer many opportunities for people to mint their transactions.  Therefore, is it possible to....

1) Mint more than one transaction at once/per block? (i.e. Five transactions of 10 YAC w/ one coin-year each, in an unlocked wallet would mint in the same block, and be returned a single transaction (50.50 YAC)
2) Increase/remove the 'coin-age' cap? (I believe transactions stop gaining 'coin-age' after 90 days) 

IMO - These adjustments will allow people to continue to fairly PoS mine YAC, with out compromising any of the security or fundamental features of YAC.

There are serious reasons to doubt this.

It works as it was designed, and there is no crap except constant values which were chosen by hand of original developer. PoW blocks target spacing must be higher or at least equal to PoS blocks target spacing, because this system is originally designed for "slow" PoW blocks and "fast" PoS blocks. It doesn't work in the perverted version and there is nothing strange here. Orphans is just another part of self-regulation in this complex system. If developer tries to set PoW spacing lower than PoS spacing then network just forces him to get acceptable PoS/PoW ratio.

If you wish to have a "fast" PoW blocks then you need another system, because this system won't allow you so. You need cunicula's concept or something like that. I.e. no PoW and PoS blocks, but a homogenious chain with a new block type. It's even possible to reuse the current code by removing PoW blocks support and forcing PoS blocks to have a suitable header hash.

Such threshold looks like allowing the PoW generation only for miners with 8 or 10+ MH/s. I mean it's pretty senseless and won't change anything. This measure is only able to increase an extent of the problem by decreasing active inputs amount.

Recursion here, you can't define an argument of difficulty function as a function of difficulty.

Balthazar, thanks very much for your input!

So, what does everyone thing we should do?  I think if something isn't agreed upon soon, it may be a good idea to just rebase YAC to the latest NVC source.