LedgerLocks: A Security Framework for Blockchain Protocols Based on Adaptor Signatures

The scalability and interoperability challenges in current cryptocurrencies have motivated the design of cryptographic protocols that enable efficient applications on top and across widely used cryptocurrencies such as Bitcoin or Ethereum. Examples of such protocols include (virtual) payment channels, atomic swaps, oracle-based contracts, deterministic wallets, and coin mixing services. Many of these protocols are built upon minimal core functionalities supported by a wide range of cryptocurrencies. Most prominently, adaptor signatures (AS) have emerged as a powerful tool for constructing blockchain protocols that are (mostly) agnostic to the specific logic of the underlying cryptocurrency. Even though AS-based protocols are built upon the same cryptographic principles, there exists no modular and faithful way for reasoning about their security. Instead, all the works analyzing such protocols focus on reproving how adaptor signatures are used to cryptographically link transactions while considering highly simplified blockchain models that do not capture security-relevant aspects of transaction execution in blockchain-based consensus. To help this, we present LedgerLocks, a framework for the secure design of AS-based blockchain applications in the presence of a realistic blockchain. LedgerLocks defines the concept of AS-locked transactions, transactions whose publication is bound to the knowledge of a cryptographic secret. We argue that AS-locked transactions are the common building block of AS-based blockchain protocols and we define GLedgerLocks a realistic ledger model in the Universal Composability framework with built-in support for AS-locked transactions. As LedgerLocks abstracts from the cryptographic realization of AS-locked transactions, it allows protocol designers to focus on the blockchain-specific security considerations instead.


INTRODUCTION
Blockchain-based cryptocurrencies such as Bitcoin, enable mutually distrusting users to perform financial transactions without relying on a trusted third party.However, for their large-scale adoption, cryptocurrencies face major interoperability and scalability challenges.These challenges can be tackled with the help of cryptographic protocols that form a more flexible application layer on top of the core cryptocurrency functionalities.Prominent examples are atomic swaps [31] for users to trade their coins across different cryptocurrencies or payment channels [1] to perform an unlimited number of fast bilateral payments while publishing only a small number of transactions on the blockchain.
To ease the interoperability across cryptocurrencies, these protocols are usually realized upon simple core operations supported by most cryptocurrencies (e.g., payment authorization with a digital signature from the sender).This endeavor has been facilitated by the recent discovery of adaptor signatures (AS) [1,16], which allow for conditioning the creation of a digital signature on the knowledge of a cryptographic secret.
Despite the multitude of cryptographic blockchain protocols relying on adaptor signatures [2,5,10,17,19,[22][23][24][25]31], the security analysis of these protocols is usually incomplete.This is due to the fact that the security of these protocols does not only rely on the correct usage of cryptographic primitives used in the message exchanges between protocol participants but also on the guarantees that stem from the underlying blockchain consensus.In spite of that, all current works proposing new AS-based blockchain protocols study their security in the context of highly simplified ledger models, defined in an ad-hoc manner [1,3,4,19,24,28,31].
However, the subtleties of the ledger model have a significant influence on the blockchain protocol security and neglecting these aspects can easily result in undetected security issues as we will show in §2.Consequently, it is highly desirable to build an infrastructure that facilitates the reasoning about AS-based blockchain protocols in the presence of a realistic ledger.
Towards this goal, we propose LedgerLocks, a framework for separating the reasoning about ledger-specific aspects of AS-based blockchain protocols from the cryptographic operations.We observe that adaptor signatures are used in these protocols to encode a generic building block that we call AS-locked transactions.AS-locked transactions are transactions whose publication on the blockchain is bound to the knowledge of a cryptographic secret in two ways: (i) knowing the cryptographic secret is a prerequisite for a party holding the AS-locked transaction to publish it on the ledger, and (ii) the publication of the AS-locked transaction on the ledger reveals the secret to all parties holding the AS-locked transaction.By synthesizing this building block and integrating it into a realistic ledger functionality, we can describe many blockchain protocols in terms of this functionality without the cryptographic interactions between the protocol participants.We illustrate this approach in Figure 1: In the state of the art, AS-based blockchain protocols are mainly given through the exchange of cryptographic messages among the participants.These interactions shall ensure that the protocol participants can construct valid transactions to be published on the blockchain (given through a simplified ledger functionality G  ) in compliance with the protocol goals.The cryptographic reasoning for showing the security of these interactions is essentially the same throughout the state-of-the-art protocols (denoted by the green parts of protocols App 1 to App  ).In Ledger-Locks, we define a realistic ledger functionality G LedgerLocks that supports generic AS-locked transactions and, thus, subsumes the cryptographic aspects of these protocols.In this way, AS-based blockchain protocols can be described in terms of AS-locked transactions without further need for cryptographic interactions between the protocol participants.Consequently, the subsequent security analysis of such protocols does not require cryptographic reasoning but can focus on the ledger-specific security arguments.Lifting the burden of concurrently reasoning about both cryptographic and ledger-specific security aspects paves the ground for the security analysis of blockchain protocols in realistic ledger models.
Constructing G LedgerLocks comes with multiple technical challenges: The logic of protocols using AS-locked transactions usually relies on relating these transactions through the structure of their cryptographic conditions.Therefore, for truly modular reasoning we need a general model of cryptographic conditions that integrates with G LedgerLocks and is adaptable to the protocol needs.Further, to show that G LedgerLocks is realizable by adaptor signatures in the presence of such a model of cryptographic conditions, a novel composable notion of adaptor signature security is needed.Finally, to facilitate flexible reasoning in a faithful ledger model, we need to model G LedgerLocks to expose provably realistic ledger behavior while supporting a generic notion of AS-locked transactions.
In this work, we overcome these challenges as follows: • We model cryptographic conditions as a standalone (global) ideal functionality G Cond , which encodes operations over conditions, such as their composition.G Cond can be easily extended to account for other operations in a modular fashion, that is, without modifying the several other functionalities using it in a shared manner to keep conditions consistent across them ( §5).
• We model (two-party) adaptor signatures as an ideal functionality F AdaptSig and prove that it is UC-realized by any two-party adaptor signature with aggregatable public keys generated from an identification scheme [16], a class encompassing all the digital signatures used in current AS-based applications ( §6).
• Based on the ledger functionality G Ledger from Badertscher et al. [8], which has been proven to be realizable by the Bitcoin backbone protocol [8] as well as the proof of stake-based protocol Ouroboros Genesis [7], we propose G LedgerLocks , an ideal functionality that models a ledger with generic AS-locked transactions.We provide a protocol Π LedgerLocks that UC-realizes G LedgerLocks in the presence of G Ledger from [8] and F AdaptSig ( §7).
• We demonstrate the flexibility of our framework, by using it to describe an enhanced atomic swap protocol Π AtomicSwap and a multi-hop payment protocol Π MultiHop over payment channels Π Channel , all of them protocols relying on AS-locked transactions.To this end, we instantiate G LedgerLocks with support for transaction timelocks, which are crucial for atomic swap and multi-hop payment security.The description of Π AtomicSwap , Π Channel and Π MultiHop does not involve additional cryptography, and hence, can focus on the delicate task of adjusting the protocol timelocks to provide security in the presence of realistic blockchains as modeled by G LedgerLocks ( §8).

