http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=p...
829 karma · joined July 20, 2010
http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=p...
EDIT: but of course I'm making the silly mistake of assuming he's an American.
Of course this might devalue the currency as a whole, but the central bank had to institute an exchange rate floor because Francs were becoming too expensive relative to the Euro. So they probably wouldn't even consider a minor devaluation a bad thing.
http://www.forbes.com/sites/andygreenberg/2012/04/03/these-a...
Even so, the current network can probably handle 100,000 messages a day, and the bottleneck there is some side channel timing attack mitigation code that causes the client to sleep while syncing with a peer. If you separate out the message syncing from the decryption process and eliminate the timing attack potential, the network can easily scale to a million messages a day or more.
At that point, the messages will need to be broken into 'streams' so that you can partition the traffic. The protocol supports this, but punts on the implementation details, so there's no easy way to implement multiple streams at this point in time.
But I would hardly describe that as full-on 'fail'. Everyone-shares-everything is a design feature to preserve anonymity. It's more difficult to tell who sent a message, who received it (if anyone), who was able to read it (if anyone), etc.
Reading more on this software, it seems like they try to solve the capacity/bandwidth problem by using a distributed hash table, but now the protocol requires a lot of handshaking with specific machines that has potential to remove some anonymity, and also potentially makes it easier to prevent a user from getting messages. Block enough traffic at the Great Firewall and you might not be able to get messages. [Take the above listed weaknesses with a grain of salt, I haven't done an in-depth look at the protocol.]
But in general it's probably premature to worry too much about scaling, since the bitmessage network can already handle several more orders of magnitude than the current traffic levels:
So even if I setup and host my own SMTP server, and even if I verify the TLS certs on my side, I have no way to verify that I'll get (1) A TLS connection (2) with an authenticated cert all the way to the ultimate destination.
It's beyond my control to ensure that I'm secured when emailing to an arbitrary domain with arbitrary configuration.
http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&l...
Similarly it's not a Ponzi scheme because it doesn't involve the fraudulent transfer of new capital into fictional profits. Nothing remotely like this happens with bitcoin.
If we alter the definition of pyramid scheme so that Bitcoin qualifies, that definition would match every successful startup company.
Let's say all bitcoin becomes is a paypal killer.
Paypal had a total payment volume of $145 billion in 2012. Now you can't just say a fair value for bitcoin's market cap is $145 billion because that doesn't take money velocity into account. Some of that volume could be the same dollars floating around. You don't need $145 billion in cash all at once to cover that activity. But paypal's revenue was $5.6 billion. So the amount bitcoin needs to be worth to handle the same amount of business as paypal is somewhere between those two numbers, and even a low $10 billion prices bitcoins at $1000 each.
Visa Inc had a total payment volume of $6.4 Trillion in 2012. Of course in addition to figuring out the actual money velocity you need to remove the credit component since bitcoin doesn't do that. But some sketchy back-of-the-envelope math can demonstrate that a $100 billion dollar market wouldn't be unheard of, with $10,000 bitcoins.
Of course I'm talking like 10-20 years out for anything like that, not today.
Why do so many TDD people think that people who don't use TDD don't write tests?
http://www.rubygems-openpgp-ca.org/blog/gem-signing-x509-and...
I've been trying to get people to sign with OpenPGP because that can be done first and then you can put an authentication system into place after the fact. You can't do this with X.509, if/when a CA comes into play all gems would need to be resigned and republished.
The thing is, for years no-one has stepped in and actually gone through the pesky little details of implementing all those semantics for rubygems via X.509 even though it's come up repeatedly. But maybe someday some expert will come along and fix things.
If you actually read the rubygems documentation on signing gems, it's pretty much "Okay generate your own self-signed key, then sign it with your self-signed key." That leaves a lot to be desired vs best practices. There isn't even an attempt to describe how you get your self-signed keys to users.
I just think leveraging the existing OpenPGP semantics, ecosystem, and battle-hardened gnupg codebase, is a lot easier than implementing an entire system from scratch on X.509 just because openssl is already installed everywhere and ruby has better bindings and gnupg is not and does not.
I'm just trying to take the approach you usually preach: Don't roll your own crypto code and leave the real work to the pros, and it seems like gpg offers a lower path of resistance.