No.  Generated coins need a place to go (they're credited to the "" account), and coins you send using sendtoaddress (where you don't specify an account) need to be debited from somewhere (they're debited from the "" account).

And it's theoretically possible somebody might could use one of your hidden "change" bitcoin addresses to send you coins; they'd be credited to the "" account, too.

JollyGreen was asking about 'typical people'.  And I think he was asking about "right now".

Typical people aren't going to distinguish the currency from all of the financial services that make the currency safe, convenient, etc.  And I think we should be honest-- bitcoin-the-currency needs more mature financial services before bitcoin-the-system makes sense as a payment solution for typical people.

Saving for the future:  bitcoins are designed to be like gold: durable, only a limited supply.  They have some advantages over gold-- they're much easier to store safely (you don't have to buy a bank vault or hire guards or trust a storage company) and, because they're electronic, they can be backed up.  And when it is time to sell them the transaction costs are very, very low.

Buy some goods online:  I don't think bitcoins have any significant advantage... yet.  Transaction fees are lower once you get bitcoins, but the transaction fees to get bitcoins probably eliminate that advantage.

I think Bitcoin's real, hidden advantage is the fact that you don't have to ask anybody's permission or fill out any paperwork to start doing creative, innovative things with them.  Lots of people are doing lots of innovative things with bitcoins, and while most of those innovative things will probably fail (most startups fail), I'm optimistic that some will succeed and in 5 years we'll be using bitcoins in some way we haven't even imagined yet.  I'm not going to pretend to know which market niches bitcoin will fill-- maybe it will be migrant workers using bitcoin to send money back home and avoiding international wire transfer and currency conversion fees.

Maybe teenagers in China will use them to buy stuff online because they can't get a credit card.

Maybe big multinational corporations will decide to use bitcoins to pay their supply chain to avoid currency exchange risk and save 0.1% on their transactions.  Who knows?  Even if bitcoin turns out to be just "a better store of value than gold" it will be hugely successful.

See:
  https://en.bitcoin.it/wiki/Block_hashing_algorithm

The exact hash done is double-sha256: sha256(sha256(block_header_data))
See:
 http://en.wikipedia.org/wiki/SHA-2

... for information about sha256

Great suggestion, I will modify the code to refund the escrow fee (if any) and donate the rest.


I have some preliminary plans for mediated escrows that will require all three parties to have ClearCoin accounts.  I'm still thinking about how to make it as simple to use as possible.

Great idea, I'll put it on the "nice to have" list.

Easy to do.  How critical is time?  Plus or minus 1 hour would be easy (there's a 'cron job' that runs once per hour to process refunds), but I don't want to make the Create an Escrow page more complicated than it really needs to be.

I'll probably target transactions under $50 remaining free, and I'm thinking of capping fees at $4... but it is likely I'll experiment with different pricing models as I fill out features.  Paying mediators (before and/or when mediation is required) adds lots more wrinkles...
Nope.  Maybe I'll franchise later if Bitcoin and ClearCoin really take off.
No-- what authentication method would you like to see?  I don't like the idea of supporting arbitrary OpenID authentication, because it is so easy to create throwaway OpenID identities (creating throwaway Google identities is at least a LITTLE bit harder...).

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