recognize insufficient proof-of-work associated with falsified blocks and
detect the attack.

Therefore, considering the substantial hurdles for an adversary to succeed in
these powerful attacks, coupled with the likely detection of such attacks by
vigilant participants, we uphold our claim.

##### Part 1: The custodians

Procedure summary: Upon receipt of $l_{cov}=l_{enf}||l_{cust}$, each custodian
verifies the inclusion of their public key $Q_{i}$ within $l_{cust}$ and
checks if $l_{cov}$ matches with the correct subscripts 4.1 and 4.2. They
subsequently receive and validate the enforcement signatures $sig^{enf}_{l}$
for $TX^{Cov}$. Next, the custodian validates $TX^{Cov}$, which spends the
covenant-bound output generated by $TX^{Dep}$, ensuring compliance with
consensus rules. Finally, they verify the permanence of $TX^{Dep}$.

Claim: Each custodian is capable of verifying the inclusion of their custodial
public key in the covenant-bound output’s script, and the correctness of the
format of $l_{cov}$.

Vulnerability B |  A custodian might be deceived regarding the inclusion of their public key $Q_{i}$ within $l_{cust}$ or the format of $l_{cov}$.
---|---
Attack B(i) |  An attacker impersonates the depositor, altering the contents of $l_{cov}$ in $TX^{Dep}$, but then forwards the custodian a correct version of $l_{cov}$ that includes $Q_{i}$. This assault necessitates compromising the depositor’s authentication and encryption credentials.
Attack B(ii) |  Alternatively, the depositor themselves could alter the contents of $l_{cov}$ in $TX^{Dep}$ but provide the custodian with a correct version of $l_{cov}$ containing $Q_{i}$.

Based on our evaluation, even in the face of the potential attacks B(i) and
B(ii), our claim remains valid. This is because, even though a custodian might
be deceived temporarily, the permanent record of $TX^{Dep}$ in the blockchain
ensures that any deceit is eventually uncovered. Thus, each custodian is
indeed capable of confirming the inclusion of their custodial public key in
the covenant-bound output’s script, supporting the integrity of the protocol
enactment.

##### Part 2: The enforcers

Procedure summary: An enforcer generates a key-pair, $(P_{l},p_{l})$, and
transmits $P_{l}$ to the depositor. Upon receiving the transaction ID,
covenant-bound output index and amount, and $l_{cov}$ from the depositor, the
enforcer verifies the inclusion of $P_{l}$ in $l_{enf}$ and checks if
$l_{cov}$ matches with the correct subscripts 4.1 and 4.2. The enforcer then
generates $sig_{l}^{enf}$ and deletes $p_{l}$. Finally, they verify the
permanence of $TX^{Dep}$.

Claim: Each enforcer is capable of validating the inclusion of their own
enforcement public key, $P_{l}$, in the covenant-bound output’s script, and
the correctness of the format of $l_{cov}$.

Vulnerability C |  An enforcer might be deceived regarding the inclusion of their public key $P_{l}$ within $l_{enf}$ or the format of $l_{cov}$.
---|---
Attack C(i) |  An attacker may impersonate the depositor and modify the contents of $l_{cov}$ in $TX^{Dep}$. However, they send the enforcer a correct version of $l_{cov}$ that includes $P_{l}$. This attack requires the compromise of the depositor’s authentication and encryption credentials.
Attack C(ii) |  Alternatively, the depositor could alter the contents of $l_{enf}$ in $TX^{Dep}$ and provide the enforcer with a correct version of $l_{cov}$ that includes $P_{l}$.

In creating an enforcement signature, $sig_{l}^{enf}$ for $TX^{Cov}$, the
enforcer relies on a version of $TX^{Dep}$ which has a covenant-bound output
that commits to $l_{enf}$ inclusive of $P_{l}$, with the correct format for
$l_{cov}$. This signature is only valid for the said transaction. Therefore,
the impact of such attacks is that a compromised or corrupt depositor could
exclude the enforcer from the protocol. However, when comparing the version of
$TX^{Dep}$ in the blockchain to the expected version, the enforcer would
become aware of this discrepancy.

This analysis indicates that, despite potential attacks, the enforcer is
capable of validating the inclusion of their enforcement public key, $P_{l}$,
in the covenant-bound output’s script. Therefore, the claim holds true,
reinforcing the integrity of the protocol.

##### Part 3: The depositor

Claim: the depositor can exclude participants, but the misbehaviour will be
discovered, thus the integrity of protocol enactment can be ensured.

Scenario: The depositor acts as a man-in-the-middle, specifically targeting
enforcers within the protocol.

Vulnerability G |  Depositor can manipulate inclusion and exclusion of enforcers within the protocol.
---|---
Attack G |  The depositor may deceive enforcers by impersonating others, replacing $m$ genuine enforcement public keys $P_{l}$ with malicious counterparts $P^{\prime}_{l}$.
Impact G |  This allows the depositor to forge enforcement signatures, effectively nullifying the covenant activation. Honest, but excluded enforcers are aware of exclusion, but included ones may misattribute integrity to the protocol.
Countermeasure G |  Enforcers could communicate out-of-band to detect the subversion, ensuring the integrity of protocol enactment.

Countermeasure G is pivotal in safeguarding the integrity of protocol
enactment against deceptive practices by the depositor. Taking the example of
insured custody, with a 2-of-2 enforcement subscript involving an auditor and
an insurance firm, we see that this countermeasure is plausible and straight-
forward to implement. If any discrepancies are detected, the parties need only
communicate with each other, negating the impact of the attack. Therefore,
despite being a straightforward attack, it is mitigated by collaboration and
vigilance among participating enforcers.

Scenario: The depositor acts as a man-in-the-middle, specifically targeting
custodians within the protocol.

Vulnerability H |  Depositor can manipulate inclusion and exclusion of custodians within the protocol.
---|---
Attack H(i) |  The depositor may deceive custodians by impersonating others, replacing $j$ genuine custodial public keys $Q_{i}$ with malicious counterparts $Q^{\prime}_{i}$.
Impact H(i) |  The depositor controls the final authorization of the covenant transaction. Honest but excluded custodians are aware, but included ones may misattribute integrity to the protocol.
Attack H(ii) |  The depositor may deceive custodians by impersonating others, replacing $k-j+1$ genuine custodial public keys $Q_{i}$ with malicious counterparts $Q^{\prime}_{i}$.
Impact H(ii) |  The depositor can block the finalisation of the covenant transaction. Honest but excluded custodians are aware, but included ones may misattribute integrity to the protocol.
Countermeasure H |  Custodians can communicate out-of-band, allowing any excluded party to complain and ensure that all are included.

Consider a collaborative custody setting where custodians want to set-up a
multi-signature access policy with a covenant that stipulates that funds must
be sent to a specific address. Communication is expected among custodians, and
countermeasure H proves to be a simple and effective way to ensure the
integrity of the protocol enactment. Any excluded custodian would recognize
the exclusion and initiate communication with others, thereby flagging the
anomaly. This reinforces the idea that the outlined attack, although
plausible, is not necessarily detrimental. The success of countermeasure H
relies on the cooperative nature of the participating custodians and the
facility for out-of-band communication.

The presented analysis demonstrates that while the depositor has the ability
to manipulate inclusion and exclusion of participants, the defined
countermeasures can effectively neutralize these attacks. By enabling out-of-
band communication, collaboration among enforcers and custodians can ensure
the claim is upheld. This is critical to consider in the design of
applications based on deleted-key covenants.

##### Part 4: Collusion

Now, let us highlight a limitation inherent to the system: despite the ability
of each custodian and each enforcer to independently verify the integrity of
their inclusion in $l_{cust}$ and $l_{enf}$ respectively, they lack the means
to substantiate the integrity of other participants. Similarly, while
enforcers can be confident in the deletion of their private enforcement key,
$p_{l}$, they possess no mechanism to provide irrefutable evidence of such
deletion to other participants. Consequently, this necessitates certain trust
assumptions regarding custodial control and covenant enforcement, which we
shall further elucidate.

Claim: The integrity of the protocol enactment relies on a sufficient number
of custodians and enforcers remaining uncompromised. Specifically, their
authentication and encryption keys should stay secure. The protocol can
withstand the compromise of up to (but not including) $min(j,k-j+1)$
custodians, and $m$ enforcers, without the integrity of the protocol enactment
being undermined.

Vulnerability D |  Custodians deceiving the depositor and enforcers.
---|---
Attack D(i) |  Compromise authentication and encryption keys of $j$ custodians. Replace $j$ custodial public keys $Q_{i}$ with attacker-owned public keys $Q^{\prime}_{i}$.
Impact D(i) |  The attacker gains custodial control. However, $TX^{Cov}$ remains bound by the covenant enforcement. The attacker can prematurely broadcast $TX^{Cov}$, disrupting a time-sensitive protocol.
Attack D(ii) |  Compromise authentication and encryption keys of $k-j+1$ custodians. Replace $k-j+1$ custodial public keys $Q_{i}$ with attacker-owned public keys $Q^{\prime}_{i}$.
Impact D(ii) |  The attacker can refuse to authorise $TX^{Cov}$, resulting in the deposited funds being effectively burned.
Vulnerability E |  Enforcers deceiving the depositor and custodians
---|---
Attack E |  Compromise authentication and encryption keys of $m$ enforcers. Replace $m$ enforcement public keys $P_{l}$ with attacker-owned public keys $P^{\prime}_{l}$ and covertly refuse to delete the associated enforcement private keys.
Impact E |  The attacker obstructs the covenant enforcement. The attacker can generate new signatures to satisfy $l_{enf}$ for transactions that are not constrained by the covenant. However, the attacker would not be able to satisfy $l_{cust}$, and would thus not be able to spend from $TX^{Dep}$.

Upon examining the attacks D(i), D(ii) and E and their potential impacts, we
find that the integrity of the protocol’s enactment can be preserved provided
a sufficient number of custodians and enforcers are not compromised. While the
attacks undermine the integrity of the protocol enactment, they are the
minimum viable attacks. Any less than that would not undermine the integrity
of the protocol. Hence, the claim holds.

As the enforcers lack a mechanism to demonstrate to other participants whether
they have truly deleted their keys, the enforcement of the covenant requires a
level of trust among participants. To avoid this reliance on trust, each
participant should act as an enforcer and configure $l_{enf}$ as an $n-$of$-n$
multi-signature script. This would grant each participant the unilateral
authority to prevent the fabrication of malicious enforcement signatures.
Otherwise, participants need to trust that a substantial number of enforcers
remain honest. Particularly, if $l_{enf}$ is set as an $m-$of$-n$ multi-
signature script, they must trust that at least $m$ enforcers are honest.

##### Summary

In conclusion, our analysis of the integrity of protocol enactment identifies
potential vulnerabilities and the corresponding attacks that may be employed
by adversaries. Through the methodology of ‘proof by contradiction’, we have
analyzed the minimum viable attacks that might invalidate the claims
associated with various aspects of the protocol enactment integrity. We will
discuss how the identified limitations, particularly related to trust
assumptions regarding custodial control and covenant enforcement, and how out-
of-band communication among participants should be considered in practical
applications in section 4.6. Here, we summarise the salient points:

  * $\bullet$

Each participant can assess the integrity of the protocol enactment with
respect to their own inclusion, but cannot overcome the trust threshold
requirements.

  * $\bullet$

Applications which involve no out-of-band communication are likely to suffer
attacks from the depositor.

  * $\bullet$

Applications wherein participants communicate with each other can effectively
dissuade a depositor from malicious actions, or else the depositor will be
discovered. In these cases, the depositor cannot undermine the integrity of
protocol enactment without colluding with a sufficient threshold of the
enforcers or custodians.

  * $\bullet$

The integrity of the protocol enactment can only be ensured if up to (but not
including) $m$ enforces and $min(j,k-j+1)$ custodians are corrupt or
compromised.

####  4.5.5 Protect Honest Participants Against Losses

In this section of the analysis we assess how protocol participants are
protected from potential harm. We systematise the analysis with an asset-
centric approach, considering in turn bitcoin assets, identity information,
and custody system information.

##### Protection of Bitcoin

Custodians and Enforcers, who do not input Bitcoin are trivially protected
against Bitcoin loss resulting from their participation. The Depositor,
however, could potentially face theft or loss of Bitcoin. The critical issue
here is whether participating in the protocol increases the risk of such theft
or loss for the depositor. Examination of the collusion attacks presented in
section 4.5.4 reveals that the depositor could be tricked into transferring
Bitcoin to an attacker. This attacker might, at the very least, aim to render
the depositor’s Bitcoin inaccessible or, in the worst-case scenario, plan to
execute a theft transaction, thereby gaining control of the Bitcoin from the
covenant-bound output.

Vulnerability F |  The Depositor can be misled into creating a malicious custodial subscript $l_{cust}$ without including a sufficient threshold of honest custodian’s public keys.
---|---
Attack F(i) |  An attacker compromises the authentication and encryption credentials of $k-j+1$ custodians, replacing $k-j+1$ custodial public keys $Q_{i}$ with malicious ones $Q^{\prime}_{i}$. The attacker then refuses to provide signatures to satisfy $l_{cust}$.
Attack F(ii) |  $k-j+1$ malicious custodians collude and refuse to provide signatures to satisfy $l_{cust}$.
Impact F |  Honest custodians are unable to finalise authorisation of $TX^{Cov}$, making funds inaccessible. The Bitcoin deposited by the Depositor is lost.
Vulnerability G |  The Depositor can be misled into creating a malicious custodial subscript $l_{cust}$, in which a sufficient threshold of malicious custodial public keys are included. The Depositor can also be deceived into creating a malicious enforcement subscript $l_{enf}$, in which a sufficient threshold of malicious enforcement private keys are included.
---|---
Attack G(i) |  An attacker compromises the authentication and encryption keys of $m$ enforcers and replaces $m$ enforcement public keys $P_{l}$ with attacker-owned public keys $P^{\prime}_{l}$. The attacker secretly refuses to delete the associated enforcement private keys. The same attacker also compromises the authentication and encryption keys of $j$ custodians, replacing $j$ custodial public keys $Q_{i}$ with attacker-owned public keys $Q^{\prime}_{i}$.
Attack G(ii) |  There is collusion among $m$ malicious enforcers, who collectively refuse to delete their enforcement private keys, and $j$ malicious custodians.
Impact G |  The attacker circumvents covenant enforcement by generating new signatures to satisfy $l_{enf}$ for transactions that are not constrained by the covenant. The attacker can also satisfy $l_{cust}$. Consequently, the attacker gains control of the output created by $TX^{Dep}$. The bitcoin deposited by the Depositor is stolen.

