6

If I have to make 10 payments of various amounts to different recipients:

  • What is the best approach for the lowest tx fee? One transaction that will serve many (or all) logical payments (many inputs and outputs) or many but small in size transactions that will each serve a single logical payment?

  • Which of the above transactions is most likely to get completed successfully? In the combining transaction, if a sub-payment fails after the transaction has been broadcasted to the network will all of the other sub-payments fail and will the transaction never confirm?

Doug Peters
  • 1,366
  • 15
  • 23

2 Answers2

4

There are more variables at play than you have listed, so I can't answer with certainty. Calculator for estimated TX-Fees lists some of the considerations as to when a fee is required, and how much the fee is. (but note that some of the info there is out of date due to a change; the Bitcoin wiki has more up to date info, and is also a good resource on this subject) For example, how many inputs are there, and what sizes and ages are they.

That said, I think that most likely, the best thing to do would be to do it all in one large transaction and pay 0.0001 BTC per 1000 bytes. I'd expect you'd have to pay 0.0001 or 0.0002 BTC (~US$0.06-0.12) for the transaction. Including more wouldn't hurt, and might improve how long it'll take to get it confirmed.

Assuming the transaction is valid (you should make sure it is before broadcasting it) and includes a large enough fee to be relayed by most peers and miners, you shouldn't have to worry about anything going wrong with the transaction. E.g. none of your recipients can invalidate the transaction.

Community
  • 1
Tim S.
  • 4,407
  • 14
  • 25
2

A single payment is better for both purposes. The transaction fee is relative to the size of the transaction in bytes, so a 1 KB transaction which pays a $0.10 fee is equal to a 10 KB transaction that pays a $1.00 fee, all other things being equal.

A typical transaction that pays a single other person will have a 4-byte version, a 36-byte outpoint (previous output identifier), a 73-byte signature script, a 4-byte sequence number, two outputs of about 33 bytes each---one for the payment and one for the change (8-byte value, 25-byte pubkey script for P2PKH)---and a 4-byte locktime, plus a few 1-byte compactSize uints for the variable-length fields. That's about 187 bytes total for one transaction and 1,870 bytes for ten transactions.

On the other hand, a transaction with 10 external payments will have the same version, same outpoint, same signature, same-byte-size change payment, and same locktime (about 154 bytes). It'll also have 10 payments with 33-byte outputs (about 330 bytes). That's about 484 bytes total for all ten payments, about 25% as many bytes.

What you call sub-payments (outputs) can't fail individually. When the transaction is accepted by a node, it checks the outputs to make sure they pass that node's validation rules. After that point, the only thing which can make them invalid is if you create a double-spend---another transaction which spends the same input as used in the first transaction.

David A. Harding
  • 11,906
  • 2
  • 46
  • 72