feat: hardware wallet transactions #98

SWvheerden · 2023-05-17T14:22:47Z

Description

Intial draft for hardware wallet transactions.

Motivation and Context

How Has This Been Tested?

src/RFC-0205_LedgerTransactions.md

AaronFeickert · 2023-05-17T21:18:08Z

What should be the relationship between this RFC and the existing RFC-0204 (which discusses interactive and "legacy" one-sided outputs) and RFC-0203 (which discusses stealth one-sided outputs)?

AaronFeickert · 2023-05-18T16:40:11Z

src/RFC-0205_LedgerTransactions.md

+### Receiving one-sided-stealth
+`TODO`
+
+### Output recovery


Perhaps worth noting that this process only works for interactive outputs.

For legacy one-sided outputs, the helper can watch for A in scripts (as you note elsewhere), but since it can't complete the DHKE required to decrypt the commitment opening, it can't assert the output is valid and must send it to the signer to be checked.

For stealth one-sided outputs, the helper can't do anything except send such outputs to the signer to be checked.

It's not ideal, but it's not terrible if the helper can at least make a note of all the places `` is found and then batch requests to signer when it's available. The UX would be "42 transactions received. Synch with your device to update the balance".

The synching would be pretty quick then.

That said, I think we'll hone in on a solution where we needn't go down this road.

Yeah, for legacy one-sided it's mostly a UX issue, and somewhat a "wait for the signer" issue. For stealth one-sided it's an entirely different problem that does not scale.

CjS77

I like it. Some discussion points and clarifying questions.

src/RFC-0205_LedgerTransactions.md

CjS77 · 2023-05-19T15:35:38Z

src/RFC-0205_LedgerTransactions.md

+\end{aligned}
+$$
+
+The blinding factor (\\( k_i \\) ) is used as a random nonce when creating the script key. This means the helper can create the public key without the signer present, and the signer can then at a later stage create the private key from the nonce. The key pair (\\( a, A \\) ) is the master key pair from the signer. The private key (\\( a \\) ) is kept secret by the signer at all times.


When you say "master key pair", does this mean that the same a is used for every transaction?

Yes, it would be.

yeah, it needs to be for the helper to calculate the Public receive address.

Is there any benefit in doing addition instead of DH?

It's faster, and there's no need to do ECDH for this use case.

src/RFC-0205_LedgerTransactions.md

CjS77 · 2023-05-19T15:42:58Z

src/RFC-0205_LedgerTransactions.md

+### Receiving one-sided-stealth
+`TODO`
+
+### Output recovery


It's not ideal, but it's not terrible if the helper can at least make a note of all the places `` is found and then batch requests to signer when it's available. The UX would be "42 transactions received. Synch with your device to update the balance".

The synching would be pretty quick then.

That said, I think we'll hone in on a solution where we needn't go down this road.

CjS77 · 2023-05-19T15:46:01Z

src/RFC-0205_LedgerTransactions.md

+### Process Overview
+By splitting the ownership of the [UTXO]'s secret by assigning knowledge of only the script key (\\( k_s \\) ) to the signer, we can lift much of the heavy cryptography like bulletproof creation to the helper device by exposing (\\( k_i \\) ) to it. By looking at how [one-sided-stealth] transactions are created, we can construct the script key in such a way that the helper can calculate the public script key, but cannot calculate the private script key.
+
+All [UTXO]s created will be created with a script `PushPubkey(K_S)`. The key (\\( k_s \\) ) is created as follows:


I gather, from the discussion below, that you mean to say that we must update the protocol to deprecate the current NOP default script so that there's always a script key present?

No, only change the default behaviour in the default implementation.
The No-Op script is still useful to have.
Currently, we use No-Op in all default interactive transactions. that's all I propose we change

CjS77 · 2023-05-19T15:49:13Z

src/RFC-0205_LedgerTransactions.md

+
+### Output recovery
+When creating outputs the wallet encrypts the blinding factor (\\k_i \\) and value \\( v \\) with (\\( k_H \\) ).
+Because the key (\\( k_H \\) ) is calculated from the seed phrase of the signer, this will be the same each time. The helper can try to decrypt each scanned output, when it is successful it knows it has found its own output. 


