Yacoin needs several issues fixed. I've already mentioned them to Joe and Groko, ane some bits I've posted here. My hope is to get larger audience onboard.
During past couple of months I've been analyzing the code, brainstorming and putting together blueprints for a solution.
It can not be done without hard fork, because of both - first and last issue. Fix for small PoS blocks can be rolled out incrementally.
Currently I am analyzing fix for chaintrust issue, because it underlies solution for others.
I will let you know about details in a day or two.
This will not prevent miner with 51% from capturing the chain, but fix for last issue will
force PoW miners to include PoS blocks and fix for first issue should make PoS blocks get higher trust value. Consequently block reorganizations should not get deep as now and stakeholders should get their power back.
Here are two drafts/outlines. Ask if something is not understandable.
And feel free to criticize or better suggest corrections and improvements:
fix trustfix ignoring PoS blocks...
...
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.
EDIT - answer2:
In your
http://yacoin.net/NewPreventPosIgnore.htm section you ask:
The later would mean we need to recalculate those values on reorganize (and at some other times perhaps?), therefore it would be more complex to implement.
How about calculating the PoW/PoS or is it the other way, ratio by just counting at startup in the load the guts code (db.cpp ->
CTxDB::LoadBlockIndexGuts()), that just plows through the blocks anyway!? There's this cryptic, at least to me, PPC code there anyway, that is:
// ppcoin: build setStakeSeen
if (pindexNew->IsProofOfStake())
setStakeSeen.insert(make_pair(pindexNew->prevoutStake, pindexNew->nStakeTime));Ron
That get's called at startup. You also need to count PoS blocks while being online and minting or receiving new blocks. And what about that big painfull REORGANIZE when all PoS blocks get trashed?
Hello 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?
In any event, when you say above,
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.
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?
And the function
min( 60,nActualSpacing) can be much less than one minute if
nActualSpacing is?
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.
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.
Ron
