Hours of Horus: Keyless Cryptocurrency Wallets

Abstract

We put forth a keyless wallet, a cryptocurrency wallet where money can be spent using a password alone, and no private keys are required. It requires a smart contract blockchain. We propose a scheme in which the user uses an OTP authenticator seed to generate a long series of time-based OTP passwords for the foreseeable future. These are encrypted and organized in a Merkle tree whose root is stored in a smart contract. The user can spend funds at any time by simply visually providing the current OTP password from an air gapped device. These OTPs can be relatively short: Just 6 alphanumeric characters suffice. Our OTP scheme can work in proof-of-stake as well as static and variable difficulty proof-of-work blockchains. The low-entropy passwords and OTPs in our scheme are protected from brute force attacks by requiring that an adversary accompany any attempt by a transaction on the chain. This quickly incurs enormous economic costs for the adversary. Thus, we develop the first decentralized rate limiting scheme. We use Witness Encryption (WE) to construct a timelock encryption scheme in which passwords are encrypted from past into future blocks by leveraging the NP-language having proof-of-work or proof-of-stake performed as the witness. Witness Encryption is a currently impractical cryptographic primitive, but our scheme may become practical as these primitives are further developed.

Appendices

Appendix

A Analysis

We now give a more complete analysis of the scheme. First, let us prove that the password-based wallet of Algorithm 1 is correct.

Theorem 1 (Password Wallet Correctness (Informal))

Let the blockchain have liveness and safety, and let the witness encryption scheme $\textsf {WE}$ be correct. An honest party spending at block height $t_1 - \ell - 2k$ or earlier will generate a valid spending transaction for Algorithm 1.

Proof (Sketch)

The contract is created when $B = \mathcal {C}[-k]$ is stable. Due to safety, all the future chains will be extending this block. The contract is initialized with $x = (B, t)$ by issuing the $\textsf {tx}_\textsf {construct}$ transaction. Due to liveness, this transaction is confirmed within $\ell$ blocks. The honest user then creates a transaction $\textsf {tx}_\textsf {commit}$ when her own chain has length $|\mathcal {C}| = t_1 - \ell - 2k$. Due to liveness, this transaction becomes confirmed for all honest parties after $\ell$ blocks have elapsed, and is placed in position $\mathcal {C}[t_1 - 2k]$ or earlier. Therefore, Line 10 of the method commit succeeds. When $|\mathcal {C}| = t_1$, the honest user calls reveal, passing w. Due to the correctness of the witness encryption scheme, the decryption succeeds. The password and salt revealed match the ones committed. Due to liveness, this transaction becomes confirmed.

The correctness of the OTP-based scheme is similar.

Theorem 2 (OTP Wallet Correctness (Informal))

Let the blockchain have liveness and safety, and let the witness encryption scheme $\textsf {WE}$ be correct. An honest party spending multiple times prior to $\textsf {MAX\_TIME} - \ell - 2k$ will succeed in creating valid transactions. in Algorithm 3.

Proof (Sketch)

The proof is the same as above, with the difference that the value t is provided at the commit time, not the construct time. The argument that Line 10 will be successful remains the same due to liveness.

Our security analysis is in a hybrid cryptographic and cryptoeconomic setting. In the system described, we have two security parameters. First, we have the cryptographic security parameter $\kappa$ (${\approx }128$ bits), which determines the security of the hash function, the security of the witness encryption scheme, and the security of the blockchain (in terms of liveness, safety, and common prefix). The probability of failure is negligible in this parameter. Any breakage in this parameter can be catastrophic for the system and can potentially provide the adversary with gains without any cost. Secondly, we have the much shorter cryptoeconomic security parameter $\lambda$ (${\approx } 35$ bits) which denotes the entropy of the chosen user password sk or the length of each OTP $\textsf {OTP}_t$. While this parameter is hopelessly short from a cryptographic point of view (and $2^{-35}$ is nothing but negligible), we will use it to establish a lower bound in the economic cost of an attack. In particular, we will tweak this parameter so that the return-on-investment of an attack can be made arbitrarily close to $-100\%$. The result will be that the adversary can make the probability of success non-negligible, but at an economic cost which renders such attempts irrational.

We begin by stating our Decentralized Rate Limiting lemma, which establishes that an adversary must necessarily submit transactions to the blockchain in order to have any non-negligible probability of success. The probability of success is determined by the number of transactions submitted by the adversary and made persistent by the system. Based on this result, we will determine the cryptoeconomic parametrization ($\lambda$) required to make the system economically infeasible to attack.

