Sure, here's one:
  http://blockexplorer.com/testnet/tx/0d6c3d3470a89e4be56df04e80a9b7da1855bbe2cf07c1e99e22e0212688eb8b

It is not a new transaction type-- transactions could always have multiple TxOuts.

However, to prevent a denial-of-service attack (which was actually attempted-- see block 71036) transactions with more than 2 TxOuts are currently dropped by clients instead of relayed.

Now that there is a need for it, the rules allow "reasonable" multi-output transactions, but still denies "unreasonable" ones (reasonable means:  is one of the 2 standard transaction types and only does one ECDSA signature verification per recipient).

So:  no, this won't cause a block chain split.  And no, old miners will not disagree with new miners, so double-spending is not possible.

I was just about to ask the same thing as LMGTFY....
Running anybody else's code on your system is dangerous.

There is no bug, but if you want to know one of your customer's bitcoin addresses (maybe you want to send them a refund?) you must ask them.  They might be using an escrow service like ClearCoin or, as theymos says, using a shared wallet service like MyBitcoin.

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

Need for this is being driven by mining pool operators; it is much more efficient to pay lots of people with one transaction rather than lots of little transactions.

Old clients will refuse to relay sendmany transactions, so to ensure timely inclusion in a block mining pool operators should either upgrade together and connect their clients together or wait until a good percentage of the network has had a chance to upgrade to the next version of bitcoin.

Examples of use from a bash command-line (note you have to quote the second 'object' argument because the {} characters are interpreted by bash):

RE: changing things now "just in case" :

No, I think it would be dumb to switch hashing algorithms or public/private keylengths now, for at least two reasons:

1. You'd just be switching from older technology that has the advantage of being well-tested and "battle-hardened" to something newer that you THINK will be more secure.

2. There are much more important things to work on.  If you know enough about crypto to evaluate whether Whirpool really is fundamentally more secure than SHA-256, please apply your knowledge to the problems we have right now, like making users' wallets more secure against trojans and malware...

So lets say I can create SHA-256 collisions fairly easily, and I want to replace an old transaction somewhere in the block chain.

I create an alternate version of the transaction with the same hash... and then?  Whenever clients happen to connect to my node to get old transactions I feed them the bogus version?

How do I get a majority of the network to accept the bogus version as valid, when the majority of the network probably already has already downloaded the old, valid version?

Same question if I'm creating duplicate (old) block hashes instead of duplicate transaction hashes.


I suppose I could try to double-spend with two transactions that hash to the same value... and hope that the merchant's bitcoin accepts Transaction Version 1 while the majority of the rest of the network accepts Transaction Version 2 (where I pay myself).   But if SHA-256 ever gets close to being broken I'm sure bitcoin will be upgraded so new clients only accept upgraded hashes for new blocks/transactions.

You're browsing the web and see a link or button that says "Pay now with Bitcoin"-- you click it, and... stuff happens.  Where that stuff does NOT involve copying and pasting anything (I know WE all know how to copy and paste, but a surprising number of computer users don't) and certainly doesn't involve trying to type in a 35-character bitcoin address.

WAAAAAY back in May of last year I did a little CPU mining.  Then stopped when I realized I was spending more on electricity than the bitcoins I generated were worth.  Bitcoins were selling for under a penny a piece, and I figured it cost a couple cents in electricity to mine them.

So if you think there's a chance bitcoin prices will be 10 or 100 times higher in the next year or three, maybe CPU mining now isn't crazy.

Just saying.

Cool... but Hal just convinced me we don't need that feature for bitcoin 1.0.

Is anybody willing to commit to actually implementing any of these?

I know the bitcoin<->Berkeley DB code pretty well, so I'll volunteer to do the "Import a backed up wallet" feature.

You mean fairly large fluctuations in BTC/$ prices?  Yes, yes it will.  If you're looking for a stable, boring investment do not buy bitcoins.

I'm still surprised we haven't seen a real price bubble yet (where my definition of bubble is "doubles in price and then falls all the way back down").  Maybe we're in the middle of one still on its way up...

Maybe it is time to start a bitcoin stack exchange site?

Forums aren't really designed for Q&A.

Conversation I had tonight:


People who know me aren't shocked that I'm working on something wild and crazy, and by saying up front "this is a wild and crazy idea that may or may not work" I think they're more likely to really think about whether or not bitcoin makes sense.

It is amazing how the brain can ignore things that it sees every single day...  (thanks for pointing that out, fixed).

RE: removing wording about generating coins on the home page:  any objections to doing that?

Pull request:
  https://github.com/bitcoin/bitcoin/pull/101

I suppose if we figure out how to make click-to-pay work for both the "I'm using an online wallet service" and the "I'm using the client" cases, then users won't have to know how to copy&paste addresses and human-type-able addresses won't be critical.

RE: DoS resistance:  please DO keep thinking about it; I'm not a networking expert (in fact, if you know any networking experts, see if you can get them thinking about it....).

Good idea.  I opened a feature request at https://github.com/bitcoin/bitcoin/issues/100

Clearcoin now supports sending unreleased coins to a charity instead of refunding them, which gives both buyer and seller the same incentives.

Crashing bugs, any bug that might result in loss of bitcoins, and security fixes are always highest priority, but here are the big things I think are very high priority that, as far as I know, nobody is working on.  I think they all need to be done before we can say we have a "Bitcoin 1.0" :

• finish download-only-blockheaders client mode
• password-protect the wallet private keys (mitigate the steal wallet.dat problem: see https://gist.github.com/803170 )
• import a backed-up wallet
• figure out how to do click-to-pay
• design/implement a secure DNS-like "map string to bitcoin address" system  (so I can send bitcoins to "gavin@acm.org")
• export+encrypt part of your balance (for long-term storage; I still waffle on whether we want to encourage that right now)

The tag is v0.3.20.2, and it is signed by my (gavinandresen@gmail.com) gpg key.

RE: roadmap for v0.4 :  I worry that we'll spend time creating a roadmap and then... people will work on whatever strikes their fancy.  So the 0.4 release will end up being completely different from what the roadmap says.

That said, I'll start a roadmap thread; maybe we CAN all agree on priorities and find people to actually work on the highest priority stuff.