With the Bitcoin Note we’ve endeavored to create a self-custodial Bitcoin storage solution that mirrors the function of bearer financial instruments like cash.
There are some significant challenges in doing so; the nature of Bitcoin as a stateless money means that no party has an incentive to remove counterfeit notes from circulation. Conversely, any manufacturer of Bitcoin bearer instruments has an incentive to keep or derive copies of private keys which would allow them to transfer funds without consent of the holder.
Leveraging a combination of currency-grade printing, secure NFC chips and a time-locked multisig we have worked to mitigate these challenges to create a usable, self-custodial Bitcoin bearer instrument. Our goal is not to move the majority of Bitcoin on to physical notes, but rather that the Bitcoin Note serves as an easy to use tool to onboard family, friends and their communities to Bitcoin with minimal technical hurdles and reasonable guarantees.
The Bitcoin Note consists of:
All value of a Bitcoin Note relates to the P2SH; the printed security features have no bearing on the ability to spend associated Bitcoin. They indicate the intended Bitcoin value stored as well as when spending should occur to ensure that no previous holder can spend the funds.
A note is first provisioned by the manufacturer. For each note manufacturer generates a unique ECDSA secp256k1 key pair, the manufacturer public key and manufacturer private key, and a unique AES key, the server wrapping key.
The manufacturer public key is stored on the note in plaintext. The manufacturer private key is generated and then encrypted using server wrapping key. The encrypted form of the manufacturer private key is stored on the note. This data is written to the note, together with a face value and a claim by date. At this point, the note still has no value.
In order to make use of the note, the first holder or user must perform a personalization process. This is done using a dedicated client application.
During the process, the user generates a unique ECDSA secp256k1 key pair, the user public key and user private key. This key pair is stored on the note, both portions in plaintext.
From the manufacturer public key and user public key, a Bitcoin P2SH is created with the following conditions:
The user is instructed to send the face value of BTC to the address corresponding to the P2SH. The process is complete after the sufficient amount of funds appears on the wallet. By default the client app will use any excess funds for miner fees. If the note has insufficient funds, it will show as invalid when scanned.
A user may rotate the user private key. During the process, a new key pair will be written to the note, without overriding the current key pair. Because the user’s key pair has changed, a new P2SH multisig will be generated, with the same conditions as described in “Personalization” above.
The user must present the server with the encrypted manufacturer private key such that in memory the server can generate a transaction to move funds from the old wallet to the new wallet, sign it with the manufacturer private key and provide the transaction to the user.
The user adds a signature with user’s old private key from the note and dispatch the transaction to the network. The process is finished after the funds are successfully moved to the new P2SH multisig.
A user is able to withdraw the funds covered by the note to an arbitrary Bitcoin address.
In order to do so, they need to mechanically cut a trace in a designated place one the note (indicated by “Cut to claim”). This will trigger a function in the NFC chip indicating that it is in claim mode. This process is irreversible, so carefully re-connecting the trace will not reset the triggered state in the chip.
The user needs to use a dedicated client app that facilitates communication between the chip and note server. The server will validate whether the note’s chip reports tampering alert. If so, the server will release the server wrapping key to the user.
With possession of both the manufacturer private key and user private key the user can create a transaction to remove funds from the associated P2SH address.
The NFC chip includes three memory slots with different write capabilities:
The state of the NFC chip is tracked across various stages of the note lifecycle by the note server. The server records a single source of truth of a note’s state whereby the server memory slot is synchronized with the server with each online verification.
The client app acts as a proxy, forwarding messages between the Bitcoin Note and the Note Server. The NFC chip has a secure authentication protocol which includes the following properties:
The app includes a command whitelist whereby it verifies each command transmitted to the NFC chip from the note server and denies execution of disallowed commands (for instance, an attempt to read the user private keys).
The client could write corrupted data to the client’s memory slot due to a bug in software or software modification. The server is reliant upon the client correctly writing data to the client memory slot.
Inconsistencies will be detected by subsequent clients attempting to validate a corrupted note. It will be either:
A malicious note server may carry out several actions:
A malicious client app could harvest information about Bitcoin Notes it has encountered. The attacker would obtain:
If a server wrapping key is stolen or leaked then a transaction for immediate withdrawal of the funds for notes where this information has been harvested may be created.
Rotating the user keys during the lifecycle of the note alleviates this problem.
The note could stop responding to the commands or experience memory corruption. If the encrypted manufacturer private key and user private key are still readable, funds may be recovered if the wrapping key is manually released or the expiration date is exceeded. If the keys are not readable, the funds are lost.
There are no known attacks against the NFC chip used in the Bitcoin Note which would allow for the creation of a counterfeit chip. Such an attack would require successful recovery of the authentication keys of each individual chip intended for counterfeit.
In order to counter these kinds of possible attacks the server memory slot contains a nonce value. This value is stored both on the server and on the chip. Upon each online verification, the server reads the nonce from the chip and compares it against the value in the note server database. The note server updates the nonce during each online verification. Likewise, only when this check is complete will the server write an updated signature to the note.
A mismatched nonce could indicate counterfeit chips in the field, however, only one chip between an original note and the counterfeits would validate moving forward.