<p><a href="https://twitter.com/_benma_/status/1268736105127579648?s=20" rel="nofollow noreferrer">Answered on Twitter</a></p>

<blockquote>
  <p>The hash of the provided prevtx must match the prevtx hash given in the input. The attacker is unable to construct a fake prevtx that hashes to a predefined value. The prevtx hash in the input cannot be changed either, otherwise the network will reject the tx.</p>
</blockquote>

<p>Basically, you can't create fake previous transactions because that would require producing a sha256 collision, which we assume can't happen.</p>

CC BY-SA 4.0
2020-06-05T02:51:27.413Z
2020-06-05T03:34:09.557Z
2020-06-05T03:34:09.557Z
justinmoon
<p>Yesterday Trezor released details of a <a href="https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd" rel="noreferrer">segwit-related hardware wallet vulnerability</a>.</p>

<p>The writeup claims that providing full previous transactions to the hardware wallet prevents the exploit.</p>

<p>My question: Why can't the compromised desktop software provide fake previous transactions corresponding to the fake inputs?</p>

<p>Using the example in the writeup:</p>

<ul>
<li>In "step 2", create a fake transaction containing an output spent by "input 2" with value  5.00000001 BTC and same outpoint as the 20BTC UTXO.</li>
<li>In "step 5", create a fake transaction containing an output spent by "input 1" with value 0.00000001 BTC and same outpoint as the 15BTC UTXO.</li>
</ul>

<p>The offline signer couldn't know that these fake transactions aren't on the blockchain. Most hardware wallets don't show information about the UTXOs being consumed so the user couldn't catch it by inspection. Does the fix involve incompatible sighash values for the two rounds?</p>

CC BY-SA 4.0
2020-06-05T01:58:30.967Z
The attack vector seems very edge case, I'm also interested in more details regarding the proposed fix.
m1xolyd1an
<segregated-witness><bip174-psbt>
Segwit & Offline Signing
justinmoon
# Segwit & Offline Signing

(Asked by: username_0 on 2020-06-05)

Yesterday Trezor released details of a [segwit-related hardware wallet vulnerability](https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd).

The writeup claims that providing full previous transactions to the hardware wallet prevents the exploit.

My question: Why can't the compromised desktop software provide fake previous transactions corresponding to the fake inputs?

Using the example in the writeup:

* In "step 2", create a fake transaction containing an output spent by "input 2" with value 5.00000001 BTC and same outpoint as the 20BTC UTXO.
* In "step 5", create a fake transaction containing an output spent by "input 1" with value 0.00000001 BTC and same outpoint as the 15BTC UTXO.

The offline signer couldn't know that these fake transactions aren't on the blockchain. Most hardware wallets don't show information about the UTXOs being consumed so the user couldn't catch it by inspection. Does the fix involve incompatible sighash values for the two rounds?

**Tags:** segregated-witness, bip174-psbt

> **Comments:**
> **username_1**: The attack vector seems very edge case, I'm also interested in more details regarding the proposed fix.  

---

## 1 answers

### Answer by username_0 on 2020-06-05. Score: 4

[Answered on Twitter](https://twitter.com/_benma_/status/1268736105127579648?s=20)

> The hash of the provided prevtx must match the prevtx hash given in the input. The attacker is unable to construct a fake prevtx that hashes to a predefined value. The prevtx hash in the input cannot be changed either, otherwise the network will reject the tx.

Basically, you can't create fake previous transactions because that would require producing a sha256 collision, which we assume can't happen.


---

