MP-HTLC: Enabling blockchain interoperability through a multiparty implementation of the hash time-lock contract

Summary The idea of hash time-lock contracts (HTLCs) has been around from 2013. Nowadays these contracts power the majority of atomic swaps making decentralized exchange of tokens possible. On the other hand, HTLCs also have some flaws. For example they can only be instantiated between two parties. This is highly inefficient when many participants want to exchange tokens between the same pair of blockchains at the same time, becausethenumberoftransactionsincreaseslinearlyinthenumberofparticipants.To solve this problem, in this article, we present MP-HTLC. MP-HTLC lets multiple users exchange tokens on different blockchains in a single instantiation of the protocol with-outanyleaderelection.WeprovethatincaseofaUTXO-basedblockchainthenumber oftransactionsremainsconstantregardlessthenumberofparticipants.Weareableto maintain the security assumptions of HTLCs using multiparty computation in the creation of the secret preimage and threshold signatures to manage transaction signing. We also present an implementation for each of the aspects of the protocol.

Analogous arguments can be done for state and payment channels. For example, in a payment channel like Lightning Network 3 the users create off-chain ledgers. Generally this ledgers are called channels. However, when there must be a transaction between two channels or a transaction between the parent chain (Bitcoin in this case) and the channel (e.g., during the opening or closing of the channel) it is important to be able to verify the states of the channel.
This last example introduces another problem of current decentralized methods of token or coin exchange. In fact, nowadays the most used method is the hash time-lock contract (HTLC), 4 but this method has two strong downsides. The first one is that it can be instantiated only between two parties. Consequently multiple participants need to instantiate a contract for each couple of participants: when there is a multitude of participants that wants to exchange tokens between the same couple of blockchain, the HTLC inner mechanics requires a new instance of the contract for each couple of participants. This has large extra costs since performing a single instance of the protocol among many participants is less expensive than creating many instances of the same protocol, both from a communication point of view and from a fee point of view for sending the multiple transactions. We prove this in Section 7.1.
In addition to inefficiency issues, HTLCs suffer also of privacy issues. In fact if a new instance is created each time for each pair of participants, by keeping track of the multiple instances is possible to keep track of which participants are involved: a passive observer of the two blockchains involved can be sure that participant A has interacted with participant B.
To solve these problems we present MP-HTLC. In MP-HTLC a group of participants can exchange tokens between the same couple of blockchains at once. That's accomplished using secure multiparty computation (MPC) 5 and Threshold Signatures (see e.g., Reference 6 for a threshold signature scheme applied in a blockchain environment). Using MP-HTLC, participants save on fees by participating all together in a single instance of the protocol and sharing the costs. They also gain privacy, as being part of an anonymity set (i.e., the group of participants in one blockchain) they are protected against an external blockchain observers who cannot link a participant in one group with a participant in the second group. To achieve this result, we use a previous work called DMix. 7 In DMix the authors create a protocol acting as a de facto decentralized mixer in a UTXO blockchain such as the Bitcoin one. The DMix protocol is split into three phases: in the first phase the participants create an address thanks to a distributed key creation protocol; in the second phase they send their funds to the address and in the third one they redeem their funds sending them to newly created addresses. In the third phase participants use n-of-n threshold signatures. We use the ideas of the DMix protocol to obtain privacy in the MP-HTLC cross-chain communication protocol. Furthermore, by using threshold signatures, participants create a single signature regardless of how many there are. This is an additional layer of protection against an outside observer who cannot know for sure which transactions on the blockchain stand alone or are part of a token exchange with MP-HTLC and it is also a cost saving improvement in case of multiple participants.
We also present two use cases. the first use case is a Bitcoin-Ethereum transfer: this way we describe the interoperability concept applied to the token exchange. For this case we propose an implementation. The second use case is a Ethereum-Polygon exchange: this way we describe the interoperability concept applied to the scalability problem. Furthermore, to prove the feasibility of MP-HTLC we present also the implementation of the case between Bitcoin and Ethereum.
In summary, our research contributions are: • we present MP-HTLC, an interoperability system between two blockchains capable of managing multiple participants in a single instance • we present use cases showing that MP-HTLC can be used both to achieve scalability and to achieve simple token exchange • we propose a decentralized and secure alternative to EVM-compatible bridges such as the one between the Binance Smart chain and Ethereum and the one between Polygon and Ethereum • we propose an implementation in the case of Bitcoin-Ethereum † • we present a cost and attack analysis showing that MP-HTLC is better than legacy HTLC in case there are more participants simultaneously available to an exchange in the same blockchain pair The rest of the article is organized as follows. In Section 2 we describe the related works. In Section 3 we describe the preliminaries necessary to understand the functioning of MP-HTLC and in Section 4 we describe the general functioning. In Sections 5 and 6 we present the use cases. In Section 7 we present the cost and attack analysis and in Section 8 we conclude.

RELATED WORKS
There are three major strands of research in the blockchain ecosystem that relate to interoperability. For details see the paper of Zamyatin, 8 which describes the topological and technical level of the different methodologies to achieve interoperability between two different blockchains, and the paper of Belchior,9 which describes all the solutions currently used to date.
The first line of research is token exchange. This type of interoperability dates back to 2016 with the report created by Vitalik Buterin. 10 This report explains the various differences between different types of blockchain and related implementations of "bridges" between them. The second strand of research has to do with the problem of blockchain scalability. It is a consequence of sharding, that is, the division of validators/miners into different committees, each specialized in processing a subset of all transactions. The third and last strand of research related to interoperability on blockchain is related to layer-two (L2) technologies.
In the following, we delve into each of these lines of research, give indications of where interoperability is needed and the proposed solutions.

Token exchange
Cross-chain token exchange, also called cross-chain asset transfers, rely on an atomic three-phases procedure: asset locking on a source blockchain, blockchain-transfer commitment, and finally a creation of a representation of the asset on a target blockchain. 11,12 This last step can be also called release. As in Zamyatin, 8 we call this three-steps procedure cross-chain communication (CCC). The methods to obtain CCC belong to four categories: sidechains, relays, notary schemes and atomic swaps via HTLC.
Sidechains were introduced by Back et al. 13 to enable innovation while maintaining security in the Bitcoin blockchain. The authors consider another blockchain (called sidechain) as an extension of the main blockchain (called mainchain). A sidechain allows the offloading of transactions from the mainchain: it processes it, and communicate the outcome of such process back to the mainchain effectively performing a CCC. An example of CCC is the two-way peg. 14 A centralized two-way peg is a single entity that locks and then create of a representation of the asset on a target blockchain. Being centralized it requires trust, but provides efficiency. To solve the trust problem, a majority of multiple entities can lock and release: in this case we talk about federated two-way pegs. 15 Relays are generally on-chain clients that can verify transactions on the blockchain using only block headers, without having its entire state.
Examples of relay are the simplified payment verification (SPV) used by light-clients and proposed in the original Bitcoin whitepaper, 16

