BTC fees in automated system

[djeZo]

I am working on an automated system that on one side accepts payments in BTC, and on the other side, sends payments in BTC out. The incoming and outgoing amounts would rather be small (from 0.001 BTC up to 0.1 BTC). I have successfully implemented RPC shaking with BTC client, but I have few questions about fees;

1. I would like to start my service completely out of my own fees. Is this even possible, since the sending of BTC I perform requires fees to be paid for BTC network. The ridicolous scenario is when I receive 0.001 BTC and I should forward 0.001 BTC. Fee for such amount is usually 0.0001 BTC. So, that is effectively massive 10%!!!

2. Can I call certain API to determine what would be the fee of outgoing transaction, so I can deduct this fee from the outgoing amount?

3. I was previously using blockchain.info API (https://blockchain.info/api/api_receive). I have noticed that they do forward payments and ALL payments were going on with 0 fee. So, if they do it, could I do it somehow too?

[empoweoqwj]

I am working on an automated system that on one side accepts payments in BTC, and on the other side, sends payments in BTC out. The incoming and outgoing amounts would rather be small (from 0.001 BTC up to 0.1 BTC). I have successfully implemented RPC shaking with BTC client, but I have few questions about fees;

1. I would like to start my service completely out of my own fees. Is this even possible, since the sending of BTC I perform requires fees to be paid for BTC network. The ridicolous scenario is when I receive 0.001 BTC and I should forward 0.001 BTC. Fee for such amount is usually 0.0001 BTC. So, that is effectively massive 10%!!!

2. Can I call certain API to determine what would be the fee of outgoing transaction, so I can deduct this fee from the outgoing amount?

3. I was previously using blockchain.info API (https://blockchain.info/api/api_receive). I have noticed that they do forward payments and ALL payments were going on with 0 fee. So, if they do it, could I do it somehow too?

Yes you can send payments  without fees. Just don't rely on them all turning up on time

[imrehg]

I am working on an automated system that on one side accepts payments in BTC, and on the other side, sends payments in BTC out. The incoming and outgoing amounts would rather be small (from 0.001 BTC up to 0.1 BTC). I have successfully implemented RPC shaking with BTC client, but I have few questions about fees;

1. I would like to start my service completely out of my own fees. Is this even possible, since the sending of BTC I perform requires fees to be paid for BTC network. The ridicolous scenario is when I receive 0.001 BTC and I should forward 0.001 BTC. Fee for such amount is usually 0.0001 BTC. So, that is effectively massive 10%!!!

Yes, the main client software that generally has such fee requirements hasn't been updated in a while to keep in touch with the BTC/fiat exchange rate (which would predict how small payments are reasonable for common use). Thus indeed you can have quite high fees. For a cup of tea/coffee/beer you could end up with 3-6% network transaction fee.

You can send your payment without any fee, just much smaller percentage of miners will accept it into their block, so you'll have to wait longer to be confirmed.

2. Can I call certain API to determine what would be the fee of outgoing transaction, so I can deduct this fee from the outgoing amount?

There's a general algorithm, of how to have a good estimate of the required fees: http://bitcoinfees.com/ The size of the transaction in bytes is "148 * number_of_inputs + 34 * number_of_outputs + 10", and every 1000 bytes have 0.00001 BTC fee normally.

3. I was previously using blockchain.info API (https://blockchain.info/api/api_receive). I have noticed that they do forward payments and ALL payments were going on with 0 fee. So, if they do it, could I do it somehow too?

They also say: Receiving transactions is completely free, any network fees will be paid by us.

[coinrevo]

Yeah, fees are now too high. I don't think there is a way around this. You have to look at the historic tables and estimate probability of : fees -> time to verify. 0 fees don't go through anymore AFAIK, on most pools. luke-jr mentioned something about that his pool relays them, perhaps blockchain uses his pool only for this.

For microtransactions currently the solution would be to use a different alt-coin or look at the microtransaction channel stuff.

[djeZo]

Thank you for your answers.

Now the only thing I need to figure out is - how can I calculate network fee, before I call sendfrom ?

[OnkelPaul]

One other thing that you should consider is to batch multiple payments into one transaction. Since the number of inputs won't grow in most cases, each additional output only incurs a cost for 34 bytes, which means you can often just slip it in without adding to the fee at all.
However, that approach would mean additional payout delays. Whether this is a problem depends entirely on your application and the response time expected by users.

Onkel Paul

[djeZo]

There are not going to be many payments, maybe one each few hours. I will settle with fixed 0.0001 network fee for now until I get to know what method to use to calculate network fee (it could really API for that...  or another sendfrom RPC command that subtracts fee from sending amount).