From ff7d5c224ba8997ff9a2c5315aec6faebc683a27 Mon Sep 17 00:00:00 2001 From: Andrew Kozlik Date: Thu, 18 Nov 2021 19:22:58 +0100 Subject: [PATCH] docs: Update transaction signing documentation. --- docs/common/communication/bitcoin-signing.md | 31 ++++++++++++-------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/docs/common/communication/bitcoin-signing.md b/docs/common/communication/bitcoin-signing.md index af45594c4..8c7a61aac 100644 --- a/docs/common/communication/bitcoin-signing.md +++ b/docs/common/communication/bitcoin-signing.md @@ -47,7 +47,7 @@ data structures that allow it to verify that the same data is sent in the follow phases. In this phase, Trezor will also ask the user to confirm destination addresses, -transaction fee, metadata, and the total being sent. If the user confirms, we continue +the transaction fee, metadata, and the total being sent. If the user confirms, we continue to the next phase. ### Validation of input data @@ -61,22 +61,27 @@ possible trailing data. This allows Trezor to reconstruct the previous transacti calculate its hash. If this hash matches the provided one, and the amount on selected UTXO matches the input amount, the given input is considered valid. -Trezor also supports pre-signed inputs for multi-party signing. If an input has an -`EXTERNAL` type, and provides a signature, Trezor will validate the signature against -the previous transaction in this step. +If all internal inputs are taproot, then the verification of the previous transactions +is skipped. This is possible because if the host provides invalid information about the +UTXOs being spent, then the resulting taproot signatures will also be invalid. -### Signing +Trezor T also supports pre-signed inputs for multi-party signing. If an input has script +type `EXTERNAL` and provides a signature, Trezor will validate the signature against the +previous transaction in this step. -Satisfied that all provided data is valid, Trezor will ask once again about every input -and generate a signature for it. +### Serialization and signing -For every legacy (non-segwit) inputs, it is necessary to stream the full set of inputs -and outputs again, so that Trezor can build the serialization which is being signed. -For segwit inputs, this is not necessary +Trezor will ask once again about every input and begin outputting a serialization of the +transaction. For every legacy (non-segwit) input, it is necessary to stream the full set +of inputs and outputs again, so that Trezor can compute the transaction digest which it +then signs. For segwit inputs this is not necessary. -Finally, when all inputs are streamed, Trezor will ask for every output, so that it can +When all inputs are serialized, Trezor will ask for every output, so that it can serialize it, fill out change addresses, and return the full transaction. +Finally Trezor asks again about segwit inputs to sign them and to serialize the +witnesses. + ## Old versus new data structures Originally, the `TxAck` message contained one field of type `TransactionType`. This, in @@ -132,7 +137,7 @@ set on `tx.input`. Usually, the user owns, and wants to sign, all inputs of the transaction. For that, the host must specify a derivation path for the key, and script type `SPENDADDRESS` (legacy), -`SPENDP2SHWITNESS` (P2SH segwit) or `SPENDWITNESS` (native segwit). +`SPENDP2SHWITNESS` (P2SH segwit), `SPENDWITNESS` (native segwit) or `SPENDTAPROOT`. #### Multisig inputs @@ -145,7 +150,7 @@ Full documentation for multisig is TBD. #### External inputs -Trezor can include inputs that it will not sign, typically because they are owned by +Trezor T can include inputs that it will not sign, typically because they are owned by another party. Such inputs are of type `EXTERNAL` and the host does not specify a derivation path for the key. Instead, these inputs must either already have a valid signature or they must come with an ownership proof. If the input already has a valid