Consequently, the depositor’s security relies on an underlying trust
assumption that there exists an honest threshold of custodians and enforcers,
which serves as a safeguard against potential loss. Note however that this is
no different than typical payments made with bitcoin transactions. The fact
that the payment was part of the deleted-key covenant protocol doesn’t
increase the risk associated with the depositor making the payment. Rather,
the presence of the enforcement subscript is an additional mitigation to
theft.

##### Protection of identity and custody system information

In our protocol, all public keys transmitted are fresh, meaning they are not
correlated with other public keys within the custody systems of the
participants. Since all communication occurs on pairwise channels with the
depositor, the depositor’s system will be able to associate public keys with
authentication credentials of the enforcers and custodians. The corruption or
compromise of the depositor can result in disclosed public key information
being linked to the authentication credentials of participants. However, if
the authentication details are anonymous and do not contain information about
the real identity of the participants, no identity nor custody system
information would be revealed.

An attacker that has spoofed (accessed and used the authentication credentials
of) a custodian or enforcer will receive all other participant’s public key
data in a single message from the depositor, encoded in the covenant-bound
output script $l_{enf}||l_{cust}$. This data will thus not be linked to other
participants’ authentication credentials.

An adversary gaining control over a custodian or enforcer can associate the
depositor’s authentication credentials with the data in $TX^{Dep}$. However,
since the depositor uses fresh public keys and only spends outputs that are
uncorrelated with others in their custody system, no further information about
the depositor’s custody system is revealed.

##### Summary

To conclude, in our analysis for the objective ‘protect honest participants
against losses’ we find that most participants are protected from any losses,
including theft of bitcoin or other sensitive data. The only exception is the
potential for the depositor to be deceived by collusion between custodians and
enforcers. However, this vulnerability is not a flaw within the protocol
design but rather an inherent aspect of making any Bitcoin payment. Therefore,
the objective of protecting honest participants is achieved with the
assumption that less than $m$ enforcers and $min(j,k-j+1)$ of custodians are
malicious.

####  4.5.6 Guarantee the Irrevocability of Covenant Enforcement

To guarantee the irrevocability of the covenant enforcement, it is pertinent
to dissect each enforcement condition separately and thoroughly assess the
scenarios in which they could potentially be compromised.

> a) There exists a covenant transaction, denoted $TX^{Cov}$, which encodes
> the covenant constraints. Furthermore, the witnesses field of $TX^{Cov}$ is
> populated with enforcement signatures that satisfy the enforcement subscript
> $l_{enf}$.

This enforcement condition underscores the critical necessity for the
custodian(s) to persistently store $TX^{Cov}$ and the accompanying enforcement
signatures. A loss of either entity would render the covenant-bound output
irredeemable. This predicament necessitates robust redundancy measures in
storage; this can either be achieved by entrusting multiple custodians with
the storage of $TX^{Cov}$ or, in a single custodian scenario, by preserving
$TX^{Cov}$ across various backup storage media.

> b) Each enforcement private key, denoted $p_{l}$, is deleted. As such, no
> new signatures can be generated to satisfy the enforcement subscript.

To break this enforcement condition, an attacker would need to either recover
deleted keys, or forge signatures associated with the enforcement public keys
in some other way. The difficulty of recovering deleted keys depends on the
method used by the enforcer to delete them. As discussed in section 2.4, many
deletion methods exist and a wide range of security models can be selected
from. These have been summarised in table 4.4. Applications which use
covenants often will benefit from re-using storage media and making an
efficient process for purging it (e.g. through de-gaussing) on-demand. One-
time applications with a lot of bitcoin at risk might favour destroying the
storage media.

Method |  Attack Vector | Relative Difficulty
---|---|---
Disposing |  Find the storage media | Low
Clearing |  Analyse residual charge on storage media | Medium
Purging |  Exploit failures to completely remove residual charge on storage media with advanced laboratory techniques | High
Destroying |  None | Impossible
Table 4.4: Description of attack vectors and their relative difficulty with
four generic methods to deleting sensitive data.

Note, this qualitative description of the relative difficulty of an attack is
provided to give an intuition to application designers. We did not find it
worthwhile to model the human-computer interaction for enacting the deletion
process as it would not result in a precise quantification of risk. We have
provided sufficient information for users of covenant-applications to select a
suitable method and understand its limitations.

Fortunately, Schnorr signatures have received significant attention from
security researchers and its security properties have been formalised
rigorously. Schnorr signatures are “strongly unforgable under chosen message
attacks in the random oracle model assuming the hardness of the elliptic curve
discrete logarithm problem (ECDLP)” [288, 171]. Informally, this means that
attackers can not forge new Schnorr signatures without having access to the
relevant private key, even if they are given (signature, message) pairs for
arbitrary messages. If an efficient method for solving the ECDLP emerges, then
not only would this enforcement condition be broken, but so too would the
basis of security for bitcoin transactions and more broadly much of the
security infrastructure for modern internet technologies.

> c) The deposit transaction, denoted $TX^{Dep}$, is included in a block that
> is sufficiently deep in the blockchain, such that it is highly improbable
> for the transaction to be removed or modified.

Once it is included in the chain, $TX^{Dep}$ cannot be modified or removed
without a chain reorganisation. A chain reorganisation attack is very
expensive, requiring the input of a significant amount of energy. Even in the
case where a highly motivated attacker out-competes the rest of the mining
network and removes $TX^{Dep}$ from the chain, there is nothing to stop it
from being re-broadcast and included in a future block. Only a sustained 51%
attack where $TX^{Dep}$ is continually censored would revert this enforcement
condition indefinitely.

The analysis of the irrevocability of covenant enforcement, broken down into
separate enforcement conditions, suggests that the proposed covenant scheme
maintains strong resistance against potential breaches. Redundant storage of
the covenant transaction ($TX^{Cov}$) can mitigate loss of funds risks.
Further, the deletion of private enforcement keys, paired with the robustness
of Schnorr signatures, reduces the feasibility of key recovery or signature
forgery. Lastly, the inclusion of the deposit transaction ($TX^{Dep}$) deep
within the blockchain, along with the prohibitive costs of a chain
reorganization attack, ensures the near immutability of $TX^{Dep}$.
Altogether, these measures significantly enhance the irrevocability of
covenant enforcement under the proposed scheme, given adherence to the
described protocol.

####  4.5.7 Maintain Honest Custodial Control for Covenant Execution

The final security objective is to ensure that honest custodians maintain
control for covenant execution. Since custodial power is distributed using a
$j$-of-$k$ multi-signature Script, the scenarios under which this objective is
achieved are readily identifiable.

Claim: The multi-signature custodial subscript ensures the authorization of
the covenant transaction $TX^{Cov}$ by a minimum of $j$-of-$k$ custodians. If
at least $j$ custodians are honest, the final authorization will be possible.
Conversely, if fewer than $j$ custodians are malicious, premature
authorization will not occur.

Vulnerability I |  Custodians’ key-management systems are subject to compromise.
---|---
Attack I |  An attacker may compromise $j$ custodians’ systems to extract or destroy their private keys.
Impact I |  The compromised private keys can authorize $TX^{Cov}$ prematurely or withhold authorization in a denial-of-service attack, potentially disrupting time-sensitive applications or locking the deposited funds.

However, it is crucial to note that this type of attack is not exclusive to
the deleted-key covenant protocol but is inherent to multi-signature custody
systems. The critical difference in this context is that the impact is
mitigated since the attacker cannot modify $TX^{Cov}$. This distinctive
feature, and its potential to enable new risk controls for Bitcoin custody
systems, will be explored in detail in chapter 5.

The enforcement of the access policy is ingrained within the Bitcoin consensus
rules. All nodes within the network participate in the verification process to
ensure that the signatures satisfy the custodial lock script. This mechanism
of strongly enforced access control facilitates an unambiguous understanding
of the security objective. The integrity of the process is maintained through
decentralized validation, leaving little room for interpretation or deviation.

It is pertinent to note that the description provided herein does not delve
into the intricacies of custodians’ key-management systems, nor does it
address the broad spectrum of potential attacks that custody systems might be
susceptible to. These attacks can generally be classified into two categories:
remote network attacks and physical device or person attacks. While a
comprehensive exploration of these vulnerabilities is beyond the scope of this
section, it is essential to emphasize that custodians must adhere to best-
practice key-management. This includes, for example, the utilization of
hardware device signers and the adoption of covert operations, measures that
contribute substantially to the robustness and resilience of the system.

####  4.5.8 Analysis Conclusion

In summarizing the extensive analysis presented herein, it should be
emphasized that a methodical and comprehensive approach was taken to
scrutinize the security aspects of the deleted-key covenant protocol. Four
specific security objectives were defined, each corresponding to stages of the
covenant’s life cycle, encompassing its establishment, the active period, and
the final execution. Additionally, we laid down explicit assumptions to ground
our analysis, while characterizing the potential adversary’s capabilities,
which encompass all the traits of a Dolev-Yao attacker, enhanced with the
capability to compromise the end-point devices of participants. Through this
examination, the conditions under which each objective could be satisfactorily
met were revealed. Key findings of the analysis include the following:

  * $\bullet$

An honesty assumption regarding enforcers is requisite for the protocol;
specifically, for an $m-$of$-n$ enforcement Script, at least $n-m+1$ enforcers
must be honest.

  * $\bullet$

Participants have the option to remove the aforementioned honesty assumption
by personally enacting the role of enforcer and setting the multi-signature
threshold as $m=n$.

  * $\bullet$

Though custodians can be compromised, the inherent constraints of the covenant
significantly mitigate the potential rewards for the attacker when compared to
a regular payment lacking the covenant’s restrictions.

  * $\bullet$

The disclosure of sensitive information does not pose a risk to honest
participants, particularly concerning authentication credentials and public
keys.

  * $\bullet$

It is recognized that the depositor, similar to any entity handling and
transacting in Bitcoin, remains vulnerable to theft due to potential
compromises in key management systems, as well as payment attacks where an
attacker fraudulently replaces recipient’s identity and public keys.

This conclusion affirms the robustness of the deleted-key covenant protocol,
acknowledging its strengths and identifying potential weaknesses, all grounded
in the methodological framework established at the outset of this inquiry.

###  4.6 Designing for Applications

In this section we will introduce several more details that are relevant for
practical applications using deleted-key-covenants.

####  4.6.1 Composability of Covenant Deposits and Commitments

The design space for covenant-based protocols can be extended from the simple
concept depicted in figure 4.1 by increasing the number of inputs and outputs
in a covenant transaction and by creating multiple dependent covenant
transactions. Additional covenant commitments can be joint in the sense that
each commitment must be satisfied, or can be disjoint such that only a subset
of commitments must be satisfied.

Figure 4.3 depicts a covenant transaction with multiple deposit transactions,
each of which participate in enforcing the covenant by committing to an
enforcement script $l_{enf}$ within an output. While this is possible, there
is a risk that if any of the deposits fail to be confirmed on the blockchain,
the funds could be lost. With this design, the enforcement condition should
instead read

> c) All deposit transactions have been included in a block that is
> sufficiently deep in the blockchain to not be removed or modified.

Figure 4.4 depicts joint covenant commitments by constructing a chain of
dependent covenant transactions. Recall that transactions that spend only P2TR
output types ensure that transactions are not malleable, such that their
transaction ID can not be changed. This is critical because references to
previous outputs in the chain of dependent transactions use the transaction
ID, and if this could be modified then the subsequent transactions would be
invalidated. Since the enforcement private keys are deleted, no alternative
transactions can be finalised to spend those outputs, and they would be
indefinitely locked. Here, $TX^{Cov}$ $1$ must be broadcast before $TX^{Cov}$
$2$ would be considered valid. Therefore, the constraints encoded by both
transactions must be met in order to satisfy the full covenant and regain
arbitrary spending capability with the funds. Another way to achieve joint
commitments would be to add each constraint to the lock Script of an output in
a single covenant transaction.

Figure 4.5 depicts disjoint covenant commitments. There is a choice with which
set of constraints to adhere to, either those encoded by $TX^{Cov}$ $A$ or by
$TX^{Cov}$ $B$. The confirmation of either transaction invalidates the other.
Another way to achieve a disjoint commitment would be to use conditional logic
in the lock Script of an output in a single covenant transaction.

Each of these concepts (multiple deposits, joint and disjoint covenant
commitments) can be combined arbitrarily to produce multiple dependent chains
of covenant transactions in a tree-like structure. Moreover, covenant
transactions can be constructed with arbitrary numbers of inputs and outputs
provided that transaction size limits are adhered to. In this way, application
designers can construct state-machines from transaction sets. Custodians
control the transition choices and timing by authorising the broadcast of the
next transaction in the tree. State can be encoded in a transaction with
various methods, described and empirically analysed by Bartoletti et al.
[240].

While infinitely recursive covenant transactions are not possible (with
deleted-key covenants), a chain of covenant transactions of arbitrary length
is possible. The chain must be pre-defined since each covenant transaction
depends on a previous transaction. Creating the unsigned transactions requires
generating the enforcement public keys and knowing the custodial public keys.
Each enforcer must be involved from the beginning and the amounts for each
transaction and the specific constraints of each covenant commitment must be
known in advance.

Figure 4.3: A covenant transaction with three inputs that spend outputs in
different deposit transactions. Each output commits to an enforcement script
$l_{enf}$ and requires sufficient enforcement signatures to be spent. All
deposits must be confirmed for the signed covenant transaction to become
active. Figure 4.4: A chain of covenant transactions whose constraints are
joint in that each must be satisfied to spend the funds which they control.
All covenant transactions with dependent transactions must be non-malleable to
protect their dependent transactions from being invalidated. Figure 4.5: Two
covenant transactions which spend from the same deposit output are considered
to have disjoint commitments in that either $TX^{Cov}$ $A$ or $TX^{Cov}$ $B$
must be satisfied while the other is invalidated.

