6

In Mastering Bitcoin on chapter 6 the Circular Dependencies issue described as following:

Many contract protocols for Bitcoin involve a series of transactions that are signed out of order. For example, Alice and Bob want to deposit funds into a script that can only be spent with signatures from both of them, but they each also want to get their money back if the other person becomes unresponsive. A simple solution is to sign transactions out of order:

Tx0 pays money from Alice and money from Bob into an output with a script that requires signatures from both Alice and Bob to spend.

Tx1 spends the previous output to two outputs, one refunding Alice her money and one refunding Bob his money (minus a small amount for transaction fees).

If Alice and Bob sign Tx1 before they sign Tx0, then they’re both guaranteed to be able to get a refund at any time. The protocol doesn’t require either of them to trust the other, making it a trustless protocol.

A problem with this construction in the legacy transaction format is that every field, including the input script field that contains signatures, is used to derive a transaction’s identifier (txid). The txid for Tx0 is part of the input’s outpoint in Tx1. That means there’s no way for Alice and Bob to construct Tx1 until both signatures for Tx0 are known—​but if they know the signatures for Tx0, one of them can broadcast that transaction before signing the refund transaction, eliminating the guarantee of a refund. This is a circular dependency.

  1. What is the circular dependency here if only tx1 depends on tx0?
  2. "one of them can broadcast that transaction before signing the refund transaction, eliminating the guarantee of a refund" - Why? If after broadcasting tx0 we broadcast tx1 the refund should work, isn't it?

2 Answers 2

8

What is the circular dependency here if only tx1 depends on tx0?

Since tx1 depends on tx0, the txid of tx0 must be known before tx1 can be created and signed. However the legacy transaction format (prior to segwit), the txid could only be known once tx0 is signed. This is because the signature is included in the txid calculation. Signatures include random data and the only way to predict a signature's value is to create it. By virtue of creating signatures for tx0, you will have also created tx0 itself. In order to create tx1, you will have to have made tx0, otherwise it will not be possible to create tx1.

But in this protocol, tx0 cannot be created until tx1 is created as that would result in the refund no longer being guaranteed. However tx1 cannot be created until tx0 is created. Thus this is a circular dependency.

Why? If after broadcasting tx0 we broadcast tx1 the refund should work, isn't it?

Since tx1 requires tx0 to first exist so that the txid is known, you could create and sign tx0 first. But once this exists, either party could broadcast it immediately.

In order for tx1 to be valid and be broadcast, it must also be signed by both parties. However, one party could act maliciously by refusing to sign tx1, therefore denying the refund. Thus the refund is not guaranteed.

5
  • "So the txid of tx0 cannot be known in order to first create tx1" - why?
    – RafaelJan
    Commented Feb 21 at 18:53
  • I've updated my answer to clarify that.
    – Ava Chow
    Commented Feb 21 at 19:53
  • Thanks but still somthing is not clear to me. "But in this protocol, tx0 cannot be created until tx1 is created as that would result in the refund no longer being guaranteed" - why refund no longer being guaranteed?
    – RafaelJan
    Commented Feb 21 at 21:49
  • I think the second half of my answer addresses this part of your question.
    – Ava Chow
    Commented Feb 21 at 21:53
  • I think I get it and here is my summary: tx1 can't be built without tx0, but once we created tx0 the tx1 lost its power since it didn't sign yet and all the deal structure we wanted to build collapsed.
    – RafaelJan
    Commented Feb 21 at 22:52
3

In Bitcoin funds are tracked in the form of Unspent Transaction Outputs (UTXOs). When building a transaction you declare exactly which UTXO you are spending by providing the UTXO’s outpoint. The outpoint is combined from the transaction id of the transaction that created the output and the output’s index in the transaction’s output list.

On non-segwit inputs, the signature appears in the input script and is part of the data that the transaction id is derived from. Therefore, it’s infeasible to produce a child transaction that spends the output of the unsigned transaction, as the outpoint of the to-be-created UTXO cannot be predicted before the parent transaction is signed. Only after the parent transaction is signed, the outpoint is known and a child transaction can be crafted.

Many smart contract protocols such as Lightning depend on the participants having a guarantee that they will be able to reclaim their funds in case the counterparty becomes inactive. This is achieved by signing a child transaction that returns the funds to the original owners after some duration before the participants sign the parent transaction that commits the funds to the smart contract.

For segwit inputs, signatures appear in the witness section which does not contribute to a transaction’s txid and therefore it is possible to predict the child transaction before the parent is signed.

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.