Uh-huh...  storing a lot of bitcoins on a usually-network-connected device would make me very nervous.  I think we're going to see a LOT of smartphone exploits over the next 5 years (maybe I'll be pleasantly surprised and it will turn out the smartphone OS folks have done a great job making them secure).

But security is not a boolean, and we clearly need to do what we can to help people keep their bitcoin wallets secure.

What happens if:

-- you dump a private key from bitcoin client 'A'
-- shutdown A
-- import it into bitcoin client 'B'
-- spend it from B
 ... wait for a confirmation or three...
-- restart A

Does A notice that the coin's been spent?  I think there's a bug that it does not, and I think that bug needs to be fixed before we make it easy to export/import private keys.  So, please bang on sipa's patch and see if anything else breaks!

I've been thinking a lot and trying to educate myself on best practices for securing the bitcoin wallet.

Part of the solution could be a smart card that supports ECDSA; the PKCS #11 standard supports elliptic key crypto, so it is feasible to have a hardware token that stores your private keys and never lets them out of the token.

If the token includes some type of biometric identification (e.g. built-in fingerprint reader or mechanism for entering a password) then there is no way for the trojan to spoof new transactions.

But [mike] is right-- if your computer is infected by a trojan the trojan can just rewrite the bitcoin address and amount before the software asks the hardware token to sign the payment transaction.  The only way to prevent that is if the hardware token can somehow display the transaction details independent of the infected computer.  That's one very sophisticated hardware token...

Hopefully Hal and bitcoinex will now tell us how all this was solved years ago and how an iPhone app synchronized with a dumb-ish smart card can use smart crypto to make it all work....

I'm looking for feedback and suggestions for a new ClearCoin feature:  refund-to-charity

Here's how it works:

When Alice creates an escrow account at ClearCoin she says that, if the coins in the account are not released, they'll be donated to charity.

She then funds the account, and shows Bob (the person she's trading with) that the coins are sitting in escrow.

Alice knows that if Bob doesn't complete the trade he won't get the coins.
Bob knows that if Alice doesn't release the coins she won't get them either.

So neither Alice nor Bob has a strong incentive to cheat.  They each have a weak incentive if they'd rather the charity get the coins (and they're not worried about potential harm to their reputation).

I've got an initial implementation up and running, with the list of charities from the Bitcoin wiki Trade page.
I'm thinking of a few enhancements, and would love feedback on which ones you think are critical and which would be just nice-to-have:

1. Give Bob (the person receiving the coins) a way to setup the escrow and send a link to Alice (who controls the account).
2. Let Bob and Alice agree (in advance) to refund the bitcoins to an arbitrary address instead of a fixed list of charities.
3. If the coins are refunded to charity, show Alice and Bob the transaction ID so it is easier for them to make sure ClearCoin isn't taking the coins.

General feedback, criticism, etc. is also very welcome!

RE: trading private keys with somebody:  theoretically you could, but that's not typical bitcoin usage and the current bitcoin client makes it hard to do.

Practically speaking, if Bitcoin did have a feature to state:
 "On THIS date somebody using the identifier <foo@bar.com> controlled THIS public/private keypair"

... that would just inspire the smarter bad guys to send stolen coins to new private keys before spending them.