Lemma 1 (Decentralized Rate Limiting (Informal))

Consider a static difficulty proof-of-work blockchain with safety and common prefix. Let the hash function H be collision-resistant and preimage-resistant, and let the witness encryption scheme $\textsf {WE}$ be a secure witness encryption with witness extractability. A PPT adversary who submits fewer than g transactions that are eventually confirmed by all honest parties has a probability of achieving a valid spending transaction in Algorithm 1 upper bounded by $\frac{g}{2^\lambda } + \textsf {negl}(\kappa )$.

Proof (Sketch)

In order for the adversary to have a valid transaction, she must have created a $\textsf {tx}_\textsf {reveal}$ in which she passes a password sk, a salt and a $\alpha '_{\textsf {to}}$ address which is different from the honestly provided $\alpha _{\textsf {to}}$ address. This reveal transaction must be confirmed into the chain $\mathcal {C}$ adopted by a verifier honest party $P_v$ and have matching data with a previous $\textsf {tx}_\textsf {commit}'$ transaction which was placed earlier in $\mathcal {C}$. Additionally, $\textsf {tx}_\textsf {commit}'$ must be in $\mathcal {C}[t_1 - 2k]$ or earlier (due to the check in Line 10). Due to the collision resistance of H, the respective commit transaction must be different from the one ($\textsf {tx}_\textsf {commit}$) provided by the honest party, as $\alpha _{\textsf {to}} \ne \alpha '_{\textsf {to}}$.

Let $r_c$ denote the round during which the spender honest party $P_s$ broadcasts their $\textsf {tx}_\textsf {commit}$ transaction to the network, and let $r_z$ denote the last round during which all honest parties have chains with length of at most $t_1 - k$.

Let us consider all adversarially generated commit transactions $\textsf {tx}^i_\textsf {commit}$ ($i \ge 1$) that are eventually reported as stable by $P_v$ (the adversary can also create transactions that do not make it in the chain of $P_v$, but we will not count these). For these transactions, let us consider the round $r_i$ during which each of these transactions $\textsf {tx}^i_\textsf {commit}$ was created.

Case 1: $r_i < r_c$. Since the honest spender has not yet submitted a commitment, the only information that the adversary has is the ciphertext c. If at this round the adversary can distinguish between sk and any other plaintext in $\{0, 1\}^\lambda$ with probability non-negligible in $\kappa$, then, due to the witness extractability of WE, an extractor can extract a witness w attesting to the existence of a chain of height $t_1$. But in that case, we can perform a computational reduction to an adversary that breaks the common prefix property of the chain by producing a chain of height $t_1$ at round $r_i$ when the honest party $P_v$ has adopted a chain of length only $t_1 - \ell - 2k$. This breaks the common prefix assumption.

Case 2: $r_c \le r_i \le r_z$. In this case, the honest spender has broadcast a commitment to the network, but there are no chains of length $t_1$. The adversary now holds both the timelocked ciphertext c and the commitment z. Again the adversary should not be able to distinguish between sk and any other plaintext in $\{0, 1\}^\lambda$, except with probability negligible in $\kappa$ (recall that the $\textsf {salt}$ is kept secret and has $\kappa$ bits of entropy). Otherwise, we can either perform a reduction to a common-prefix-breaking adversary making use of witness extractability, or we can perform a reduction to a preimage-resistance-breaking adversary.

Case 3: $r_i > r_z$. By the definition of $r_z$, in round $r_i$ there must exist an honest party with a chain of length at least $t_1 - k$. By the common prefix property, all other honest parties have a chain of length exceeding $t_1 - 2k$.

Let us consider what happens in all of these three cases. In the first two cases, any single guess that the adversary places into a transaction can be correct with probability $\frac{1}{2^\lambda } + \textsf {negl}(\kappa )$. In the third case, while the adversary can potentially guess with better probability (due to the chain reaching its leakage point $t_1 - k$), any such transactions can never make it into the chain eventually adopted by $P_v$, as the check in Line 10 will fail.

As the transactions that eventually make it into the chain of $P_v$ were all generated prior to $r_z$, the probability that each of them is a valid spending transaction is upper bounded by $\frac{1}{2^\lambda } + \textsf {negl}(\kappa )$. If the adversary submits at most g such transactions, and applying a union bound, the overall probability of success is $g(\frac{1}{2^\lambda } + \textsf {negl}(\kappa )) = \frac{g}{2^\lambda } + \textsf {negl}(\kappa )$.

