Is there a way to create a transaction that it can only be confirmed after another unrelated transaction has been confirmed?

Question

Is there a way to create a transaction A that cannot be confirmed until B has been included in a block, although A does not build on any UTXO B creates?

B would have already been broadcast by another user at that point, and you'd only be able to control A.

---

Background:
I was following a discussion on reddit, where a user was entertaining the scenario that in the future a mining cartel might censor transactions. He suggested creating transactions A that would only become spendable in the event of a confirmation for the censored transaction B, i.e. lending your fee as additional financial incentive for some miner to include B and break the censorship.
I was wondering whether that would actually be possible. Sorry, I wasn't able to find the thread.

Answer 1

I assume A spending the UTXO of an intermediate transaction C, which spends a UTXO of B doesn't count as 'unrelated', as that's just two degrees of separation instead of one.

Here are three partial-solutions:

1. To state the obvious, you could simply wait until B is confirmed to publish A.

2. You could publish A with a lock time in the future and then update it at a regular interval with increasing sequences and extending the lock time each time, but that doesn't eliminate the possibility that earlier versions of A will get mined when their lock time expires. Then when B is mined you publish a new version of A without the lock time enabled.

3. If you only require that it doesn't affect the coins moving around in transaction B, You could add an output to B that doesn't have any coins in it, and is used only for the dependency tracking of transactions. This requires that you know that you plan to publish a dependent transaction, A, ahead of time though.

I think you'll find that there really isn't a good way to do what you are asking. Transaction dependencies are usually handled by referencing outputs of the previous transaction.

---

In terms of the scenario where you are trying to bribe miners to confirm transactions that they have been censoring, this is essentially trying to do Child-Pays-For-Parent with transactions that cannot reference outputs. While this is still not possible, you might be able to do something like this:

The community realizes that many transactions are being censored, and they want to pay miners to include their transactions. So everyone starts appending an extra OP_TRUE output to their transaction, with 0 coins in it. Then if you want to reward a miner for mining the transaction with an OP_TRUE output in it, you spend that output with an empty scriptSig and spend another output to provide some fees.

One downside to this is that a miner will only be able to accept one person's bribes, as there is only one OP_TRUE UTXO added. But, I think if Bitcoin gets to this point, then it will likely have failed.

You could also do an escrow, where you put coins into a 2-of-3 with you, the miner, and a trusted third party. If the miner mines B, then you sign the release transaction to take the coins out of escrow and give them to the miner. If the miner doesn't mine B after a certain amount of time, then you request that the trusted third party help you release your funds. This is a lot of work for a simple task, though.

Answer 2

Let's say A create a multisig tx.
A sign it a transfer the raw tx to an oracle.
The oracle listen network, check if B is included in a block.
If B is included, the oracle will sign A tx then send it to the network.

Keep it mind that an oracle in a another program "somewhere" and by working with it you trust a third party.

Answer 3

The only way to do it - is to flood the network with transactions with higher priority and/or with SIGOPs-attack