<blockquote>
  <p>With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?</p>
</blockquote>

<p>If you are trying to combine two independently signed transactions together it would include a number of constraints on how the amount can be spent and how the transaction is structured. This is because when we sign transaction, we include the serialized transaction as the message (until we have <code>SIGHASH_NOINPUT</code>). The constraints are the following:</p>

<ol>
<li>The version and nLocktime of both transactions would have to be same.</li>
<li>The individual transaction inputs would need to be signed with <code>ANYONECANPAY|SINGLE</code> SIGHASH flag. The <code>ANYONECANPAY</code> allows adding additional inputs to the transaction. However, if you sign with <code>ANYONECANPAY|NONE</code>, the signer is at a risk of his output being excluded from the transaction as he has not committed to any outputs. Signing with <code>ANYONECANPAY|ALL</code> binds all the outputs and hence no other outputs can be added. All of this means, the signer can only send money to a single address/script and hence cannot include a change output to send remaining money.</li>
</ol>

<p>The #2 point is true if the signer does not trust any centralized entity in batching the transaction. A signer can however, sign with <code>ANYONECANPAY|NONE</code> flag and assume that when the centralized entity broadcasts the transaction they will sign the transaction with <code>ALL</code> flag in order to bind all the outputs to the transaction.</p>

<blockquote>
  <p>Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?</p>
</blockquote>

<p>Transaction fees are based on the weight of the transaction. Signatures, outpoints of tx referenced, and locking script occupy the vast majority of that which cannot be done away with batching transactions signed independently. You will only be saving transaction costs on things that are common like 4 byte transaction version, 4 byte nLocktime, 2 bytes for number of tx inputs/outputs.</p>

<p>Batching is generally done to mask who pays to whom (eg. coinjoin) not to save fees. But even in that case the batching server gives the senders a final serialized transaction containing all the inputs and the outputs that all of them sign with <code>sighash_all</code> flag. Each input is not signed independently.</p>

CC BY-SA 4.0
2019-05-27T12:09:25.710Z
2019-05-27T12:24:40.227Z
2019-05-27T12:24:40.227Z
Ugam Kamat
<p>With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)? </p>

<p>Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?</p>

<transactions><bitcoin-cli><signrawtransaction><payment-batching>
How to combine separately signed inputs from different users?
user95756
# How to combine separately signed inputs from different users?

(Asked by: username_0 on 2019-05-27)

With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?

Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?

**Tags:** transactions, bitcoin-cli, signrawtransaction, payment-batching


---

## 1 answers

### Answer by username_1 on 2019-05-27. Score: 0 | Accepted answer

> With two separate signed raw transactions from two users, how would one go about 'batching' these manually (combining the inputs and outputs into a single transaction)?

If you are trying to combine two independently signed transactions together it would include a number of constraints on how the amount can be spent and how the transaction is structured. This is because when we sign transaction, we include the serialized transaction as the message (until we have `SIGHASH_NOINPUT`). The constraints are the following:

1. The version and nLocktime of both transactions would have to be same.
2. The individual transaction inputs would need to be signed with `ANYONECANPAY|SINGLE` SIGHASH flag. The `ANYONECANPAY` allows adding additional inputs to the transaction. However, if you sign with `ANYONECANPAY|NONE`, the signer is at a risk of his output being excluded from the transaction as he has not committed to any outputs. Signing with `ANYONECANPAY|ALL` binds all the outputs and hence no other outputs can be added. All of this means, the signer can only send money to a single address/script and hence cannot include a change output to send remaining money.

The #2 point is true if the signer does not trust any centralized entity in batching the transaction. A signer can however, sign with `ANYONECANPAY|NONE` flag and assume that when the centralized entity broadcasts the transaction they will sign the transaction with `ALL` flag in order to bind all the outputs to the transaction.

> Is this a viable solution for groups of users attempting to save on fees, or would the extended length of the resulting transaction negate any real savings?

Transaction fees are based on the weight of the transaction. Signatures, outpoints of tx referenced, and locking script occupy the vast majority of that which cannot be done away with batching transactions signed independently. You will only be saving transaction costs on things that are common like 4 byte transaction version, 4 byte nLocktime, 2 bytes for number of tx inputs/outputs.

Batching is generally done to mask who pays to whom (eg. coinjoin) not to save fees. But even in that case the batching server gives the senders a final serialized transaction containing all the inputs and the outputs that all of them sign with `sighash_all` flag. Each input is not signed independently.


---