Scalability
Blockchains are a particular design of distributed systems, so they stand in the tradition of distributed protocols of replicated state machines. As in any distributed system, nodes must reach an agreement, so consensus is one of the most important problems in the blockchain literature.
One of the problems with current consensus algorithms is that they don't scale. In fact, there are two key metrics to measure scaling: transaction throughput (i.e., the maximum rate at which the blockchain can process transactions) and latency (i.e., the time to confirm that a transaction has been included in the blockchain). Generally, both transaction throughput and latency remain constant even as the number of miners and validators (i.e., those who are able to process new information and write it on the blockchain) increases.
One solution is to divide the miners and validators into smaller subsets so that each of these subset processes a distinct subset of the information or set of transactions (called "shards"). This method is called sharding. Its first academic proposal has been Plasma 2 and it is currently on the roadmap for Ethereum 2.0 ‡ . The term "sharding" refers to approaches targeting the blockchain's core design, also known as on-chain solutions, rather than techniques that delegate to parallel blockchain instances such as sidechains, as in Section 2.1. We model the process of sharding as in Reference 8.
Let n be the number of participating nodes on a blockchain and for simplicity we assume they have the same computational power. We also assume that a fraction f of those nodes is controlled by a Byzantine adversary (of course f could be equal to 0 if all nodes are honest). We index the ith transaction in block j as x j i and assume there is a validity boolean-function V which outputs 1 if x j i is valid and 0 otherwise. For a fixed block j, a sharding protocol Π running between n nodes outputs a set X which contains k separate shards (subset of transactions): and X = ∪X w . Each shard must follow the subsequent conditions: • Agreement. given a security parameter , honest nodes agree on X with a probability of at least 1 − 2 (− ) • Validity. The agreed shard X w satisfies the validity function V such that ∀w ∈ 1 … k, ∀x j w i ∈ X w , V(x j w i ) = 1.
• Scalability. The value of k grows almost linearly with the size of the network.
In practice, a sharding algorithm automatically parallelizes the available computation power, by dividing the nodes into several smaller committees, each of them processing a disjoint set of transactions. The sharding protocol Π consists of five critical components: 1. Committee formation. Each node is assigned to a committee, after it has been identified for example, via a public key, an IP address or a proof-of-work (PoW) solution. The identification is needed in permissionless blockchain to prevent the Sybil identity 18 2. Overlay setup for committees. After the committee's formation, each node communicates to discover the identities of other nodes in its committee, generally via a gossip protocol. 19 3. Intra-committee consensus. Each node in a committee runs a consensus protocol to agree on a single set of transactions 4. Cross-shard transaction processing. the inputs and outputs of a transaction might be in different shards. These transactions are called cross-shard (or inter-shard) transactions 5. Epoch reconfiguration. the shards need to be reconfigured after a predetermined time ("epoch") to guarantee the security Interoperability is needed for Cross-shard transaction processing, which generally represents the vast majority of transactions in a sharding consensus protocol. In both the Unspent Transaction-Output (UTXO) model and the account transaction model it is expected that up to 90% of transactions are cross-sharded, as seen in Reference 20 (UTXO model) and in Reference 21 (account-based model).
Atomic commitments are used to perform cross-chain transactions. 8 Protocols that use this method are RSCoin, 22 Chainspace, 23 OmniLedger, 20 RapidChain. 24 These atomic commitments act as garbage-collectors: this can be seen well in UTXO models where a transaction will never be used again once spent. Another method is the distributed state snapshotting mechanism 25 to record the blockchain's recent status. This mechanism is used by SideCoin 26 and Roller-Chain. 27 Other projects such as Elastico, 28 do not provide a clear or separated process to deal with the cross shard transactions.

Layer 2
Layer-two protocols, built on top of (layer-one) blockchains, don't disseminate every transaction to the whole network and exchange authenticated transactions off-chain. They utilize the blockchain only as a recourse for disputes. More formally, using Definition 1 in Reference 8 a "layer-two protocol allows transactions between users through the exchange of authenticated messages via a medium which is outside of, but tethered to, a layer-one blockchain. Authenticated assertions are submitted to the parent-chain only in cases of a dispute, with the parent-chain deciding the outcome of the dispute. Security and non-custodial properties of a layer-two protocol rely on the consensus algorithm of the parent chain." In this case interoperability is required to pass from the blockchain to the off-chain method and vice versa. Of these three mechanisms, the only one that needs interoperability is the channel construction and closing, so in the following we explain how channels work An off-chain channel between n coequal parties establishes a private peer-to-peer medium. This medium allows the involved parties to consent Therefore the creation of a payment channel creates at a practical level a new blockchain. This chain is to all intents and purposes off-chain, but having nodes keeping track of funds, it is a ledger. For this reason, every step from the main chain to the secondary chain requires interoperability between the two ledgers. It is important that the methods for exchanging tokens between layer one and layer two are efficient, secure, and provide privacy guarantees, ideally by making the channel opening or closing transaction indistinguishable from any other transaction on layer one. Current methods do not satisfy these premises: the normal way to open a channel is via a multi-signature and it has been shown that this method cannot be considered private. 29

Blockchain, participants, and network model
We assume the blockchains constitute an asynchronous system lacking of a global clock across chains. For this reason we rely heavily on the result of Asokan 30 on the impossibility of fair exchange without a third parties: its consequence is that there can't be a cross chain communication protocol tolerant against misbehaving nodes with out a trusted third party (see corollary 1 in Reference 8). Our goal is to provide a multi-party locking mechanism to remove the asynchronicity assumption. Note that we rely on chain-dependent clocks on the chain. In particular, time is based on block generation. This hinders a possibility of synchronization across chains. We analyze possible attacks based on this in Section 7.2.
We model blockchain transactions as a tuple tx = (fromAddr, toAddr, amt, {conds}), where fromAddr is the sending address, toAddr is the receiving address, amt is amount of token sent and conds are the conditions needed to redeem tx. In UTXO-based blockchain, conds is never empty because the redeemer has to present at least a signature as a form of zero knowledge proof of knowledge of private key. On the other hand, we assume conds = ∅ if tx is in an account-based blockchain. For a difference between the two models see Section 3.2.
The MP-HTLC protocol has multiple participants. We call P 1 , … , P N the participants that have funds on BC 1 and Q 1 , … , Q N the participants that have funds on BC 2 . We model the set {P 1 , … , P N } as a set of participants containing at least one rational participant, P r and the set {Q 1 , … , Q N } as a set of participants containing at least one rational participant, Q r .
We assume P 1 , … , P N are "on the same side", meaning that no P i is actively dishonest towards {P 1 , … , P N } ⧵ P i , while allowing for passive dishonesty, that is, willing to read messages which are not sent to it (the honest-but-curious model) and the ability for P i to go offline and not replying to messages sent by {P 1 , … , P N } ⧵ P i towards P i . The same goes for Q 1 , … , Q N .
Note that this assumption means that there can be no meaningful collusion between P 1 , … , P N and Q 1 , … , Q N : if P i colludes with one of Q 1 , … , Q N , then if P i acts on the result of the collusion then P i would be actively dishonest towards P 1 , … , P N .
On the other hand, we allow P 1 , … , P N to be actively dishonest towards Q 1 , … , Q N , and viceversa, as long as this does not result in a situation which is equivalent to collusion. In particular, we do not allow for example, P i to bribe or otherwise manipulate the behavior of Q j since then Q j would act actively dishonest manner towards Q 1 , … , Q N . Note that this last requirement intuitively "normal" since it is the natural extension of the HTLC between two parties A and B: in that case it is assumed that A cannot control B, since if that were not the case, A could steal from B without having to start a HTLC.
Finally, since we present a HTLC-based protocol, we require that the domain of the hash function has the same size in both chains. Possible attacks that can be performed if this assumption is not met are presented in Reference 31. In practice all examples will use the SHA256 hashing algorithm, so the domain of the hash function will obviously be the same.

