it back to the wallet in the partially-signed Bitcoin Tx (PSBT) format [89].
It’s exchanged with a sufficient threshold of the other managers to add their
signatures and hand it back to the initiator. The initiator requests a
signature from each of the anti-replay oracles and pushes the fully-signed
Spend Tx to the coordinator. The initiator broadcasts the Unvault Tx,
triggering a lookup from the watchtowers to the coordinator for the Spend Tx.
If the Spend Tx is valid according to all of the watchtowers policies and none
of them cancel this unvaulting attempt, the manager waits $X$ blocks and
broadcasts the Spend Tx.

If, during the unvaulting process, there’s a significant increase in the fee-
level required for a Spend Tx to be mined, a manager needs to bump the fee.
Managers use a dedicated single-party fee wallet for this. Similarly,
watchtowers use a fee wallet in the case there is high demand for block space
to bump the fee for Cancel or emergency Txs.

Figure A.3: Data flow diagram for the communication of the managers’ spend
process. In this example there are two managers (M), three anti-replay oracles
(O), five watchtowers (WT) and a coordinator. A Partially-signed Bitcoin Tx
(PSBT) is exchanged among managers and between a manager and the anti-replay
oracles. A fully signed SpendTx is shared with the WTs through the
coordinator.

###  A.5 Methodology

To see where this research fits in to the big picture, consider the key life-
cycle of a custodial operation. There are three phases; initialization,
operation, and termination. Initialization is where wallet and communication
keys are generated, where software integrity is verified, hardware security
modules are checked, and relevant public information is shared among
participants. Operation encompasses the active fund management. Termination is
the phase wherein the wallet is de-commissioned and all sensitive information
destroyed. Initialization and termination are out of scope for this chapter.
Our risk model covers the operations phase. In the following we present our
rationale for our chosen attack modeling formalism and explain how this can be
used as a risk framework.

####  A.5.1 Operational Security Models

A framework for high-level risk analyses for the integration of custody into a
multi-stakeholder context has not yet been presented. To-date the literature
has focused primarily on cryptographic security modeling, dealing with low-
level risks associated with cryptographic primitives, key-management
protocols, HSMs and single-party wallets. The underlying cryptographic
security is fundamental but should be complemented by an operational security
model, which is much more likely to be the domain where participants create
vulnerabilities for an attacker. Advanced custody protocols that use multi-
layer access control with both static and active defences for insider and
external attackers demand a whole-system approach to security analysis.

We present now several requirements for our modelling formalism: a) the
ability to represent complex processes with numerous components and sequential
events; b) supports qualitative risk analysis; c) supports automated
quantitative methods for multi-attribute risk analysis; d) readily
comprehensible and visual models that are more amenable to open-source
intelligence; and e) extensible and modular models to support differential
analysis and re-use of modules.

The two most popular attack modeling techniques in cyber-security literature
are attack-trees and attack graphs [184]. In short, tools for attack graphs
tend to produce graphs that aren’t readily comprehensible due to the
complexity of real-world attack scenarios [147]. That is, attack graphs don’t
scale well [259]. On the other hand, attack-trees seem to meet all of our
requirements, at least when considered with the right structure and semantics
(as described in section A.5.2) and thus we construct our risk model using
this formalism.

While a statement such as ‘our custody solution is based on an $m-$of$-n$
security model’ can entail a lot for simple multi-signature custody protocols,
it doesn’t capture the reality nearly as well as our proposed methodology
would. It is certainly not sufficient for a more complex custody protocol like
Revault. What is the physical environment for those $n$ private keys? Are any
of those keys online? Are there key backups and, if so, what protections are
in place for these? Too much depends on the broader security environment of a
custody protocol for it to be left without scrutiny.

Application threat modelling has been used to harden the Revault protocol
throughout both its theoretical development and implementation. For each
application process (spend, routine signing, emergency, revault) a component-
by-component and connection-by-connection analysis has been carried out to
determine the consequences of outages, data tampering, component corruption,
etc., and has resulted in the design specification [12] and the transaction
flow threat model [190]. The application threat modeling approach is
complementary and has informed us in enumerating the risks presented with the
attack-trees. However, in contrast to attack-trees, it lacks a semantic
structure which is amenable for automated risk quantification and thus isn’t
suitable as the basis of a risk framework.

####  A.5.2 Attack-Tree Formalism

The risk model is presented using the formalism of attack-trees [260, 286,
51]. Attack-trees have an attack at their root, and branches that capture
alternate (OR) and complementary (AND) attack pathways comprised of
intermediate attack goals as non-leaf nodes and basic attack steps as leaf
nodes. As in numerous other works [125, 164, 181, 204, 203, 219], we extend
the basic attack-tree to support sequential conjunction of branches (SAND)
allowing us to model an attack where some sub-tree of an attack pathway has to
occur before and in addition to another sub-tree. For brevity we depict our
attack-trees as nested lists. The logical gates (OR, AND, SAND) shown with
each node apply to the next node at the same depth. This means that at any
given depth, a node with a SAND gate occurs before other nodes that are shown
below it. Some aspects of the system are built to be resilient to attack and
failure through redundancy. For example, an attacker needs to compromise all
stakeholders’ private keys to steal funds locked to the deposit descriptor. To
be concise, rather than having several copies of the same sub-tree we write
($X$ times) to note that the sub-tree has to happen $X$ times. During an
analysis, these sub-trees should be considered as $X$ separate AND sub-trees,
since they are contextually different (corresponding to different
participants, remote and physical environments).

We provide a set of attack-trees, capturing prominent risks that have been
enumerated primarily by considering tangible and intangible assets. Tangible
assets (bitcoins) are distinguished by the access control structures
determined by the set of descriptors. We consider operational privacy and
business continuity as intangible assets.

Our work here is focused on security, rather than safety. In principle, the
same methodology could be extended to an integrated security-safety model by
constructing attack-fault-trees [181]. Another common extension to the attack-
tree formalism is to include countermeasures, producing attack-defence-trees
[176, 156]. The benefit of our modular modelling technique is that it enables
future work to integrate these extensions and re-use results from this work.
Hence, we prioritise constructing a strong foundation based only on attacks,
and aim to incrementally improve on the model presented as new intelligence
emerges.

####  A.5.3 On Risk Analysis

Our purpose in constructing the risk model presented in section A.6 is to
provide a framework to support both qualitative and quantitative risk analyses
for specific deployment instances of Revault custody. By determining costs,
likelihoods, and other attributes for risks associated with custodial
processes, an organisation can perform a differential analysis of
countermeasures until their risk-tolerance is satisfied. An explicit framework
not only helps an organisation deploying Revault with risk-management but
could form a standard by which insurance companies and regulators consider
specific deployments. As with any model of complex reality, attack-trees are
imperfect and cannot capture every possible attack pathway, but the
alternative—complete ignorance—is not better.

To perform a context-specific risk analysis, a set of estimates are made
(using in-house empirical data, public research, and expert opinion) for each
basic attack step on different attributes such as monetary cost, execution
time, or likelihood. With that, a bottom-up procedure (from leaf nodes to the
root) is used to compute aggregated attributes. Bayesian methods can be used
to update prior estimates with more refined values as new data sources emerge.
The process for generating estimates is critical and should be considered with
care. In-depth research-based practical guidance on this topic is given by D.
W. Hubbard and R. Seiersen in [161]. Given specific contextual information,
estimations can be improved by further decomposing basic attack steps (e.g.
‘steal keys backup’) into multiple steps (e.g. ‘bribe manager to determine
backup location’ SAND ‘break into safe’). If a basic attack step has a highly
uncertain estimate, then further decomposition into more explicit steps can be
beneficial. On the other hand, decomposing into quantities that are more
speculative than the first could compound uncertainty rather than reducing it.

Various methods for analysis can be used to compute aggregated attributes for
attack-trees. Kordy et al. gave an overview [177]. Our purpose here is to
provide the framework on which to perform analyses rather than to provide a
specific analysis. We have not performed a comprehensive evaluation of
analysis methods, but offer some suggestions based on a comparison in [180].
Two methods that support evaluating the attributes of cost, probability, and
time are stochastic-model checking [181] and game-theoretic analysis [156].
Whichever methods are used must appropriately capture the constraints of our
model (including SAND gates) and should be automated to enable rapid
attribute-based queries for security metrics such as; the expected attack pay-
off for the most likely attack, or the possible attack pathways given a budget
of $10,000.

Our approach to constructing the risk model is centered on assets since these
are clearly distinguished through Bitcoin descriptors, as continuity of a
custodial process, or as operational privacy. However, when performing the
risk analysis it can be insightful to consider attacker personas [263]: a
crime syndicate; an opportunistic burglar; a nation state; a business
competitor; or even an insider. If the organisation understands any of these
personas well (arguably they should especially understand their competitors
and employees) they can reduce the uncertainty in their aggregate risk
estimates for these scenarios. Attacker-profiles are a useful way to prune
attack-trees [180].

###  A.6 Risk Model

We have constructed the risk model with several assumptions that limit the
scope of the analysis to the operational aspects of custody. Known risks from
other protocol and environment dependencies that are discussed in other works
should be considered as complementary but are, for the purpose of clarity,
assumed to be benign here. First, we assume that the Bitcoin network is
functional, realising its live-ness and availability properties [127, 128,
233, 65, 64]. We assume that there is significant hash-rate to prevent
blockchain reorganisations of a depth higher than the Unvault Tx’s relative
lock-time. Next, we assume that Revault’s Tx model is robust; with scripts
that realise the access control structures we expect, without unintended
consequences from Tx malleability and network propagation issues as described
in [190]. We assume the initialization process was secure and safe; private
keys and backups were correctly and confidentially constructed for each
participant, software and hardware integrity were verified, relevant public
key information for both the wallet and communication was shared among
participants leading to a correct configuration for the wallet clients,
watchtowers, anti-replay oracles and the coordinator. We assume that Revault’s
communication security model as described in [12] is robust. That is, where
messages need to be authenticated or confidential, they are. We assume that
the software development life-cycle of Revault is secure, such that any
deployment is using an implementation that adheres to the protocol
specification. Finally, we assume that entities constructing Deposit Txs don’t
succumb to a man-in-the-middle attack. That is, they lock funds to the deposit
descriptor rather than to an attacker’s address.

