So, here's my current version of the Python utility:

https://www.dropbox.com/sh/ysbyb3v5zec43pe/Emrn5v2slX/files.zip

The one thing I can't figure out is what it exactly means to take the "SHA256(resulting bitcoin address)". Do I SHA256 the address itself? A bytestring version of it? A bytestring version padded with '\x00'? None of those seems to work. But barring that my utility is decoding Casascius's example correctly.

Another question/concern: why limit it to (8,8)? There is no need whatsoever to do this. All you have to do is keep applying progressively smaller caps to the high-position intermediate k-values and as long as the cap keeps decreasing fast enough there's no problem - I implemented it in my code already. We can limit it to (16,16) and have 8 bytes of error correction in the encoding instead of 9 and everything will work just fine.

Not really - you forget the impact of lost coins. Assuming a 0.5%/year loss rate, a permanent 10.5 million BTC per four years would amount to an ultimate fuzzy cap of 525 million coins, while Bitcoin's current strategy would peak the currency at 18.9 million in 2028 and then have it slowly come down and be all the way down to 13.6 million at the end of the century.

Define "world". As a proponent of space exploration, I see things a bit differently.

Although making Bitcoin work over a one hour latency is a rather interesting task...

Sure, all you need to do for that is to set up a (3,6) system where one of the six outputs is itself stored in the form of a (3,8) system.

All you technically have to do is to use your password as a seed for the random number generator.

The above may or may not make actual RSA security professionals scream, but that's the simplest way to do it.

Same

Although I will likely come either way.

You could use a key family scheme to generate as many addresses as you want from a single seed - something like this:

http://crypto.stackexchange.com/questions/1534/families-of-public-private-keys-in-elliptic-curve-cryptography

It also has the advantage that you could store some derivative privkeys in a more accessible place (eg. desktop client, blockchain.info) and use them normally without risking your root key being compromised.

Nice!

I'll come up with a cross-platform python utility for this when I have time.

One question - let's say that I accept a call for 10 BTC at $10.50 with an expiration time of one day. Two hours later, the price goes up to $11, and I want to cash out. How do I do that? Is my only choice to accept a 10 BTC put option as well so that the two cancel each other out? Can I sell my option for a price? If so, if the price drops to $9.90 instead, and I want to cash out because I'm scared that it will go down further, can I cut my losses by selling it for a negative price?

Providing employment is always a good option - ask a question on Rugatu and point people to it.

That's not really a good argument -  there's no reason why the absolute volatility of the price should be constant, rather than proportional to the price itself. What is a good argument is that higher price implies more people which implies a more diffuse community and therefore more stability due to the random walk effect.

It's only arcane if there is no simple and integrated GUI (or even command line tool) for it.

Summary:

1. Bitcoins are volatile. Look at the chart.
2. Bitcoins are bad.
3. Bitcoiners are hypocrites for promoting Bitcoin when things are going well but keeping silent when it was going down from $30 to $2.

There were no arguments presented beyond this.

There. I just saved everyone ten minutes of wasted time.

https://en.bitcoin.it/wiki/User:Vbuterin/K_of_N_redundant_offline_private_key_proposal

Fairly technical (hard to avoid that when describing these types of protocols), but here you go.

Rises in price aren't a bad thing. They have some harmful effects in the case of merchants who set fixed BTC prices, but their good massively outweighs the bad - they make using Bitcoin as a currency exchange intermediary essentially free or even negative cost, they encourage general interest in Bitcoin, and they make Bitcoin holders, the largest of whom are also Bitcoin businessmen, richer. But we're not worried about the rise. We're worried about the fall after the rise. At this point I doubt Bitcoin will fall to less than $7, but if Bitcoin goes up to $40 and then back down to $7 that would seriously disrupt the Bitcoin economy in many ways - it was a big problem the first time it happened in late 2011.

For the private key splitting, your approach of storing parts combined with a global XOR seems to be redundant against only one failure. But why not expand the concept to an arbitrary (n,k)-redundant encoding? Here's a quick brainstorm of how a scheme might work:

