Topic: Keeping Transaction Costs Down (Read 1245 times)

I have a medium level of tx understanding and I didn't have much trouble understanding your guide.  Maybe I will give creating my own raw transaction one day.
Thanks for the guide.

I have a short writeup on raw transactions. It has not been field-tested for understandability yet, so if things are unclear please let me know.

It advises you to do a bit of background reading to make sure you're familiar with how transactions work -- take this advice!

As for your website, how small is "small"? Would your trust model make it appropriate for probabilistic payments or having a deposit/withdraw account system?

Thanks for the input! I hadn't considered the idea of building my own raw transactions and using bitcoind to sign them.

I'll go look into that! Don't suppose anyone reading had any example code of that setup by any chance? I've found this topic on the forums so I'll start with that and see how it goes for me: https://bitcointalksearch.org/topic/using-the-raw-transactions-api-to-build-a-simple-transaction-101525

Am I right to think that I would basically be searching frantically for 5 or less inputs with the required BTC? Using those inputs and sending to their withdrawal address (with a valid change address specified) and then wallah, a transaction fee of just 0.0001 BTC? :-D

All good information and advice. 

Just make sure to test it using testnet first since it can be tricky.  ;-)

Here's how you can estimate your fee:

(149 Bytes (181 Bytes if uncompressed)x number of inputs) + (34 Bytes x number of outputs) + 10 Bytes = Size of transaction in bytes.

If you are receiving a lot of small amounts, then your input count will be sky high, and if you're sending to a bunch of people at once, then outputs will be high too.

With compressed inputs, you can fit 27 inputs and 27 outputs in a 5,000 byte transaction. For uncompressed you can fit 23 inputs and 23 outputs.

If you want to keep your transactions sub-1,000... you need to keep them down to 5 inputs and 5 outputs for compressed, 4 inputs and 4 outputs for uncompressed.

But when you think about it, you're getting more bang for your buck with the larger transactions.


Let's take things back a bit... Why don't you just create your own raw transactions and use bitcoind to sign them? (ie. DON'T use Createrawtransaction and just make your own and feed it into signrawtransaction?)

If you set it to 0.0001 and it's giving you a 0.0005 fee, that means your transaction's filesize is between 4,001 bytes and 5,000 bytes.

Does anyone have some good suggestions for keeping transaction costs down for payments sent with bitcoind via RPC?

I've done a lot of reading and what I've learnt is:
- transaction fees relate to the length of time BTC has been in an address if BTC has been in that address long enough
- transaction fees are higher for payments lower than 0.01 BTC
- the bitcoind client, while it allows the transaction fee to be set both in it's conf file and via RPC, will ignore those settings if it thinks a higher transaction fee is necessary (and in my experience at least, default to 0.0005 BTC)
- if your bitcoind node is modified so that it keeps the transaction fee low it is at risk of being ignored due to broadcasting what might be considered 'spam' transactions
(Please correct me if I've got any of this wrong!)

So, with that in mind, is there a way to play within the rules and keep transaction fees to 0.0001 BTC on sent transactions of less than 0.01 BTC?

I'm developing a website that will receive lots of small amounts and be sending lots of small amounts. In testing bitcoind has always defaulted the transaction fee to 0.0005 BTC, despite me trying to enforce a transaction fee of 0.0001 BTC in both the conf file and via RPC command. I've had feedback from people who have tested it that a transaction fee of 0.0005 BTC is "just too damn high". I was wondering - maybe if I deposited 10BTC into the wallet and left it there a few days before launch - would that allow smaller transaction fees on subsequent withdrawals, even though they are below 0.01 BTC...?

Unless I'm missing something I have two options:
1) Leave the transaction fee set at 0.0005 BTC and upset the users (as it's "just too damn high")
-OR-
2) Set the transaction fee at 0.0001 BTC and just eat the 0.0004 BTC difference out of the hot wallet as a hard cost (sure, only $0.20 USD~, but will mount up over time!)

I would love it if someone could suggest an option 3 or option 4 that I'm missing so I can both keep transaction costs low and avoid paying the difference myself!

Thanks in advance for any help you can offer!