Lets suppose the speculation is true, and the Pirate has in fact been selling large amounts of coin. Ostensibly this is to stop bubbles, but another possibility is he's gradually converting a large amount of his bitcoin holdings into fiat. One he's done that he then has the incentive to crash the bitcoin market as his Bitcoin Savings and Trust obligations are denominated in Bitcoins. For instance, suppose he's a FinCEN insider and known's that repressive anti-bitcoin measures are about to be introduced. After the crash he simply has to buy back the coins at much-reduced rates, and he gets to keep the fiat left over as his profits.

tl;dr - The Pirate has a big incentive to destroy Bitcoin itself.

One trick with EC2 is to take your EBS store for your micro instance, deassociate it, reassociate it as the root partition of a more powerful instance, and use that to get the blockchain verification done in a reasonable amount of time. Then you can move the partition back to the micro-instance, which in my experience is still adequate for the current transaction load.

Equally, do the blockchain verification on your own computer then copy it (the .bitcoin directory) to the EC2 instance.

See, in a strongly typed language, I'd agree with you. But Ruby and Python are dynamically typed, which greatly reduces the advantages of traditional enums because there is no mechanism to type-check them anyway.

Note though, the actual preferred Ruby enum approach is apparently symbols - as notme mentioned, see http://stackoverflow.com/questions/75759/enums-in-ruby - which are pretty much immutable strings with some syntactical sugar. (and potentially namespacing) Still using strings may make sense in some cases, like interfacing to external code. Python meanwhile doesn't even have the concept of a symbol.

Is dynamic typing system the right approach? That's a very complex question... For one thing, remember that typing systems can be a lot more complex than the simple C/C++ model of mostly incompatible types. Look as Haskell's inferred typing for instance.

I can't speak for Ruby or that exact case specifically, but often in modern languages string comparisons are a lot faster than they look. For instance, a typical enum replacement would look like this:


The trick is that if strings are immutable, and short strings are guaranteed to have unique memory locations, the a == "foo" comparison can actually be implemented as a direct pointer comparison rather than a slow string comparison. This is basically just as fast as a traditional enum, and in practice takes up the same amount of space. (integers in structures are usually not packed) Of course, comparing three letters is pretty quick as well, especially in the context of an interpreted language. FWIW if I'm not mistaken Python strings work this way, and it's considered "Pythonic" to use strings to replace enums.

Premature optimization is the root of all evil.

Heck, while it's not (known to be) military developed these days, they still list military uses on their website: https://www.torproject.org/about/torusers.html.en#military

Interesting to see the mention that Tor is used by the US government, but not the mention that they originally developed it in the first place.

If you're charging a 1.5% fee for this anonymous send service, how are you going to withdraw your fees? It strikes me that it'd be very easy for you to create a block of coins tainted by every coin sent through the service, which itself, should it get into wider pools of coins like instawallet, would create tainted blocks of coins that would be quite hard to send through the mixer again... Limited by the 250 depth limit, but still. Similarly anyone can use the mixer a few times to create their own "ultra-tainted" coins, aided by the fact that the mixer will always give you coins that haven't been tainted by the total sum of the taint you already possess. This doesn't even need to be very expensive if you taint a small amount of coins each time, so the 1.5% fee isn't very high, and use them to taint a much lager amount which you then send to something like instawallet.

Given how thoroughly tainted the future could be it also occurs to me that what you will eventually see is miners selling their untainted coins to the mixer, which then leads to pools inserting transactions with unusually high fees, which then leads to pools conspiring to reverse said transactions. Not to mention the question of are mining payouts tainted by the coins which lead to their fees?

Note: for all the bad connotations of the word taint, imagine how much longer and convoluted the above message would be if we had decided to call it coins' provenance.

That 1FLo9g9AZ7Up1tgLv4xyx8xvAKiGGhAi6p address is very strange. It's been receiving huge numbers of small integer-valued BTC transactions from a large number of addresses, with the transactions spaced seconds apart. Some sort of mixing network maybe? It'd have to be one owned by a direct recipient of bitcoinica funds, as shown by transaction http://blockchain.info/tx-index/7915029/95dea21bca1a0b337f9f8cbdfb56c5d25546ea5a9e43d9dd96f9e3e9eac57018 Also, if you look at the dendogram for that transaction, you see that the final amount is being split into large numbers of 100-300BTC payments, which in turn are getting split up in all sorts of ways. Possibly this is because they're being funneled through a wallet service like instawallet; the values after that point are all over the place, like more typical transactions.