1. Take your private key and find n values (which we'll call v(1) to v(n)) which meet the following conditions:

i. v(k) <= 2 ^ 256 / (k)^(3*n)
ii. hex(SHA256(k)) starts with '00' - this is the checksum
iii. XOR(v(k) for all k 1 to n) = the original private key

The first condition isn't too important, it's just nice to have if you want all of your pieces to stay within 64 bytes.

Now, for the pieces. Piece k will have the following format (encoded into base 58 of course):

Byte 0 = 0x86 (or whatever)
Byte 1 = k
Byte 2 = string length of the resulting base58
Bytes 3-whatever = v(1) + v(2)*2^k + v(3)*3^k + v(4)*4^k + ...

For example, if you want your private key to require three out of five pieces to reconstitute, the final pieces will be (string lengths will depend on exactly what v(1), v(2) and v(3) are):

0x86 1 45 v(1) + v(2)*2 + v(3)*3
0x86 2 45 v(1) + v(2)*4 + v(3)*9
0x86 3 46 v(1) + v(2)*8 + v(3)*27
0x86 4 46 v(1) + v(2)*16 + v(3)*81
0x86 5 46 v(1) + v(2)*32 + v(3)*243

To reconstitute the private key, simply solve the linear system from any three pieces and XOR all the results. You actually don't have to know what n is because you can simply assume that n is the number of pieces that you have, and if you have too many pieces solving the linear system will simply lead you to discover that the n+1st, n+2nd, etc pieces are all equal to zero.

The scheme can easily be adapted to make the private key the EC product of v(1), v(2), etc rather than an XOR, and even the linear systems can be changed to an multiplicative/exponential equivalent if desired, so it's pretty adaptable.

Hello, I'm Vitalik Buterin, the one who wrote the article. The following are my personal opinions, and do not represent an official position of anyone.

I agree with Matthew's posts above. I concede that the information that Zhou Tong made a $40k LR transaction itself is not private since, as Roberto pointed out, Zhou himself earlier admitted this. However, the information that Aurum and MtGox released stretches a bit beyond this. It also includes that:

1. Zhou had not been a customer of Aurum before that transaction
2. The transaction went to Zhou's bank account in Singapore
3. Zhou had an account at MtGox since "sometime in 2011" with the address stevejobs807@gmail.com (the second part of this information may or may not have been previously obtained legitimately, so I'll let it go).
4. Your use of the phrase "closely matches" in your original statement implies that the two numbers (what the thief transferred and what Zhou did) match by more significant digits than just $40k.

Concerns about releasing info relating to money laundering investigations also exist, but are irrelevant at this moment because my accusation was about you violating a privacy agreement, not breaking money laundering laws.

Your defense was followed up with the following:


I would like clarification on this law in the Commonwealth of Dominica that says that privacy agreements are null and void if you admit to being a customer of the organization. I have never heard of such a law anywhere and, as presently described, essentially implies that if a customer says "I have to go withdraw some money from XYZ bank today" on an internet forum XYZ bank somehow gains the right to start disclosing private details about its relationship with the customer. To my intuition, this sounds ridiculous. If I am wrong, I would be glad to be enlightened.

You can always use a third party service to verify incoming transactions for you. AFAIK, this is how Electrum works already.

What are some examples of antisocial acts that are not illegal and do not require an existing relationship? I actually can't think of anything beyond trivial "don't hold the door" type of stuff.

And if Spendbitcoins sees this, changes their policy to make the refund return a constant number of bitcoins, and the same thing happens while prices are falling for a month, then people would be complaining that they thought they were done with their BTC when they paid for the paypal and were not expecting to get $80 worth of BTC back for the $100 they put in.

You can't have it both ways. Looks like Spendbitcoins has chosen their policy and if you don't like it you can always buy a speculator bond on the GLBSE to simulate your desired risk profile until Kronos.io comes out.