I can imagine a black market forming where dumber bad guys sell stolen wallet.dat files (at a discount) to smarter bad guys (or just plain greedy people who don't bother to ask where the wallet came from), who mix up the coins in them and then sell them.

Yes, not implemented yet.  Do you want to remove them just so the listaccounts output isn't messy, or is the lack of a deleteaccount API call preventing you from doing something you need to do?

From another thread:

No need to embed the identification in the transactions, I don't think.  You just need to associate your public keys with 'you' at some place where anybody can see that association and prove that you originally owned the private keys associated with those public keys.

Let's see, I think something like this would work:

For every private key in your wallet:
  Grab the corresponding public key
  Sign it with the private key
  Compute SHA256(public key, signature, "your name and email address")

Then upload all of those SHA256 hashes to some secure central database somewhere, which stores it along with the time it was uploaded.

Now if somebody copies your wallet and spends your coins, you can prove that you had the public/private keys in the past by showing everybody the (public key, signature, "your name and email address") that hashes to the value in the central database.

The crook can upload their own SHA256, of course-- this relies on you uploading before the crook.

Entering a password every time you want to send coins (or pulling out your... dongle... err, that didn't come out right, uhh, fetching your one-time-password-generating-device) might be annoying enough that withdrawing 50 or 100 bitcoins that you can spend with minimal hassle would be a nice feature.

Converting from a double-precision float from the JSON library to an int64 bitcoin is:
... which will always do the right thing (COIN is 100000000).

int64 to JSON string there are no code changes.

GUI string to int64 is a direct conversion, no intermediate double precision.

And int64 to GUI string is:
... which also always does the right thing (printf of a floating point number rounds, and there is enough precision in a double the rounding will always be correct).

0.1 bitcoins will always become exactly 10000000 base units internally, and 10000000 base units will always be shown as exactly 0.10 (in the GUI) or 0.10000000 (in JSON).

I just did some testing (on Linux) and the GUI seems to handle full-precision values quite nicely.

https://github.com/bitcoin/bitcoin/pull/79

This modifies FormatMoney to display full-precision values (with trailing zeroes trimmed correctly-- e.g. 0 is 0.00 but 0.00010000 displays as 0.0001).

And ParseMoney allows entry of full-precision values.

And JSON's AmountFromValue doesn't round to two places, so you can send/move full-precision values.

I haven't tested this with the GUI bitcoin yet, it will probably require UI layout tweaks.

Bitcoin is confusing at first glance because so many problems are solved using just a few ideas.  If you think about it long enough, it is quite elegant.

The busy-work of finding a block hash that is "small enough" solves a couple of problems:

First, by making it hard to create coins so they are artificially scarce.  That is really important; if it was easy to create gazillions of bitcoins we'd all have gazillions of bitcoins that were worth nothing.

Second, it solves the double-spending problem-- the computer that solves the busy-work problem first gets to decide which transactions are "THE" transactions, and which ones are invalid (because you're trying to spend coins you've already spent).

Our legal systems haven't caught up with the Internet.  What's the proper jurisdiction for somebody in Iceland using a bitcoin exchanger in the US who got ripped of by somebody living in (lets see, which country do I want to offend today....)  a seasteading community?

"people" is me-- when I tweak the Faucet's code I erase my IP address from its database and then have it send coins to itself as a sanity test.

And Hal's right, Bitcoin chooses transactions to spend, not specific outputs (which only matters for sends-to-self, where you own both outputs of a transaction).

Hmmm...

Thinking a little more, Mr. Lucky will have some coding to do.  Blocks are indexed based on their hash, so when he generates that second all-zero hash he's going to have trouble with the current implementation.  Actually, he'll have trouble before then, because if the target is low enough there won't be enough unique hashes...

(and before somebody asks: YES, there is a very small chance that two blocks will be found with the same hash.  And NO, that is NOT a problem that needs to be solved, it is so improbable it is not worth worrying about).

Looks like somebody's playing with a tweaked bitcoin-- if you trace back the inputs they're from a previous block that has the same odd pattern.

The standard coin selection algorithm in bitcoin would generate a one input / one output transaction.

Hal and theymos are right-- I misremembered how the coin selection algorithm works.

Updated Mac build is on Sourceforge, as is a PGP-signed README.txt.

I also just changed the links on the front page of the wiki; the links at bitcoin.org will be updated as soon as sirius and I are awake at the same time again 

SHA1-checksums for the binary files are:
7dfbc05b36112f59886a29f044cfd21c6c253169  bitcoin-0.3.20.01-linux.tar.gz
3fe4c5f2a5406322a2f116b30aefbd402b079940  bitcoin-0.3.20.01-win32-setup.exe
dffb709a90a7abcff08c2ef1e79d3f9b54751786  bitcoin-0.3.20.01-win32.zip
b540825d864e7561cc21465ad072fb299e0d817a  bitcoin-0.3.20.01.01-macosx.zip

Rumor has it he stole an Infinite Improbability Drive.

RE: a checklist:

For the next release, I will write a script that does all of the build/package steps.  I'll let the computer run the checklist for me... and the whole process should be much quicker, easier and smoother.

RE: 0.3.20.01

Fixed builds are at sourceforge, named 'bitcoin-0.3.20.01' to try to avoid confusion.
The mac build was 0.3.20.00 also; I am going to update that .zip when we get a .01 build, and I think I'll rename the
linux downloads to be consistent and, again, to try to avoid confusion.


SHA checksums:

3fe4c5f2a5406322a2f116b30aefbd402b079940  bitcoin-0.3.20.01-win32-setup.exe
dffb709a90a7abcff08c2ef1e79d3f9b54751786  bitcoin-0.3.20.01-win32.zip

The public Amazon AMI virtual machine image used to build them is:
 ami-7a21d213   982440761210/BitcoinMinGW

I'll be re-releasing updated windows .zip and .exe files later today to fix these issues.
And this time I'll triple-check versions on everything.