1

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?

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.