I've got a fully functioning web service working with my bitcoin daemon, which I'm pretty happy with. When a withdrawal is requested, I'm doing the following -
settxfee = 16 satoshis / per byte (this seems pretty safe, however I may switch to using 'estimatefee 6')
sendtoaddress (I'm terrified about attempting rawtransactions)
I'm now thinking how to best handle fees so that they won't eat in to any potential profits. Sending to many isn't an option at this point. Withdrawals will come from warm storage.
I'm still thinking how to best handle things. Should I eat the tx fees or pass them on. Should I deduct a static fee from all withdrawals or a tiny percentage.
settxfee = 16 satoshis / per byte (this seems pretty safe, however I may switch to using 'estimatefee 6')
sendtoaddress (I'm terrified about attempting rawtransactions)
I'm now thinking how to best handle fees so that they won't eat in to any potential profits. Sending to many isn't an option at this point. Withdrawals will come from warm storage.
- Would it make more sense to utilize sendFrom, and then specify a minimum confirmation of ~6? I believe this should reduce fees.
- Is there anything I can do with my warm storage funds, in terms of organising unspent outputs, that will help increase their priority etc and therefore reduce fees?
- In the client it's possible to deduct the transaction fee from the sending amount, is this possible through the daemon?
- Are there any other practices or recommendations I'm missing?
I'm still thinking how to best handle things. Should I eat the tx fees or pass them on. Should I deduct a static fee from all withdrawals or a tiny percentage.
All things considered, fees are pretty low. Calculate the transaction size before sending, calculate the txfee, then deduct total fee from the amount your sending before you send it.
Check out this post: http://bitcoin.stackexchange.com/questions/22313/fees-for-bitcoind-sendmany-limits-for-number-of-end-addresses
