0

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?

|improve this question
  • SIGHASH_SINGLE | SIGHASH_ANYONE_CAN_PAY sighash type might do the trick if I understood you correctly. – renlord Nov 16 '17 at 4:33
0

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.

|improve this answer
  • 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 Nov 16 '17 at 13:18
  • 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 Nov 16 '17 at 17:03
  • 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 Nov 16 '17 at 18:56
  • 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 Nov 16 '17 at 19:50
  • 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 Nov 16 '17 at 23:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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