Taking the existing INPUT and changing the OUTPUT to steal bitcoins. Is this a possible bitcoin theft scenario and how to prevent it?

Question

I'm relatively new to Bitcoin and I'm wondering how Bitcoin defends against the following scenario and if it's even possible.

Before I start with the scenario, just two notes:

1. There is a lot of text because I just tried to explain in detail what I mean.

2. Please note that I am relatively new to bitcoin

So let's start.

Suppose we have an initial transaction (T1) from which everything starts. This transaction has been part of the blockchain for some time and has the following 2 inputs and 3 outputs. So we can write this transaction as follows:

T1(T1I1, T1I2; T1O1, T1O2, T1O3)

To spend funds from any of these outputs it is necessary to solve cryptographic puzzle set by locking script in corresponding output. For example, if we want to spend funds from T1O2, we will need to create an input in a new transaction with an unlocking script that solves the cryptographic puzzle set by T1O2.

Now, let's say someone who knows how to solve all these cryptographic puzzles wants to spend outputs 2 and 3 from the previous transaction (T1). So a new transaction will be created and, for example, it will look like this:

T2(T2I1, T2O2; T2O1, T2O2)

• T2I1 solves the cryptographic puzzle from T1O2
• T2I2 solves the cryptographic puzzle from T1O3

Also, let's assume that the fee for this transaction is set to 1 BTC which means that this transaction will be accepted within 6 blocks (this is a very high fee, but for simplicity I put 1 BTC). So, with this assumption, the transaction is put into the mempool and will be accepted in the next, say, 1-2 hours.

Now we come to the crux of the whole story. Suppose a hacker has access to the mempool and monitors all new transactions. As he watches, he notices our transaction T2 and wants to steal funds from it, that is, from T1 whose funds transaction T2 is consuming. He can't do this in the normal way because he is unable to solve the cryptographic puzzles from the outputs O2 and O3 in T1, so he can't make "valid" inputs. He also can't steal funds using the outputs from T2 because he doesn't know the solution to these cryptographic puzzles either. But what he can do is the following (I guess he can, that's my question). The procedure that the hacker does is presented in steps

1. Since the hacker does not know how to create unlocking scripts to solve the cryptographic puzzles set by locking scripts in the outputs of transaction T1, he will just take the solutions (inputs, unlocking scripts) from T2. Let's say he only takes the first input (T2I1).

2. After that, he creates new outputs with locking scripts that he will know how to solve.

3. Since he has inputs and outputs, he creates a transaction that will look like this:

   T3(T2I1, T3O1)

• input T2I1 hacker took from valid transaction T2
• output T3O1 he just created with locking script he knows solution to

4. Hacker now takes this transaction and sends it through the bitcoin network and sets the fee at 5 bitcoins (5 times the original transaction) which ensures that the transaction is immediately accepted in the next block.

These steps lead to the fact that there are two conflicting transactions in the mempool because they consume the same input (T2I1). When a miner creates a new block, he will select a set of transactions to include in the new block based on the fee. Since a malicious transaction (hacker transaction) has a high fee, it will be immediately included in the next block. In this way, a hacker's transaction is one that is included in the blockchain and its outputs (for which he knows the solution) become part of the blockchain, while a valid transaction and those outputs are discarded as malicious. By doing so, he stole bitcoins.

Based on everything written, I have two questions:

1. Is this a possible scenario?

2. How does Bitcoin defend against this scenario?

Answer 1

The digital signatures which are included in a transaction input to authorize the spending commit to (largely) the entire spending transaction. If any part of it changes (including which outputs are spent by it, or where the resulting funds are sent), the signatures are invalidated.

The "cryptographic puzzles" you refer to, if we ignore the script system, boil down to a cryptographic primitive called a digital signature. It is a collection of 3 algorithms:

• KeyGen(): generate a private key with corresponding public key
• Sign(message, private_key): given a message to sign, and a private key to sign with, produce a signature.
• Verify(message, public_key, signature): given a message that was allegedly signed, a public key, and a signature, verify if that signature was created by the corresponding private key on that message.

The key generation is generally handled by key derivation logic, which you've already been asking about here. The signing/verify functions come from ECDSA (for pre-segwit, or segwit v0) or from BIP340 (for segwit v1). The message argument is important here: when the message changed between signing and verifying, verification will (almost certainly) fail. If an attacker can construct a signature on a different message than messages they've already seen signed, without access to the private key, we consider the signature scheme broken. ECDSA and BIP340 are, as far as we know, not broken.

In the context of Bitcoin transactions, this message is called the "sighash". The details are somewhat complicated, but slightly simplified, it consists of most of the fields of the spending transaction (so the transaction which contains the signatures).

If an attacker takes a valid transaction's inputs, and reconstructs a new transaction with different outputs with those same inputs, the signatures won't verify anymore, because some of the message being signed changed.