I moved this from the Newbie forum-- looks like a great project!

I'd like to see somebody work on a "shun ill-behaved peers" patch.

So if one of your peers sends you lots of garbage (blocks/transactions/addresses/whatever) you just disconnect from it and refuse to accept connections from it for a while.

The trick is thinking really hard about what is really 'garbage' and what might be honest, it-happens-every-so-often weird behavior due to block chain splits or other network events.

The goal would be to prevent a wide range of denial-of-service attacks.

A long-term fix for transaction fees (as opposed to the ad-hoc "we'll just try to guess what the 'right' fees are") is high on my priority list for bitcoin. There are only two very-high-priority things on my bitcoin wish list:  fix scaling issues and make sure we have any infrastructure in place to support ultra-high-security wallets. Fixing transaction fees is a scaling issue.

"Pick a fee and hope my transaction makes it into a block" is NOT the right answer. And we've already seen what happens when there is a mismatch between miner transaction fee policies and client transaction fees (remember the big backlog of low-priority transactions we had a couple of months ago?).

Facebook credits are designed so that dollars go in, but only flow back out to the companies with facebook games.

And Facebook tries hard to ensure that the companies cashing out the credits are real companies, and not people just trying to move money through their system. There are no open exchanges, by design.

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.