The above Lemma is identical for our other construction. We state it for completeness.

Lemma 2 (OTP Decentralized Rate Limiting (Informal))

Consider a static difficulty proof-of-work blockchain with safety and common prefix. Let the hash function H be collision-resistant and preimage-resistant, and let the witness encryption scheme $\textsf {WE}$ be a secure witness encryption with witness extractability. Let $\mathcal {G}$ be a secure pseudorandom function $\{0, 1\}^\kappa \times \mathbb {N} \longrightarrow \{0, 1\}^\lambda$. A PPT adversary who submits fewer than g transactions that are eventually confirmed by all honest parties has a probability of achieving a valid spending transaction in Algorithm 3 upper bounded by $\frac{g}{2^\lambda } + \textsf {negl}(\kappa )$.

Proof (Sketch)

The proof here is identical to Lemma 1, noting that each of the different $\textsf {OTP}_t$ essentially gives rise to independent attack paths to the adversary. Due to the pseudorandom nature of the OTP scheme, any previous OTPs do not reveal any information to our polynomial adversary. An adversary making a spending attempt has a probability of $\frac{1}{2^\lambda }$ of succeeding in each attempt, unless it can be reduced to a collision-resistance-breaking adversary, a common-prefix-breaking adversary, or an adversary breaking the pseudorandomness of the OTP scheme. But all of these events are negligible in $\kappa$.

At this point, we have established that the probability of success is negligible in both parameters $\kappa$ and $\lambda$. However, we will keep the parameter $\lambda$ short, and we will make the $\kappa$ parameter reasonably long ($\kappa = 128$). Setting $\lambda = \kappa$ would, of course, give sufficient security. The reason for separating these two parameters is that the $\lambda$ parameter affects the usability of the system: It is the number of characters that must be remembered by the user in the case of a password, or the number of characters that must be visually copied by the user in the case of an OTP.

In the above result, we have expressed the probability as a sum of two terms: $\frac{g}{1^\lambda } + \textsf {negl}(\kappa )$. This reflects the nature of the two parameters: We opt to calculate the concrete probability with respect to $\lambda$, but only give an asymptotic probability with respect to $\kappa$. This treatment hints at our intentions: Our high-level argument was to condition the system to the overwhelming events that there will be no cryptographic breakage in the hash function, common prefix property, blockchain safety, blockchain liveness, and OTP pseudorandomness. Conditioned under these events, the concrete probability as a function of $\lambda$ allows us to make an argument of why any attack is uneconomical. This gives rise to our (cryptoeconomic) security theorem.

Theorem 3 (Cryptoeconomic Security (Informal))

Consider a chain with fee f per transaction. If the wallet of Algorithm 1 or Algorithm 3 is used with a maximum capital of V, then the parametrization $\lambda > \log \frac{V}{f}$ yields a negative expectation of income for the adversary, with overwhelming probability in $\kappa$. Additionally, the expected return-on-investment for this adversary is at most $\frac{V}{f 2^\lambda } - 1$.

Proof (Sketch)

Consider an adversary who submits g transactions that are eventually confirmed by every honest party. This adversary is irrevocably investing a capital of gf for this attack. By Lemma 1, the adversary has a probability of success upper bounded by $\frac{g}{2^\lambda }$ (with overwhelming probability in $\kappa$). The expected income for this adversary is at most ${{\,\mathrm{\mathbb {E}}\,}}[\textsf {income}] \le V \frac{g}{2^\lambda } - gf$. Taking $\lambda > \log \frac{V}{f}$, we obtain ${{\,\mathrm{\mathbb {E}}\,}}[\textsf {income}] < 0$. The expected return-on-investment is $\frac{{{\,\mathrm{\mathbb {E}}\,}}[\textsf {income}]}{gf} - 1$.

In this scheme, we can set $\lambda$ big enough to make the return-on-investment as close to $-100\%$ as we want. If we want the return-on-investment to be $-1 + \epsilon$ for some $\epsilon \in (0, 1]$, we let $\lambda = \log \frac{V}{f \epsilon }$. In short, we can make the adversary lose an amount arbitrarily close to all their money in expectation.

