Segregated Witness and TREZOR
Tags: Security, Trezor, Bitcoin, Featured Posts

Verifying Inputs

When composing a new transaction, the wallet has to request the information on previous outputs it received, to use them as inputs. However, the amount in the previous output is not explicitly given to the wallet. Instead, the wallet only knows the Transaction ID of the previous transaction and the position of the previous output inside of that transaction.

Alice’s Transaction will therefore look more like this, with no amounts in the inputs, but rather Transaction IDs and positions of previous outputs:

Alice's Transaction

Inputs Outputs

[TXID1, #0] [B, 10BTC]

[TXID2, #4] [A, 1.5BTC]

[TXID3, #2]

----------------------------------------- Calculating TXFEE

SUM=12BTC SUM=11.5BTC DIFF=TXFEE=0.5BTC // The transaction does not actually look like this.

The wallet can stream the value of these inputs/previous outputs from somewhere, but how can it know that the amount is correct? What if it was intercepted and modified by someone?

In addition, you have surely noticed that the transaction fee is not explicitly stated. It is implicitly given by the difference between the sum of all outputs and sum of all inputs. This unfortunately opens up an attack vector, where one of the inputs used is actually larger than the user expects, and thus the user can lose a significant amount of coins to the transaction fee. This is the so-called Fee Attack vector.

There is a way to protect your wallet from this attack; TREZOR and many other (hardware) wallets employ this method. Essentially, the wallet depends on cryptographic verification of the input — hashes, to confirm the correctness of the input value supplied.

The wallet calculates the hash of the previous transaction and compares it to the hash published with the transaction in the blockchain. If the hashes match, then the wallet can be certain that the amount to be used as an input was not modified.

Let’s go slower, one by one.

Consider the input N1. Assume the input was a part of transaction TXID1 and output #0. The transaction TXID1 might have looked something like this:

Transaction TXID1

Inputs Outputs

[TXIDa, #0] [N1, 3BTC]

[TXIDb, #2] [P4, 11.5BTC]

HASH:34b23ea....

----------------------------------------- Calculating TXFEE

SUM=15BTC SUM=14.5BTC DIFF=TXFEE=0.5BTC // The transaction does not actually look like this.

When composing a new transaction, the wallet will stream the previous transaction (TXID1) from the blockchain, and ask for the specific output #0 (first position) and its value. Once it receives the value, the wallet will start hashing then entire transaction. Only if the hash exactly matches the hash published (34b23ea….), then the wallet can be certain that the amount is correct; in this case 3 BTC.

The wallet has to do this for each and every input to be used for a new transaction.

Hardware Wallets: Limited Power

Verifying inputs is, in itself, not a problem. The verification process only reinforces the security of hardware wallets. The issues with this operation only arise when there is a large number of inputs in a new transaction, as the hardware wallet will have to calculate all of the hashes of previous transactions.

Hardware wallets do not, in comparison with a phone or a computer, have sufficient computational power to run through a large number of hashes quickly. This explains why some transactions might take a long time to be processed on TREZOR, especially in accounts with a large amount of small inputs.

This issue with limited power is further exacerbated by the fact that sighash operations (signature-hashing — different operation) scale quadratically and not linearly. This means that a transaction double in size will take four times as long to compute.

How Will SegWit Change This?

SegWit transactions are designed in such a way that allows hardware wallets to get rid of the verification process altogether. Why? Because SegWit transactions will include the value of previous outputs in the signature of the transaction. The wallet thus does not need to request the previous transactions nor hash them anymore, saving precious time for users.

It might seem to be a trivial change, but the security implications are large. The lower the amount of operations the hardware wallets need to do, the lower the probability of something going awry. As the value of the previous output to be used as input is already included in the signature of the previous transaction, there is no possibility of anyone modifying the input value.

Moreover, with SegWit, wallets do not sign each inputs separately anymore, but first they will hash all the inputs, and then sign the hash. With this method, the amount of operations the wallets have to do is decreased, and thus the transaction creation process is sped up. This also means that the quadratic difficulty of sighash operations is replaced by linear difficulty; doubling the size of the transaction will theoretically only double the computation time.

Should SegWit Be Activated?

From a hardware wallet’s perspective there is no reason to delay SegWit activation. In fact, for any user with a hardware wallet, which is probably the most secure device you can use to store your private keys in, the benefits SegWit activation should be obvious.

To reiterate, this article raises the merits of SegWit without mentioning its implications for the Blocksize debate. It also does not discuss the method of implementation: softfork or hardfork. Nonetheless, it is disappointing that this piece of code has not been activated yet due to political disagreements within the Bitcoin ecosystem, in conjunction with the inability to compromise.