STATE-OF-THE-ART BLOCKCHAIN PROTOCOL ANALYSIS
In this section, we overview the existing approaches to analyzing the security of (AS-based) blockchain protocols with an emphasis on the ledger modeling.For this, we first give background on the workings of realistic ledgers and then illustrate the impact of the ledger model on the security analysis using the examples of an atomic swap and a multi-hop off-chain payment protocol.Finally, we discuss the ledger models used in literature and their limitations.
Blockchain workings.In cryptocurrencies built upon a tamperresistant distributed ledger (the blockchain), network participants conduct transactions by broadcasting them to the network.Specific network nodes, so-called miners, group valid transactions into blocks and append them to the blockchain.To ensure fairness, the miner selection process is randomized based on a resource in the possession of miners (usually their computational power or financial stakes).With a majority of the resource being owned by honest miners, it is guaranteed that the system will progress safely: Eventually, the system will reach consensus on a stable prefix of the blockchain and valid transactions are guaranteed to be eventually included in such a stable prefix.
The resulting transaction execution model comes with several peculiarities: Transactions submitted by honest users are not necessarily guaranteed to be included in the blockchain but could still be outrun by (adversarial) transactions that invalidate them, e.g., by consuming the same assets.Also, transactions are already public before their inclusion in the blockchain, possibly leaking sensitive information to a (miner-controlling) attacker.Atomic swaps.An atomic swap (Figure 2) involves two ledgers A (blue), B (orange) and two users Alice (A) and Bob (B), holding assets in A and B, respectively.A correct atomic swap protocol ensures that Alice receives Bob's assets on B and Bob receives Alice's assets on A if both parties are honest.An atomic swap protocol is considered secure if an honest party always either (i) receives the other party's assets; or (ii) keeps their own assets.To set up such an atomic swap, Alice locally creates a cryptographic secret .Moreover, Alice and Bob deposit their assets into a shared account AB in the respective chain (through deposit transaction dtx  and dtx  ).The assets in a shared account are set up such that they can be released by the intended receiver showing the secret value  or refunded to the original owner.This functionality is achieved by Alice and Bob jointly creating AS-locked transactions ctx  and ctx  , which can only be submitted upon the knowledge of secret  and whose publication will release  to the other party.Further, they create the refund transactions rtx  and rtx  that allow Alice and Bob to retrieve back their assets in case the other party stops collaborating.
After a successful setup, Alice, who knows the secret , can claim Bob's assets in B (using ctx  ).Then, Bob can read  from B and use it to claim the assets in the shared account on A (using ctx  ).Alternatively (e.g., if the other user fails to cooperate), Alice and Bob can refund their assets by publishing rtx  or rtx  , respectively.Alice's refund transaction rtx  is equipped with a timelock that ensures that it can only be published after time .This restriction prevents Alice from simultaneously publishing rtx  and ctx  to retrieve the assets on both chains.Instead, if Alice has not claimed Bob's assets (through ctx  ) until time right before , Bob can publish rtx  to be refunded before rtx  becomes valid at time .Ledger model and atomic swap security.Although the idea behind the atomic swap protocol seems simple, it is only secure when assuming a highly simplified ledger model.More precisely, its security relies on the assumption that rtx  will be included immediately after Bob sent it to the network.In practice, the ledger only guarantees, that rtx  will be included in the blockchain within a time delay Δ.During this time, other transactions (even if submitted later) may be included in the blockchain, invalidate rtx  and, thus, prevent its inclusion.Specifically, a malicious Alice could send ctx  right after observing rtx  on the network.As a consequence, ctx  could be included in the blockchain first, canceling rtx  .
To secure the atomic swap protocol in the presence of such ledgers, Bob's behavior in the protocol needs to be adapted as illustrated in Figure 3 (top): Right before time  − 2Δ, Bob needs to initiate the refund of their assets by publishing rtx  (denoted by a dotted arrow).Like this, Bob knows right before time  − Δ whether the refund was successful or whether Alice managed to outrun Bob with ctx  .In the latter case, Bob learns  and publishes ctx  , which is guaranteed to be included before , the time starting from which Alice could publish rtx  .
Interestingly, even the adapted protocol is insecure when considering another subtlety of realistic ledger workings: Once submitted to the network, a transaction becomes public to the miners, even before being included in the blockchain.Considering that and despite her advantage of exclusively knowing secret , Alice is subject to an attack (Figure 3, bottom).When Alice claims Bob's assets (by publishing ctx  ), a malicious Bob can learn  and still outrun ctx  with rtx  .Then, Bob could claim Alice's assets (publishing ctx  ) before Alice could refund her assets using rtx  at time .
This issue can be mitigated when introducing an additional timelock for Bob's refund transaction rtx  but it would stay undetected when relying on a ledger model that does not leak transactions to the attacker upon their submission to the network.
Multi-hop payment security.The described issues do not only apply to atomic swaps but extend to a wide range of (AS-based) blockchain protocols.One example is off-chain payments in payment channel networks such as described in [24].Payment channel networks, like Bitcoin's Lightning Network [26], form a layer for fast peer-to-peer payments on top of cryptocurrencies by relying on two-party payment channels.In a payment channel, users lock funds in a shared account and exchange guarantees for the ownership Figure 4: Setup for a multi-hop payment from sender  to receiver .Dotted boxes denote payment channels between users, with the funds of the left participant in white, funds of the right participant in green, and locked funds in black.The distribution of locked funds is controlled using transactions ctx  and rtx  .distribution (channel state) of these funds.In this way, collaborative channel users can perform offchain payments by updating the channel state without making transactions on the blockchain.The channel parties can always close the channel (e.g. when the other party stops collaborating) by publishing transactions on the blockchain to obtain the funds according to the latest channel state.
Users that do not share a payment channel can still securely exchange offchain payments as long as they are connected via a path in a payment channel network as illustrated in Figure 4.For preparing a payment, the users   on a payment path between sender  (=  0 ) and receiver  (=   ) lock channel funds for the payment such that the payment later can be enforced atomically.To this end, the users   (0 ≤  < ) prepare conditional offchain payments based on some condition   to their successors  +1 on the payment path.These conditional offchain payments are realized through AS-locked transactions ctx  on the channel funds that can be published once the channel is closed.The conditions   are set up such that if user  +1 claims ctx  , this will reveal a secret   to   allowing them to satisfy  −1 and claim ctx −1 in turn.Once all conditional payments are set up,  initiates the payment by revealing a secret   to  that allows them to open  −1 .Next, the payment gets propagated through the payment path: Collaborative users   and  +1 can update their payment channels offchain after revealing the secret that would enable ctx  .If   is not collaborating,  +1 can close the channel and use ctx  to enforce the conditional payment based on the last channel state.
To ensure that a malicious sender cannot indefinitely lock the funds of intermediaries on the path, the users, in addition to ctx  prepare a refund transaction rtx  that allows   to retrieve back their funds after time   .As for the atomic swap protocol, such a refund option introduces additional challenges in the design of a secure protocol: If user  +1 is not responding, honest   needs to close the channel and invoke the refund using rtx  .However, even after successful channel closure while waiting for rtx  to be included in the blockchain,  +1 may still decide to publish ctx  instead.In this case   needs to observe ctx  on the blockchain, learn   and use it to continue the payment (either offchain or onchain).For this, it needs to be ensured that ctx −1 is still valid at this point and so that rtx −1 has not been published yet.
This illustrates how the protocol design is closely intertwined with the precise guarantees that the underlying ledger provides: (i) The protocol transactions need to have timelocks that respect the ledger inclusion times.In particular, timelock   of rtx  needs to be adjusted such that   <  −1 + 2Δ + Δ close (for  −1 being the timelock of rtx −1 and Δ close being the channel closing time) to ensure that   after closing their outgoing channel and publishing rtx  at   , when learning (latest) at   + Δ whether rtx  or ctx  got included in the blockchain there is still enough time to close their ingoing channel and publish ctx −1 on the blockchain (which may take up to Δ close + Δ). (ii) The honest participant strategies need to respect the timing constraints.It is e.g., crucial that honest participants frequently poll the blockchain for the inclusion of payment channel closing transactions and to react on the publication of a claim transaction ctx onchain in well-defined time windows to obtain the desired correctness guarantees.
If the ledger model is not accounting for the exact ledger behavior concerning the attacker's delay and learning capabilities, wrong protocols can easily be proven secure.E.g., consider a version of the multi-hop payment protocol where receiver  accepts 's payment too late: After setting up the payment, if  receives   only after   + Δ close ,  is not guaranteed anymore to receive the payment: If  −1 does not collaborate in updating the channel,  needs to close the channel with  −1 (taking up to Δ close ) and then publish ctx  at time  <   .At   , however, a malicious  −1 already submitted rtx  to outrun ctx  resulting in  −1 being refunded while still learning   .With the knowledge of   ,  −1 completes the payment and receives the funds meant for .Similar to the atomic swap example, such an attack could not be detected in the presence of a ledger model with instant transaction inclusion or without modeling that the attacker may learn transaction details (such as   ) before the transaction's inclusion in the blockchain.
Ledger models in the state of the art.As highlighted by the examples in the last paragraph, there are several realistic ledger features whose modeling comes with immediate security implications: Foremost, this is a realistic attacker model that accounts for both the attacker knowledge (e.g., the knowledge of transactions after they got submitted but before they got included in the blockchain) and the attacker capabilities (e.g., to influence the order and time of transaction inclusion).Related to the attacker capabilities, the concrete inclusion time guarantees for honest users are crucial for secure protocol design (e.g., for the correct adjustment of timeouts).
The importance of a realistic ledger model for the security analysis of blockchain protocols is also emphasized by [20] who propose a formal security analysis of Bitcoin's Lightning Network in the presence of the ledger model G Ledger from [8].The authors showcase that for precisely specifying the Lightning Network protocol, it is inevitable to rely on the exact timing guarantees obtained from the ledger in [8].Further, they prove that the simplified models that are used in the security analysis of [12][13][14][15]31] do not only not fail to reflect the guarantees of realistic ledgers but that it is impossible to design a ledger that could provide such guarantees.
However, as summarized in Table 1, the state-of-the-art still analyses blockchain protocols in the presence of simplified ledger models, which disregard security-relevant ledger features.These works consider either (i) (provable unrealizable) ledgers L inst with immediate inclusion guarantees [12][13][14][15]31]; or (ii) ledgers L Δ that let the attacker delay the inclusion of a transaction up to delay Δ [1,2,4,5,19,27,28,30,32].Even in protocols from the second category, the exact way that the attacker can exercise their power to delay transactions stays vague.E.g., in [1], it is stated that upon a message being posted by the user, the ledger should "wait until round  1 ≤  0 + Δ (the exact value of  1 is determined by the 1: Overview of features of ledger models used for the analysis of blockchain protocols.X * denotes that the corresponding ledger feature is underspecified, X † indicates that the realizability of L Δ is unknown.adversary)".This description leaves open at which point in time and based on which information the adversary determines the inclusion time  1 .However, as shown for the example of atomic swap and multi-hop payments, leaving these aspects underspecified may result in the security analysis missing relevant attacks.

