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:
- you need to extract the V_in and V_Out from Alice transaction
- need to integrate these parts in the model above, and update the
TX_IN and TX_Out counters
- 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.
SIGHASH_SINGLE | SIGHASH_ANYONE_CAN_PAY
sighash type might do the trick if I understood you correctly. – renlord Nov 16 '17 at 4:33