Cryptocurrency Security Threats
Donate
This wiki page provides information on cryptocurrency security threats. The article discusses the use of QR codes, the best protection against theft, and multisig strategies. The page also lists specific rules to follow when using multisig for cryptocurrency storage, including the need to back up extended public keys (xpubs) and verifying the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
Introduction[edit]
Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.
QR codes[edit]
When scanning QR codes in context of an air gap wallet, use a QR code scanner or camera? Such as electrum running as watch-only wallet on an online computer while electrum offline
QR code scanner is supposedly working similar to a USB keyboard, i.e. technically implemented the same way a USB keyboard is implemented. What would be more trustworthy?
Best Protection from Theft[edit]
brain wallet + live system
Advantage: Access to spend funds stored in a brain wallet (a cryptocurrency recovery seed phrase memorized in human memory) combined with a live system (read-only) in theory cannot be stolen by stealing any storage devices (hard drives) or by offline forensics since data is never written to such devices in the first place.
Disadvantage: Higher risk of loss (forgotten seed phrase), difficult inheritance planning, no multisig.
Related: Live Mode.
multisig[edit]
To be able to restore a multisig setup every cosigner MUST backup all extended public keys (xpubs) (also known as Master Public Keys (MPKs)) of all cosigners as well as the derivation path. [1] For example, with a quorum of 2/4 setup:
Location 1: wallet seed 1, master pub key 2, master pub key 3, master pub key 4 Location 2: master pub key 1, wallet seed 2, master pub key 3, master pub key 4 Location 3: master pub key 1, master pub key 2, wallet seed 3, master pub key 4 Location 4: master pub key 1, master pub key 2, master pub key 3, wallet seed 4
It is highly recommended to exercise the multisig restoration process before relying on multisig for anything except test transactions.
Now let's talk some multisig...https://btcguide.github.io
, (@mflaxman
Rule #4: Verify the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
This is not 100% mandatory - but if you're no expert - you really should do it.
If a hardware wallet doesn't support displaying the xpub, (like Trezor), it could be fine to just verify each address on it - so long as you verify consistency on all other devices as well, but I wouldn't recommend such a device for non-experts.
Rule #5: Verify "receive" addresses on EVERY device of the multisig quorum. This is especially true for at least one address (see next rule) but recommended for all. If using a device that you haven't verified the xpub of on-screen, you should verify all receive addresses on it!
Rule #6: While it is best to verify each receive addresses on ALL devices in the multisig setup - you might choose to trust a specific one, verifying the xpub/ first address on all - then the rely only on the "trusted" device - ONLY IF YOU ALSO VERIFY XPUBS...
By that, I mean verify on the "trusted" hww used for general verification, that the xpubs are consistent for all cosigners. This is needed only once with wallets like ColdCard, Cobo Vault, Bitbox02, and Specter DIY - since they allow saving the multisig xpubs on the device. With Trezor T - you have to verify the xpubs of cosigners every time - which is why it's not recommended for that purpose - with Trezor One it's simply not possible...
So while you might use a Trezor in a multisig, I would not recommend it to non-experts.
Rule #7: Do NOT use Ledger in a multisig setup! (unless you are an expert or have a very good reason...)
Ledger currently does not allow verifying multisig addresses on the device - nor displaying the XPUB on its screen. This means you have no way to verify it was not swapped by an attacker in your multisig setup - EVEN IF YOU DO A SUCCESSFUL TEST TRANSACTION!
It is still possible for a (very) sophisticated attacker to make you think it worked, while it was him signing for you...
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and rely on that paper list for your day to day verification. This is very useful for multisig! - where devices might be distributed in various places.
Rule #9: Multisig change verification should be the same as with Rule #3 - on the device at the time of signing.
Popular devices (besides Ledger as said), can verify that the address you send from and the change address used belong to the same multisig wallet (from same xpubs). If they fail to verify the change address - they will show it as a standard, independent, recipient - in that case YOU SHOULD NOT MAKE THE TRANSACTION.
This is valid for both single sig and multisig! (although even more relevant for the latter).
Please note: Some things here might not be fully accurate for the expert user (especially around multisig address verification), but for the less advanced users' sake, I have tried to be on the safe side when things get tricky...
That said, if you see inaccuracies or mistakes (or just have questions), please comment!!
Also check out some more info on multisig setups over at:https://btcguide.github.io
Timelocks[edit]
Introduction[edit]
Prevention of spending coins until a defined time has lapsed to avoid hasty and coerced transactions.
Has Complexity Risk.
Blockchain Based Timelocks[edit]
This is a uncommon feature.
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.https://en.bitcoin.it/wiki/Timelock#Far-future_locks
The problem I see with time-locking coins is, if the keys are compromised, you'll find yourself in a race with an attacker when the coins are unlocked. The attacker might even set an enormous fee to get in a block before you.https://www.reddit.com/r/Bitcoin/comments/7e0ums/best_way_to_timelock_bitcoin_to_hodl/dq1qtud/?utm_source=reddit&utm_medium=web2x&context=3
Software Based Timelocks[edit]
Less trusted employees with limited permissions to spend cryptocurrency could be prevented from spending until a time defined on the trusted server has lapsed. Since the trusted server enforcing the timelock is by definition trusted, this does not seem possible outside of a multi user or institutional level cryptocurrency custody.
whitelists[edit]
Self-custody cryptocurrency wallets, enforced using blockchain features: Conceivable with smart contracts to permit spending to defined recipients only such as perhaps a centralized cryptocurrency exchange. But how could the whitelist be updated if need be? Unpopular. No known example implementations.
Self-custody cryptocurrency wallets, enforced using software: Similar to Software Based Timelocks.
Funds on centralized exchanges: withdraw whitelists make sense, specifically if withdraws are only allowed to high security (self-custody) wallets.
Has Complexity Risk.
spend limits[edit]
Similar to whitelists.
Complexity Risk[edit]
For example the parity blockchain based multisig locked Ethereum (ETH).
Multi-sig wallets have been frozen which are estimated to hold roughly $150 million in Ethereum.https://www.zdnet.com/article/ethereum-user-accidentally-exploits-major-vulnerability-locks-wallets/
At time of writing (2021) these funds would be even more worth in fiat money equivalent, has not been resolved, a previous vote (#EIP-999) to resolve it failed.
Smart Contract On Chain Multisig vs Threshold Signature Wallets[edit]
Smart Contract On Chain Multisig is very much Too complex. Millions worth of ETH was and still is frozen in the parity multisig smartcontract.
https://web.archive.org/web/20220909050353/https://sepior.com/blog/advanced-mpc
Further Reading[edit]
Footnotes[edit]
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!