And also from people who are abusing it, and are funneling cash back into their primary account, often without TX fee...

http://blockexplorer.com/a/8i3b7nXppE
(View transaction detail -- many 0.05 receipts.)

This came out just now in #111264 when someone 'unclogged the drain':
http://blockexplorer.com/t/APn3cXG9Z1

# Number of inputs?: 181 (Jump to inputs)
# Total BTC in?: 9.05  => 181*0.05
# Number of outputs: 2 (Jump to outputs)
# Total BTC out?: 8.72
# Size?: 32.661 kilobytes

IMHO though, if anyone could maliciously generate a comparable volume of free transactions, that's still a potential issue, even if the faucet is fixed.

Transactions seem to be being processed 'up' the chain (the opposite direction of the arrows), albeit very slowly.  Usually only 1 in a block, but http://blockexplorer.com/b/111261 contained about 10 in a row (from the same chain).

ps. the green was my attempt to highlight transactions that have been confirmed, but my data for that was unreliable/wrong.

Hi, I made some further observations regarding the stalled transactions that started off this discussion (so hopefully this is on-topic) :


I then realised these transactions are being processed sequentially, only one per block:

• tx 8074fb67ce... was in block http://blockexplorer.com/b/111257
• tx 8ec51bbaf5... was in block http://blockexplorer.com/b/111258
• tx f9ccaa5e8b... was in block http://blockexplorer.com/b/111259
• tx 7dddd55332... was in block http://blockexplorer.com/b/111260

Any guesses tx dafce7d622... makes block #111261?

I find it very odd that exactly one transaction from this 'dependency chain' is being included into block.  Is this really the expected behaviour?  A mere coincidence?  Or something to be worried about?

My graph of 'dependency chains' I've observed in my debug.log is here:  http://pyro.eu.org/stuff/bitcoin-txqueue.pdf

Update: I think it's okay... in #111261 block, a huge chunk of items from that 'chain' I was looking at, made it into the block.  I guess there's nothing to be worried about.

I think it would be at least 10 blocks;  your transaction may get stuck in a backlog of free transactions that can't all fit into the next block.  Which seems to be happening for real right now...

If someone can flood the network with free transactions to/from their own addresses, and there's no way to make sure legitimate transactions are unaffected, there'd soon be no such thing as a free transaction any more.  Would it be so bad to disallow them to conserve resources?  The difficulty I imagine, would be in enforcing a minimum fee that would be remain sensible as BTC's value varies.


As for requiring 'proof of work';  requiring a BTC value inherently does that (they could join a mining pool to do the 'proof of work', then use their earnings to pay the fees).

A /48 block of IPv6 addresses is very easily obtained;  anything less strict than that could be easily abused I should imagine.  I'd wary of restricting access to anything by IPv4 or IPv6 address at all;  anyone in a large DHCP pool or at a site with large IP assignment (like a university campus) will likely try to connect from many IPs or physical machines.

I noticed this transaction today which looks somewhat suggestive of someone abusing the faucet -- I guess the zero fee (below the default for >=4kB transaction?) means they also wanted to hold on to every penny they'd accumulated:

• http://blockexplorer.com/tx/d737c270d090a8f0b01b6ea333123017af9bb157b6dc12f5df38d05c6f8b89bc

As for changing the faucet 'payout', I don't see why it can't just just calculate a fixed fraction of whatever's available at the time, rounded, and then clamped between safe minimum/maximum values.  It shouldn't need much manual adjustment then.  Abuse of the pool would lower the payout, making it less worthwhile, but preserving funds to keep the faucet functional for users just wanting to get started on bitcoin and play around.  And the payout would react sensibly to changes in BTC value (because that would affect donations, and hence the available funds).

Also I was wonder if the faucet could offer a 'include transaction fee' option whereby a portion of the faucet payout would be used to pay a transaction fee.  Or eventually even make a very small fee compulsory, marking a shift away from free transactions.

Hi,  I was affected by this issue too.

I'm totally new to bitcoin;  installed the Debian bitcoin-cli package yesterday, created a separate address from the default one (14mX4LPATYGqHqN16egft9dzwbjGy8j1Zc) and requested 0.05 from the faucet (txid e5017a6831e7034432ca033258254f3fda37ebae9c0de9765918380160d690cd) which has remained pending for almost 18 hours.

When investigating this I noticed lots of errors in ~/.bitcoin/debug.log like this:

Some of these partial txid's seem to 'cascade' on from one another, so I figured there was a dependency chain forming here.  I've managed to render this in the PDF below;  maybe that helps people to visualise what's going on.  If anyone else has transactions not completing, they may try searching for the transaction ID in the PDF document.  I found my transaction in there with at least 5 preceding it.  I count about 275 transactions in total at the moment, but I don't currently have the means to check if any of the displayed transactions eventually got processed.

• http://pyro.eu.org/stuff/bitcoin-txqueue.pdf

Hope this is somehow helpful!