Account based versus UTXO based
There are two major types of models in the blockchain ecosystem. The first model is called the Account (or Balance) model. In this model, the states related to an account are saved inside the account. A transaction in the account-based model is an instruction for how to transition two or more accounts to the next state. The actual transition is executed by the nodes. The final state is not specified in the transaction The other methodology, called UTXO model, does not contain the logic and states of an account within the account itself, but is constantly recomputed by scanning the entire blockchain. In this type of model, a user sends transactions that contain the results, not the necessary calculations. These are defined as the output of the new transaction, and are expendable by the recipient if they can meet the conditions. In this model the logic is aimed at verification.

An example of a blockchain with an account-based model is Ethereum while an example of a blockchain with an UTXO-based model is Bitcoin.
This is one of the reasons why in Section 5 we choose to make the case study on the exchange between these two blockchain projects.
Finally, since blockchains in an account model have the ability to save states, it is possible to integrate all the logic of the protocol into a single smart contract. As for a UTXO model the logic must be expressed every time in every translation.
This difference is important for our protocol. In the case of a blockchain with an account model we can make a single smart contract containing all the necessary logic. Instead if we are dealing with a UTXO model we will have to make more transactions with similar logic § .

Hash-time lock contracts
It is a well-known result that a fair exchange (as defined in Reference 30) in an asynchronous system is impossible without a third party. [32][33][34][35] Zamyatin et al. 8 reduce the cross-chain communication (CCC) problem to the fair exchange one, proving that there can't be an asynchronous protocol tolerant against misbehaving nodes without a trusted third party (TTP). So for this reason, to have a secure CCC, we have to either introduce synchrony or a TTP. We want MP-HTLC to be a P2P protocol, so we decided to introduce synchrony. We do that by using a locking mechanism called Hash-Time Lock Contract (HTLC). 4 In a HTLC a transaction from Alice to Bob has two redeeming paths. In the first one, the transaction is redeemable by Bob providing the preimage of a hash before a certain timeout; in the second path, Alice can redeem the transaction after the timeout, that is, if Bob did not redeem it before. Thus HTLCs work thanks to the preimage resistance property of hash functions.
Atomic swaps (a particular case of CCC) leverage HTLCs in the following way: 1. Suppose Alice has 0.1 BTC and she wants to exchange it with someone for 1 ETH, and suppose Bob has the inverse need 2. If Alice and Bob agree on the exchange, Alice produces a secret r uniformly at random and creates a hash-time locked transaction, such as the one described before, with hash h = H(r) (where H is a hash function) and timeout Δ with Bob's address on the Bitcoin blockchain as the recipient 3. Bob uses h to create a hash-time locked transaction directed to Alice's address on the Ethereum blockchain with timeout Δ ′ < Δ 4. Alice redeems the transaction on Ethereum before Δ; by doing that she provides r, which is visible to anybody on the Ethereum blockchain 5. Bob uses r to redeem the transaction on Bitcoin before Δ If Alice misbehaves by not following through the protocol after Step 2, then Bob can redeem his own transaction after Δ ′ . The swap is atomic in the sense that either Alice and Bob get their new coins, or they get their old ones: there is no way one party can lose anything.

Threshold signatures
A threshold signature scheme (TSS) lets a group of participants compute a signature together, without learning information about the private key.
Generally in a (t, n)-TSS, n participants hold their distinct private keys (called key shares) and any set of t + 1 ≤ n distinct participants can produce a valid signature, while any subset of at most t participants can't.
MP-HTLC needs a (n, n)-TSS, so that all participants are needed to produce a signature. This is done to avoid possible collusion between the participants who can in this way steal money from the minority of people. Reasoning of this type are common in the literature, see for example, More formally a TSS has always two algorithms: • Thresh-DKGen, a distributed key generation (DKG) protocol. If the protocol is successful, each participant has its private share key sk i of the whole private key sk • Thresh-Sig, a distributed signing protocol. If the protocol is successful, it returns a valid signature of a message.
In MP-HTLC, we use threshold signatures to mask the number of participants behind a transaction. In fact, only one signature is produced in a TSS, whatever the number of participants. This is different from multisignatures which produce one signature per participant. For a more detailed description see Reference 37.
For the proof of concept (PoC) presented in this paper, we used the ZenGo ECDSA-TSS library ¶ . That's because both Bitcoin and Ethereum currently use the ECDSA signature scheme. In any case, both projects will change the signature scheme. Bitcoin is currently switching to a Schnorr signature scheme, 38 while Ethereum is switching to BLS. 39 43 This means that MP-HTLC can in principle be instantiated also between Monero and another blockchain using another synchrony assumption (e.g., signature-based contracts as explained in Reference 44 instead of HTLC as said in Section 3.3).