Nope, but that's a very common misconception.

IAMAED (I am an electronics designer)

I posted this basic idea awhile back on the -dev list, but Gavin's recent "UltraTransactions" post reminded me about it again...

So as we all known establishing reputation anonymously is very difficult. However, if you could provably, publicly, spend coins at a net deficit to you, with the transactions cryptographically traceable to your identity, you can establish a value for the  identity that will be destroyed if tarnished.

Option 1: From an address you control, spend coins to an unspendable address - 1111111111111111111114oLvT2 is a good choice.

Option 2: Create transactions that spend coins to miners fees. These transactions will have to be numerous and consecutive; if not someone with control of a decent amount of hashing power could simply spend coins in blocks they themselves mined.

In either case the identity, even in the face of pruning, becomes the merkle paths from the transactions to the blockchain, allowing future proof that the transactions happened from an address you control. (of course, using that identity is now a matter of signing statements with the private key of that address)

Option 1 is very simple, and I see no security flaws in it. Option 2, while nice from an encouraging network security point of view, is more problematic. For instance, aside from the consecutive problem, if this idea becomes popular in theory we could even see large mining pools collaborating to to reverse blocks where this has happened. You could keep the fees per transaction low-ish, but then the required number of transactions, and the size of the identity, becomes huge.


Now, you've got an identity, great! Lets suppose you're operating a trusted bank, for, say, zero-conf transactions. Ideally what we want is a fully automated way of distributing proof that the identity has violated trust. For instance, if you want to send money to someone, the bank will sign a "letter of intent", stating what the bank will do. Now if the bank fails to send the money, or refund you, you create a machine readable "violation notice" and publish it. The bank can undo the effect of this notice by proving that it did what the letter of intent said it'd do, for instance, by providing transactions showing that money was transferred as requested. If it can't do that, everyone can choose to do no more business with that bank in the future, destroying the trusted identity.

The trick then is, how do you publish these notices? You need a persistent log of every violation made in a given type of trust domain, while at the same time preventing griefing like publishing lots and lots of spammy notices. Again, requiring a provable expenditure to publish a violation could work. Similarly if every violation really is properly machine readable it might be enough to just have nodes validate them and move on. You're also going to want to prevent finney attacks somehow... although in general, information is much easier to copy than censor.

There is also another issue: going back to the bank example, how do you know if the total deposits exceed the value of the identity? One way would be for the bank to do all transactions through a given address (or a deterministic wallet) and expect people to audit the block chain, although that has the issue that certain types of services, such as anonymity providers that resend pools of coins become more easy to track. For non-bitcoin applications this is even more difficult; essentially you've got the same "what happened?" distributed problem that the blockchain solves in the first place.


In any case as a first step creating a protocol, even for human verification, would be valuable; people can always bitch on bitcointalk if someone screws them over...

This would be a great way to make use of my idea awhile back for establishing trust by provably and publicly throwing coins away, either by transferring it to the null address (all zeros) or by spending it in fees to miners. If Ultra is charging fees for the service, it'd be worth it's while to be honest if acquiring the reputation is sufficiently expensive.

For a straight-up bank role the analysis is easy: the bank's identity is tied to the root of a deterministic wallet, and interested parties can then audit the blockchain to ensure that the bank isn't at any one time holding more bitcoins than the identity is worth. (albeit this is difficult with future transaction volumes and pruning)

With Ultra's only being able to destroy coins, rather than steal them, I'm not really sure how you would value it. I mean, griefers can be quite irrational, although rarely that rich. For micropayments though I can see the idea definitely working.

Also, have you talked to zipconf? I dunno how exactly their service works - is it transaction or address based? - but it'd make for an interesting, high-visibility, high-risk test case. IE: maybe they'd give you a discount on the fees.

Part of profitability is risk. If the market is assuming that Bitcoin mining is highly risky, the apparently profitability can be very high even if the total profitability is zero.

Of course, no-one knows how risky mining actually is.