####  A.6.1 Common Attack Sub-Trees

These attack sub-trees are common to different attacks on Revault, and a, b,
c, d, e, f and g are likely to be common to attacks on other custody
protocols.

  * a :

Compromise a participant (stakeholder or manager)

    * 1 :

Coerce participant (OR)

    * 2 :

Corrupt participant

Coercion and insider threats from corrupt participants must be considered.
Legal defences for malicious employee behaviour can be effective deterrents
here.

  * b :

Compromise a participant’s (stakeholder’s or manager’s) HSM

    * 1 :

Physical attack of HSM (OR)

      * 1.1 :

Determine location of participant’s HSM (SAND)

      * 1.2 :

Access the physical security environment of the participant’s HSM (SAND)

      * 1.3 :

Exfiltrate keys (either on premise or after stealing it) (OR)

      * 1.4 :

By-pass PIN and make the HSM sign a malicious chosen message

    * 2 :

Remote attack of HSM (OR)

      * 2.1 :

Compromise a device that is then connected to the HSM (SAND)

        * 2.1.1 :

(see g) Compromise the participant’s wallet software (OR)

        * 2.1.2 :

Trick participant into connecting their HSM to a compromised device via social
engineering

      * 2.2 :

Exploit a firmware vulnerability (OR)

      * 2.3 :

Trick participant into compromising their own HSM with the user interface of
the compromised device

    * 3 :

(see a) Compromise a participant

  * c :

Compromise a participant’s (stakeholder’s or manager’s) keys backup

    * 1 :

Physical Attack (OR)

      * 1.1 :

Determine location of the keys backup (SAND)

        * 1.1.1 :

Watch the participant between the custody initialization and the start of
operations (OR)

        * 1.1.2 :

Watch the participant during a backup check (OR)

      * 1.2 :

Access the physical security environment of the keys backup (SAND)

      * 1.3 :

Depending on backup format, steal or copy it

    * 2 :

(see a) Compromise a participant

  * d :

Compromise a server (watchtower, anti-replay oracle, or coordinator)

    * 1 :

Remote attack (OR)

      * 1.1 :

Exploit a software vulnerability (OR)

        * 1.1.1 :

Determine the public interfaces of the server (SAND)

        * 1.1.2 :

Exploit a vulnerability on one of the softwares listening on these interfaces

      * 1.2 :

Exploit a human vulnerability (e.g. trick participant into performing a
malicious update)

    * 2 :

Physical attack (OR)

      * 2.1 :

Determine server’s location (SAND)

      * 2.2 :

Access the physical security environment of the server (SAND)

      * 2.3 :

Compromise the server (e.g. inject malware)

    * 3 :

(see a) Compromise the participant managing the server

An attacker who successfully completes d for a watchtower will be able to
steal funds from the watchtower’s fee wallet and will be able to force an
emergency scenario by broadcasting all Emergency and Unvault-Emergency Txs it
has stored. They can also prevent broadcast of a Cancel Tx from this
watchtower either passively (ACK the secure storage of the signature to the
stakeholder, but then drop the signature) or actively.

  * e :

Shutdown a watchtower

    * 1 :

Physical attack on the watchtower (OR)

      * 1.1 :

Determine watchtower’s location (SAND)

      * 1.2 :

Sever the internet connection to the building in which the watchtower is
located (OR)

      * 1.3 :

Sever the power-line connection to the building in which the watchtower is
located (OR)

      * 1.4 :

Access the physical security of the watchtower and un-plug the machine

    * 2 :

Remote attack on the watchtower

      * 2.1 :

Determine public interfaces of watchtower (SAND)

      * 2.2 :

Denial of Service attack through one of the public interfaces (OR)

      * 2.3 :

Eclipse attack on the watchtower’s Bitcoin node [154] (OR)

        * 2.3.1 :

Slowly force de-synchronisation of watchtower with the true block height by
delaying block propagation [250] (OR)

        * 2.3.2 :

Prevent outgoing propagation of Cancel or Emergency Txs

      * 2.4 :

Denial of Service attack on the fee-bumping UTxOs pool—not enough funds to pay
competitive fees

  * f :

Get signature from participant to unlock UTxO for Theft Tx

    * 1 :

(see a) Compromise a participant (OR)

    * 2 :

(see b) Compromise participant’s HSM (OR)

    * 3 :

(see c) Compromise participant’s keys backup

  * g :

Compromise a participant’s wallet

    * 1 :

Physical attack (OR)

      * 1.1 :

Locate participant’s device (SAND)

      * 1.2 :

Access physical security environment of participant’s device

    * 2 :

Remote attack (OR)

      * 2.1 :

Determine public interfaces of device (SAND)

      * 2.2 :

Exploit a vulnerability

    * 3 :

(see a) Compromise participant

Participant’s wallet devices are expected to be used for day-to-day
activities. With many vulnerabilities to exploit, the likelihood of success
for g is high.

  * h :

Determine the locking Script for a deposit or unvault UTxO (Witness Script)

    * 1 :

(see g) Compromise any participant’s wallet (OR)

    * 2 :

(see d) Compromise a watchtower (OR)

    * 3 :

(see d) Compromise an anti-replay oracle

Deposit and unvault descriptors are deterministic, but public keys are needed
to derive UTxO locking Scripts. These are stored by all wallets, watchtowers
and anti-replay oracles.

  * i :

Satisfy an input in a Theft Tx that consumes an identified deposit UTxO or
unvault UTxO (through $N-$of$-N$)

    * 1 :

(see h) Determine the UTxO locking Script (Witness Script) (SAND)

    * 2 :

Prevent the relevant Emergency Tx from being broadcast until the Theft Tx is
confirmed (where $A+B=N$) (AND)

      * 2.1 :

(see d) Compromise a watchtower (A times)

      * 2.2 :

(see e) Shutdown a watchtower (B times)

      * 2.3 :

(see g) Compromise stakeholder’s wallet ($N$ times)

    * 3 :

(see f) Get signature from a stakeholder to unlock UTxO for Theft Tx ($N$
times)

  * j :

Satisfy an input in a Theft Tx that consumes an identified unvault UTxO
(through $K-$of$-M$, anti-replay oracles and time-lock)

    * 1 :

(see h) Determine the UTxO locking Script (Witness Script) (SAND)

    * 2 :

Receive signatures for Theft Tx from all $N$ anti-replay oracles (AND)

      * 2.1 :

Compromise a manager’s private communication keys and the set of anti-replay
oracles’ public communication keys (OR)

        * 2.1.1 :

(see g) Compromise a manager’s wallet (OR)

        * 2.1.2 :

(see a) Compromise a manager

      * 2.2 :

(see d) Compromise the anti-replay oracle

    * 3 :

(see f) Get signature from a manager to unlock UTxO for Theft Tx ($K$ times)

  * k :

Satisfy an input in a Theft Tx that consumes an identified emergency UTxO

    * 1 :

Determine the emergency descriptor policy (SAND)

    * 2 :

Satisfy the emergency descriptor’s locking conditions (may include waiting for
time-locks, giving sufficient signatures, giving hash pre-images, etc.)

The details of the emergency descriptor are intentionally not specified with
the Revault protocol, except that it is more difficult to access than the
deposit descriptor. Stakeholders may compartmentalise and distribute the
descriptor information to afford its privacy some resilience to attack.

####  A.6.2 Attack-Trees

The following attack-trees are the foundation for an operational risk
framework for Revault.

  * A :

Compromise privacy of the custody operation (determine the set of public
UTxOs)

    * 1 :

(see d) Compromise any of the servers (OR)

    * 2 :

(see a) Compromise a participant (OR)

    * 3 :

(see g) Compromise a participant’s wallet (OR)

    * 4 :

Traffic analysis of connections between servers and/or wallets (OR)

    * 5 :

Blockchain analysis

Without privacy support for advanced descriptors (such as by using MuSig2
[221] or MuSig-DN [222] if the proposed Taproot [291] upgrade is activated by
the Bitcoin network) Revault’s operational privacy is brittle.

  * B :

Broadcast Theft Tx(s) that consume all deposit UTxOs

    * 1 :

(see A) Determine $\mathcal{D}$, the set of deposit UTxOs (SAND)

    * 2 :

(see h) Determine the locking Script for deposit UTxO ($|\mathcal{D}|$ times)

    * 3 :

(see i) Satisfy an input in a Theft Tx that consumes an identified deposit
UTxO ($|\mathcal{D}|$ times)

A Theft Tx that consumes all available deposit UTxOs would be catastrophic
since this comprises the majority of funds. We recommend a defence wherein
each stakeholder is equipped with a panic button that is directly connected to
their watchtower or dedicated emergency service. When triggered, all the
signed Emergency and Unvault-Emergency Txs are broadcast, negating the pay-off
for an attacker and thus acting as a deterrent.

  * C :

Broadcast Theft Tx(s) that consume as many available unvault UTxOs as
watchtower spending policies permit

    * 1 :

Determine spending constraints of all watchtowers’ policies (SAND)

      * 1.1 :

(see a) Compromise a participant (OR)

      * 1.2 :

(see g) Compromise a manager’s wallet

      * 1.3 :

(see d) Compromise a watchtower ($N$ times)

    * 2 :

Determine $\mathcal{U}$, the set of available unvault UTxOs (SAND)

      * 2.1 :

(see A) Compromise privacy of the custody operation (determine the set of
public UTxOs) (SAND)

      * 2.2 :

(see h) Determine the locking Script for unvault UTxO ($|\mathcal{U}|$ times)

    * 3 :

(see i OR j) Satisfy an input in a Theft Tx that consumes an identified
unvault UTxO ($|\mathcal{U}|$ times)

C can be avoided if watchtowers have a white-list of addresses that Spend Txs
can pay to.

  * D :

Broadcast Theft Tx(s) that consume all available unvault UTxOs, by-passing
watchtowers’ spending policies

    * 1 :

Prevent watchtower from broadcasting Cancel or Unvault-Emergency Txs before
Theft Tx is confirmed ($N$ times SAND)

      * 1.1 :

(see d) Compromise a watchtower (OR)

      * 1.2 :

(see e) Shutdown a watchtower

    * 2 :

