May 17, 2023

By SW van Heerden

MimbleWimble and Hardware Support

In MimbleWimble things work a little differently than other blockchains. In most blockchains, a transaction is sent to a public key. Users then scan the blockchain for their public keys and know when they have received a mined transaction from which they can spend the funds. They then use the private key to prove ownership when spending. In MimbleWimble things don’t quite work like that. Here you create your own output with a single-use key each time you receive a transaction. This means that when you and the sender talk to each other, you interactively work together to create a new transaction. The sender creates a proof that they are able to spend the UTXO, and the receiver creates a proof that no new coins have been received and that the chain balance still holds. This ensures that the transaction is blinded.

In the Tari network things work a bit differently since we have TariScript. Here we effectively have two secrets per UTXO, compared to the one per vanilla MimbleMimble. We have the blinding factor and the script key. If the spender cannot provide knowledge of both of these secrets, they cannot spend the UTXO. This means that a user can give out their blinding factor, and post it on the internet. And everybody can go look on the blockchain, and verify the output. But if someone does not have the script key they cannot unlock the output and spend it. While this is obviously a bad idea for privacy reasons, it’s doable and safe.

So what does this mean for hardware wallets? Hardware wallets already have support on other blockchains like Grin and MimbleWimble Coin while others like beam are in development. All of these blockchains work with the blinding factor as the secret to prove ownership. In practical terms, this has two big negatives for the hardware wallet: crypto complexity and online receive only. The crypto complexity comes from the fact that the hardware wallet now was to do all complex cryptography proofs like the bulletproof which can be very taxing for a low-power device. But the bigger downside is that you have to have the ledger signed in, and online at all times to receive funds. This means that you cannot safely store away the hardware wallet in a safe until such a time as you want to spend your funds.

Because in Tari we have the two secrets per UTXO, we can safely leave all the blinding factor generation, bulletproof generation, etc. for the normal wallet. As long as we attach a script to the UTXO with a claim script key known only to the hardware wallet we still force the requirement that the hardware wallet needs to sign the transaction before spending the UTXO. And if we are clever with the choice of the private script key, we allow the wallet application to pre-calculate the public key required to spend the UTXO without the need for the ledger to calculate the private key.

If assign a private key pair (a, A) to the Hardware wallet. The wallet can calculate a Diffie-Hellman shared secret as s = Hash(k * A). It can then calculate the public key required for the script as K_S = S + A When spending time comes around the hardware wallet needs to provide k_S = s + a

Because a is only known to the hardware wallet, the script secret key is only known to it and not the wallet, thus the one secret never leaves your hardware wallet, allowing you to receive transactions while your hardware wallet is safely stored away in your safe. This all means doing hardware wallet support on Tari is much easier, safer, and userfriendly.