####  4.6.2 Class of Possible Covenants

It should be clear that the class of possible covenants is predominantly
restricted by the parameters of a transaction template. This means that
traditional covenants such as those based on the operational capacity of a
business could only be implemented by use of an oracle who would validate data
external to the blockchain and then either authorise (or refuse) the covenant
transaction. Without oracles, deleted-key covenants can have commitments that
only require validating internal blockchain and transaction data, since each
Bitcoin node has the capacity to independently validate transactions (and
transaction chains). Constructing a condition that relies on external
validation requires participation from an oracle but this introduces some
trust assumptions that weaken the security model of the covenant. Script does
not enable explicit requests to external servers, nor does it enable importing
mutable state variables. A basic mechanism for enabling an oracle is to give
them a necessary signing key in the enforcement Script, and design them to
only provide the signature to authorise the transaction once some condition in
the external world has been met. Some issues that arise with the use of
oracles include; they can be hacked, bribed, or be poorly designed and return
incorrect outputs, or they can go offline and a required private key can
vanish leading to a loss of funds. Well designed oracles may rely on a
consortium of independent signatories to introduce Byzantine fault-tolerance.
Moreover, signatories may be instantiated on secure hardware for trusted
computing. A more advanced oracle mechanism is Discreet Log Contracts [112]
and it is being actively researched. Integrating external validation methods
is a topic for future research.

Covenants that require only internal validation are our focus here. Bitcoin
transaction signatures can be set to commit to different signature message
types, allowing for some selection for which subset of transaction data are
included. The subsets were shown explicitly in section 4.2.3. Recall that
chains of dependent transactions must avoid malleability to prevent the risk
of indefinitely locking bitcoin. However, the final transaction in a chain can
safely be modified because no subsequent transactions depend on it having a
static transaction ID. Covenant transactions may be defined long before they
are broadcast, and enabling some modification of the transaction without
invalidating the signatures could be useful in some contexts. For example, to
help with dynamically allocating fees, or to adjust how much change is
returned to the one paying.

A minimally constrained deleted-key covenant transaction would use the
A1CP||NONE signature type and, referring to table 4.3, the enforcement
signature(s) would commit to the transaction version and the data for a single
input (except its index). The enforcement signature(s) would be valid for any
transaction that shares that subset of data; the outputs and other inputs are
free to change. This particular usage is unlikely to be broadly useful since
the only restriction the covenant could have is on the transaction version and
the input’s sequence and annex fields.

A maximally constrained deleted-key covenant transaction would use the ALL
signature type and the enforcement signature(s) would commit to every field of
the transaction, except the witnesses field. Most of the power of this type of
covenant comes from the locking Script associated with each output. One can
specify that a given set of inputs can only be spent to a set of output
addresses whose amounts are well defined and whose unlocking scripts are any
set of constraints specifiable in Bitcoin Script.

A partially constrained deleted-key covenant transaction could use the
A1CP||ALL signature type and the enforcement signature(s) would commit to
every field of the transaction except for other inputs and the witnesses
field. This would allow additional inputs to be added by custodians without
invalidating the enforcement signature(s). Since the outputs are fixed, adding
new inputs increases the fee paid to miners. Since the fee-market is driven by
current demand and is dynamic, this method can be useful to application
designers.

For enforcement signatures with the type SINGLE, the enforcers commit to all
inputs and a single output. New outputs can be added to the transaction. This
means that custodians can update the output set to handle any excess bitcoin
that is not directed to the fixed output. Again, an example use-case for this
is to adjust the fee by adding a change output immediately prior to
broadcasting the transaction.

Thus we have seen why signature message types play an important role in
defining what class of covenant commitments are possible. Note that all
signature message types are possible: ALL, A1CP||ALL, SINGLE, A1CP||SINGLE,
NONE, and A1CP||NONE. This approach is a hack because the signatures message
types were not designed for this purpose. With a more efficient and flexible
way to get verified transaction data onto the execution stack, the class of
possible covenants would be more broad. Other covenant mechanism proposals
differ from what is presented here.

####  4.6.3 Dynamic Fee Allocation

There are two mechanisms in Bitcoin for increasing the fee paid in a
transaction if the transaction becomes stuck in the memory pool due to having
a low fee-rate (in satoshis/kb) relative to others in the pool; ‘replace-by-
fee’ (RBF) [148] and ‘child-pays-for-parent’ (CPFP). Application designers
should consider both CPFP and RBF, and the best approach might involve a
combination of the two.

RBF is a signalling mechanism that alerts miners that a transaction may be
replaced by an equivalent one with a higher fee. Miners and nodes opt-in to a
policy of detecting RBF-enabled transactions and updating their memory pool if
certain conditions are adhered to. For example, the replacement transaction
must have a higher absolute fee, and the fee must be sufficiently high to
cover the additional bandwidth cost imposed on the network by the replacement.
See the BIP for a precise specification of conditions [148]. Miners have an
incentive to claim the higher fee replacement if they are aware of it. Note
that the replacement conditions are only policies set by each node but they
are not consensus rules. A replacement transaction may be consensus-valid but
nodes may still reject to propagate it. The replacement conditions are
designed to protect the peer-to-peer network from denial-of-service attacks.
However, if a replacement transaction is sent directly to a miner, that miner
may include it in their block despite it not adhering to the replacement
conditions.

CPFP became the default transaction selection method for block building in
Bitcoin Core $v0.13$. Bitcoin’s consensus rules enforce a strict ordering of
transactions in the blockchain. However, transactions which depend on an
unconfirmed transaction can be included in the same block as its ancestor
(parent) as long as it appears later in the block. Thus, if an unconfirmed
transaction has a small fee, but its child transaction has a fee large enough
to cover itself and the unconfirmed parent transaction, miners have an
incentive to include both in a block. If there is a chain of unconfirmed
covenant transactions in the memory pool, the final transaction can pay for
the whole chain, but the whole chain will appear in the same block. If a
transaction chain is to be broadcast across multiple blocks, then so-called
‘CPFP outputs’ should be added to each transaction. CPFP outputs are
additional outputs that are controlled by a key the user has for fee
management. The CPFP output itself need not have any value (in satoshis), but
it can be consumed in a ‘fee-bump transaction’ that pays for itself and the
unconfirmed parent transaction. This allows the transaction chain to progress
even if the market fee-rate hikes.

####  4.6.4 Safety Concerns

There are three classes of attack that application designers must be aware of
when using different signature message types; transaction ID malleability
attacks, pinning attacks, and theft. If a transaction is consensus-valid but
none of the required signatures used ALL, then some part of the transaction
can be modified without invalidating it, in some cases enabling these attack
vectors.

Generally, ‘pinning’ is a class of attacks in which the attacker takes
advantage of an aspect of network topology, transaction relay and/ or memory
pool policies to prevent timely inclusion of a transaction in a block. An
example is when a user broadcasts a transaction with an A1CP||ALL-type
signature and with RBF enabled, with the intention of adding an additional
input to increase the fee if the transaction is low-priority in the
transaction queue. However, an attacker can add low-value (in satoshis) inputs
with large size (in kb) to the transaction and re-broadcast it. If the
absolute fee is sufficient, nodes in the network (by default in bitcoin-core
v23.0) will accept the replacement and propagate it. However, the fee-rate
(fee per kb) will be very low, making it low priority for miners to include in
the blocks they produce. Pinning attacks create risks in many off-chain
transaction protocols [217, 249, 271].

Transaction ID malleability attacks are disruptive for chains of dependent
covenant transactions. An attacker modifies any part of an intermediate
transaction in the chain, resulting in a different Transaction ID. In doing
so, all subsequent covenant transactions become invalid, and the bitcoin they
control is effectively burned.

Theft is a possible attack vector if a transaction is signed with SINGLE and
broadcast. An attacker could add an output to the transaction to redirect to
them-self any residual value that is implicitly allocated as a fee. Miners
that detect such a transaction will not gain from this type of attack since
the fee is already directed to them-self. However, with RBF enabled, any
listener on the network can broadcast a replacement transaction and the theft
is likely to succeed.

Without RBF enabled, attackers would not be able to broadcast a replacement
transaction. However, modified transactions would still be consensus-valid.
The thief would have to collude with a miner to get it included. An attacker
would have to offer something sufficient to the miner in return. However, the
miner that creates the next block is probabilistic, not deterministic. An
attacker would have to collude with several powerful miners to have a
reasonable likelihood of success. Thus we see how, in general, not enabling
RBF is a strong mitigation for these classes of attack.

####  4.6.5 Fee Strategy

Given the general approaches and safety concerns discussed in previous
sections for increasing transaction fees, we now move on to discuss those
methods in the context of deleted-key covenant transaction applications.

To be safe, partially constrained covenant transactions should be protected by
a non-empty custodial script $l_{cust}$ for which custodians provide ALL-type
signatures. Application designers should determine their tolerance for
malleability or pinning attacks and act accordingly. A more secure design,
where ALL-type signatures are used would be less flexible. A more flexible
design in which, for example, new inputs or outputs can be added, would be
less secure to rely on. Thus there is a security-flexibility trade-off for
satisfied (fully-signed, consensus-valid) covenant transactions.

On the other hand, for covenant transactions that are not completely satisfied
(and not yet consensus-valid) that trade-off is not present. For example,
enforcers can safely use any signature types, enforcing only the constraints
which they require, relying on custodians to satisfy covenant transactions
with ALL-type signatures. Enforcers can grant flexibility to custodians, but
custodians must not grant flexibility to potential attackers. Moreover, some
custodians can grant flexibility to others, but a sufficient threshold of
custodians must use ALL-type signatures to maintain safety when broadcasting.

In table 4.5, we summarise several methods for increasing the fee with
deleted-key covenants. The signatures $sig_{l}^{enf}$ and $sig_{i}^{cust}$ are
created by enforcers and custodians respectively. The pre-broadcast method
highlights how to increase the fee before the transaction is transmitted to
the peer-to-peer network. The post-broadcast method highlights how to increase
the fee for transactions that have been broadcast but are low-priority in the
memory pool. If the method is safe to use given that the covenant transaction
has dependent covenant transactions, then ‘works with dependent $TX$’ is
marked ‘Yes’, otherwise ‘No’. Finally, we show whether or not pinning and
malleability attacks are possible.

The Fee input(s) and Change output(s) strategies are safe to use for single
covenant transactions, but not for chains of covenant transactions (except for
the final one).

The CPFP output(s) strategy is probably the most adaptive, since it works for
chains of covenant transactions across multiple blocks, and can in principle
handle any market fee-rate scenario. It requires broadcasting a second ‘fee
transaction’, relying on the CPFP mechanism to pay for itself and the parent
covenant transaction. The fee transaction can also enable RBF in case it needs
to be replaced with a higher fee. If the CPFP output is not required and not
consumed, this could lead to an increase in the set of unspent transaction
outputs, which has to be maintained in memory by all nodes in the network.

The ‘prepare fee range’ strategy requires the user to sign several variants of
a covenant transaction with a range of fees, anticipating broad changes in the
market fee-rate. The more variants that are signed within a range, the more
accurate the fee-rate will be to current market conditions. However, each
signature is a burden for the user to generate (especially if they are using
an offline signing device). For a chain of covenant transactions of length
$t$, if each one is prepared with $p$ variants, then $p^{t}$ covenant
transactions must be prepared. This is because each covenant transaction is
bound to a specific variant that it is spending from and so $p$ variants must
be created for each new dependent covenant in the chain for all $p$ variants
of the previous covenant. This scales exponentially poorly in both storage and
computation required for signature generation.

If none of the required signatures from the custodians use the ALL type, as
with the ‘unsecured fee input(s)’ method, then the covenant transactions will
be at risk of both pinning and malleability attacks. It is not suitable for a
chain of dependent transactions. It is reasonable to enable RBF in a case
where the timeliness of including a transaction in a block is not critical.
While the transaction would be at risk of being pinned, it would likely be
included in a block eventually.

Strategy |  $sig_{l}^{enf}$ type |  $sig_{i}^{cust}$ type | Pre-broadcast | Post-broadcast | Works with | Pinning | Malleability
---|---|---|---|---|---|---|---
Name |  |  | method | method | Dependent | attacks | attacks
|  |  |  |  | Txs |  |
Fee | A1CP||ALL | ALL | Add inputs, | Use RBF, add inputs, | No | No | No
input(s) |  |  | new $sig_{i}^{cust}$ | new $sig_{i}^{cust}$ |  |  |
Change | SINGLE | ALL | Add/ modify | Use RBF, add/ modify | No | No | No
output(s) |  |  | unenforced outputs, | unenforced outputs, |  |  |
|  |  | new $sig_{i}^{cust}$ | new $sig_{i}^{cust}$ |  |  |
CPFP | ALL | ALL | Fee TX | Fee TX with RBF | Yes | No | No
output(s) |  |  |  |  |  |  |
Prepare | ALL | ALL | Prepare TXs with | Use RBF, prepare TXs | Yes | No | No
fee range |  |  | range of fees | with range of fees |  |  |
Unsecured | A1CP||ALL | A1CP||ALL | Add input(s) | Use RBF, add input(s) | No | Yes | Yes
fee |  |  | and witness(es) | and witness(es) |  |  |
input(s) |  |  |  |  |  |  |

Table 4.5: Comparative summary of strategies for allocating fees to deleted-
key covenant transactions.

####  4.6.6 Proof-of-Reserves

Financial auditing often requires verifying claims that an entity has access
to funds. With Bitcoin, so-called ‘proof-of-reserve’ protocols exist for this
purpose. In the simple case, the claimant aims to demonstrate their ability to
spend an unspent transaction output, $u$. As per the proof-of-reserves
protocol described in [272], the claimant can construct an invalid transaction
(e.g. one which creates more bitcoin than it consumes) that consumes $u$ and
generate a valid signature to satisfy the associated lock script. The invalid
transaction and signature together can be safely shared with the auditor for
verification, demonstrating that the claimant can generate similar but valid
transactions that consume $u$.

