Here’s something else that needs to be repeated again and again until people finally stop making this error: micro-group consensus is not superior to a blockchain. They are two completely things used for two completely different purposes.
For instance, I would gladly walk around with a bitcoin wallet on my phone because if I got mugged, the blockchain would allow me to point to exactly what bitcoins got stolen, when they got stolen, and find the son of a bitch who mugged me and make me whole. Safecoin, on the other hand, is built from the ground up to prevent me from doing this (natively), so I would never walk around with a safecoin wallet whose coins weren’t on a blockchain. Yes, I am aware that I’m effectively already doing the equivalent of this with cash, but we want to progress technology forward, not sideways.
I’m not quite sure I understand. Even if you lost your maidsafe device, wouldn’t those coins be associated with your account? You’ve effectively only lost a farming device, but your docs and money presumably are still on the network. So why wouldn’t you want to be carrying a maidsafe-wallet-carrying device?
Now when I run Bitcoin Core, all blocks are validated by it, and “correct” means what consensus approves.
Save for the hash collision attack (which is equally likely or unlikely against SAFE or other networks), by participating in the network I always get first-hand info about blocks and hashes.
By running an SPV client, then I could choose to trust some exchange’s IPFS account and get those blocks instead, but for that the s/w would have to be built to work with it that way.
My understanding is that as an inherent quality of not having a transaction history pass the recording of the previous owner of a safecoin giving said safecoin to the current owner, and in general being fully anonymous, safecoins are more susceptible to disappearing into the tumbling ether never to be seen again by the victim of a mugging (or a hacking, I’d imagine) than a blockchain based currency, where given enough (computer) resources, (private) protection agencies can track down who took what and go after the scumbag.
The client has to use an API and be able to send transactions and do other things. It’s not enough to just have the blocks. If lookup is local and the rest still has to interact with other bitcoin API servers, it’s pointless.
Hashes are known to be secure still. Latest speculation is that elliptic curves are insecure as well as possibly all current asymmetric encryption. The NSA has been asking NIST to develop quantum resistant algorithms and are recommending against EC crypto (all of suite B is being phased out).
I think janitor just likes to argue for the sake of arguement…
If I ask for the file with has x the file I get will either be the file I requested or something absolutely gibberish even if a hash collision was possible. There is infinately little risk…
I don’t think that’s the case. I was just trying to point out two things:
IPFS as-is would only offer a bunch of (blockchain) files.
Bitcoin client can’t use plain files (how does it even know what files to read?). I needs to be able to query the network using Bitcoin API.
So if one built a plugin for IPFS, it could “translate” Bitcoin API calls to IPFS, but it would have to have some place to talk to the Bitcoin network. It’d be like a bitcoin SPV wallet that talks to IPFS to query the blockchain, and talks to some other servers (probably Web API) to send transactions and do other operations that require connection to the bitcoin network.
In that way you wouldn’t add much functionality. Instead of having your SPV client send all queries to a bunch of online API servers, it’d just split them between IPFS and the Web API. It would work, but you’d have 2 points of failure instead of 1.