arno/trezor-firmware
1
0
Fork 0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-11-17 21:22:10 +00:00
Code Issues Releases Wiki Activity

docs: Update transaction signing documentation.

Browse Source
This commit is contained in:
Andrew Kozlik 2021-11-18 19:22:58 +01:00 committed by Andrew Kozlik
parent 7b7aa2d971
commit ff7d5c224b
1 changed files with 18 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/common/communication/bitcoin-signing.md
View File

@ -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