Can only wait and see if devs can provide some light on the matter. Maybe to make force and update though to old wallets to announce new wallet download and release.

Feature for the future.

Wallet updater. On loading wallet has little feature to check current version and also announce and a small popup saying update available download and update gives option to close or update. When clicking update launches command to close wallet and update services in background and then pop back up and run client after update with another one saying successful That way users would get updates a lot quicker too:)

I have been getting a few blocks on v2 for the last hours, are these on the right fork?
(this includes blocks mined by rich list list #12 and #9, so if it's a fork, they would be on it as well)


Technically speaking, the file is not provided by the team, but by a link to a mediafire url.
The trust issue is not about the dev team, but about whether the data you get may or may not actually be from the dev team

The github source code is trustable, as it is hosted on an https server, with a well identified url and a list of recent changes/commit and git's own tamper-proof hashing, so any hijacking attempt would not go unnoticed, but the mediafire link on the other hand is "meaningless", http, and the data itself hosted by a 3rd party. This is vulnerable to several vectors of attack.

When replacing the db, the wallet will only check the last 2500 blocks, while when using a bootstrap.dat, the wallet will check the whole blockchain, making hijacking attempts as hard as a full-scale 51% attack, so it's okay to host the bootstrap.dat anywhere.

Got past 262799 with the bootstrap, but with the previous version (2.0 did not get past it)

Now trying to switch to 2.0... It's getting stuck :/

Also the July fix seems to have been reverted in 2.0 with a "version bump" comment, alongside actual version bump commits, could that be the bug?

We are coming for Number 1.000.000

Not accusing anyone, just pointing that a mediafire download of a raw db is not trustable in several ways (it's vulnerable even to simple network corruption)

The bootstrap.dat is a pre-download of the chain on the other hand, but the client will still validate all the blocks (which is why importing a bootstrap is slow), so it's okay to get one from an untrusted source.

can someone please provide a working bootstrap?  The one on the website won't load properly.

our chain isn't re-org'ing properly and it looks like we're stuck at a block.

Postponing 213 reconnects
REORGANIZE
REORGANIZE: Disconnect 0 blocks; 47d2dd6bd61953a2dce4..47d2dd6bd61953a2dce4
REORGANIZE: Connect 1 blocks; 47d2dd6bd61953a2dce4..7b898ae61611fdd3e411
ERROR: ConnectInputs() : 901f545ae2 stake reward exceeded
ERROR: Reorganize() : ConnectBlock 7b898ae61611fdd3e411 failed
InvalidChainFound: invalid block=ccde9b849ce3d929238f  height=288010  trust=81800836414611  date=08/31/15 02:00:37
InvalidChainFound:  current best=47d2dd6bd61953a2dce4  height=287796  trust=81683904261753  date=08/30/15 18:29:31
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 21803d32c0ccfd8db3da
Postponing 214 reconnects

thanks,
richie@bittrex

Thanks - I now understand & see that Navajocoin has fast transaction times in the seconds and #Bitcoin can take a minimum of 10 - 30 minutes on Exchanges . Sometimes even an hour. Also I feel that Bitcoin is not worthy of being King Crypto. When I to use it in the real world it's slow and disappointing  (with respect).

I believe in Decentralization greatly and thank you Bitcoin for doing all that.

Soopy can Navajocoin take the King crown and if Navajocoin gets a  direct Fiat conversion capabilitie could this happen. Or is this simplify not possible for Any Altcoin

i have a friendly question soopy. now that bip is implemented, can we change the roadmap to; percentage of progress meters? would make more sense. that way the only questions youll get is the, "why has it been at 34% for a week?" ... then you reply with, "i have to sleep sometimes." ... i guess this is also a strugg question.

I am sorry, but. 2.0 does not make sense... 1.1 makes way more sense...... 1.0.9 -----2.0 really.... Sorry I am not fudding. 1.1 makes WAY MORE SENSE

Thanks Soopy

Will the Navajo Web Wallet and  Navajo Air Android Web Wallet be released at the same time or separately . Also will you be  doing the  development for Android
Or does BIP32 simplify  both releases.
HaSh

Edit : Also what's your opinion on  Bip 100 & BIP 101 Large Block Size  

Nice, Now if he answers my PM.

All I can say right now: Allow him some time.

Yeah, soopy has been very busy, recently.

I totally understand, I give him time....

As promised here is the new analysis on the number of addresses that generate
block, day by day.

The method by which it is carried out influences the results obtained, so here's a
brief description of how it was conducted, sorry to be a bit boring.

The files of 73 MB of which I wrote yesterday, is a list of the blocks produced by
block 1.4M up to 1,669,266, the last block of the day 26/07/2015 (UTC time).

The blocks of the next day accounted for only a part of the day, and then I have
not included here.  

The file has been sorted for the block date [1], and every day, were counted the
blocks (from which to derive the average block interval), and the addresses which
have generated at least one block in that day.

The extracted data are fairly coarse, their resolution is in fact a whole day, but I
hope that makes the idea, consider them only as preliminary data.
Perhaps it is too coarse for a precise analysis of cause and effect, if you need a
more precise let me know.

In this period of time, the number of addresses that have generated blocks is varied
between a minimum of 124 and a maximum of 162, also quite a few after all.
The number of blocks produced daily was between 3532 and 8298, far too many,
considering that should be 2880.
The average interval between the blocks is gone from a maximum of 24.5 to 10.4.



At first glance, there may be similarities between the tracks, but if we look
carefully we can see that the block interval in some cases has been dropped
even when the number of users was practically stable, or even decrease.

Perhaps it might be more likely an inverse relationship, I mean, when the block
time interval and PosDiff fall (see chart from yesterday), then the addresses
which typically fail to get into the game, producing a few small block more often.
And so shortly after the fall we see the effect of an increase in the number of addresses.

In summary, your hypothesis that a greater number of users has resulted in an
acceleration of the product cycle of blockchain not seem sufficiently supported by
data, but this is just my interpretation of these coarse data, not necessarily the
correct one.


[1] Small note:
In early attempts to process the data, I did not do the sort of lines based on the
time of the block, and I got strange results, such as "days" that contain only 4 or
5 blocks, followed by other blocks belonging to the previous day, then some of
the next, and again the previous one, and finally a series of consistent data.

This odd behavior at the edge of date change, I would have expected
for 1-2 blocks, but 4 or 5 jumps one after another seem far too many,
abnormal, rather symptomatic.

As an example you may try to control the sequence of blocks between 1652846
and 1652867.

This oddity is evident during the date change, but I think it also occurs
during the rest of the day and days.

Bye Bye

Very small update:
The previous graph was unsatisfactory for me, too coarse, and missing
data from the last hour.
This new has a resolution of one hour, with the values that are calculated on frame of
previous 24 hours, and covers data from 1.4M up to block 1,679,912.



The observations made in the previous message seem confirmed by the new graphic.

Bye Bye

I'm glad that I'm with the coin from the beginning, even from the time Summercoin.
If the team starts it everything it promised, it becomes a coin NAVAJO very unique and appreciated.

GOOD WORK SOOPY AND TEAM

Well, I would like to avail myself of your great experience, and kindly ask you a few things:
 A) What do you think about of this acceleration of the block chain?
 B) What do you think it could be the cause?
 C) What steps have been taken by the DevTeam so far?
 D) You have identified some sort of remedy, direct or indirect, or even temporarily,
to be put in place now?

I hope you will be so kind as to answer as soon as possible, because never as in this case, "time flies".

Bye Bye

Yes, you are right, but is even worst.

If we look at Explorer Block, and we set the block 1666855 as reference,
we can see that its Unix time is 1440604876.

If we look at the block 1665855, 1000 blocks before the reference above,
we can see that the its time is 1440594764.
So, the time difference is 10112, divided by 1000 blocks, we have the block
average time interval is of 10.112 seconds.

One third of what it should be.

Concluding, IMHO with this type of speed the NAV can only go in three places, the
"24 Hours of Le Mans", to "Indianpolis 500", or to encounter to trouble.

Bye Bye