The goal of hardware wallets is to keep private keys secure, allowing users to sign transactions and to receive funds safely.
They use a very simple mechanic and relatively basic technology, but with the advancements being made on the Bitcoin network, hardware wallets could be so much safer and easier to use.
Future features
There are a number of features that hardware wallets still do not support which would seriously improve both security and ease of use.
Some potential upgrades that have already been developed on the Bitcoin blockchain include CoinJoin, Lightning, custom scripts, multisig, and sidechains.
At the time of writing, you can’t perform CoinJoins with hardware wallets, meaning there is no way to mix your coins with other users’ coins to boost privacy. Simply put, CoinJoin is a mechanism that enables transactions from multiple senders to be batched into a single transaction, similar to ring signatures.
Another way to improve transaction malleability and to add an extra layer of privacy on top of the wallet would be to add signature aggregation, or Schnorr signatures, to the hardware wallet software. Signature aggregation refers to when there are a number of people who each have their own key. They can then produce a combined key that can only be used to sign when they all come together. This technology is used in multisig, or multisignature transactions, where multiple users need to sign a transaction to make it valid.
Technically, in order to combine all the transaction input signatures into one, we don’t need a multisignature scheme, but rather an aggregate signature scheme. The distinction is simply that in an aggregate signature scheme, each signer has their own message rather than one message shared by all.
For hardware wallets, the immediate advantage would be the fact users could keep their message private, and would only need to prove their ownership whenever needed. In terms of data ownership, I think this logic makes more sense when applied to hardware wallets than multisignature schemes.
Lightning in hardware wallets?
Lightning is an innovative technology but can be tricky. The fact we still need to create Lightning invoices to receive payments can be a hassle for users. Plus, channels need to be open and remain open while users transact. At the same time, agents need to pay attention to time locks, otherwise transactions might fail.
Operators need to be connected all the time in order to route Lightning payments and also receive Lightning payments. The blockchain needs to be monitored constantly to check whether the channel is still open, closed, or giving an error.
Another minor bottleneck is linked to the number of secret keys in the Lightning protocol. There are on-chain keys, channel keys, and revocation secrets. There’s also the keys used to fund the channels, the keys used to update the channels, and revocation secrets that we give out to other parties.
Plus, if an attacker gains control of your Lignthing node, your hardware wallet security would be compromised.
It would be nice to have a backup communication channel if an attacker tries to completely disconnect your hardware wallet. Watchtowers could work, or any kind of notification to the user that something is going wrong.
Securing Lightning in hardware wallets
To mitigate these problems, it could be possible to limit some nodes to simply receive and send payments by limiting some of the routing functionality. This would force users to get a message signed on the hardware wallet with the key that was used to open the channel, and this message can be verified. The message would be routed to the trusted node and can be rerouted to other channels.
Another interesting feature would be the capability to sign a message and define a limit, and then have the trusted node enforce said limit.
This still relies on the trusted node to behave properly, but at least there is some additional security against external attackers.
What this solution proposes is a higher degree of entropy due to increased centralisation, with the sole benefit of allowing users to risk less of their own funds when transacting.
Disclaimer: The views and opinions expressed by the author should not be considered as financial advice. We do not give advice on financial products.