Naw, there is a bitcoin at 300.  It would eat your 389k.. Also during those huge dumps the bots come out and play and create liquidity as well.

This is what happens whenever I have tried to -salvagewallet this one

2017-07-14 19:52:55 Renamed wallet.dat to wallet.1500061975.bak
2017-07-14 19:52:55 Error: Salvage found errors, all data may not be recoverable.
2017-07-14 19:52:55 Salvage(aggressive) found no records in wallet.1500061975.bak.

2017-07-14 19:54:03 Failed to rename wallet.dat to wallet.1500062043.bak

and the client exits. I gave up before when this happened because I couldnt figure it out. Is it doing this because the wallet was encrypted?

also, db.log gives me a bunch of errors. heres the last one

wallet.1488662875.bak: DB_VERIFY_BAD: Database verification failed
file unknown has LSN 359/6987529, past end of log at 71/4537095
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment

Hmm A possibly corrupted encrypted wallet.. I am not sure I have dealt with that yet. I will ask the obvious, do you have a backup before it was encrypted, or one that was encrypted but from a while ago?

I don't know if the database dir has much do to with it. But you should attempt to salvage on a clean database dir as well. Under a separate datadir, so you don't mess up your normal wallet.

I think the coin age and the development activity are important, plus 100% yearly is not that high

OK this seems crazy to me but, here we go ....
I tried the -salvagewallet - still crashes same way
I tried a lower version HoboNickel wallet - dies same way
I tried it with the original wallat.dat - it still dies, OK yea, that got me thinking too
So I tried the same procedures on another computer, another Windows 7 Pro, this one is 64bit - and it comes up fine.

That original computer that it kept crashing on was a freshly formatted PC, with a fresh OS installed.  What in the world could be wrong with that PC?  That is hates the HBN wallet so much?

---

I have 0 (zero) network connections, what am I missing.  (I only rebuild wallets about once a year, so I have to learn most of the stuff all over again)

Hey Tranz, I have a problem with 1.5.2.0. It crashes on start up.

hobonickels-qt: src/kernel.cpp:372: unsigned int GetStakeModifierChecksum(const CBlockIndex*, bool): Assertion `pindex->pprev || pindex->GetBlockHash() == (!fTestNet ? hashGenesisBlock : hashGenesisBlockTestNet)' failed.
Aborted

If I comment out that line in the code, it dies anyway.


If I delete the chain data and sync again, it gets stuck at 90-something days ago. Restart and the same crap happens.

Does anyone know what heppen with cryptopia wallet?

Bit of an orphan fest right now?

Either 1.5.3 or the fact I have let my stakes run down to many small blocks this time around. The hit rate is 5 stakes 105 orphans overnight

New client did struggle a bit to get in sync and stay there - last block time is laggy but I'm not sure that isn't just GUI update lag
POS block info window seems very shy these days.

I'll get a transaction stuck on 1 confirm for 5-10 mins and then suddenly 24 confirms and a bunch of stakes go orphan with it.

Also seems to be behaving worse @ 1.6GB ram usage than @ 2GB

Are we are waiting this out for block 5.6M?


.. wow this is like going to the doctor. In the time taken to type this a flurry of confirmed Stakes arrives

Yeah me too but started to feel guilty about not holding up the network so decided to let thinks take a natural course.
I think I have found the red line.

Orphans are caused by lots of things. For HBN the reasons are many, but not without solutions.

1) 30 Second block time. This is very hard to get a block transmitted around the world in 30 seconds. ALso each block times CPU and time to process, which cause GUI and Staking lag.
2) PoW and PoS which effectively changes the block time to 20 seconds or lower.
3) Low difficultly with a lot of coins and a lot of hash out there. This allows people to generate many blocks very very quickly. Which can cause the network issues while everyone is catching up.
4) Staking efficiency.


To fix these here is what we can do.

1) We need to talk about changing the block time to something a bit longer. I am thinking 90 seconds.
2) PoW is going to be slowed down and eventually effectively eliminated.  So this will help
3) This will be fixed with #2 and #1.
4) This is in progress right now and I am hoping to have it released in version 1.5.5

I am going to commit version 1.5.4 tonight. It will contain some malleability fixes and adds the ability to watch and report on other address that you do not own. Usually referred to as Watch Only. So you can use it to watch all of you wallets in 1 place, or spy on a large address to watch what is going on. 

It required by Feb 2018, which is approx when all of the forks, whatever the happen to be, will take place. Those not in version 1.5.3 that is.