TECHNICAL OVERVIEW
In this section, we overview the LedgerLocks framework.For enabling modular reasoning about the security of blockchain protocols, LedgerLocks relies on the Universal Composability (UC) framework of Canetti [11].In the UC framework, the security of protocols is defined in terms of ideal functionalities, which describe the idealized secure protocol behavior.Slightly simplified, a protocol is considered secure (w.r.t. an ideal functionality) if an adversarial environment cannot distinguish whether it interacts with the protocol or with the ideal functionality.This security notion is sufficiently strong to enable modular security reasoning.More precisely, once protocol Π is proven secure w.r.t. an ideal functionality F , the security of protocols using Π as a subroutine can be analyzed assuming F as subroutine instead.
The LedgerLocks framework provides ideal functionalities to characterize the security of cryptographic conditions (G Cond ), adaptor signatures (F AdaptSig ), and lock-enabling ledgers (G LedgerLocks ). Figure 5 depicts how these ideal functionalities connect to finally expose an interface for modularly defining AS-based blockchain protocols (such as an atomic swap protocol Π AtomicSwap ) based on lock-enabling ledgers and cryptographic conditions.
In the following, we describe in more detail the different components of the LedgerLocks framework (as highlighted by the different background colors in Figure 5).To this end, Figure 6 gives a more granular account of the individual components from Figure 5.
Conditions.We first define the ideal functionality G Cond for representing (secure) cryptographic conditions ( §5).Intuitively, a cryptographic condition describes the properties as given by a hard relation .Concretely, a condition is identified by a public statement and we say that the condition is satisfied if the corresponding witness is provided.Due to the hardness of the relation, without prior knowledge, it is hard to come up with a witness satisfying a given condition.A typical example is the discrete logarithm (DLOG) assumption over certain cyclic groups (G, , ) (with generator  and order ), where given a group element (the statement)  =   , it is hard to compute the exponent  (the witness).
At first sight, it may seem counter-intuitive to define conditions as a standalone ideal functionality.The reason for doing so is that § § § § the prerequisites for a party to craft a witness related to a statement often emerge from a cryptographic protocol for the condition creation.As an example, consider the following scenario.Alice plays a simple guessing game with Bob.If Bob can guess a number between 1 and 10 then he gets a prize from Alice.To implement this based on DLOG, Alice prepares ten secret witnesses ( mask For reasoning about the above-described guessing game, we need to capture that there are ten conditions out of which Bob can open exactly one.However, the creation of conditions with this property involves a protocol itself.This condition-creation protocol is independent of more advanced protocols relying on conditions with the respective property.In summary, by modeling conditions as a separate functionality, we can modularize reasoning about condition creation (e.g., # »  guess ) and protocols using these conditions (e.g., the payment from Alice to Bob based on  guess ). Technically, this means that we can extend the functionality G Cond with further types of conditions without reproving any of the results in Sections 6 and 8.For the scope of this work, we present three different forms of conditions: 1) Plain conditions (which we call individual conditions), which users can create on their own by creating a fresh witness and the corresponding statement for a given hard relation.2) Composed conditions, which combine two existing conditions.The concrete composition operation depends on the underlying hard relation and is specified as a parameter  merge to the functionality G Cond .3) 1-out-of-n conditions, which enable a party  together with a set of users  to jointly create a vector of statements, such that  can (without the collaboration of all users in  ) only know the witness for exactly one out of these statements.The described guessing game included the creation of a 1-out-of-10 condition for DLOG with  = Bob and  = {Alice}.
Note that we fix the hard relation  (as well as  merge ) as a parameter to G Cond .This is needed to enable composability with the adaptor signature functionality F AdaptSig , which is also defined w.r.t. to .In §5, we show how to provably realize G Cond for the DLOG relation with the protocol Π Cond .
Within our LedgerLocks framework, we treat G Cond as a global subroutine [6].In the UC framework, a global subroutine G is an ideal functionality that can be securely used by some protocol Π, even if Π relies on another functionality F , which makes use of G as a subroutine.One can think of G as constituting some safely shared state between Π and F .An example for this usage of G Cond is shown in Figure 6: Here, the protocol Π AtomicSwap uses the functionalities G Cond (for creating conditions) and G LedgerLocks again uses G Cond as a subroutine (for checking conditions).Having G Cond as a global subroutine, intuitively allows us to define higher-level functionalities relative to a shared, stateful notion of conditions.
Adaptor signatures.In §6, we define F AdaptSig , an ideal functionality for adaptor signatures.Following the two-party adaptor signatures scheme defined by Erwig et al. [16], our ideal functionality F AdaptSig allows two parties to jointly create a verification key, sign a message and pre-sign a message with respect to a given condition.Moreover, each user on its own can adapt a pre-signature into a valid signature if they can satisfy the corresponding condition.Finally, they can also extract the witness  for a condition  if, for any given message , they can provide a valid pre-signature σ on  with condition  and the corresponding full signature  obtained through adaptation with .
In contrast to the adaptor signature scheme whose security is characterized in terms of game-based security definitions, modeling adaptor signatures as an ideal functionality comes with the benefits of composable reasoning in the UC framework.In particular, it enables modular reasoning with respect to conditions, since our model of F AdaptSig relies on G Cond to handle conditions.This means that for signature adaption F AdaptSig queries G Cond for determining whether the correct witness to open a condition was provided.Similar to G Cond , F AdaptSig is parameterized by a hard relation , and additionally a function  adapt , which transforms a pre-signature σ and a witness  into a corresponding full signature .This parametrization enables F AdaptSig to use conditions as provided by G Cond in a truly modular fashion.Without fixing  adapt , it would be required to make assumptions on the way that protocols relying on F AdaptSig use G Cond for condition generation.We include a more detailed discussion of this aspect in §6.
In practice, the parametrization by  adapt does not pose a restriction.Indeed, we can show that F AdaptSig is realizable for a big class of adaptor signatures (and corresponding adaptation functions).Erwig et al. [16] showed a generic transformation from signature schemes built from an identification scheme to two-party signature schemes (with aggregatable public keys), and then from there to two-party adaptor signature schemes.This transformation requires an adaptation function  adapt with certain generic properties.We can show that all adaptor signature instances resulting from the transformation realize F AdaptSig for the same  adapt function as used in the transformation.More precisely, we give a generic wrapper protocol Π AdaptSig around the algorithmic interface of two-party adaptor signature schemes (as defined in [16]) and prove this protocol to realize F AdaptSig by reduction to the game-based security properties for adaptor signatures.Since (virtually all) the concrete adaptor signature constructions proposed so far are identification scheme-based signature schemes, our proof shows all of these schemes to realize F AdaptSig .
Lock-enabling ledger.In §7, we define G LedgerLocks , an ideal functionality for a distributed ledger with AS-locked transactions.In the design of G LedgerLocks , we follow the technique in [8]: The authors in [8] provide G Ledger , an ideal functionality modeling the subtleties of real-world blockchain consensus, in particular, realistic guarantees about the inclusion of transactions into the ledger.Moreover, they give Π Ledger , a description of the Bitcoin backbone protocol and prove that it UC-realizes G Ledger .
G Ledger and Π Ledger are generic in that they do not fix the concrete transaction format or ledger logic.Instead, both of them are parametrized with a predicate isValidTx, which based on the internal ledger state determines whether a transaction is valid.
In this manner, the UC-realization proof holds for any instantiation of this predicate.Moreover, one can leverage the results in [8] by extending G Ledger in two ways: (i) instantiating isValidTx predicate to account for the specific transaction formats and ledger logics; and (ii) extending the API of G Ledger to account for further ledger features.Our ideal functionality G LedgerLocks follows this blueprint to model multi-party account-based transaction authorization.
In more detail, G LedgerLocks allows multiple parties to create a joint account.Transactions are associated with the set of all accounts, which need to provide authorization for transaction publication on the ledger.In addition to full authorization, accounts can lock a transaction on a condition, in which case any account owner can complete the authorization by providing an adequate witness.If such a AS-locked transaction is published on the ledger, honest account owners learn the corresponding witness, while a malicious owner learns the witness already upon transaction submission.
We build G LedgerLocks from G Ledger by 1) requiring the transaction format to include the list of accounts to authorize the transaction; 2) adding additional state and interfaces for the new operations; and 3) instantiating the valid predicate to check for correct transaction authorization.The operation for releasing a AS-locked transaction thereby makes use of G Cond to determine whether a provided witness satisfies the condition of the corresponding transaction.To stay general, we do not fully fix the transaction format and the isValidTx predicate but introduce another predicate CheckBase, which performs additional transaction validity checks.In this way, we can modularly add further functionality to G LedgerLocks , e.g., support for timelocks as we will show in §8.
Finally, we show how to realize G LedgerLocks with a protocol Π LedgerLocks , which uses G Ledger and F AdaptSig .Thanks to our modeling of G Cond as global ideal functionality, the whole construction and proof are independent of the concrete realization of conditions.
Using the framework.We show how to use our LedgerLocks framework using an oracle-based atomic swap protocol that relies on AS-locked transactions as a case study.An oracle-based atomic swap works as the swap protocol described in §2 with the only difference that a third party (the oracle) needs to agree to the swap being executed.To this end, the condition locking the claim transactions is composed of a condition  chosen by Alice and a condition   chosen by the oracle so that the oracle needs to communicate its witness for   to Alice for enabling the swap.
To express this protocol (denoted by Π AtomicSwap ), we (partially) instantiate the CheckBase predicate of G LedgerLocks to encode a timelock check.Since G LedgerLocks is an extension of G Ledger , we inherit its guarantees concerning the transaction inclusion time.Based on these guarantees, we can create timelocks that ensure that (1) Alice can successfully claim Bob's assets before Bob can refund and (2) Bob has always enough time to claim Alice's assets if Alice has claimed Bob's assets before, avoiding the attacks from §2.Note that Π AtomicSwap does not only rely on G LedgerLocks but also on G Cond for the condition creation.The swap conditions are created by composing two conditions  and   .Since LedgerLocks is fully modular with respect to G Cond , it is not even necessary to fix the protocol to create   .
This example shows the flexibility of the LedgerLocks framework to use conditions in a way parametric to the other functionalities.To show this beyond the atomic swaps, we use LedgerLocks to express a multi-hop payment protocol over payment channels in the full version [29].These examples also demonstrate how the ledger functionality can be easily extended to account for new ledger features, avoiding repetitive proofs for the ledger core functionality.Privacy.Adaptor signatures come with privacy advantages that cannot easily be captured within UC-based security definitions.For completeness, we discuss privacy in §6 and give (game-based) definitions for adaptor signature privacy and a resulting privacy notion achieved by lock-enabling ledgers in the full version [29].

