Is there a type of signature that will be valid in a transaction with multiple inputs/outputs that are unknown at the time of signing?

Question

Alice is the owner of input_a (txid: xxxyyyzzz). Can Alice do a transaction that will entirely spend input_a (txid: xxxyyyzzz) minus fees to Bob (outout_a pkh: 1aaabbbccc) that can later be picked up by someone else and merge it into another transaction that spends 9 other different inputs (input_b, input_c...k) to 9 other different outputs? Alice needs to do the signature without being aware of which the rest 9 inputs / outputs are, nor the signatures for them.

Anyone knows a trick that could make this happen?

Answer 1

I think there is no "trick" :-) Maybe I don't fully understand your logic with "later by someone else". But maybe this helps you to get along: I would think about a smart contract with CHECKSEQUENCEVERIFY, where you have a condition, that get's redefined, when a certain time has passed (after a specific amount of blocks have been mined). A very short idea could be this (baseline idea, no real code!):

OP_IF
   OP_DUP OP_HASH160 [PUBKEYHASH Alice] OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
   [blocks to pass] OP_CHECKSEQUENCEVERIFY OP_DROP
   OP_DUP OP_HASH160 [PUBKEYHASH "someone else"] OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

This translates into this logic: Alice can spend the tx anytime, but when a certain amount of blocks happened, then someone else can spend the tx.

It wouldn't matter, from "where" someone else spends the tx, if it is a single transaction with one input (aka Alice' Satoshis), or with many inputs from other tx. The spending condition for "someone else" is independant from the tx, in which it appears.

There is no wallet I'm aware of, that allows to realise the above condition via a graphical interface. It would have to be handcrafted... (aka "coded").

===================

Update after comments section has been worked through (28 March 2018)

Understanding your point corectly, you want to extend an existing tx with additional tx. To my knowledge there is no wallet which allows to do this. With the help of some command line tools one can get to the goal. A standard tx looks like this:

VERSION
TX_IN COUNT (e.g. 9 input structures)
 TX_IN[0]
  TX_IN[0] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence 
 TX_IN[1]
  TX_IN[1] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence 
 TX_IN[n]
  TX_IN[n] prev TX hash, OutPoint index, Script Length, Script Sig, Sequence 

TX_OUT COUNT (e.g. 9 output structures)
 TX_OUT[0]
  TX_OUT[0] Value, PK_Script, pk_script 
 TX_OUT[1]
  TX_OUT[1] Value, PK_Script, pk_script 
 TX_OUT[n]
  TX_OUT[n] Value, PK_Script, pk_script 
LOCK_TIME

So if the unsigned tx from Alice needs to go into this structure (of someone else), there are three things to get it correct:

1. you need to extract the V_in and V_Out from Alice transaction
2. need to integrate these parts in the model above, and update the TX_IN and TX_Out counters
3. then the "someone else" would have to sign the tx...

The signing will be the complex part for someone else, cause somehow each input is signed with the corresponding privkey. So Alice would have to trust "someone else", and provide her privkey... If the privkey is not provided, the signature would stay invalid, and could not be sent into the network.

In general I was thinking, why one would do such an effort? For sure to save fees... As @willtech explained, exchanges collect many inputs into a single transaction, and then they have their corresponding privkey.

To get around this signing problem for Alice, one could think of a multisig. Then she doesn't need to provide her privkey to anyone.