Are a and k_H the same thing?

No, k_H is a fixed helper key derived from a that's used for encrypting commitment openings. The signer provides it once to the helper, who can then use it for AEAD operations.

CjS77 · 2023-05-19T15:55:06Z

src/RFC-0205_LedgerTransactions.md

+
+### Output recovery
+When creating outputs the wallet encrypts the blinding factor (\\k_i \\) and value \\( v \\) with (\\( k_H \\) ).
+Because the key (\\( k_H \\) ) is calculated from the seed phrase of the signer, this will be the same each time. The helper can try to decrypt each scanned output, when it is successful it knows it has found its own output. 


So it's a bit worrying to use the same key every time from a security perspective.

Could we perhaps use a strategy similar to the one in BIP-32 for deriving an infinite number of A' from a single parent private key (signer) or the parent public key (helper)?

There's no security problem here. Encrypted openings use an extended nonce whose entire purpose is to allow for safe key reuse with random nonce sampling. And this key reuse allows for super-fast interactive output scanning during recovery.

Also, the wallet public key A doesn't play any role in AEAD decryption during recovery. It only comes into play when testing for offset script public keys, and in that case, there's already a hash-based offset applied that masks the fixed A.

CjS77

I like it. Some discussion points and clarifying questions.

Co-authored-by: Cayle Sharrock <CjS77@users.noreply.github.com>

stringhandler

I think it's worth adding a section on generic TariScripts that are not one-sided, e.g. HTLC

src/RFC-0205_LedgerTransactions.md

stringhandler · 2023-05-22T08:44:32Z

src/RFC-0205_LedgerTransactions.md

+
+## Background
+
+Vanilla [Mimblewimble] only has a single secret per [UTXO], the blinding factor (\\( k_i \\) ), the Tari protocol extends the [Mimblewimble] protocol to include scripting in the form of [TariScript]. This adds a second secret per [UTXO] called the script_key (\\( k_s \\) ). In practical terms this means that while vanilla [Mimblewimble] only requires that a wallet wishing to spend an [UTXO], prove knowledge of (\\( k_i \\) ) by producing the kernel signature, this is not sufficient for Tari. A Tari wallet must also prove knowledge of the script key (\\( k_s \\) ), by producing the script signature. 


Is this true even for Nop scripts?

Practically No, Technically yes.
A No-Op script that just contains the No-Op operation accepts any input.

So from the wallet submitting the tx, it can submit any Public key as input, and it's still valid. But it still needs to prove it knows the secret key of that public key.

But from the prover side, aka base_node, it just runs, the script and verifies the signature, thus proving knowledge of the script key k_S. How the key was calculated from the script the Base_node does not care.

stringhandler · 2023-05-22T08:46:33Z

src/RFC-0205_LedgerTransactions.md

+
+To properly implement hardware wallets we need the following requirements to be met:
+* No UTXO can be spent without a user physically approving the transaction on the hardware wallet.
+* Users need to verify transaction properties when signing for transactions.


Are you referring to the display of the transaction on the HW wallet?

src/RFC-0205_LedgerTransactions.md

stringhandler · 2023-05-22T08:57:52Z

src/RFC-0205_LedgerTransactions.md

+\end{aligned}
+$$
+
+The blinding factor (\\( k_i \\) ) is used as a random nonce when creating the script key. This means the helper can create the public key without the signer present, and the signer can then at a later stage create the private key from the nonce. The key pair (\\( a, A \\) ) is the master key pair from the signer. The private key (\\( a \\) ) is kept secret by the signer at all times.


Is there any benefit in doing addition instead of DH?

src/RFC-0205_LedgerTransactions.md

stringhandler · 2023-05-22T09:07:36Z

src/RFC-0205_LedgerTransactions.md

+
+### Receiving normal one-sided transaction
+This can be done by the helper asking the signer for a public key. And advertising this public key as the destination public key for a 1-sided transaction. 
+The helper can scan the blockchain for this public key. 