PRELIMINARIES
We review adaptor signatures and defer their full definition and other basic cryptographic primitives to the full version [29].We define a two-party adaptor signature scheme with respect to a standard two-party signature scheme with aggregatable public keys Σ 2 and a hard relation .We first recall the notion of a hard relation.

Definition 1 (Hard Relation).
Let  be a relation with statement/witness pairs (, ).Let   be the associated language   := { | ∃ s.t.( , ) ∈ }.We say that  is a hard if: 1) There exists a PPT sampling algorithm GenR(1  ) that on input the security parameter  outputs a statement/witness pair (, ) ∈ . 2) The relation is poly-time decidable.3) For all PPT adversaries A there exists a negligible function negl, such that: In an adaptor signature scheme, for any statement  ∈   , a signer holding a secret key can produce a pre-signature w.r.t. on any message .Such a pre-signature can be adapted into a valid full signature on  if and only if the adaptor knows a witness for  .Moreover, if such a valid signature is produced, it must be possible to extract the witness for  given the pre-signature and the adapted signature.Next, we formally define the two-party adaptor signature scheme with aggregatable public keys.
Adapt(apk, σ, ): is a DPT algorithm with input an aggregated public key apk, pre-signature σ and witness , outputs a signature .
In addition to the standard signature correctness, an adaptor signature scheme has to satisfy pre-signature correctness.Informally, it says that an honestly generated pre-signature w.r.t. a statement  ∈   is valid and can be adapted into a valid signature from which a witness for  can be extracted.