To consider some concrete parametrization of the scheme, let us assume that we wish to establish a target $-90\%$ ($\epsilon = 0.1$) expected return-on-investment for the adversary in a wallet where we want to store up to $V = \$100{,}000$ in capital at any point in time. Consider a blockchain where the fees per transaction are¹ at least $f = \$1.60$. We obtain $\lambda = \log \frac{V}{f \epsilon } = \log _2 625{,}000 < 20$ bits. This corresponds to just 6 numerical characters (base 10), or just 4 alphanumeric characters (base 58). A standard OTP authenticator such as Google’s Authenticator application is therefore appropriate for such parameters. Increasing the maximum capital that will be stored in the wallet by three orders of magnitude to $\$100{,}000{,}000$ requires 5 alphanumeric characters instead.

B Proof-of-Stake

Contrary to proof-of-work blockchains, a proof-of-stake chain progresses in slots (prefixed time durations) during which parties can create blocks or remain silent. As in proof-of-work, each block header $B_i$ consists of $\left\langle \textsf {tx}_i, s_i\right\rangle$, but now does not include a $\textsf {ctr}_i$. The blocks created at each slot are accompanied by a signature $\sigma _i$ created by a designated leader for the slot. A proof $\pi _i$ illustrating the designated leader is the rightful one is also broadcast together with the block. The probability that a party becomes a leader at a given slot is roughly proportional to the stake they hold within the system. These proofs of leadership are different depending on the system and can be the random outcome of a multiparty computation, as in the Ouroboros [39] system, or a verifiable random function [45] evaluated on this randomness, as in the Ouroboros Praos [24] construction. In the first system, each slot is allocated to precisely one party, and the production of no blocks, or two competing blocks in the same slot, indicates adversarial behavior. In the second system, it is possible that a slot is allocated to multiple honest parties, or no parties at all. These details do not affect our scheme, as long as the following property is maintained: For any 2k consecutive slots, at least $k+1$ slots are allocated to an honest party. Additionally, we will assume that the common prefix property holds here, too.

As in proof-of-work, the chain is split into epochs. At the end of each epoch, a multiparty computation is performed to determine the randomness value for the next epoch based on the stake distribution during the current epoch. Different systems use different MPCs. Our only requirement is that these MPCs provide some evidence $u_e$ that the randomness for epoch e is $\rho _e$. This evidence must be polynomially checkable in retrospect. This requirement is satisfied in proof-of-stake blockchains, as it is this evidence that allows new nodes to bootstrap correctly [5].

In this section, we adapt our OTP wallet construction to the proof-of-stake setting (the password wallet can also be adapted likewise). For concreteness, we describe a construction for the Ouroboros [39] and Ouroboros Praos [24] systems, but our results are extensible to other systems as well (such as Snow White [11] and Algorand [44]).

The construction does not change much from the proof-of-work case, so we only provide a sketch of the construction here. The smart contract remains identical, except for the moderately hard NP language describing the existence of a proof-of-work witness. More concretely, the problem instance x is now $(\rho , sl, D, t)$, where $\rho$ denotes the randomness of the current epoch, sl denotes the slot during which block B (the most recently known stable block $\mathcal {C}[-k]$) was generated, D denotes the stake distribution during the current epoch, and t denotes the future time. While the proof-of-stake chains also enjoy the common prefix property, unfortunately, we cannot simply take any blockchain that has length t following B, because the adversary can create blockchains of arbitrary length. The proof-of-stake system ensures that such chains are not taken into account by checking that any blockchain received on the network does not contain blocks that were issued in future slots [39]. However, we cannot incorporate this check in the form of an NP language, as we do not have access to a clock.

Instead, we rely on a critical property of the proof-of-stake system that states that, in any consecutive 2k slots, at least $k+1$ will be honestly allocated. Therefore, we reinterpret the parameter t to mean the number of slots after block B instead of the number of blocks. The witness w consists of two parts: block data and epoch data. The block data contains a sequence $(\sigma _1, H_1, \pi _1, sl_1), (\sigma _2, H_2, \pi _2, sl_2), \cdots , (\sigma _d, H_d, \pi _d, sl_d)$ of signatures $\sigma _i$ each with their corresponding slot $sl_i$, with $sl_i > sl$ and a proof of leadership $\pi _i$. As in the proof-of-work case, no transaction data is verified. The epoch data contains a sequence $(\rho _1, u_1), (\rho _2, u_2), \cdots , (\rho _e, u_e)$ spanning all the epochs starting from the epoch of slot sl up until the epoch of slot $sl + t$. For each of these, the randomness $\rho _j$ and evidence $u_j$ of the multiparty computation leading to it (typically a collection of signatures) is included.