What happens to the wallet's Tari Address? Is this not related?

Currently, the wallet calculates the Public script key for the script from the wallet's Tari Address. The only reason that is used is that it's an easily known key that the wallet has the secret key to. So we use that key in place of the TariAddress

stringhandler · 2023-05-22T09:08:37Z

src/RFC-0205_LedgerTransactions.md

+The helper can scan the blockchain for this public key. 
+
+### Receiving one-sided-stealth
+`TODO`


Just adding a marker here. DNM until resolved

As far as I see it, this is no different from normal (public) one-sided transactions

Co-authored-by: stringhandler <stringhandler@gmail.com>

src/RFC-0205_HardwareTransactions.md

AaronFeickert · 2023-05-24T14:13:12Z

src/RFC-0205_HardwareTransactions.md

+* Helper: This entity is the program that helps the signer construct the transaction, send it over the network and scan the network, aka wallet.
+
+### Process Overview
+By splitting the ownership of the [UTXO]'s secret by assigning knowledge of only the script key (\\( k_s \\) ) to the signer, we can lift much of the heavy cryptography like bulletproof creation to the helper device by exposing (\\( k_i \\) ) to it. By looking at how [one-sided-stealth] transactions are created, we can construct the script key in such a way that the helper can calculate the public script key, but cannot calculate the private script key.


Some context on what a UTXO's "secret" is could be helpful here. Really it's two secret values: the commitment mask and the script private key. (The value is private too, but can be easily brute forced and therefore not as relevant.)

It is discussed two paragraphs up?

src/RFC-0205_HardwareTransactions.md

AaronFeickert

There are a few spots where the math-mode separators are written incorrectly, meaning not all math renders properly.

src/RFC-0205_HardwareTransactions.md

Co-authored-by: Brian Pearce <brianp@users.noreply.github.com>

add extra requirement

add mention of provider requirements

SWvheerden added 2 commits May 17, 2023 16:21

wip ledger draft

8f3e489

grammer and spelling

727449e

This was referenced May 17, 2023

feat!: proof offloading tari-project/bulletproofs-plus#29

Closed

[WIP] ledger compat tari-project/bulletproofs-plus#24

Closed

Computational offloading tari-project/bulletproofs-plus#27

Closed

feat: add optional range proof types tari-project/tari#5372

Merged

AaronFeickert suggested changes May 17, 2023

View reviewed changes

ghpbot-tari-project added P-acks_required P-reviews_required labels May 17, 2023

AaronFeickert reviewed May 17, 2023

View reviewed changes

src/RFC-0205_LedgerTransactions.md Outdated Show resolved Hide resolved

AaronFeickert mentioned this pull request May 17, 2023

RFC-0204/TariScriptExamples references deprecated range proof rewinding #83

Open

review

31254c6

AaronFeickert mentioned this pull request May 18, 2023

Remove internal value/mask AEAD KDF tari-project/tari#5393

Closed

AaronFeickert reviewed May 18, 2023

View reviewed changes

CjS77 reviewed May 19, 2023

View reviewed changes

CjS77 changed the title ~~feat: HW transactions~~ feat: hardware wallet transactions May 19, 2023

SWvheerden and others added 2 commits May 22, 2023 10:15

Update src/RFC-0205_LedgerTransactions.md

a016f03

Co-authored-by: Cayle Sharrock <CjS77@users.noreply.github.com>

Update src/RFC-0205_LedgerTransactions.md

07db5bc

Co-authored-by: Cayle Sharrock <CjS77@users.noreply.github.com>

fix review comment

2f87243

stringhandler reviewed May 22, 2023

View reviewed changes

SWvheerden and others added 5 commits May 22, 2023 11:51

Update src/RFC-0205_LedgerTransactions.md

f1fc202

Co-authored-by: stringhandler <stringhandler@gmail.com>

Update src/RFC-0205_LedgerTransactions.md

f1e1b0d

Co-authored-by: stringhandler <stringhandler@gmail.com>

Update src/RFC-0205_LedgerTransactions.md

e23704a