Merged Conditions:
Upon receiving (create-merged-cond, sid, ( 1 ,  2 )) from some party  We review the security properties of a two-party adaptor signature scheme with aggregatable public keys: Unforgeability resembles two-party existential unforgeability under chosen message attacks (2-EUF-CMA) but additionally requires that producing a forgery  for some message  is hard even given a pre-signature on  w.r.t. a random statement  ∈   .Allowing the adversary to learn a pre-signature on the forgery message  is crucial as for our applications unforgeability needs to hold even in case the adversary learns a pre-signature for  without knowing a witness for  .
Pre-signature adaptability requires that any valid pre-signature w.r.t. (possibly produced by a malicious signer) can be adapted into a valid signature using the witness  with ( , ) ∈ .
Finally, witness extractability guarantees that a valid signature/presignature pair (, σ) for a message/statement pair (,  ) can be used to extract the corresponding witness  of  .
We formally define these properties in the full version [29].Combining the three properties described above, we can define a secure adaptor signature scheme as follows.
Definition 3 (Secure Two-Party Adaptor Signature Scheme).A two-party adaptor signature scheme with aggregatable public keys Ξ ,Σ 2 is secure if it is 2-aEUF-CMA secure, two-party pre-signature adaptable and two-party witness extractable.
Finally, we review the Universal Composability (UC) framework, which we use in our framework LedgerLocks.We briefly overview the notion of secure realization in UC framework [11].Intuitively, a protocol realizes an ideal functionality if any distinguisher, i.e., the environment, cannot distinguish between a real run of the protocol and a simulated interaction with the ideal functionality.
Let  be a protocol.The output of an environment E interacting with protocol  and an adversary A, on input the security parameter 1  and auxiliary input , is denoted as EXEC ,A,E (1  , ).Let  F be the ideal protocol for an ideal functionality F , i.e.,  F is a trivial protocol in which the parties simply forward their inputs to the  ideal functionality F .The output of an environment E interacting with protocol  F and an adversary S (also called the simulator), on input the security parameter 1  and auxiliary input , is denoted as EXEC  F ,S,E (1  , ).
The main security notion of the UC framework informally says that if a protocol  UC-realizes an ideal functionality F , then any attack that can be carried out against the real-world protocol  can also be carried out against the ideal protocol  F .Definition 4 (UC Security).We say a protocol  UC-realizes an ideal functionality F , if for every adversary A there exists an adversary S such that (where ≈  denotes computational indistinguishability).

