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.
