The way thing are going, it looks as if it's going to take some paranormal activity before trading resumes...

I don't disagree with that. And I don't know anything about Danny Brewster.

I don't think their plans were that outlandish. I think everything that was in their plans was feasible and is still feasible. Except maybe the pegged accounts, but even that could at least have worked for a while. As far as I can tell they never even got round to, you know, implementing their products. Was there ever a demo of their POS solution? I vaguely recall there was, but I'm not sure.

My guess that it didn't start out as a scam, but that they've run out of money, or are about to. Quite possibly they've seen this coming for a while too. I'd love to be wrong about this, and I had great hopes for Neo & Bee.

I doubt it is a scam, because you'd think it would be executed differently if it were.

I had my doubts about that too, but it could work (at least for a while) if it was funded by Bitcoin enthusiasts who are willing to HODL anyway. As an experiment, I think it would be legitimate, and listing on a Bitcoin exchange could be the perfect way to find funding for it.

Boy, this is looking bad. It's too early to be certain Neo & Bee is doomed, but something very bad is going on. The radio silence is the most worrying of all. If you're not even a little worried, you need to snap out of it right now. I see lots of denial, rationalisation and magical thinking here.

Test vectors are good, but they don't protect you against backdoors.

It would be good to involve a well-known traditional accountancy for this. There are all kinds of standards that could be useful, such as SSAE 16. Note that I'm not talking about permits here, but voluntary audits by a trusted third party.

They've filed for a preposterous (because trivial) patent on this. Multisig escrow isn't new, and keeping a timestamped log of evidence isn't either, and there are far better distributed logs than the centralised one proposed by Coinsigner, such as virtual-notary.org and lots of others. I'm in favour of doing something like this, in fact I've proposed it myself, but as a distributed service, possibly a new protocol layered on top of Bitcoin.

I call on everybody to boycot this site. Trivial patents like this are essentially a land grab, or theft of other people's potential productivity. It's disgusting.

Don't delete the data folder (answered earlier in this thread). Especially not your wallet.dat!!! Well, at least not until you're 100% sure you've backed up the latest version properly.

Top of the page still says "News: Bitcoin Core 0.8.6 is now available. Download."

If I uninstall the old version, do I have to backup the blockchain or will the uninstaller leave it on disk? Same question for wallet.dat. Of course, I've already backed up wallet.dat, but it would be nice to know.

I know, but this doesn't even give you privacy. I think the old RipplePay used a centralised server. In this way, you didn't need banks, though you did need a central party for bookkeeping. In the new Ripple, you no longer need a central bookkeeping server, and you still do not need banks, but you need both centralised bookkeeping and a gateway if you want privacy.

I'd like to see an ECDSA signed message saying "Bitcoin, I am your father!".

It would be fun to see what would be needed to get the oldest version to compile and run. You could fill in the blanks with stuff from later versions and then remove what isn't needed to make it work.

Scripts do not have access to amounts and addresses, so currently this can be done. It can be simulated with multisig and a trusted party. Banks could offer this service if they wanted. Experimentation with this would be a good first step before deciding to extend the scripting system.

Maybe you could do something with uppercase lowercase instead? Capitalise every first, fifth etc letter? Or alternate blocks of four uppercase with four lowercase letters.

Maybe add some dashes every four characters to make it easier to keep track of where you are in the txid when you're reading it aloud?

I've been reading some threads on allowing checks of block height in scripts, and I still don't understand what's so dramatically bad about it. It's clear enough that a previously valid transaction can become invalid after a reorganisation, but that is solved in most cases if you wait for enough confirmations. The exception appears to be that after a lengthy segmentation you would get much more collateral damage than usual.

There was some suggestion that it might also allow people to deliberately create reorganisations, but I don't understand how that would work. Also, some developers seem to have changed their minds a bit. So, what's current thinking about a block height opcode and what exactly are the scenarios people are worried about?