MPC
Similar to HTLC, MP-HTLC also has a secret creation phase. This secret cannot be created by a single participant, who would become a kind of leader in the protocol, decreasing its decentralization and security. For this reason the creation of the secret must be a joint computation performed by all parties involved. That means that we are in a distributed computing scenario and secure multi-party computation (MPC) is used to be sure that the joint computations are secure: the goal of MPC is for a group of participants to learn the correct output of some previously agreed function applied to their private inputs without revealing anything else. To practically create the secret, the participants will use MPC to sum their private inputs.
In MPC security is defined using the real-ideal paradigm. In the ideal world parties interact with a third party which is completely trusted, cannot be attacked and would never betray any of the parties. Of course we can't use the same model for the real world, because no entity can be absolutely trusted. In the real world the third part is replaced by a protocol. Intuitively, this protocol is considered secure if any consequences caused by an adversary in the protocol in the real world could also be achieved in the ideal world.
There are two different adversary models commonly used for MPC: semi-honest and malicious adversary. A semihonest adversary is one who corrupts parties but follows the protocol as specified. This is the case where parties can collude by pooling their views (i.e., private inputs) together.
This kind of adversary is considered passive, because they cannot act on the knowledge gained. Another name for semi-honest is honest but curious adversary.
The other kind of adversary is the malicious (also called active) one. This kind of adversary may cause corrupted parties to deviate arbitrarily from the prescribed protocol. A malicious adversary has all powers of a semi-honest one, but it can also act on the knowledge it gains manipulating the outputs of the protocol. For more details see for example, Reference 45.
To implement this part of the protocol, we used the framework proposed by Keller. 46 The framework proposes several methods to perform MPC protocols between two or more participants in different types of adversaries. Given the modularity of MP-HTLC, the choice of the specific MPC protocol does not affect the other routines. For this reason the proof of concept proposed in this paper uses the Tale protocol to do the sum.

P2SH bitcoin transactions
In Bitcoin supports very basic smart contracts which allow different types of scripts. Scripts are divided into standard and non-standard which contain the logic to redeem a transaction. By default non-standard scripts are not accepted by miners who do not include them in their blocks, even though they are valid. This is to avoid possible DDoS. 47 Currently the standard types are • Pay to public key hash (P2PKH) • Pay to script hash (P2SH) • Multisig

• Pubkey
• Null data For more details on current standard scripts see the page dedicated to bitcoin developers # .
Each transaction is divided into two parts. One part determines the conditions needed to redeem the transaction and it's called scriptPubKey.
The other part contains data to satisfy those conditions and it's called scriptSig.
We only use P2SH transactions in the course of the protocol. This transaction type allows users to embed non-standard scripts into a standard script creating an acceptable transaction. This allows a sender to fund any arbitrary transaction, no matter how complicated its script. The format of this type of transaction is as follows: 48 where [20-byte-hash-value] is the hash of the serialized nonstandard script.
This kind of transaction can be redeemed by a standard scriptSig: We use this construct in two phases of the protocol. We explain in the phase sections the particular script.

Partially signed bitcoin transactions
Sometimes multiple parties need to cooperate to produce a transaction. Examples include multisignature setups, transferring funds form or to cold or hardware wallets, and CoinJoin transactions. In these cases, one party A may need to exchange an unsigned or partially-signed transaction with another party B so that A and B together can send these funds to a third party C. Originally this process was wallet-implementation dependent, making it hard for people who use different wallet softwares to exchange these partially signed transactions. This problem has been solved with BIP174 49 and BIP370. 50 Those BIPs create an interchange format for Bitcoin transactions called Partially Signed Bitcoin Transaction (PSBT).
To give an example of how PSBT work, we describe the process in the case mentioned before, that is, where a party A and a party B need to send a payment to C using inputs from both A and B. The construction goes through the following steps || : 1. Without loss of generality, A proposes a particular transaction to be created by building a PSBT ptx that contains certain inputs and outputs; no additional metadata is needed. A sends ptx to B 2. B adds information about the UTXOs being spent by the transaction to ptx. In particular B adds its inputs 3. Signers A and B inspect the PSBT transaction ptx and its metadata to decide whether they agree with the transaction.
4. If they agree, they produce a partial signature for the inputs for which they have relevant keys. Without loss of generality A sends the current state of ptx to B.
5. B runs an extractor protocol to produce a valid Bitcoin transaction from ptx if all inputs are finalized.
In practice PSBTs let Bitcoin users aggregate inputs and outputs in a single transaction. This helps them reduce fees by requiring them to broadcast only one transaction to the chain instead of many. We take advantage of this fact during the Commit Phase in the Bitcoin transaction to make only one signature (see Section 5.2) PSBT are already working on both Bitcoin, Bitcoin Cash and its subsequent forks ** . A version of PSBT called Partially Created Zcash Transactions (PCZT) are currently in the process of being finalized † † .

DESIGN
The goal is to make a multiparty-swap protocol between two blockchains minimizing the number of transactions needed while ensuring the same level of security. We do that by generalizing the HTLC to multiple participants (multiparty-HTLC) with the same secret. In the following we will be blockchain agnostic. We call blockchain BC 1 the first blockchain and blockchain BC 2 the second blockchain. The N participants in blockchain BC 1 will be P 1 , … , P N and the N participants in blockchain BC 2 will be Q 1 , … , Q N . In the course of the explanation, P 1 , … , P N will also be called the initiators and Q 1 , … , Q N the finalizers. The protocol is easily extendable to the case where a P i serves both Q i and Q j or where a P i is served by Q i and Q j for some i, j, so that there is a different number of participants in the two blockchains, say N in BC 1 and N ′ in BC 2 . In fact, we can represent a participant as dual, instead of a single participant with multiple funds, so that we end up having the same number of participants in both blockchains.
The only assumption on both blockchains is that they are able to understand the same hash function and have a basic scripting language. An example blockchain is Bitcoin, but also Ethereum or Tezos are supported. On the other hand blockchains like Monero or Komodo cannot be used as they do not have a scripting language.
In the course of explaining the design in the protocol, we will refer to the two types of blockchain: account-based blockchains and UTXO-based blockchains. The protocol is divided into three phases: Precommit, Commit and Redeem. Table 1 gives an overview of the whole protocol and the different steps needed in the UTXO and Account based models.

Precommitting phase
In the first part of the protocol, there are two objectives: • Creation of the secret: this part is similar to the creation of the secret in HTLC and is done only by one group of participants.
• Creation of the aggregate public key: this is done by everyone and it is necessary for all participants to have the same possibility to manipulate the money.
In the following we will explain in detail these two subroutines. This phase is carried out in parallel by the two groups.

Secret creation
Participants P 1 , … , P N undertake a process of creating a secret. To do so, participants use a multiparty computation protocol with the goal of obtaining an output from hidden inputs. Formally, P 1 , … , P N from private inputs (x 1 , … , x n ) create an output y = f(x 1 , … , x n ). Examples for a function f To be more concrete, let's assume that f is the sum of the private inputs. Remember that the aggregate key is inherently public, as explained in Section 3.3, and that we don't know its private key and that the public key is different from the address on the blockchain. In fact, the address on the blockchain is a derivation of the public key. In the case of Bitcoin for example the address is a derivative of the script used within the transaction.
In this part we see the difference between a blockchain with an account-based model and one with a UTXO-based model. A blockchain with UTXO-based model uses particular constructs within the transaction, while a blockchain with account-based model deploys a Smart Contract.
Whatever mechanism is used in this phase, it must have the ability to be inactive for this phase. In fact, if it were active the other participants could take the tokens without giving their own in return. Inactivity can be achieved with time-locks or activation switches in the smart contract.
This mechanism must have two possibilities of redemption of funds. The first is to be used in case all participants are honest. In practice this means that the money goes from the group of participants P 1 , … , P N to Q 1 , … , Q N or vice versa. The second way of redemption is instead used in the event that the other participants are dishonest: assuming that the mechanism is initiated by P 1 , … , P N , the second way gives them the possibility to take back their tokens in case Q 1 , … , Q N behave dishonestly.