The relation $\mathcal {R}$ polynomially verifies that all the signatures $\sigma _i$ correctly sign their respective plaintext $H_i$, that the proofs of leadership $\pi _i$ are correct, and that the evidence $u_j$ for the randomness $\rho _j$ of each epoch is correct. Critically, it also checks that, for every window of length 2k slots, at least $k+1$ blocks have been provided.

This completes the basic scheme. We can improve upon this scheme by noting that blocks and signatures for everything but the most recent epoch are not necessary, as long as the randomness and its evidence for each epoch is given. This evidence can be made quite short using ATMs schemes, in which the evidence consists of aggregate threshold signatures (c.f., [37]). In such an optimization, a constant amount of bits is required per epoch. Blocks only need to be presented for the last epoch in order to have better time granularity. However, here, too, some pruning can occur: It is sufficient that only $k+1$ blocks and signatures pertaining to the most recent 2k slots of the most recent epoch are presented. The relation $\mathcal {R}$ can then simply check the evidence for each epoch randomness, that the $k+1$ signatures are correct, that they all fall within a 2k window, and that the slot during which the last such block was generated is t. Again, the witness encryption can be composed with a zk-SNARK to make the witnesses constant size.

Contrary to proof-of-work where the velocity of the chain is unknown, despite bounded, in the proof-of-stake case we have a much better grasp on how quickly the time t will be reached, as it is a slot number. While the adversary still enjoys some early leakage (k slots early), the timelocked data will be available at the prespecified time. In the proof-of-work case, it is possible that the blockchain growth rate will increase or decrease due to the stochastic nature of block production. As such, the proof-of-stake scheme is naturally fitting to the timelock problem.

C Variable Difficulty Proof-of-Work

In the variable difficulty model, the target T is adjusted based on how the chain evolves. Concretely, the chain is split into epochs of constant block length m each. At the end of each epoch, the timestamp at the end of the chain is noted and the mining target is adjusted with the aim of keeping the expected block production rate constant. The way T is adjusted is algorithmically determined, and it is important that it follows certain rules. While we will not articulate the exact rules, we remark that the new value $T'$ must fall within a range $\tau T, \frac{1}{\tau } T$, where $\tau \in (0, 1)$ (for example, Bitcoin sets $\tau = \frac{1}{4}$). This critical condition is necessary to avoid certain attacks [7].

The proof-of-work OTP wallet described in the main body is suitable for the static difficulty model in which the mining target T is not adjusted and remains constant. Real blockhchain systems adjust their T parameter dynamically in every epoch [29]. Our construction in this section will work in both models.

The construction for the dynamic difficulty proof-of-work model is similar to the static difficulty proof-of-work construction, with a key difference in the NP language used for witness encryption. The key idea is that, instead of encrypting for a chain descending from B and consisting of t blocks in the future, we need to encrypt for a chain descending from B and consisting of blocks that have together accumulated a total of t difficulty. More concretely, the witness encryption problem statement $x = (B, t, T_0, r_0, \nu )$ contains B and t as before, but now also contains the term $T_0$, the difficulty of the chain at the point when timelock encryption took place, the round $r_0$ during which the first block of the current epoch was generated, as well as $\nu$, the position of block B within its current epoch ($\nu = (|C| - k) \bmod m$, where m denotes the fixed epoch length).

