Ledger, a provider of hardware solutions which offers the Ledger Nano hardware wallet, recently posted a blog on Medium addressing the use of Segregated Witness for hardware wallets. Pieter Wuille, a bitcoin core developer, presented his Segregated Witness proposal at the Scaling Bitcoin in Hong…
Ledger, a provider of hardware solutions which offers the Ledger Nano hardware wallet, recently posted a blog on Medium addressing the use of Segregated Witness for hardware wallets. Pieter Wuille, a bitcoin core developer, presented his Segregated Witness proposal at the Scaling Bitcoin in Hong Kong.
Hardware wallets protect bitcoin keys to make sure bitcoin purchases are made to the right address and the right amount, the blog noted. In order to do this, they require certain information about the transaction. They have to know the destination address, the amount and how much money is actually entered into the payment.
This amount is not included in the “previous output” information that qualifies the transaction input. An attacker could misrepresent the amount associated with the inputs, delivering an inflated fee as the fee gets coded as the difference between the outputs paid and the inputs provided. This is the problem that a hardware wallet developer has to solve.
A hardware wallet signs the transaction to validate it. Under the current process, this includes modifying a copy of the full transaction for each input signed. This requires strong design choices because hardware wallets typically do not have enough RAM to hold an arbitrary transaction.
This problem can be solved by developing a proprietary “previous output” structure called a “trusted input.” The hardware wallet parses the previous transaction fully, then returns a signed “previous output” with an associated value.
But even if this can be done in the background, it does not provide an optimal solution. The prior transaction still needs to be fetched from the network and streamed to the hardware wallet. If the prior transaction comes from a service that groups payments into big transactions like a mining pool reward or a lottery, this can be quite painful.
Streaming speed is also slow upon implementation while sticking to smartcard standards. We use an ISO 7816-4 T=0 encoding on top of HID to easily move to CCID for vanilla ISO smartcards or NCF. The transaction parser has to work around the RAM limitation of Ledger Nano (around 2Kb available.)
The new signature algorithm that Segregated Witness enforces solves this issue in the best way possible by including the prior output value in the signature directly. Hence, hardware wallets do not have to process the prior transaction any longer. In addition, the client does not need to request the complete prior transaction either since any change in the associated value will invalidate the input signature.
With the current process, signing a transaction occurs in the following way with the trusted protocol after obtaining the trusted input with “get trusted input”:
• Prepare the transaction copy with the proper input script prepared on the host computer.
• Stream the transaction to the dongle using the “untrusted hash transaction input start.”
• Stream the output script with “untrusted hash transaction input finalize full.”
• Request the signature with “untrusted hash sign.”
• Repeat for every input.
The process clearly is complex, particularly when collecting a big number of low-value inputs. By collecting a large number of low-value inputs that come from a big transaction, it is even worse on account of the prior problem, which is what occurs most of the time with such services.
Segregated Witness helps in this area. The signature mechanism complexity avoids rehashing the complete transaction for every input and helps node validation when addressing mega transactions. The same logic can be reused for each transaction, and an image of the data can be kept to hash and skip most of the prior process.
When signing a Segregated Witness input, the procedure changes as follows:
• Stream the transaction to its outputs to the dongle using “untrusted hash transaction input start.” It is not necessary to use trusted inputs and we can directly push the previous output and its associated amount.
• Stream the output script with “untrusted hash transaction input finalize full.” The hardware wallet at that point can cache the hash state for the full transaction.
• Stream a pseudo transaction for each input with a single input and no output with “untrusted hash transaction input start,” then request the signature with “untrusted hash sign.”
For a sample transaction with four inputs, with each prior transaction being about 400 bytes long, consider how much time is saved in implementation.
• The trusted input computation four times is 330 ms * 4 times: 1.3 seconds
• The generic transaction parsing is 1 second * 3 times: 4 seconds
What is left is the signature of the inputs:
• Inputs signatures four times: 1 second * 4 times: 4 seconds
This provides an economy of 5.4 seconds on a process of 9.4 seconds; about a 60% boost in performance.
Segregated Witness addresses two major hardware wallet performance concerns – trusted input computation and generic transaction parsing.
Developers can try this immediately with the Ledger Wallet Nano beta version following the updated technical specification. It is also available in the trusted execution environment application for Android which was released recently.
Featured image from Shutterstock.
Last modified: January 25, 2020 11:18 PM UTC