<p>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.</p>

<p>Here are three partial-solutions:</p>

<ol>
<li><p>To state the obvious, you could simply wait until B is confirmed to publish A.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>

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

<hr>

<p>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:</p>

<p>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 <code>scriptSig</code> and spend another output to provide some fees.</p>

<p>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. </p>

<p>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 <code>B</code>, 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 <code>B</code> 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.</p>

CC BY-SA 3.0
2017-02-20T06:53:28.163Z
The bribe transaction could itself include an OP_TRUE output, so if someone else wants to add a second bribe, they can spend the output of the first bribe; and they can include an OP_TRUE of their own and repeat ad infinitum.  This gets awkward if the censored transaction is very popular, because the bribes may step on each other.  Or, each one contains several OP_TRUE outputs; now the number of available places to hang a bribe grows exponentially.
Nate Eldredge
CC BY-SA 3.0
2016-04-29T18:35:19.073Z
2016-04-29T18:58:39.430Z
2016-04-29T18:58:39.430Z
morsecoder
<p>The only way to do it - is to flood the network with transactions with higher priority and/or with SIGOPs-attack</p>

CC BY-SA 3.0
2016-04-29T19:35:35.227Z
2016-04-29T19:35:35.227Z
amaclin
<p>Let's say A create a multisig tx.<br>
A sign it a transfer the raw tx to an oracle.<br>
The oracle listen network, check if B is included in a block.<br>
If B is included, the oracle will sign A tx then send it to the network.</p>

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

CC BY-SA 3.0
2016-04-29T10:21:25.070Z
2016-04-29T10:21:25.070Z
onepix
<p><strong>Is there a way to create a transaction <code>A</code> that cannot be confirmed until <code>B</code> has been included in a block, although <code>A</code> does not build on any UTXO <code>B</code> creates?</strong></p>

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

<hr>

<p>Background:<br>
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 <code>A</code> that would only become spendable in the event of a confirmation for the censored transaction <code>B</code>, i.e. lending your fee as additional financial incentive for some miner to include <code>B</code> and break the censorship.<br>
I was wondering whether that would actually be possible. Sorry, I wasn't able to find the thread.</p>

CC BY-SA 3.0
2016-04-29T13:34:51.433Z
Are you the creator of both `A` and `B`, or do you only have control over the creation of `A`?
Jestin
CC BY-SA 3.0
2016-04-29T18:28:33.393Z
Out of curiosity, what problem are you trying to solve, where the possibility of referencing previous outputs is not available? If it's not just a pure curiosity question, this may be a case of Nick ODell's favorite [XY problem](http://xyproblem.info/).
morsecoder
CC BY-SA 3.0
2016-04-29T18:38:40.183Z
@Jestin: No, you're only the creator of `A`, and `B` already exists when you want to create `A`.
Murch
CC BY-SA 3.0
2016-04-29T18:39:06.293Z
@StephenM347: Good question. I've added some background information to the post.
Murch
<transactions><script><transaction-selection>
Is there a way to create a transaction that it can only be confirmed after another unrelated transaction has been confirmed?
Murch
# Is there a way to create a transaction that it can only be confirmed after another unrelated transaction has been confirmed?

(Asked by: username_0 on 2016-02-21)

**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.

**Tags:** transactions, script, transaction-selection

> **Comments:**
> **username_1**: Are you the creator of both `A` and `B`, or do you only have control over the creation of `A`?  
> **username_2**: Out of curiosity, what problem are you trying to solve, where the possibility of referencing previous outputs is not available? If it's not just a pure curiosity question, this may be a case of Nick ODell's favorite [XY problem](http://xyproblem.info/).  
> **username_0**: @username_1: No, you're only the creator of `A`, and `B` already exists when you want to create `A`.  
> **username_0**: @StephenM347: Good question. I've added some background information to the post.  

---

## 3 answers

### Answer by username_2 on 2016-04-29. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_3**: The bribe transaction could itself include an OP_TRUE output, so if someone else wants to add a second bribe, they can spend the output of the first bribe; and they can include an OP_TRUE of their own and repeat ad infinitum.  This gets awkward if the censored transaction is very popular, because the bribes may step on each other.  Or, each one contains several OP_TRUE outputs; now the number of available places to hang a bribe grows exponentially.  

---

### Answer by username_4 on 2016-04-29. Score: 0

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


---

### Answer by username_5 on 2016-04-29. Score: 0

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.


---

