Pakage, as you know I always look for the most effective solution, so instead of a stapler, I guess
if you wanted to use a carpenter's nail, a 10 cm long ones, you may get a more... definitive effect.

 


An alternative solution, certainly better for you and all users, it could be that the DevTeam fix the
code of wallet/supernodes so that there is no longer need to manually load the addNode, or peers.dat.

IMHO, this should be a priority over any other development.

PS:
IMHO, Eventually also the pacemaker for the stake, could be useful.

Hi Dev!
Starting from the bottom to create "(yet, another one)" coin, is
not a challenge of little value, so in any case I congratulate you.

Before going into further details I would like to better understand
the prospect of this significant effort you are making.

The design of this new currency, which it wants to be:
a) A "simple" proof of concept that it is an end in itself?
b) A limited prototype, you need to prepare something different,
which you have already started to design?

c) The advanced stage of a defined project, but not yet totally evolved?
d) Or this is in effect the final stage (or almost all) of the project, then
a valid coin ready to be used for real, and to land to the Exchanges?

TIA

ps:
Watch out for the "List index out of bounds".

A small notice for new beginners, the conf shown by Shahim must be
customized by you for safety reasons.

To do this, change the lines rpcuser= and rpcpassword= with a complex
string that only you know.

You have no reason to accept connections from an external IP,
so unless you know what you do, it would be useful to delete the line
"rpcallowip=5.230.142.254".

Finally, once you have completed all the procedures, and you are perfectly
in sync, remember to reactivate staking changing the line:
staking=0
to
staking=1

These are things that experienced users know and can confirm,
but that might be unknown to beginners.

This is my advice, then you do as you please.  



EDIT: obscured connection detail in the quote.

I guess you are referring you to Nav 2.0, in this case the directory should be NavCoin2.

No, he's right, the Nav is dead.

Shahim, you know this better than anyone else.
Thou hast turned off its blockchain.

I do not blame you Shahim, that is clear.
After all it was a fact that had been previously announced.
We knew that for Nav 1.0 soon his time would come.

So let my express my personal condolence at DevTeam &
 Foundation & all community.

However, know that NavajoCoin is ceased to exist so, alone,
in silence and without the comfort of friends... sorry, it hurts.
Shahim, tell me the truth, in its late moments... it suffered?
How old it was?

At least, I was hoping for some word of farewell by the Dev Team.

IMHO, for sure the NavajoCoin not had an easy life, it was not all gold
that glittered, indeed very few of us have received what they hoped at
the beginning.

From birth it has been attacked relentlessly using arguments futile,
but this certainly could not stop it, or its community.

The biggest insult of all, however, was being looted and sold out to
the markets due to a double expense, a kind of thing which had already
destroyed other currency most known which are now forgotten.
But no, despite this, thanks to the will of many, NavajoCoin resisted.

I remember at the time and later, that often made us despair or doubt,
how many times have we seen in the markets the Nav 1.0 sink or float
adrift as died, so someone has abandoned him.

I also think of how much work and how many sleepless nights have been
necessary to try to make sure that it would work as expected.

Yet this little bastard, supported by the DevTeam, Foundation & community,
gradually recovered, without a purpose without a reason, but it stand it,
survived.

Twice it went to the mat, sent stalled due to a kind of time-bomb, but as
a warrior, it was recovering.

Later a large entity, with his behavior has slowly poisoned it.
The pace of NavajoCoin had been damaged, it ran wildly and thus lost
a year of life in few weeks, therefore causing permanent damage.

The paradox, is that also in this case the NavajoCoin survived.
Because of the damage suffered its size has increased dramatically,
becoming resource-hungry and not very snappy, but it has survived,
continuing stoically his duty.

The same however can not be said for the mysterious entity, that shortly
after he stopped all activities, leaving inert his assets.

Now a new generation, the NavCoin 2.0, is ready to take the inheritance
of the old warrior, ready to support all its commitments and go even further,
already getting better results than its predecessor.

But who could see all this with his own eyes, who knows the NavajoCoin
history, he knows that the warrior passed away while he was still on duty,
aged, wounded... but never defeated.

As told of another more famous commander, "A quarter hour before his death,
he was still quite alive".

 
PS:
Aside jokes...

Speaking in general, the value of a cryptocoin, is not just what you see in
the markets, this changes like a leaf in the wind.

I write it now and you never see more:
Also the wallet code has a relative importance.
It can be changed completely, or correct in many ways with a pair of lines.

IMHO you should consider more the people who are behind some money.
At how they react to avversity.
The trust of a community, is not something which can be easily creates,
or even that can be adjust it with a couple of easy fixes.

Even you don't have to believe to the evaluation of an article, from what
was written by this or that person. Or worst at pump.

IMHO, Only after knowing all of the facts together, you will be able to
make a your considered judgment.

ROTFL!!

Sounds like a cruel and unusual punishment to me. 

I also believe that many among the boldest could flee away screaming, well
before they reach the last pages.

But if you want to start from the very beginning, you should also read the
SummerCoin threads.   

I think you're stacked in a private fork, very deep, generating for the rest of NAV
network only a lot of orphans blocks.

