What are the circular dependencies when signing an unconfirmed transaction chain?

What is a circular dependency if only tx1 depends on tx0?

Since tx1 depends on tx0, we need to know the txid of tx0 before creating and signing tx1. However, in traditional transaction formats (before segwit), the txid is known only after tx0 is signed. This is because the signature is included in the txid calculation. A signature contains random data, and the only way to predict its value is to create it. By creating a signature for tx0, you are also creating tx0 itself. To create tx1, you must create tx0. Otherwise tx1 cannot be created.

However, in this protocol, tx0 cannot be created until tx1 is created. If you do so, you are no longer guaranteed a refund. However, tx1 cannot be created until tx0 is created. So this is a circular dependency.

why? Shouldn’t the refund work if I broadcast tx0 and then broadcast tx1?

In tx1, tx0 must exist first for the txid to be known, so we can create and sign tx0 first. But once it exists, either party can broadcast it immediately.

For tx1 to be valid and broadcast it must be signed by both parties. However, it is possible for one party to act maliciously by refusing to sign the tx1 and thereby denying the refund. Therefore, no refund is guaranteed.