Well, you know you're absolutely right I think, but I'm actually looking forward to seeing SMS payments get stolen precisely because it'll be solid evidence that carrier security isn't very good. It's like how at work I leave my spare change on my desk, completely visible, precisely so I'll find out if any of the cleaners or my coworkers aren't honest. So far, they have been.

Doesn't seem to be working in Canada. I just get an unspecified "Error Sending SMS Payment"

Doh! Yeah, in general that's not a safe assumption, because in theory miners drop out as profitability drops due to the new hash power, but I'm assuming a sudden attack. In that scenario you actually have to provide an equal amount of hash power to the existing network. So all my already conservative, BFL labs goes bankrupt because they don't sell enough hardware, estimates can be doubled.

As it is, the idea that miners will drop out as profitability drops is probably not all that true either now that mining profitability is mainly a function of capital costs rather than marginal electricity costs.

Sure, but this time, using tor. And, no offence to Gavin and the rest of the Bitcoin devs, but the development being done right is something that a large number of developers could do. If they had to step down for some reason, other people could be found to fill their place.

ASIC mining will make it much, much tougher for an entity to borrow a bunch of computing power to attack bitcoin.

For instance, lets suppose BFL sells just $5 million dollars worth of their "coffee warmers". (a highly conservative number that'd probably leave them bankrupt after they paid for the ASIC development costs) That's about 33 thousand coffee warmers, or 234TH/sec. Suppose the attacker decided to requisition a whole bunch of computers to attack Bitcoin, for instance by asking Amazon or Google "nicely" One 4-way Opteron CPU can do about 115MH/s, so for your 51% attack you'll need about 1 million CPU's. If you're renting from Amazon, that's costing you something like a million dollars an hour, assuming you could even get them to let you rent that much computing power. The capital cost of all that computing power is also in the range of hundreds of millions of dollars, heck, easily a billion dollars with server farm overhead.

Finding a whole bunch of GPU's is actually rather tough, as most GPU farms are for scientific computing and use floating-point optimized GPU's that aren't very good at computing hashes.

A final possibility is borrowing an FPGA farm. We could make the rough assumption that the value of the farm's FPGAs will have the same $/Hash ratio as BFL's currently shipping product. So that's 117TH/sec / 0.8GHash/Single * $600/Single = $87.7 Million dollars worth of FPGAs. Intel might have that kind of FPGA farm available - they're used for chip verification - but again, renting it won't be cheap. Also, it looks like BFL is getting it's FPGAs at pretty cheap prices - a $600 single has $2000 worth of FPGAs in it - so with wholesale discounts we still might need to triple or quadruple that $87 million.

With ASIC mining, the cheapest way to computationally attack Bitcoin is probably by doing a run of your own ASICs, and it's not something you can do quickly. All that effort and money just so you can find out the myriad ways that the devs can stop 51% attacks using techniques possible now that Bitcoin is widely established.


For instance, lets suppose the NSA decides to attack Bitcoin. They could probably round up the hundreds of millions of dollars worth of computing power to make it happen, although it'd be a big hit to their black budget. Chances are within a few hours to days the devs will respond with something like a "coin-age" rule and ask everyone to upgrade. Now blocks get rejected, and nodes blacklisted, if they try to pass blocks into the network that don't meet coin age requirements. Transactions start flowing again, although the price on Mt. Gox has dropped severely, lets say 50%. At the same time the "known-legit" mining pools are also taking steps to protect their investment, by temporarily centralizing a bit, and blocking connections to nodes that aren't on a whitelist; the "most-difficult-block-wins" rule has been temporarily suspended. Note that at this point it's still not possible for anyone to steal coins, and not much more possible to do double spends.

Now, one thing the NSA could do is buy a bunch of coins so their blocks get accepted again. The problem is, now they're basically giving people a way to get out of Bitcoin, and boosting the price on the exchanges, restoring confidence. Exactly what they don't want! If they do nothing, they're still burning at least hundreds of thousands of dollars an hour, while the network figures out ways to mitigate the damage.

Honestly, ordering some assassinations on the guys running major exchanges sounds a lot cheaper...

Feature request: sending to P2SH-style addresses.

I really think you should use a separate extension for this.

I have no need for this feature - it is a niche use case - and I'd much rather be running a verifier with fairly limited privileges than one that in itself represents a security risk.