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?

Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems.

The danger is similar websites that try to blacklist <script> tags in HTML entered by users to prevent cross-site-scripting hacks.  See http://ha.ckers.org/xss.html for a nice sampling of how creative hackers can be.

I haven't asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit.  I don't think it matters; I'm still convinced that whitelisting acceptable transaction types is the right thing to do.

As for "the above option was thrown out by the developers"  -- nothing has been thrown out!  Again, I haven't talked to Satoshi, but I'm open to the idea of a third 'standard' transaction type that includes extra, arbitrary data.   Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs... and if there's general consensus that it is a good idea, roll it into production.

There's been exactly one block with non-standard transactions:
  http://blockexplorer.com/b/71036
... and it contained no fees.

HOWEVER:  jgarzik, you're over-reacting, too.  This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid.  Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them.  There will be no havoc.

I'll and add another reason not to have a "list transactions that happened after <txid>" :

move "transactions" don't have a transaction id, but they do affect account balances (and are listed in listtransactions).

Your code is going to get really messy if you expect to call listtransactions and then squirrel away the txid of the last item returned.  If it was "category":"move",  there WILL be no txid...

RE: eliminating polling:  at some point fairly soon, I plan on cleaning up my "monitorreceived" patch, to POST to a URL when transactions come in or blocks are accepted... but I need to do some Deep Thinking to redesign based on lessons learned from 'accounts'.  It might turn into a very minimal API, where the notification is "Hey, txid <123ae4221...> just got to N confirmations, you might want to call gettransaction and getbalance to get up-to-date."

Yes, although the first big feature on my ClearCoin TODO list is a reputation/feedback system.

Thanks for all the great feedback!

Maybe one way to think about ClearCoin is as a tool to help manage risk between buyer and seller.

If the buyer completely trusts the seller, then you don't need ClearCoin-- just send bitcoins directly.
If the seller completely trusts the buyer, then just send the product first.

Usually there's some level of trust/mistrust between buyer and seller.  If you use ClearCoin in creative ways, you should be able to come up with a way of using ClearCoin that balances the risks to both buyers and sellers.

To take davout's example:  The person paying could deposit 20% of the funds in a ClearCoin account, then immediately release that 20% as a "good faith payment".  Then they deposit the other 80%.

That gives an 80/20 risk split.   "Half now, half on delivery" type arrangements can be done the same way.

davidonpda:  You can choose how long your coins will be tied up when you create the escrow account-- one month, six months, or a year.  Of course, the longer they're held the more comfortable the person on the other side of the transaction will be.

PS to Vinnie:  ClearWing Software is the company; ClearCoin is the service.