I read the announce, the reactions, and I was surprised...
well... I expected a lot more insults.
Ok, jokes aside, I am pleased that there were no bad moods, I think that the
road taken by the DevTeam, is one that allows to get the best results quickly.
After the announce, there were some intelligent questions on the technical side,
and I think they deserve a little more depth reasonings and answers.
For example, the demand on the type of hashing and if there will be a POW phase.
If I have understand correctly, the Nav 2.0 is a predominantly POS type coin,
then there is not necessity of a strong POW algorithm to enforce a high difficulty
or Asic resistance. So I wonder, is it really necessary for calculating the blocks
hash, to use all the 13 algorithms of the X13 ?
Whereas this is a choice that will take you from here on out, it would not be
better to resort immediately to a calculation of the hash more simpler and
lighter for the CPU?
Regarding the POW stage, I think that a small initial phase is necessary,
at least from a technical point of view.
In case of pure POS coin, in the initial stage of life of the new blockchain,
there is a risk that it might get stuck because there are no mature coins
ready for the POS, and without a stream of blocks the Exchanges would not be
able to distribute the coins to the holders of the new wallet.
If the concern is not to increase the total NAV, the Dev might perform the
POW with a reward fixed at 0, it possibly should be enabled\permitted
automatically just when there were no blocks at least for a certain number
of seconds.
The DevTeam would be so kind to give us some more detail on this?
Another intelligent question, it is about the interval time of the blocks and
the waste of space in bytes which results in inflating of blockchain.
In order to reduce the daily blocks (and MByte), it has been suggested to
double the block time to 60 sec / 6 minutes for the minimum confirm.
But this request as been denied, and the time will still remain to 30 sec / 3 Min,
just like as it is now.
Personally, I like a quick time for blockchain, IMHO, it favors the ease of use
of the coins in real life, and it is more easier for everyone to produce POS block.
At same time, I understand very well the concern about waste of bytes \ resource
(and at long cpu time) that all this can leads, we have all a proof of what this mean.
If we see at the NAV 1.0 blockchain, it is just a raw estimate, but I think
over 95% of the blocks that have been generated so far are useless, because
they do not have recorded new real transactions, but only the TX needed for
the POS itself.
IMHO, This it one thing that few can know, but that should not be ignored.
Of course part of reasons of this, is due ehm... the lack of real use of coin,
and I hope for all of you this belong to the past, but in any type activity
there are moment of high load and other with zero work.
The new bigger size for block of NAV 2.0 can do its best in the moment of
hight load, but IMHO can do nothing for blocks with zero payload.
I would ask: would not be useful if DevTeam study also a system with a
variable interval time between the blocks?
Try to imagine a system which provides minimum interval time for blockchain,
to be used just when there are new transactions or they need to be confirmed,
and another more relaxed interval time, (ie a minute or more) to be used when
there are no real transactions in progress.
This system can potentially maintain a low transaction time, but at same time
avoid useless waste of byte for long series of empty block.
Or maybe they can explore other solution, with new more complex^2 routines,
able to recycle or "forget" the previous empty blocks, but at the same time
safeguarding the revenues of the POS of their respective owners.
What do you think?