The format of the witness w is now a sequence of block headers in the form $\left\langle T_i, \textsf {ctr}_i, \textsf {tx}_i, H(B_{i-1}), r_i\right\rangle$, where $\textsf {ctr}_i$, $\textsf {tx}_i$ and $H(B_{i-1})$ are as before, and, additionally, $T_i$ is the individual block’s mining target and $r_i$ is the round during which it was mined (following the notation of Garay et al. [29]). The relation $\mathcal {R}$ checks that the witness provided forms a chain that begins at the last known stable block B, that every block satisfies the dynamic difficulty proof-of-work equation $H(B_i) \le T_i$, and that difficulty has been adjusted correctly. Specifically, for the difficulty adjustment, it checks that for all $i \ge 2$, if $i - \nu \bmod m \ne 1$, then $T_{i-1} = T_i$ (ensuring difficulty was not improperly adjusted internally within the epoch of B or any subsequent epochs). It also checks that the rounds provided are increasing $r_i < r_{i+1}$, and ensures that the difficulty at the epoch borders $i-1$, i with $i - \nu \bmod m \ne 1$ and $i > 1$ has been correctly adjusted by verifying that $T_{i} = \min (\max (T'_i, \frac{1}{\tau } T'_i), \tau T'_i)$, where $T'_i = \frac{r_{i-1} - r_{i-m}}{a} T_{i-1}$ is the unclamped target, and the term a indicates the expected block production rate of the system in rounds [29]. To achieve security with overwhelming probability, and not just in expectation, in $\kappa$, it is imperative that the $\tau$ bounds are also checked by $\mathcal {R}$ (see Bahack [7] for more details on a tail attack). Lastly, the relation checks that the difficulty is sufficient, as required by the t parameter. To do this, the difficulty of each block in the witness is summed up to discover the cummulative difficulty of the fork, checking that $\sum _{\left\langle T_i, \_, \_, \_, \_\right\rangle \in w} \frac{1}{T_i} \ge t$.

Now that the precise NP language has been established, a couple of things need to be changed in our protocol. First of all, at the time the OTPs are generated, MAX_TIME no longer indicates the maximum lifetime of the wallet (in chunks of HOURLY_BLOCK_RATE blocks), but the maximum total difficulty accumulated during the lifetime of the wallet. So we rename it to MAX_DIFFICULTY. This parameter is sensitive in case the difficulty increases. Hence, the value must be increased sufficiently (at the cost of increased IPFS storage needs) to cover for all foreseeable difficulty adjustments for the expected lifetime of the wallet. One way to do this is to look at past difficulty adjustment trends and extrapolate them to the future for the number of years the wallet is to be usable. In any case, this prediction does not need to be perfect: In the unfortunate case that the OTPs are close to becoming exhausted, which can easily be observed by inspecting the chain as it evolves, the wallet can be sunset by moving the funds to a new wallet with a new lifetime.

Next, the value HOURLY_BLOCK_RATE no longer indicates the number of blocks generated in one hour, but the amount of difficulty that must be accumulated before the next OTP can be utilized. So we rename it to OTP_ROTATION_DIFFICULTY. This parameter is sensitive in case the difficulty decreases. Hence, this value must be decreased sufficiently (at the cost of increased IPFS storage needs) to allow the user to spend as quickly as desired. As difficulty typically does not decrease, one way to do this is to look at the previous HOURLY_BLOCK_RATE parameter and multiply it by the current difficulty to obtain a lower bound for the future. If one can predict a lower bound for how much future difficulty increases, it is also possible to timelock encrypt with non-uniform difficulty: The difference in the difficulty used to witness encrypt two early consecutive OTPs can be smaller than the difference in difficulty used to witness encrypt two later consecutive OTPs. The precise mechanism to do this effectively depends on the cryptocurrency and empirical measurements.

Lastly, the smart contract must be modified in the security-critical line that ensures that t is sufficiently in the future. In the static difficulty, t counts the number of blocks (or slots in the proof-of-stake case), but here it is counting difficulty. Therefore, it cannot be compared to block.number, and the 2k delay (which also counts blocks) cannot be readily applied. Instead, we must use a new variable² block.cumdiff, the cummulative difficulty collected by the blockchain if all the difficulty from genesis to the current block is summed up. Additionally, the 2k factor must be weighted by the current difficulty $\frac{1}{\textsf {block.T}}$, where $\textsf {block.T}$ indicates the mining target of the current block.

The algorithms for the variable difficulty OTP wallet appear in Algorithm 5 and 6.

The argument for the correctness of the scheme and the security of the scheme remains the same. Some remarks about the security portion are in order. First, recall that any blockchain protocol does not accept blocks with timestamps in the future. In the static difficulty model, this was not important, but in the proof-of-stake and in the variable difficulty model, it is something to consider. In particular, for the variable difficulty case, if the adversary constructs blocks timestamped with future rounds, she can cause the difficulty to drop more than it would be possible in a real-world execution. However, this does not bless the adversary with more mining power. Additionally, such chains will not be mined on by honest parties (because they are considered invalid, as of yet), and so they will only be extended by the adversary. The effect is the contrary of a difficulty raising [7] attack: The total difficulty accumulated as the target difficulty is artificially decreased becomes concentrated to its expected value. Hence, the minority adversary, who does not win in expectation, has an even lower probability of accumulating the difficulty goal described by x in this futuristic chain. Therefore, we shall not be concerned about this behavior.

The Bounded Delay Model. The above high-level analysis, as well as the more detailed analysis of the static case in Sect. A, was in the synchronous setting. However, all the proofs made direct use of high-level chain properties such as the common prefix property, safety, and liveness. The use of the rounds $r_c$, $r_i$, and $r_z$ to split time into chunks in the proof of Lemmas 1 and 2 is material to the proof. However, these rounds are defined based on transaction broadcast events and lengths attained by local honest chains. In a setting where the parties incur an unknown bounded delay $\varDelta$ (which satisfies certain conditions [27]), the properties of the chain still hold, albeit with worse parameters k and $\ell$, and the same security proof remains valid.

D Discussion

Having completed the presentation of our schemes in both static and variable proof-of-work, as well as in proof-of-stake, we now discuss a couple of remarks (and shortcomings) of our scheme.

Large Witnesses. The witnesses to the problem instances of the moderately hard NP language describing chain creation can grow linearly together with the chain. To reduce witness size, a (zero knowledge) proof of knowledge such as a zk-SNARK [9] can be used. In this case, instead of witness encrypting against a decryptor who “knows a witness consisting of a list of chain headers that satisfy the blockchain properties,” one can instead witness encrypt against a decryptor who “knows a witness consisting of a zero-knowledge proof of knowledge attesting to the knowledge of chain headers that satisfy the blockchain properties.” This composition of witness encryption and zero-knowledge proofs allows the witnesses presented to the blockchain to become constant size. For further details, refer to [41].

Using Standard Time-Based OTP. A standard time-based OTP cannot be used by the user of our protocol, because the chain, as a stochastic process, may have grown faster or slower than expected. The OTP device must know the current height of the blockchain to be able to reveal the correctly indexed OTP (which will reside at OTP index $|\mathcal {C}| + \ell + 2k$). One practical way to achieve this is to have the mobile wallet (or a block explorer) display the current block height, which can then be inputted by the user to the OTP application.

Security of the Online Computer. One critical point of infrastructure is the online computer to which the user inputs their OTP code. If that computer becomes compromised, it can change the target address and amount that the user is inputting and deplete the wallet. One practical mechanism to cut the user’s losses is to establish an hourly limit in the amount that can be spent by the wallet. The simplest way is to add an assertion in Algorithm 3 that ensures the amount spent in every reveal call is limited. In such a case, the compromised computer can only steal the user’s funds once, and up to the specified hourly limit, before being detected. More complex schemes can introduce limits for various periods of time, and the contract would have to keep track of how much money has been spent in every period of time.

Two-Factor Wallets. The OTP scheme can be used either as a single-factor (as described in the main body) or as a second factor combined with a private key if desired. It is an effective second factor because, if either, but not both, of the private key or the OTP device become compromised, the wallet remains secure.

A Bounty for the Miners. In our analysis, we have considered a rational adversary who is only allowed to allocate her capital into taking guesses for the user passwords and OTPs and holds a minority of the adversarial power. This worldview is slightly myopic. An adversary with a large capital operating in an open world can also use this money for other purposes such as bribing miners. In fact, let us take a step back and reconsider the honest majority assumption of the chain which allowed us to conclude that the properties of common prefix, safety, and liveness hold. What if the miners are not honest, but rational, instead? In this case, the properties do not hold (it is known that the honest protocol is not a Nash equilibrium [26], although it may be close to it [38]). In our case of keyless wallets, the wallet functions as a bounty to the miner who creates a long chain fork: If an adversary can violate the common prefix property, then she can, as far as the chain is concerned “go back in time.” In such an attack, after the secrets become timelock decryptable, the adversary creates a long chain reorganization and resubmits the correct guess to the wallet. As the reorganization was long, the delay check in the smart contract succeeds and the trial is correctly committed to the chain, granting the adversary the prize. This can be dangerous.

However, It can be argued that such bounties can be created by the adversary herself: If she double spends her money, she creates an incentive for herself to go back in time and reclaim it. But there is a crucial difference: The adversary can only spend her own money in the double spending case. Namely, although in a double spending case, the party receiving the money was harmed by the chargeback, it is the adversary’s money that is being double spent, not someone else’s. There is another critical difference here: While a single adversary can create such bounties for herself, keyless wallets are universal bounties claimable by any miner. We remark, however, that a double spending adversary can twist the double spending attack in a way that makes it a universal bounty: The adversary first creates a legitimate transaction spending some of her own money and receives, say, fiat money in exchange. She then creates a double spending transaction in an alternative fork: That double spending transaction pays $50\%$ of her money to herself, and the rest to the miner who confirms the given block. In this case, all miners are incentivized to confirm this transaction and fork.

Therefore, we argue that the existing blockchain systems are not very different in the way incentives are aligned as compared to our proposed wallet. Nevertheless, as highlighted in the analysis, the proposed wallet does indeed have a different security model from a standard wallet: It is not purely cryptographic, but a cryptographic/cryptoeconomic hybrid. A quantified analysis of the (ir)rationality of conducting a common prefix attack is explored by Bonneau et al. [12].

Temporary Dishonest Majority. Our analysis assumed adversarial minority throughout the execution. However, this may not necessarily be the case. Blockchains have faced situations where the adversarial power has temporary majority spikes, even though the adversary generally controls only a minority [4, 6]. One of the arguments protecting from double spending stems from the ability of the user to set their own local k parameter when they consider which transaction to accept as confirmed. The parameter k is not a global parameter of the system, but it can be set by each user individually at the time of payment. If there are rumours or evidence that the chain may be under attack, the user can delay accepting payments. This is not the case for our protocol. While the user can set the critical 2k delay when instantiating the contract, and this is a local choice, this choice cannot be changed later. If an adversary attains majority after the contract has been instantiated, she will be able to roll back the chain sufficiently to steal the user’s money. This limitation of the system must be taken into account when deciding about the k parameter of the wallet: The parameter must not only withstand current adversarial bounds, but adversarial bounds through the lifetime of the wallet. One mechanism to deal with this issue is to migrate from a wallet with a small k to a different wallet with a more conservative value when evidence appears that the chain may become attacked in the near future. If the blockchain network cannot be trusted to maintain honest majority, and the adversarial majority spike length is unpredictable, the money cannot be left and forgotten as in a key-based wallet.

Detectability of Brute Force Attacks. One of the advantages of our system is that brute force attacks are not only economically infeasible, but they are also detectable. If an adversary submits a brute force attempt to the wallet, a commit transaction will appear on the chain that the honest user will see. As such, the user can decide to move their funds out of their wallet if they observe such behavior. This benefit stems from the fact that the brute forcing of user passwords and OTPs cannot be done offline, but must necessarily be made on the chain. Our rate limiting scheme is therefore not just enabling limiting, but also detection. It is the first scheme of its kind that works in a decentralized manner on-chain.

E Auxiliary Theorems

The following theorem establishes that chains cannot grow too quickly. It uses the notation adopted from the backbone series [28, 29].

Theorem 4 (Chain Growth Bound)

In a typical execution, consider a round $r_0$ during which the longest chain that exists on the network has a height of $h_0$. Then at round $r_1 > r_0$, let $h_1$ denote the height of the longest chain that exists on the network. The chain cannot grow too quickly:

$$ \Pr [h_1 - h_0 > (1 + \epsilon ) (r_1 - r_0)nq \frac{T}{2^\kappa }] \le \exp (-\varOmega (\kappa (r_1 - r_0))) $$

Proof

Let us consider the case where the adversary uses all her queries (if the adversary does not use all of her queries, we can force her to do so at the end of her round and ignore the results). Then there will be nq queries per round in total, and $(r_1 - r_0)nq$ queries across all the rounds in $r_1 - r_0$. In typical executions, the longest chain on the network can only grow if a query is successful. The probability of success of a query is $\frac{T}{2^\kappa }$. The random variable $h_1 - h_0$ is hence upper bounded by a Binomial distribution with parameters $\frac{T}{2^\kappa }$ and $(r_1 - r_0)nq$, which has expectation $(r_1 - r_0)nq \frac{T}{2^\kappa }$. Applying a Chernoff bound with error $\epsilon$, we obtain the desired result.

We include the Chernoff bound, referenced at a high level throughout this paper, for completeness.

Theorem 5 (Chernoff bounds)

Let $\{X_i:i\in [n]\}$ are mutually independent Boolean random variables, with $\Pr [X_i=1]=p$, for all $i\in [n]$. Let $X=\sum _{i=1}^nX_i$ and $\mu =pn$. Then, for any $\delta \in (0,1]$,

$$\Pr [X\le (1-\delta )\mu ]\le e^{-\delta ^2\mu /2}\text { and } \Pr [X\ge (1+\delta )\mu ]\le e^{-\delta ^2\mu /3}.$$