The solution has already been indicated by Pakage, the full reload of blockchain.

After downloading of zip, to allow the wallet a better final sync, which is a fairly
long operation, I think it may be useful to disable temporarily the staking.

The money that were sent were in a different fork, literally it has never happened.
When you hast returned to the official blockchain and repaired the walled,
your money will still be there.

Obviously, also all stake made in your private fork did not occur, really.
You can fully recover your earnings with the next stakes.

He 's not the only one in these conditions, I believe that the address NQzRPy ... uymRT
is in much worse conditions, it has generated thousands of orphans blocks.

I think both should carry out the manual forced re-sync of the blockchain as soon as possible.


PS:
Sorry for the overlap.

Honestly, I do not know.

In the last hours I was in the new blockchain, to increase the number
of nodes in sync in the right fork and facilitate the stabilization of the network.

The two networks share the same ports, and if I now close the new wallet and
launch the old wallet, changing reference network, I should still continue to receive
connections from the nodes that they had seen me in the other network.

I believe that the new wallet shortly after the connection would reject me, but given
the situation, for the time being I would like to avoid mixing things and instead proceed
in the manner as clean as possible.

In the coming days, when there will be more peaceful conditions, I hope to be able to answer,
although Shahim definitely has a more clear vision of the old network nodes.

EDIT:

Some vague memories which I can't verify, a few days ago in the old blockchain I
thought I saw an old node yet to version 2.0.5, and another node with a newer
version, but that day after day remained locked and it could not go forward.

Who knows, maybe one of them is Yobit.

The yours is a well focused analysis, as ever.


Thanks for the update.
You must have a good machine, I thought a little more time.  

Now to complete the curve I only need an estimate of the final time to complete the bootstrap.
As you said, when it finished the bootstrap should be left a few orphan block, and this gives us a time trace.

In rounding to the nearest ten minutes, in order to avoid identification of your address,
you may write the time of the first orphan block?

TIA


Wow. Very impressive!
My TopStaker statistics show for him 505 stakes in a row.
I hope it take a little breath, or really it will need a pacemaker.

These are exceptional times, in many way.

Wrong port.

Maybe if you agreements in PM with Shahim, you could try with a reverse
connection.

I mean that could be Shahim which try to to add your ip to the list of its
nodes, and start an incoming connection (view from your side).

PS:
If I remember correctly, the RPC command to do this on a temporary basis should be:
addnode "ip" onetry

LOL!!
Shahim, if there is one thing of which you and I are both experienced,
well this is definitely the bootstrap of the Nav.

Indeed as you say, during the bootstrap you do not need to be online.

There are other factors that determine the time required to bootstrap,
for example, the hardware configuration... or the software.

Thanks Bspus.
IMHO This is the correct\canonical way to load a blockchain,
in this way each block is read, fully controlled and therefore indexed,
just as if it was downloaded from the network, but without having
to be online.

Do not worry, take all the time you need.
As you may have noticed the progression is more than linear.
 
You're right when you say that to a higher frequency of stakes,
often it is also accompanied by a higher probability of producing
chains of orphans blocks, is something that we have experienced all
many months ago.
 
Perhaps, in the future the DevTeam could imagine a kind of
simple "pacemakers", which avoids the production of too many
consecutive blocks by a wallet (too heavy).

For example it may be sufficient to impose a pause of 40 seconds
of sleep to the miner, after it as produced a new block.

This is a simple thing that they can do with a couple of lines.
I think that would not result in losses to the miner, but on the
contrary it would give everyone a chance to produce blocks.

Moreover giving the possibility of alternating the blocks created
by different wallet, it could increase security and possibly lessen
the orphans.

What happens now is that a few hours ago, after the stall of the
blockchain the PosDif collapsed at very low levels, but fortunately
now is recovering, as you can see here, in the chart below:
https://chainz.cryptoid.info/nav/#!extraction

I imagine that when you've finished bootstrapping, POSDif will be returned
normal, but in the meantime it will not surprise me if there will be a few
more small number of orphans, and a bit of Yoyo effect in the staking times
and PosDif.

Would you be so kind as to take note of how long it takes to complete the bootstrap?
It does not need a precise measure up to the second, even a crude measure would be helpful.

The time can also vary according to the hardware in use, so it would be useful to have data from different users to aggregate.

In fact it is something that usually is not measured very often.

I got there by accident, trying to understand why the wallet took
so long to load so few blocks.
Reading between the lines of the messages in the forum, written by
other trusted users, I noticed that they also had some difficulties
in the initial sync.
 
From the data that you have shown, for which I thank you Shahim,
the difference seems remarkable, about 60% larger.
It must be noted that also in the "my" wallet the txindex is enabled.

What seems to be missing in the "standard" NAV wallet, is an option to
disable the updating of the addrindex.

The easiest way to do this, you can find it by making a side to side
comparison between the group of lines, in the standard Nav wallet code:
https://github.com/navcoindev/navcoin2/blob/master/src/main.cpp#L1848
up to the line in 1892, and those lines that you can find here:
https://github.com/transferdev/Transfercoin/blob/master/src/main.cpp#L2100
until the 2147 line.

