If your backup is made with 0.5.3 or earlier wallet , then follow my instructions .

1. exit current wallet .
2. download 0.5.3 wallet , install , run , import the backup , exit 0.5.3 wallet .
3. install 0.8.1 wallet directly , no need to import backup , wait for sync ...and done .

Yes, this is a known bug that has not been tracked down yet. This is the workaround for now.

can someone tell me what this means? i do receive that message when i try to trade on the bts exchange.

What is the exact steps you do when you see this message?

When i ran my old copy of v0.7 and I was able to see the missing BitAssets - I couldn't figure out how to get more info on the transaction, as it was labelled "virtual"  which isn't clickable to get more info on, at least i couldn't get the transaction details by clicking on the yellow "Virtual" tag, like i can when i click on the blue "Details" tag in the log...?

Can you post or PM me the transaction ID(s) for the original transactions where you made a bid/ask/short on the market that result in the "virtual" payouts of the now-missing bitassets?

Quote from: arubi on March 26, 2015, 02:10:19 pm

I still don't understand why minority fork clients don't just discard whatever short chain they're on and join the main chain where we have >90% delegates participation. We can't rely on checkpoints for long

We only save the undo state for about an hour's worth of blocks (maintaining it is expensive).  For short forks this works out well, but if you get on a fork with >360 blocks on it, you won't have enough undo history available to roll your blockchain back to the fork point, thus you'll never be able to rejoin the main chain even if your client knows it is better and has downloaded all the blocks on the main chain.  If you don't have the undo history to get there, the only other way to get back to the fork point is to reindex or re-download the blockchain from the beginning.  And when re-downloading, as long as there are publicly-accessible nodes out there serving up the wrong blockchain, there's a chance you'll connect to them first and download the wrong blockchain and end up back in the same state, unless you force your client to reject the wrong chain with checkpoints.  Fortunately, as more public clients switch over to the main chain, the chance anyone will end up syncing to a minority fork decreases.

I haven't read the rest of the thread but the above is the primary problem, and is common whenever we hardfork because we get long minority chains from delegates who haven't updated.

There is also a second problem where blocks after the hardfork are not necessarily invalid for old clients. So they might upgrade after the hardfork and if they don't reindex, they will have an inconsistent state but cannot tell until they finally start rejecting blocks.

It seems like we can mitigate the most common issues by a combination of:

• Force all blocks after a hardfork to be invalid for old clients
• Always reindex for hardfork releases
• Always release a version with a checkpoint right after the hardfork as soon as possible. And force a reindex on startup if any checkpoints dont match the current state

Also theoretical had an idea to stop old clients syncing before a hardfork. I am not convinced it is worth the effort, but here is part of our conversation:

[3/26/15, 4:49:46 PM] Vikram Rajkumar: there is a remaining problem due to our implementation—some delegates will not upgrade and so old clients will go down that minority chain—once they go too far and are past the undo limit, and upgrade to say 0.8 for example which has the new rules but no new checkpoints after the hardfork—they are still stuck. it will not resync or reindex
[3/26/15, 4:49:56 PM] Vikram Rajkumar: automatically. so not sure how to address that
[3/26/15, 4:54:09 PM] theoretical bts: i think we talked about this the other day...have delegates publish in public_data the block number of next hardfork as well as the version they are running
[3/26/15, 4:54:53 PM] theoretical bts: then if client notices majority of delegates claim there is a hardfork at block #X but block #X does not exist in local hardfork database, client warns user that they are out of date and stops syncing at block #X
[3/26/15, 4:57:30 PM] Vikram Rajkumar: yea i guess that’s better than what we currently do is which is just disconnect all old clients from the main chain

We've identified some problems with our strategy of handling hardforks that could leave people stuck like this. For now the most sure way is probably to fully resync with --resync-blockchain or deleting chain folder.

No difference anymore between 0.8.1 and 0.8.0.

You got stuck because you synced up too far on the old version after the hardfork--you will have to resync from scratch probably. We are thinking of ways to address this for future releases.

Oh man this version is awesome, so so smooth! Nice work

OSX Yosemite with 8GB ram.

When was the involuntary 0.1BTS receive fee decided on? I think this should be re-thought because at the moment. there's nothing stopping a rich twisted person from setting their transaction fee to 0.1 and sending <0.1 payments to people thus reducing their balance overall.

It's not a receive fee, just a transaction fee. Right now you don't pay anything extra for including dust in a transfer.