Unfortunately all attempts at making remote manipulation devices both mechanical and electronic have resulted in things that are far more cumbersome than using your hands directly. The human arm and hand is an amazingly good maniupulator with extremely good feedback so it can grasp something firmly without damaging it.

There is usually a way to clamp the workpeice and keep your fingers out of harms way but it's slower and more cumbersome than just holding it and people have a nasty habit of getting overconfident in the own ability to not slip up.

There are boards that are faster than the Pi and boards that are cheaper but I haven't seen anyone come out with a board that is both faster and cheaper.

Looks like it's still arround.

The networks are a risk but they are a risk that can be mitigated to at least some extent by strong well-managed encryption (and yes this does mean avoiding the easy to use centralised systems where the system operator manages the encryption and going for something more decentralised and that requires more work and understanding but lets you manage the encryption yourself).

But if the end devices are compromised then the keys can be stolen or the data can simply be copied before it is encyrpted.

btrfs brings really useful features like data integrity protection through the combination of checksums with either multiple copies or error correction codes*, snapshotting** and the ability to create a logical copy of a file without creating a physical copy. These are features that most other linux fileystems don't have. You can find out more at https://btrfs.wiki.kernel.org/...

Unfortunately it's hard to take a filesystem, particularly a complex one like btrfs from "seems to work fine under our lab tests" to "proven stable in production" . devs need data from real world problems to improve the filesystem but to get data from real world problems requires people to run it on real world systems but people are reluctant to put an experimental filesystem on their production servers.

This is good news towards the goal of turning btrfs into a "proven stable in production" soloution.

* The trouble with conventional raid is it keeps multiple effective copies but it has no idea which of those copies is correct. So it relies on the underlying drives to return either correct data or an error code. Experiance has shown that the checksum systems built into drives are not strong enough to completely prevent bad data from being returned.
** Yes you can do snapshotting with a layer like lvm between the filesystem and the storage but there are distinct advantages to doing it as part of the filesystem.

AIUI many shorting contracts require you to cover your short once your losses reach a certain level. You can still lose even if you turn out to be ultimately right.

While governments can sometimes go after individual users doing so on any significant scale carries a very high political cost. It's much easier to paint a handful of people who form a competing central authority as "criminals" and shut them down than it is to go after everyone participating in making a decentralised system work.

Which is not to say it's impossible for governments to crush bitcoin just much harder for them to do it than to crush comparable centralised schemes.

What is novel about bitcoin is it does what it does without requiring a central authoritiy. People who have tried to make "alternative money" systems with a central authority have found themselves either crushed or subsumed into the regulated system where the government can tell you who you may or may not give money to or order transactions reversed long after the fact.

bitcoin is to e-gold as gnutella is to napster.

According to blockchain.info the top three mining pools between them control over 54% of the total mining power add number four and you get up to 67%.

So if they were to team up into a cartel they could arbiterally prevent blocks they didn't like from staying in the blockchain. The interesting question is if the leaders of the guilds decided to do this to enforce higher transaction fees would their members go along with it or would they break ranks in sufficient numbers to negate the affect?

So you have a scenario where miners are giving up and the toal network hashrate (and hence the difficulty) is falling. This means two things.

1: The ammount of hashing power needed for a 51% attack goes down
2: The ammount of mining hardware available on the likes of ebay at knockdown prices goes up.

Combine the two and it potentially becomes a lot more economical to amass enough mining power to do a 51% attack.

The motives of the attacker could be varied. It could be a government who wants to destroy bitcoin. It could also be done by someone (or a cartel) for "buisness" reasons (if you control 51% of the hashing power you can enforce a minimum transaction fee by refusing to accept any blocks that contain transactions with lower fees).

Of course the problem with placebos is that they essentially require lying to the patient. If you are honest and actually tell the patient "it's just a sugar pill" then it's not going to have any affect.

Which is why you get things like homeopathy dressing up placebos in some BS that sounds plausible to the uneducated.

You forgot those trying to do a "51% attack" for the purposes of killing or controlling bitcoin.

If mining rewards drop signinficantly and consequently lots of miners quit then said attacks will get easier both because they will require less hashing power and because there is likely to be a lot of uses mining hardware turning up on ebay at knockdown prices.

Sure such a system works well for slow moving carts but i'm not sure it would work so well for a car. For best milage you really want to avoid actively braking (even regenerative) as much as possible. Your proposal would make it very difficult to express to the car "I want to coast not actively putting power in but not actively taking it out either".

I'd also be worried about whether a speed pedal would be fine enough control to correctly select the desired speed over the wide range a car operates over.

And that whole range can be blocked in one go.

What matters for avoiding blocks is not merely having lots of addresses, it's having lots of addresses spread out through the address space so that people can't effectively block you without either causing massive collateral damage or painstakingly hunting down your addresses.

Another approach is to create fictional IDs with generic email addresses (gmail or similar), create keys for the fictional IDs and get them signed. Then use the keys associated with fictional IDs to sign the keys you plan to use for impersonation.

This is more work than just having shady people use their real IDs to sign the impersonation keys but reduces the risk of your accomplices being found out.