For funds that are bound by deleted-key covenants, the proof-of-reserves
protocol must be adapted slightly. The custodians have control of $TX^{Cov}$
with witnesses that satisfy $l_{enf}$, but they cannot generate signatures to
satisfy $l_{enf}$ with a different transaction. However, as long as $l_{cust}$
is not empty, $sig_{l}^{enf}$ can be shared with an auditor without granting
them the ability to finalise $TX^{Cov}$ for broadcast. Given this, the
custodian must:

  1. 1.

Enact the simple proof-of-reserves protocol for a fake output with $l_{cust}$
as its lock script,

  2. 2.

Share the enforcement signature(s), the lock script
$l_{cov}=l_{enf}||l_{cust}$, and $TX^{Cov}$ with the auditor.

Now the auditor can verify each signature and confirm the validity of
$TX^{Cov}$. Note that the auditor has no guarantee that the covenant
commitments will be enforced, since they have no proof that the enforcement
private keys were deleted.

###  4.7 Covenant Mechanism Comparison

Here we will consider three plausible soft-fork upgrade paths for Bitcoin
which would enable consensus-enforced covenants. By ‘consensus-enforced’ we
mean that one or more consensus rules would need breaking to break the
enforcement of the covenant. By definition, consensus rules are those followed
by all peers in the network. Each node in the network verifies that
transactions and blocks adhere to consensus rules, or else they fall out of
consensus with the network. On the other hand, deleted-key covenants are
enforced by the deletion of enforcement keys, which cannot be verified without
interactive participation during the activation of the covenant. Consensus-
enforced covenants remove this requirement altogether, they are verifiable.

These three plausible soft-fork upgrades each have a code implementation and
are actively being debated among Bitcoin developers and enthusiasts;
ANYPREVOUTANYSCRIPT (APOAS) [100], OP_CHECKTEMPLATEVERIFY (CTV) [253], and
OP_INSPECT_X (INSPECT_X) [168]. CTV and APOAS are very similar to each other
and to deleted-key covenants in the class of possible covenants they enable.
There are minor differences in what subsets of transaction data can be
committed to. These are summarised in table 4.6.

The signature checking operations use modified signature message types when
APOAS is used. The primary differences are that A1CP is set by default (only
the current input is included) and the output’s hash, index, public key script
and the TapScript’s leaf hash are not included in the message. The downside of
this design is that pinning attacks are ever-present. This is becuase
adversaries can freely add data-heavy inputs to the transaction and, in the
worst case when RBF is enabled for the transaction, adversaries can propagate
their replacement transaction across the peer-to-peer network. It has been
suggested to make the A1CP functionality optional instead [96], which would
prevent this pinning attack vector.

The property that is lacking with CTV and APOAS is granularity. INSPECT_X
enables granularity for covenant constraints in that any transaction, input or
output field can be constrained. This enables a much broader design space for
covenants.

Mechanism | Class of possible covenants
---|---
Deleted-key | Constraints on choice of signature message type:
|  ALL, SINGLE, NONE, ALL||A1CP, SINGLE||A1CP, NONE||A1CP
APOAS | Constraints on choice of modified signature message types:
|  APOAS:ALL, APOAS:SINGLE, APOAS:NONE
CTV | Constraints on default transaction template (initial version),
| subset templates (later versions)
INSPECT_X | Constraint on field X
Table 4.6: Comparison of the class of possible covenants for several covenant
mechanisms.

Another critical difference between the three alternatives is in which dynamic
fee allocation methods they support. In comparison with table 4.5, APOAS
covenants can make use of the more efficient and intuitive strategies ‘Fee
input(s)’ and ‘Change output(s)’ but with the benefit that they work with
dependent chains of transactions. It does not matter if transaction IDs change
with intermediate transactions in a dependent chain since references to
previous transactions are omitted from signature messages. Recall that the
covenant transactions should require custodial signatures, $sig_{i}^{cust}$,
with type ALL to prevent pinning and malleability attacks, while the
enforcement signatures, $sig_{l}^{enf}$ can choose any type. Covenants with
INSPECT_X can use the same fee allocation strategies as APOAS covenants.
However, CTV covenants commit to all parts of the transaction, and must
therefore not modify any intermediate transactions in a dependent chain. The
best available approach in this case is to use ‘CPFP output(s)’ or to prepare
multiple covenant transactions with a range of fees and to commit to each one
in a separate TapScript branch.

The enforcement subscripts are shown for each mechanism in table 4.7. These
mechanisms have different relative performances measured by the size of their
scripts and in the verification cost of the script. Both APOAS and CTV commit
to a large subset of transaction data efficiently (via a signature or a hash),
encompassing numerous constraints on the transaction. The primary cost of
verifying the APOAS enforcement subscript is one signature verification. The
primary cost of verifying the CTV enforcement subscript is producing one
transaction message hash. For INSPECT_X to commit to the same subset as either
APOAS or CTV, it would require several constraints to be added in the
enforcement subscript and would be a rather large size. This is a downside for
having primitive operations instead of procedural-macro operations, and it
reveals a trade-off for granularity. However, INSPECT_X constraints do not
require signature or hash operations, meaning that the verification cost is
significantly lower.

Soft-fork name | Enforcement subscript
---|---
APOAS |  <sig> <PK> CHECKSIG
CTV |  <tx hash> CTV
INSPECT_X | INSPECT_X <target_value> EQUAL_VERIFY
Table 4.7: For each proposed soft-fork upgrade, the covenant enforcement
subscripts, which are part of the lock script, are shown.

Concerns have been raised about recursive covenants making Bitcoin contracts
‘Turing-complete’ [295]. It is broadly accepted that Script programs must
terminate, or else there would be high risk of denial-of-service attacks on
nodes which run those programs, and ultimately on the entire peer-to-peer
network. The development community prefer that Script is not Turing-complete
since the halting problem [195] (knowing if a program will terminate or not)
is unsolvable for Turing-complete languages. However, with recursive
covenants, multi-transaction Bitcoin contracts may become Turing-complete. In
our opinion, this is not a problem because the throughput of transactions is
limited by available block space and each transaction requires a fee. Thus a
denial-of-service attack in this case amounts to paying significant amount in
fees to overwhelm the memory pool with transactions. Such an attack is very
costly to maintain. An attacker can create an infinite loop (a recursive
covenant without an exit-path), but the progress of this infinite loop will be
incremental, transaction by transaction. A node which is validating
transactions in this infinite loop will not need to perform infinite
computation in a finite time period. The node’s resource limits will not be
surpassed because it will automatically restrict the number of transactions it
retains in memory to protect itself. It is not necessary to prove that the
infinite chain of transactions will terminate, as is prevented by the halting
problem.

###  4.8 Conclusion

In this chapter we introduced the deleted-key covenant protocol. A series of
security objectives for the protocol were proposed and subsequently analysed
to discern the precise circumstances in which they can be accomplished, given
a set of predefined assumptions and a threat model outlining the potential
capabilities of an attacker.

The study revealed that the resilience of the deleted-key covenant protocol
against formidable attacks can be substantially enhanced with proper
parameterisation of the multi-signature thresholds within both the covenant
enforcement subscript and the custodial subscript. This insight serves as a
crucial foundation for designing and implementing secure and efficient
applications based on deleted-key covenants.

Additionally, this chapter offered a detailed examination of the critical
aspects of engineering applications that rely on deleted-key covenants,
including the safe composability of covenant transactions and the maintenance
of the described security model. A classification of possible covenant
commitments was presented, drawing attention to pertinent safety concerns
related to modifying covenant transactions. This analysis was instrumental in
our evaluation of dynamic fee allocation methods for deleted-key covenant
applications, a summary of which was encapsulated in table 4.5. The potential
of extending the basic proof-of-reserves protocol [272] for deleted-key
covenants was explored, although the requisite interactivity with the verifier
during the protocol was identified as a significant drawback.

Finally, through a baseline comparison with deleted-key covenants we revealed
insights about alternative covenant proposals; comparing the class of possible
covenant commitments, differences with dynamic fee allocation methods, and
relative size and verification cost of each.

In line with the objectives outlined in the introductory chapter, this
investigation has successfully achieved the goal to ‘Design and analyze a
novel covenant protocol that works with state-of-the-art Bitcoin features’, as
well as to ‘Provide a comparative analysis of alternative covenant
constructions’. Moving forward, the forthcoming chapter will introduce a
custody protocol that leverages the deleted-key covenant protocol, further
extending the practical applications of this research. Thus, the exploration
and refinement of Bitcoin covenants continues.

##  Chapter 5 Ajolote: Custody with Bitcoin Vaults

In this chapter we present Ajolote, a custody system that uses Bitcoin vault
covenants. We specify the system primarily as a series of message sequence
diagrams where the human-interaction is explicitly included. We evaluate the
state dynamics of the system and its on-chain privacy properties. We compare
the system with industry-standard multi-signature custody systems to explain
how vault covenants can improve the state-of-the-art. By following the
‘ceremony analysis’ methodology, we construct a risk model for the system. The
specification and analysis include the system setup, operation, and recovery
(to handle attack on and failure of system components). Finally, we provide
new insights into the ongoing debate about consensus-enforce covenants in
Bitcoin. This chapter addresses thesis objective O3 (see 1.2).

###  5.1 Introduction

####  5.1.1 Overview

Ajolote is an autonomous custody system, constructed to provide robust
protection for individuals—referred to as the users—who hold substantial
wealth in bitcoin. It is a theoretical design and no implementation has yet
been developed. The custody system derives its name from the Ajolote, an
amphibian renowned for its unparalleled regenerative abilities, including the
restoration of its limbs and even its head. This aptly characterizes the
inherent resilience of the Ajolote custody system, which preserves its
operational integrity even in the face of the failure or compromise of
individual signing devices. Like the amphibian, the system is designed to
‘regenerate’, continuing to function effectively amidst adverse conditions and
thereby reinforcing its reliability as a bitcoin custody solution.

A comprehensive custody system facilitates the holding, management, and
spending of bitcoin. This system should have rigorously defined procedures for
its setup, operation, and recovery in case of a compromise or failure. Ajolote
embodies such a system with multiple defensive layers, thereby conferring
resilience to both failure and compromise. It builds upon the foundations of
standard multi-signature custody systems but distinguishes itself through the
innovative application of the novel deleted-key covenant protocol, as detailed
in the previous chapter.

As operational prerequisites, the user must have access to four separate safe
locations and be in possession of a mobile and four distinct hardware signing
devices. A simplified entity diagram is shown in figure 5.1. The Ajolote
system classifies accessibility into three distinct tiers, as depicted in
figure 5.2.

Figure 5.1: Entity diagram for the Ajolote custody system. Dashed boundaries
represent distinct physical security environments. Solid boundaries represent
distinct devices. Inside, their type and primary system function is noted
(e.g. type: Hardware signer and function: signer 2). The ‘User’ environment
represents the user’s physical location, which often will overlap with their
Home or Office environment, and on rare occasions may overlap with the Bank A
and Bank B environment. The Bitcoin peer-to-peer network is represented with
the dotted box. There are $W$ watchtowers, each in a distinct physical
location and physical security environment. Figure 5.2: Three distinct risk-
accessibility tiers in Ajolote. Tier 1; $2$-of-$3$ multi-signature controlled
by the user. Tier 2; Vault covenant which can only pay to Tier 2 or Tier 3.
Tier 3; $3$-of-$5$ multi-signature controlled by the user.

With each increase in accessibility comes an increase in risk of compromise.
Tier 1 is utilised for a minor proportion of the total balance, with the
majority of funds sequestered in Tier 2. A streamlined procedure is in place
to transition to Tier 3, if necessary. Tier 1 adopts a $2-$of$-3$ signature
access policy, while Tier 2 can also be accessed with a $2-$of$-3$ signature,
provided a time-lock has expired. Tier 3 employs a $3-$of$-5$ signature access
policy and is reserved as a fall-back system for failure and compromise
scenarios.

A watchtower is an automated server for network monitoring and response. By
default, the user engages one or more third-party watchtower
providers111Proficient users with expertise in server administration may opt
to deploy their own watchtower(s). to enforce a withdrawal policy from Tier 2.
If that policy is breached, the watchtower or the user can trigger a fallback
procedure from Tier 2 to Tier 3, provided they act before the time-lock
expires. Accessibility and risk of compromise would be reduced, thus enhancing
security. The watchtowers do not possess the ability to access funds directly,
they only have the power to trigger the fallback procedure from Tier 2 to Tier
3.

Ajolote obviates the need for seed backups. Instead, the system offers
resilience to a loss or theft of up to two signers. Furthermore, Ajolote
comprises a set of recovery procedures to invalidate a lost signer and
initialise a new one. This allows the user to regain strong safety and
security if up to two signers are lost or stolen.

Though Ajolote is designed to function within the current consensus
constraints of Bitcoin Core v24.0, its efficiency and security could be
enhanced if granular, consensus-enforced covenants were introduced to Script
via a soft-fork upgrade.

####  5.1.2 Covenant Pattern

The fall-back procedure is implemented with two types of covenant, which have
a distinct transaction pattern and functional behaviour. The first type is a
pay-to covenant, a constraint on the redeeming transaction to create an output
with a pre-defined amount and destination.

The second type is a vault covenant, a constraint on the redeeming transaction
to create an output with two spend paths: one time-locked path, and one
immediate path. In Ajolote, the time-locked path can be used to send bitcoin
to Tier 1, while the immediate path uses a pay-to covenant with the fall-back
address of Tier 3 as its destination. The time-lock grants the user and its
watchtowers time to observe the withdrawal attempt and to react by allowing or
disallowing it. Watchtowers enforce withdrawal constraints composed of
arbitrary rate-limits or permitted transacting hours. The fall-back address
has a stricter access policy and is thus used to enhance security.
Simultaneously, the fall-back address has a larger key-set and is thus used to
enhance safety.

####  5.1.3 Related Work

Besides the more general work on custody specifications and risk modelling
discussed in chapter 3, there are several related works which influenced the
design of Ajolote. The idea of a Bitcoin vault covenant was introduced by
Möser et al. [213]. The focus was on the technical mechanism for how to
achieve the vault pattern, but lacked a deeper discussion of a complete
custody system design and the benefits it yields. The technical mechanism
required powerful new Script commands.

