Somebody did that a few months ago (theres a message here in the forums SOMEWHERE...)

If I recall correctly, after he was done he found that it wouldn't compile on Windows any more.

Maintaining the faucet isn't a big drain on my time-- most days I don't think about it.

Given the number of newbies who wander into #bitcoin-dev and mention they got 0.05 BTC from the faucet, I think it is still valuable as a nice introduction to using bitcoin.

And Jim:  thanks!  Without donations the Faucet would have run out of coins long ago...

You can't send messages with transactions.

There was some discussion of adding another "standard" transaction type that allowed you to add N bytes of arbitrary data.  I think that is a good idea (I think people would find all sorts of interesting uses for it), but there are higher priority things on the development roadmap.

Thanks-- there was indeed a bug in the "weren't you just here?" code...

The Bitcoin Faucet ran out of coins this morning, so I took that as a sign that I should make some changes that I've been meaning to make for a while.

The big change is the Faucet now requires you to have a Google account (and login with your Google Account) to get coins.  With IPv6 starting to happen, and people getting ever more creative in the ways they tried to get around the "X bitcoin per unique IP address" rule, I decided to let Google catch people trying to create lots of accounts.

From what I remember, the cost of buying a google account is much higher than the value of the coins I'm giving out (as opposed to the cost of hiring somebody to solve captchas), so the only people working hard to create new Google accounts to try to rip off the Faucet will likely be teenagers with way too much time on their hands.

One little change:  Faucet pay-outs are now:
  0.11 BTC when balance > 500 BTC
  0.05 otherwise (same as before).

And an invisible change that actually happened a few days ago:  the Faucet pays a 0.01 transaction fee every time it sends coins.  That makes Faucet transactions get into blocks quicker when there are lots of other free transactions on the network, and leaves more room in blocks for free transactions.

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