-
-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Taproot in Trezor T #1891
Taproot in Trezor T #1891
Conversation
Two high level notes:
|
In 21f0bf8 I expanded the corresponding code comment. I also switched the two branches of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
i have a bunch of style comments and a few questions I'd like clarified
plus the thing about signmessage path warnings
If I understand it correctly, it turned out that the conjecture written on Slack isn't true because of external inputs and replacement transactions. |
Not only that. Although the attack that was disclosed in June 2020 would not be feasible in it's original form, it would be feasible if in addition the attacker provided invalid information about the script types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, modulo sign_message which will be resolved by rebasing
- Refactor TxWeightCalculator to count inputs and outputs itself. - Fix witness data weight by adding the weight of the witness stack item count for each input in segwit transactions and removing the weight of the nonsensical extra inputs count. - Get multisig pubkey count from multisig.nodes or multisig.pubkeys like in multisig_get_pubkeys(). - Fix size of multisig script length encoding in segwit (varint vs. OP_PUSH). - Improve comments.
After fixing the TxWeightCalculator the approver needs to account for the weight of the coordinator's output.
…() with two functions.
3fe330e
to
44ea5e4
Compare
This PR implements the main Taproot functionality (#1656) in trezor-core, and fixes some bugs that I stubled on along the way:
GetAddress
for Taproot.Hash143
toSigHasher
and replacespreimage_hash()
with two functionshash143()
andhash341()
.SignMessage
if a non-standard path is used, e.g. GreenAddress or Casa. This is not critical, but seems reasonable to do simply for consistency with how other messages are treated. Once we implement Taproot message signing this will probably become more important, see below.OP_PUSH
writing.TxWeightCalculator
and adds unit tests which would have caught them. I also added support for external inputs inTxWeightCalculator
. After these fixes the CoinJoin approver needs to account for the weight of the coordinator's output when considering the fair distribution of the fees, which also required a fix.This PR does not implement any Taproot functionality in trezor-legacy. It also does not implement any of the following in trezor-core:
One item that is open for discussion is how to behave when a Taproot path is used with ECDSA or when a non-Taproot path is used with Schnorr signatures. The current implementation will only show an "unknown path" warning dialog in these cases. Using the same key in two different algorithms is generally not recommended, at least not without deeper analysis. As far as we known there is no known attack when using the same private key in ECDSA and Schnorr [1], [2], [3]. We could be more strict and allow these scenarios only if safety checks are disabled. On the other hand I am not sure yet how Taproot message signing works in bitcoin-core. If it allows using ECDSA, then being strict in Trezor might pose a problem.
@onvej-sl please review the changes in the C code (trezor-crypto and the trezorcrypto.bip340 module) and review the rest of the code from a security perspective.
@matejcik please review the Python code overall (design, security, etc.).
[1] https://bitcoin.stackexchange.com/a/107928
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018384.html
[3] https://crypto.stackexchange.com/questions/54660/is-it-safe-to-use-same-private-key-in-two-or-more-ec-signature-algorithms