In other work, McElrath introduced the basic idea of using a specific type of
deleted-key covenant to enforce a vault [206]. The sketched mechanism had a
weakness in that the key deletion process was a single-point of compromise.
The primary benefit here was compatibility with the existing consensus rules
in Bitcoin. However, there was no formal description nor analysis of the
mechanism. Moreover, a custody system design was not present.

Hommel implemented a prototype of this deleted-key mechanism for a hardware
signing device [157]. This was a practical study on the data type requirements
for message passing between signing devices and transaction coordination
applications in the context of deleted-key covenants. Compatibility of
hardware signing devices with covenants remains as a barrier for a real-world
deployment.

Bishop developed a prototype implementation for constructing trees of pre-
signed transactions with support for deleted-key vault covenants and their
Script implementation [76]. Bishop noted the importance of compartmentalising
funds in several separate ‘vaults’, to prevent putting the user’s entire
balance at risk once the time-lock expires. Indeed, this is a critical insight
for designing a complete custody system based on vaults.

The foundational concepts and insights presented in this chapter draw
inspiration from a collaborative effort between myself, McElrath, Bishop, and
Hommel. This collaboration led to the development of two papers focusing on
Bitcoin covenants [266] and vault-based custody [267]. While these papers
provided a foundation, the corresponding chapters in this thesis are not
merely reproductions. As noted in section 1.3, with the consent of my
collaborators, I have substantially revised, corrected, and extended these
earlier works. This involved updating to reflect the current state-of-the-art,
enhancing methodology, and conducting new analyses and evaluations. This
adaptation serves to refine our collective understanding and to provide a more
comprehensive and nuanced perspective on the subject at hand.

As part of a series showcasing Sapio, a development framework for creating
multi-transaction Bitcoin contracts, Rubin implemented a vault covenant (where
the precise covenant mechanism is abstracted) [252, 254]. Rubin introduced a
variation on the standard vault covenant, a ‘structured liquidity vault’. In
this case, a sequence of transactions is kept wherein each transaction unlocks
a portion of the total balance. Imagine a sequence of $n$ transactions and
total balance, $B$. Each transaction releases $B/n$ bitcoin to the user and
keeps the rest in the vault sequence. Each transaction has a time-lock $T$.
This way, ‘liquidity’ is structured to $B/n$ every $T$ blocks. The practical
issue here is that the liquidity structure must be pre-specified, and both
user’s requirements and the price of Bitcoin can vary significantly in short
time frames.

The vault pattern is typically used as a demonstrative example of a covenant
mechanism. O’Connor and Piekarska described how to implement one with their
CHECKSIGFROMSTACK covenant mechanism [226]. Bartoletti et al. used the vault
pattern to demonstrate their formal model of Bitcoin contracts. More vault
prototypes where implemented by O’Beirne [223] and Poinsot [239] for the
covenant mechanisms CTV and APOAS, respectively. Kirstein et al. implemented a
vault with Ethereum smart contracts and evaluated it with formal specification
and verification methods [173]. However, while useful for understanding the
mechanisms, these demonstrations do not necessarily translate into effective
custody solutions.

The Revault custody system uses a type of vault, relying on a strict multi-
signature policy and pre-signed transactions rather than a covenant mechanism.
Unlike the rest, Revault has a comprehensive design specification [12] with
production-grade implementation libraries and a software application [13].
This system was designed specifically for enterprise multi-party usage.

An open-source project ‘Bitcoin Contracting Primitives Working Group’ is
building a repository of related resources and consolidating research efforts.
Vaults is one of the use cases discussed and analysed [1].

####  5.1.4 Contributions

The focus of this chapter is to explore the question, ‘How can the
introduction of vaults into a custody system enhance its capabilities and
improve upon the state-of-the-art?’. For this, a detailed specification of a
custody system is required along with a comparison against its equivalent
without a vault. Moreover, limitations and risks are created with the
introduction of vaults to custody systems and these have yet to be explored in
detail. Finally, while vaults are a typical example of the benefits of
consensus-enforced covenants in Bitcoin, no study on precisely what benefits
are gained has been carried out. This chapter addresses these issues.

Introducing Ajolote: In section 5.2 we introduce and specify Ajolote, a vault-
based custody system, detailing every component and procedure for the setup
(5.3), operation (5.4), and recovery (5.5) phases.

Evaluating the Design: In section 5.6 we evaluate this design in several ways.
We validate the specification of Bitcoin Scripts by using the Miniscript
compiler. We describe an operational model to understand the state dynamics
and demonstrate important trade-offs. We analyse the privacy properties
associated with Ajolote transaction sequences and our use of taproot trees to
encode Bitcoin Script. We compare Ajolote with the closest equivalent custody
systems which do not use covenants or the vault pattern and offer clarity on
the strengths and weaknesses of the vault pattern.

Risk and Threat Modelling: With section 5.7 we present a comprehensive risk
model that spans the entire life-cycle of the custody system and propose a
realistic threat model which, we argue, captures realistic attacker
capabilities.

Exploration of Covenant Mechanisms: Finally, in section 5.8, we explore some
expected fundamental differences that derive from the choice of covenant
mechanism to determine how consensus-enforced covenants can improve Ajolote
and similar systems. Notably, we present a plausibility argument that only
granular covenants can fix coin control issues that arise with using the vault
pattern.

####  5.1.5 Objectives

In designing Ajolote we set several objectives.

  * Autonomous: The user is the only entity that can initiate withdrawals and make external payments. No third-party can prevent this.

  * No single point of failure (SPOF): Any single hardware device, sensitive datum, or software program may fail or get lost, but the custody system will remain safe and available to the user.

  * No single point of compromise (SPOC): An attacker may compromise any single hardware device, sensitive datum, or software program, but the custody system will remain secure and available to the user.

  * Usable: The procedures to setup and operate the custody system will be sufficiently specified such that users can correctly follow it without creating unexpected safety or security issues.

  * Bitcoin compatible: The custody system will be compatible with the consensus rules of Bitcoin.

In designing Ajolote we adhered to the following design patterns so as not to
create either a SPOF or SPOC.

  * Modular: Hardware and software components in the custody system can be replaced or updated, as needed.

  * Redundant: Sets of components can perform the same functions so that if one component fails, the custody system remains functional.

  * Diverse: Different supply chains, devices, and software are used across components to avoid fragility to malware, software bugs, hardware faults, and so on.

  * Verifiable: Failure or compromise of components must be detectable (where possible) so that recovery procedures can be enacted in time.

####  5.1.6 Methodology

Our methodology is underpinned by the following systematic steps:

Specification: We denote the custody system as Ajolote and outline the entire
system, including cryptographic key material and their context of use, Scripts
and output types,, transaction types and their format, functional elements,
and human-device procedures.

Analytical Examination: We employ multiple methods to uncover design flaws and
gain insights into custody with Bitcoin vaults, considering state dynamics,
privacy properties, Script implementation, and a comparison with equivalent
systems with no vault pattern and no covenants.

Risk Analysis: Conducting a thorough risk analysis, we adopt both asset-
centric and attacker-centric approaches. That is to say, we list all sensitive
and critical assets and the impact from having them leaked or stolen. Then, we
describe explicitly the capabilities of an attacker in a threat model.
Utilizing ceremony analysis (see 2.5.2), we enumerate vulnerabilities,
attacks, and risks of the Ajolote custody system.

Consideration of Alternative Covenants: Building on prior work, we investigate
the potential of different types of consensus-enforced covenants in addressing
issues discovered in vault-based Bitcoin custody.

###  5.2 Ajolote System

In this section, we introduce the inter-dependent Ajolote data structures,
which are organized systematically as follows:

$\text{Cryptographic}\text{ keys}\rightarrow\text{High-level}\text{
access}\text{ policies}\rightarrow\text{Transaction}\text{
types}\rightarrow\text{Output}\text{ types}\rightarrow\text{TapTrees}$

Our system specification needs to address several questions. What
cryptographic keys are necessary? What physical and operational boundaries
should those keys be subject to? Which keys are used for the access policies
of the three risk-accessibility tiers from figure 5.2? What transaction types
can implement these conceptual tiers and the transitions between them? What
constraints are encoded by covenant transactions? How should the access policy
be implemented in TapScript? What are the functional elements (devices,
services, instructions) that manage these data structures? This section
provides detailed answers to each of these questions, in preparation for the
following sections wherein the procedures are specified.

####  5.2.1 Bitcoin key boundaries

Each private key has well-defined usage boundaries to ensure that single
points of failure or compromise are not created. Table 5.1 summarises these
boundaries.

The user has 5 master extended private and public key-pairs labelled
$(q_{n},Q_{n})$ respectively, with $n\in\\{1,2,3,4,5\\}$. The user generates
enforcement key-pairs $(e^{v}_{1},E^{v}_{1})$ and $(e^{v}_{2},E^{v}_{2})$ for
each vault $v$. These are not extended because no key derivations are
necessary. Each of $N$ watchtowers are labelled by $k$ and have master
extended private and public keys $(w_{k},W_{k})$, where $k\in\\{1,2,...,N\\}$.

Key-pair | Location | Device | Role
---|---|---|---
$(q_{1},Q_{1})$ | With User | Mobile | Active
$(q_{2},Q_{2})$ | Home | Hardware signer | Active
$(q_{3},Q_{3})$ | Office | Hardware signer | Active
$(q_{4},Q_{4})$ | Bank A Safe Deposit | Hardware signer | Fall-back
$(q_{5},Q_{5})$ | Bank B Safe Deposit | Hardware signer | Fall-back
$(e^{v}_{1},E^{v}_{1})$ | With User | Mobile | Enforcement
$(e^{v}_{2},E^{v}_{2})$ | Home | Hardware signer | Enforcement
$(w_{k},W_{k})$ | / | Server | Response Key
Table 5.1: The location, storage device, and operational role are shown for
each type of key-pair. Non-capital and capital letters represent private and
public keys respectively.

Recall from figure 5.1 that the user keeps hardware signers in 4 distinct
secured locations such as their home, office, bank A and bank B. The user has
4 distinct non-networked hardware signers on which to generate and store
master key-pairs (ideally, different manufacturers and distributors). The user
keeps another master key-pair on their mobile device which we assume is on
their person at all times. Including the mobile device, there should never be
more than two signers in the same location at any time. The enforcement
private keys will be contained on the user’s mobile and their primary hardware
signer (in this case, the home signer). The watchtowers should be housed
across several data centers or dedicated facilities managed by a service
provider. Each watchtower keeps their own key-pair.

The user has 3 active master key-pairs and 2 fall-back master key-pairs.
Typically the mobile signer will be the initiator, and the home signer will be
the finaliser, as per the roles in the partially-signed bitcoin transaction
specification [89]. However, technically any key from the active and fall-back
key-sets can fulfill these roles for outputs they control. The enforcement
private keys are ephemeral, and only used to enforce deleted-key covenants
(though the public keys are persistent). The response keys are used by
watchtowers to initiate the reject procedure.

Figure 5.3 illustrates the key-tree for which the master key-pairs are the
root. As per the hierarchical deterministic wallet specification [290], the
master key is comprised of a 32 byte master secret key and a 32 byte chain
code. Master public keys are never used explicitly in transaction Scripts.
They are confidential, contained to their device for their entire life time.

To facilitate secure coordination, each signer will store a hardened public
key derived from each of the master key-pairs. We call the first hardened
extended child public key account 1, $A^{1}_{n}$. At some point, the signer
may need to rotate to a new account. This can be done by generating a new
hardened public key as a child of the master. That way, any other entity (e.g.
a compromised signer) that knows $A^{i}_{n}$ will not automatically know
$A^{i^{\prime}}_{n}$ where $i\neq i^{\prime}$. For each signer, an arbitrary
number of (non-hardened) public keys can be derived from the account that is
in use. Any entity that knows the extended public key for the current account
can derive these non-hardened public keys. We label the depth of the
derivation with a second superscript $h$ or $j$. At each depth there are keys
for different Ajolote output types, which will be described in the following
sections; $R^{i,h}_{n}$, $V^{i,j}_{n}$, $U^{i,j}_{n}$, $F^{i,j}_{n}$. These
keys use distinct derivation paths. Notice that $R^{i,h}_{n}$ can be at a
different depth $h$ to the others, which are labelled by $j$.

Figure 5.3: The key-tree for a master key-pair $(q_{n},Q_{n})$ in Ajolote. The
master key-pair is generated and stored on the signer. Accounts, $A^{i}_{n}$,
are hardened extended public keys to be shared with other signers. The current
account is denoted by $i$. The signer may rotate to a new account by deriving
a new hardened extended public key, $A^{i+1}_{n}$. Non-hardened public keys
for each Ajolote output type are derived from the $i^{th}$ account and depths
$h$ or $j$; $R^{i,h}_{n}$, $V^{i,j}_{n}$, $U^{i,j}_{n}$, $F^{i,j}_{n}$.

The watchtower key-tree is shown in figure 5.4. The watchtower uses the same
account rotation mechanism as the user. The watchtowers’ accounts are labelled
as $W^{i}_{k}$. These are hardened extended public keys. From a watchtower’s
account, their key-chain can be constructed using non-hardened public key
derivation. When the user instructs the service provider to re-initialise
their watchtowers (during a recovery process), the watchtower will rotate to
the next account.

Figure 5.4: The key-tree for a watchtower’s master key-pair $(w_{k},W_{k})$ in
Ajolote. Watchtower accounts, $W^{i}_{k}$, are hardened extended public keys
to be shared with other signers. A watchtower may rotate to a new account by
deriving a new hardened extended public key, $W^{i+1}_{k}$. Non-hardened
public keys are derived from the $i^{th}$ account with depth $j$;
$W^{i,j}_{k}$.

Note that these key-pairs are not backed up in Ajolote as is typically done
with single-key custody systems. Backups are not necessary for system-wide
resilience. Moreover, backups are cumbersome to use either when performing
system-health checks or when in a recovery scenario. The added procedural
complexity is not only a usability issue but it increases the attack-surface.