Commit phase
At this phase, the parties commit to sending money. Participants in both sets send transactions, whether this is a particular transaction or a transaction to the smart contract, in order to prove that they have the tokens and are willing to continue the protocol. In order not to confuse the transactions that occur in the different phases, we will call these transactions the inTx transactions, while the other transactions in the Redeeming Phase will be called the outTx transactions. Transactions inTx can be redeemed by P 1 , … , P N together before a time-out Δ, and by the single P i after that, similarly to the normal HTLC case (see Section 3.3) These transactions will be understood in detail in Section 5 where we present the case study between Bitcoin and Ethereum. This is the end of the Commit Phase.

Redeem phase
The last step is performed sequentially. Each step is done first by one group of participants and then by the other group of participants, when the latter receives confirmation that the intermediate step has been done. The goal of the participants in this step is to redeem all the tokens.
The protocol initiators P 1 , … , P N perform the first outTxes to redeem the transactions or smart contract of the finalizers Q 1 , … , Q N .
In the case of a blockchain with UTXO model, this type of transaction also has paths to be redeemed: the first if the finalizers are honest and the second in case they are dishonest. As in the Commit Phase, paths are time dependent, that is, transactions outTx can be redeemed by Q 1 , … , Q N before a time-out Δ ′ , and by P 1 , … , P N after that, again similarly to the normal HTLC case (see Section 3.3).
These transactions can be signed with the aggregate key created in the first step, contain h and can be redeemed by the finalizers using the y secret. In the case of a blockchain capable of supporting Smart Contracts, the logic is already all built into it and since the Smart Contract is already deployed in the first phase, this transaction simply consists of activating it (see functions activationSwitch and isSha256Preimage in Section 5).
After finalizers see the transactions made by initializers, they can proceed with their transactions and redeem the funds on the other blockchain, having seen the secret y in the blockchain.

ETHEREUM-BITCOIN CASE STUDY
For the purpose of this paper, we create a proof of concept of a MP-HTLC between the Bitcoin and the Ethereum blockchains. We made this choice because the former blockchain has a UTXO-based model while the latter has an account-based model.
Throughout this section, the notation changes slightly from the previous section to make it more intuitive according to the case study. Table 2 give a schematic view of what happens.
For easiness of explanation we distinguish between "bitcoiners", participants who have bitcoin and want ethers, and "etherers", participants who have ethers and want bitcoin. Formally, we assume there are 2N participants such that B 1 , … , B N are bitcoiners and E 1 , … , E N are etherers. We proceed with the description of the three phases of the MP-HTLC protocol.

Precommitting phase
In the first phase we assume that each B i has already chosen an E i and exchanged with it all the necessary information to proceed to a classical atomic swap (e.g., pubkeys, BTC/ETH rate, timeouts, and amount of coins). This part is outside the scope of the paper and can be performed via public billboards, order-books or, theoretically, even with Automated Market Makers.
In this phase and the next one, bitcoiners and etherers proceed in parallel without interaction. For ease of explanation, however, we first explain what happens between bitcoiners and then what happens between etherers.

Bitcoiners
Bitcoiners have two goals for the precommitting phase: to create a secret and its hash for the MP-HTLC, and to create a shared public key. Bitcoiners B 1 , … , B N use a distributed key generation mechanism Thresh − DKGen to create an aggregate public key AggPk BTC .

Etherers
Etherers have two goals for the precommitting phase: to create a shared public key, and to create and (after receiving h) deploy a smart contract SC. The smart contract contains the necessary logic for either receiving and sending funds based on the presentation of a preimage of the hash h or returning of funds to the owners. This smart contract is the analogue of the P2SH transactions made by bitcoiners. Etherers first use the same distributed key generation mechanism used by bitcoiners to create an aggregate public key AggPk ETH .
This step is also necessary in an account-based blockchain like Ethereum. This is because many of the operations can only be done by the person who creates the smart contract. Formally the smart contract must be deployed on the blockchain using the address associated with the public key AggPk ETH .
Deploying a smart contract means publishing a transaction to a particular address. For this reason it is possible to use threshold signatures of E 1 , … , E N to sign and publish it.
The main functions of the smart contract ‡ ‡ are: • activationSwitch: this function makes the smart contract active; before SC is activated, sending a preimage of the hash (however correct) does not allow the release of the coins contained in the smart contract • isSha256Preimage: this function takes care of sending funds to bitcoiners upon presentation of the right h hash preimage if SC has been previously activated via the activationSwitch function As of now the smart contract is deployed but unfunded and not activated. Both the funds and the activation arrive in the Commit Phase. This concludes the precommitting phase

