I'm busy watching the Red Sox whoop the Brewers.

I'm planning on posting my talk's slides tomorrow. I gave a general report on the visit on Bruce's Bitcoin Show.

FYI: I posted this here on the forums because I see the mailing list as being for nuts-and-bolts "lets talk about exactly how to get XYZ done."

And I see these forums as a better place for brainstorming and pie-in-the-sky maybe-it-will-work-maybe-it-won't discussions.

Also, equations don't look pretty in plain-text emails.

Planet Money is one of my favorite podcasts.

They interviewed me when I was in France, and I hope I didn't say anything too stupid. They seemed "appropriately skeptical."

So I've been thinking a lot about wallet security; Matt's password patch is a good first step, but maybe we can at least build in some infrastructure for a better solution.

We really need a solution where transactions are generated on one device and then verified on a second device, so malware must compromise both devices (e.g. computer and mobile phone, or web wallet and mobile phone) to steal coins.

gmaxwell from IRC thinks it can be done without multiple signatures (just with the standard transaction we have now), and staring at the ECDSA math on this wikipedia page I think he's right.  I believe he was inspired by ByteCoin's observation that you can create a vanity public key generating service that is secure-- the service can generate the public key but not know the private key.

I'm mostly writing this to convince myself it could work and to give ByteCoin and Hal and gmaxwell and anybody else who knows a whole lot more crypto than me a chance to poke holes in it. And then point me to a FIPS standard that has it all figured out already...

So:  generating an ECDSA keypair means choosing a private key d_A, then calculating the public key Q_A = d_AG (where G is a fixed point on the elliptic curve).

The key generation can be split; have device 1 choose d_A1 and device 2 choose d_A2.  Device 1 then sends Q_A1 to Device 2, and it can calculate Q_A1d_A2 = Q_A1*A2.  Or in english, Device 1 finds a public key on the curve.  Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key.

So great, neither Device 1 or 2 needs to ever have both parts of the private key on them to generate the shared public key.

Now lets say Device 1 wants to spend a TxOut that is one of these split keys.  The key bit of the signature generation algorithm (see the Wikipedia page: http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm ) is:
...
4. Calculate s = k^-1(z+rd_A)(mod n)
...
That can be rewritten as:

Calculate s = k^-1(z+rd_A1d_A2)(mod n)

And now I'm stuck.  Can that equation be refactored so that Device 1 can compute part of the signature, send its partial result to Device 2, and have Device 2 complete the signature (without Device 2 being able to figure out 1's part of the private key?)?

Bitcoin's technology is unstoppable, like p2p filesharing has proven to be unstoppable. But "the Bitcoin Project" could fail in a bunch of different ways.

If mainstream people think "Oh, bitcoin is that internet thing used by criminals", that is bad for bitcoin. It might be bad enough to kill the project (note that I said "the project", not "the technology").

If bitcoin really does turn into an internet thing only used by criminals then I'll personally consider it a failed experiment and will find something else to do.


PS: the cbsnews interview was with Jeff, not me, and my last name is "Andresen"

+1

If you can, please help test, it really helps. Patch for wallet encryption is at: https://github.com/bitcoin/bitcoin/pull/232
As bitlotto says, us a wallet with very few coins in it and/or run with the -testnet flag to use test network coins.

If your device (computer, mobile phone) is infected and your bitcoin wallet keys are stored on that device (encrypted or not), then the bad guys will get your coins sooner or later.

Sooner if the wallet is not encrypted. Later if it is encrypted.

Come up with all the fancy "measure timing and enter your fingerprints and choose an 80-character-long password and store your private keys inside the Trusted Platform Module Chip" pseudo-security measures you like; if your device is infected they will not work.

The bad guys will simply hack the software so that you THINK you're securely sending 1 bitcoin to your cousin (because that's what it says on the screen), but instead you're REALLY authorizing sending your entire bitcoin balance to the bad guys.

As long as the questions are core-bitcoin-related and not specific to your alternative client.

Good alternative client question:  "I'm writing an alternative client that doesn't store private keys at all (they are generated from the user's password). But I'll need a bitcoin protocol message that does XYZ to make it work; are other clients willing to support that new message?"

Bad alternative client question: "I'm coding my alternative client in Forth; what's the best GUI toolkit to use?"

Yep. Every transaction you make potentially leaks a little information about other transactions to/from your bitcoin wallet.

That's why I always say "bitcoin anonymity is complicated" and "bitcoin transactions are more private than credit card or bank transactions, but less private than cash transactions" or "staying completely anonymous while using bitcoins is hard."

And that's why you won't find (or, at least, shouldn't find) any claims that bitcoin is anonymous on the bitcoin.org home page or in the bitcoin source code.

What can you do? Use separate wallets. Make your donation address an instawallet or mybitcoin address that you don't use for anything else.

I exchanged email with Jacob, and he's predicting bugs because some very good "white-hat" people are looking hard at the code, trying to find bugs or vulnerabilities.

That's all.  And that's good news; the more people who try to find problems with the code (and who will report any problems responsibly so they can get fixed before they're exploited), the better.

I'm reposting from the ClearCoin news blog:
   http://clearcoin.blogspot.com/2011/06/charity-escrow-changes.html

I've been contacted by a charity who is not happy that they were listed as a donation option for ClearCoin charity escrows.

I made the mistake of assuming that charities would appreciate the extra bitcoins; it never occurred to me that ClearCoin customers might contact a charity and ask THEM for their (supposedly-donated) coins back. Charities can't be expected to resolve ClearCoin disputes.

To fix the problem, I have disabled all charities for new escrow accounts except one: the Bitcoin Faucet. I will be writing to any charities that received ClearCoin donations from already-created escrow transactions to make them aware of the situation and will ask them to forward any ClearCoin-related issues to me.

Busy... very busy...

This would be like a 6-blocks-back block chain lock-in.  Maybe not a bad idea at this point (unlike the early days when legitimate users might throw lots of new hashing power at the network or there might have been network splits because there were so few nodes).

I think there would have to be an override, in case there WAS an hour or two or three network split.

Or maybe some attempt to detect double-spends (e.g. more-than-5-block-split OK if all transactions are valid on both chains).

I still think selling boot-able USB sticks that contain a Linux distro, bitcoin, a bitcoin miner, and "starter" bitcoins would be a great eBay business/product. You're not selling currency, you're selling software and a USB stick.

You'll have to have a good eBay rep, though, because the person who gets it would have to trust that you didn't keep a copy of the wallet.

Does anybody have the full text of the open letter? Mr. Google is failing me when I search for it...

I'll confess: the bitcoin GUI is not a high development priority for me because I think downloading and running software on your computer will soon be almost extinct.

I expect pretty soon most people will be using bitcoin through web applications (like mybitcoin or instawallet) or as apps running on their mobile phones.

I'll also confess that I like the bittorrent model-- create a great technology, a "good enough" interface for it, and encourage the creation of compatible applications that have great user interfaces.

See https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC) for relevant advice.

As Pieter says, bitcoin converts all user-entered values and JSON-RPC values to fixed-point 64-bit integers as soon as it gets them. All calculations except for that conversion are done using 64-bit integers.

Bitcoin does not "use floating point", it parses numbers-containing-a-decimal-point values that come from JSON (the Number type in JSON is double-precision float; let's not restart the "we should pass numbers as strings in JSON" debate, please, there are several long threads from a couple of months ago about that) or from the GUI.

Testnet faucet is up and running if you need testnet coins:
  https://testnet.freebitcoins.appspot.com/

Although I've mostly been using testnet-in-a-box for testing recently:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/