The wallet does no process control and has no ability to start itself back up again.  If you're running this inside a VM maybe the VM is broken?

Did you import the wallet seed through "Advanced" -> "Accounts" -> "Import wallet" and "Import seed"?  I just followed these steps and got the same sequence given the same seed and the account balances showed up again.

I did notice the top sometimes cleared "synchronizing" but it wasn't actually complete when I checked "advanced" -> "ledger".  I'll try to clear that up.

The live network turned on in October 2015 so they would have to be from after that point to be live accounts.  

They would be named something like B2D6251D31A4DD03C9A4474FFEEA3DB1785D842651444D206DA8A186A853F9DE.json

and start with something like:


You can try to import it with "Advanced" -> "Accounts" -> "Import Wallet" and enter the file name and password.

Wallet seeds are obviously the easier method going forward, let me know if there are any issue.  I watch the google groups more closely if there's an urgent issue.  https://groups.google.com/forum/#!forum/raiblocks

I see, yes the x2 only has SSE3.

I will try to build a version with more compatibility.

This looks like an illegal instruction error cd00001d, probably from SSE4 instructions. What CPU are you using?

You can back up the wallet seed:
https://github.com/clemahieu/raiblocks/wiki/Wallet-Backups

This also tells how to save the backup files but if you write down the wallet seed somewhere that's the best way.

To prevent spam, each transaction contains a small proof of work, generated by the transaction creator and verified by everyone.

If this were to be used on mobile devices we wouldn't want to generate work on the device itself.  The blocks were designed so work is outside the signed area, a mobile device could generate an unworked block, send it to a service they subscribe to who will recognize their account, generate the work for them, and republish to the network.

If someone has high transaction volume they might want to distribute this load; this part is already implemented in the node config so I should probably update this item.

Yes this is approximately correct.  Details on distribution is here:

https://github.com/clemahieu/raiblocks/wiki/Distribution-and-Mining

Yes, you can write down the wallet seed for later reconstitution.  https://github.com/clemahieu/raiblocks/wiki/Wallet-Backups

Is this what you're looking for?

100% through a captcha on the website.  Currently at 1.939% distributed.

https://raiblocks.net/#/start

Others have requested we make this a little more visible and we're working on making that change.

Yes, a couple people have requested so I'm building one now.  I hope either tomorrow or the next day it should be finished.

I'll contact them again, I'm working on a BTC compatible API that could make their job easier.

Bittrex and C-cex are also leads that might add with the BTC API.

The core protocol is complete; we didn't announce before the code was finished.

Our roadmap of small feature improvements are here.
https://github.com/clemahieu/raiblocks/wiki/Roadmap

Let me know if you have any ideas.

Version 7.4.0 released featuring deterministic wallets

https://groups.google.com/forum/#!topic/raiblocks/uOG4XNUXsdY

Supply is at 1.772% distributed.

https://raiblocks.net/#/start

Version 7.3.4 released, optional update.

https://groups.google.com/forum/#!topic/raiblocks/xMAWD0AY1Vk

Sounds right I think, bootstrap poisoning is one attack vector.  One way to address this would be to bootstrap to your representative or whoever gave you your wallet code.  Presumably if you trust them enough to download and execute a program that manages your private keys, you can trust them to bootstrap you correctly.

Another option is to bootstrap to someone you're interested in sending to, a merchant perhaps, because in the end the only thing that matters is if they'll accept your payments as valid and they'll tell you what they're accepting through bootstrapping.

Another problem would be if almost everyone simultaneously changed their representative while forks were occurring. This would would require every account to be online and simultaneously signing a change to their representative; interesting but I don't see that actually happening.

This is also why storing historical votes is unnecessary per our previous discussion. Votes only matter when they're actively being taken off the network and weighed by the current ledger state.

This is to prevent history rewriting.

Nodes take the first block they receive or which ever block is winning in votes as observed by vote traffic coming off the network compared against the set of stake holders currently in the ledger.  Unless the stake holders from their perspective are voting for the new block, they won't evict a block.

It sounds like your describing a system where nodes compute accumulated stake in order to find a "highest branch"; RaiBlocks doesn't operate this way.

You can definitely make your local node do that though the security comes from the fact that you can't make the network accept the partition you created unless you own 50% of the market cap from their perspective, not the perspective of your local node.

If you tried to spend from a double spend you forced your local node in to, everyone else sees it as invalid.

How does this convince the network to evict the original block?. From their perspective your historical stake is currently worth 0.