Of course, there are alternatives to the boundaries set here. For example,
Ajolote could be deployed with a fiduciary co-signer (controlling an active
key), or fiduciary recovery signer (controlling a fall-back key). Or, an
active or fall-back key could be stored at the home of a family member or
close friend. However, these alternatives would have to account for insider
attacks and collusion in their risk model.

####  5.2.2 High-level Policies

Let us write general, high-level descriptions of Miniscript policies for
Ajolote [8]. First we will label and describe some policies and policy
fragments. Let the receive policy be

$l_{receive}=thresh(2,pk(R_{1}^{i,h}),pk(R_{2}^{i,h}),pk(R_{3}^{i,h}))$ (5.1)

This represents a $2-$of$-3$ multi-signature policy, with the $3$ public keys
derived from $Q_{1}$, $Q_{2}$, and $Q_{3}$, the user’s active key-set.

Similarly, we will use a $2-$of$-5$ multi-signature policy fragment to
initiate withdrawals (using the active and fall-back key-set)

$l_{wit}=thresh(2,pk(V_{1}^{i,j}),pk(V_{2}^{i,j}),pk(V_{3}^{i,j}),pk(V_{4}^{i,j}),pk(V_{5}^{i,j}))$
(5.2)

We write the covenant enforcement fragment as

$l_{enf}=and(pk(E^{v}_{1}),pk(E^{v}_{2}))$ (5.3)

where the vault number, $v$, is an integer. This fragment requires signatures
for both enforcement public keys. The custodial subscript for a fall-back
output is intended to allow the user or any of their watchtowers to finalise a
Fall-back transaction, $TX^{fb}$ (described in section 5.2.3). It can be
satisfied with only $1$ signature. We write this as

$l_{pay-to-
fb}=thresh(1,pk(U_{1}^{i,j}),pk(U_{2}^{i,j}),pk(U_{3}^{i,j}),pk(U_{4}^{i,j}),pk(U_{5}^{i,j}),pk(W^{i,j}_{1}),pk(W^{i,j}_{2}),...,pk(W^{i,j}_{N}))$
(5.4)

The spend policy fragment has the same format as the receive policy, but with
keys from a different derivation path:

$l_{spend}=thresh(2,pk(U_{1}^{i,j}),pk(U_{2}^{i,j}),pk(U_{3}^{i,j}))$ (5.5)

Let us define the user’s fall-back policy as

$l_{fb}=thresh(3,pk(F_{1}^{i,j}),pk(F_{2}^{i,j}),pk(F_{3}^{i,j}),pk(F_{4}^{i,j}),pk(F_{5}^{i,j}))$
(5.6)

This represents a $3-$of$-5$ multi-signature policy with all of the user’s
keys. With these, we can get an intuitive understanding for the meaning of the
policies for each output type in Ajolote, as summarised in table 5.2. The
length of the delay length is $T$ and it is implemented as a relative time-
lock, denoted older in policy.

Finally, we define the test policy as

$l_{test}=thresh(5+N,pk(A_{1}^{i}),pk(A_{2}^{i}),pk(A_{3}^{i}),pk(A_{4}^{i}),pk(A_{5}^{i}),pk(W^{i}_{1}),pk(W^{i}_{2}),...,pk(W^{i}_{N}))$
(5.7)

It is used to verify whether or not the signing devices for the custody system
are functional.

Output Type | High-level Policy
---|---
Receive Output | $l_{receive}$
Vault Output | $and(l_{wit},l_{enf})$
Unvault Output | $or(and(l_{spend},older(T)),$
| $and(l_{pay-to-fb},l_{enf}))$
Fall-back Output | $l_{fb}$
Test Output | $l_{test}$
Table 5.2: Miniscript policies and policy fragments in the Ajolote custody
system.

####  5.2.3 Transaction Design

The transaction diagram for Ajolote is shown in figure 5.5. The receive and
vault-deposit are separated into two steps, two transactions, $TX^{rec}$ and
$TX^{dep}$. This is primarily because the vault-deposit procedure requires the
user to complete an interactive deleted-key covenant protocol (as detailed in
Chapter 4) with their mobile signer, home signer, and watchtowers and bringing
an external entity into that protocol creates unnecessary risk. Unfortunately,
received funds are not automatically guarded by the vault covenant. Note that
$TX^{dep}$ may aggregate several receive outputs in one transaction, creating
fewer vault outputs.

Each vault output is created with a pair of covenant transactions; Withdraw,
$TX^{wit}$, and Fall-back, $TX^{fb}$. We specify this procedure in section
5.4.2. The Spend transaction, $TX^{spend}$, is unrestricted, except that it is
invalid until the time-lock expires ($T$ blocks after $TX^{wit}$ is included
in a block).

The test transaction, $TX^{test}$, is not part of a sequence (and not shown in
the diagram) but it is critical for testing and checking the health of the
custody system (detailed in sections 5.3.6 and 5.4.6). It is formatted for the
Bitcoin test network. However, its input is invalid and the transaction should
not be broadcast to the network. As we will see, it is sufficient for signers
to verify each others’ signatures on $TX^{test}$ to check whether or not they
have the correct setup data.

Figure 5.5: Transaction (TX) diagram of the Ajolote custody system. Covenant
transactions are partially pre-signed; their enforcement subscripts are
satisfied. The primary output type is written for each named transaction.
These outputs are consumed by the proceeding transaction. Change outputs are
not shown here for simplicity.

Recall that in table 4.5 in chapter 4 we summarised the strategies for
allocating fees to deleted-key covenant transactions. For Ajolote, we must
choose an appropriate strategy for both $TX^{wit}$ and $TX^{fb}$. $TX^{wit}$
has a dependent transaction and thus cannot be modified. For now we will
select a simple but inefficient strategy and leave optimization for future
work. We prepare both $TX^{wit}$ and $TX^{fb}$ with a hard-coded base fee of
40 satoshis per byte. This is very high compared to the the average
transaction fee per day for the last year222According to statistics provided
on statoshi.info. A very high fee gives more certainty that the transactions
will be processed quickly and reduces reliance on a dynamic fee allocation
strategy such as CPFP outputs. Implementing a CPFP output strategy would
create procedural burden for the user and possibly create pinning attack
vectors by the watchtowers.

####  5.2.4 TapTrees

Now, we will describe our TapTree constructions based on the high-level
policies. The TapTrees are designed to enhance operational privacy by not
requiring public keys, parameters and TapScripts to be revealed unnecessarily.
They are equivalent to the high-level policies; the combination of TapScripts
in a tree equates to the high-level policy, while the individual TapScripts
can be stricter. Formally, the logical disjunction of the policy of all
TapScripts in a TapTree is equivalent to the high-level policy.

For a given output type, the TapTree will be unique from the leafs, through
the branches to the root. Why? Because each leaf node is the hash of a unique
TapScript which is comprised of newly derived public keys. The uniqueness of
TapTrees prevents a network peer from observing simple and definitive clusters
of outputs controlled by the user. A deeper analysis of the correlation of
outputs is given in section 5.6.2.

Recall that TapTree information is leaked when the output is spent in a
transaction, not when the output was created. The information is revealed as
part of the witness field of the transaction. It contains signatures, the
TapScript used, and the control block that contains branch nodes necessary to
prove the inclusion of the TapScript in the TapTree.

Receive outputs. In general, receive outputs will be spent using the mobile
and home signer. This is the left-most branch of the TapTree depicted in
figure 5.6. Using this branch reveals a 2-of-2 TapScript. Using this branch
hides the fact that a 2-of-3 branch was available. In the case that either the
mobile or home signer have been lost or compromised, the right-most branch may
be used to access coins.

Vault outputs. Vault outputs will typically be spent using the mobile and home
signer. This is the left-most branch of the TapTree in figure 5.7. Using this
branch reveals a 4-of-4 TapScript. If either the mobile or home signer have
been lost or compromised, the right-most branch may be used to withdraw funds
from the vault. This branch would reveal a TapScript with 2 required
signatures and a 2-of-5 multi-signature.

Unvault outputs. This is the most complicated TapTree in Ajolote. It is
depicted in figure 5.8. For successful withdrawals, the user will typically
spend using the 2-of-2 TapScript between the mobile and home signer, after
waiting for the time-lock to expire (the right-most branch). This would reveal
a 2-of-2 TapScript with a time-lock of length $T$. The user has the option to
spend with a 2-of-3 between the mobile, home and office signers. In this case,
a 2-of-3 TapScript with a time-lock would be revealed. In both cases, a
withdrawal reveals a minimum TapTree depth of 2 (since te control block
contains two TapBranch hashes). For reject procedures, a 3-of-3 TapScript will
be revealed. A minimum TapTree depth of up to $N+5$ will also be revealed,
depending on which watchtower initiates the procedure. The rationale for
structuring the tree to have a maximum depth of $N+5$ was to obfuscate how
many watchtowers are present to observing network peers. For fall-back
procedures, any of the users’ signers can be used.

Fall-back outputs. For withdrawals that are rejected, the left-most branch of
the TapTree depicted in figure 5.9 will be used. This will reveal a 3-of-3
TapScript. For fall-back scenarios, a 3-of-5 multi-signature will be revealed.

Figure 5.6: Receive Output TapTree. Figure 5.7: Vault Output TapTree. Figure
5.8: Unvault Output TapTree. Figure 5.9: Fall-back Output TapTree.

In table 5.3 we summarise the result of compiling the Miniscript policies (for
each TapScript leaf in each TapTree) to Bitcoin Script. Note that the compiler
is for version 0 segregated witness output types and therefore supports $\tt
OP\\_CHECKMULTISIG$ and $\tt OP\\_CHECKMULTISIGVERIFY$. As specified in
BIP-342 [289], we can replace these disabled instructions with $\tt
OP\\_CHECKSIGADD$ and $\tt OP\\_NUMEQUAL$333A Script $2$ $P_{1}$ $P_{2}$
$P_{3}$ $3$ $\tt OP\\_CHECKMULTISIG$ can be implemented as $P_{1}$ $\tt
OP\\_CHECKSIG$ $P_{2}$ $\tt OP\\_CHECKSIGADD$ $P_{3}$ $\tt OP\\_CHECKSIGADD$
$2$ $\tt OP\\_NUMEQUAL$ with TapScript.. We have adjusted the output of the
compiler to reflect this.

