I've been struggling recently to keep ClearCoin moving forward while I also try to keep core bitcoin on track, and with all the demands on my time I can't spend the time on ClearCoin to make it a project that I'm really proud of.

So in the next day or two I'll stop allowing the creation of new escrow transactions. Existing transactions will be unaffected, and I'll keep ClearCoin running for at least two months after the last active transaction has expired.

I hope ClearCoin will be back at some point in the future, but I won't bring it back until a lot of behind-the-scenes work is done to make it a robust, scalable business.

RE: cryptocards instead of an online service:

Seems like we aught to be able to come up with a protocol that works over the web or that can talk to http://localhost:SOMEPORT to interact with an attached smart-card device (there'd be helper software running on localhost:SOMEPORT that spoke the protocol and relayed to the smart card).

I wanted to start this discussion to make sure we don't re-invent the wheel, and to think in advance about what changes to core bitcoin (if any) are needed to support this kinds of functionality.

Here's a use case I'd like to work:

I tell Bitcoin running on my computer or cell phone to run transactions through a bitcoin security service-- maybe I give it a https:// URL for the service.

I tell the security service "auto-approve small-value transactions, but give me a call for any transactions above $X (or $XY per day)."

The security service sends me something in the mail that I keep safe, but that I can use to recover use of my bitcoins in case the security service goes out of business or disappears or I decide to stop paying for the service.

I get bitcoin addresses either from my bitcoin client (not trustworthy!) and/or from the security service that require both my computer and the security service to sign to spend.  And I have people send bitcoins (or I self-send my own bitcoins) to those addresses.

Spending coins is done as usual-- I type in an amount and an address.  Behind the scenes, magic happens, and if the transaction is greater than $X I get a phone call -- "Press 1 to confirm payment of $X bitcoins to bitcoin address blah, press 2 to cancel."

If I suddenly get random phone calls, I know my computer has been infected.

I took error's work and further tweaked so it works (and is rebased against) latest git head.

... but I'm not 100% happy with it. I'm not sure it properly handles block chain re-orgs and dependent orphan transactions. Would be nice to write some tests to exercise those edge cases, and figure out what it SHOULD do in those cases.

The risk profile I care about is:

User's computer is completely compromised by a root-kit trojan, but they don't know it.

However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.

I don't want to keep putting band-aids on the transaction fee problem, so I'm against adding Yet Another Button to the client.

If you're impatient and can't stand the thought of paying half-a-millibitcoin for a transaction, then compile your own version of bitcoin. Just don't complain if you end up with a wallet full of 0/unconfirmed transactions that tie up all your funds.

Anybody else already working on tests?

Steve: mind if I pull out just the boost-unit-test bits of your tree?

Zero-knowledge proofs... ummm....

Nice to know it can be done securely. I'll leave it to the professionals to actually do it.

EFF blog post: https://www.eff.org/deeplinks/2011/06/eff-and-bitcoin

RE: refunding donations by proving you own one of the private keys that donated:  interesting idea!  Anybody willing to write code to do that?  Could be a fun project... (find all the transactions that donated to EFF, dig out the public keys, come up with a way to sign/verify a message with private key proving you own a public key, then keep track of which donation transactions have already been refunded)

Cindy Cohn, legal director at the EFF, called me a while ago to figure out what to do with the bitcoin donations they were sent, and what to do with coins that might be sent to their donation address in the future.

Ideally, they'd like to return them, but that can't be done-- bitcoin has no "return to sender" function. Returning to the last-address-the-coins-were-sent-to doesn't work because people use shared online wallets and can, and do, send their coins to new wallets and delete old wallets.

The EFF is firm in their decision NOT to cash them in (they'll be coming out with a blog post explaining their reasons very soon), and after talking over several possibilities the idea they liked best was to redistribute the coins via the Bitcoin Faucet (and have any donations that trickle in get passed back out via the Faucet).  The reasoning is that anybody who donated bitcoins to the EFF would also support the mission of the Faucet-- to promote bitcoin by giving people new to the currency a little bit to start.

Other options for what to do with the EFF donations (like setting up a non-profit entity to take the donations and... do something with them...) were rejected as too complicated and/or costly.

I'll need to do a little bit of thinking about how to handle the EFF coins safely (just dumping them all into the Faucet's wallet is not a good idea; I would hate for them to get lost if somebody managed to hack the Faucet's web-facing code). Whatever I do, I will make sure the process of moving the coins from the EFF's donation address to the Faucet is absolutely transparent.

I just uploaded pdf and KeyNote versions of the talk I gave at the CIA last Tuesday:
 https://s3.amazonaws.com/gavinandresen-bitcoin/GavinAndresenCIATalk.pdf
 https://s3.amazonaws.com/gavinandresen-bitcoin/GavinAndresen_Bitcoin.key

I took questions in the middle, before I dove into the technical details. I was asked about whether or not I thought price instability would be a problem ("yes, I'll talk about that later") and how/why I got involved.

Later, at the panel discussion, I was asked a question that showed I need to do a better job of distinguishing bitcoin addresses and IP addresses. And I was asked if there were moral issues, since bitcoin can be used by criminals ("I'm working on bitcoin because I think the potential benefits to the world are much, much greater than the costs.")

The other speakers were from PayPal, Facebook Payments, M-Pesa, Heartland Payment Systems, and the Federal Reserve, so it was worth going just for the connections. Bitcoin is definitely the new kid on the block, and I presented it as such; not "bitcoin will take over the world" but "bitcoin is a very interesting experiment that could be world-changing if it works out."

And now... there is plenty of work to be done, so I'm going to stop reminiscing about the good old days last week....

RE: pulling the wallet private key encryption ASAP:  Agreed 100%

I wanted to start discussing split keys now because if we need a new standard transaction type then it is best to do that in stages-- let clients relay, and miners include in blocks, the new transaction type.  Then once most of the network will accept the new transactions, people can actually start USING them.

RE: making it harder to brute-force:

I have a couple of thoughts.  First, if users choose passwords like 'abc123' or 'password' or any of the other top-1,000 passwords it doesn't matter if we're scrypt'ing; they're toast. I'd rather see work on either giving users feedback on how strong or weak their password is rather than adding a tiny-little-bit-more security by scrypting.

That said, changing the 'ekey' data so that ONLY the 256-bit private key is encrypted should increase security with very little extra code. Consider what you'd have to do to brute-force:

1000 x SHA256(password_text)

Now you have a 256-bit number.  Is it the right private key?  To check:
ECC multiply to get candidate public key
RIPEMD160(SHA256(candidate public key)), and check to see if it matches public key.

Anybody know how easy it is to GPU parallelize ECC multiplies?  A quick google search gives me the impression that is an area of active research.


RE: pre-computing wallet keys:  ??  wallet private keys are 256-bit random numbers.  Am I misunderstanding you gmaxwell?

I agree; I think allowing commas in numbers is a bitcoin GUI mis-feature.

Because sending to a multiple-signature-required address requires a new standard transaction type, a new type of bitcoin address, and a protocol for Device 1 <-> Device 2 communication. More code means more possibility of bugs, so I was hoping there is a simpler solution.

And as I said in the original post, I wanted to start discussion:If the answer is "multiple signatures" then so be it.

Yes, don't trust me, please.  I am human and will make mistakes.

The CSRF vulnerability on ClearCoin is fixed. I will be contacting any ClearCoin customers who have changed their refund addresses to make sure that they were not the victim of a CSRF attack.

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?)?