Did you simulate network connectivity at all?  Bitcoin is a semi-randomly connected network, where most of the connections are (I would guess) outbound connections from non-generating nodes who are sitting behind firewalls.  With a typical node having 8 random connections, to different /16 networks, it seems to me it would be pretty tough to get tight-enough control over enough network connections to consistently win the "announce a new block" race.

Anybody know how to estimate what percentage of connections the cartel would have to control to only lose the announce-a-block race 15% of the time?  It'll be way more than 15%....

What theymos said.  You're asking for the balance of the account named '1Fs5rqB2sXZ3kax1r3HfuYpK2ksSxLYJT8', and there is no such account.

Whether bitcoin should return an error (instead of 0) if you ask for the balance of a non-existant account is debatable...

If the hashing algorithms are broken I might be able to generate an ECDSA private/public key pair where the public key hashes to the same bitcoin address as one of your public keys.

If I can do that, then I can spend your coins.

On my list of things to worry about, this is just below "Asteroid impact destroys the earth" (but above "Aliens invade and make me their slave").

getaccountaddress is designed for exactly this kind of thing-- it will return the same address over and over, until it gets used (until somebody donates).  After that, it returns a different address...

Of course, if "the public" is grabbing the donation address off your "Donate to Us" page, they could generate a list of donation addresses, add up the donations received on all those addresses, and figure it out.  Depending on how many donations you're getting that might be easy (scrape the page once per day) or hard (if you're getting dozens of donations per day).

You could make it much harder for anybody to figure out how much you're getting in donations by randomly donating to yourself (using the same address returned by getaccountaddress), preferably from a wallet shared by lots of other people (like a MyBitcoin or Mt.Gox account)... 

Change "getnewaddress(label)"  to "getaccountaddress(label)" and you'll get the same address over and over, until somebody donates.  Then you'll get a different one.

This thread talks in detail about Bitcoin's use of hashing of ECDSA public keys to generate bitcoin addresses.

Executive summary:
  bitcoinaddress = RIPEMD-160(SHA-256(publickey))

So you'd need to break both RIPEMD-160 and SHA-256 hashing algorithms.  And the RIPEMD break would have to be quite extreme-- more than just "add some random data to force a hash collision" (which is how MD5 is broken), because it is hashing a SHA-256 hash, so you're not able to add some random data to be hashed.

I was sent this question in email:

Why can't somebody just create a version of the software that gives you extra bitcoins?

... and couldn't find a good, non-geeky answer in the FAQs.  So I wrote one:

When you spend some bitcoins, the software on your machine has to prove to the software running on everybody else's machine that those bitcoins are valid.

How does it do that? Well, it is a little bit complicated; you've got to understand how bitcoins are created, and how they are traded.

First, how they're created: 50 bitcoins are created approximately every 10 minutes. Everybody who is trying to create bitcoins is in a race to try to find those 50 bitcoins; they are really hard to find, but, once found, it is easy to verify that, yes, indeed, your bitcoin software found them, so you get to spend them.

Second, how they're traded: Imagine you did find 50 bitcoins (well, your computer found them by running the bitcoin software for a few months or a year– they are not easy to find, and are harder to find the more people who are looking for them). You trade them to me by sending them to my bitcoin address. Inside the software, a messages is created and then broadcast to everybody that says “These 50 bitcoins that we all agree are valid are hereby officially traded to somebody else (me– well, one of my bitcoin receiving addresses, actually).”

Now I've got them. If you try to trade those same 50 bitcoins to somebody else, it won't work– everybody running Bitcoin sees all the trades, so if you try to spend the same coins a second time everybody else's software will reject your attempt to cheat.

And that's it– that's how it works. Bitcoins are scarce because only about 50 are created every ten minutes. And you can't claim to have more than you really have because everybody else can check to see if your coins really were created by the “race” process, or if they were from valid trades.

I'm not the designer of Bitcoin (I am one of the developers), but I have been thinking a lot about what it will take to make it safe(r) for my grandma to use.

playanaut, I'd love to hear your suggestions on how to make bitcoin better.  And (shameless plug): I'd also love to know if you think my latest project, ClearCoin, is a step in the right direction.

