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

[DougPeters]

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 ?!

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.

[TierNolan]

It doesn't really matter how much you transfer, each transaction output takes the same amount of effort for the network to process.

It isn't unreasonable that if you put a large load on the network that you would have to pay high fees.

You might be able to get away with using free transactions, but then you would have to wait even longer.

The current blockchain is around 16GB, so consolidating your transactions would nearly double the total size.

Since there are only around 10 million outputs at the moment, I assume this is a future plan?

If so, you should look into things like payment channels.  They allow you to handle micropayments better.  This assumes that each customer makes lots of micropayments.

[Rannasha]

Sorry to burst your bubble, but 100 satoshi outputs are not spendable according to the current protocol rules that miners apply. Any outputs below 5430 satoshis cost more in fees than they are worth, so a typical miner will not include such transactions in blocks.

[DougPeters]

Since there are only around 10 million outputs at the moment, I assume this is a future plan?

If so, you should look into things like payment channels.  They allow you to handle micropayments better.  This assumes that each customer makes lots of micropayments.

Yes, the service rolled out only a couple of months ago but this is the way it currently works so we need to readjust its revenue model ASAP! Thanks for your suggestions!

[DougPeters]

Sorry to burst your bubble, but 100 satoshi outputs are not spendable according to the current protocol rules that miners apply. Any outputs below 5430 satoshis cost more in fees than they are worth, so a typical miner will not include such transactions in blocks.

I thought there were some miners who don't follow the rules and can include them in their blocks. Nice..

[teukon]

If you have lots of users making tiny payments, why not look into a "probabilistic payments" algorithm.  The idea is, instead of paying 100 satoshi, you pay 100`000 satoshi with a probability of 0.1% (some fun with crypto and proofs to be had here).  This will reduce your Bitcoin footprint (and therefore fees) 1000-fold while having negligible effect on users.

[DougPeters]

If you have lots of users making tiny payments, why not look into a "probabilistic payments" algorithm.  The idea is, instead of paying 100 satoshi, you pay 100`000 satoshi with a probability of 0.1% (some fun with crypto and proofs to be had here).  This will reduce your Bitcoin footprint (and therefore fees) 1000-fold while having negligible effect on users.

That sounds like a good approach, I'll have to check it out ASAP, thank you for bringing it up.

[gmaxwell]

Sorry to burst your bubble, but 100 satoshi outputs are not spendable according to the current protocol rules that miners apply.

That isn't true!  The network tries to discourage you from _creating_ such outputs (because they tend to be uneconomical to spend), but you are in no way discouraged from spending them other that just from the cost of doing so.

[Luke-Jr]

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.

Wow, the antispam fees are actually working for once, in a sense!
Your service is exactly what the fee aims to prevent.

Bitcoin's blockchain is not a micropayment system.

[jl2012]

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.

Wow, the antispam fees are actually working for once, in a sense!
Your service is exactly what the fee aims to prevent.

Bitcoin's blockchain is not a micropayment system.

Bitcoin could be a better system for micropayment, if it allows:

1. shorter public keys and key hash: you don't need the full protection just for 100 satoshi. Something that is bruteforcable in a few months is already more than enough

2. signing multiple inputs with one signature

3. adopt a balance based system

[Luke-Jr]

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.

Wow, the antispam fees are actually working for once, in a sense!
Your service is exactly what the fee aims to prevent.

Bitcoin's blockchain is not a micropayment system.

Bitcoin could be a better system for micropayment, if it allows:

1. shorter public keys and key hash: you don't need the full protection just for just 100 satoshi. Something that is bruteforcable in a few months is already more than enough

2. signing multiple inputs with one signature

3. adopt a balance based system

There are a number of ways Bitcoin could be extended to do micropayments; I was just commenting on the OP's present use.
(btw, your suggestion #3 is fatally flawed when it comes to avoiding double spends...)

[jl2012]

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.

Wow, the antispam fees are actually working for once, in a sense!
Your service is exactly what the fee aims to prevent.

Bitcoin's blockchain is not a micropayment system.

Bitcoin could be a better system for micropayment, if it allows:

1. shorter public keys and key hash: you don't need the full protection just for just 100 satoshi. Something that is bruteforcable in a few months is already more than enough

2. signing multiple inputs with one signature

3. adopt a balance based system

There are a number of ways Bitcoin could be extended to do micropayments; I was just commenting on the OP's present use.
(btw, your suggestion #3 is fatally flawed when it comes to avoiding double spends...)

I think I have found a solution: https://bitcointalk.org/index.php?topic=552624.msg6376604#msg6376604

Please see if you could find further flaws

[teukon]

If you have lots of users making tiny payments, why not look into a "probabilistic payments" algorithm.  The idea is, instead of paying 100 satoshi, you pay 100`000 satoshi with a probability of 0.1% (some fun with crypto and proofs to be had here).  This will reduce your Bitcoin footprint (and therefore fees) 1000-fold while having negligible effect on users.

That sounds like a good approach, I'll have to check it out ASAP, thank you for bringing it up.

No problem.  I think your situation is suitably uncommon/extreme that you won't find much more than theory.  Try searching for things like "provably fair coin flips" in this sub-forum.

If you do decide to take this route, some of the encryption techniques commonly used in provably fair gambling or decentralised mixing solutions could be useful too.  I lack the time to create a working implementation myself (it's on my to-do list but quite low down), but might be able to help out if you have further questions.

[uminatsu]

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)

[Peter882]

If you have a big input in your wallet, you could very slowly "consolidate" your bitcoin using high-priority free transaction.
Anyway, it seems there is a big flaw in your business.