That is really fast. I wasn't aware about this explorer. Tnx.
Besides I have been getting a lot of errors lately with explorer.yacoin.org (python script, class 'psycopg2.DataError...).

Any news regarding yacointalk?

Now explorer.yacoin.org is not operational (throwing errors).
And it looks like yacoin was removed from coinmarketcap.com (possibly due to new cryptos flood).


As for Cryptorush it seems to me there is automated voting going on (or someone is clicking like crazy). This is not how I imagine successful cryptocurrency rise.

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.

Here is an example I had in mind:
Rogue miner is mining private chain and when he gets far into the future he starts mining with higher difficulty than he thinks real difficulty will be at that time. If you just compare latest blocks when he releases his chain you might prefer his fork.

Remind you that I do not know how chain forks get compared in detail.

As mentioned before: PoS block spacing and thus occurrence can be controlled.

Difficulty alone is most useful for block to block comparrisson (but not only that).
I am trying to point out that PoW currency supply can be used as additional input for calculating chaintrust. It can be looked at as a historical difficulty average.

Even if you leave the attacker control over number of PoS blocks, you can still average the sum of PoW rewards over number of PoW blocks and use that as factor.

Another thing regarding chaintrust calculation:

Since reward considers difficulty and get's lowered with higher difficulty, private miners would produce higher supply in equal timeframe.
EDIT: presuming PoS block count is equal or similar (but that can be enforced)

1.
Private mining needs wider timespans between PoW blocks in order to keep difficulty low.

	t1	t2	t3	t4	t5
◔	▉	▉	▉	▉	▉

Average of PoW block intervals ( t[ i+1 ]-t[ i ] ) should be therefore longer with fake chains. And that can be used for chaintrust calculation.


2.
Window for one PoS block opens randomly

Prevents miners to exclude PoS blocks and replace it with more profitable PoW. I think it also makes it a bit harder to prepare for network takeover with private PoW mining on lower difficulty after PoS is found. With shortening intervals on each Nfactor change it also enables gradual PoS mechanism takeover.

Example formula: mod(last1440blocks.getTransactionCount(), x) ==  0
X could range from 500 ( approx. 1-3 times a day ) down to 10 (every ten minutes).


3.
No two consecutive PoS blocks allowed (prevents PoW block orphaning)

---

What would be an possible attack scenario or significant shortcoming if this is implemented?

I think I have a solution (not centralized) for comparing different blockchain forks.
However I need some more information.

How do yacoin clients fetch data from other peers - do they ask for latest block and then get them one by one by previous block link or do they go in other direction and ask peers for next block from the time of their most recent block on disk?

Thanks a lot for explanation and your valuable insight, Balthazar.

This is really complex stuff and I have read it again and though I do not get it all (and probably not right either), I do have some thoughts.


EDIT-new paragraph:
If this quote from Sairon is correct, PoS window periods mentioned on previous page could be used as checkpoints. Software should calculate the difference between timestamps of PoW blocks between PoS blocks and the result could serve as a chaintrust value.

Blockchain fork with lowest time difference should be considered most valid one.


EDIT-old paragraph ( I don't understand anything written )
If this quote from Sairon is correct, before mentioned PoS window and the next one could be used as checkpoints. If software would be set to calculate distance to next PoS block to be 59 PoW blocks ahead, the difference between timestamps of PoW blocks on both edges between PoS blocks could serve as a chaintrust value - or is it active weight?

Blockchain fork with lowest time difference should be considered most valid one.
And actual equation would probably be more complicated (considering many segments).

Perhaps we could also use PoS timestamp in calculation...

Can someone please explain what can the attacker do if Sairon's fix (no two consecutive PoS blocks) would be merged with criteria for dynamic PoS block window opening a couple of times a week (and later per day or hour)?

EDIT: I've read the previous page again and my understanding is that somewhere in the future attacker generates a chain that replaces original chain with clients that are not on latest chain.
Is that correct?
And that is all because of one (to keep it simple) PoS block inserted?

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.

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.

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.

Would it be possible to implement automatic calculation of how many PoS blocks can be allowed one after another based on N factor?
This is my idea and let's say for example that we get a new fork on February 1st. Column "Blockchain example" shows what could be allowed ( Nfactor-13 consecutive PoS blocks )

▉  PoW
◔   PoS

Nfactor	Date time	Consecutive PoS blks allowed	Blockchain example	N	Memory	Timestamp
14	We are here		◔◔◔◔◔◔◔◔◔◔◔	32768	4 MB	1384768416
14	Sun 1 Feb 2014 00:00:00	1	▉◔▉▉▉◔
15	Sat 31 May 2014 14:13:52	2	▉◔◔▉◔◔▉▉▉◔	65536	8 MB	1401545632
16	Fri 05 Sep 2014 16:24:00	3	▉◔◔◔▉◔◔▉▉◔◔◔	131072	16 MB	1409934240
17	Tue 23 Jun 2015 22:54:24	4	▉◔◔◔◔▉◔◔◔◔▉	262144	32 MB	1435100064
18	Sat 16 Jul 2016 07:34:56	5	▉◔◔◔◔◔▉◔◔◔◔◔▉	524288	64 MB	1468654496
19	Tue 08 Aug 2017 16:15:28	6 or perhaps release restrictions?		1048576	128 MB	1502208928
20	Fri 16 Oct 2020 18:17:04	?		2097152	256 MB	1602872224

I can not imagine YAC having any distinct advantage over other prominent coins without POW far in the future (at least a couple of years).
And if Yac is to succeed N factor will be the key driving force for superior POW block distribution.
Remove that and you are left with just a bunch of coins in a few hands and have initiated euthanization of a plain clone.

I am ok with Feb 1st or even sooner since I believe Yac has a lot of attention right now due to exchange problems.

You will find more answers on yacointalk:
http://yacointalk.com/forum/index.php?action=recent

yacexplorer.tk has been hacked...
You get redirrected to some ad sites.

And regarding this:

... here could be an explanation:
http://yacointalk.com/forum/index.php/topic,473.0.html

Sorry, don't know that. It's been a long time since I cpu-mined LTC.
And very short period unfortunately

I am hashing at about 1K/s ( that made from 150-180 coins last couple of days - but not today ).

This is what I get:
YAC/LTC profitability: Infinity%
YAC Mined per day: 166.83 YAC / 0.0113463 BTC / 13 USD



Guess I earned less than one tenth of that due to pools outage today.

Does anyone know what is going on with yacoin mining pools today?


yac.coinmine.pl:
[2013-11-28 20:35:17] HTTP request failed: Empty reply from server
[2013-11-28 20:35:17] json_rpc_call failed, retry after 30 seconds

yac.ltcoin.net very unstable, almost no rewards and a lot of errors:
[2013-11-28 20:22:59] HTTP request failed: Operation timed out after 30186 milliseconds with 0 out of -1 bytes received
[2013-11-28 20:22:59] json_rpc_call failed, retry after 30 seconds
[2013-11-28 20:23:50] HTTP request failed: Failed connect to yac.ltcoin.net:5555; No error
[2013-11-28 20:23:50] json_rpc_call failed, retry after 30 seconds

pool.yacointalk.com:
[2013-11-28 20:35:11] HTTP request failed: The requested URL returned error: 403 access forbidden
[2013-11-28 20:35:11] json_rpc_call failed, retry after 30 seconds


I posted this question here too:
http://yacointalk.com/index.php/topic,482.0.html