GLOBAL CONDITIONS
In existing blockchain protocols, adaptor signatures and their associated conditions are analyzed within monolithic protocol descriptions.Here, we advocate for handling conditions in a modular fashion instead, using a standalone global functionality G Cond .Global conditions functionality.We illustrate the (global) ideal functionality G Cond for conditions in Figure 7. G Cond is parameterized by a hard relation  and merging function  merge .G Cond provides three interfaces: The individual conditions interface acts as a bulletin board for conditions created outside the ideal functionality, and just stores the input condition/opening (i.e., statement/witness) pair in the list L. The merged conditions interface models the creation of a condition as the composition of two other conditions, where the concrete composition operations are given by  merge .This function is split into an operation + on witnesses and an operation • on statements, which need to satisfy that ( The open condition interface allows checking if a condition/opening pair is valid (i.e., is in L).Global conditions protocol.We describe the global conditions protocol Π Cond in Figure 8 for DLOG.The protocol is parameterized with a group description (G, , ) and the discrete logarithm (DLOG) relation  DLOG over it, i.e., (, ) ∈  DLOG ⇐⇒  =   .We

Ideal Functionality F 𝑅,𝑓 adapt AdaptSig
The functionality is parameterized by a hard relation  and an adaptation function  adapt .It maintains the list K that stores all generated keys; the list Q that stores tuples (, , ,  ) representing message, signature, key and a verification flag, and the list P that stores tuples (, σ, , ,  , ,  ) representing message, pre-signature, signature, key, condition, witness, and pre-verification flag.All lists are indexed by a session identifier and are initially set to ∅. Key Generation: Upon receiving (keygen, sid) from  0 and  1 , verify that sid = ( 0 ,  1 , sid ′ ) for some sid ′ .If not, ignore the request.Else, send (keygen, sid) to S. Upon receiving (verification-key, sid, ) from S, add  into K [sid] and send (verification-key, sid, ) to  0 and  1 .Adaptation: Upon receiving (adapt, sid, σ, , ) from some party  , check if there is an entry ℓ := (, σ, ⊥, ,  , ⊥,  assume that the group G is a DLOG-hard group here.The function  merge defines the witness operation (+) as addition and the statment operation (•) as the group operation.
In the case of individual conditions, the protocol checks if the input condition/opening pair (i.e., statement/witness pair for  DLOG ) is valid, and in such case, returns it.In the case of merged conditions, the protocol multiplies the inputted condition to form the merged condition, which gets returned by this process.Lastly, for opening conditions, the protocol validates the membership of input condition/opening (i.e., statement/witness) pair in the relation  DLOG , and returns the output bit .Security.The security of our construction is established with the following theorem.We provide a proof in the full version [29].
Theorem 1.Let G be a DLOG-hard group, then the protocol Π  DLOG Cond UC-realizes the ideal functionality G , merge Cond , for  =  DLOG and  merge as defined in Figure 8.
Extensions.Our model can be extended to account for further protocols to create and verify conditions.As an example, in the full version [29] we show an extension to account for additional combinations of conditions, e.g., 1-out-of-n.Note that the existing interfaces of G Cond would stay unaffected by such extensions and, hence, proofs conducted with respect to the current version of G Cond remain valid.Moreover, it might be interesting to analyze constructions for other hard relations such as the RSA assumption (e.g., used in Guillou-Quisquater-based adaptor signature [16]) or the  SIS relation (as used in Dilithium-based adaptor signature [18]).

UC ADAPTOR SIGNATURES
We first define an ideal functionality for adaptor signatures, which accounts for multiple keys per session and models two-party key generation (with public key aggregation) and signing.Then, we show that any two-party adaptor signature scheme with aggregatable public keys Ξ ,Σ 2 securely realizes our ideal functionality.Two-party adaptor signature functionality.Our functionality F AdaptSig (c.f. Figure 9) extends the digital signature functionality in [21] to adaptor signatures by considering a hard relation  and a deterministic adaptation function  adapt .Furthermore, it accounts for multiple keys per session and models 2-party key generation (with public key aggregation) and the 2-party signing protocol.
The functionality captures the expected correctness and security properties of a two-party adaptor signature as described in §4.More precisely, it captures completeness and consistency, along with (two-party) unforgeability and witness extractability.Pre-signature correctness and adaptability are captured with the help of the function  adapt and global conditions functionality G Cond .
The parametrization with  adapt is required to stay fully modular with respect to G Cond .By using G Cond in a modular fashion, we do not make any assumption about the creation of conditions, and in particular about which protocol parties know the witness for a condition.However, for parties knowing the witness , the presignature σ and the corresponding adapted signature  =  adapt ( σ, ) are distinctly connected.For showing that a protocol Π AdaptSig UC-realizes F AdaptSig without assuming any knowledge about which party knows , we need to ensure that signatures created via F AdaptSig 's adaptation interface cannot be distinguished from those created through the adaptation algorithm (even for parties knowing ).If we would let the simulator choose  at this point (as one would usually do in such cases), the simulator could not be guaranteed to know , nor to complete the signature adequately (without leaking  or making an assumption on condition generation).Consequently, we need to let F AdaptSig compute the correct signature based on , to which end we must fix  adapt .Two-party adaptor signature protocol and security.We describe how to translate a two-party adaptor signature scheme with aggregatable public keys (from identification scheme) Ξ ,Σ 2 into a protocol Π AdaptSig in the full version [29].Note that the construction is parametric with respect to G Cond where G Cond needs to support the relation  of Ξ ,Σ 2 .The security is established with the following theorem, which we prove in the full version [29].
2 be a secure two-party adaptor signature scheme with aggregatable public keys (from identification scheme) that is composed of a hard relation  and a secure two-party signature scheme Σ 2 , then Π AdaptSig UC-realizes the ideal functionality F AdaptSig .
Modeling privacy of adaptor signatures in UC.We note that our adaptor signature functionality from Figure 9 does not model any privacy property.We discuss the reason for it here and refer to the full version [29] for game-based privacy notions.
Capturing a privacy property (e.g., that the freshly computed signatures and adapted ones are indistinguishable or that the signature does not reveal any information about the corresponding witness used) for two-party adaptor signatures is difficult because it inherently only holds against a third party not involved in (pre-)signature generation and only sees the final signature.However, in the UC security proof we need to consider that the parties actually involved in the two-party (pre-)signing are adversarial, hence, such a third-party privacy notion is not provable.
More technically, in order to model such a privacy notion we need the simulator S to produce a valid full signature  without having access to the corresponding witness .One potential way to achieve this is inside the adaptation interface of F AdaptSig to make a call to the simulator S, and let S return a fresh full signature  ′ that is independent of the witness .Then, we can argue that  ′ is indistinguishable from a full signature , which is obtained by adapting a pre-signature σ with the witness .However, since we are in the two-party adaptor signatures setting, it means that during the simulation we have to assume that one of the two parties involved in (pre-)signature generation is corrupted.Though, if one of the (pre-)signers is adversarial, then it is trivial for the adversary to distinguish different protocol runs, and hence, different signatures, since it is itself involved in the protocol execution.

LOCK-ENABLING LEDGER
We model a realistic ledger supporting AS-locked transactions as an ideal functionality G LedgerLocks .Figure 10 shows how G LedgerLocks is constructed from the base ledger G Ledger defined in [8].
Lock-enabling ledger functionality.We formally describe functionality G LedgerLocks in Figure 11.G LedgerLocks builds upon G Ledger by adding interfaces, introducing an additional state, and refining the transaction validation check (by instantiating the predicate isValidTx).G LedgerLocks keeps three lists to model account management (L AccId ), authorization (L Auths ) and locking of transactions (L TxsCond ).The new validity predicate CheckCond operates on transactions of the form (A, tx ′ ) where A denotes the set of accounts controlling the transaction tx ′ .For checking the validity of a transaction, it checks L Auths for authorization of all accounts in A and invokes CheckBase for further validity checks.In addition to the interfaces for submitting and reading transactions provided by G Ledger , G LedgerLocks provides five interfaces: The account generation interface allows multiple parties to jointly generate an account (added to L AccId ).Although the ideal functionality models multiparty account generation, we note that in our protocol in Figure 12, we only consider two-party account generation as this is sufficient for our envisioned applications.Moreover, a transaction can have several accounts associated to it, contributing to the generality of the ideal functionality definition.In particular, this allows for modeling UTXO-style cryptocurrencies, where a transaction refers to multiple inputs, which may be controlled by different accounts.
The transaction locking interface allows the parties owning an account to jointly create an authorization for a transaction, which is locked under a specified condition and can only be released using the opening information for this condition.This authorization is recorded in L TxsCond .The transaction release interface allows a party controlling the respective account and knowing the opening information of the condition to submit a locked transaction to the ledger, moving the transaction from L TxsCond to L Auths .The witness signaling interface allows the account parties to extract the condition witness from the published AS-locked transaction.
One subtlety in our model here is that witness signaling is only enabled when the previously released transaction is added to the ledger.Only then we can guarantee that any party (involved in its creation) would have seen both the AS-locked transaction and the released transaction.We model this by checking whether the
Figure 11: Ideal functionality G LedgerLocks .Here, pt  is 's pointer into the state, as defined for G Ledger [8].Moreover, inState(tx, state) := ∃ ∈ state, tx ∈ Blockify −1 (), where Blockify is a predicate to parse transactions into a block [8].released transaction is in the ledger's view of the party invoking the witness signaling interface, which can be accessed by the ledger state variable, as defined in G Ledger .While an honest user is only guaranteed to learn the witness upon inclusion of the transaction in the ledger, a malicious user may learn the witness already upon the transaction's submission to the ledger.As motivated in §2, this situation may occur if the attacker controls both the user participating in the creation of the AS-locked transaction and a miner.We reflect this subtlety in the release interface: If any of the transaction's account owners is corrupted, the witness is immediately sent to the adversary.As shown in §2, modeling this behavior is crucial for an accurate security analysis of blockchain protocols.
Lock-enabling ledger protocol.Our lock-enabling ledger protocol Π LedgerLocks is defined in the (F AdaptSig , G Ledger )-hybrid model and given in Figure 12.During account generation, parties obtain verification keys by making calls to the key generation interface of F AdaptSig .Analogously, authorization of transactions and locking of transactions happen with a call to the signing interface of F AdaptSig , where in the latter case, only a pre-signature σ that is conditioned on  is computed, whereas in the former a full signature  over the transaction is computed.Releasing of transactions happens by calling the adaptation interface of F AdaptSig with the witness (i.e., opening)  of the corresponding condition (i.e., statement)  used during the locking procedure.Lastly, witness signaling calls the extraction interface of F AdaptSig , which returns witness .
Finally, the validation predicate CheckAdapt verifies the signatures attached to the transactions.Note that the instantation of G Ledger used for Π LedgerLocks differs from the one that G LedgerLocks extends.More specifically, G Ledger used in Π LedgerLocks operates on transactions of the form tx * = (tx, ì ) that (in addition to the account identities of tx) hold the signatures ì Sig that CheckAdapt verifies via F AdaptSig .To hide this difference in format from a distinguishing environment, Π LedgerLocks wraps the corresponding interfaces of G Ledger for reading and submitting.Security.The security of conditional ledger is captured with the theorem below, which we prove in the full version [29].

LEDGERLOCKS APPLICATIONS
We demonstrate how to use LedgerLocks for modeling AS-based blockchain protocols.To this end, we first give a concrete example of an oracle-enabled atomic swap protocol that we express with the help of LedgerLocks.Finally, we provide a general recipe for working with LedgerLocks to model and analyze blockchain protocols that are based on adaptor signatures.

Case Study: Oracle-enabled Atomic Swaps
In the following, we consider the oracle-enabled atomic swap protocol, as described in §3.We provide the full protocol description in the full version [29].Here, for illustrative purposes, Figures 14  and 15 show different phases of the protocol.
The key feature of LedgerLocks is that for describing an AS-based blockchain protocol such as the atomic swap protocol considered here, we only need to rely on the functionality G Cond and instances of G LedgerLocks representing the blockchains involved in the protocol.In particular, we do not need to make use of (adaptor) signatures because their utility is abstracted by the corresponding interfaces of G LedgerLocks .For the given protocol, we use two instances of G LedgerLocks (called A and B here in the following) representing the two blockchains between which assets shall be swapped.Thanks to the generality of LedgerLocks, G LedgerLocks can easily be instantiated to support additional blockchain features such as scripting capabilities by instantiating the CheckBase predicate.For modeling the atomic swap protocol from §3, the underlying blockchains need to support timelocks.A timelock of a transaction ensures that this particular transaction can only be included starting from a certain blockheight.The blockheight denotes the number of blocks in the blockchain and can be accessed through the variable state of G LedgerLocks (which is inherited from G Ledger ).To obtain A and B with timelock support from G LedgerLocks , we fix their transaction format to pairs of the form (tx ′′ , tl), where tl denotes the timelock and by defining their CheckBase predicate as follows to support the timelock check: For generality, we again only specify checks for the desired feature and leave further validity checks to another ledger-specific predicate CheckBase C .
Figure 14 shows the setup phase of the atomic swap protocol.Both parties initially know the oracle condition  O , which is assumed to be registered in G Cond .In the first step, Alice constructs the locking condition  * by merging a newly created individual condition  and the oracle condition  O using G Cond .Next, Alice and Bob create joint accounts on the two ledgers A and B. Based on these accounts, both of them prepare three kinds of transactions: (1) a deposit transaction dtx (which spends funds of the corresponding party to the joint account), (2) a claim transaction ctx (which transfers the deposit from the joint account to the other user), and (3) a refund transaction rtx (which transfers the deposit back to the original owner).Importantly, ctx  and rtx  (along with ctx  and rtx  , respectively) are conflicting transactions, which can only be spent with authorization from the joint account.Conflicting means that only one out of them can be published in the ledger.To establish an order on the transaction execution, the refund transactions are equipped with a timelock ℎ.These timelocks will ensure that Alice will always have enough time to safely claim ctx  and that Bob will always have enough time to claim ctx  once ctx  has been claimed.The corresponding property is checked by the predicate safe, which is formally defined in Figure 13.The safe predicate accounts for the fact that A and B are independent blockchains that can provide different inclusion guarantees and proceed at different block creation rates.Inherited from G Ledger , the relevant behavior of a G LedgerLocks instance C is determined by the parameters windowsize C (the maximum amount of blocks that an honest user can be lacking behind the current state of the blockchain), minTime C window (the minimal amount of time for including windowsize C blocks) and maxTime C window (the maximal amount The function ub C 1 →C 2 computes an upper bound on the number of blocks that can be added in ledger C 2 while  blocks are added to C 1 .Using this, safe can check that given the current blockheight   on ledger B there is still enough time include transactions dtx  on A (taking up to ub A→B (# A safe ) blocks) and to include transactions dtx  and ctx  on B (taking up to 2 • # B safe blocks) before reaching timelock ℎ  (first conjunct).The second conjunct ensures that given current blockheight   on ledger A, at the point that an honest Bob learns whether rtx  that they submitted after ℎ  has been included on B (latest after ℎ  + # B safe blocks), the blockheight on A (computed by   + ub B→A (ℎ  + # B safe −   )) is still at least # A safe before ℎ  so that ctx  can be safely included.
After checking the timelocks, the users authorize their refund transactions and lock their claim transactions on the condition  * .Once this is done, Alice submits dtx  to A, and once Bob sees it published on A they submit dtx  to B and finish the setup.Note that the setup should be completed in a timely fashion (|state| < |ℎ  | − # B safe ) so that there is still time for Alice to claim ctx  before Bob needs to initiate the refund.
Figure 15 shows the case when a malicious Alice does not submit ctx  in time.Here, Bob needs to submit rtx  at the earliest possible point (once ℎ  is reached).Thanks to B's transaction inclusion guarantees, Bob can enforce that by ℎ  + # B safe , either the refund was successful, or ctx  must have been published.In the latter case (thanks to the original validity check), there is still enough time (# A safe ) for Bob to submit ctx  to A before (at ℎ  ) rtx  can be submitted and, hence, Bob can complete the protocol as in an honest execution.
The example illustrates how delicate the correct modeling of the blockchain fairness guarantees is to reason about the security of blockchain-based protocols: If the timelocks are wrongly set up, Bob could lose their money, because a malicious Alice could claim ctx  and still prevent Bob from claiming ctx  by sneaking the refund rtx  in before ctx  .Similarly, in an attack as shown in §2, if ℎ  is not set properly, Bob could outrun Alice's ctx  transaction with rtx  and receive the assets on both chains.Setting up timeouts correctly and reasoning about their security become particularly hard when considering protocols across independent ledgers as shown in the example.Even for stating the checks to be done by the protocol participants (here given through the safe predicate), we need to resort to the safety and liveness guarantees provided by the underlying ledgers -an aspect disregarded in most prior work.

Template for using LedgerLocks
The oracle-enabled atomic swap case illustrates how to model ASbased blockchain protocols using LedgerLocks.We generalize this approach here and outline further steps towards using LedgerLocks for the verification of AS-based blockchain protocols. 1Up to windowsize blocks may be added to the ledger per round, so when user U makes an observation at blockheight ℎ, the ledger may be at height ℎ +windowsize−1.
After submission, G Ledger (and hence G LedgerLocks ) guarantees a valid transaction to appear in U's view within 4 • windowsize blocks.Modeling the protocol.For describing a protocol Π * (such as Π AtomicSwap ) with the help of LedgerLocks, Π * can be defined in a G Cond ,G LedgerLocks -hybrid world, meaning that it may interact with G Cond and G LedgerLocks .Intuitively, all (adaptor-)signaturerelated operations of the protocols can be replaced with calls to the corresponding interfaces of G LedgerLocks .G Cond allows for a logical separation between the creation of conditions and their usage to restrict transaction publication on G LedgerLocks .
In cases where Π * involves several blockchains, the description of Π * uses multiple instances of G LedgerLocks (such as A and B in the previous example).The characteristics of these blockchain instances can be further refined by specifying the CheckBase predicate (and correspondingly the transaction format) to describe the logic of transaction execution.For the atomic swap example, we showed how to extend the blockchain logic with timelocks in this way.However, the formalism is expressive enough to encode more involved smart contract logic.
If Π * requires the creation of conditions with additional properties (that go beyond simple conditions, merged conditions, or 1-out-of-n conditions), then G Cond 's condition creation interface can be extended to G * Cond to support the new condition types.In this case, for some relation R (known to realize G Cond ) one needs to give a protocol Π R and prove that it realizes the newly added interfaces in G * Cond .Alternatively, one can immediately give a protocol Π R * for some new relation R * (that is known to be supported by an adaptor signature scheme) and show it to realize all of G * Cond .Defining protocol security.LedgerLocks can also serve as a starting point for defining the security of AS-based protocols.An ideal functionality F * capturing the desired security of Π * can be described by extending G LedgerLocks , e.g., by instantiating the CheckBase predicate that determines which transactions will be considered valid in a faithful protocol execution.Similar to how we extended G Ledger to G LedgerLocks , F * may make use of additional state to capture the desired correctness and security properties of the protocol.For cross-chain blockchain protocols, F * may hold several internal copies of extended G LedgerLocks functionalities.
Proving UC-realization.Finally, one needs to prove Π * to UCrealize F * .This proof should not involve cryptographic reductions but focus on how the interactions of Π * with G LedgerLocks and G * Cond are translated into interactions with F * .As F * uses G LedgerLocks as a component, the proof's essence should lie in showing that the way that transactions are created, locked and released within Π * enforces the transaction inclusion logic encoded in F * .
Limitations.LedgerLocks, in its current form, is not suitable for modeling blockchain protocols operating on ledgers that do not support transaction authorization through adaptor signature schemes.However, most cryptocurrencies base their transaction authorization on signature schemes shown to support adaptor signatures.One notable exception is Zerocash [9].Further, since G Ledger is currently only shown to be realized by the Bitcoin (PoW) backbone protocol [8] and the Ouroboros Genesis (PoS) protocol [7], LedgerLocks (relying on the security of G Ledger ) only provides full end-to-end guarantees for ledgers using one of these protocols.

CONCLUSION
We provide foundations for the security of adaptor signatures and the applications using them as building blocks for blockchain protocols.We give novel ideal functionalities in the UC framework to model standalone cryptographic conditions, as well as adaptor signatures and lock-enabling ledgers operating upon such conditions.We define concrete protocols and show them to securely realize the different functionalities and finally, we showcase the utility of our model by using it to describe an atomic swap protocol in a clear and modular fashion.In the future, the same blueprint can be used to define other blockchain protocols based on AS-locked transactions.

CCS ' 23 ,Figure 1 :
Figure 1: Overview of the LedgerLocks framework.Cryptographic protocols for creating AS-locked transactions in the state of the art (in green) are modeled by an ideal functionality G LedgerLocks .

Figure 5 :
Figure 5: Overview of the infrastructure of LedgerLocks.Darkgray components indicate novel functionalities and protocols introduced in this work.The ≼ relation denotes that a protocol Π (left) realizes a functionality F /G (right) in the UC framework.

𝑖)
∈ (1,10) and sends the corresponding statements # »  mask = (  mask  )  ∈ (1,10) to Bob. Bob himself prepares one witness  win and ten witnesses ( blank  )  ∈ (1,10) .For the guess , Bob prepares # »  guess = ( guess  )  ∈ (1,10) such that for  ≠ ,  guess  = ( mask  )  blank  and  guess  =   win .At this point, Bob knows the witness for  guess  , while he cannot know the witness for any statement  guess  with  ≠ , since for this, Bob would require Alice's secret masking values ( mask  )  ∈ (1,10) .Bob proves in zeroknowledge to Alice that # »  guess is well-formed.Now, Alice chooses a number  and prepares a payment to Bob based on  guess  .Alice at this point, cannot know which condition Bob can open, only that Bob can open exactly one out of the ten provided conditions.If Alice and Bob chose the same number ( = ), Bob can complete the payment, otherwise, the money stays with Alice.

Figure 6 :
Figure 6: Detailed overview of the different components of the LedgerLocks infrastructure.White arrow-shaped boxes indicate parametrization; black ones instantiation.