sooo....i thought google helped China restrict the internet? they ended up not wanting to go along with all the chinese government's requests?
Yes, they did help out the Chinese gov't initially, then they changed their mind as the requests became more and more invasive. Actually, they've changed their minds after they were attacked: http://googleblog.blogspot.fr/2010/01/new-approach-to-china.html |
|
|
|
I'm not actually expert on biometrics but I've done some research on it for work and producer of scanner told me so. Low cost scanner integrated in laptop works that way, so some bank door opener. They have a small database of path and check on it it there is corrispondence.
Wait, but if you need a database of paths, it means the scan alone is not enough to produce the exact same path that was produced before for that individual. You're back to "comparing images". Unless you mean they use a database of path hashes, in which case the scan would have to produce the exact same path before hashing. The scan would be just like a password, and could then be used as an encryption key, provided there's enough entropy in fingerprints - in case there isn't, it could be added to an actual password. |
|
|
|
You're true for a hash of the full image, but fingerprint scanner actually save only a "path" of the minutiaes of the fingerprints. And using that work in a reliable way.
You mean that, for a given individual, you can always obtain the same unique "path"? BTW to avoid physical coericion there is a way, even not too difficult to implement: some times ago I've a phone with an encrypted area in which store password and pins. If you input the good password you decrypt the area, if you put a wrong one you obtain an error, but if you put a "special" one you go into a fake area with other data. Maybe is possible, for extra-paranoid implement a similar approach: one pin for real wallet, another one for another with only few BTC in it.
But again we are talking of extra-paranoid people here. IMHO slush design is more than adeguate.
That's plausible deniability, or more specifically, deniable encryption. Truecrypt does it. I'd expect future dedicated device wallets to implement this, but as you note it's not a priority, at least not while most burglars remain ignorant about bitcoin.  |
|
|
|
Only better way is to replace the password with the hash of a biometric scan (fingerprints maybe) but in this way cost are higher and not all devices can support it.
Biometric scans, AFAIK, are like images. Different scans of the same individual will produce different data, which would produce different hashes. You can compare different images to see if they belong to the same person, but if you use one of these images as an encryption key, there's no guarantee you'll ever be able to unencrypt your data. Of course that biometric scans could be used as an authentication method by a sophisticated device, but if the device is "physically hacked" and the biometric check is bypassed, you'll need something else to protect the data. And, honestly, if you're afraid of physical thefts, shouldn't you also be afraid of physical coercion? What good is a biometric scan if the thief can simply force you to put your finger/eye/whatever? As slush said before, we are not at the point where this is a reasonable threat for most of us. Hackers are a serious threat though, so we should first focus on how to protect ourselves from them first. |
|
|
|
My favorite comment: "This is fantastic! With a place to spend Bitcoins, we can now begin accepting them from our readers. Thanks, WordPress!"
Indeed! I also liked this one: This is very interesting. I didn’t know of Bitcoin… thank you!
PS: How do we make a quote linking to a different site? |
|
|
|
|
I see no reason to forbid someone from spending an unconfirmed transaction, even if it's not change. Particularly now that bitcoind will soon be able to sum up all transaction fees in an unconfirmed transaction chain. If you are on the tip of such chain, just add a fee to it.
|
|
|
|
Here's a funny remark. Let's say "scarce" really means finite (or that whatever is finite is also scarce).
Something that is abundant can very well be nethertheless finite. After all, as mirkhul pointed it out (and even underlined it): infinitiy does not exist (I don't think that's true but let's imagine it is).
So something can be abundant and yet finit. But if it's finite it is also scarce.
Conclusion: something can be both abundant and scarce.
I'm sorry but to me, there is something wrong here.
Grondilu, the economical meaning of "abundant" is not the same meaning of the colloquial use of the word. A resource is economically abundant when every demand for it can be instantly satisfied - no matter how much demand that is. Everything else is scarce. The sole example of something for which every demand can be fully and instantly satisfied that I know of is breathable air. And as I said above, even that could become scarce is some very specific contexts. |
|
|
|
What about a movie theater screen? Watching it == using it, and multiple people can do it at once.
Well, there is a limited number of seats in the theatre, isn't there? And only one person at a time can seat on a seat. So it's not the movie that is rival (that's why there is such mess about copyrights anyway), it's the seats. What's your point exactly? My point was that the screen is clearly scarce, while it can be used by multiple people. I know space and seats are also scarce, but I was talking about the screen. I don't think "impossible multiple usage" defines scarcity. "Impossible multiple control" perhaps. |
|
|
|
That definition can't be correct. Roads are definitely scarce, but are not "rival", many people can use it at once.
The definition of rival fits into a road, as long as you consider a single use not being for the whole road, but for the actual surface on the road where your car is. You can't stack cars one on top of an other, that's why the surface of the road is a scarce/rival ressource. What about a movie theater screen? Watching it == using it, and multiple people can do it at once. |
|
|
|
Is see water scarce, according to you?
Economically speaking it is scarce. If I want sea water right now, I won't have it. Some work will have to be done so it can be brought to me. Breathable air is normally referred as an economically abundant good (the sole example I know of) since we normally have it in the amount we need to satisfy our demand, anytime we want it. We just consume it by filling our lungs. But even breathable air may become scarce in some particular contexts, say, in a submarine for example. Scarcity, Economic. In economic terminology, "scarcity" refers to the fact that the same resource - regardless of its quantity - cannot be put to more than a single use at a time. Scarcity in an economic sense refers simply to the choice as to what use to put a specific resource, not to the quantity available. I thought this was the definition or rivalBut ok, let's say "scarce" means "rival". That definition can't be correct. Roads are definitely scarce, but are not "rival", many people can use it at once. Perhaps if you replace "single use at a time" by "single sovereign control over it at a time" then you start getting a better definition. Given a particular scarce resource in a particular moment in time, only one entity can be in "sovereign control" over it, meaning that only one entity can be the ultimate decision maker on what concerns such resource. Maybe that's what the text you quoted means by "single use". |
|
|
|
Moi je m'y perds un peu dans les différents types de clients légers.
C'est vrai qu'il y a des variétés. BitcoinJ (et donc, MultiBit et Android Wallet, qui l'utilisent), est un client "SVP", Simple Verification Payment ou qlq chose comme ça. C'est toujours un client p2p, qui se connecte donc à plusieurs instances de bitcoind, mais qui n'estoque que les entêtes des bloques plus les transactions qui concernent le portefeuille du client. Aujourd'hui il télécharge tous les transactions quand même, ce qui commence a être trop lourd pour certains portables Android. Une fois le bloom filter implémenté, le volume des données à télécharger va diminuer drastiquement. Electrum est un programme client-serveur. Le serveur est un nœud lourd dans le réseau p2p. Le client non, mais c'est lui qui gère les clés privés. Le serveur ne peut donc pas voler le client, même s'il est contrôlé par des criminels. Le serveur peut, toutefois, surveiller toute monnaie qui entre et sort du portefeuille de chaque client. Blockchain.info fonctionne à peu près de la même façon, mais avec l'avantage d'avoir une copie chiffrée des clés privées estoquées sur le serveur. Comme ça tu peux accéder ton argent de n'importe où, et même si ton client est perdu/détruit, tu peux récupérer tes bitcoins. Et finalement il y a les clients web pure, comme Instawallet, MtGox, bitcoin-central etc, où ton portefeuille reste au serveur. Des opérations automatiques peuvent donc s'effectuer sur ton compte (comme l'exécution des ordres d'achat et vente des bitcoins, par ex.), mais si le serveur est volé, tes bitcoins partent ensemble. Les eWallets souvent agrègent tous les bitcoins dans un seul gros portefeuille aussi, ce qui permet de mixer tes pièces avec celles des autres. Voilà un petit résumé. |
|
|
|
We're targeting to common users, not mafia.
haha, well.. if one day bitcoin becomes as widely known as gold, you could certainly expect burglars to attempt to force people to give their bitcoins. But yeah, there's quite some time until that happens.  Pardon my ignorance, but why does it need to be initialized on an unsecured machine?
This is chicken and egg problem. If you already have secure machine, why do you need to export already encrypted backup to it? If this computer is not *so* secured, how you can put passphrase over it? Never mind, I hadn't yet read that it will not have a keyboard when I first wrote that. At this date, there have been many of successful hacker attacks (I personally lost 3100 BTC during that one), but not a single known issue of $5 wreck attack against bitcoin wallet owner. Let's do solve real issues and don't try to solve something what's not the real problem.
Definitely. One step at a time. |
|
|
|
I respectfully disagree - unless the content printed is encrypted. We're targeting to average users, for common usage. But security freaks ... IMHO, an impossible to re-flash hardware is much more "security freakishness" than password-protected files... And, why making an impossible to re-flash or read keys hardware if the whole wallet will likely be stored unencrypted on paper in the same physical building than the device? Somebody with physical access to the device will likely have physical access to the paper backup. Finally, if you don't consider encrypting the keys in the device, then you're not considering plausible deniability. Somebody willing to physically steal the device is much more likely to simply physically force the user to give him the money ($5 wrench attack). If you don't have multiple encrypted volumes, and you're not some sort of Rambo capable of counter-attack in meatspace, then you lose. are free to boot live distro from trusted source, write down the seed to text file, encrypt that and do with it whatever they want. Actually if you know what you're doing, you'll make encrypted backup of the seed in less than 10 minutes.
I know. I just think it'd be nice if everybody could easily have the option of having the same level of safety and security as well, including people who don't know what the heck a "live distro" is. However, as I said, it is almost impossible to encrypt the seed while initializing the device on untrusted machine, so encrypting seed during this process would be false promise.
Pardon my ignorance, but why does it need to be initialized on an unsecured machine? PS; Please don't take what I say here as bashing criticism. Even if this device is not "physically safe/secure" at all, it would still be awesome as a protection against hackers, which are the real danger most bitcoin users face today - and will remain the sole sensible danger for years. So, just want to make sure you understand I fully support your initiative either way. I'd just like it more if it had these encryption features, that's all. EDIT: Sorry, I had not seen the previous message: For average user, keeping piece of paper in secret is much easier than to store piece of digital information for long enough time (for years). Don't forget that most of users don't do backups and if so, they do it in wrong way.
Again I respectfully disagree. Most young people at least would likely find it easier to store things on their google accounts than to physically store paper in an organized and safe manner. But anyway, that's now pointless, since... This device won't have a physical keyboard. It is expensive and makes the design much bigger.
If that's the case, then yeah, there's no way to encrypt things on the device. Even small keybords like those in some cellphones are that expensive? I'm really ignorant on this. We considered multi-wallet support like this and it would be possible, but it goes against of our motto - make it now and make it easy. All of these ideas are making the device more complicated even for usage (wallet won't be recognized automatically when plugged into computer). However I might consider this in the future for "advanced" product version.
If it's cheap enough, different people could have their different devices anyway. It's definitely not a showstopper not to be multiuser. |
|
|
|
Oui, il existe des client légers qui consultent la base de données depuis un serveur distant, sans la télécharger. Electrum, Armory. Ou bien l'appli mobile développée par les gars de bitcoin-central: instawallet je crois. Il y en a plein d'autres. Fouine un peu sur le forum et tu trouveras..
Et il y a aussi un moyen terme, MultiBit, qui est à la fois p2p (ne dépend pas d'un serveur), et légère (n'estoque pas toute la chaîne de bloques dans une BD). À propos, je croyais qu'Armory était un client lourd, dépendant de bitciond en faite. Ils l'ont évolué pour le rendre aussi un client légère client-server? |
|
|
|
Why not just type the paper backup into a .txt file, and encrypt that?
Fine enough, as long as the passphrase is typed only in the secure device, which will be the one encrypting it. I shouldn't need another secure device only to backup. Actually, I wouldn't bother if the paper backup is already printed encrypted. This way I can safely scan the paper in a unsecured device and back it up. Honestly, asking people to type a passphrase and expecting them to make it complicated enough that it cannot be hacked in any reasonable number of years (at least until well past the time they die) as well as not forget it is just as impractical as a piece of paper. Guess how they are going to remember their complex decades-future-proofed password? And that's even assuming they choose a password strong enough! Anyone who doesn't would have a good chance of their coins being stolen from their "ultra secure" device, and sudden, that device gets a bad rap from it. A passphrase need not to be super complex, it only need to be long. The device could display a strength meter. And, again, this doesn't need to be the sole option, it could still have a printer. Plus, I hardly think people would store the value for decades and never reopen the wallet in between. This is more like your "bank account", the place where you store your salary for instance. You take some money out with the same frequency you go to an ATM. People normally don't put their life savings in "money", it's usually in the form of financial assets. (it's true that if this device supports OT, perhaps one day people could actually have their life savings in it... but still, they would open the wallet once in a while) No, slush is making a very wise choice in only supporting paper/manual backups.
I respectfully disagree - unless the content printed is encrypted. It puts all the blame unquestionably on the user if anything bad happens.
If you want the user to be fully responsible of his security, why even bother with this project? We should help them, and I honestly believe an encrypted backup on the cloud is safer than a piece of paper. People put all kinds of valuables in safes and fire safes in their homes - why would this need be any different?
I only know one person who has a safe at home - and that's because he's a gun owner, legally required to keep his gun in a safe. I actually have never seen a home with a safe. But anyway, that's just me. It's possible to please everyone here. |
|
|
|
First of all, my sincere congratulations for the initiative! * No need for periodic backups, writing down the seed to paper during the device initialization will be enough forever
...
* Possibility to do paper-backup of private keys only once during wallet initialization
I'm really not a big fan of paper backups. There are so many ways paper could be destroyed/lost, and there's no way to encrypt paper and send it safely to remote backup servers distributed all over the globe. Plus, if you consider an attacker gaining physical access to the device, you should consider him getting physical access to the paper backup too. I'd strongly suggest an alternative: allow the user to type a passphrase during initialization. Use this passphrase to encrypt the seed and save only the encrypted copy outside the device via USB. Obviously, instruct the user to use a strong passphrase and to back up the file as much as he can. I realize that I can scan the paper backup, encrypt it and do it myself. But then again, I would need a safe device just for this task... * Impossibility to obtain private keys from the device in a case of theft
* Impossibility to re-flash the device with malicious code
Cool. These are important features. But honestly, a thief willing to physically steal the device will likely not even bother hacking it, he'll just perform a $5 wrench attack (or variant) and get the money. The only potential protection I can think of against $5 wrench attacks is plausible deniability (hidden volumes) - and even that will not protect you if the attacker knows how much money you've got. By the way, "plausible deniability" may also translate to "multiuser". Each wallet user may have a different password (plus a few "fake users" just for the thieves ), which would represent a different hidden volume in the device. This way, a family for example could share the same device, with each family member having its own wallet. I think you should consider implementing this, not only for security reasons, but also for this nice safe multiuser feature. I want one immediately.
Me too!  I am interested in this for OT. What can you tell us about the platform, OS, RAM, etc? I would like to make sure OT is able to run on your device.
That could be quite cool too! Particularly if you could easily run an OT-server in it. If I understand OT correctly, you may have multiple servers and exchange tokens from different servers, can't you? This way each asset issuer could easily have their own safe servers, even those issuers which are not tech savvy people. But something tells me that you cannot have a server in the device while preserving its strong security constraints... a server would likely need to be upgraded frequently, I suppose. Even still, it'd be safer than using a generic computer. |
|
|
|
Not being useful for the artificial creation of credit through inflation is perhaps the most appealing feature of Bitcoin, economically-wise. If you think there's anything good in artificial credit created from inflation, please read: http://mises.org/daily/672Even the ECB "got" that, by the way. |
|
|
|
|
Deepbit is intentionally making empty blocks? What's the reason? To decrease its blocks' propagation time?
If that's the reason, wouldn't pool operators gain if they make sure to be all interconnected? This way they could make sure other pools are the first to receive a new block they generate, decreasing the chances of losing a block. P2Poll miners could also attempt to connect to all pools too.
I'm probably missing something, since if that was enough deepbit would probably go this way instead of ignoring transactions.. can somebody explain me what I'm missing then?
|
|
|
|
... Isn't this good?
Of course, this is awesome. In no way I meant otherwise! LIMITATIONS
...and does not feature a wallet.
This is an excellent limitation to have, and it should stay this way. It should have support for communicating with a wallet module or wallet service, but I think having an integrated wallet is a bad design decision that leads to more bad design with all kinds of horrible implications. I tend to agree with this feeling. Managing a Bitcoin wallet and managing the Bitcoin p2p protocol are two different tasks, there's no need for them to be strongly coupled. |
|
|
|
By the way, OP, why not reuse BitcoinJ code if it fits?
Because it does not. Ok then. I thought that you had done it on purpose, as if sharing code was something bad. caveden, there have been several other full reimplementations. BitcoinJS is one, I think UfaSoft made one, and actually I just finished merging code from Matt that makes bitcoinj a fully verifying ultra-prune style implementation as well (of course, it can still run in SPV mode too).
I'm aware about the efforts to make BitcoinJ a full node, what I find quite good. I don't know about "UfaSoft", and didn't know BitcoinJS was a full node implementation either, I thought it depended on a bitcoind running on the server. Nice to know all this. I'm glad to see Bitcoin evolving so fast. |
|
|
|
|
Show Posts