Determine $\mathcal{U}$, the set of available unvault UTxOs (SAND)

      * 2.1 :

(see A) Compromise privacy of the custody operation (determine the set of
public UTxOs) (SAND)

      * 2.2 :

(see h) Determine the locking Script for unvault UTxO ($|\mathcal{U}|$ times)

    * 3 :

(see i OR j) Satisfy an input in a Theft Tx that consumes an identified
unvault UTxO ($|\mathcal{U}|$ times)

  * E :

Broadcast a Theft Tx that by-passes watchtowers’ spending policies

    * 1 :

Determine $\mathcal{U}$, the set of available unvault UTxOs (SAND)

      * 1.1 :

(see A) Compromise privacy of the custody operation (determine the set of
public UTxOs) (SAND)

      * 1.2 :

(see h) Determine the locking Script for unvault UTxO ($|\mathcal{U}|$ times)

    * 2 :

(see f) Get signature from a manager to unlock $U\subseteq\mathcal{U}$, a
subset of available unvault UTxOs for a valid Spend Tx ($K$ times)

    * 3 :

(see i OR j) Satisfy an input in a Theft Tx that consumes an identified
unvault UTxO ($|U|$ times)

    * 4 :

(see d) Compromise an anti-replay oracle to get a signature for the valid
Spend Tx which consumes $U$, the UTxOs ($N$ times SAND)

    * 5 :

Advertise the valid Spend Tx to the watchtowers through the coordinator (SAND)

    * 6 :

Broadcast all Unvault Txs that the valid Spend Tx depends on and wait for the
time-lock to expire

  * F :

Force emergency scenario

    * 1 :

Broadcast the full set of signed Emergency and Unvault-emergency transactions

      * 1.1 :

(see d) Compromise a watchtower (OR)

      * 1.2 :

(see a) Compromise a stakeholder

The emergency deterrent results in better security from the most egregious
physical threats to participants (particularly stakeholders who control the
majority of funds) but also in a fragility to the continuity of operations
that could be abused by an attacker. Attacks that rely on E may seek a pay-off
other than fund theft, such as damaging the reputation of the organisation for
having down-time and taking a leveraged bet on the likely market consequences.
However, forced down-time attacks through power or internet outages or
detainment of personnel are prevalent threats for organisations who aren’t
deploying Revault. In any case, with this risk model the consequence of not
using an emergency deterrent can be considered by performing an analysis with
pruned attack-trees.

  * G :

Broadcast a Theft Tx which consumes all available UTxOs locked to the
emergency descriptor

    * 1 :

(see F) Force an emergency scenario (SAND)

    * 2 :

Determine $\mathcal{E}$, the set of available emergency UTxOs (SAND)

      * 2.1 :

(see A) Compromise privacy of the custody operation (determine the set of
public UTxOs)

    * 3 :

(see k) Satisfy an input in a Theft Tx that consumes an identified emergency
UTxO ($|\mathcal{E}|$ times)

  * H :

Broadcast a Theft Tx which spends from a manager’s fee wallet

    * 1 :

(see g) Compromise a manager’s wallet

While this is a relatively simple attack, the fee wallet will never hold a
significant portion of bitcoins and is considered external to the custody
protocol.

  * I :

Prevent Emergency, Unvault-Emergency, and Cancel Tx valid signature exchange

    * 1 :

$1$ of $N$ stakeholders doesn’t sign (OR)

      * 1.1 :

Prevent stakeholder from accessing their HSM (OR)

      * 1.2 :

Prevent stakeholder from accessing their wallet (OR)

      * 1.3 :

(see a) Compromise a stakeholder

    * 2 :

Shutdown coordinator (OR)

    * 3 :

(see e) Shutdown a watchtower ($N$ times) (OR)

    * 4 :

Blockchain re-organization and Deposit Tx outpoint malleation.

  * J :

Prevent Unvault Tx signature exchange

    * 1 :

$1$ of $N$ stakeholders doesn’t sign (OR)

      * 1.1 :

Prevent stakeholder from accessing their HSM (OR)

      * 1.2 :

Prevent stakeholder from accessing their wallet software (OR)

      * 1.3 :

(see a) Compromise a stakeholder

    * 2 :

Shutdown coordinator (OR)

    * 3 :

Prevent all managers from accessing their wallet software

  * K :

Prevent managers from broadcasting a Spend Tx

    * 1 :

Prevent managers from signing the Spend transaction (OR)

      * 1.1 :

(see d) Compromise an anti-replay oracle (OR)

      * 1.2 :

Prevent sufficient threshold of managers from signing the Spend Tx (where
$A+B+C=M-K+1$) (OR)

        * 1.2.1 :

(see a) Compromise a manager ($A$ times)

        * 1.2.2 :

Prevent manager from accessing their HSM ($B$ times)

        * 1.2.3 :

Prevent manager from accessing their wallet software ($C$ times)

    * 2 :

Force broadcast of Cancel Tx (OR)

      * 2.1 :

(see d) Compromise a watchtower

    * 3 :

Prevent broadcast of Unvault Tx

      * 3.1 :

High demand for block space making the Unvault Tx not profitable to
mine.333Manager’s fee-bumping wallet can not cover this until a network policy
such as Package Relay [11] is implemented.

      * 3.2 :

(see g) Compromise manager’s wallet ($M$ times)

###  A.7 Conclusion

The rise of Bitcoin has led to a new commercial ecosystem, with market
exchanges enabling its sale and purchase, companies and financial institutions
offering secure custody services, and insurance brokers and underwriters
willing to insure individuals, exchanges and custodians against loss or theft
of their assets. In this chapter we first posit that a methodology to better
understand risks in custodial operations is needed, something complementary to
understanding blockchain and cryptographic security. We put forth requirements
of the modelling technique and propose attack-trees as a formalism which
satisfies those requirements. We exemplify the approach by presenting a
library of attack-trees constructed for a multi-party custody protocol called
Revault and explain how this framework can be used as a basis for risk-
management in custodial operations. The next steps for this work are to:
construct a set of defences to the prominent risks and incorporate them into
the model; and to determine or build a suitable tool for automating
computations for a specific analysis.

