update 110 (#162)

_updates/2023-05-17-update-110.md

@@ -0,0 +1,47 @@
+---
+layout: update
+tag: Developer Update
+date: 2023-05-17
+author: SW van Heerden
+thumbnail: update-background.jpg
+title: MimbleWimble and Hardware Support
+class: subpage
+---
+
+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](https://rfc.tari.com/RFC-0201_TariScript.html). 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](https://www.reddit.com/r/grincoin/comments/z39ebv/grin_ledger_hardware_wallet_support/) and [MimbleWimble Coin](https://github.com/mwcproject/ledger-mwc)
+while others like [beam](https://twitter.com/BeamCTO/status/1620333432751685632?lang=en) 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.