Add script_pubkey field to TxInput message #1857
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signing Taproot UTXOs involves computing the new BIP341 hash, which hashes all previous scriptPubKeys, not just the one we are signing. If we own the input, then we can (and should) derive its scriptPubKey inside Trezor. If it's an external input, then we need the scriptPubKey to be supplied. We can already do that with the present API by requesting the corresponding
PrevOutput
, i.e. just the one previous output, not the entire previous transaction. An alternative is to change the API by adding ascript_pubkey
field to theTxInput
message, which will have to be filled in for external inputs only. We have decided to go with the latter option. For the record, the reasons considered are summarized below.Reasons to keep the API as is:
PrevOutput
message will be needed only for external inputs (once for signature hashing and once for verification of externality). Apparently the only disadvantage is that in CoinJoin it will mean2*(N-1)
extra messages during signing, whereN
is the number of participants, which seems acceptable.script_pubkey
toTxInput
we increase the maximum size of the message by another 520 bytes.TxInput
is already the biggest message type we have with a theoretical maximum size of 7767 bytes and a practical maximum of ~4000 bytes.PrevOutput
solution seems nicer from a defensive coding point of view. we wouldn't need to check yet another optional field, we're guaranteed that an attacker isn't slipping in a value that gets accidentally used when it shouldn't, etc.Reasons to add the
script_pubkey field
to theTxInput
message:PrevOutput
message handling if they only sign Taproot inputs.TxInput
we already have fields likewitness
andownership_proof
which have very similar rules, e.g.ownership_proof
may be present only for external inputs. The main difference between the addition of these fields and the question of addingscript_pubkey
is that there exists an alternative way to getscript_pubkey
viaPrevOutput
.TxInput
already has the fieldamount
, which also wouldn't have to be there and could be obtained viaPrevOutput
. The main difference betweenamount
andscript_pubkey
is thatamount
is mandatory for every input whereasscript_pubkey
only for external inputs.legacy
, where requesting thePrevInput
means adding a new state to the state machine.