Bitcoiners
In this phase, the goal of Bitcoiners is to fund AggPk BTC with a transaction. Using PSBT (see Section 3.

Etherers
Having created the smart contract SC in the precommitting phase with all the necessary logic, this phase is easier for etherers. E 1 , … , E N just send their funds (plus fees) to the smart contract. Then they wait for bitcoiners B 1 , … , B N in the redeem phase. Now SC is funded, but still inactive

Redeem phase
At the formal level, B 1 , … , B N must make a single transaction out tx BTC that has as input the transaction outputs identified by the in txHash BTC and as output Bitcoin addresses redeemable by E 1 , … , E N . B 1 , … , B N must then produce one threshold signature to publish this transaction.
The output addresses in this transaction are derived from P2SH transactions as in the Commit Phase. In fact each output has two redeeming paths as well (one before and one after a timeout we call out Δ, which is generally different from in Δ) to defend bitcoiners from possible non-activation by etherers. So this transaction is not a standard one and needs to be encapsulated in a P2SH transaction. For each ith output, the first redeeming path expires at timeout out Δ and needs the preimage of hash h, as well as the signature verifiable from the public key provided by The protocol is then concluded.

Implementation
We propose an implementation of this use case. The link can be found here § § .
To implement the threshold signature we used the ZenGo project ¶ ¶ . We modified the demo so that it would sign particular digests of transactions from the input. In particular we used the distributed key generation and the distribute signing protocol from Reference 51. This is one possible choice of many and we could use other threshold protocols. Then we proceeded to create scripts for both Bitcoin and Ethereum. To explain what we did we split this explanation into two parts

Bitcoin
We used the bitcoin-libs Python 3 library to create the transactions. We modified the library to make the transaction signed by the ZenGo library.
Namely we did five steps: • we create the aggregated key using the distributed key generation algorithm of the rust library and derived a P2PKH address; we call this address AggAddrBTC • we sent coins to this AggAddrBTC • we created a transaction to send the money to another address, we call this address NewAddr, and we get the digest.
• we used the rust library's API to sign in a distributed way the digest • we sent the transaction ##

Ethereum
In the case of Ethereum we made these steps: • we create the aggregated key using the distributed key generation algorithm of the rust library and derived an Ethereum address; we call this address AggAddrETH • we created a smart contract able to manage the funds, as explained in the previous subsection; the owner of the smart contract is the AggAddrETH • we modified the ethereumjs/tx creating a new function we called signTh: this function calls the rust library to sign the transactions so that it is verifiable using the aggregated public key behind AggAddrETH

EVM-COMPATIBLE BLOCKCHAINS CASE STUDY
Here we present another use case, namely a Ethereum-Polygon token exchange. After reading the section, it will be easy to see how this way to exchange tokens between blockchains can be used for any couple of EVM-compatible blockchain, effectively creating an alternative to centralized bridges such as the Binance smart chain bridge or the Polygon one. This use case is different from the previous one in two ways. The first difference concerns the model of the blockchains involved. In fact, both the Ethereum and Polygon blockchains are account-based: in this case MP-HTLC is smart contract based on both sides. The second difference is in terms of purpose. As stated by the Polygon whitepaper, the project aims to be an interoperable sidechain of Ethereum to achieve scalability. Polygon has faster block-creation time and cheaper fees. Currently many blockchain DApps are creating Polygon version of their services, especially DeFi services like AAVE*, SushiSwap † or Uniswap. 52 Note that the idea of using new EVM-compatible blockchains to solve Ethereum's scalability problems is not new and is also used by blockchain-based video games such as Axie Infinity ‡ which created its own EVM-compatible blockchain for game management.
Of course Polygon already provides a bridge to exchange tokens between the Polygon network and Ethereum, but this bridge is centralized and therefore is subject to possible censorship and theft. Here we propose a decentralized alternative using MP-HTLC.
To understand why our alternative can substitute the whole bridge, the reader should recall two things. The first one is that every token on a EVM-compatible blockchain are the result of the deploy of a smart contract which then manages the balances of the users. The second thing to remember it that given two EVM-compatible smart contracts SC A and SC B , it is possible to call a function in SC B from SC A . We use the notation We model the group of participants in this way. We assume there are N participants that own some amount of TokenA on the Ethereum blockchain and want the same amount of TokenA on the Polygon blockchain. We denote these participant as E A 1 , … , E A N and we call them etherers, as in Section 5. Similarly we assume there are N participants that own some amount of TokenA on the Polygon blockchain and want the same amount of TokenA on the Ethereum blockchain. We denote these participant as P A 1 , … , P A N and we call them polygoners. So there are 2N participants in total We proceed with the description of the three phases of the MP-HTLC protocol in the case of EVM-compatibility blockchains.

Precommitting phase
In the first phase we assume that each E A i has already chosen an P A i and exchanged with it all the necessary information to proceed to a classical atomic swap (e.g., pubkeys, timeouts, and amount of coins). Note that there is no rate of exchange for TokenA because we are assuming this token is pegged. As in the previous use case, how the participants exchange this data is outside the scope of the paper and can be performed via secure chats.
In this phase and the next one, etherers and polygoners proceed in parallel without interaction. For ease of explanation, however, we first explain what happens between etherers then what happens between polygoners, so in practice without loss of generality we assume etherers will start the process.

Etherers
Etherers have three goals for the precommitting phase: to create a secret and its hash for the multi-HTLC, to create a shared public key and to use this public key AggPk ETH as the identity (address) for deploying the smart contract SC ETH that containing the necessary logic for managing the funds.
In practice etherers E A 1 , … , E A N use the distributed key generation mechanism Thresh − DKGen to create an aggregate public key AggPk ETH and MPC to create a secret all together, as in the previous use case. From the secret s, all participants can build the same hash h = H(s) and use it in the second set of transactions in the Redeem Phase.
After that, each E A i is responsible to send h to P A i . The smart contract is the same as the one in the previous use case. The only difference is the function to send money. As explained before, there is a function call from SC ETH to the smart contract of TokenA on Ethereum. Formally the function is: which is called if the checkHash function returns true

Polygoners
Polygoners have two goals for the precommitting phase: to create a shared public key, and to create and (after receiving h) deploy the smart contract SC POL . Polygoners first use the same distributed key generation mechanism used by etherers to create an aggregate public key AggPk POL . l The smart contract is the same as the one in the Ethereum case. The function call from SC POL to the smart contract of TokenA on Polygon is: which is called if the checkHash function on SC POL returns true As of now both smart contracts are deployed but unfunded and not activated. Both the funds and the activation arrive in the Commit Phase.
This concludes the precommitting phase

Commit phase
In this phase participants on both chains send funds to the send the funds to their respective smart contracts. Now SC ETH and SC POL are funded, but still inactive

Redeem phase
Similarly as the Redeem Phase of Section 5, participants activate their relative smart contract. After doing that etherers redeem the funds in SC POL by sending the preimage of h. Polygoners are therefore able to get the funds from SC ETH .

ANALYSIS
In the following we present a cost analysis where we prove that MP-HTLC can be superior to HTLC in terms of number of transactions needed and an attack analysis. Finally we present a note on the security of the protocol.

Cost analysis
In this section we analyze the costs of our MP-HTLC. We compare it with the standard HTLC. We prove that as long as there are at least two participants on a UTXO-based blockchain, then it is more cost effective to use MP-HTLC instead of instantiating different HTLCs.
In the standard HTLC as defined in Reference 4 (and explained in Section 3. We count the number of transactions for each phase in both the UTXO and account model assuming there are n participants on each blockchain. In Table 3 we put a summary of the number of transaction for each phase and each model. Batching is currently impossible on account-based blockchain, even if there are multiple proposals that aim to address and solve this problem, especially for EVM-compatible blockchain. [53][54][55][56] If it will be possible to batch more transactions into one, then the number of transaction in an account-based blockchain will be the same as the number of transactions needed in a UTXO-based blockchain.

Attack analysis
Multiple-blockchains modeling is more complicated than treating each part singularly, as there is extra complexity underlying the cross-chain communication. In fact, even if each blockchain has its own security model, these models can be different between blockchains. For example: the Bitcoin blockchain Proof-of-Work-based consensus algorithm is proved to work correctly only if the adversarial computation power is less than 33%. 57 On the other hand, some Proof-of-Stake-based consensus algorithms are proved to work correctly only if the total adversarial stake is less than 33%.
Even if the two values are the same, the cost of attaining them is potentially different.
We decided to address the two blockchain attacks that have reorganization of blocks (also called reorgs) as a consequence: other attack would have no effect on the transactions. Note that there is no 51% attack. This is because it is not a real attack formally, but it is a state of the blockchain nodes that allows the implementation of real attacks, such as censorship or double spending. So in this sense, we do not directly mention the 51% attack, but we do mention its effects.

Double spending
This is the most famous blockchain attack and it is even mentioned in the Satoshi's Bitcoin paper. 16 The goal is to trick two different entities (e.g., two different merchants) into assuming they have been paid, using the same coins (technically, the same transaction output(s) in a UTXO-model blockchain, see Section 3.2). When this attack is successful, only one of those transactions is definitely accepted by the blockchain network, but the attacker receives both products from both vendors. The easiest way to deal with this attack is by waiting for the confirmation period. As explained in Section 3.1 there is no global or shared clock. So "time" is defined as the passing of blocks' generation. In this case, participant have to wait for the confirmation period of their chain before assuming the current phase is finished and starting the next phase of the protocol. Other works, such as Sai et al., 58 propose methods to punish the double spend problem across two blockchains.
Similar to the Double spend attack, the Finney and Brute force attacks aim to spend the same coins twice. they are different on the social level.
For example, the Brute-Force attack assumes the attacker can control a lot of computing power and it will use this power to perform the double spend. Because the mechanics of the attack are the same, we don't further analyze these variation.

Selfish mining and selfish endorsing
Eyal and Sirer propose the selfish mining attack, 57 where a malicious miners is incentivized to deviate from the honest protocol withholding valid blocks until it mines two consecutive blocks. If this strategy is successful, then the miner gets double the reward because both of its blocks gets accepted forming the longer chain ¶ . In the following years Sapirshtein et al. 59 identify the optimal selfish-mining policy, Nayak et al., 60

A note on correctness
Goal of this section is to prove that the MP-HTLC protocol is correct in the same sense a HTLC is correct. Intuitively, that is because MP-HTLC follows the same construction of HTLCs, if we abstract the participants on one side as a single entity. Yet, we have to prove that this abstractions is well defined, meaning that we have to prove that (using the general notation of Section 4) a cheating participant between P 1 , … , P N or Q 1 , … , Q N would not endanger the correctness of the protocol. We will prove it by showing that if there is a dishonest participantP j between P 1 , … , P N , then the protocol is still correct if Q 1 , … , Q N treat P 1 , … , P N as all dishonest participants and abort the protocol. The same goes if there is a dishonest participantQ j between Q 1 , … , Q N .
We do that in two steps. In the first step we assume participants can only cheat by missing timeouts. Then we let participants cheat by sending arbitrary messages. Note that in Section 3.1 we stated that P 1 , … , P N may be actively dishonest only towards Q 1 , … , Q N and passively dishonest towards all participants in the MP-HTLC protocol, and that the same goes for Q 1 , … , Q N .
We need to reason around the concept of "time", an essential concept to talk about timeouts in a meaningful way. Throughout the paper we assumed asynchronous systems and a block-based time tracking (see Section 3.1). Assuming a constant rate of block production for each blockchain (e.g., at most 15 blocks produced in Ethereum per one block produced in Bitcoin) is enough to ensure correctness of the HTLC protocol between two parties (single entities) Alice and Bob. The question is under which assumptions this reasoning holds true in the case of multiple parties for each blockchain.
The main source of problems comes from the fact that in normal HTLCs between two parties A and B, one entity A either respects or does not respect the timeout, with no middle cases. In case A does not respect the timeout, then B acts accordingly. On the other hand, in case of multiple participants P 1 , … , P N it is possible to have a situation in which some participants have been honest and respected the timeout, while others did not. We denote asP j the dishonest participant in the set {P 1 , … , P N }. In such a case, we have implicitly considered the protocol as aborting, that is, we assumed that participants P 1 , … , P N and Q 1 , … , Q N stop the protocol and redeem the coins they already invested. We have to prove that this behavior does not affect the correctness of the protocol.
We start by stating what correct means in MP-HTLC and then we prove that the protocol is correct even in the aforementioned case. Definition 1. (correctness) Let P 1 , … , P N be participants in blockchain BC 1 , powered by coin c 1 , who owns amounts a 1 1 , … , a 1 N of coin c 1 respectively. Similarly, let Q 1 , … , Q N be participants in blockchain BC 2 , powered by coin c 2 , who owns amounts a 2 1 , … , a 2 N of coin c 2 respectively. Finally, assume c 1 = c 2 with the agreed exchange rate between c 1 and c 2 and , so that the value a 1 i c 1 has the same (monetary) value as a 2 i c 2 for each i = 1 … N. Then the protocol as described in Section 4 is correct under the model of Section 3.1 if and only if at the end of the protocol: 1. Either any rational participant in P 1 , … , P N obtained amounts a 2 1 , … , a 2 N of coin c 2 and any rational participant in Q 1 , … , Q N obtained amounts a 1 1 , … , a 1 N of coin c 1 2. Or any rational participant in P 1 , … , P N still own amounts a 1 1 , … , a 1 N of coin c 1 and any rational participant in Q 1 , … , Q N own amounts a 2 1 , … , a 2 N of coin c 2 In other words, Definition 1 states that the MP-HTLC protocol is correct if and only if participants either get the amounts of coins they want (Point 1 of the definition) or they still own the initial amount of funds (Point 2 of the definition), in accordance with the requirements of a general CCC 8 as presented in Section 3.3. We are ready to prove that MP-HTLC is correct in the case of participants missing timeouts. Proposition 1. Assume participants P 1 , … , P N need to exchange an amount a 1 1 , … , a 1 N of coin c 1 on blockchain BC 1 for an amount a 2 1 , … , a 2 N of coin c 2 on blockchain BC 2 , and assume participants Q 1 , … , Q N have an opposite need. Assume there is at least one rational participant P r among P 1 , … , P N and at least one rational participant Q r among Q 1 , … , Q N .
Assume P 1 , … , P N and Q 1 , … , Q N agree on using MP-HTLC and that participantP j is dishonest and does not follow the protocol by missing the timeout Δ, as defined in Section 4.2. Then if all participants P 1 , … , P N and Q 1 , … , Q N abort the protocol, then the protocol MP-HTLC is correct in the sense of Point 2 of Definition 1. This is valid also in the case participantQ j is dishonest and does not follow the protocol by missing the timeout Δ ′ as defined in Section 4.3.
Proof. Recall that we assumed participants can get the current state of both blockchains BC 1 and BC 2 at any time.
Assume dishonest participantP j does not follow the protocol at the Commit Phase (Section 4.2) and by the time the timeout Δ passesP j has not sent its own inTx transaction. Then all participants in the set {P 1 , … , P N } ⧵ {P j } can redeem their own inTx transaction.
Furthermore, participants Q 1 , … , Q N see this behavior by observing the blockchain BC 1 . Since there is at least one rational participant in the {Q 1 , … , Q N } set it is clear that it is impossible for them to conclude the Redeem Phase, since Q r will not participate in signing the outTx (Section 4.3), forcing Q 1 , … , Q N to redeem their inTx transaction. Therefore the protocol aborts and P 1 , … , P N own amounts a 1 1 , … , a 1 N of coin c 1 respectively and Q 1 , … , Q N own amounts a 2 1 , … , a 2 N of coin c 2 respectively, which is the case presented in Point 2 of Definition 1. Note that this reasoning also applies to the case where dishonest participantQ j has not sent its own inTx transaction on BC 2 by the time the timeout Δ passes in the Commit Phase, since rational participant P r will not sign outTx.
On the other hand, assume all participants P 1 , … , P N and Q 1 , … , Q N completed the Pre-commit and Commit Phases successfully, and they are in the Redeem Phase. Then P 1 , … , P N have to sign a transaction together using threshold signatures as in Section 3.4, regardless of whether they are in a UTXO based blockchain or in an Account based blockchain. SinceP j can only cheat by missing deadlines, we assumeP j participates in it. Assume for the same reason that Q 1 , … , Q N also follow the protocol. The only deadlineP j can miss is the redeeming of outTx in BC 2 . But in this caseP j would not be rational and the correctness definition does not apply to him sinceP j goes against his own interest. Interestingly, Q j if rational will be able to redeem its own coins on BC 1 regardless, since Q j can surely see the preimage of the hash from rational participant P r : which is the case presented in Point 1 of Definition 1. ▪ After proving that if one participant misses a deadline then the protocol is still correct, we now see that this remains true for any kind of dishonest behavior, provided it is compliant with the model in Section 3.1. We do that by showing that any dishonest behavior involving transactions is equivalent to missing a timeout and therefore already covered in Proposition 1.

Proposition 2.
Assume a setting similar to Proposition 1 where P 1 , … , P N and Q 1 , … , Q N are allowed to have dishonest behavior according to the model in Section 3.1. Then the protocol as described in Section 4 is correct, as in the Definition 1.
Proof. The easiest way to prove that is by going through each of the phases. In the precommit phase there is no transaction involved, so any cheating has no effect on any fund.
In the Commit phase, the only transactions are the one analyzed in Proposition 1 and are "on the same side", meaning P 1 , … , P N do transactions that are redeemed by either P 1 , … , P N together with a threshold signature or each participant will redeem its own.
All possible kinds of dishonest behavior in this phase have to be equivalent to missing the timeout Δ: dishonest participantP j cannot steal funds from P i in any way since it is not allowed by the model described in Section 3.1. Therefore the whole Commit Phase for Finally, regarding the Redeeming Phase, P 1 , … , P N are required to essentially send funds to Q 1 , … , Q N and viceversa. Assume a dishonest participantP j which blocks this step: then the redeeming phase cannot start, which is basically a missed timeout and parties can redeem their own funds. As in Proposition 1 then, the protocol remains correct thanks to Point 1 of Definition 1. ▪

A note on security
While the HTLC is vulnerable to bribery attacks (see e.g., References 63 and 64), recently Tsabary et al. presented MAD-HTLC. 65 In MAD-HTLC the authors modify the classic HTLC adding a redeem path that benefits the miner in case Bob is dishonest but benign (i.e., rational and willing not to follow the protocol in case of potential reward but prefers to act honestly for the same reward). This contract is called MH-Dep.
To prevent the case where Bob is spiteful (i.e., dishonest even if he would lose the reward) the authors introduce a collateral contract (MD-Col).
MD-Col can be redeemed by Bob if he's honest, or by any miner if Bob tries to be dishonest.
Using MAD-HTLC instead of HTLC in a cross-chain communication doesn't provide atomicity anymore: MAD-HTLC uses the mutual assure destruction (MAD) principle where if a party misbehave, then all parties lose everything.
MP-HTLC can obtain synchrony with both MAD-HTLC and HTLC thanks to the modularity of the construction, but for ease of explanation we presented the MP-HTLC protocol using HTLC.

Other synchrony methods
Throughout the article, we described MP-HTLC using HTLC as a method to achieve synchrony between two blockchains (i.e., two asynchronous systems). The downside is that HTLCs require both chains to support the same hash function and that's not always the case. For example, Tezos supports the Blake2 hash function, Bitcoin the SHA256 function and Monero don't support any hash function as it does not have a scripting language.
Fortunately, HTLCs aren't the only locking mechanism for getting synchrony out of the system. Other methods are: • Signature Based Locks. Instead of relying on the preimage resistance property, signature based lock rely on the discrete logarithm problem. In this case, after creating a secret r, Alice computes Y = g r and embeds it in the creation of a digital signature. 66 it is possible to prove discrete logarithm equality even across different groups, 44 which means that a variation of MP-HTLC supporting Monero is possible and we are working on it right now.
• Time Lock Puzzles. In this case Alice weakly encrypts the secret r so that Bob can decrypt it in a finite and predetermined (by Alice) time using basically a brute force algorithm. An example is found in Reference 67.
It is possible to combine locking mechanism. For example it is possible to prove that a discrete logarithm is equal to a preimage via zero-knowledge proofs. 68 This enables the implementation of MP-HTLC between a HTLC-capable blockchain such as Bitcoin or Ethereum and a non-HTLC-capable blockchain such as Monero that is capable of Signature Based Locks.

CONCLUSIONS
In this paper we presented a method to achieve hash-time-lock contracts between multiple participants in the same instance in order to decrease costs and increase user privacy. We have also presented two use cases. The first between Bitcoin and Ethereum, where we also linked the code used to instantiate the protocol and produce a test transaction. The other use case is done between two EVM-compatible blockchain.
To prove that the MP-HTLC protocol satisfies correctness as the HTLCs, we described a suitable model where the participants can be abstracted as one rational entity and proved correctness in that model. To achieve that, we assumed participants on one blockchain are not willing to perform active dishonest acts to each other. The rationale has been that one single participant would act in its own self-interest if rational, and we decided to treat the whole group as rational. Surprisingly, we proved that under these assumptions it is possible to treat the whole group as rational by requiring only one rational party per group of participants. We argued that for protocol correctness purposes requiring one rational party for each group allows for the treatment of the whole group of participants P 1 , … , P N and Q 1 , … , Q N as two separate single entities.

CONFLICT OF INTEREST
All authors declare that they have no conflicts of interest