Output |  Miniscript Policy |  Bitcoin Script
---|---|---
Receive |  $and(pk(R^{i,m}_{1}),pk(R^{i,m}_{2}))$ |  $R^{i,m}_{1}$ ${\tt OP\\_CHECKSIGVERIFY}$ $R^{i,m}_{2}$ ${\tt OP\\_CHECKSIG}$
Receive |  $thresh(3,pk(R^{i,h}_{1}),pk(R^{i,h}_{2}),pk(R^{i,h}_{3}))$ |  $R^{i,h}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $R^{i,h}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $R^{i,h}_{3}$ $\tt OP\\_CHECKSIG$
Vault |  $thresh(4,pk(V^{i,j}_{1}),pk(V^{i,j}_{2}),$ $pk(E^{v}_{1}),pk(E^{v}_{2}))$ |  $V^{i,j}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $V^{i,j}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $E^{v}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $E^{v}_{2}$ $\tt OP\\_CHECKSIG$
Vault |  $and(and(pk(E^{v}_{1}),pk(E^{v}_{2})),thresh(2,$ $pk(V^{i,j}_{1}),pk(V^{i,j}_{2}),pk(V^{i,j}_{3}),$ $pk(V^{i,j}_{4}),pk(V^{i,j}_{5}))$ |  $E^{v}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $E^{v}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $V^{i,j}_{1}$ $\tt OP\\_CHECKSIG$ $V^{i,j}_{2}$ $\tt OP\\_CHECKSIGADD$ $V^{i,j}_{3}$ $\tt OP\\_CHECKSIGADD$ $V^{i,j}_{4}$ $\tt OP\\_CHECKSIGADD$ $V^{i,j}_{5}$ $\tt OP\\_CHECKSIGADD$ $2$ $\tt OP\\_NUMEQUAL$
Fall-back |  $thresh(3,pk(F^{i,j}_{1}),pk(F^{i,j}_{2}),pk(F^{i,j}_{3}))$ |  $F^{i,j}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $F^{i,j}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $F^{i,j}_{3}$ $\tt OP\\_CHECKSIG$
Fall-back |  $thresh(3,pk(F^{i,j}_{1}),pk(F^{i,j}_{2}),$ $pk(F^{i,j}_{3}),pk(F^{i,j}_{4}),pk(F^{i,j}_{5}))$ |  $F^{i,j}_{1}$ $\tt OP\\_CHECKSIG$ $F^{i,j}_{2}$ $\tt OP\\_CHECKSIGADD$ $F^{i,j}_{3}$ $\tt OP\\_CHECKSIGADD$ $F^{i,j}_{4}$ $\tt OP\\_CHECKSIGADD$ $F^{i,j}_{5}$ $\tt OP\\_CHECKSIGADD$ $3$ $\tt OP\\_NUMEQUAL$
Unvault |  $and(thresh(2,pk(U^{i,j}_{1}),$ $pk(U^{i,j}_{2})),older(T))$ |  $U^{i,j}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $U^{i,j}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $T$ $\tt OP\\_CHECKSEQUENCEVERIFY$
Unvault |  $and(thresh(2,pk(U^{i,j}_{1}),pk(U^{i,j}_{2}),$ $pk(U^{i,j}_{3})),older(T))$ |  $U^{i,j}_{1}$ $\tt OP\\_CHECKSIG$ $U^{i,j}_{2}$ $\tt OP\\_CHECKSIGADD$ $U^{i,j}_{3}$ $\tt OP\\_CHECKSIGADD$ $2$ $\tt OP\\_NUMEQUALVERIFY$ $T$ $\tt OP\\_CHECKSEQUENCEVERIFY$
Unvault |  $thresh(3,pk(E^{v}_{1}),pk(E^{v}_{2}),pk(U^{i,j}_{n}))$ |  $E^{v}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $E^{v}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $U^{i,j}_{n}$ $\tt OP\\_CHECKSIG$
Unvault |  $thresh(3,pk(E^{v}_{1}),pk(E^{v}_{2}),pk(W^{i,j}_{k}))$ |  $E^{v}_{1}$ $\tt OP\\_CHECKSIGVERIFY$ $E^{v}_{2}$ $\tt OP\\_CHECKSIGVERIFY$ $W^{i,j}_{k}$ $\tt OP\\_CHECKSIG$
Table 5.3: For each Ajolote output type, the Miniscript policy is shown with
its compiled Bitcoin Script.

####  5.2.5 Functional Elements

##### Mobile

The mobile device acts as a coordinator and signer for the custody system. The
user primarily interacts with the system through the user interface on the
mobile. The watchtowers communicate with the mobile. The hardware signers
communicate with the mobile. However, the mobile is not trusted to behave
correctly. It can behave in arbitrarily malicious ways. It can tamper with
messages or display false information to the user. To alleviate this, the
procedures which comprise the setup, operation and recovery often involve
verifying that the mobile data is consistent with the hardware signers and
watchtowers.

The mobile runs a (hypothetical) Ajolote application. It supports everything a
generic bitcoin transaction coordinator and signer should support, including;
hardware signer support, consensus-library, key-management, signature
generation and verification, transaction validation, partially signed bitcoin
transactions, hierarchical deterministic derivation support, output script
descriptors, address utilities, and Miniscript policies. The application also
runs a bitcoin-core full-node but prunes most of the history, retaining only
recent blocks. Alternatively, it could connect to a full-node server run by
the user. However, for simplicity we consider that the mobile itself is
operating a full-node.

Moreover, the Ajolote application includes an implementation to enact every
procedure (as described in the following sections). It has a library of
Ajolote data types, message types, transaction and output types, TapTrees,
Miniscript policies and scripts. It has an implementation to track the
complete state and history of the custody system; both what is on-chain as
unspent transaction outputs and off-chain as covenant transactions. It has a
secure-delete implementation for strong enforcement of the covenants. It has
support for the Noise protocol and the Onion Router (TOR) protocol. Finally,
it manages user authentication with a PIN and bio-metric reading.

##### Watchtower

A Watchtower (WT) is a server program that performs specific monitor and
response functions on behalf of the user. A WT can be containerised (e.g. with
Docker) for easy deployment and launched with orchestration services on cloud
providers (e.g. Docker swarm) to enable replication with geographical
redundancy for reliable up-time. Ideally, the WT implementation will be open-
source and verifiable by the user and the industry.

In Ajolote a WT broadly performs the following functions;

  * Bitcoin full-node:  The WT continuously monitors the Bitcoin blockchain. It establishes connections to the peer-to-peer network using TOR to hide its IP address. It validates each transaction and each block it sees in order to remain in consensus and maintain an accurate view of the current state.

  * Onion Service:  The WT operates as an anonymous Onion Service for the user, to keep its IP address private and reduce the network-based attack surface.

  * Covenant storage provider:  The WT maintains a register of user vaults, and stores partially-signed (with enforcement signatures) transaction pairs $(TX^{wit},TX^{fb})$ for each vault.

  * Withdrawal constraint enforcer:  Upon detecting a user’s $TX^{wit}$, the WT validates whether or not the withdrawal attempt is permitted according to the withdrawal constraints (set during watchtower initialisation). If so, the WT does not respond further. If not, the WT signs and broadcasts the associated $TX^{fb}$.

  * Ajolote recovery assistant:  Upon request from the user, the WT will send its registry of vaults and partially-signed transaction pairs $(TX^{wit},TX^{fb})$.

Messages between a WT and the user are transported through encrypted and
authenticated channels. The user and WT establish Noise channels during the
setup procedure (detailed in section 5.3.3). They use Noise key-pairs which
are distinct from their Bitcoin key-pairs. We denote the user’s and the
$k^{th}$ WT’s noise key-pairs as $(p^{Noise},P^{Noise})$ and
$(w^{Noise}_{k},W^{Noise}_{k})$ respectively. Moreover, the Watchtower and
user communicate with specific messages only; those included in the message
sequence diagrams for each procedure specified in the following sections.
Other message types are considered to be invalid inputs and are ignored.

##### Hardware signers

The Ajolote custody system requires hardware signers that support both generic
Bitcoin functionality and Ajolote-specific functionality. The hardware signers
are offline devices.

Generic Bitcoin functionality includes; key-management, signature generation
and verification, transaction validation, partially signed bitcoin
transactions, hierarchical deterministic derivation support, output script
descriptors, address utilities, and Miniscript policies.

Ajolote-specific functionality includes; secure-delete functionality (for
covenant enforcement keys), Ajolote message types (as in the procedure
specifications), Ajolote transaction and output types, Ajolote TapTree
support, and Ajolote key-tree support. In particular, there will be strict
formatting for message, transaction and output types that the device enforces.

Hardware signers are PIN protected. Furthermore, the hardware signer wipes
itself after more than three invalid PIN entries. The hardware signer can
connect to a transaction coordinator via a wire or through a camera-QR code
channel (where both devices have a screen and a camera). Hardware signers have
sufficient storage capacity, and encrypt sensitive data before storing it.

##### User Manual

A (hypothetical) user manual guides the user in all aspects of the system and
ensures they act as needed to maintain the integrity and security of their
custody system. The user manual describes how the user should enact each
procedure during setup, operation, and recovery. This is an essential
functional element without which the user could be tricked to compromise their
own system. Moreover, it makes the system accessible to less experienced
users, giving them confidence to operate an advanced custody system. Ideally,
the manual would be well-designed and user-friendly, in addition to being
correct.

##### Computer

A computer is used during the setup phase in order to double-check that data
received from the service provider and imported to the user’s other devices
have not been tampered with. The computer runs a minimal software tool to fill
in a few data types and transfer these to hardware signers.

###  5.3 Ajolote Setup Procedures

The setup is required to initialise all system components, generate all key
material, and test the system. Without a secure setup, no operation can be
secure regardless of how well designed it is. The setup has been decomposed
into procedures; mobile initialisation, watchtower initialisation, hardware
signer initialisation, setup finalisation, and the setup test. These should be
completed sequentially. The user must abort if any verification step fails.
Devices must abort if any verification step fails or if they receive an
unexpected input.

####  5.3.1 Pre-requisites

Here is a list of pre-requisites for the setup.

  * $\bullet$

The user has obtained and verified an Ajolote user manual to guide them
through the setup.

  * $\bullet$

The user has prepared a private space to enact the setup.

  * $\bullet$

The user has a computer, mobile, four hardware signers, paper, pen, and the
user manual.

  * $\bullet$

The user has prepared their four hardware signer storage locations: Home,
Office, Bank A and Bank B.

  * $\bullet$

The user’s computer and mobile are connected to different networks; Wi-Fi and
mobile data.

  * $\bullet$

The watchtowers are live and their administrating service provider has a list
of their hidden-service onion addresses.

  * $\bullet$

Hardware signers have Ajolote software installed. Due to differences in how
hardware signers handle application management, we do not specify this
procedure. Users have already set their PIN on the hardware signers and have
backed up that PIN.

  * $\bullet$

The computer has downloaded the Ajolote setup software.

####  5.3.2 Mobile Initialisation

The mobile initialisation is specified in figure 5.10. Notice that we specify
the sub-procedure as a ceremony where the user is included in the protocol
specification. The user instructs the mobile to connect with the App store,
then to download and install ‘Ajolote’ software from the App store. The mobile
and App store communicate using HTTPS. This way, the mobile can authenticate
the app store and the communication is encrypted in both directions. The app
store serves the requested software and the mobile installs it. Upon launching
it, the software prompts the user to set both a PIN and a bio-metric
authentication token. The mobile will not store copies of the PIN and bio-
metric data, but only sufficient data to verify them (such as their hash). The
mobile generates its Bitcoin master extended key-pair and stores it in the
mobile’s secure element. The software prompts the user to set the
configuration parameters $c=\\{T,V_{min},V_{max},N\\}$ and the withdrawal
constraints $w$. $T$ is the time-lock length and is constant for all
withdrawals. $V_{min}$ and $V_{max}$ are the minimum and maximum amounts of
bitcoin the user intends to deposit into each vault. $N$ is the total number
of watchtowers the user will hire. Finally, the software generates the Noise
key-pair and stores them in the mobile’s secure element.

Figure 5.10: Mobile initialisation. The final mobile state contains: Ajolote
software, Bitcoin master extended key-pair, Noise key-pair, configuration
parameters $c$, withdrawal constraints $w$, data to verify PIN and bio-metric
tokens.

For the remainder of the setup, the user maintains the same authenticated
session on the Ajolote mobile application.

####  5.3.3 Watchtower Initialisation

In figure 5.11 we depict the initialisation of the watchtower. The user
interacts with the browser application and the Ajolote application, both on
their mobile. We use a ‘Service Provider’ abstraction which does not depict
the system architecture that enables the service provider to serve their
website and control their watchtowers. There are at least two service
providers, labelled by $y$. There are $N_{y}$ watchtowers for each service
provider. Each watchtower is labelled by $k$. Note that the total number of
watchtowers is $\sum_{y}N_{y}=N$. Rather than repeat the same message sequence
for each service provider and watchtower, we depict which messages are
repeated and show an arbitrary service provider and watchtower.

The user inputs a URL for the service provider and the mobile and Service
provider establish a HTTPS connection. The service provider serves the mobile
with their website. The user registers with each service provider by inputting
a username and password. These can be used by the service provider to
authenticate the user later. The user copies $P^{Noise}$ from Ajolote
application and pastes it into their browser application. The user shares
relevant setup information ($T,w,N_{y},P^{Noise}$) with the service providers.
Service providers share a service level agreement (SLA) with the user and the
user must evaluate it before signing and making an initial payment. In
particular, the user verifies that the setup information is correct. Service
providers distribute $(T,w,P^{Noise})$ to each of their watchtowers to store
these data. The service provider shares the set of their watchtowers’ onion
addresses, $\\{O_{k}\\}_{y}$ with the mobile via the browser. The user imports
them into the Ajolote application.

The Ajolote application establishes a Noise KX communication channel with each
of the watchtowers [269]. ‘K’ means that the user’s Noise public key is known
by the watchtower. The watchtower can authenticate the user. ‘X’ means the
watchtower’s Noise public key is transmitted to the user during the handshake.
The user’s authentication of the watchtower is transitive, relying on secure
communication with the service provider. The watchtowers send their first
account (a Bitcoin extended public key), $W^{1}_{k}$, signed with their
associated private key, denoted as $signed_{1,k}(W^{1}_{k})$. The mobile can
thus verify that the watchtower has control of the public key. The Ajolote
application stores $(O_{k},W^{1}_{k},y)$ $\forall$ $y,k$.

Figure 5.11: Watchtower (WT) initialisation. The final state of the Ajolote
application includes the onion address, Bitcoin public key, and associated
service provider for each watchtower; $(O_{k},W^{1}_{k},y)$ $\forall$ $y,k$.
The final state of each watchtower includes
$(O_{k},w_{k},W_{k},T,w,P^{Noise})$.

####  5.3.4 Hardware Signer Initialisation

Figure 5.12 depicts the initialisation procedure for all four hardware
signers. It involves initial key generation and sharing relevant public keys
across all signers. Rather than repeat the message sequence for each of them,
we show which sequence is repeated for an arbitrary hardware signer labelled
as $n\in\\{2,3,4,5\\}$. Hardware signers may connect to the mobile using a
wire or using a camera and QR codes. Messages sent from the hardware signer to
the user are displayed on its screen. Messages sent from the user to the
hardware signer use input buttons.

The hardware signer requires the user to enter a PIN before allowing the
mobile to send requests to it. The first request is to initialise Ajolote and
it also requires user confirmation. In response, the hardware signer generates
its Bitcoin master extended key-pair $(q_{n},Q_{n})$ and computes its first
account $A^{1}_{n}$. Then it sends $A^{1}_{n}$ to the mobile. After enacting
this with each signer, the user must again connect the mobile to each hardware
signer in turn to import the complete set of first accounts. This set is
written as $\\{A^{1}_{n}\\}$. For now, this data remains unverified and could
be inconsistent across hardware signers. The mobile also sends the
configuration parameters $c$ to the hardware signer. The user verifies that
what is written on the hardware signer’s display matches their decision.

Figure 5.12: Hardware signer initialisation. The state of the Ajolote
application (on mobile) now includes the complete set of first accounts for
hardware signers, $\\{A^{1}_{n}\\}$. The state of the hardware signers
includes $\\{A^{1}_{n}\\}$ and $c$.

####  5.3.5 Setup Finalisation

Figure 5.13 depicts how to finalise the setup, which involves transporting
watchtower credentials to each hardware signer. To achieve this while
preventing a potentially malicious mobile device from tampering with messages,
the user communicates with the service provider through a separate channel
using their computer.

First, the user inputs a URL for the service provider and the computer and
Service provider establish a HTTPS connection. The service provider serves
their website. Then, the user enters their login details to authenticate them-
self to the service provider. Once the service provider accepts, the user
requests to finalise the setup. The service provider responds with a copy of
the SLA including the relevant setup configuration data and watchtower data.
The user will verify that the SLA matches the previous one and that $T,w,$ and
$N_{y}$ are correct. This protocol is enacted for each service provider.

Next, the user connects each hardware signer to both the mobile and the
computer and retrieves the setup data. From the mobile, it receives the set of
watchtower accounts, $\\{W^{1}_{k}\\}$, the set of onion addresses,
$\\{O_{k}\\}$, and $p^{Noise}$. From the computer, it receives
$\\{W^{1}_{k}\\},\\{O_{k}\\},P^{Noise}$. It verifies that the $p^{Noise}$ it
was given by the mobile is the private key corresponding to $P^{Noise}$, as
received from the computer. To prevent the mobile or computer from omitting
messages to them, the hardware signers display how many of the watchtower
public keys and onion addresses were consistent from the mobile and the
computer, and prompts the user to verify the total number of watchtowers $N$.

Figure 5.13: Setup finalisation. The state of the hardware signers now
includes $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, and $p^{Noise}$.

####  5.3.6 Test Setup

Figure 5.14 depicts the protocol to test the finalised setup. In this
procedure, one goal is to have each signer (mobile, hardware signer,
watchtowers) provide a signature for a test transaction $TX^{test}$, and to
have each of the user’s devices verify the complete set of signatures. Each of
the signers uses their knowledge of $\\{W^{i}_{k}\\}$ and $\\{A^{i}_{n}\\}$ to
generate $l_{test}$ independently. Another goal is to have each of the user’s
devices compute the hash of their setup state,

$H^{setup}=hash(\\{W^{i}_{k}\\}||\\{A^{i}_{n}\\}||\\{O_{k}\\}||P^{Noise}||c)$
(5.8)

and for the user to verify that these match by comparing what the mobile and
hardware signers display.

The user initiates the test on the mobile. The mobile provides $TX^{test}$ to
each watchtower, which generates a signature $sig_{k}^{test}$ with $w_{k}$ and
sends this to the mobile. The mobile verifies the complete set of watchtowers’
signatures $\\{sig_{k}^{test}\\}$. The mobile connects to a hardware signer,
the user authenticates the connection with their PIN, and the mobile requests
a setup test. The mobile provides $TX^{test}$, and the hardware signer
verifies whether the expected $l_{test}$ was used. The mobile provides
$\\{sig^{test}_{k}\\}$, and the hardware signer verifies each of the
signatures. Both the mobile and the hardware signer display $H^{setup}$ and
the transaction ID for $TX^{test}$, prompting the user to verify if they
match. If so, the user inputs OK on the hardware signer. The hardware signer
generates its own signature $sig^{test}_{n}$ and sends it to the mobile. This
sequence is repeated for each hardware signer.

Finally, the user reconnects each hardware signer with the mobile (one at a
time). The mobile sends the complete set of signatures from the user’s
signers, $\\{sig^{test}_{n}\\}$. The mobile and hardware signer verifies these
signatures. If everything is correct, the hardware signers display ‘setup test
success’ to the user.

Note that $TX^{test}$ does not need to be broadcast to allow each of the
user’s signers to verify that the others have knowledge of their first
account, and to prove to others that they have the associated private key. It
is sufficient to check that they are consistent among each other. In fact,
broadcasting $TX^{test}$ can reveal operational information (such as public
keys and the number of watchtowers).

Figure 5.14: Setup test.

####  5.3.7 Conclusion

After successfully completing and testing the setup, the user should move
hardware signers to their safe and secured locations. Each device will have
the state summarised in table 5.4. The computer will not be required again. It
should be purged of all information related to the setup.

Device | State Contents
---|---
Mobile |  $\\{A^{1}_{n}\\}$, $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, $c=(T,V_{min},V_{max})$,$(q_{1},Q_{1})$, $(p^{Noise},P^{Noise})$, $w$
Home signer |  $\\{A^{1}_{n}\\}$, $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, $c=(T,V_{min},V_{max})$,$(q_{2},Q_{2})$, $(p^{Noise},P^{Noise})$
Office signer |  $\\{A^{1}_{n}\\}$, $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, $c=(T,V_{min},V_{max})$,$(q_{3},Q_{3})$, $(p^{Noise},P^{Noise})$
Bank A signer |  $\\{A^{1}_{n}\\}$, $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, $c=(T,V_{min},V_{max})$,$(q_{4},Q_{4})$, $(p^{Noise},P^{Noise})$
Bank B signer |  $\\{A^{1}_{n}\\}$, $\\{W^{1}_{k}\\}$, $\\{O_{k}\\}$, $c=(T,V_{min},V_{max})$,$(q_{5},Q_{5})$, $(p^{Noise},P^{Noise})$
Watchtower $k$ |  $w_{k},W_{k}$, $O_{k}$, $T$, $P^{Noise}$, $w$
Table 5.4: Summary of device state after a successful setup.

###  5.4 Ajolote Operational Procedures

After a successful setup, the user can begin using the custody system. The
following procedures are not necessarily sequential. Though, of course, the
user needs to receive bitcoin first.

In the procedure specifications, when transactions are sent to ‘Bitcoin
Network’, assume they have satisfactory witness fields (signatures and Scripts
included). Assume also that the user authenticates them-self to the mobile
(with their PIN and bio-metric data) before initiating each procedure.

####  5.4.1 Receive

In this procedure the user receives bitcoin with a Receive transaction,
$TX^{rec}$. Any entity may authorise a $TX^{rec}$. A $TX^{rec}$ has no
constraints other than creating a receive output, i.e. one which is controlled
by the user’s active key-set, $l_{receive}$. By separating this procedure from
the vault-deposit, we ensure that external entities are not participants in
the deleted-key covenant protocol. This way trust in counter-parties is
minimised.

A secure procedure for the user to generate an address and share with a
counter-party was described by Arapinis et al. [56]. The basic idea is to
verify the address generated on the mobile with one generated on a hardware
signer, and to send this to the counter-party through a channel that’s not
controlled by the mobile. This prevents a compromised mobile device from
replacing the address with one controlled by an adversary; an address
generation attack.

Figure 5.15: Receive. Critically, the communication between the user and
counter-party is not mediated by the mobile.

####  5.4.2 Vault-deposit

Conceptually, in this procedure the user adds a layer of security to
previously received funds by depositing them into a bitcoin vault. This
procedure is where the user constructs the two covenant transactions,
$TX^{wit}$ and $TX^{fb}$ (withdrawal and fall-back) and pays to them with the
vault-deposit, $TX^{dep}$. Recall from the previous chapter, section 4.4.4,
how a deleted-key covenant should be implemented and the required constraints
on transactions. In this case the user self-imposes the covenant. The user
enacts each role with their mobile device and home signer; ‘depositor’,
‘enforcer’, and ‘custodian’. The user also sends the covenant transactions,
$TX^{wit}$ and $TX^{fb}$ to their watchtowers. Recall that watchtowers
participate in the custodial sub-script for $TX^{fb}$, so they too enact the
‘custodian’ role. The communication protocol for the procedure is depicted in
figure 5.16. In addition, important actions by each device are shown between
messages.

Figure 5.16: Vault-deposit. Protocol to deposit funds into a deleted-key vault
covenant in the Ajolote custody system. The mobile and home signer use
ephemeral keys to create enforcement signatures for the withdrawal and fall-
back transactions that implement ‘vault’ and ‘pay-to-fallback’ covenants.

The user initially selects an amount $x$ to deposit into a vault. This amount
can be any number that is the sum of a subset of amounts held in receive
outputs. An example user interface could be a slider, with intervals fixed to
valid amounts. The user authenticates the connection between the mobile and
home signer. The mobile requests to deposit $x$ from the home signer, which
relays the request to the user for verification.

The additional data stored by the home signer, mobile, and watchtowers after a
successful instance of the vault-deposit protocol is summarised in table 5.5.
Each entity has sufficient data to fulfil their duties. The covenant
transactions and their enforcement signatures are redundantly stored by the
mobile, home signer, and all watchtowers. Signatures with subscript 1 and 2
were generated by the mobile and home signer respectively, using ephemeral
private keys $e_{1}^{v}$ and $e_{2}^{v}$. These keys are subsequently deleted
to enforce the covenants. Notice that the home and mobile signer wait for
confirmation from the watchtowers before deleting.

Spending taproot outputs also requires knowledge of the TapScript and the
control block which form part of the witness. This is a necessary subset of
the TapTree required to spend. The public keys $E^{v}_{1}$ and $E^{v}_{2}$ are
part of the vault and unvault output TapTrees and are stored by the mobile,
home signer, and watchtowers. The mobile and home signer can derive the
TapTree with these, however the watchtowers do not know the accounts of the
user’s signers nor of each other watchtower. This is why they are also given
$c_{k}$, the control block needed to authorise $TX^{fb}$ in a reject
procedure.

The mobile stores $TX^{dep}$ in its transaction history records. The home
signer and mobile store $j$, the derivation index variable which is
incremented with each new vault-deposit. This is used to derive new public
keys from the current accounts of all signers.

The home signer only provides signatures for an acceptable $TX^{wit}$ and
$TX^{fb}$. How? By constructing them from its own data; this includes
constructing the descriptors, setting the transaction fee, and setting the
outputs. The home signer trusts the mobile when setting the input in
$TX^{wit}$ (using the vault output information from $TX^{dep}$). While the
home signer can not verify if its $TX^{wit}$ and $TX^{fb}$ will be valid with
respect to the state of the blockchain, it can verify if they are valid with
respect to the consensus rules and the Ajolote system rules. As well as
ensuring appropriate output types and a transaction fee, the home signer can
enforce that the vault-deposit amount is within the acceptable range of
$(V_{min},V_{max})$. Moreover, the home signer will be a storage device for
enforcement signatures. It must verify the ones received from the mobile
before accepting and storing them. The home signer must abort and warn the
user if the verification fails.

The mobile will verify all signatures received from the home signer and notify
the user if there is ever a failure. Similarly, the watchtowers will verify
each signature (received from the mobile) and check the validity of the
covenant transactions it receives. The watchtower validates against the
withdrawal constraints $w$ and the Bitcoin consensus library. Furthermore, the
watchtower must check that $c_{k},E_{1}^{v}$ and $E_{2}^{v}$ are used to
derive the Merkle root of the TapTree by matching it against the taproot
output key for the unvault output. The mobile waits for acknowledgement from
each watchtower before broadcasting $TX^{dep}$ to the Bitcoin network.

The watchtowers monitor the network for $TX^{dep}$. Once it has been included
in a block, they generate a signature for the fall-back transaction and send
this to the mobile, which will forward it to the home signer. This signature
is verified by both mobile and home signer, and interpreted as an
authenticated message that $TX^{dep}$ has been confirmed, and that the
watchtowers have verified and validated the covenant transactions and
associated data. If the home signer verifies these signatures, it notifies the
user that the vault-deposit was successful.

Device | New State Contents
---|---
Home signer |  $TX^{dep}$, $TX^{wit}$, $TX^{fb}$, $sig^{wit}_{1},sig^{wit}_{2},sig^{fb}_{1},sig^{fb}_{2},E^{v}_{2},E^{v}_{1},j$
Mobile |  $TX^{dep}$, $TX^{wit}$, $TX^{fb}$, $sig^{wit}_{1},sig^{wit}_{2},sig^{fb}_{1},sig^{fb}_{2},E^{v}_{2},E^{v}_{1},j$
Watchtower $k$ |  $TX^{dep}$, $TX^{wit}$, $TX^{fb}$, $sig^{wit}_{1},sig^{wit}_{2},sig^{fb}_{1},sig^{fb}_{2},c_{k},v$
Table 5.5: New state entries after a successful vault deposit.

####  5.4.3 Withdrawal

The withdrawal procedure is restricted by the covenant enforcement. In the
typical case, where the withdrawal is honest, the user must wait for the time-
lock to expire before being able to spend funds. In the event that a
compromise is detected or the withdrawal policy is breached, the reject
procedure will be initiated before the time-lock expires, resulting in a
failed withdrawal attempt.

The user must satisfy $and(l_{wit},l_{enf})$ to finalise $TX^{wit}$. In
addition to the enforcement signatures $sig_{1}^{enf}$ and $sig_{2}^{enf}$
which will have been stored on the mobile device, the user must generate
signatures to satisfy the $l_{wit}$ fragment, $sig_{1}^{wit}$ and
$sig_{2}^{wit}$. Withdrawals can be initiated with user’s mobile and any of
the user’s hardware signers, as depicted in figure 5.17. Under normal
operating scenarios the mobile and home signer will be used. The user selects
which vault $v$ to withdraw. The relative time-lock for the spend path begins
once the associated withdrawal transaction, $TX_{v}^{wit}$, is included in a
valid block.

Figure 5.17: Withdrawal.

####  5.4.4 Spend

The spend procedure, depicted in figure 5.18, allows the user to make
arbitrary payments to external entities with funds that have successfully been
withdrawn and any other outputs that are currently locked to $l_{receive}$.
The user first acquires a payment address, $A$, from the counter-party they
intend to pay. The user initiates the spend by specifying an amount $x$ and
$A$ in the Ajolote application on the mobile. The mobile and home (or office)
signer are used to authorize the spend transaction, $TX^{spend}$. The user
verifies that the mobile sent the appropriate spend details to the home signer
by checking the amount, $x$, and destination address, $A$, on the hardware
signer’s display.

Figure 5.18: Spend.

####  5.4.5 Reject

A reject procedure should be initiated automatically by at least one
watchtower if the broadcast of a withdrawal transaction conflicts with the
pre-determined withdrawal constraints, $w$. This scenario is depicted in
figure 5.19. This procedure must occur before the expiration of the relative
time-lock.

Figure 5.19: Reject.

####  5.4.6 System health check

A complete system health check is important to carry out periodically. In
figure 5.20 we depict the system health check ceremony. This is an extended
version of the setup test. It includes checking the consistency of operational
state across devices. The public and private Bitcoin keys, covenant
transactions and enforcement signatures, public and private Noise keys, and
configuration parameters. In this procedure, we define an additional hash
value for the user to compare,

$H^{operation}=hash(\\{TX^{wit}\\}||\\{TX^{fb}\\}||\\{sig^{wit}_{enf}\\}||\\{sig^{fb}_{enf}\\}||\\{(E_{1}^{v},E_{2}^{v})\\})$
(5.9)

which is a hash of the complete set of withdrawal and fall-back transactions,
their enforcement signatures and public keys. Together, $H^{setup}$ and
$H^{operation}$ allow the user to match the consistency of the majority of
data across signers and watchtowers.

To begin, the user initiates the system health check on the mobile. The mobile
sends a request to the watchtower, including the test transaction to sign. The
watchtower responds with its signature, and $H^{operation}$ which it has
signed with $w^{i}_{k}$ so that the hardware signers can authenticate that the
message came from the watchtower.

Then, the user must connect to each hardware signer. To do this, they must
travel to each one’s safe location. The mobile provides the hardware signer
with the test transaction and the data from each watchtower. The user matches
the values displayed on the screen of the hardware signer with the mobile. Any
discrepancy demonstrates that the device is not consistent with the rest of
the system. The hardware signer verifies the signed $H^{operation}$ from each
watchtower, and their test transaction signatures. From the hardware signers,
only the home signer can compute $H^{operation}$ itself and match against what
it received from the watchtowers. The others merely check that all watchtowers
are consistent with each other. If successful, the hardware signers shares its