Oh, and RE: privacy:

Mixing all of the 'coins' for all of the accounts together is, I think, an overall plus for privacy.  True, you might receive coins from somebody and be able to figure out "Hey, they sent me some of exactly the same coins I deposited in my BigBitBank account yesterday!   They must have an account at BigBitBank, too!"

But mixing all the accounts' coins together makes it much more difficult to figure out where any user's coins came from, or, if you know where they came from, where the user is spending their bitcoins.  Unless you can subpeona BigBitBank's records, of course...

I wrote all this up (minus the little man) for the wiki:
  http://www.bitcoin.org/wiki/doku.php?id=accounts

Let me know if it doesn't make sense.  Or, even better, fix it for me!

Sorry to send you on a wild goose chase, the problem is NOT CRLF issues.

The problem is in your HTTP headers; you're sending the request as:

Content-Type: application/x-www-form-urlencoded

The correct Content-Type for JSON-RPC over HTTP is:
  Content-Type SHOULD be 'application/json-rpc' but MAY be 'application/json' or 'application/jsonrequest'

I'm not sure what .net is doing with the body of the request, but by the time it gets to Bitcoin/PostBin, it has x-www-form-urlencoded it enough to confuse the heck out of them.

When you get this working, please update this thread, and for extra positive karma, add a .net section to the Bitcoin JSON-RPC wiki page.

Accounts do not affect the previous-transaction-selection algorithm at all; if you sendfrom FOO, bitcoin doesn't make any effort to only use coins that were received by FOO.

Think of your wallet as being a big pool of coins.  Coins are not stamped with account names when they go in, instead, there's a little man with a green visor making entries in a ledger.

Each receiving address is a pipe that dumps coins into the pool, and the little man knows which pipes are assigned to each account.

Every send the little man grabs his shovel and picks a bunch of coins randomly from the pool.  Then debits an account.

And for moves, the little man doesn't have to touch the coins in the pool at all, he just adjusts his ledger.

You just did raise this as a potential bug, but you need to convince me that Bitcoin is not following the HTTP/1.1 spec, which says:


... and, for 'tolerant' applications:


What character(s) is JayRock putting between the headers and the body?

moves do not touch the block chain, they add accounting entries to your wallet to adjust the balances of the accounts involved.

Yes, listtransactions "*" <count> is possible.  The other account routines could return a new "invalid account name" error if given "*".

I've got two issues with it, though:

1.  listtransactions "*" will have to iterate over every transaction in the wallet (transactions are not indexed by time), which will be slow for large wallets and will get slower over time.  And indexing transactions just so that listtransactions * is fast violates the "an optional feature shouldn't cost anything if it is not used" principle.

2. What is the use case for "list the last N transactions across all accounts" ?   The only one I can come up with is developing an alternate GUI that communicates with bitcoind via the JSON-RPC, but to support that at least a couple of other features would have to be added at the same time (e.g. listtransactions would needs to add account and bitcoin address information to the objects it returns....)

Actually, thinking about it, are you sending \r\n for newlines?

Fricking PC versus Unix versus Mac line-endings will be causing problems until the end of time....

You're missing a blank line between the HTML headers and the HTML body-- PostBin and Bitcoin both think you're sending an empty request.

I dunno enough about JayRock to suggest how to fix that...

Nightly builds are a great idea; does the build service do an automatic svn update?  Anybody else willing to help get GUI-bitcoin building (or anybody know somebody on the wxWidgets team?)

Can you change the username/password in the authentication and then have it POST to:
  http://gavinpostbin.appspot.com/pwbba8

... so I can see all the headers/etc ?  You're probably not sending what you think you're sending...

Quick reaction:  what stops malicious or lazy BitX chain generator from implementing a type of denial-of-service attack against some bit-app they either don't like or don't know about?  If BitX blocks are never rejected for bit-app reasons, then what is the incentive for main-BitX chain generators to include only (or any!) valid bit-app hashes?   What stops me from constantly flooding the BitX network with bogus bit-app hashes and asking them to be included in BitX blocks?