Co-authored-by: stringhandler <stringhandler@gmail.com>

Update src/RFC-0205_LedgerTransactions.md

aab475b

Co-authored-by: stringhandler <stringhandler@gmail.com>

rename rfc

52ab8a2

AaronFeickert reviewed May 24, 2023

View reviewed changes

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

AaronFeickert reviewed May 24, 2023

View reviewed changes

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

AaronFeickert reviewed May 24, 2023

View reviewed changes

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

SWvheerden mentioned this pull request Jul 3, 2023

Create a simple NewBlockTemplate that creates a block template and inserts the coinbase in one -- one sided coinbase tari-project/tari#4419

Closed

update hashes

d053068

AaronFeickert suggested changes Jul 17, 2023

View reviewed changes

update math

d1baeb8

AaronFeickert suggested changes Jul 17, 2023

View reviewed changes

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

minor edits

0d5faed

AaronFeickert approved these changes Jul 17, 2023

View reviewed changes

brianp reviewed Jul 18, 2023

View reviewed changes

src/RFC-0205_HardwareTransactions.md Outdated Show resolved Hide resolved

Update src/RFC-0205_HardwareTransactions.md

e125840

Co-authored-by: Brian Pearce <brianp@users.noreply.github.com>

SWvheerden mentioned this pull request Aug 21, 2023

feat: ledger key manager interface tari-project/tari#5644

Merged

4 tasks

SWvheerden added 2 commits August 21, 2023 13:23

Update RFC-0205_HardwareTransactions.md

509cb87

add extra requirement

Update RFC-0205_HardwareTransactions.md

3ecbd82

add mention of provider requirements

CjS77 approved these changes Feb 11, 2024

View reviewed changes

CjS77 merged commit 584e997 into tari-project:main Feb 11, 2024
2 checks passed

SWvheerden deleted the sw_ledger branch April 22, 2024 14:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: hardware wallet transactions #98

feat: hardware wallet transactions #98

SWvheerden commented May 17, 2023

AaronFeickert commented May 17, 2023

AaronFeickert May 18, 2023

CjS77 May 19, 2023

AaronFeickert May 19, 2023

CjS77 left a comment

CjS77 May 19, 2023

AaronFeickert May 19, 2023

SWvheerden May 22, 2023

stringhandler May 22, 2023

AaronFeickert May 22, 2023

CjS77 May 19, 2023

CjS77 May 19, 2023

SWvheerden May 22, 2023

CjS77 May 19, 2023

AaronFeickert May 19, 2023

CjS77 May 19, 2023

AaronFeickert May 19, 2023

AaronFeickert May 19, 2023

CjS77 left a comment

stringhandler left a comment

stringhandler May 22, 2023

SWvheerden May 22, 2023

stringhandler May 22, 2023

SWvheerden May 22, 2023

stringhandler May 22, 2023

stringhandler May 22, 2023

SWvheerden May 22, 2023

stringhandler May 22, 2023

stringhandler May 22, 2023

AaronFeickert May 24, 2023

SWvheerden Jul 14, 2023

AaronFeickert left a comment


		## Background

		Vanilla [Mimblewimble] only has a single secret per [UTXO], the blinding factor (\\( k_i \\) ), the Tari protocol extends the [Mimblewimble] protocol to include scripting in the form of [TariScript]. This adds a second secret per [UTXO] called the script_key (\\( k_s \\) ). In practical terms this means that while vanilla [Mimblewimble] only requires that a wallet wishing to spend an [UTXO], prove knowledge of (\\( k_i \\) ) by producing the kernel signature, this is not sufficient for Tari. A Tari wallet must also prove knowledge of the script key (\\( k_s \\) ), by producing the script signature.

feat: hardware wallet transactions #98

feat: hardware wallet transactions #98

Conversation

SWvheerden commented May 17, 2023

Description

Motivation and Context

How Has This Been Tested?

AaronFeickert commented May 17, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CjS77 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CjS77 left a comment

Choose a reason for hiding this comment

stringhandler left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AaronFeickert left a comment

Choose a reason for hiding this comment