1

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.

  • 1
    Are you the creator of both A and B, or do you only have control over the creation of A? – Jestin Apr 29 '16 at 13:34
  • 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. – morsecoder Apr 29 '16 at 18:28
  • @Jestin: No, you're only the creator of A, and B already exists when you want to create A. – Murch Apr 29 '16 at 18:38
  • @StephenM347: Good question. I've added some background information to the post. – Murch Apr 29 '16 at 18:39
2
+50

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.

  • 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 Feb 20 '17 at 6:53
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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.