Only a few lines seem to be missing, this could be an oversight in the
process of editing, or they may be removed for some good reasons, that
simply I do not know.

This is the reason why I asked Pakage, how much those additional features
are necessary for normal users.

This new wallet, is in some ways still a new thing, I think we still have
to know him well, and maybe there is still some details to be tuned.

 

Ok, sometimes can happen.

You could start reading this first:
https://bitcointalk.org/index.php?topic=679791.msg15111383#msg15111383

and then this:
https://bitcointalk.org/index.php?topic=679791.msg15407396#msg15407396

they are both tightly connected.

This potentially can be an issue especially for you, I mean for the the raspberry
standalone staking unit.

In this case the size matter, and a high growth (and rewrite) of the txleveldb,
will also mean a high use of mass storage device I/O, with higher use of
CPU resource, which are both scarce in that type of micro computer.

But it is not just an issue for the raspberry, each type of node in theory is affected
by this slowdown, although a few may realize it, because it is progressive and
spread out over time.

Just FYI, I'm running a version of wallet with the continuous updating of data
used by that function disabled, so in this condition the size of my txleveldb dir
is currently 88.931.647 byte, at block 178978, while the blk0001.dat size
is 95.087.484 byte.

Now I have not a direct element of comparison with the directory's size
of a "normal" version of wallet, so I'm sorry for be so raw but I must ask,
how is big the yours?   

Hmmmm....
I have a curiosity, would you be so kind to look in your debug.log
to the rows with a text similar to these:
Loaded ### addresses from peers.dat ## ms
Flushed ### addresses to peers.dat ## ms

Apart from this, your firewall / nat / router or whatever it is, has
been set up to accept incoming connections on the wallet port?

LOL!

Warning, a large senseless wall of text approaching.  

There are be different types of staking strategies, that can be put
in place by choosing or not the size of the coin piles, and if put them
all into a single address or multiple addresses.

Each strategy has its pro and cons.  

For example, the strategy of having many small "piles", if on one hand
it allows to have a proportionally greater number of candidates to the
stake, at the same time each of them will have less "weight" and therefore
less possibility of producing a stake (especially if the posDiff has an
increase), and will produce interest on a smaller portion of the total
figure.

A single pile instead would have greater weight, and more probabilities
to produce a stake, but in case of bad luck, even a long time without seeing
anything positive.

As rightly pointed out, when stake a "pile" with more than 100 Nav,
it is automatically split into two new piles.

Instead, if the value of pile is lower, it is not split, then there is also
another mechanism start, that is little known, the dust collection.
When this happen, other piles are searched for that belong to the same address
of kernel pile and which have not staked from several time,
and if found, they can be collected together until they reach a figure
of about 1000 Nav.

This useful mechanism tends to recover the "dust coin pile" that due to
the split have become too small to be able to produce on their own
a new stake.

So, the strategy to split the "piles" in many different addresses, would
interfere with this recovery mechanism, and solitary pile too small could
end up not ever produce one stake or only after long time.

Fortunately, whether the pile are small or large, whether they produce
a stake after a short time, or after a long time, when staking they still
produce each a fair interest of around 5%, according to its age.

Of course, apart from these automatic mechanisms, can always be intervene
manually via the coin control, to subdivide or to aggregate in other sizes the
piles, and send-back them to own address.

Considering all this, many strategies are possible, which can be more or less
valid according to the own habit and figures in the field.

IMHO, Everyone should experience them personally, to develop the one that
suits him best.

Often a cause of too many orphani blocks, could be due to some
incomplete previous transaction (check with the rpc command "checkwallet").

However, sometimes it may be due to the simple fact that your PC has a
system time too early or late, and this is easy to check.

I also take this opportunity to remind everyone that the new
blockexplorer is very full of useful information, such as:
https://chainz.cryptoid.info/nav/#!extraction
where you can find the list of topstaker, and also a diagram of orphan
blocks generated in the last week.

I really like this new blockexplorer.

I think the command you are looking for is "-rescan", and it is
also present in NavCoin wallet, but it is not an RPC command that
you can use in the wallet when it is already running.

This is a command that must be invoked at the time of startup of
the wallet program, at the command prompt level or in the shell,
for example with:
navajocoin-qt  -rescan

This reviews the entire blockchain looking for missing transaction,
or which are not recorded in own wallet, and is a task quite long.

I imagine that you know well what it does, but I wrote this for completeness only.

LOL!!

I'm still around here, for the moment...
and I'm still waiting for some technical answers by the DevTeam. 

Just to say, even just a one line reply, to understand if the question
has been read, and it was compresibile.

However, I saw that a few days ago here there was a lot of activity of
new names, and I imagined that a stickler b.+breaker like me, was
better to be quiet... just for the moment.

Thanks for the nice words, but I will not be part of NavTeam, a personal
decision I took many months ago.

Apart from that, you're wrong, how you might forget one of the oldest and at
the same time, the youngest investors of this forum, the son of Juguelo,
though I imagine that for now he can't yet read.