## References

  * [1] Bitcoin contracting primitives working group.  https://github.com/ariard/bitcoin-contracting-primitives-wg.
  * [2] Blockchain Commons.  https://github.com/BlockchainCommons.
  * [3] Blockchain Commons: Gordian Seed Tool.  https://github.com/BlockchainCommons/GordianSeedTool-iOS.
  * [4] CryptoCurrency Security Standard.  https://cryptoconsortium.notion.site/CryptoCurrency-Security-Standard-e372d9cad52f4615aa3ad0c47c24ea21.
  * [5] Foundation Devices, Inc.: Foundation Passport.  https://foundationdevices.com/passport/.
  * [6] Google: Use Google Play Protect to help keep your apps safe and your data private.  https://support.google.com/googleplay/answer/2812853?hl=en-GB#zippy=%2Chow-malware-protection-works%2Chow-google-resets-permissions-for-unused-apps.
  * [7] Hardware wallet.  https://en.bitcoin.it/wiki/Hardware_wallet#Commercial_hardware_wallets_.28ordered_chronologically.29.
  * [8] Miniscript.  https://bitcoin.sipa.be/miniscript/.
  * [9] Nunchuck.  https://nunchuk.io/about-us/.
  * [10] Output Script Descriptors: a language for abstracting out the spending conditions of a Bitcoin transaction output.  https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md.
  * [11] Package Relay design questions for the Bitcoin P2P network.  https://github.com/bitcoin/bitcoin/issues/14895.
  * [12] Practical Revault.  https://github.com/revault/practical-revault.
  * [13] Revault.  https://github.com/revault/.
  * [14] Rusty’s Remarkably Unreliable Guide To Bitcoin Storage: 2018 Edition.  https://github.com/rustyrussell/bitcoin-storage-guide.
  * [15] Script.  https://en.bitcoin.it/wiki/Script.
  * [16] Sparrow wallet.  https://sparrowwallet.com/.
  * [17] Wasabi.  https://docs.wasabiwallet.io/using-wasabi/.
  * [18] YetiCold.com Bitcoin Storage.  https://github.com/JWWeatherman/yeticold/blob/master/README.md.
  * [19] Microsoft Corporation: Security Design by Threat Modeling, 2005.  https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee810542(v=cs.20).
  * [20] Certicom Research: SEC 2: Recommended Elliptic Curve Domain Parameters, 2010.  http://www.secg.org/sec2-v2.pdf.
  * [21] Telecommunication Standardization Sector of ITU: Message Sequence Chart (MSC).  2011\.  https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Z.120-201102-I!!PDF-E&type=items.
  * [22] National institute of standards and technology: Digital signature standard (dss).  FIPS PUB 186-4 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, 2013.  https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdfhttps://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.
  * [23] National Institute of Standards and Technology: FIPS 180-4: Secure Hash Standard (SHS), 2015.  https://csrc.nist.gov/publications/detail/fips/180/4/final.
  * [24] Bip39-diceware, 2017.  https://github.com/taelfrinn/Bip39-diceware.
  * [25] Common Criteria Development Board: Common Criteria for Information Technology Security Evaluation Part 1, 2017.  https://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf.
  * [26] Glacier Design Document, 2017.  https://glacierprotocol.org/assets/design-doc-v0.9-beta.pdf.
  * [27] How does Blockstream Green’s multisig security work?, 2017.  https://help.blockstream.com/hc/en-us/articles/900001391763-How-does-Blockstream-Green-s-multisig-security-work-.
  * [28] Multisig Wallets, 2017.  https://electrum.readthedocs.io/en/latest/multisig.html.
  * [29] Introducing Boltzmann and STONEWALL, 2018.  https://blog.samouraiwallet.com/post/173544815052/full-bech32-support-introducing-boltzmann-and.
  * [30] National Institute of Standards and Technology: Framework for Improving Critical Infrastructure Cybersecurity, 2018.  https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf.
  * [31] Square, Inc.: Subzero: HSM-backed Bitcoin Cold Storage.  2018\.  https://subzero.readthedocs.io/en/master/.
  * [32] Capital Markets and Technology Association: Digital Assets Custody Standard.  2020\.  https://www.cmta.ch/content/272/cmta-digital-assets-custody-standard-v1-public-consultation.pdf.
  * [33] Casa: Wealth Security Protocol.  2020\.  https://docs.keys.casa/wealth-security-protocol/.
  * [34] Generating Device Seeds Using Dice, 2020.  https://medium.com/coinmonks/generating-device-seeds-using-dice-894082d43aea.
  * [35] Shift Crypto AG: BitBox02 threat model, 2020.  https://shiftcrypto.ch/bitbox02/threat-model/.
  * [36] Enno Wallet Threat Model for Mobile Apps, 2021.  https://github.com/Enno-Wallet-Enno-Cash/security-public/tree/main/threat-model.
  * [37] Apple: App security overview, 2022.  https://support.apple.com/en-gb/guide/security/sec35dd877d0/1/web/1.
  * [38] Bip39 Offline Mnemonic Generator, 2022.  https://github.com/veebch/Bip39-Dice.
  * [39] Center for Internet Security: The 18 CIS Critical Security Controls, 2022.  https://www.cisecurity.org/controls/cis-controls-list.
  * [40] Coinkite Inc.: HSM Security Notes, 2022.  https://coldcard.com/docs/hsm/security.
  * [41] Ledger Donjon: Threat Model, 2022.  https://donjon.ledger.com/threat-model/#security-mechanisms.
  * [42] SatoshiLabs: Common security threats, 2022.  https://trezor.io/learn/a/common-security-threats.
  * [43] K. Abdellatif, C. Guillemet, and O. Hériveaux.  Unfixable Seed Extraction on Trezor - A practical and reliable attack, 2019.  https://blog.ledger.com/Unfixable-Key-Extraction-Attack-on-Trezor/.
  * [44] D. Abram, A. Nof, C. Orlandi, P. Scholl, and O. Shlomovits.  Low-Bandwidth Threshold ECDSA via Pseudorandom Correlation Generators.  Cryptology ePrint Archive, Paper 2021/1587, 2021.  https://eprint.iacr.org/2021/1587.
  * [45] L. Abrams.  Criminals are mailing altered Ledger devices to steal cryptocurrency, 2021.  https://www.bleepingcomputer.com/news/cryptocurrency/criminals-are-mailing-altered-ledger-devices-to-steal-cryptocurrency/.
  * [46] A. Akavia, S. Goldwasser, and C. Hazay.  Distributed Public Key Schemes Secure Against Continual Leakage.  In Proceedings of the 2012 ACM Symposium on Principles of Distributed Computing, PODC ’12, pages 155–164. ACM, 2012.
  * [47] R. Ali, J. Barrdear, R. Clews, and J. Southgate.  The economics of digital currencies.  2014\.  https://www.bankofengland.co.uk/-/media/boe/files/quarterly-bulletin/2014/the-economics-of-digital-currencies.
  * [48] C. Allen and S. Appelcline.  Cold Storage Self-Custody Scenario.  2019\.  https://github.com/BlockchainCommons/SmartCustodyBook/blob/master/manuscript/02-scenario.md.
  * [49] C. Allen and S. Appelcline.  Smart Custody Book, 2019.  https://github.com/BlockchainCommons/SmartCustodyBook/blob/master/manuscript/.
  * [50] C. Allen and S. Appelcline.  Multisig Self-Custody Scenario.  2022\.  https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/Scenario-Multisig.md.
  * [51] E. G. Amoroso.  Fundamentals of Computer Security Technology.  Prentice-Hall, Inc., 1994.
  * [52] R. J. Anderson.  Security Engineering: A Guide to Building Dependable Distributed Systems.  Wiley Publishing, 2nd edition, 2008.
  * [53] G. Andresen.  Address Format for pay-to-script-hash, 2011.  https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki.
  * [54] G. Andresen.  Pay to Script Hash, 2012.  https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki.
  * [55] A. M. Antonopoulos.  Mastering Bitcoin: Unlocking Digital Crypto-Currencies.  O’Reilly Media, Inc., 1st edition, 2014.
  * [56] M. Arapinis, A. Gkaniatsou, D. Karakostas, and A. Kiayias.  A Formal Treatment of Hardware Wallets.  Financial Cryptography and Data Security, pages 426–445, 2019.
  * [57] M. Arenas, T. Reisenegger, J. Reutter, and D. Vrgoč.  Is it possible to verify if a transaction is spendable?  Frontiers in Blockchain, 4, 2021.
  * [58] F. Astolfi, J. Kroese, and J. van Oorschot.  I2P - The Invisible Internet Project.  http://mediatechnology.leiden.edu/images/uploads/docs/wt2015_i2p.pdf.
  * [59] K. Atlas.  Best Practices for Heterogeneous Input Script Transactions, 2016.  https://github.com/bitcoin/bips/blob/master/bip-0126.mediawiki.
  * [60] A. Au, M. Hoffman, J. Mattingly, P. McAteer, and Y. Takahashi.  Care, Custody, & Control (CCC): Identification, quantification, and mitigation of cryptocurrency custodial risk.  2020\.  https://www.paulmcateer.com/wp-content/uploads/2021/01/CCC_Pub_Version.pdf.
  * [61] J.-P. Aumasson and O. Shlomovits.  Attacking threshold wallets.  Cryptology ePrint Archive, Paper 2020/1052, 2020.  https://eprint.iacr.org/2020/1052.
  * [62] A. Back.  Hashcash - A Denial of Service Counter-Measure.  2002\.  http://www.hashcash.org/papers/hashcash.pdf.
  * [63] A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille.  Enabling Blockchain Innovations with Pegged Sidechains, 2014.  https://blockstream.com/sidechains.pdf.
  * [64] C. Badertscher, J. Garay, U. Maurer, D. Tschudi, and V. Zikas.  But Why Does It Work? A Rational Protocol Design Treatment of Bitcoin.  In J. B. Nielsen and V. Rijmen, editors, Advances in Cryptology – EUROCRYPT 2018, pages 34–65. Springer International Publishing, 2018.
  * [65] C. Badertscher, U. Maurer, D. Tschudi, and V. Zikas.  Bitcoin as a transaction ledger: A composable treatment.  Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 10401 LNCS(Crypto 2017):324–356, 2017.
  * [66] Z. Bao, W. Shi, S. Kumari, Z.-y. Kong, and C.-M. Chen.  Lockmix: a secure and privacy-preserving mix service for bitcoin anonymity.  International Journal of Information Security, 19, 2020.
  * [67] M. Bartoletti, S. Lande, and R. Zunino.  Bitcoin covenants unchained.  Leveraging Applications of Formal Methods, Verification and Validation: Applications, 2020.
  * [68] M. Bartoletti, S. Lande, and R. Zunino.  Computationally sound bitcoin tokens.  2021 IEEE 34th Computer Security Foundations Symposium (CSF), 2021.
  * [69] M. Bartoletti and R. Zunino.  BitML: A Calculus for Bitcoin Smart Contracts.  Cryptology ePrint Archive, Paper 2018/122, 2018.  https://eprint.iacr.org/2018/122.
  * [70] M. Bartoletti and R. Zunino.  Formal models of bitcoin contracts: A survey.  Frontiers in Blockchain, 2019.
  * [71] M. Battagliola, R. Longo, A. Meneghetti, and M. Sala.  Threshold ECDSA with an Offline Recovery Party.  Mediterranean Journal of Mathematics, 2020.
  * [72] G. Bella.  Formal Correctness of Security Protocols.  2007\.
  * [73] A. Berentsen and F. Schar.  The Case for Central Bank Electronic Money and the Non-case for Central Bank Cryptocurrencies.  Federal Reserve Bank of St. Louis Review, Second Quarter 2018, pages 97–106, 2018.
  * [74] A. Biryukov, D. Khovratovich, and I. Pustogarov.  Deanonymisation of clients in Bitcoin P2P network.  Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, abs/1405.7418, 2014.  http://arxiv.org/abs/1405.7418.
  * [75] A. Biryukov and I. Pustogarov.  Bitcoin over Tor isn’t a good idea.  CoRR, abs/1410.6079, 2014.  http://arxiv.org/abs/1410.6079.
  * [76] B. Bishop.  On-chain vaults prototype, 2020.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html.
  * [77] Blockchain Commons.  Uniform Resources (UR): An Introduction, 2021.  https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md.
  * [78] D. Boneh, R. Gennaro, and S. Goldfeder.  Using Level-1 Homomorphic Encryption to Improve Threshold DSA Signatures for Bitcoin Wallet Security.  Progress in Cryptology – LATINCRYPT 2017, 2019.
  * [79] J. Bonneau, A. Narayanan, A. Miller, J. Clark, J. Kroll, and E. Felten.  Mixcoin: Anonymity for bitcoin with accountable mixes.  Cryptology ePrint Archive, Paper 2014/077, 2014.  https://eprint.iacr.org/2014/077.
  * [80] BtcDrak, M. Friedenbach, and E. Lombrozo.  CHECKSEQUENCEVERIFY, 2015.  https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki.
  * [81] Y. Bulut and I. Sertkaya.  Security problem definition and security objectives of cryptocurrency wallets in common criteria.  Bilişim Teknolojileri Dergisi, 13(2):157 – 165, 2020.
  * [82] V. Buterin.  Deterministic Wallets, Their Advantages and their Understated Flaws, 2013.  https://bitcoinmagazine.com/technical/deterministic-wallets-advantages-flaw-1385450276.
  * [83] R. Canetti, Y. Dodis, S. Halevi, E. Kushilevitz, and A. Sahai.  Exposure-resilient Functions and All-or-nothing Transforms.  In Proceedings of the 19th International Conference on Theory and Application of Cryptographic Techniques, EUROCRYPT’00, pages 453–469. Springer-Verlag, 2000.
  * [84] R. Canetti, R. Gennaro, S. Goldfeder, N. Makriyannis, and U. Peled.  UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts.  Cryptology ePrint Archive, Paper 2021/060, 2021.  https://eprint.iacr.org/2021/060.
  * [85] M. Carlos and G. Price.  Understanding the weaknesses of human-protocol interaction.  In J. Blyth, S. Dietrich, and L. J. Camp, editors, Financial Cryptography and Data Security, pages 13–26. Springer Berlin Heidelberg, 2012.
  * [86] G. Castagnos, D. Catalano, F. Laguillaumie, F. Savasta, and I. Tucker.  Two-Party ECDSA from Hash Proof Systems and Efficient Instantiations.  Cryptology ePrint Archive, Paper 2019/503, 2019.  https://eprint.iacr.org/2019/503.
  * [87] G. Castagnos, D. Catalano, F. Laguillaumie, F. Savasta, and I. Tucker.  Bandwidth-efficient threshold EC-DSA revisited: Online/Offline Extensions, Identifiable Aborts, Proactivity and Adaptive Security.  Cryptology ePrint Archive, Paper 2021/291, 2021.  https://eprint.iacr.org/2021/291.
  * [88] L. Childs and K. Carpenter.  Passport Security Model, 2021.  https://github.com/Foundation-Devices/passport-firmware/blob/main/SECURITY/SECURITY.md.
  * [89] A. Chow.  Partially Signed Bitcoin Transaction Format, 2017.  https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki.
  * [90] A. Chow.  PSBT Version 2, 2017.  https://github.com/bitcoin/bips/blob/master/bip-0370.mediawiki.
  * [91] D. Coutts and E. de Vries.  Formal specification for a Cardano wallet.  2018\.  https://iohk.io/en/research/library/papers/formal-specification-for-a-cardano-wallet/.
  * [92] E. Crites, C. Komlo, and M. Maller.  How to Prove Schnorr Assuming Schnorr: Security of Multi- and Threshold Signatures.  Cryptology ePrint Archive, Paper 2021/1375, 2021.  https://eprint.iacr.org/2021/1375.
  * [93] A. Dabrowski, K. Pfeffer, M. Reichel, A. Mai, E. R. Weippl, and M. Franz.  Better keep cash in your boots - hardware wallets are the new single point of failure.  In Proceedings of the 2021 ACM CCS Workshop on Decentralized Finance and Security, DeFi ’21, page 1–8. Association for Computing Machinery, 2021.
  * [94] A. Dalskov, C. Orlandi, M. Keller, K. Shrishak, and H. Shulman.  Securing DNSSEC Keys via Threshold ECDSA from Generic MPC, pages 654–673.  2020\.
  * [95] I. Damgård, T. P. Jakobsen, J. B. Nielsen, J. I. Pagter, and M. B. Østergård.  Fast Threshold ECDSA with Honest Majority.  Cryptology ePrint Archive, Paper 2020/501, 2020.  https://eprint.iacr.org/2020/501.
  * [96] Darosior.  ANYPREVOUT in place of CTV.  2022\.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html.
  * [97] P. Das, A. Erwig, S. Faust, J. Loss, and S. Riahi.  The Exact Security of BIP32 Wallets.  Cryptology ePrint Archive, Paper 2021/1287, 2021.  https://eprint.iacr.org/2021/1287.
  * [98] J. D. Davidson and W. Rees-Mogg.  The Sovereign Individual: How to Survive and Thrive During the Collapse of the Welfare State.  Simon & Schuster, Inc., 1996.
  * [99] C. Decker, R. Russell, and O. Osuntokun.  Eltoo: A Simple Layer 2 Protocol for Bitcoin.  2018\.  https://blockstream.com/eltoo.pdf.
  * [100] C. Decker and A. Towns.  SIGHASH_ANYPREVOUT for Taproot, 2021.  https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki.
  * [101] C. Decker and R. Wattenhofer.  Information propagation in the Bitcoin network.  In IEEE P2P 2013 Proceedings, pages 1–10, 2013.
  * [102] C. Decker and R. Wattenhofer.  A fast and scalable payment network with bitcoin duplex micropayment channels.  Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 9212:3–18, 2015.
  * [103] S. Delgado-Segura, C. Pérez-Solà, G. Navarro-Arribas, and J. Herrera-Joancomartí.  A fair protocol for data trading based on bitcoin transactions.  Future Generation Computer Systems, 107:832–840, 2020.
  * [104] V. Di, R. Longo, F. Mazzone, and G. Russo.  Resilient custody of crypto-assets, and threshold multisignatures.  Mathematics, 8:10, 2020.
  * [105] P. Dikshit and K. Singh.  Weighted threshold ECDSA for securing bitcoin wallet.  ACCENTS Transactions on Information Security, 2:43–51, 2016.
  * [106] J. Dilley, A. Poelstra, J. Wilkins, M. Piekarska, B. Gorlick, and M. Friedenbach.  Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks.  CoRR, abs/1612.05491, 2016.
  * [107] R. Dingledine, N. Mathewson, and P. Syverson.  Tor: The Second-Generation Onion Router.  13th USENIX Security Symposium (USENIX Security 04), 13, 2004.
  * [108] H. Dobbertin, A. Bosselaers, and B. Preneel.  Ripemd-160: A strengthened version of ripemd.  In D. Gollmann, editor, Fast Software Encryption, pages 71–82. Springer Berlin Heidelberg, 1996.
  * [109] J. Doerner, Y. Kondi, E. Lee, and abhi shelat.  Secure Two-party Threshold ECDSA from ECDSA Assumptions.  Cryptology ePrint Archive, Paper 2018/499, 2018.  https://eprint.iacr.org/2018/499.
  * [110] J. Doerner, Y. Kondi, E. Lee, and abhi shelat.  Threshold ECDSA from ECDSA Assumptions: The Multiparty Case.  Cryptology ePrint Archive, Paper 2019/523, 2019.  https://eprint.iacr.org/2019/523.
  * [111] D. Dolev and A. Yao.  On the security of public key protocols.  IEEE Transactions on Information Theory, 29(2):198–208, 1983.
  * [112] T. Dryja.  Discreet Log Contracts.  https://adiabat.github.io/dlc.pdf.
  * [113] C. M. Ellison.  Ceremony design and analysis.  IACR Cryptology ePrint Archive, 2007:399, 2007.
  * [114] M. Erhardt.  An Evaluation of Coin Selection Strategies, 2016.  http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf.
  * [115] S. Eskandari, D. Barrera, E. Stobert, and J. Clark.  A first look at the usability of bitcoin key management.  In Workshop on Usable Security (USEC), 2015.
  * [116] I. Eyal.  On cryptocurrency wallet design.  IACR Cryptology ePrint Archive, 2021.
  * [117] C.-I. Fan, Y.-F. Tseng, H.-P. Su, R.-H. Hsu, and H. Kikuchi.  Secure hierarchical bitcoin wallet scheme against privilege escalation attacks.  International Journal of Information Security, 19, 2020.
  * [118] G. C. Fanti, S. B. Venkatakrishnan, S. Bakshi, B. Denby, S. Bhargava, A. Miller, and P. Viswanath.  Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees.  CoRR, abs/1805.11060, 2018.
  * [119] A. Feder, N. Gandal, J. Hamrick, and T. Moore.  The impact of DDoS and other security shocks on Bitcoin currency exchanges: Evidence from Mt. Gox.  Journal of Cybersecurity, 3:137–144, 2017.
  * [120] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee.  Hypertext Transfer Protocol – HTTP/1.1.  IETF Request for Comments, RFC 2616, 1999.  https://www.rfc-editor.org/info/rfc2616.
  * [121] L. Fournier.  CTV dramatically improves DLCs.  2022\.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html.
  * [122] Fresheneesz.  Tordl Wallet Protocols.  https://github.com/fresheneesz/TordlWalletProtocols.
  * [123] M. Froehlich, P. Hulm, and F. Alt.  Under Pressure. A User-Centered Threat Model for Cryptocurrency Owners.  Proceedings of the 2021 4th International Conference on Blockchain Technology and Applications, 2021.
  * [124] M. Froehlich, F. Waltenberger, L. Trotter, F. Alt, and A. Schmidt.  Blockchain and Cryptocurrency in Human Computer Interaction: A Systematic Literature Review and Research Agenda.  Proceedings of the 2022 ACM Designing Interactive Systems Conference, 2022.
  * [125] O. Gadyatskaya, R. Jhawar, P. Kordy, K. Lounis, S. Mauw, and R. Trujillo-Rasua.  Attack Trees for Practical Security Assessment: Ranking of Attack Scenarios with ADTool 2.0.  International Conference on Quantitative Evaluation of Systems, 2016.
  * [126] A. Gagol, J. Kula, D. Straszak, and M. Swietek.  Threshold ECDSA for Decentralized Asset Custody.  Cryptology ePrint Archive, Paper 2020/498, 2020.  https://eprint.iacr.org/2020/498.
  * [127] J. Garay, A. Kiayias, and N. Leonardos.  The Bitcoin backbone protocol: Analysis and applications.  Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 9057:281–310, 2015.
  * [128] J. Garay, A. Kiayias, and N. Leonardos.  The Bitcoin Backbone Protocol with Chains of Variable Difficulty.  In J. Katz and H. Shacham, editors, Advances in Cryptology – CRYPTO 2017, pages 291–323. Springer International Publishing, 2017.
  * [129] F. Garillot, Y. Kondi, P. Mohassel, and V. Nikolaenko.  Threshold schnorr with stateless deterministic signing from standard assumptions.  Cryptology ePrint Archive, Paper 2021/1055, pages 127–156, 2021.  https://eprint.iacr.org/2021/1055.
  * [130] R. Gennaro and S. Goldfeder.  Fast Multiparty Threshold ECDSA with Fast Trustless Setup.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, pages 1179–1194. ACM, 2018.
  * [131] R. Gennaro, S. Goldfeder, and A. Narayanan.  Threshold-Optimal DSA/ECDSA Signatures and an Application to Bitcoin Wallet Security.  Cryptology ePrint Archive, Paper 2016/013, 2016.  https://eprint.iacr.org/2016/013.
  * [132] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin.  Secure Distributed Key Generation for Discrete-Log Based Cryptosystems.  Proceedings of the 17th International Conference on Theory and Application of Cryptographic Techniques, 2005.
  * [133] A. Gervais, S. Capkun, G. O. Karame, and D. Gruber.  On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients.  In Proceedings of the 30th Annual Computer Security Applications Conference, ACSAC ’14, pages 326–335. ACM, 2014.
  * [134] S. Ghesmati, W. Fdhila, and E. Weippl.  SoK: How private is Bitcoin? Classification and Evaluation of Bitcoin Mixing Techniques.  Cryptology ePrint Archive, Paper 2021/629, 2021.  https://eprint.iacr.org/2021/629.
  * [135] S. Ghesmati, W. Fdhila, and E. Weippl.  Usability of Cryptocurrency Wallets Providing CoinJoin Transactions.  Cryptology ePrint Archive, Paper 2022/285, 2022.  https://eprint.iacr.org/2022/285.
  * [136] A. Gkaniatsou, M. Arapinis, and A. Kiayias.  Low-level attacks in bitcoin wallets.  Information Security, pages 233–253, 2017.
  * [137] S. Goldfeder, H. Kalodner, D. Reisman, and A. Narayanan.  When the cookie meets the blockchain: Privacy risks of web payments via cryptocurrencies.  Proceedings on Privacy Enhancing Technologies, 2018, 2017.
  * [138] Gregory Maxwell.  Coinjoin: Bitcoin privacy for the real world, 2013.  https://bitcointalk.org/index.php?topic=279249.0.
  * [139] J. Groth and V. Shoup.  Design and analysis of a distributed ECDSA signing service.  Cryptology ePrint Archive, Paper 2022/506, 2022.  https://eprint.iacr.org/2022/506.
  * [140] J. Groth and V. Shoup.  On the Security of ECDSA with Additive Key Derivation and Presignatures.  Cryptology ePrint Archive, Paper 2021/1330, 2022.  https://eprint.iacr.org/2021/1330.
  * [141] C. Guillemet.  Extracting seeds from Wallets, 2019.  https://blog.ledger.com/Extracting-Seeds/.
  * [142] C. Guillemet and J.-B. Bédrune.  On the security model of software wallets, 2021.  https://blog.ledger.com/software-wallets/.
  * [143] C. Guillemet and O. Hériveaux.  Extracting seed from Ellipal wallet, 2019.  https://blog.ledger.com/Ellipal-Security/.
  * [144] M. Guri.  BeatCoin: Leaking Private Keys from Air-Gapped Cryptocurrency Wallets.  CoRR, abs/1804.08714, 2018.  http://arxiv.org/abs/1804.08714.
  * [145] G. Gutoski and D. Stebila.  Hierarchical deterministic Bitcoin wallets that tolerate key leakage (short paper).  In Proceedings of the 19th International Conference on Financial Cryptography and Data Security (FC 2015). Springer, 2015.
  * [146] F. Hao, D. Clarke, and A. F. Zorzo.  Deleting Secret Data with Public Verifiability.  IEEE Transactions on Dependable and Secure Computing, 13(6):617–629, 2016.
  * [147] M. S. Haque.  An Evolutionary Approach of Attack Graphs and Attack Trees: A Survey of Attack Modeling.  2017\.  http://dcsl.cs.ua.edu/papers/SAM9712.pdf.
  * [148] D. A. Harding and P. Todd.  Opt-in Full Replace-by-Fee Signaling, 2015.  https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki.
  * [149] M. Harrigan and C. Fretter.  The Unreasonable Effectiveness of Address Clustering.  2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress, 2016.
  * [150] F. A. Hayek.  Denationalisation of Money - The Argument Refined: Second (Extended) Edition.  The Institute of Economic Affairs, 1978.
  * [151] A. Hayes.  Covenant, 2020.  https://www.investopedia.com/terms/c/covenant.asp.
  * [152] D. He, S. Li, C. Li, S. Zhu, S. Chan, W. Min, and N. Guizani.  Security analysis of cryptocurrency wallets in android-based applications.  IEEE Network, PP:1–6, 2020.
  * [153] M. Hearn and M. Corallo.  Connection Bloom filtering, 2012.  https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki.
  * [154] E. Heilman, A. Kendler, A. Zohar, and S. Goldberg.  Eclipse Attacks on Bitcoin Peer-to-Peer Network.  In 24th USENIX Security Symposium (USENIX Security 15), pages 129–144. USENIX Association, 2015.
  * [155] O. Helmer.  An experimental application of the delphi method to the use of experts.  Management Science, 9:458–467, 1963.
  * [156] H. Hermanns, J. Krämer, J. Krcál, and M. Stoelinga.  The Value of Attack-Defence Diagrams.  Principles of Security and Trust, pages 163–185, 2016.
  * [157] S. Hommel.  Vault-mbed, 2020.  https://github.com/fmr-llc/Vault-mbed.
  * [158] I. Homoliak, S. Venugopalan, Q. Hum, and P. Szalachowski.  A security reference architecture for blockchains.  In 2019 IEEE International Conference on Blockchain (Blockchain), pages 390–397, 2019.
  * [159] B. Hu, Z. Zhang, J. Liu, Y. Liu, J. Yin, R. Lu, and X. Lin.  A comprehensive survey on smart contract construction and execution: paradigms, tools, and systems.  Patterns, 2:100179, 2021.
  * [160] Y. Hu, S. Wang, G.-H. Tu, L. Xiao, T. Xie, X. Lei, and C. Li.  Security Threats from Bitcoin Wallet Smartphone Applications: Vulnerabilities, Attacks, and Countermeasures.  Proceedings of the Eleventh ACM Conference on Data and Application Security and Privacy, page 89–100, 2021.
  * [161] D. W. Hubbard and R. Seiersen.  How to Measure Anything in Cybersecurity Risk.  2016\.
  * [162] International Standards Organization.  ISO/IEC 27001 and related standards, 2022.  https://www.iso.org/isoiec-27001-information-security.html.
  * [163] S. Jain, E. W. Felten, and S. Goldfeder.  Determining an optimal threshold on the online reserves of a bitcoin exchange.  Journal of Cybersecurity, 2018.
  * [164] R. Jhawar, B. Kordy, S. Mauw, S. Radomirovic, and R. Trujillo-Rasua.  Attack Trees with Sequential Conjunction.  CoRR, abs/1503.02261, 2015.
  * [165] S. Jokić, A. S. Cvetković, S. Adamović, N. Ristić, and P. Spalević.  Comparative analysis of cryptocurrency wallets vs traditional wallets.  Ekonomika, 2019.
  * [166] S. Joshi, D. Pandey, and K. Srinathan.  ATSSIA: Asynchronous Truly-Threshold Schnorr Signing for Inconsistent Availability, pages 71–91.  2022\.
  * [167] M. Jourdan, S. Blandin, L. Wynter, and P. Deshpande.  Characterizing Entities in the Bitcoin Blockchain.  2018 IEEE International Conference on Data Mining Workshops (ICDMW), pages 55–62, 2018.
  * [168] S. Kanjalkar.  TapScript OP_CODES documentation for elements.  2021\.  https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality.
  * [169] N. P. Karvelas and A. Kiayias.  Efficient Proofs of Secure Erasure.  In Security and Cryptography for Networks, pages 520–537. Springer International Publishing, 2014.
  * [170] B. Keceli.  Bitmatrix: A Constant Product Market Maker Based on Recursive Covenants.  2021\.  https://docs.bitmatrix.app/v1/11_21_21/Bitmatrix_Paper_Early_Preview.pdf.
  * [171] E. Kiltz, D. Masny, and J. Pan.  Optimal security proofs for signatures from identification schemes.  Cryptology ePrint Archive, Paper 2016/191, 2016.  https://eprint.iacr.org/2016/191.
  * [172] P. Kim.  The Glacier Protocol and Using Dice To Generate Keys, 2021.  https://blog.keyst.one/the-glacier-protocol-and-using-dice-to-generate-keys-6677550c2b86.
  * [173] U. Kirstein, S. Grossman, M. Mirkin, J. Wilcox, I. Eyal, and M. Sagiv.  Phoenix: A Formally Verified Regenerating Vault.  2021\.  https://arxiv.org/pdf/2106.01240.pdf.
  * [174] R. Kissel, M. A. Scholl, S. Skolochenko, and X. Li.  SP 800-88 Rev. 1. Guidelines for Media Sanitization.  National Institute of Standards & Technology, 2006.
  * [175] C. Komlo and I. Goldberg.  FROST: Flexible Round-Optimized Schnorr Threshold Signatures.  Cryptology ePrint Archive, Paper 2020/852, 2020.  https://eprint.iacr.org/2020/852.
  * [176] B. Kordy, S. Mauw, S. Radomirovic, and P. Schweitzer.  Foundations of Attack–Defense Trees.  Lecture Notes in Computer Science, 2010.
  * [177] B. Kordy, L. Piètre-Cambacédès, and P. Schweitzer.  DAG-Based Attack and Defense Modeling: Don’t Miss the Forest for the Attack Trees.  Computer Science Review, 13, 2013.
  * [178] P. Koshy, D. Koshy, and P. McDaniel.  An Analysis of Anonymity in Bitcoin Using P2P Network Traffic.  Financial Cryptography and Data Security, pages 469–485, 2014.
  * [179] S. A. KrishnanThyagarajan, A. Bhat, G. Malavolta, N. Döttling, A. Kate, and D. Schröder.  Verifiable timed signatures made practical.  Cryptology ePrint Archive, Paper 2020/1563, 2020.  https://eprint.iacr.org/2020/1563.
  * [180] R. Kumar.  Truth or Dare: Quantitative security risk analysis using attack trees.  PhD thesis, 2018.
  * [181] R. Kumar and M. Stoelinga.  Quantitative Security and Safety Analysis with Attack-Fault Trees.  2017 IEEE 18th International Symposium on High Assurance Systems Engineering (HASE), 2017.
  * [182] J. Kurose and K. Ross.  Computer Networking: A Top-down Approach.  Always learning. Pearson, 2013.
  * [183] M. C. Kus Khalilov and A. Levi.  A Survey on Anonymity and Privacy in Bitcoin-Like Digital Cash Systems.  IEEE Communications Surveys Tutorials, 2018.
  * [184] H. Lallie, K. Debattista, and J. Bal.  A review of attack graph and attack tree visual syntax in cyber security.  Computer Science Review, 35:100219, 2020.
  * [185] J. Lau.  OP_PUSHTXDATA, 2017.  https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki.
  * [186] Y. Lindell.  Fast Secure Two-Party ECDSA Signing.  Advances in Cryptology – CRYPTO 2017, pages 613–644, 2017.
  * [187] Y. Lindell.  Simple Three-Round Multiparty Schnorr Signing with Full Simulatability.  Cryptology ePrint Archive, Paper 2022/374, 2022.  https://eprint.iacr.org/2022/374.
  * [188] Y. Lindell and A. Nof.  Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody.  In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, pages 1837–1854. ACM, 2018.
  * [189] K. Loaec.  Hardware wallets and “advanced” Bitcoin features, 2021.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018352.html.
  * [190] K. Loaec and A. Poinsot.  Revault: a multi-party Bitcoin vault architecture, 2020.  https://revault.dev/assets/revault_documentation.pdf.
  * [191] E. Lombrozo, J. Lau, and P. Wuille.  Segregated Witness (Consensus layer), 2015.  https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki.
  * [192] J. Lopp.  The Challenges of Optimizing Unspent Output Selection, 2015.  https://blog.lopp.net/the-challenges-of-optimizing-unspent-output-selection/.
  * [193] J. Lopp.  A Treatise on Bitcoin Seed Backup Device Design.  2022\.  https://blog.lopp.net/a-treatise-on-bitcoin-seed-backup-device-design/.
  * [194] J. Lopp.  Metal Bitcoin Seed Storage Reviews.  2022\.  https://jlopp.github.io/metal-bitcoin-storage-reviews/.
  * [195] S. Lucas.  The origins of the halting problem.  Journal of Logical and Algebraic Methods in Programming, 121:100687, 2021.
  * [196] Lukáš Kozák.  Security Analysis of Hardware Crypto Wallets, 2020.  https://dspace.cvut.cz/bitstream/handle/10467/88181/F8-BP-2020-Kozak-Lukas-thesis.pdf.
  * [197] A. D. Luzio, D. Francati, and G. Ateniese.  Arcula: A secure hierarchical deterministic wallet for multi-asset blockchains.  Cryptology ePrint Archive, Paper 2019/704, 2019.  https://eprint.iacr.org/2019/704.
  * [198] M. Mouchous.  Mounting a low-cost laser bench, 2022.  https://blog.ledger.com/laser-bench-low-price/.
  * [199] H. N. M. Sato, M. Shimaoka.  General Security Considerations for Cryptoassets Custodians.  2019\.  https://tools.ietf.org/html/draft-vcgtf-crypto-assets-security-considerations-05.
  * [200] E. V. Mangipudi, U. Desai, M. Minaei, M. Mondal, and A. Kate.  Uncovering impact of mental models towards adoption of multi-device crypto-wallets.  Cryptology ePrint Archive, Paper 2022/075, 2022.  https://eprint.iacr.org/2022/075.
  * [201] J. Martina, E. Dos Santos, M. Carlos, G. Price, and R. Custódio.  An adaptive threat model for security ceremonies.  International Journal of Information Security, 14, 2014.
  * [202] S. Matetic, K. Wüst, M. Schneider, K. Kostiainen, G. O. Karame, and S. Capkun.  BITE: Bitcoin Lightweight Client Privacy using Trusted Execution.  In IACR Cryptology ePrint Archive, 2018.
  * [203] P. Maynard, K. Mclaughlin, and S. Sezer.  Modelling Duqu 2.0 Malware using Attack Trees with Sequential Conjunction.  International Conference on Information Systems Security and Privacy, 2016.
  * [204] P. Maynard, K. McLaughlin, and S. Sezer.  Decomposition and sequential-AND analysis of known cyber-attacks on critical infrastructure control systems.  Journal of Cybersecurity, 6(1), 2020.
  * [205] P. McCorry, M. Möser, and S. Ali.  Why preventing a cryptocurrency exchange heist isn’t good enough.  Security Protocols XXVI, pages 225–233, 2018.
  * [206] B. McElrath.  Re-Imagining Cold Storage with Timelocks.  2016\.  https://medium.com/@BobMcElrath/re-imagining-cold-storage-with-timelocks-1f293bfe421f.
  * [207] S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. Mccoy, G. Voelker, and S. Savage.  A fistful of bitcoins: Characterizing payments among men with no names.  Communications of the ACM, 59, 2016.
  * [208] A. J. Menezes, S. A. Vanstone, and P. C. V. Oorschot.  Handbook of Applied Cryptography.  CRC Press, Inc., 1st edition, 1996.
  * [209] R. C. Merkle.  A digital signature based on a conventional encryption function.  In Annual International Cryptology Conference, 1987.
  * [210] G. Merzdovnik, M. Huber, D. Buhov, N. Nikiforakis, S. Neuner, M. Schmiedecker, and E. Weippl.  Block Me If You Can: A Large-Scale Study of Tracker-Blocking Tools.  In 2017 IEEE European Symposium on Security and Privacy (EuroS P), pages 319–333, 2017.
  * [211] T. Moore and N. Christin.  Beware the Middleman: Empirical Analysis of Bitcoin-Exchange Risk.  Financial Cryptography and Data Security, pages 25–33, 2013.
  * [212] T. Moore, N. Christin, and J. Szurdi.  Revisiting the risks of bitcoin currency exchange closure.  ACM Transactions on Internet Technology, 18:1–18, 2018.
  * [213] M. Möser, I. Eyal, and E. G. Sirer.  Bitcoin Covenants.  In FC ’16: Proceedings of the the 20th International Conference on Financial Cryptography, 2016.
  * [214] S. Nakamoto.  Bitcoin: A Peer-to-Peer Electronic Cash System.  2008\.  https://bitcoin.org/bitcoin.pdf.
  * [215] G. Naumenko and A. Riard.  CoinPool: efficient off-chain payment pools for Bitcoin.  2022\.  https://coinpool.dev/.
  * [216] R. M. Needham and M. D. Schroeder.  Using encryption for authentication in large networks of computers.  Communications ACM, 21(12):993–999, 1978.
  * [217] J. Newbery.  What is meant by transaction ‘pinning’?, 2018.  https://bitcoin.stackexchange.com/questions/80803/what-is-meant-by-transaction-pinning/80804#80804.
  * [218] H. Nguyen, P. Gray, M. Bencun, A. Chen, and R. Novak.  Bitcoin Secure Multisig Setup (BSMS), 2020.  https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki#Security.
  * [219] H. N. Nguyen, J. Bryans, and S. Shaikh.  Attack Defense Trees with Sequential Conjunction.  2019 IEEE 19th International Symposium on High Assurance Systems Engineering (HASE), 2019.
  * [220] J. Nick, A. Poelstra, and G. Sanders.  Liquid: A Bitcoin Sidechain, 2020.  https://blockstream.com/assets/downloads/pdf/liquid-whitepaper.pdf.
  * [221] J. Nick, T. Ruffing, and Y. Seurin.  MuSig2: Simple Two-Round Schnorr Multi-Signatures.  Cryptology ePrint Archive, Report 2020/1261, 2020.  https://eprint.iacr.org/2020/1261.
  * [222] J. Nick, T. Ruffing, Y. Seurin, and P. Wuille.  MuSig-DN: Schnorr Multi-Signatures with Verifiably Deterministic Nonces.  Cryptology ePrint Archive, Report 2020/1057, 2020.  https://eprint.iacr.org/2020/1057.
  * [223] J. O’Beirne.  A simple vault structure using OP_CTV.  https://github.com/jamesob/simple-ctv-vault.
  * [224] M. Ober, S. Katzenbeisser, and K. Hamacher.  Structure and Anonymity of the Bitcoin Transaction Graph.  Future Internet, 5:237–250, 2013.
  * [225] R. O’Connor.  TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT, 2022.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html.
  * [226] R. O’Connor and M. Piekarska.  Enhancing Bitcoin Transactions with Covenants.  In Financial Cryptography and Data Security, pages 191–198. Springer International Publishing, 2017.
  * [227] C. O’Flynn.  Glitching Trezor using EMFI Through The Enclosure, 2019.  https://colinoflynn.com/2019/03/glitching-trezor-using-emfi-through-the-enclosure/.
  * [228] O. Osuntokun and A. Akselrod.  Compact Client Side Filtering for Light Clients, 2017.  https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki.
  * [229] R. O’Connor.  Simplicity, 2017.  https://blockstream.com/simplicity.pdf.
  * [230] C. Paar and J. Pelzl.  Understanding Cryptography: A Textbook for Students and Practitioners.  Springer Publishing Company, Incorporated, 1st edition, 2009.
  * [231] M. Palatinus, P. Rusnak, A. Voisine, and S. Bowe.  Mnemonic code for generating deterministic keys, 2013.  https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki.
  * [232] S. Pan, K. Y. Chan, H. Cui, and T. H. Yuen.  Multi-Signatures for ECDSA and Its Applications in Blockchain.  Information Security and Privacy, page 265–285, 2022.
  * [233] R. Pass, L. Seeman, and A. Shelat.  Analysis of the Blockchain Protocol in Asynchronous Networks.  In J.-S. Coron and J. B. Nielsen, editors, Advances in Cryptology – EUROCRYPT 2017, pages 643–673. Springer International Publishing, 2017.
  * [234] M. S. Pedro, C. Guillemet, and V. Servant.  Breaking Trezor One with Side Channel Attacks, 2019.  https://blog.ledger.com/Breaking-Trezor-One-with-SCA/.
  * [235] D. Perito and G. Tsudik.  Secure Code Update for Embedded Devices via Proofs of Secure Erasure.  In D. Gritzalis, B. Preneel, and M. Theoharidou, editors, Computer Security – ESORICS 2010, pages 643–662. Springer Berlin Heidelberg, 2010.
  * [236] T. Perrin.  The Noise Protocol Framework.  2018\.  https://noiseprotocol.org/noise.pdf.
  * [237] M. Pettit.  Efficient Threshold-Optimal ECDSA.  Cryptology ePrint Archive, Paper 2021/1386, 2021.  https://eprint.iacr.org/2021/1386.
  * [238] A. Poelstra.  Tapscript: New Opcodes, Reduced Limits and Covenants.  2022\.  https://blog.blockstream.com/tapscript-new-opcodes-reduced-limits-and-covenants/.
  * [239] A. Poinsot.  James O’Beirne CTV vault using ANYPREVOUT in place of CTV.  https://github.com/darosior/simple-anyprevout-vault.
  * [240] L. Pompianu, M. Bartoletti, and B. Bellomy.  A journey into bitcoin metadata.  Journal of Grid Computing, 2019.
  * [241] J. Poon and T. Dryja.  The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.  2016\.  https://lightning.network/lightning-network-paper.pdf.
  * [242] J. Postel.  Internet protocol (ip).  IETF Request for Comments, RFC 791, 1981.  https://www.rfc-editor.org/info/rfc791.
  * [243] J. Postel.  Transmission control protocol (tcp).  IETF Request for Comments, RFC 793, 1981.  https://www.rfc-editor.org/info/rfc793.
  * [244] J. Postel and J. Reynolds.  File Transfer Protocol (FTP).  1985\.  https://www.rfc-editor.org/info/rfc959.
  * [245] S. Rashid.  Extracting TREZOR Secrets from SRAM, 2017.  https://saleemrashid.com/2017/08/17/extracting-trezor-secrets-sram/.
  * [246] J. Reardon, D. Basin, and S. Capkun.  SoK: Secure Data Deletion.  In 2013 IEEE Symposium on Security and Privacy, pages 301–315, 2013.
  * [247] F. Reid and M. Harrigan.  An Analysis of Anonymity in the Bitcoin System.  Security and Privacy in Social Networks, pages 197–223, 2013.
  * [248] M. Rhodes-Ousley.  Information Security The Complete Reference, Second Edition.  The Complete Reference. Mcgraw-hill, 2013.
  * [249] A. Riard.  Pinning : The Good, The Bad, The Ugly, 2020.  https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html.
  * [250] A. Riard and G. Naumenko.  Time-Dilation Attacks on the Lightning Network.  Cryptoeconomic Systems, 2021.  https://cryptoeconomicsystems.pubpub.org/pub/riard-lightning-dilation.
  * [251] D. Ron and A. Shamir.  Quantitative Analysis of the Full Bitcoin Transaction Graph.  Cryptology ePrint Archive, Paper 2012/584, 2012.  https://eprint.iacr.org/2012/584.
  * [252] J. Rubin.  Designing Bitcoin Contracts with Sapio.  https://learn.sapio-lang.org/.
  * [253] J. Rubin.  CHECKTEMPLATEVERIFY, 2020.  https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki.
  * [254] J. Rubin.  Building Vaults on Bitcoin, 2021.  https://rubin.io/bitcoin/2021/12/07/advent-10/.
  * [255] T. Ruffing, V. Ronge, E. Jin, J. Schneider-Bensch, and D. Schröder.  ROAST: Robust Asynchronous Schnorr Threshold Signatures.  Cryptology ePrint Archive, Paper 2022/550, 2022.  https://eprint.iacr.org/2022/550.
  * [256] R. Russell.  [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY, 2022.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020450.html.
  * [257] S. Volokitin.  Software Attacks on Hardware Wallets - Black Hat, 2018.  https://i.blackhat.com/us-18/Wed-August-8/us-18-Volokitin-Software-Attacks-On-Hardware-Wallets.pdf.
  * [258] A. Sasse, S. Brostoff, and D. Weirich.  Transforming the ‘weakest link’ — a human/computer interaction approach to usable and effective security.  BT Technology Journal, 19, 2001.
  * [259] C. Schmitz, A. Sekulla, and S. Pape.  Asset-centric analysis and visualisation of attack trees.  In Graphical Models for Security: 7th International Workshop, GraMSec 2020, Boston, MA, USA, June 22, 2020, Revised Selected Papers, page 45–64. Springer-Verlag, 2020.
  * [260] B. Schneier.  Attack Trees.  1999\.  https://www.schneier.com/academic/archives/1999/12/attack_trees.html.
  * [261] C. P. Schnorr.  Efficient signature generation by smart cards.  Journal of Cryptology, 4(3):161–174, 1991.
  * [262] D. Sempreboni and L. Viganò.  A mutation-based approach for the formal and automated analysis of security ceremonies.  Journal of Computer Security, 2022.
  * [263] A. Shostack.  Threat Modeling: Designing for Security.  2014\.
  * [264] M. Skibinsky and A. Krotou.  Generate a Seed Phrase using Dice., 2022.  https://vault12.com/securemycrypto/cryptocurrency-security-how-to/dice-crypto-recovery-seed/1-gather-your-pencil-and-paper-your-dice-a-bip39-word-list-and-let-s-get-ready-to-roll.
  * [265] D. Stinson and R. Strobl.  Provably Secure Distributed Schnorr Signatures and a (t, n) Threshold Scheme for Implicit Certificates.  Information Security and Privacy, pages 417–434, 2001.
  * [266] J. Swambo, S. Hommel, B. McElrath, and B. Bishop.  Bitcoin Covenants: Three Ways to Control the Future.  CoRR, abs/2006.16714, 2020.  https://arxiv.org/abs/2006.16714.
  * [267] J. Swambo, S. Hommel, B. McElrath, and B. Bishop.  Custody Protocols Using Bitcoin Vaults.  CoRR, abs/2005.11776, 2020.  https://arxiv.org/abs/2005.11776.
  * [268] W. Swanson.  Creating Bitcoin Private Keys with Dice, 2014.  https://www.swansontec.com/bitcoin-dice.html.
  * [269] T. Perrin.  The Noise Protocol Framework: Interactive handshake patterns (fundamental), 2018.  https://noiseprotocol.org/noise.html#handshake-patterns/.
  * [270] A. Taaki.  BIP Purpose and Guidelines, 2011.  https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki.
  * [271] B. Teinturier.  RBF Pinning with Counterparties and Competing Interest, 2020.  https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002739.html.
  * [272] J. Timón.  Simple Proof-of-Reserves Transactions, 2015.  https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki.
  * [273] P. Tolmach, Y. Li, S.-W. Lin, Y. Liu, and Z. Li.  A survey of smart contract formal specification and verification.  ACM Computing Surveys, 54:1–38, 2021.
  * [274] A. Towns.  SIGHASH_ANYPREVOUT for Taproot Scripts, 2019.  https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki.
  * [275] M. Tran, L. Luu, M. S. Kang, I. Bentov, and P. Saxena.  Obscuro: A Bitcoin Mixer using Trusted Execution Environments.  Cryptology ePrint Archive, Paper 2017/974, 2017.  https://eprint.iacr.org/2017/974.
  * [276] L. Trevisan.  CS276: Cryptography: Notes for Lecture 27, 2009.  http://theory.stanford.edu/~trevisan/cs276/lecture27.pdf.
  * [277] J. Valamehr, M. Chase, S. Kamara, A. Putnam, D. Shumow, V. Vaikuntanathan, and T. Sherwood.  Inspection Resistant Memory: Architectural Support for Security from Physical Examination.  SIGARCH Comput. Archit. News, 40(3):130–141, 2012.
  * [278] L. Valenta and B. Rowan.  Blindcoin: Blinded, accountable mixes for bitcoin.  Financial Cryptography and Data Security, pages 112–126, 2015.
  * [279] L. Van Der Horst, K.-K. R. Choo, and N.-A. Le-Khac.  Process memory investigation of the bitcoin clients electrum and bitcoin core.  IEEE Access, PP:1–1, 2017.
  * [280] S. B. Venkatakrishnan, G. C. Fanti, and P. Viswanath.  Dandelion: Redesigning the Bitcoin Network for Anonymity.  CoRR, abs/1701.04439, 2017.
  * [281] L. Viganò.  Formal methods for socio-technical security: (formal and automated analysis of security ceremonies).  Coordination Models and Languages (COORDINATION 2022), 2022.
  * [282] Z. Voell.  Sorry, Bitcoin is still Anarchist.  2018\.  https://medium.com/@zackvoell/sorry-bitcoin-is-still-anarchist-3e995d2fbbf1.
  * [283] S. Volokitin.  Glitch in the Matrix: Exploiting Bitcoin Hardware Wallets, 2019.  https://www.offensivecon.org/speakers/2019/sergei-volokitin.html.
  * [284] H. Wang, X. Li, J. Gao, and W. Li.  Mobt: A kleptographically-secure hierarchical-deterministic wallet for multiple offline bitcoin transactions.  Future Generation Computer Systems, 101, 2019.
  * [285] H. Wang, W. Ma, F. Deng, H. Zheng, and Q. Wu.  Dynamic threshold ECDSA signature and application to asset custody in blockchain.  Journal of Information Security and Applications, 61:102805, 2021.
  * [286] J. D. Weiss.  A system security engineering process.  In Proceedings of the 14th National Computer Security Conf., 1991.
  * [287] D. A. Wheeler.  What is open security?, 2013.  https://dwheeler.com/essays/open-security-definition.html.
  * [288] P. Wuille, , J. Nick, and T. Ruffing.  Schnorr Signatures for secp256k1, 2020.  https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki.
  * [289] P. Wuille, , J. Nick, and A. Towns.  Validation of Taproot Scripts, 2020.  https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki.
  * [290] P. Wuille.  Hierarchical Deterministic Wallets, 2012.  https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki.
  * [291] P. Wuille, J. Nick, and A. Towns.  Taproot: SegWit version 1 output spending rules, 2019.  https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki.
  * [292] Y. E. Bulut and İ. Sertkaya.  Security Problem Definition and Security Objectives of Cryptocurrency Wallets in Common Criteria, 2020.  https://dergipark.org.tr/tr/download/article-file/1081388.
  * [293] T. H. Yuen, H. Cui, and X. Xie.  Compact Zero-Knowledge Proofs for Threshold ECDSA with Trustless Setup.  Cryptology ePrint Archive, Paper 2021/205, 2021.  https://eprint.iacr.org/2021/205.
  * [294] F. Zhang, P. Daian, I. Bentov, I. Miers, and A. Juels.  Paralysis proofs: Secure dynamic access structures for cryptocurrency custody and more.  In Proceedings of the 1st ACM Conference on Advances in Financial Technologies, AFT ’19, page 1–15. Association for Computing Machinery, 2019.
  * [295] ZmnSCPxj.  Speedy covenants (OP_CAT2), 2022.  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/{020434}.html.