Shield Support

[Duddino]

Abstract

This PR adds Shield capabilities to MPW.
When a user imports a seedphrase, a new spending key is generated, following the zip32 protocol.
Using the key, the user is able to view the balance, receive and spend Shield PIVs, including shielding and deshielding to self.

Limitations:

• Sapling parameters must be downloaded when a user wants to make shield transactions. They are not needed for viewing the balance.
  Currently, they're being hosted over on https://duddino.com/sapling-spend.params and https://duddino.com/sapling-output.params.
  The parameters can be cached so that they will be downloaded only once per device.
• Each client needs to download all shield blocks, since we can't send the viewing key over the network.
  This sync time can be shortened by the use of checkpoints; However, only checkpoints older than the wallet creation time can be safely used, otherwise the wallet might miss some notes/nullifiers, missing some funds at best, or making it unusable at worst.
  Currently, this is not a big deal, because we can assume that the latest checkpoint is good, since it has been created before MPW had the capability of making shield transactions, however this might become a problem in the future, as more blocks are created.
• Shield transactions may take a long time to prove, especially on slower devices like mobile phones.
  This is a limitation of web assembly. Multithreaded support was added, however for it to work, HTTP headers must be set to the following values:

            'Cross-Origin-Embedder-Policy': 'require-corp',
            'Cross-Origin-Opener-Policy': 'same-origin',

They have been enabled on netlify and the dev server.
If these headers are set to different values, the UI thread will be blocked and the loading bar will not work.

Privacy implications

• A malicious explorer could tie a shield transaction to a specific IP, this can be mitigated by using a VPN, tor or self hosting.
• A malicious explorer could somehow fingerprint a client based on the sync activity, for example: The explorer sees a request for block 100 to 200 (current block at the time). A day later, there is another request for block 200 to 300. The malicious explorer could assume that it's the same client making the requests, even if the IP address changes.
  This can be mitigated by self hosting, or randomly choosing an explorer when syncing.
  It's important to note that the more requests an explorer gets, the harder it is to "fingerprint" the requests.

Only selected explorers are whitelisted to be used on the official instance of MPW, and it's unlikely that any of them are logging information, however if a user needs absolute privacy, it's best if they self host. In the near future, a docker image will be provided with each release to make self hosting easy.

Things not covered in this PR:

• Memos

Testing

• Test that you can receive (via Shield address) and send shield PIV (using Use Shield inputs in the Send menu).
• Test that you can de-Shield PIV by sending them to a transparent address.
• Test that you can Shield your PIV by sending them to your own Shield address.
• Test importing your seed on various devices, and that your Transparent and Shield balances are correct after syncing.

Tests are not passing due to a missing key in the pivx-shield package.json.
To make them pass locally, add "main": "pivx_shield.js" to node_modules/pivx-shield/package.json after running npm ci.
This will be fixed next release.
Coauthored with @panleone

[netlify]

✅ Deploy Preview for cheery-moxie-4f1121 ready!

Name	Link
🔨 Latest commit	bf2f8f4
🔍 Latest deploy log	https://app.netlify.com/sites/cheery-moxie-4f1121/deploys/65bcf8698a8357000887b50c
😎 Deploy Preview	https://deploy-preview-244--cheery-moxie-4f1121.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[JSKitty]

tACK bf2f8f4

Happy with the stability of Shield at this point, with various random transactions it's appearing fairly fast for my hardware and also synchronising the balances accurately (even if a little slow, but this is largely due to Blockbook from my inspection).

UX enhancement will be done in a future PR as soon as this one is merged, LGTM as-is.

[Luke-Larsen]

tACK bf2f8f4

The shielding system seems to work really well from my testing on multiple browsers and system. With UX being worked on a different PR, I think this is ready to go

[Liquid369]

tACK bf2f8f4

testing has gone very well, i believe we are ready for the polishing up stages