stuhood

> physical security of storage media, information security of computations involving bitcoins

Only funds that you have daily access to need be vulnerable to the latter point, as physical security (air-gapping) is sufficient when you do not need to -send- funds.

> And it is much easier to accidentally lose bitcoins than gold, pirate tales notwithstanding.

Strongly disagree. Can you keep N redundant copies of your gold? Combined with secret splitting, you could require that at least K of N secure locations be accessed.

The first solution that didn't involve disk or network IO was the fast one?

Two points that are specified but somewhat hidden in the article: 1) the 400% number is between Cassandra 0.6 and Cassandra 1.0, 2) the test is CPU bound because the dataset fits very easily in memory.

A lot of awesome work has gone into Cassandra 1.0: many thanks to the Datastax team.

I'd say this is completely and utterly overshadowed by Google's hangouts API allowing you to embed content in a hangout... their first example was shared Youtube video watching.

The graph is from this wiki page, which explains the axes slightly better: https://en.bitcoin.it/wiki/Bitcoin_Days_Destroyed#Graph_of_P... : the x-axis is time measured in blocks (created on average once every 10 minutes).

The percentage is (bitcoin_days_ever_destroyed / bitcoin_days_ever_created). Today there will be ~7.2 million bitcoin days created, because that is how many BTC are in circulation.

Yes, it is: assuming you use client side encryption, an online storage company never needs to know your secrets. It's the difference between a trusted and untrusted third party.

Hardware. http://www.memorydealers.com/

Not particularly... an attacker with a rack of GPU filled machines will only find a valid block every 10 days or so, and blocks are valid for around 10 minutes on average: this is a relatively narrow window for double spending, and not an opportunity to waste on a small transaction.

There are other attacks that rely on the receiver being fenced off from the wider network, but those are even harder to coordinate.

This is actually a special case of a general concept: specifying how much you trust particular addresses. Instawallet has just coined 'green address' as a nickname for an address that you will accept payments from instantly (0 confirmation), but what do you call an address for which you would prefer to see 1 or 2 confirmations (~10 or 20 minutes, respectively)?

If Bitcoin UIs allowed you to specify how much you trusted particular sending addresses (in terms of confirmation numbers), things like green addresses would fall out naturally. Also, providing these trust numbers is a great usecase for a web-of-trust system.

You're missing something, but I'm not sure what... Addresses are always public knowledge, along with all transactions between them. Who owns the address, on the other hand, is usually not advertised: but in this case Instawallet is claiming and endorsing their address to allow for instant payments on your behalf.

I can't tell how this diminishes security, assuming the normal practice of using one-time receiving addresses is still used. EDIT: And assuming you are comfortable having a middleman like Instawallet involved.

One assumption that the post (and I assume the paper as well) makes is that there _was_ a thief. It is entirely possible that one user played both the victim and the thief in this story.

This would cause inflation, because miners would be able to print money by throwing hardware at the problem.

The ideal system/algorithm would exactly match the amount of Bitcoin in circulation to the growth of the economy, which would keep prices stable. Bitcoin pioneered most of what you'd need to create such an algorithm in a new system, but what does "growth of an economy" look like in terms of transactions between anonymous addresses? You'd need some concept of identity to determine the number of unique players, and the value flowing between them.

A system that solves this problem at scale is the economic holy grail.

This is why people say Bitcoin is pseudonymous: the entire transaction history of every Bitcoin is public knowledge.

To achieve actual anonymity, receivers need to use a one-time-address for each sender, and senders need to not leak information about which addresses they own.

https://en.bitcoin.it/wiki/Anonymity

This would already be a problem for you if you have an online bank account.

An insecure computer means an insecure life.

See https://github.com/bitcoin/bitcoin/pull/232

Adding Tor to the equation makes the system fully anonymous, assuming you don't leak other information.

You can buy groceries with Bitcoin: http://bitmunchies.com/

The value of the Bitcoin currency is driven by speculation. The value of the Bitcoin system-for-distributed-transactions is driven by utility.

If you don't trust the value of the Bitcoin currency, that doesn't stop you from using the Bitcoin system as a replacement for Paypal et al. for 1) anonymous transactions, 2) payments to a trusted recipient, and 3) micropayments.

Exchanges will compete to convert Bitcoin into your "trusty" local peso/lira/drachma, although their primary customers will probably be speculators for the near future.

The Bitcoin protocol allows for 8 decimals worth of divisibility, meaning that there are actually 2.1E16 or 21 quadrillion "units" (aka "Satoshi's") available.

Why would Top Gear use a calculated track capacity number (55 miles), given that they could have measured an actual number? I understand that 30 minutes of hard driving can be exhausting, but how exactly could they have calculated an accurate value?

Say what you will about EPA numbers, but at least they involve standardized measurement.

As mentioned in the BBC article though, doing that kind of math does not lead to an accurate result, due to the fact that your body is constantly healing. It's the bursts of radiation that are most damaging.

Links are awesome in a small dataset, but on a larger cluster, the probability that each link walk means both an extra seek and a network roundtrip makes them less attractive.

Local graph databases avoid the extra seeks by keeping extra copies of the destination vertex immediately next to the source vertex on disk, but I don't think Riak is doing this, or that it is actually practical in an eventually consistent system.

Note that the Tesla Roadster can be charged to full in ~3 hours on the 240V outlets found in RV Parks.

Crossing Utah is no problem: http://maps.google.com/maps?q=rv+park+near+Utah

John Kalucki from Twitter's platform team responded in the comments with what sounds like a reasonable alternative: http://hoisie.com/post/a_warning_to_hackers_be_careful_build...

I'm fairly certain they are talking about a CA system, since locks must be acquired for the tuples involved in a transaction (even if only long enough to determine an ordering id for the transaction). In the presence of a partition, it wouldn't be safe to acquire these locks.

Rackspace is hiring distributed systems devs in Austin: https://rackspace.hua.hrsmart.com/ats/js_job_details.php?req...

The first video should be available today from The Changelog, and a better quality copy in the next few days: http://twitter.com/changelogshow/status/10581052288

This is a perfect response: thank you.

Also, the definition of scalability seems fairly clear: how many times can you square your capacity before you need to re-architect?

Rackspace is also hiring in the Austin, TX area: https://rackspace.ats.hrsmart.com/cgi-bin/a/highlightjob.cgi...

That's kindof like trying to quit smoking cold turkey. It's killing you, and you know it, but you still have to make the transition gradually.