<p>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!):</p>

<pre><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
</code></pre>

<p>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. </p>

<p>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. </p>

<p>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"). </p>

<p>===================</p>

<p><strong>Update</strong> after comments section has been worked through (<strong>28 March 2018</strong>)</p>

<p>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: </p>

<pre><code>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
</code></pre>

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

<ol>
<li>you need to extract the V_in and V_Out from Alice transaction</li>
<li>need to integrate these parts in the model above, and update the
TX_IN and TX_Out counters</li>
<li>then the "someone else" would have to sign the tx...</li>
</ol>

<p>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. </p>

<p>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. </p>

<p>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. </p>

CC BY-SA 3.0
2017-11-16T13:18:53.677Z
No. That is wrong. The someone else in your example can wait for the time to pass and spend the input to someone else, not Bob. I want for the transaction to be from Alice to Bob and all that someone else can do is to merge it into another transaction with other inputs and outputs but without being able to change the destination and amount from Alice to Bob n BTC.
skydanc3r
CC BY-SA 3.0
2017-11-16T17:03:55.417Z
in your first sentence you say "spend to someone else, not Bob", and the last sentence says "without being able to change the destination". confused ...
pebwindkraft
CC BY-SA 3.0
2017-11-16T18:56:53.347Z
Where did i say spend to someone else? I said can be picked later up by someone else and merged in a new bigger transactions that joins other inputs and outputs with this one.... Sorry for the confusion my explanation might not read 100% clear.
skydanc3r
CC BY-SA 3.0
2017-11-16T19:50:12.153Z
I see..  "Can Alice do a transaction that will entirely spend input_a (txid: xxxyyyzzz) minus fees to Bob (outout_a pkh: 1aaabbbccc)" - yes. After tx is mined, only Bob has the keys to spend the funds... "that can later be picked up by someone else" - no, cause only Bob has the keys to spend. Bob could combine this into another tx with different inputs and outputs. The inputs are basically the previous tx hash and counter, which are usually different hashes. And they can be spent to any output... (as long as you have then the possibility to sign correctly).
pebwindkraft
CC BY-SA 3.0
2017-11-16T23:19:57.790Z
Of course Bob can spend and combine with other inputs after that (the child transaction that spends Alice s ouput) but i was refering to the unconfirmed transaction from Alice to Bob to be picked up by anyone and be merged in a bigger transaction without changing the amount or destination, just merge it into a bigger transaction with more inputs and outputs so they are mixed together.
skydanc3r
CC BY-SA 3.0
2018-03-28T02:09:42.327Z
@skydanc3r some web wallets do that because they own the keys for all of the addresses so they combine the several transactions into one transaction. If you have a Bitcoin client (wallet) on your desktop or server there is no way to do that unless you own all of the keys for all of the inputs.
Willtech
CC BY-SA 3.0
2018-03-29T19:23:35.800Z
and having dived into the code, there is a combine function (line ~620): https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L849
pebwindkraft
CC BY-SA 3.0
2017-11-16T09:34:26.473Z
2018-03-28T06:46:18.583Z
2018-03-28T06:46:18.583Z
pebwindkraft
<p>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.</p>

<p>Anyone knows a trick that could make this happen?</p>

CC BY-SA 3.0
2017-11-16T04:33:14.350Z
`SIGHASH_SINGLE | SIGHASH_ANYONE_CAN_PAY` sighash type might do the trick if I understood you correctly.
rny
CC BY-SA 4.0
2020-04-17T12:27:23.233Z
could you elaborate a little bit more your question? so far it looks like a simple smart contract problem. Who would be in charge of the smart contract? who or how will it be decided to spend these inputs and how?
Oscar Serna
<transactions><signature>
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?
skydanc3r
# 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?

(Asked by: username_0 on 2017-11-15)

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?

**Tags:** transactions, signature

> **Comments:**
> **username_1**: `SIGHASH_SINGLE | SIGHASH_ANYONE_CAN_PAY` sighash type might do the trick if I understood you correctly.  
> **username_2**: could you elaborate a little bit more your question? so far it looks like a simple smart contract problem. Who would be in charge of the smart contract? who or how will it be decided to spend these inputs and how?  

---

## 1 answers

### Answer by username_3 on 2017-11-16. Score: 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 @username_4 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.

> **Comments:**
> **username_0**: No. That is wrong. The someone else in your example can wait for the time to pass and spend the input to someone else, not Bob. I want for the transaction to be from Alice to Bob and all that someone else can do is to merge it into another transaction with other inputs and outputs but without being able to change the destination and amount from Alice to Bob n BTC.  
> **username_3**: in your first sentence you say "spend to someone else, not Bob", and the last sentence says "without being able to change the destination". confused ...  
> **username_0**: Where did i say spend to someone else? I said can be picked later up by someone else and merged in a new bigger transactions that joins other inputs and outputs with this one.... Sorry for the confusion my explanation might not read 100% clear.  
> **username_3**: I see..  "Can Alice do a transaction that will entirely spend input_a (txid: xxxyyyzzz) minus fees to Bob (outout_a pkh: 1aaabbbccc)" - yes. After tx is mined, only Bob has the keys to spend the funds... "that can later be picked up by someone else" - no, cause only Bob has the keys to spend. Bob could combine this into another tx with different inputs and outputs. The inputs are basically the previous tx hash and counter, which are usually different hashes. And they can be spent to any output... (as long as you have then the possibility to sign correctly).  
> **username_0**: Of course Bob can spend and combine with other inputs after that (the child transaction that spends Alice s ouput) but i was refering to the unconfirmed transaction from Alice to Bob to be picked up by anyone and be merged in a bigger transaction without changing the amount or destination, just merge it into a bigger transaction with more inputs and outputs so they are mixed together.  
> **username_4**: @username_0 some web wallets do that because they own the keys for all of the addresses so they combine the several transactions into one transaction. If you have a Bitcoin client (wallet) on your desktop or server there is no way to do that unless you own all of the keys for all of the inputs.  
> **username_3**: and having dived into the code, there is a combine function (line ~620): https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L849  

---

