1,500% transaction fee and 3,5 months to confirm?

So my service is skimming a tiny 0,001% (1/1,000) fee off every payment that gets through it. Most of the transactions are actually micro-payments so there are thousands of tiny unspent outputs accumulating in the service's wallet. I'm worried now that I will not be able to spent these outputs without having to pay a load of transaction fees and wait for eternity for this payment to clear.

The average btc value of my unspent outputs that come out of the commissions is 100 satoshis (0,000001 btc). That means that if I want to cash out 100 btc, I need to spend on average 100,000,000 of these outputs.

According to: How to calculate transaction size before sending the transaction size is: in*148 + out*34 + 10 plus or minus 'in', which makes my withdrawal equal to: 100,000,000*148 + 2*34 + 10 + 100,000,000 = 14,900,000,078 bytes = 14,9 GB ?! (am I missing something here?)

The maximum block size is 1 MB so I will need to split this transaction in more than 14,900 transactions of 1,000 kB each ?!

A transaction fee of 0.0001 btc per kB is required, so I will need to spend 0,0001 * 1,000 = 0,1 btc for each of these 14,900 transactions which means I will need at least 1,490 btc (to send 100 btc), which is roughly 15 times the amount I'm trying to send!

All these 14,900 transactions will need to be included on different blocks (since they would exceed the maximum block size otherwise) and since one block is found every 10 minutes on average, I will need to wait 14,900 * 10 minutes = 149,000 minutes = 2,483 hours = 103 days = 3 months and a half ?!

Please tell me I got this all wrong. I've really freaked out.

Edit1: Thanks to Nate Eldredge for pointing out an error in the calculations.

Doug Peters

Posted 2014-04-24T12:18:31.647

Reputation: 1 326

2If you mine it yourself, you don't need to include fees. You do, however, need to mine 14,900 blocks, which is not so easy (massive understatement). – Tim S. – 2014-04-24T14:04:04.083

1When you import a paper wallet into Coinbase, do they deduct transaction fees? If not, you could import the private key(s) into Coinbase, and then verifying would be their problem...you'd basically be ripping them off, by exploiting a loophole in their rules. (Warning: if this would work, don't actually do this without Coinbase's written permission. You'd be a jerk, might tank Coinbase and harm Bitcoin with it, and/or get sued.) – Tim S. – 2014-05-20T13:50:10.267

Please see what Coinbase's software will do with it :) – Lodewijk – 2014-10-31T00:53:35.380

Answers

You're doing it wrong if your service generates thousands of dust-sized outputs. You need to consolidate your outputs as you go.

I assume that a transaction under your current model is like this:

Input (x1): 
Payer Address (X BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (100 satoshis)
Payer Change Address (X - Y - 0.00000001 BTC)

What you should do is to keep the Service Wallet Address accumulate the 100 satoshis as you go:

Inputs (x2):
Payer Address (X BTC)
Service Wallet Address (Z BTC)

Outputs (x3):
Payee Address (Y BTC)
Service Wallet Address (Z + 0.000001 BTC)
Payer Change Address (X - Y - 0.000001 BTC)

uminatsu

Posted 2014-04-24T12:18:31.647

Reputation: 1 061

2The service's commission is always sent to the same address but how does this make any difference, every transaction contributes one more unspent output that is now owned by this address but still are distinct outputs, or am I missing something here? – Doug Peters – 2014-04-24T20:14:51.570

4@Doug: It adds one new output but consumes one that previously existed. The total number of inputs needed is the same, but this way you piggy back on a transaction that is already being made, and don't need to pay another fee. – Nate Eldredge – 2014-04-24T20:28:31.697

@NateEldredge could you please analyze this for me on a more technical level? I seem to fail to get it. What you actually say is that if I sent a few satoshis from different transactions to the same local address they will accumulate as a single unspent output? – Doug Peters – 2014-04-24T20:35:51.847

4@Doug to avoid thousands of dust outputs, you must consume your previous output by including it in the TX inputs. So every TX consumes an output at your service address and produces a new output at the same address with slightly higher account balance. – uminatsu – 2014-04-24T21:09:17.837

1@uminatsu I think I get it! So basically what I do is use my outgoing transactions to mash up my dust outputs into a single unspent output, right? Very smart, thanks for making it clear for me, also thanks to Nate. – Doug Peters – 2014-04-24T23:51:19.747

As amended, your calculations look essentially correct to me.

(The total time will actually be worse, since you are competing with all other users of the network for block chain space. And some miners enforce a smaller block size limit - in the default client I think it is 350K.)

So I suggest that you don't do that :-) As far as I know, Bitcoin was never intended to be used for micro-payments like this, and in fact many of these features exist specifically to discourage them. You may need a different business model.

Nate Eldredge

Posted 2014-04-24T12:18:31.647

Reputation: 21 420

You will need to start a policy of merging these transactions together, small group by small group. You will have to investigate the optimal strategy for it.

Then, over the course of probably years, you will have to keep these dust-mopping-transactions filling out the free crannies and nookies of every block. You'll be done in O(nlogn) transactions.

This result is somewhat intentional, it is a massive administrative pain to have all these mini-outputs. From now on you may wish to either bundle transactions (as to have less dust) or continuously mop dust together. It's a shame though, super small transactions are a neat feature!

Lodewijk

Posted 2014-04-24T12:18:31.647

Reputation: 1 447