1

I am wondering whether the following scenario is possible. Any help is very appreciated.

Alice and Bob are creating a (taproot) 2-of-2 multisig together. They do not trust each other. They intend to fund the multisig address with 1 BTC each but before they send their Bitcoin to the multisig address, they presign a transaction (the redeem transaction) that spends 1 BTC back from the multisig to each of them. Only when both of them have a copy of this unbroadcasted transaction, will they proceed to fund the multisig.

Is this possible? In order to presign the redeem transaction they would need to know the TXID of the outputs they intend to send to the multisig, correct? So they would need to create their separate funding transactions that go into the multisig and share the TXID with each other (but do not broadcast it yet). Then they construct and sign the redeem transaction. Then they broadcast the funding transactions. Is this possible or am I thinking too complicated?

Also, what if the fee environment changes during this process and one of the funding transactions does not get confirmed? Then the presigned redeem transaction is worthless since using RBF on the funding transaction would change the TXID and thus invalidate the presigned redeem transaction? Is there a way to circumvent that?

Thanks a lot!

EDIT: Here is an example of a situation that describes what I want to achieve. Alice and Bob want to create a venture fund. They do not know in which startup to invest just yet. Of course, they will only invest in a startup if both agree that it is a good investment. So they create a 2-of-2 multisig for this purpose. Before funding it, however, they think about what would happen if the other party disappears or if they will not come to an agreement about where to invest. They could block the others funds indefinitely. Therefore they want to have to option to exit the multisig unliterally to predefined addresses.

2
  • I don't think the example in your edit is a good one for chains of presigned transactions. The co-investment could just be a single transaction Alice and Bob craft once they've decided what company to fund. This transaction would spend coins from both Alice and Bob. Commented Jun 4 at 9:36
  • Yes, fully agree. It is a contrived example (not a good one at that). But I am still interested whether it is possible to achieve exactly this outcome that I describe above.
    – Neo
    Commented Jun 4 at 10:45

2 Answers 2

0

Yes it is possible. It is in fact a technique at the core of most trustless protocols on top of Bitcoin. Including the most used one, the Lightning Network.

Regarding the funding transaction confirmation, any secure protocol would wait for it to be sufficiently buried before treating the contract as active. For instance in the case of a payment channel, both parties would wait for confirmations before making payments to each other through the channel.

Indeed bumping the fees of the funding transaction would change its txid. But if both parties cooperate they can just pre-sign another chain of transactions from the new, bumped, funding transaction. If they don't, each party can just RBF ("double spend") their funding transaction. That is, spending any of the coins spent by their unconfirmed funding transaction in another transaction with a higher fee which sends the coins back to themselves (or otherwise makes a payment).

2
  • Thanks for your answer @Antoine. The last part with RBF makes sense and I understand it. For the first part, I am not quite sure, I understand. If I wait for the funding transactions to confirm and only then try to collaborate to construct the redeem transaction, I can still be stuck in the multisig. I would need to have a valid redeem transaction before I am willing to even send money into the multisig, or no?
    – Neo
    Commented Jun 4 at 10:44
  • Yes, well that's the scheme you described? If the tx confirms, any party can unilaterally get back their coins. You asked whether it was the same if the transaction does not, which is why i detailed how it's the same in this case. Commented Jun 4 at 11:14
0

I think I found the answer to my question in the Bitcoin Lightning white paper. Section 3.1.1 ff explains it very well.

Here is the link: Lightning White Paper

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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