Proceedings on Privacy Enhancing Technologies 2021

Felix Engelmann*, Lukas Müller, Andreas Peter, Frank Kargl, and Christoph Bösch SwapCT: Swap Confidential Transactions for Privacy-Preserving Multi-Token Exchanges

Abstract: Decentralized token exchanges allow for se- e.g. reputation points, lottery tickets, shares of com- cure trading of tokens without a trusted third party. panies, fiat currency, precious metals and many more. However, decentralization is mostly achieved at the ex- While the token’s security is backed by a distributed pense of transaction privacy. For a fair exchange, trans- ledger (DLT) sometimes called (block)chain, most are actions must remain private to hide the participants traded on centralized exchanges which operate like stock and volumes while maintaining the possibility for non- exchanges. These central exchanges provide the required interactive execution of trades. In this paper we present privacy for fair trading such that participants have no a swap confidential transaction system (SwapCT) which insight into a detailed order book or trades of competi- is related to ring confidential transactions (e.g. used tors. Unfortunately, users have to trust the exchange op- in Monero) but supports multiple token types to trade erators which are susceptible to malicious activity like among and enables secure, partial transactions for non- theft [6] or hacks for data exfiltration. Due to these interactive swaps. We prove that SwapCT is secure in reasons, self-governing exchanges based on consensus a strict, formal model and present its efficient perfor- in a distributed ledger system are beneficial. There are mance in a prototype implementation with logarithmic plenty of smart contract based decentralized exchanges, signature sizes for large anonymity sets. For our con- however, to allow public auditing, they typically reveal struction we design an aggregatable signature scheme details about the performed trades. With all bids and of- which might be of independent interest. Our SwapCT fers persisted on the DLT, the exchange is no longer pri- system thereby enables a secure and private exchange vate and any malicious participant in the system has the for tokens without a trusted third party. advantage of detailed insights into the order book and upcoming offers in the pool of unconfirmed DLT trans- Keywords: atomic swap, exchange, typed tokens actions (mempool). This enables e.g. front-running [10] attacks, where a miner who notices a large bid in the mempool may just persist an order of themselves first 1 Introduction and then profit from selling it later to the prospective buyer. The underlying issues are persisted, public offers (smart contract calls) when ordered by an untrusted Crypto-currencies are primarily used to trade tokens. party. Either they are traded between systems or within Many applications which build on top of a token sys- one environment, such as within Ethereum with its tem require an efficient and fair exchange mechanism. ERC20 [19] token standard. The thousands of ERC20 Exchange happens between tokens of different types and tokens with multiple billions USD of market capitaliza- between a type and the base currency to initially buy tion and similar daily trading volumes1 are used to trade and sell the tokens or pay fees. Additionally, a large part of Ethereum’s success is attributed to the possibility of creating arbitrary tokens independent of the base cur- *Corresponding Author: Felix Engelmann: Aarhus rency. However, all token types inherit the security of University, Denmark, E-mail: [email protected] or the whole Ethereum network, which is not the case for [email protected] tokens deployed and maintained on their own ledger. Lukas Müller: Ulm University, Germany, E-mail: [email protected] We illustrate the benefits of a single DLT with swaps Andreas Peter: University of Twente, The Netherlands, E- between types with a concrete example: a DLT-based li- mail: [email protected] cense management system for 3D-printed objects where Frank Kargl: Ulm University, Germany, E-mail: everyone can create new 3D object designs and license [email protected] them to others for printing. Such transfers of licenses are Christoph Bösch: Ulm University, Germany, E-mail: [email protected] represented by transactions on the DLT and each object type is represented by a separate token type. Introduc- 1 https://coinmarketcap.com/tokens/ SwapCT 2 ing a new object design, which happens frequently, in- Table 1. Overview of systems and their supported properties. volves introducing a new token type. Setting up and Partial support of a feature is noted with (X). maintaining a separate chain for each token type gen- SRA COA COT DSE NIT DEX [22] erates a much higher overhead than a single multi type MimbleWimble [12] XX X (X) chain. In addition to performance, this example demon- Confidential Assets [17] XXXX strates our privacy and confidentiality requirements. If Stellar [2] XXXX Zcash [18] [13] ( [13]) information about company A licensing a certain num- XXX X X X-Chain Swap [8] XXXX (X) ber of prints for a specific design is available on the Monero [1] XXXX DLT, then this means a leak of crucial information to Omniring [15] XXXX competitors. Even the meta-data from the existence of Our SwapCT XXXXXX private transactions on a chain dedicated for one design inevitably leaks information about business activities of them atomic swap transactions. To satisfy the NIT prop- company A. Therefore, we require a DLT with support erty, atomic swaps need to be non-interactive and work for user anonymity and confidentiality for transactions without a trusted third party. By non-interactive we that hide the token type and whether a transaction is a mean to allow a single message only from the offering regular transfer or a swap. party to e.g. an exchange. This is analogous to a classical To realize a privacy friendly multi-token system exchange, where a party submits a bid to an exchange which provides similar operations as ERC20 tokens, its and then forgets about it until it is fulfilled. Our non- functionality has to include registration of new token interactivity especially excludes the offering party to ac- types for any user and trading between all types. Most tively participate in the merging of offers. For sender applications using ERC20 tokens, i.e. those pegged to anonymity, swap transactions hide the number of par- fiat currency, rely only on these features and there- ticipants resulting in the indistinguishability of simple fore can seamlessly switch to a privacy-preserving multi- transfers and swaps providing additional privacy by a token system. Trading needs to be 1. private, such that joint anonymity set. only selected parties have insight into what is traded A transaction system with all the above properties and 2. fair, i.e. no malicious party can abort with a provides a privacy friendly alternative for many existing profit. For this, we identify the following six proper- applications currently based on public tokens. Addition- ties required by a privacy-preserving DLT transaction ally, new platforms with strong privacy requirements, as system: Sender and receiver anonymity (SRA) en- described in the above-mentioned licensing example, are sures that senders of funds should remain hidden to easily developed on top of such a private system. Table all parties and that recipients are known only to the 1 provides an overview of existing systems with support sender of a transaction. This enables basic user privacy for a large subset of our required properties. We describe in transactions. Confidential amounts (COA) hide the details on these systems in Section 2. the amounts transferred and thereby prevent heuristic Our goal is to design a transaction system, that sat- deanonymization of rational transactors. Confidential isfies all six aforementioned properties. While Omniring types (COT) support independent token types within provides a thorough security definition for a single to- one transaction system and hide the type to provide a ken system, there exists no formal description of a multi single joint anonymity set over all types. Decentral- token system with swap transactions. Regarding a con- ized setup (DSE) ensures that the security and privacy struction, the restriction on communication (NIT) re- of the system does not rely on a trusted party or cere- quires participants of a swap to prepare a partial trans- mony. This increases the trust for a truly decentralized action signature which is mergeable into a transaction system. Non-interactive transactions (NIT) guaran- by an untrusted party, perfectly hiding the contribu- tee that transactions consist of a single, non-interactive tors of the final signature. To our knowledge, there is broadcast message. Any direct communication between no signature scheme supporting this merge operation. senders and receivers decreases the sender anonymity Therefore, we propose a novel aggregatable signature as the receiver learns the network identity of the sender scheme for this purpose. through meta-data. Decentralized exchanges (DEX) To address all six properties combined for a decen- should be used to trade tokens of different types. Trad- tralized exchange and to overcome the drawbacks of ex- ing is achieved by supporting transactions which ex- isting systems, we propose Swap Confidential Transac- change the ownership of tokens of different types. As tions (SwapCT), a decentralized and privacy-preserving they atomically swap the ownership of tokens, we name transactions system for multiple token types support- SwapCT 3 ing non-interactive, atomic swaps. SwapCT is based on Zcash [18] is a production system providing user unspent transaction outputs (UTXO) where tokens are privacy and amount confidentiality without support for stored in transaction outputs and spent by anonymously types. It hides amounts in commitments and references referencing these. All referenced outputs become invalid previous outputs through zero-knowledge proofs. The to prevent double spending. We make use of primitives efficiency of Zcash’s zk-SNARK proofs is dependent on proven efficient and secure in Monero [1] and Omnir- a trusted setup. Recipients’ identities are protected by ing [15] (DSE) such as logarithmically sized, linkable ring one-time addresses. To facilitate trade between such sin- signatures for sender anonymity and one-time addresses gle type systems, there are multiple approaches, summa- for receiver anonymity (SRA). Instead of Pedersen com- rized by Zamyatin et al. [21], even in a private setting mitments for amounts, we integrate typed homomorphic with privacy-preserving cross-chain swaps [8]. Cross- commitments similar to confidential assets to hide the chain transactions generally create one transaction on amounts (COA) and types (COT). To prove conservation each chain which privately reference each other. Only if of types and amounts combined, we design an efficient both transactions are valid, the tokens are exchanged. zero-knowledge proof based on Bulletproofs [4]. Independent single-type DLTs with cross-chain swaps For atomic swap transactions that are indistinguish- allow for flexible governance and implementations opti- able from simple transactions, we propose a transaction mized for the specific token’s challenges. As cross-chain structure which uses our new aggregatable signature swaps require a new DLT for each token they cannot scheme. For such an atomic swap transaction, senders provide type confidentiality. create offers which capture the intent to spend some Poelstra et al. [17] propose confidential assets, a tokens in return for different types of tokens. Offers commitment scheme to provide confidential types and provide sender and receiver anonymity and are not per- confidential amounts. The interactive transaction gen- sisted on a DLT. For additional sender privacy, offers are eration of MimbleWimble [12] allows for a direct re- mergeable non-interactively from original senders (NIT). placement of the single type commitment scheme with An atomic swap is performed by merging two matching confidential assets, demonstrated by Zheng et al. [22]. offers. If the offers do not match exactly, a third offer, Instead of using addresses to non-interactively receive prepared by the merger with their own inputs, is added. tokens, the MimbleWimble transaction generation is an Merged offers are persisted as a single transaction, in- interactive protocol between sender and receivers, re- distinguishable from regular transactions (DEX). ducing the anonymity of both. Our contributions can be summarized as follows: Stellar is an already deployed transaction system – We specify a formal model for SwapCT systems with multiple asset types. It uses ZkVM [2] transactions which extends the type-less model of Omniring. to enable confidential transactions that satisfy an ar- – We provide an efficient instantiation of our SwapCT bitrary arithmetic circuit. To create a transaction, the system which natively supports multiple token sender provides a proof of correctness according to the types, large anonymity sets and swap transactions constraint system. However, the system does not pro- that are indistinguishable from regular transactions. vide sender anonymity or non-interactive swaps. – We prove the security of our SwapCT protocol. Gao et al. propose a private atomic exchange [13] – To non-interactively merge partial transactions and where they introduce the notion of debt which has to be hide the original participants, we propose a novel settled on spending. The authors claim that their model anonymously aggregatable signature scheme, which can be instantiated in a transparent setup, and provide might be of independent interest. a Zcash [18] based version without a performance eval- – We implement our SwapCT scheme and pro- uation or implementation. Their system requires per- vide performance numbers comparable to Monero sisting multiple transactions per swap, increasing the demonstrating its efficiency. overall cost and duration. Monero [1], Omniring [15] and RingCT 3.0 [20] are privacy-preserving transaction systems with a trans- 2 Related Work parent setup, sender and receiver anonymity, non- interactive transactions and amount confidentiality. These systems use anonymity sets to hide senders and Previous research and commercial projects achieved generate one-time addresses for receiver anonymity. some properties required for a private, decentralized ex- Their transaction verification proves conservation of a change system as shown in Table 1. SwapCT 4

[¤][a] tag ← MLSAG [¤][a] which proves that the signer knows the inputs’ secret [][] [a] [][] [][] [¤][a] [][] [¤][a] keys ¤ and that the intermediate commitment is equal [¤][a] [][] [¤][a] [][] [¤][a] [¤][a] [¤][a] to the real input. Wealth conservation is then proven [¤][a] [a] Σ,rng [][] tag, tag ← Omnisig [][] tag ← MLSAG by a Schnorr signature Σ over intermediate and output (a) Monero RCT-simple (b) Omniring commitments and Bulletproof range proofs [4] (rng) in [¤][a,ty] [][] [¤] a,ty [][] a,ty [][] [a,ty] Figure (1a). [¤] a,ty [][a,ty] [][] tag ← AS [][] Monero as well as Omniring require the final set of [][a,ty] [][] [][] [][a,ty] outputs at the time of signing the input ring(s), which [¤][a,ty] a,ty [¤] a,ty [][] [a,ty] Seal is not available in non-interactive swaps since the swap [][] tag ← AS [][] tag, tag ← AS (c) SwapCT offerer (d) SwapCT merger partner might not be known in advance. To support non- interactive swap transactions, we propose a new transac- Fig. 1. Transaction structures for (a) Monero RCT-simple, (b) Omniring, (c) two SwapCT offers and (d) one SwapCT trans- tion structure (Figure 1 (c,d)) which slightly resembles action. a represent arbitrary amounts, ty is any type. Dashed Monero. Figure (1c) shows two independent parties (up- lines are signatures to authorize spending and dotted lines ensure per and lower), each with one input [¤][a]. However, in- wealth conservation. [·] denotes a commitment to the value and if stead of directly signing inputs with ring signatures, us- not blank, the value is known to the signer. ing all outputs concatenated as signing message, we pro- single currency and has no notion of types. Without pose a new anonymously aggregatable signature (AS) in multiple token types, they do not support atomic swaps. combination with an efficient linkable ring signature for each input. We use a separate ring signature for each input to hide if multiple inputs are contributed by the 3 Private UTXO Transactions same signer. Each partial transaction, called offer, has its own outputs [¤] a,ty which are joined by merging of- fers. We use the intermediate copies for amounts and In this section we provide an overview of different ap- types a,ty as Monero does for amounts [a] only. The open- proaches to UTXO based transaction structures and de- ings of our intermediate and output commitments are scribe how our new SwapCT structure relates to them. part of the offer and therefore offers must not be pub- Figure 1 shows the transaction structures most simi- lished globally. We envision multiple off-chain dissemi- lar to our scheme ((a) Monero RCT-simple and (b) nation scenarios: 1. The offer is not shared with anyone. Omniring). All examples use 2 inputs and 3 outputs. The outputs are then designated recipients, resulting in The visibility of secrets is from the senders perspective. a simple transaction. 2. The offer is sent to a peer who To achieve sender anonymity, both schemes rely on an created a matching offer. The offers are merged for an anonymity set where each real input [¤][a] of the sender atomic swap transaction. 3. The offer is shared with a on the left is hidden in a set of other possible inputs, small group of participants who may be interested to denoted by empty brackets [][]. For the real inputs, fulfill the offer. 4. The offer is sent to a lightweight ex- a tag is provided such that reusing the same input is change. Exchanges in our SwapCT system are entrusted detectable. The consensus algorithm maintains only a with publishing an order-book and merging of offers. list of spent tags and rejects all transactions with a tag Due to our AS, ring signature and one-time accounts, already used as double spend attempts. While Monero SwapCT exchanges cannot steal tokens or deanonymize uses an independent ring signature for each input, Om- their users. A merged transaction is sealed to assure niring, true to its name, uses a joint ring as anonymity amount and type conservation (Seal). The real senders set for all inputs. The outputs of a transaction, on the are hidden from the merger who only seals a transaction right in all schemes, are one-time accounts derived from with the final set of outputs and intermediate commit- recipient identities by the sender. ments. Miners without insight into transactions have no Transactions are signed to attest the intent to spend advantage reordering them to front-run offers. the real input to designated outputs by proving knowl- To support confidential types, the wealth conser- edge of the inputs’ private keys ¤ and to ensure that vation requires a zero-knowledge proof that the com- the cumulative wealth in the output is equal to the one mitted types are valid. The DLT maintains a list of in the inputs. Omniring uses an all encompassing ring valid types. New types are registered by proposing a signature (Omnisig) to prove both requirements. Mon- one-time account which holds the initial supply of to- ero first copies the amounts into intermediate commit- kens. If the new type is unique, it is persisted in the ments [a]. Then, MLSAG [1] is used as the ring signature DLT and future transactions can reference it as input. SwapCT 5

These are similar requirements to other privacy preserv- Alice Bob DLT ltp := KeyGen ltp := KeyGen Setup ing DLTs such as Zcash and Monero and allow SwapCT A B tyg = TypeGen(green) tyr = TypeGen(red)

accA = OTGen(ltpA, 42, tyg) accB = OTGen(ltpB , 100, tyr) to be readily deployed on a clone of their DLT infras- accB , red accA, green acc 0 = OTGen(ltp , 40, ty ) acc 0 = OTGen(ltp , 95, ty ) tructure. Alternatively SwapCT can be integrated into A A g B B r accA00 = OTGen(ltpA, 5, tyr) accB00 = OTGen(ltpB , 2, tyg) a blockchain framework such as https://substrate.dev. SA = {(accA, tagA)} SB = {(accB , tagB )} Substrate is a rust framework which provides modules to TA = {accA0 , accA00 } TB = {accB0 , accB00 } oA = Offer(SA, RA, TA) oB = Offer(SB , RB , TB ) operate a blockchain. Our rust prototype implementa- offA = off(SA, RA, TA) offB = off(SB , RB , TB ) Merger tion of SwapCT is easily adapted to form the transaction offA, oA, offB , oB generation and validation module, as it already has an o = Merge(oA, oB ) t = Seal(offA ∪ offB , o) interface close to substrate’s architecture. The remain- tx = tx(off ∪ off ) A B VfTx(tx, t) (40, ty ), (5, ty ) = Receive(tx) der of necessary components for a blockchain, such as g r (95, tyr), (2, tyg) = Receive(tx) peer-to-peer network with discovery, block generation and dissemination is provided by the framework. Fig. 2. Example of a full SwapCT system with setup, type regis- For efficient ring signatures and conservation proofs tration and an atomic swap of 2 green for 5 red tokens between Alice and Bob with an untrusted Merger and DLT. Sampling of in SwapCT, we adapt an elegant Bulletproof non- the rings Ra and Rb is covered by related research [16]. interactive, zero-knowledge approach, which is similar to the single signature in Omniring. With an anonymity ply of each type is fixed in this operation. The consen- set size of r and m inputs, this results in transaction sus accepts the registration of a new token type as the sizes of SwapCT between the logarithmic efficiency of identifiers (g, r) are unique regarding all previous regis- Omniring O(log(m·r)) and the linear efficiency of Mon- trations. Alice now possesses all green tokens and Bob ero O(m · r). We achieve a transaction size logarithmic all red tokens. Alice wants 5 red tokens and proceeds to in the size of the anonymity set per input O(m log(r)) generate outputs accA0 and accA00 which deduct 2 green because of the non-interactive ring signature creation. tokens from her account accA and give her 5 red tokens. An efficient proof for large ring sizes is important She authorizes the tentative spending of accA by creat- to provide sender anonymity. As SwapCT ring signa- ing an offer offA with inputs SA, outputs TA and ring tures provide the same anonymity as Monero ring sig- members RA signed by Offer. Bob creates a complemen- natures, we can use the Binned Mixin Sampling from tary offer, which trades 5 red tokens for 2 green tokens. Möser et al. [16] to select the ring members. Binned The spending authorization consists of publishing a tag Mixin Sampling references temporally local groups of corresponding to the input account. The offers are then previous outputs to counter timing attacks and protect merged with Merge by either an independent Merger, against an adversary who controls many outputs. Sam- Alice or Bob. Merging does not require any secret in- pling a proper ring is important, as transaction graph put. However, each input in an offer contains a unique analysis with external information may trace an input to tag to prevent double-spending. Anyone with access to a real sender with high probability. While Monero users an offer will recognize its tag in a persisted transaction. are financially incentivized to keep the ring size small Still, access to an offer does not deanonymize the sender due to linear transaction fees per mixin, our SwapCT or receiver and only reveals the tokens transferred. ring signature sizes only grow logarithmically in the ring A balanced offer, where the input and output is size. The default Monero ring size of 11 may provide a equal, is then sealed with Seal and submitted to the worst-case effective untraceability set of 4 to 6 possible consensus for verification (VfTx). The transaction is per- inputs. With suggested 123 ring members in SwapCT, sisted, if the signatures are valid and all tags are unique the worst-case effective untraceability is 40 to 60. The regarding all previous transactions. After persisting the effective untraceability is the anonymity set expected af- 0 00 transaction, the designated outputs {accA, accA} and ter running statistical deanonymization attacks on the 0 00 {accB, accB} generated in the offer process are received transaction graph. with Receive and usable as future transaction inputs. To show the usual interaction of the algorithms of our SwapCT system, we describe a swap between Alice and Bob in Figure 2. The system is transparently set up and to participate both users generate a long term 4 Formalizing Swap Transactions key with KeyGen serving as their identity. As there are no types registered yet, both create their own type with In our SwapCT system, we distinguish the following TypeGen and set themselves as recipients. The total sup- roles in our security model, where each participant of SwapCT 6 the system may hold multiple roles at once and over for better understanding and to conclude rigorous secu- time. We model the security of our system on top of an rity proofs where adding a type to Omniring’s defini- anonymous broadcast peer-to-peer network such as I2P tions may be ambiguous. or libp2p using any consensus algorithm for transaction ordering which prevents information leakage through Definition 1. A Swap Confidential Transaction meta-data. For transaction verification, nodes need ac- (SwapCT) scheme consists of a tuple of PPT algo- cess to the full history of transactions. Verifier: All rithms (Setup, KeyGen, TypeGen, OTGen, Offer, VfOffer, participants verify persisted transactions. In this role Merge, Seal, VfTx, Receive) defined as follows: everyone acts honestly as all their outgoing messages λ α β are verified by the consensus rules. However they try to pp ← Setup(1 , 1 , 1 ) takes the security parameter λ α deanonymize users or reveal transferred amounts and and integers α for a maximum of 2 outputs of a trans- β types. Offerer: A participant creating an offer is mod- action where each has an amount maximum of 2 − 1. eled as malicious as they have incentives to steal or Then it outputs public parameters pp which are implic- create funds. Merger/Exchange: Anyone matching, itly given to all the following algorithms. Setup is called merging and sealing offers into a transaction is mod- once when a SwapCT system is initialized. eled as malicious. Their goals are to deanonymize par- (ltp, lts) ← KeyGen() generates a long term secret key ticipants from their offers or redirect funds in an of- lts with the corresponding long term public key ltp for fer to themselves. When sealing an offer to create a participants to initially join the system. The ltp is dis- transaction, the mergers are trusted to scrub the of- tributed and serves as a recipient address. fers off the plaintext values and types, which were re- ty ← TypeGen(name) generates a type ty given a name. quired to match offers together. Publishing the amounts acc, ck ← OTGen(ltp, a, ty) creates a one-time account and types reduces the anonymity set. Therefore, we re- acc with coin key ck from a long term public key ltp and quire multiple, non-colluding mergers, but each of them an amount a of a type ty to then use this account as an may act maliciously. Knowing a fraction of plaintext output in an offer or a new type registration. amounts and types (the ones merged by the adversary) o ← Offer(S, R, T ) takes the inputs S S S |S| in the graph of many transactions from other mergers S = {(tagi, ji, ski, ai , tyi , cki )}i=1 is a set of inputs with a tag corresponding to accR at index j ∈ [|R |], secret and direct transactions is not sufficient to deanonymize i i,ji i i S S S users. In case of a single merger for the whole SwapCT key ski, amount ai and type tyi with coin key cki . R |Ri| |S| system, this merger acts as a central gateway to the R = {{acci,j}j=1 }i=1 is a set of ring account sets, one ledger and can partially deanonymize the transaction set per input to hide the real account. T T T T |T | T graph and trace the amounts and types of transactions T = {(acci , ai , tyi , cki )}i=1 is a set of accounts acci T T T they have merged. There, the only anonymity set left with amount ai , type tyi and coin key cki . It outputs is the set of direct transactions submitted to the ledger a signature o as authorization to spend the inputs. by users, bypassing the single merger. In summary, the b ← VfOffer(off, o) takes a signature o and an offer anonymity set of offers depends on the ratio of uncom-  S S |S| off(S, R, T ) := {tagi, ai , tyi }i=1, promized transactions persisted on the ledger. (1) R |Ri| |S| T T T T |T |  First, we introduce some general notation. Given a {{acci,j}j=1 }i=1, {acci , ai , tyi , cki }i=1 security parameter λ ∈ N, we denote negl(λ) as negligi- and returns a bit b specifying if the offer is valid. ble in λ, equivalent to 1 . To sample an element x poly(λ) o ← Merge(o , o ) takes two offer signatures and gener- $ 0 1 uniformly at random from the set S, we write x ←− S. ates a combined one o valid for the union of both offers. The set of integers up to n is defined as [n] := {1, . . . , n} t ← Seal(off, o) Takes a valid balanced offer defined as and in general, sets are ordered if not specified other- above and its signature o and outputs a seal proof t. P P wise. For any set S we define S := s∈S s. If an b ← VfTx(tx, t) takes a transaction defined as tx(off) := algorithm fails, it will always abort with ⊥. We write   {tag }|S| , {{accR }|Ri|}|S| , {accT }|T | and the signa- PPT for probabilistic polynomial time complexity. i i=1 i,j j=1 i=1 i i=1 ture t and returns a bit b representing the validity. The security of single-type set anonymous systems (tag, sk, a, ty, ck) ← Receive(acc, lts) gets an account acc is well formalized by Omniring [15]. We extend this for- and a long term secret lts and returns the matching tag, malization to encompass type support and swap trans- secret key sk, amount a, type ty and coin key ck for acc. actions. Parts in blue are very similar to the Omniring Further, we require the following two auxiliary al- description, e.g. only the type added, and are included gorithms to define the security properties. SwapCT 7 b ← ChkAcc(acc, a, ty, ck) takes an account acc, an properties in the presence of offers, types and multiple amount a with type ty and a coin key ck and checks distrusting parties jointly transacting. if they are consistent. The core of any transaction system is to assure that b ← ChkTag(acc, tag, sk) takes an account acc, a tag and no value is created out of thin air. Moreover, for individ- a secret key sk and returns 1 if consistent, 0 otherwise. ual participants, it is of paramount importance, that all outgoing transactions from their wealth are authorized. Definition 2 (Correctness). A SwapCT scheme is cor- The authorization in the case of a single transactor λ α β rect, if for all λ, α, β ∈ N and all pp ∈ Setup(1 , 1 , 1 ): is simple: Signing the transaction with a set of inputs Honestly generated payments are received correctly: For for a final set of outputs. This is not directly applicable any ltp, lts ∈ KeyGen(), any name ∈ (0, 1)∗, ty = to offers that may not have a final output set at the time TypeGen(name), any amount a ∈ {0,..., 2β − 1}, any of authorizing the first inputs. The authorization given 0 (acc, ck) ∈ OTGen(ltp, a,ty), and any (·, a0, ty0, ck ) ∈ to an offer translates to a condition that the signer ac- 0 Receive(acc, lts), it holds that (a, ty, ck) = (a0, ty0, ck ). cepts the spending of the inputs if and only if the speci- Honestly received payments have a valid amount, fied outputs are fulfilled. As offers have to be authorized type and tag: For any (tag, sk, a, ty, ck) ∈ before some untrusted party uses them to seal a transac- Receive(acc, lts),ChkAcc(acc, a, ty, ck) = 1 and tion and without further interaction, the authorization ChkTag(acc, tag, sk) = 1 hold. must be conditioned that all designated outputs are in- Honestly generated offers are valid: For each S, R, T , cluded in the final transaction without modifications. defined as above, that satisfy As long as at least one input authorization, identified – ∀i ∈ [|S|], ChkTag(accR , tag , sk ) = 1 i,ji i i by a tag, is used from an offer, the transaction outputs – ∀i ∈ [|S|], ChkAcc(accR , aS , tyS , ckS ) = 1 i,ji i i i must be a super-set of the original offer outputs. The T T T T – ∀i ∈ [|T |], ChkAcc(acci , ai , tyi , cki ) = 1 tag is anonymously bound to the hidden input. and for any signature o ∈ Offer(S, R, T ), it holds that To achieve theft prevention, we require ChkAcc and VfOffer(off, o) = 1 with off = off(S, R, T ). ChkTag to be binding. Then, if a tag is bound to a source Honestly merged valid offers are again valid: For each account, double-spend detection is reduced to checking pair of valid Sk, Rk, Tk with k ∈ {0, 1}, each ok ∈ for duplicate tags. In addition, the binding property pre- Offer(Sk, Rk, Tk) and o = Merge(o0, o1), it holds that vents opening an account to a different amount or type. VfOffer(off, o) = 1 with off = off(S0∪S1, R0∪R1, T0∪T1). Honestly sealed transactions are valid: For any Definition 3 (Theft). A SwapCT scheme is theft pro- S, R, T as above that satisfies all offer criteria and: tecting, if for any λ ∈ N and all α, β ∈ poly(λ) with α T β pp ← Setup(1λ, 1α, 1β) (1) ChkTag and ChkAcc are bind- – |T | ≤ 2 , ∀i ∈ [|T |]: ai ∈ {0,..., 2 − 1} T |T | ing such that for any adversary A it holds that – ∀ty ∈ {tyi }i=1 : P{aS |tyS = ty}|S| = P{aT |tyT = ty}|T |  i i i=1 i i i=1 ChkTag(acc, sk, tag) = 1 Pr and for any proof t ∈ Seal(off, o) it holds that ChkTag(acc, sk0, tag0) = 1, (sk, tag) 6= (sk0, tag0) VfTx(tx, t) = 1 with off = off(S, R, T ) and tx = tx(off). (acc, sk, tag, sk0, tag0) ← A(pp) ≤ negl(λ) and

 0 0 ty = TypeGen(n), ty = TypeGen(n )

5 Security  ChkAcc(acc, ck, a, ty) = 1 Pr   ChkAcc(acc, ck0, a0, ty0) = 1

To formalize the security of a SwapCT scheme, we bor- (a,n, ck) 6= (a0,n 0, ck0) row components from other RingCT schemes, namely (acc, a,n, ck, a0,n 0, ck0) ← A(pp) ≤ negl(λ) Omniring, as transactions of a SwapCT scheme should have comparable properties to their single type RingCT (2) for all PPT adversaries A and all S, R, T defined counterparts. For the non-slanderability, we make use of as above, it holds that the definitions from Omniring [15], which allows an at- " 0 tacker to make arbitrary transactions through oracles 0 |S | |S| {tagi}i=1 ∩ {tagi}i=1 6= ∅ Pr 0 and who must then output a valid transaction which 0T |T | T |T | 0 0 {acc i }i=1 6⊇ {acci }i=1, VfOffer(off , o ) = 1 uses a tag of the oracle controlled accounts that was not o ← Offer(S, R, T )  previously authorized. Theft prevention and privacy of ≤ negl(λ). (o0, off0) ← A(pp, o, off(S, R, T )) SwapCT require additional constraints to ensure these SwapCT 8

λ α β InitOracles() BalanceA,EA (1 , 1 , 1 ) LTP := LTS := ∅ TryReceive(acc) pp ← Setup(1λ, 1α, 1β ) Offrd := ∅ for all i ∈ [|LTS|] do (tx, t) ← A(pp) (tag, sk, a, ty, ck) ← Receive(acc, LTS[i]) (S, R, T ) ← EA(pp, tx, t) KeyGenO() |S| if (tag, sk, a, ty, ck) 6= ⊥ then  S S S (ltp, lts) ← KeyGen() parse S as tagi, ji, ski, ai , tyi , cki return (tag, sk, a, ty, ck) i=1 LTP := LTPkltp |R| return ⊥  R |Ri | LTS := LTSklts parse R as {acci,j }j=1 i=1 return ltp |T |  T T T T parse T as acci , ai , tyi , cki OfferO(I, T ) i=1 b := VfTx(tx, t), b := tx = tx(S, R, T ) S := ∅ 1 2 R |Ri | |I| R parse I as {ji, {acc } } b3 := ∀i ∈ [|S|], ChkTag(acc , ski, tag ) = 1 i,j j=1 i=1 i,ji i R S S S for all i ∈ [|I|] do b4 := ∀i ∈ [|S|], ChkAcc(acc , a , ty , ck ) = 1 i,ji i i i R Si := (tagi, ski, ai, tyi, cki) := TryReceive(acc ) b := ∀i ∈ [|T |], ChkAcc(accT , aT , tyT , ckT ) = 1 i,ji 5 i i i i // Check that the same tag was not used with another ring T |T | S S |S| T T |T | P P R |R | b6 := ∀ty ∈ {tyi }i=1 : {ai |tyi = ty}i=1 = {ai |tyi = ty}i=1 i if (tagi, ·) ∈ Offrd ∧ (tagi, {acci,j }j=1 ) 6∈ Offrd then return ⊥ return b1 ∧ b2 ∧ ¬(b3 ∧ b4 ∧ b5 ∧ b6) R |Ri | |I| R = {{acci,j }j=1 }i=1, off = off(S, R, T ), o ← Offer(S, R, T ) if VfOffer(off, o) = 0 then return ⊥ Offrd := Offrd ∪ {(tag , {accR }|Ri |)}|I| Fig. 3. Balance experiment i i,j j=1 i=1 return o

To prevent users from spending more value than they Fig. 4. Oracles for the privacy experiments have as input or spending the same value twice, increas- ing the total supply, a transaction must be balanced. 6 Privacy Our balance property only differs from a type unaware RingCT system in the fact that the balance has to hold The privacy of a SwapCT scheme consists of two for each type individually. different settings. Offers require sender and receiver To achieve the balance property, we rely on theft anonymity, while for sealed transactions the regular prevention, as a prerequisite. The balance experiment RingCT privacy must hold, which consists of sender and in Figure 3 states, that for any efficient adversary A receiver anonymity as well as value confidentiality. To which generates a valid transaction tx, t, there exists provide value confidentiality in a SwapCT, we have to an extractor E which extracts the witness S, R, T of A extend the RingCT model by also hiding the type. this transaction. The witness must satisfy that the tags The transaction creation process may be distributed match the inputs accR . In addition, the amounts and i,ji and offers are passed to possibly malicious parties. types must match the input and output accounts with Therefore, we require sender and receiver anonymity ChkAcc. Unlike single type transaction systems, we ad- for offers, too. Value and type confidentiality are not ditionally require that each output type is present in the desired for offers, as other parties must be able to ac- input. Then, the sum of amounts in the inputs must be cess the offered assets and decide if they want to merge equal to the sum of outputs per type. the offer. To ensure that swap transactions are indis- Assume an efficient adversary creating a valid trans- tinguishable from single-user transactions, the number action signature for an unbalanced transaction. The sig- of offers merged together must remain hidden, making nature ensures balance and thereby the adversary can merged offers appear identical to single transaction. be used to create an efficient adversary against one of Sender and receiver anonymity is defined by an ad- the binding properties. This means being able to spend versary interacting with a set of oracles and then pre- the same account under a different tag or change the senting a maliciously crafted offer together with instruc- amount or type. tions for the security experiment on how to construct Definition 4 (Balance). A SwapCT scheme is bal- two sets of offers. The instructions contain input ring anced if it prevents theft (Def. 3) and for all accounts with two possible senders and recipients to- PPT adversaries A and all positive integers α, β ∈ gether with amounts and types. In addition, they con- tain an identifier of the party which should use the input poly(λ), there exists a PPT extractor EA such that λ α β or output, thereby showing that the offers do not reveal Pr[BalanceA,EA (1 , 1 , 1 ) = 1] ≤ negl(λ) with λ α β the participants. The adversary should not be able to BalanceA,EA (1 , 1 , 1 ) defined in Figure 3. distinguish which set of offers is created and merged. More formally, we specified a security experiment OffPvb in Figure 5 with a bit b ∈ {0, 1}. An adversary A queries the available oracles (Figure 4) and then returns a valid offer (off, o) and instructions I and J. I contains S 1 R |Ri| |I| S {({ut,i, jt,i}t=0, {acci,j}j=1 )}i=1 where ub,i is the iden- SwapCT 9

b λ α β b λ α β OffPvA(1 , 1 , 1 ) TxPvA(1 , 1 , 1 ) pp ← Setup(1λ, 1α, 1β ), InitOracles() pp ← Setup(1λ, 1α, 1β ), InitOracles() O = {KeyGenO, OfferO} O = {KeyGenO, OfferO} (I, J, off, o) ← AO(pp) (I, J, off, σ) ← AO(pp) o0 := o1 := o, off0 := off1 := off, S0 := S1 := T0 := T1 := ∅ S0 := T0 := S1 := T1 := R := ∅ if VfOffer(off, o) = 0 then return 0 1 R |Ri | |I| parse I as {({jt,i}t=0, {acci,j }j=1 )}i=1 S 1 R |Ri | |I| parse I as {({(ut,i, jt,i)}t=0, {acci,j }j=1 )}i=1 for all i ∈ [|I|] do for all i ∈ [|I|] do for all t ∈ {0, 1} do S S S S R for all t ∈ {0, 1} do (tagt,i, skt,i, at,i, tyt,i, ckt,i) := TryReceive(acct,j ) S S S S R t,i (tagt,i, skt,i, at,i, tyt,i, ckt,i) := TryReceive(acci,j ) S S S S t,i St[i] = (tagt,i, jt,i, skt,i, at,i, tyt,i, ckt,i) S S S S |R | St[i] = (tagt,i, jt,i, skt,i, at,i, tyt,i, ckt,i) R i R[i] = {acci,j }j=1 R |Ri | if tagt,i ∈ Offrd ∧ (tagt,i, {acci,j }j=1 ) 6∈ Offrd then return 0 1 if tag0,i 6= tag1,i ∧ {(tagt,i, ·)}t=0 ∩ Offrd 6= ∅ then return 0 |J| if a0,i 6= a1,i ∨ ty0,i 6= ty1,i then return 0 T T T 1 parse J as {{(kt,j , at,j , tyt,j )}t=0}j=1 T T 1 T T |J| parse J as {({(ut,i, kt,i)}t=0, ai , tyi )}i=1 for all j ∈ [|J|] do for all j ∈ [|J|] do for all t ∈ {0, 1} do T T T T T for all t ∈ {0, 1} do (acct,j , ckt,j ) := OTGen(LTP[kt,j ], at,j , tyt,j ) T T T T T T T T (acct,j , ckt,j ) ← OTGen(LTP[kt,j ], aj , tyj ) Tt[j] := (acct,j , at,j , tyt,j , ckt,j ) T [j] = (accT , aT , tyT , ckT ) t t,j j j t,j for all t ∈ {0, 1} do for all t ∈ {0, 1} do ot ← Merge(o, Offer(St, R, Tt)) |I| |J| UI := {uS } , UJ := {uT } offt := off(St, R, Tt) ∪ off t t,i i=1 t t,j j=1 tx := tx(off ) if UI 6= UJ then return 0 t t t t tt ← Seal(offt, ot) I for all k ∈ Ut do if VfOffer(offt, ot) = 0 ∨ VfTx(txt, tt) = 0 then return 0 |I| k S 0 O 0 St := {St[i]|ut,i = k}i=1 b ← A (txb, tb) return b k |R| S |I| Rt := {{acci,j }j=1|ut,i = k}i=1 T k := {T [j]|uT = k}|J| t t t,i j=1 Fig. 6. Transaction privacy experiment k k k k offt ← off(St , Rt , Tt ) k k k k ot ← Offer(St , Rt , Tt ) if VfOffer(offk , ok ) = 0 then return 0 b t t offers and authorizes each of them. All offers offk, along k k k offt := offt ∪ off(St , Rt , Tt ) k with the malicious off are merged. The adversary wins ot ← Merge(ot, ot ) 0 0 b ← AO(offb, ob) return b by correctly guessing the bit b.

Fig. 5. Offer privacy experiment Definition 5 (Offer Privacy). A SwapCT scheme has private swaps, if for all PPT adversaries A tifier of the party who should use input i depending and all positive integers α, β ∈ poly(λ) it holds that on the selected bit b. The set of all input identifiers 0 λ α β 1 λ α β S |I| I Pr[OffPvA(1 , 1 , 1 ) = 1] − Pr[OffPvA(1 , 1 , 1 ) = 1] {u } form the unordered set Ut for t ∈ {0, 1}. jt,i t,i i=1 ≤ negl(λ) with OffPvb (1λ, 1α, 1β) defined in Figure 5. R |Ri| A specifies the index in the set of ring accounts {acci,j}j=1 S S S on which the experiment calls (tagt,i, at,i, tyt,i, skt,i) ← The privacy of a sealed transaction extends the offer TryReceive(accR ) to recover the account secrets. Some S T i,jt,i privacy as follows. As the amounts ai , ai and types trivial cases which are easy to distinguish are excluded. S T tyi , tyi of an offer are discarded in the seal operation, An efficient adversary exists, if the amount and type of the requirement on the instructions from the adversary the two ring accounts may be different, as these values to have equal amounts and types are lifted. Accord- will be published in the merged offer. Therefore, we re- ing to Definition 5, the number of transactors is hid- S S S S quire a0,i = a1,i and ty0,i = ty1,i for all i. We also abort den. Thereby, it is sufficient to show the case where the if one of the tags was already disclosed in another offer: adversary provides instructions to just one party. The (tagt,i, ·) 6∈ Offrd. This implies, that when a participant security experiment in Figure 6 then seals the merged decides to create multiple offers with the identical in- transaction at the end. put, it is important to the sender anonymity, that the input uses the same ring in each offer as otherwise, the Definition 6 (Transaction Privacy). A SwapCT real sender is an account of the intersection of all rings. has private transactions, if the participants are The output instructions J are similar to I, as they able to share messages by an anonymous broad- T T 1 T T |J| T contain {({ut,i, kt,i}t=0, ai , tyi )}i=1 where ut,i specifies cast, and if for all PPT adversaries A and all the party to use this output and all output identifiers positive integers α, β ∈ poly(λ) it holds that J I 0 λ α β 1 λ α β form the unordered set Ut , equal to Ut . The element Pr[TxPvA(1 , 1 , 1 ) = 1] − Pr[TxPvA(1 , 1 , 1 ) = 1] b λ α β kt,i references an uncompromized long term public key ≤ negl(λ) with TxPvA(1 , 1 , 1 ) defined in Figure 6. T LTP[kt,i] from which a one-time account acct,j is derived. T T As the amounts ai and types tyi of an offer are public, they are equivalent in both values of b. The experiment proceeds by distributing the inputs and outputs to each I J identifier in the set Ut = Ut = Ut , then creates a set of SwapCT 10

7 SwapCT Components σ ← SoK[L]Sim(stmt, m)) for any NP language L. They fulfill the properties completeness, simulatability and extractability according to [5]. Our construction of a SwapCT system as defined We require a protocol to anonymously authorize above depends on the following six components. (1) spending from a set of ring accounts {(pk , com )}|R| We make use of the Omniring tagging scheme [15] for i i i=1 without revealing the true source (pk , com ) and pre- double-spend detection, which consists of the algorithms j j vent double-spending. Especially the creator of the au- TAG = (TagSetup, TagKGen, TagEval). It uses a se- thorization does not necessarily know the secret keys of cret key space (χ, +), a public key space (X , ·) and all the ring accounts nor interacts with the parties hold- a tag space ψ. TagKGen is homomorphic, i.e. for any ing the secret keys. A ring signature solves exactly this x, x0 ∈ χ, TagKGen(x) · TagKGen(x0) = TagKGen(x + x0). problem to sign a message without revealing the true TagEval takes a key x ∈ χ and outputs a tag ∈ X . secret key sk used. In addition, we require linkability if We require related-input one-wayness and pseudoran- the same secret key and thereby the same account was domness as defined in Omniring. (2) Further we make used in two different ring signatures. This is achieved use of a labeled public-key encryption scheme PKE = by publishing a tag which is anonymously bound to the (PKESetup, PKGen, Enc, Dec) which is IND-CCA and IK- public key pk . If two signatures have the same tag, they CCA secure. (3) We base a typed homomorphic commit- j were created by the same secret key. This is known as ment on the idea of confidential assets [17] to hide values a tagged ring signature scheme TRS, similar to the ML- and types. It provides the algorithms THC =(ComSetup, SAG scheme in Monero [1]. The TRS is parameterized ComTypeGen, Commit) defined as with a tagging scheme TAG and a typed homomorphic pp ← ComSetup(1λ) generates the public parameters for commitment scheme THC. We define this in the form of the rest of the algorithms with a randomness space , R a SoK parameterized with the following language Lring a type space T and message space M. ∗ ty = ComTypeGen(i) takes an identifier i ∈ {0, 1} and  |R| 0 stmt = ({(pki, comi)}i=1, tag, com ): outputs a base type ty ∈  T ∃wit = (j, sk, a, ty, ck, ck0) s.t. com = Commit(ty, v; r) takes a type ty ∈ T and a := pk = TagKGen(sk), com = Commit(ty, a; ck) value v ∈ M with randomness r ∈ R and outputs a  j j  0 commitment com. We require the following homomor-  tag = TagEval(sk), com0 = Commit(ty, a; ck ) phic property, that Commit(ty, v; r) Commit(ty, v0; r0) = 0 Thereby, we assure that the signer knows at least one Commit(ty, v + v ; s) with s ∈ R efficiently computable. secret key sk of the ring accounts, and the tag matches The security requirements to a typed homomorphic this account j. The TRS also shows that a commitment commitment are similar to Pedersen commitments and com0 commits to a type ty and amount a, which is the we therefore require binding and hiding properties, de- same as the amount and type in com , referenced by tag tailed in Appendix A. (4) We define a Tagged Ring Sig- j but has a different coin key ck0 to hide the link to com . nature as a Signature of Knowledge (SoK) to anony- j From Lring, we see that given a binding THC scheme mously authorize spending. (5) We define a Seal signa- and a secure TAG scheme, the SoK ring signature is set ture to confidentially prove the balance of an offer, and anonymous and assures equal values in com and com0. (6) we specify an anonymously aggregatable signature j The seal signature is a SoK convincing a verifier scheme, which is parameterized with the tagged ring in zero knowledge that an offer is balanced. Given a signature and binds outputs to authorized inputs. 0 |S| set of temporary commitments {comi}i=1 and a set of |T | output commitments {comj}j=1, a valid signature con- 7.1 Signatures of Knowledge vinces an honest verifier, that for each type ty present in T |T | the transaction outputs {tyj }j=1 the sum of amounts P S S |S| For a generalized description of the tagged ring signa- in the inputs {ai |tyi = ty}i=1 is equal to the sum of P T T |T | ture and the seal signature, we use signatures of knowl- amounts in the outputs {ai |tyi = ty}i=1. We specify edge (SoK) which are efficiently constructable from ar- guments of knowledge (AoK) [5, 15] by including a message in the Fiat-Shamir transformation [11]. They consist of the algorithms pp ← SoK[L]Setup, σ ← SoK[L]Sign(stmt, wit, m), b ← SoK[L]Verify(σ, stmt, m), SwapCT 11

seal |S| |S| |T | the seal signature with the following language L ({ri}i=1, a) ← AsSign({(stmti, witi)}i=1, {mj}j=1) takes  |S| |T | |S| 0 T a set of statement and witness tuples {(stmti, witi)} stmt = ({comi}i=1, {comj }j=1): i=1  |T |  0 |S| T |T |  S S T T and a set of messages {mj}j=1 and outputs a set of ∃wit = ({tyi , ai , cki}i=1, {tyj , aj , ckj }j=1) s.t.  |S|  0 ∀i ∈ [|S|]: com0 = Commit(tyS , aS ; ck ) signatures {ri}i=1 and a proof a. := i i i i |S| |T | T T T T b ← AsVerify({(ri, stmti)}i=1, a, {mj}j=1) takes the sig- ∀j ∈ [|T |]: com = Commit(ty , a ; ckj )  j j j natures r and statements stmt , a proof a and the mes-  T |T | i i ∀ty ∈ {tyj }j=1 : |T |  sages {mj}j=1 and outputs a bit b depending on the  P S S |S| P T T |T | {ai |tyi = ty}i=1 = {ai |tyi = ty}i=1 validity of the signatures and the proof. a ← AsMerge(a , a ) takes two proofs a , a and outputs From Lseal, we see that with a binding THC scheme, the 1 2 1 2 a combined proof a. SoK signature is secure and assures the balance of two ({r }|S| , a) ← AsSim({stmt }|S| , {m }|T | ) takes state- sets of commitments. i i=1 i i=1 j j=1 ments stmti and messages mj and outputs a set of sim- |S| ulated signatures {ri}i=1 and a simulated proof a. 7.2 Aggregatable Anonymous Signature Definition 7 (Correctness). (1) For all (stmti, witi) ∈ ∗ |T | |S| To create offers independently and merge multiple offers RL and all messages {mj ∈ {0, 1} }j=1 with ({ri}i=1, a) |S| |T | into a transaction, we require a high level of privacy such ← AsSign({(stmti, witi)}i=1, {mj}j=1) it holds, that that the final transaction does not leak the individual |S| |T | AsVerify({(ri, stmti)}i=1, a, {mj}j=1) = 1 (2) Regard- parties’ inputs. However, we also require an authoriza- ing merging with t ∈ {1, 2}, for any (stmtt,i, witt,i) ∈ tion, such that signatures of offers cannot be abused to ∗ |Tt| RL and all messages Mt := {mt,j ∈ {0, 1} }j=1 authorize spending of the tokens to different recipients. |St| |St| with ({rt,i} , at) ← AsSign({stmtt,i, witt,i} ,Mt) Without the privacy requirement, a solution to i=1 i=1 and a ← AsMerge(a1, a2) it holds that achieve authorization of inputs spending to a fixed set S |St| S AsVerify( {(rt,i, stmtt,i)} , a, Mt) = 1 of outputs is simple. Each authorization signature signs t∈{1,2} i=1 t∈{1,2} a message that is the subset of outputs required to be The formal security describing that each signature per- in the final transaction. On verification, the signature is manently binds a subset of messages is done by refor- invalid, if an output is missing or changed. However, this mulating the problem more rigorously. If a SoK ri is reveals the mapping between the signers and outputs. reused, then the new set of messages must be a superset The generalized problem is a set of signers, each of the signed messages, such that all previously signed |T | with a set of messages {mj}j=1 (representing trans- messages are included. action outputs) and a set of statements and witnesses |S| {(stmti, witi)}i=1 for a SoK (representing authorization Definition 8 (Security). Given a secure SoK scheme, signatures on inputs). Each of the signers create sig- an aggregatable signature scheme AS is secure, if |S| natures {ri}i=1 which bind the messages to the given for all PPT adversaries A, all statements and signatures. However, linking signatures to specific mes- |S| witnesses {(stmti, witi) ∈ RL}i=1 and all mes- sages must be infeasible. Verification must only succeed ∗ |T | |S| sages {mj ∈ {0, 1} }j=1 with ({ri}i=1, a) ← on the full set of all signatures and messages. |S| |T | AsSign({(stmti, witi)} , {mj} ) it must hold, that As the aggregation is agnostic to the signature i=1 j=1 0 scheme, we describe it with the notation of a SoK as " 0 |S | |S| 0 {ri}i=1 ∩ {ri}i=1 6= ∅, T 6⊇ T defined above. An independent use-case are e.g. authors Pr 0 0 AsVerify({(r0 , stmt0 )}|S |, a0, {m0 }|T |) = 1 each writing and signing a chapter. They may then later i i i=1 j j=1 λ  claim to have participated in the whole book without pp ← AsSetup(1 ) 0 0 ({(r0 , stmt0 )}|S |, a0, {m0 }|T |))  ≤ negl(λ) revealing which part of it they wrote and signed. i i i=1 j j=1  An aggregatable signature scheme consists of |S| |T | ← A({(ri, stmti)}i=1, a, {mj}j=1) AS = (AsSetup, AsSign, AsVerify, AsMerge, AsSim) parametrized with an NP Language L and its relation To show that the scheme does not reveal the witness,

RL. we require that an efficient simulator exists to produce pp ← AsSetup(1λ, L) takes the security parameter λ and an indistinguishable transcript without the witness. the language L which parametrizes the SoK and outputs the public parameters pp. SwapCT 12

b λ ring accounts and a tagged ring signature assures that ASPrivacyA(1 ) pp ← AsSetup(1λ) the published tag belongs to the account from which (I, J, Σ, STMT, M, a) ← A(pp) Σ0 := Σ1 := Σ, M0 := M1 = M, a0 := a1 := a the amount and type is spent. To decouple the sender |Σ| |Σ| parse Σ as {ri}i=1 and STMT as {stmti}i=1 |Σ| |M| anonymity set from the remainder of the transaction, we if AsVerify({(ri, stmti)}i=1, a, {mi}i=1 ) = 0 then return 0 S 1 |I| create an intermediate, randomized commitment with a parse I as {({ut,i}t=0, stmti, witi)}i=1 T 1 |J| parse J as {({ut,i}t=0, mi)}i=1 copy of the input values. Output accounts are derived for all t ∈ {0, 1} do I S |I| J T |J| from the recipients long term public key. To combine Ut := {ut,i}i=1, Ut = {ut,j }j=1 I J if Ut 6= Ut then return 0 inputs with outputs, we use our anonymously aggregat- I for all k ∈ Ut do k S |I| able signature scheme which enables the simple merging STMTt := {stmti|ut,i = k}i=1 k S |I| of offers. Finally, an offer is sealed by the seal signature WITt := {(stmti, witi)|ut,i = k}i=1 k T |J| Mt := {mi|ut,i = k}i=1 to become a verifiable transaction to be persisted. (Σk , ak ) ← AsSign(WITk , Mk ) t t t t For a detailed description, let χ be the key space of // % zips: |A| = |B| and A%B := {(a1, b1),..., (a|A|, b|B|)} k k k k ∗ if AsVerify(Σt %STMTt , at , Mt ) = 0 then return 0 TAG and the THC randomness space. Let h : {0, 1} → k k k R Mt := Mt ∪ Mt , Σt := Σt ∪ Σt , at ← Merge(at, at ) 0 0 χ be a random oracle. Setup generates the public param- b ← A(Σb, ab) return b eters of each component by calling their setup functions. Fig. 7. AS privacy experiment To participate, each entity generates a long term key (ltp, lts) with KeyGen that consists of two key pairs Definition 9 (Simulatability). AS is simulatable if of the PKE scheme: (vpk, vsk) is used for access to re- ( ) ceived amounts and (apk, ask) is used to recover the au- pp ← AsSetup(1λ, L) x thorization key to spend the received funds. The long |S| |T | ¯ ¯ x ← AsSign({(stmti, witi)}i=1, {mj}j=1) term credentials further include a key pair (sk, pk) from ( ) the TAG to later calculate tags for each derived account. pp ← AsSetup(1λ, L) = x The different token types available in a SwapCT x ← AsSim({stmt }|S| , {m }|T | ) i i=1 j j=1 system are not specified a priori but are dynamically The privacy of the AS scheme is expressed by the se- added. A new type ty is generated by specifying a new curity experiment in Figure 7 similarly to the privacy unique name and using ComTypeGen of the commitment of the SwapCT offer privacy. The mapping of inputs to scheme as described in TypeGen. The mere specification outputs and the number of participants must remain of a type ty is not sufficient to introduce the new type hidden. An Adversary A generates a valid set of sig- into circulation. To allow trading with this new type, a natures Σ, statements STMT and messages M and pro- new account acc is derived from a long term public key vides instructions I,J for the experiment to append sig- ltp by OTGen. The acc is piggybacked onto a regular natures and messages. For two cases of the parameter transaction to pay the registration fee. The matching lts is then allowed to spend the newly minted tokens of b ∈ {0, 1}, the adversary A specifies which party k ∈ Ut S type ty. The uniqueness of the name in such a type reg- gets access to the witnesses witi|ut,i = k and messages T istration must be ensured by the consensus mechanism. mi|ut,i = k. A wins by calculating b correctly. The one-time account generation is used in subse- Definition 10 (Privacy). An AS scheme is pri- quent transactions to specify the outputs. OTGen gener- vate, if for all PPT adversaries A it holds that ates a random ephemeral key ek and uses it to generate 0 λ 1 λ a public key pk for which only the recipient can recover Pr[ASPrivacyA(1 ) = 1] − Pr[ASPrivacyA(1 ) = 1] ≤ b λ the secret key sk.A THC com is created to the amount a negl(λ) with ASPrivacyA(1 ) defined in Figure 7. and type ty with a random coin key ck ∈ R. Finally, the secret values ek, ty, a, ck are encrypted under the recipi- ent’s keys apk, vpk to be decrypted with ask, vsk recover- 8 SwapCT Construction ing the tokens. The structure of the one-time accounts is very similar to the Omniring construction apart from With all the components specified in the previous sec- using a typed homomorphic commitment. tion, the SwapCT construction Ξ is the interaction of The owner of the long term secret key lts is able to the algorithms shown in Figure 8. Intuitively, we create receive an account acc by Receive. This is again similar to accounts with the public key of the tagging scheme and Omniring with the exception of a different commitment. store the amount and type in a commitment. For each First the recipient decrypts the ciphertexts ek˜ , ck˜ with input of an offer, the real account is hidden in a set of the labeled encryption scheme to get ek, the amount a, SwapCT 13

Setup(1λ, 1α, 1β) Offer(S, R, T ) pp ← ComSetup(1λ) OTGen(ltp, a, ty) S S S |S| THC parse S as {(tagi, ji, ski, ai , tyi , cki )}i=1 λ parse ltp as (vpk, apk, pk¯ ) |R | |S| ppPKE ← PKESetup(1 ) R R R i parse R as {{acci,j := (pki,j , comi,j , ·)}j=1 }i=1 λ $ λ ppTAG ← TagSetup(1 ) ek ←−{0, 1} T T T T |T | λ ring parse T as {(acci , ai , tyi , cki )}i=1 ppAS ← AsSetup(1 , L ) $ ck ←− $ pp ← SoK[Lseal]Setup(1λ, 1α, 1β , pp ) R {ck0 ←− , com0 ← Commit(tyS , aS ; ck0 )}|S| seal THC s := h(ltp, ek) i R i i i i i=1 pp := (pp , pp , pp , pp , pp ) THC PKE TAG AS seal pk := pk¯ · TagKGen(s) {stmt = {(pkR , comR )}|Ri |, tag , com0
}|S| return pp i i,j i,j j=1 i i i=1 com := Commit(ty, a; ck) {wit = (j , sk , aS , tyS , ckS , ck0 )}|S| KeyGen() ek˜ ← Enc(apk, (pk, com), ek) i i i i i i i i=1 ck˜ ← Enc(vpk, (pk, com), (ty, a, ck)) |S| |S| T |T | (vpk, vsk) ← KeyGen(ppPKE) ({ri}i=1, a) ← AsSignSoK[Lring ]({(stmti, witi)}i=1, {accj }j=1) acc = (pk, com, ek˜ , ck˜ ) (apk, ask) ← KeyGen(ppPKE) 0 0 |S| return ({ri, com , ck } , a) $ return (acc, ck) i i i=1 sk¯ := x ←− χ, pk¯ := X ← TagKGen(x) ltp := (vpk, apk, pk¯ ) Receive(acc, lts) Merge(o1, o2) lts := (vsk, ask, sk¯ ) ˜ ˜ 1 01 01 |S1 | parse acc as (pk, com, ek, ck) parse o1 as ({(ri , com i , ck i )}i=1 , a1) return (ltp, lts) parse lts as (vsk, ask, sk¯ ) 2 02 02 |S2 | parse o2 as ({(r , com , ck )} , a2) ek = Dec(ask, (pk, com), ek˜ ) i i i i=1 TypeGen(name) a ← AsMerge(a1, a2) (ty, a, ck) = Dec(vsk, (pk, com), ck˜ ) |S | |S | ty := ComTypeGen(name) return ty return ({(r1, com01, ck01)} 1 ∪ {(r2, com02, ck02)} 2 , a) s := h(ltp, ek) i i i i=1 i i i i=1 ChkAcc(acc, ck, a, ty) sk := sk¯ + s o 0 Seal(off, ) ˜ ˜ pk = TagKGen(sk) if VfOffer(off, o) 6= 1 then return ⊥ parse acc as (pk, com, ek, ck) com0 = Commit(ty, a; ck)) return com = Commit(ty, a; ck) if (pk, com) 6= (pk0, com0) then tx = tx(off) parse o as ({r , com0 , ck0 }|S| , a) and off as (S, R, T ) ChkTag(acc, sk, tag) return ⊥ i i i i=1 tag ← TagEval(sk) s ← SoK[Lseal]Sign(stmt(tx), wit(S, {com0 , ck0 }|S| , T ), tx) parse acc as (pk, com, ek˜ , ck˜ ) i i i=1 return (tag, sk, a, ty, ck) 0 |S| return tag = TagEval(sk)∧ return t = (s, {ri, comi}i=1, a) pk = TagKGen(sk) VfOffer(off, o) VfTx(tx, t) |S| R |Ri | |S| T T T T |T |
parse off as {tagi}i=1, {{acci,j }j=1 }i=1, {acci , ai , tyi , cki }i=1 parse tx as {tag }|S| , {{accR }|Ri |}|S| , {accT }|T |
T T ˜ ˜ 0 0 |S| i i=1 i,j j=1 i=1 i i=1 parse acc as (pki, com , ek, ck) and o as ({ri, com , ck } , a) i i i i i=1 R R R for all i ∈ [|S|] do parse acci,j as (pki,j , comi,j , ·) 0 0 if com 6= Commit(ty , ai; ck ) then return ⊥ T T i i i parse acci as (pki, comi , ·) |R | R R i 0 0 |S| stmti := ({(pk , com )} , tagi, com ) i,j i,j j=1 i parse t as (s, {ri, comi}i=1, a) R R |Ri | 0 for all j ∈ [|T |] do ∀i ∈ [|S|]: stmti := ({(pk , com )} , tag , com ) T T T T i,j i,j j=1 i i if com 6= Commit(ty , a ; ck ) then return ⊥ α j j j j b0 := |T | < 2 |S| T |T | |S| |T | return AsVerify ring ({(r , stmt )} , a, {acc } ) T SoK[L ] i i j ring i=1 j=1 b1 := AsVerifySoK[L ]({(ri, stmti)}i=1, a, {accj }j=1) seal b2 := SoK[L ]Verify(s, stmt(tx), tx)) return b := b0 ∧ b1 ∧ b2

Fig. 8. SwapCT Construction

0 |S| T |T | type ty and ck and then derives the tag for this account stmt(tx) := ({comi}i=1, {comj }j=1) containing the from the tagging scheme. relevant intermediate commitments com0 and output With all accounts set up, Offer ensures sender commitments comT . The matching witness is the 0 0 0 |S| anonymity by creating a temporary commitment comi set of committed values: wit(S, {comi, cki}i=1, T ) = for each input i ∈ [|S|] with fresh randomness ck0 ∈ . S S S |S| T T T |T | i R ({tyi , ai , cki }i=1, {tyj , aj , ckj }j=1). The seal algo- It then calls the aggregatable signature scheme param- rithm operates on the temporary commitments com0 eterized with the tagged ring signature language Lring. and keeps the real sender hidden in the set of ring ac- The SoK for TRS requires the temporary commitment counts. The TRS ensures that com0 commits to the same 0 comi as well as the ring accounts as statement, which type and value as the real input. The seal signature t is the input for the AsSign function. The transaction then contains the SoK signature s and all parts of the T 0 output accounts acci are used as messages. An offer offer signature o, without the temporary coin keys ck . then consists of off(S, R, T ), defined in Eq (1), and Many public ledgers use financial incentives. We 0 0 |S| o = ({ri, comi, cki}i=1, a). suggest using a common native type for all incentives With the underlying aggregatable signature scheme (transactions fees and mining rewards) as it is equally AS, merging offers o1, o2 with Merge directly translates valued by every participant. A block reward is generated to merging aggregatable signatures a , a . The offers 1 2 by (accreward, ck) ← OTGen(ltpminer, areward, tynative) 0 along with the temporary commitments com and autho- and accreward is included in the block. A transaction rization signatures r are combined by using their union. fee is handled by generating a commitment comfee = Offers are verifiable by VfOffer which checks that the Commit(tynative, afee, r) and appending it to the trans- 0 T commitments com , com agree with the opened values action with the plaintext values afee, r. A verifier checks aS , tyS , aT , tyT and verifies o with AsVerify. the commitment and then appends it to the Lseal state- Once an offer is balanced and valid, it can be T |T | ment of output commitments {comj }j=1 ∪ {comfee}. sealed. Seal uses a SoK with the seal language Lseal This assures that the inputs provide enough tokens in with a message of tx = tx(off) and a statement SwapCT 14 the native type to satisfy all regular outputs and the fee. |S| |T | AsSign({(stmti, witi)}i=1, {mj}j=1) In a swap, offers may include a small surplus of native $ |T | ~s,~r ←− Zq ,C := D := ∅ tokens not claimed by any output. The merger creates for all j ∈ [|T |] do sj rj Cj = G H a single commitment to the sum of surplus from each T ped πj ← SoK[L ]Sign(stmt := Cj , wit := (sj , rj ), mj ) offer and proceeds as explained above. Exchanges may hj = h(mj ||Cj ) $ |S|−1 P|T | P|S|−1 ~x ←− , x|S| := (hj + sj ) − xi request operation fees. Therefore they accept only of- Zq j=1 i=1 for all i ∈ [|S|] do fers which have the requested surplus to be claimed on xi S com Di := G , πi ← SoK[L ]Sign(stmt := Di, wit := (xi), 42) merging in a regular output to the exchange. Regarding ri ← SoK[L]Sign(stmti, witi,Di) S |S| T |T | P|T | a := ({(π ,Di)} , {(π ,Cj )} , rj ) i i=1 j j=1 j=1 transaction size, this requires one additional input and |S| return ({ri} , a) output for each merged transaction by the exchange. i=1 AsVerify({(r , stmt )}|S| , a, {m }|T | ) A transaction is verified with VfTx which proceeds i i i=1 j j=1 S |S| T |T | parse a as ({(πi ,Di)}i=1, {(πj ,Cj )}j=1, r) similarly to VfOffer except that it does not verify the Γ := H−r , ∆ = I 0 T for all j ∈ [|T |] do openings of the commitments comi and comj but only ped T if SoK[L ]Verify(stmt := Cj , πj , mj ) = 0 then return 0 h(mj ||Cj ) the aggregatable signature a. Instead, the commitments Γ := ΓCj G for all i ∈ [|S|] do are checked by verifying the seal signature s. ChkAcc and com S if SoK[L ]Verify(stmt := Di, πi , 42) = 0 then return 0 ChkTag verify the consistency of the inputs by verifying if SoK[L]Verify(ri, stmti,Di) = 0 then return 0

∆ := ∆Di the THC and TAG schemes. return b := Γ = ∆ The construction is correct and adheres to the fol- AsMerge(a1, a2) parse a as ({(πS ,D )}|S1 |, {(πT ,C )}|T1 | , r ) lowing security properties. The proofs thereof are pre- 1 i,1 i,1 i=1 j,1 j,1 j=1 1 parse a as ({(πS ,D )}|S2 |, {(πT ,C )}|T2 | , r ) sented in Appendix B. 2 i,2 i,2 i=1 j,2 j,2 j=1 2 S |S1 | S |S2 | a = ({(πi,1,Di,1)}i=1 ∪ {(πi,2,Di,2)}i=1 , T |T1 | T |T2 | {(π ,Cj,1)} ∪ {(π ,Cj,2)} , r1 + r2) return a Theorem 1 (Non Slanderability). If AS is extractable j,1 j=1 j,2 j=1 and simulatable, TAG is related-input one-way, and h is Fig. 9. Instantiation of AS modeled as a random oracle, then the construction Ξ is non-slanderable. Theorem 2 (Theft Prevention). If THC is binding and outputs). We, therefore, present a novel aggregatable AS is secure and Ξ is non-slanderable, it prevents theft. signature scheme AS which allows the non-interactive Theorem 3 (Balance). If THC is binding and merging of offers, as related aggregatable signature SoK[Lseal] is extractable and Ξ is non-slanderable the schemes [3, 7] are not applicable in our setting. construction is balanced. Regarding privacy, our AS provides anonymity of Theorem 4 (Offer Privacy). If THC is hiding and the mapping between individual messages and signa- binding, PKE is IND-CCA secure and key-private, AS is tures. Regarding security, tampering of messages is de- simulatable and private, and TAG is related-input pseudo tected by verifying the full set of messages and signa- random, Ξ has offer privacy. tures as a whole. The important feature which results Theorem 5 (Transaction Privacy). If Ξ has offer pri- from these properties is the possibility for multiple par- vacy and SoK[Lseal] is simulatable, the construction Ξ ties to generate such signatures which are later com- has transaction privacy. bined into a single signature valid for the union of sig- natures and messages. The aggregated signature is in- distinguishable from one created by a single party. 9 Component Instantiation We achieve this balance by introducing randomness in the form of commitments and then revealing just enough of this randomness such that verification is fea- In this section, we provide the instantiation for our ag- sible. Let G = ( , q, G, H) be a cyclic group of prime gregatable anonymous signature scheme. For detailed G G order q with generators G and H where the discrete log examples of instantiations of the tagging scheme and assumption holds. Further, we require a hash function the labeled public-key encryption scheme, we refer to h : {0, 1}∗ → which could be implemented using a the Omniring paper [15]. The instantiation of the other Zq random oracle. These, along with the language of the components are presented in Appendix A. actual SoK (Lring in our case) are returned as public The main challenge of non-interactive privacy- parameters by AsSetup. preserving swap transactions is to decouple authoriza- Signing (Figure 9) Using the messages m directly as tion signatures from the signed messages (spending j messages in SoK[L]Sign reveals the link between SoK SwapCT 15

T S signatures and messages since the correct message is mitments Cj,Di with their SoK signatures πj , πi , the required for verification. Therefore, a Pedersen commit- SoK[L] signatures ri and the sum of blinding factors r. s r ment Cj = G j H j to a random value sj ∈ Zq with Merging To merge two valid signatures a1, a2, it is suf- a blinding factor rj ∈ Zq is generated for each mes- ficient to add their randomness r1 + r2 = r and use the sage mj. To assure that the prover knows the random- union of the sets in a. ness (sj, rj) and link the proof to the message, we re- Verification If the publicly calculable product holds, ped T T S quire a SoK[L ] πj over the two exponents in each and all SoKs (πj , πi , ri) are valid, 1 is returned. ped commitment Cj. The language is defined as L := Our construction fulfills all required definitions s r {C : ∃(s, r) s.t. C = G · H }. To get a scalar in Zq which are proven in Appendix B. we hash the concatenation of the message mj and the commitment Cj to get hj = h(mjkCj). With the com- Theorem 6 (Secure). The construction for the aggre- mitment Cj and the correct message, a verifier can cal- gatable signature is secure according to Definition 8. hj hj +sj rj Theorem 7 (Simulatable). The AS construction is culate G · Cj = G · H to verify if the messages belong to the signatures. simulatable according to Definition 9. T Theorem 8 (Private). The construction for AS is pri- The signature πj is necessary, proving knowledge T vate according to Definition 10. about the values in the commitment. Without πj , an s −r adversary, given r may calculate G = Cj ·H and reuse it in one of their commitments, convincing a verifier that the original message and s are present. In conclusion, sj 10 Evaluation is a hiding proxy for mj. Knowledge of sj is required to h change the message while keeping G j · Cj constant. The offer and transaction sizes of our SwapCT system For a single message, the privacy is irrelevant, as are competitive. The parameters which influence the there was exactly one party involved. With multiple transaction size are the number of inputs m, the number P|T | messages however, we define a secret sum j=1(hj +sj) of outputs n, and the size of the anonymity set r. We P|T | ˜ and a public sum r = j=1 rj. Given the value of r, the denote the size of an elliptic curve point G and a field ˜ messages mj and commitments Cj, which imply hj, it element Z, both 32 Bytes in our implementation with is infeasible for the verifier to calculate an individual sj. curve25519. The final transactions consist of an offer ∗ It is also infeasible to change a message mj and adapt and a nearly constant seal signature (≈ 800 B) which is ∗ P|T | independent of r. Both together with outputs total to some sj such that j=1(hj + sj) stays constant with- ˜ ˜ out knowing sj. Original signers can always replace their rings: m · (5Z + (2 + 1 + 4 + 2 · dlog2(r + 5)e)G) offer from a merged set and add different offer. aggregation: +m(1Z˜ + 2G˜ ) + n(2Z˜ + 2G˜ ) + 1Z˜ ˜ ˜ We use this property to distribute the value seal: +5Z + (4 + 2dlog2(2 + m + n + m ∗ n + n ∗ 64)e)G P|T | outputs +3 ˜ of j=1(hj + sj) randomly over the messages for G SoK[L]Sign. For each signature, we create a simple com- While significantly better than Monero’s proofs (O(m · |S| xi P r + log(n))), we observe our size to be asymptotically mitment Di = G with the constraint that i=1 xi = P|T | linear in m and n while the single type Omniring trans- j=1(hj + sj). A pragmatic approach is to use |S| − action has no linear components: O(log(r · m + n)). The 1 random values and calculate the last as x|S| := P|T | P|S|−1 possibility to non-interactively merge offers requires in- (hj + sj) − xi. To assure the honest cre- j=1 i=1 dependent proofs for each input and output, prohibiting ation of these commitments, a valid SoK[Lcom] πS must i aggregation. However, we achieve a similar logarithmic be attached. An Argument of Knowledge is sufficient dependency on r. Absolute transaction sizes are shown here, so we use a constant message. The language is in Figure (10a) where a common transaction (4 in/4 defined as Lcom := {D : ∃x s.t. D = Gx}. We see out) requires approximately 5 kB (offer: 4.5 kB, seal: that the product of signing side commitments Di are 0.8 kB). These sizes even hold for ring sizes of 1000, out equal to the product of message commitments Cj with Q|S| −r Q|T | hj of reach for the current Monero transaction signatures. Di = H · (G · Cj) up to the randomness i=1 j=1 To show the applicability of our SwapCT scheme, Hr which is known to the verifier, as r is published. we implemented a prototype in rust based on Finally each SoK[L] ri is generated with the supplied curve25519_dalek [14]. All benchmarks are compiled statements stmti and witnesses witi and the messages with rustc 1.48 and run on a ThinkPad T460p with Di. The aggregatable signature then consists of the com- a i7-6820HQ CPU running kubuntu 20.10 on kernel SwapCT 16

106 Monero, 4 Monero, 2 2 offer+seal, 123 offer+seal, 123 SwapCT, 4 SwapCT, 2 offer+seal, 11 offer+seal, 11 5 Omniring, 4 Omniring, 2 seal 400 seal 10 seal sig, 4 seal sig, 2 Omniring, 123 Omniring, 123 Monero, 123 Monero, 123 1 Monero, 11 Monero, 11 104 200 size in Bytes

3 10 Generation time in s

0 Verification time in ms 0 24 26 28 210 0 10 20 0 10 20 (a) Ring size (b) # inputs and outputs (c) # inputs and outputs

Fig. 10. a)Transaction size for 4 and 2 inputs and outputs depending on the ring size. For Omniring, we assumed a common ring size of r. Run time for (b) transaction generation with ring size independent sealing time part and (c) transaction verification with a ring independent seal verification in SwapCT, Omniring and Monero (RCTsimple) with same number of inputs and outputs for two different ring sizes r ∈ {11, 123} (Monero’s default is 11 and there is no Omniring data for 11, as the ring size must be larger than number of inputs). The points show the median and the error bars the minimum and maximum time of 30 runs.

5.8.0-43. Timings for your hardware are easily generated protocol works efficiently and is production-ready after by running our published code at https://github.com/ a security audit of the implementation. SwapCT/SwapCT. We provide a Dockerfile with all de- pendencies, however execution in a container might im- pact performance. For comparison, we chose Monero’s 11 Conclusion RCTsimple as it is the only system with an implementa- tion available, which includes all aspects of transaction With our SwapCT, we present a novel decentral- generation, e.g. encryption of account values. For a bet- ized transaction system which supports both privacy- ter comparison to Omniring, we implemented a full Om- preserving transactions and non-interactive atomic niring system and provide a performance comparison in swaps. We formalize the system and provide an efficient the omniring branch. instantiation which offers logarithmically sized transac- Compared to systems without swaps, the total time tions for large anonymity sets. For this, we propose our to create a SwapCT transaction consists of creating an novel aggregatable anonymous signature, a new scheme offer and then sealing it (Figure 10b). Either a single for non-interactive merging of partial transactions. Our signer creates a balanced offer themselves, or multi- prototype implementation demonstrates equal perfor- ple offers are merged by a sub millisecond operation mance to current systems that do not support multiple of adding randomness. Signing an offer depends on the tokens or swap transactions. Thereby, our SwapCT sys- anonymity set size. A transaction always requires a seal- tem enables secure and private trading of multiple types ing operation, independent of the anonymity set size, for decentralized transaction systems and digital cur- which is shown as an offset. rencies. At a larger scale, our system allows anyone to The verification in SwapCT consists of the same two operate a fully functional decentralized token exchange. parts (Figure 10c). An ring size independent seal signa- ture verification and the offer verification. As Monero only supports complete transactions, we compare the sum of necessary steps in SwapCT (offer+seal and ver- Acknowledgements ify offer+verify seal) to the Monero implementation. While our prototype is slightly slower than Mon- We thank the anonymous reviewers and our shepherd, ero, it is comparable to a deployed production system Pedro Moreno-Sanchez, for their helpful comments in with fewer features. The largest discrepancy for low ring improving this work. This work was partially supported size transaction verification is the result of meticulous by a fellowship within the IFI programme of the Ger- optimization of the Monero verification code over mul- man Academic Exchange Service (DAAD) and partially tiple years, as it is run by every participant. For larger funded by the Carlsberg Foundation under the Semper anonymity sets, we perform on par, showing that our Ardens Research Project CF18-112 (BCM). SwapCT 17

mous payments from bitcoin. In Security and Privacy (SP), References 2014 IEEE Symposium on. IEEE, 2014. [19] F. Vogelsteller and V. Buterin. Erc-20 token standard. [1] K. M. Alonso and J. Herrera-Joancomartí. Monero - privacy Ethereum Foundation, Switzerland, 2015. in the blockchain. IACR Cryptology ePrint Archive, 2018. [20] T. H. Yuen, S.-f. Sun, J. K. Liu, M. H. Au, M. F. Esgin, [2] O. Andreev, B. Glickstein, V. Niu, T. Rinearson, D. Sur, and Q. Zhang, and D. Gu. Ringct 3.0 for blockchain confidential C. Yun. Zkvm: fast, private, flexible blockchain contracts. transaction: Shorter size and stronger security. In Inter- Technical report, 2019. national Conference on Financial Cryptography and Data [3] A. Bagherzandi and S. Jarecki. Identity-based aggregate and Security. Springer, 2020. multi-signature schemes based on rsa. In P. Q. Nguyen and [21] A. Zamyatin, M. Al-Bassam, D. Zindros, E. Kokoris-Kogias, D. Pointcheval, editors, Public Key Cryptography – PKC P. Moreno-Sanchez, A. Kiayias, and W. J. Knottenbelt. Sok: 2010. Springer, 2010. Communication across distributed ledgers. 2019. https: [4] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and //eprint.iacr.org/2019/1128. G. Maxwell. Bulletproofs: Short proofs for confidential trans- [22] Y. Zheng, H. Ye, P. Dai, T. Sun, and V. Gelfer. Confidential actions and more. In 2018 IEEE Symposium on Security and assets on mimblewimble. rin, 1000:1, 2020. Privacy (SP). IEEE, 2018. [5] M. Chase and A. Lysyanskaya. On signatures of knowledge. In International Cryptology Conference. Springer, 2006. A Components [6] U. W. Chohan. The problems of cryptocurrency thefts and exchange shutdowns. Available at SSRN 3131702, 2018. We construct THC like confidential assets which satisfies [7] J. M. de Fuentes, L. González-Manzano, J. Tapiador, and P. Peris-Lopez. Pracis: Privacy-preserving and aggregatable the following properties. cybersecurity information sharing. Computers & Security, Definition 11 (Binding). A THC scheme is value bind- 2017. Security Data Science and Cyber Threat Mgnt. ing, if for any adversary A and any λ, it holds that [8] A. Deshpande and M. Herlihy. Privacy-preserving cross-chain  0 0 atomic swaps. In International Conference on Financial ty = ComTypeGen(i), ty = ComTypeGen(i ) Cryptography and Data Security. Springer, 2020. Pr  Commit(ty, v; r) = Commit(ty0, v0; r0) [9] J. Don, S. Fehr, and C. Majenz. The measure-and- i 6= i0 ∨ (i = i0 ∧ v 6= v0) reprogram technique 2.0: multi-round fiat-shamir and more. In Annual International Cryptology Conference, pages 602– pp ← ComSetup(1λ), (i, i0, v, v0, r, r0) ← A(pp) < negl(λ) 631. Springer, 2020. [10] S. Eskandari, S. Moosavi, and J. Clark. Sok: Transparent Definition 12 (Hiding). A THC scheme is hiding, if dishonesty: front-running attacks on blockchain. 2019. for any λ and any adversary A it holds that [11] A. Fiat and A. Shamir. How to prove yourself: Practical

solutions to identification and signature problems. In A. M. Pr b0 ← A(pp, com), b = b0

Odlyzko, editor, Advances in Cryptology — CRYPTO’ 86.  pp ← ComSetup(1λ), r ←−$ , b ←−{$ 0, 1} [12] G. Fuchsbauer, M. Orrù, and Y. Seurin. Aggregate cash R 1 < negl(λ) systems: A cryptographic investigation of mimblewimble. In (i , i , v , v ) ← A(pp)  − 0 1 0 1  2 Annual International Conference on the Theory and Applica- com = Commit(ComTypeGen(ib), vb; r) tions of Cryptographic Techniques. Springer, 2019. [13] Z. Gao, L. Xu, K. Kasichainula, L. Chen, B. Carbunar, ∗ Let G = (G, q, G) be a secure group and H : {0, 1} → and W. Shi. Private and atomic exchange of assets over a hash function. The randomness space is := 2, zero knowledge based payment ledger. arXiv preprint G R Zq arXiv:1909.06535, 2019. M := Zq. A type is the hash of its name ty = H(name) r a [14] Isis Agora Lovecruft and Henry de Valence. and thereby T := G. To commit, calculate (ty · G , ty · curve25519_dalek https://doc.dalek.rs/curve25519_dalek/. Gra+s) := Commit(ty, a;(r, s)). [15] R. W. Lai, V. Ronge, T. Ruffing, D. Schröder, S. A. K. Theorem 9 (Updatable). For any i, i0 ∈ {0, 1}∗ Thyagarajan, and J. Wang. Omniring: Scaling private pay- and ty = ComTypeGen(i), ty0 = ComTypeGen(i0) ments without trusted setup. In Proceedings of the 2019 0 0 ACM SIGSAC Conference on Computer and Communica- with (T,V ) = Commit(ty, a;(r, s)) and (T ,V ) = tions Security, 2019. Commit(ty0, a0;(r0, s0)) it holds that i = i0, if there ex- 0−1 φ [16] M. Möser, K. Soska, E. Heilman, K. Lee, H. Heffan, S. Sri- ists a PPT algorithm to compute φ1 in T · T = G 1 . vastava, K. Hogan, J. Hennessey, A. Miller, A. Narayanan, 0−1 φ If additionally φ2 in V ·V = G 2 is PPT computable, et al. An empirical analysis of traceability in the monero ty = ty0 and a = a0 holds. Proof in Appendix B. blockchain. PoPETs, 2018. [17] A. Poelstra, A. Back, M. Friedenbach, G. Maxwell, and The Omniring tagging scheme is used as an ex- x P. Wuille. Confidential assets. In Financial Cryptography ample: Let TagKGen(x) = H with H ∈ G and Bitcoin Workshop, 2017. 1 TagEval(x) = G x . We denote the vector exponentia- [18] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, tion as G◦~v := (Gv1 ,...,Gvn ). For a scalar s we define E. Tromer, and M. Virza. Zerocash: Decentralized anony- SwapCT 18

n 0 1 n−1 k ~s := (s , s , . . . , s ). An ordered set {Ai}i=1 may be P: Define polynomials in X: l(X) := ~cL +~α+~sL ·X and ~ ~ interchangeably written as vector A = (A1,...,Ak). r(X) := Θ · (~cR + ~sR · X) + ~µ with com ped 2 For the languages L and L we use a standard t(X) := hl(X), r(X)i = δ + t1X + t2X for some t1 $ sigma protocol and transform it to a SoK. As both the t1 τ1 t2 τ2 and t2, let τ1, τ2 ←− Zq, T1 := G F ,T2 := G F Tagged Ring Signature and the Seal Signature are based $ $ P → V: T1,T2 and V: x ←− Zq,Q ←− G and P ← V: x, Q on a Signature of Knowledge, we first describe a generic 2 P: 1. τ := τ1x + τ2x , r := rA + rSx efficient SoK based on the Bulletproof and Omniring 2. (~l, ~r, t) := (l(x), r(x), t(x)) structure and then parametrize it for each of the pur- 3. padd ~l and ~r with 0 to the next power 2 length. poses. Let again be G = (G, q, G, H) a cyclic group G of ~ ~ ~ Θ~ ◦−1 4. πIP ← IPprove(l, ~r, Gw, H ,Q) prime order q with generators G and H where the dis- P → V: τ, r, πIP, t crete log assumption holds. The goal of this signature is x ~ ~α ~ β~ −r t V: calculate P = AS GwH · F · Q and verify to prove the knowledge of the vectors ~cL,~cR which sat- ~ ~ Θ~ ◦−1 t τ δ x x2 IPvf(πIP, Gw, H ,P,Q) = 1∧ G F = G T1 T2 isfy a set of conditions relative to publicly known group We use the inner product protocol (IPprove, IPvf) ~ elements K and inner product relations. The parameters from Bulletproofs which satisfies the language LIP := m   of the system consist of two witness vectors ~cL ∈ Zq and ~ m ~ ◦~l ~ ◦~r h~l,~ri m (P, Q, G, H) ∈ G : ∃l, ~r ∈ Zq s.t. P = G H Q ~cR ∈ Zq of length m. They may be dependent on the We instantiate the tagged ring signature by spec- challenge variables u, v. Each vector is composed of two ifying the parameters of the previously defined effi- parts ~c = (~c k~c ) and ~c = (~c k~c ) where ~c L L,1 L2 R R,1 R2 L,1 cient SoK. Using the concrete instantiations for THC and ~cR,1 are both of length n with n ≤ m. The second ~ n (com := (T,V )) with Theorem 9 and TAG, we get the parameter is a vector of public group elements K ∈ G , ring following language L which may depend on u, v and fulfills the condition that THC,TAG  |R| the product of element-wise exponentiation by ~cL,1 re- 0 0 stmt = ({(pki, (Ti,Vi))}i=1, tag, (T ,V )) : sults in the identity element I = Q K~ ◦~cL,1 . Additionally  ∃wit = (j, x, a, ty, (r, s), (r0s0)) s.t. it accepts constraints in a very specific form. Each con- := ◦~ej −1 ~ x x Q ~ 0−1 ◦~ej φ1 0 m pk = H , tag = G , (T · T ) = G straint ~vi,~vi ∈ Zq may be parameterized by u, v, y. For  Q ~ 0−1 ◦~ej φ2 each i, the structure of the constraint can fall into one  (V · V ) = G ,~ej unit vector , |~ej| = |R| of the following four constraints classes, where ci is effi- Given the challenge variables u, v from the SoK sys- ciently computable by the verifier: mul: h~cL,~cR ◦~vii = ci, tem, we compress the conditions into K~ 0 := pk~ ◦ (T~ · 0 0−1 ◦u 0−1 ◦u2 ◦~c dir: h~cL,~vii = ci, sum: h~cL,~vii + h~cR,~vii = ci, and one: T ) ◦ (V~ · V ) . To satisfy Q K~ L,1 = I and ~m h~cL − ~cR − 1 ,~vii = ci. The prover P and verifier V check for a correct tag, we extend K~ 0 with tag, G, H. engage in the following interaction: The encoding for ~cL,1 is chosen appropriately with $ $ ~ $ n ~ 0 $ m−n ~ $ m 2 3 −1 0 0 V: u, v ←− Zq, F ←− G, P ←− G , G ←− G , H ←− G ξ = −uφ1 − u φ2 − u x with φ1(r, r ) = r − r and ~ ~ 0 ~ 0 0 0 0 P ← V: u, v, F, P, G , H φ2(a, r, s, r , s ) = ar + s − ar − s . It combines to ~ ~ ◦w ~ ~ 0 P, V: For w ∈ Zq define Gw := (K ◦ P kG ) 3 K := tagu kGk H k K~ 0
$ r ~cL ~c P: rA ←− q, A := F A G~ H~ R and P → V: A Z 0 ~cL := ( 1 k ξ k −x k ~ej kφ1kφ2) $ −1 ~|R| V: w ←− Zq and P ← V: w ~cR := ( 0 k 0 kx k~ej − 1 k 0 k 0 ) ( 0 if ~c [i] = 0 $ m R P: 1. ~sL ←− Zq , ~sR = (∀i ∈ [m]: ) To enforce correct witness encoding, we define inner s ←−$ else Zq product relations. A constraint is parameterized by the $ rS ~ ~sL ~ ~sR 2. rS ←− Zq,S := F Gw H and P → V: S variables u and v as well as a new challenge y: $ V: y, z ←− Zq and P ← V: y, z |R| ~v0 := (0k0k 0 k~y k0k 0 ) h~cL, ~cR ◦ ~v0i= 0 Now the prover and the verifier compress the |R| m ~v1 := (0k0k 0 k~y k0k 0 )h~cL − ~cR − ~1 , ~v1i= 0 |R| 2 2 constraints of the parametrization. Each constraint ~v2 := (yk0k 0 k1 k0k 0 ) h~cL, ~v2i= h~1 , ~y i |R| 2 ~vi has an index i and cls(~vi) returns the class ~v3 := (0k1k 0 k~0 kuku ) 0 3 ~|R| 0 {mul, dir, sum, one} of the constraint. Define: ~v3 := (0k0ku k0 k0k 0 ) h~cL, ~v3i + h~cR, ~v3i= 0 |R| ~v4 := (0k0k−yk~0 k0k 0 ) h~cL, ~cR ◦ ~v4i= y P i P i Θ~ := z ~vi ~µ := z ~vi i:cls(~vi)=mul i:cls(~vi)6=mul Using these parameters, we get an efficient SoK for the ~ν := P zi~v ~ω := P zi~v0 i:cls(~v )=one i i:~v0 6=0 i i i Tagged Ring Signature which has logarithmic communi- ~α := Θ~ ◦−1 ◦ (~ω − ~ν) β~ := Θ~ ◦−1 ◦ µ δ := h~α,~µi + h~1m, ~νi + P zic cation size in the members of the ring allowing for large i i anonymity sets with small proof sizes. SwapCT 19

The seal signature uses the same efficient generic traction proofs follow the same structure as Omniring SoK. Here we describe the preparation of the parame- proofs we refer the reader to Lai et al. [15]. seal ters. Using THC and Theorem 9, we get LTHC

 0 0 |S| T T |T | stmt = ({(Ti ,Vi )}i=1, {(Ti ,Vi )}j=1):  B Construction Security Proofs ∃wit = ({ty0 , a0 , (r0, s0 )}|S| , {tyT , aT , (rT , sT )}|T | ):  i i i i i=1 j j j j j=1  ◦−ei (Q T ~0 j φ1,j := Tj · T = G As we use the same TAG scheme as Omniring, and their ∀j ∈ [|T |]: T T  aj s  V T = T T G j , aT ∈ {0,..., 2β − 1} security proof for non-slanderability requires only a sim-  j j i  |S| |T | −1 Q 0 Q T φ2 ulator for the transaction signature, Theorem 1 holds in i=1 Vi · j=1 Vj = G our setting, as our new transaction signature is simulat- seal To compress this into a compact form with the least able by AsSimLring (Theorem 7) and SoK[L ]Sim. group elements possible, we require G, T~ , T~ 0 and one T Proof of Theorem 2 (Theft). For ChkTag to be compu- publicly computable element Vˆ which contribute to K~ . tationally binding, assume a PPT adversary which The secret exponent ~c of K~ to enforce the constraints L,1 outputs two valid openings (acc, sk, tag, sk0, tag0). The and result in the identity, are constructed as follows: validity requires pk = TagKGen(sk) = TagKGen(sk0) ~ ~◦u·~v|T | ˆ
which forces sk = sk0 because TagKGen is a bijection. K := Gk TS kTT kV 0 ~cL,1 := ( ξ k ~eˆ k ~aT k 1 k v(E) k v(B) ) As TagEval is deterministic, tag = tag , contradicting ~|S| ~|T | ~|T |·|S| ~|T |β 0 ~cL,1 := ( 0 k0 k 0 k 0 kv(E) − 1 kv(B) − 1 ) (sk, tag) 6= (sk , tag0) ChkAcc is binding because it requires ˆ Y ~ ◦−~v|T | Y ~ ◦−u·~v|T | Y ~ ◦u2 Y ◦−u2 Commit(ty, a; ck) = Commit(ty0, a0; ck0) with (ty, a) 6= V = TT · VT · VS · VT | {z } | {z } | {z } (ty0, a0) which contradicts the THC binding property. Surjection Commitments Equality T 0 |T | 0 P We show that an adversary cannot change a valid of- φ1(~r , ~r , E, v)= h~v , ~rT + E~r i = j φ1,j |S| T |T | |S| fer off := ({tag, ·}i=1, R, {acci , ·}i=1), o := ({ri, ·}i=1, a) 0 0 0 ~|S| 0 0 0 ~|T | 0 0 φ2(~r , ~s ,~a , ~rT , ~sT ,~aT )= h1 ,~a ◦ ~r + ~s i − h1 ,~aT ◦ 0 0 |S | 0 0T |T | 0 |T | 2 to off := ({tag , ·}i=1, R , {acc i , ·}i=1 ), o := ~rT + ~sT i, ξ = −φ1 + uh~v , ~sT i − u φ2 0 0 |S | 0 0 0 ~ |T | ({ri, ·}i=1, a ), such that it is valid (VfOffer(off , o ) = 1), v(E) := (~e1j k~e2j k ... k~e|T |j ) and eˆ = ~v E 0 0 |S | |S| bin(a) := β -bit binary representation of a reuses a tag from off ({tagi}i=1 ∩ {tagi}i=1 6= ∅) and T v(B) := (bin(aT )k ... kbin(aT )) changes or removes an output acc from off. 1 |T | |S| To enforce the two constraints above on the encoded Assume that some tag∗ ∈ {tagi}i=1 from off 0 0 0 |S | witness, we again define inner product relations similar is reused in off (tag∗ ∈ {tagi}i=1) and an output T T |T | T to Bulletproofs. They are parameterized by u, v, y: acc∗ ∈ {acci }i=1 was modified or removed (acc∗ 6∈ 0 0T |T | 0 {acc i }i=1 ). As the offer off is valid, this implies that ~|S| ~|T | |T |·|S|+|T |β ~v0 := (0k 0 k 0 k 0 k ~y ) a0 is valid by AsVerify in VfOffer. The security of the AS ~v := (0k ~0|S| k ~0|T | k 0 k ~y|T |·|S|+|T |β ) 1 scheme from Definition 8 then implies that no signature ~v := (0k ~0|S| k ~0|T | ky|T |k~y|T | ⊗ ~1|S|k ~0|T |β ) 2 |S| 0 |S| |S| |T | |T |·|S| |T | β was reused ({r } ∩ {r , } = ∅), as at least one out- ~v3 := (0k ~0 k−~y k 0 k ~0 k~y ⊗ ~2 ) i i=1 i i=1 |S| |T | |T | |S| |T |β T ~v4 := (0k−~y k ~0 k 0 k~v ⊗ ~y k ~0 ) put message, namely acc∗ , was changed. An efficient ad- versary against Theorem 2 can be used to construct an m ring with h~cL,~cR ◦~v0i = 0, h~cL −~cR −~1 ,~v1i = 0, h~cL,~v2i = efficient adversary against the security of SoK[L ] as |T |+1 |T |+1 h~1 , ~y i, h~cL,~v3i = 0, and h~cL,~v4i = y. the verification in AsVerifySoK[Lring] requires that for each ring SoK[L ]Verify(ri, stmti, ·) = 1. The non-slanderability Theorem 10 (SoK Signatures). Given the parameters of Theorem 1 prevents exactly this. above, the resulting protocols are perfectly complete, per- Proof of Theorem 3 (Balance). To show the bal- fectly special honest-verifier zero-knowledge and loga- ance property, we proceed by constructing an effi- rithmic round arguments of knowledge schemes for Lring cient extractor E. As VfTx(tx, t) = 1 implies that and Lseal. Given witness-extended emulation and com- SoK[Lseal]Verify(t, stmt(tx), tx) = 1. Then there ex- putationally unique responses, they are transformable to ists an efficient extractor SoK[Lseal]E extracting a perfectly complete, extractable, perfectly simulatable sig- A wit for stmt(tx). Parse the statement as stmt = natures of knowledge for the languages and any message ({com0 }|S| , {comT }|T | ) and the witness as wit = m ∈ {0, 1}∗ using Fiat-Shamir [11] which holds for mul- i i=1 j j=1 S S 0 |S| T T T |T | tiple rounds [9, Thm. 23]. As the simulator and an ex- ({tyi , ai , ck i}i=1, {tyj , aj , ckj }j=1) where ∀i ∈ [|S|]: SwapCT 20

0 S S 0 T comi = Commit(tyi , ai ; cki) ,∀j ∈ [|T |]: comj = OHyb6 changes output commitments and coin   Commit(tyT , aT ; ckT ) ,∀ty ∈ {tyT }|T | : P{aS |tyS = |S| T T T |T | j j j j j=1 i i keys to {tag1,i}i=1, {pk1,i, com1,i, ck1,i}i=1 and |S| |T | P T T 0 |S| ty}i=1 = {ai |tyi = ty}i=1 holds. This directly 0 {com1,i, ck1,i}i=1 implies the following conditions of the balance ex- OHyb7 reverts to the real signature AsSign instead of T T T T periment: ∀i ∈ [|T |], ChkAcc(acc , a , ty , cki ) = 1 , 1 i i i the simulated one, which results in OffPvA. T S |S| T |T | ∀i ∈ [|T |], tyi ∈ {tyj }j=1 and ∀ty ∈ {tyi }i=1 : We now show the indistinguishability of the hybrids. P S S |S| P T T |T | {ai |tyi = ty}i=1 = {ai |tyi = ty}i=1. OHyb1 ≡ OHyb2 follows from the simulatability of AS. The validity of VfTx(tx, t) = 1 additionaly re- OHyb2 ≡ OHyb3 : To show the equivalence, we define |S| T |T | quires AsVerifySoK[Lring]({(ri, stmti)}i=1, a, {accj }j=1) = |S| + 1 sub-hybrids where each changes one interme- 1. This is only true, if for each i ∈ [|S|]: diate commitment. The first sub-hybrid is equal to ring SoK[L ]Verify(ri, stmti, ·) = 1 holds. Due to OHyb2,0 = OHyb2 and the last is OHyb2,|S| = OHyb3. the extended witness emulation of SoKs, there In OHyb2,l the information available to the adversary is ring  |S| |T |  exist efficient extractors SoK[L ]EA,i extract- T T 0 0 l {tag0,i}i=1, {acc0,i, ck0,i}i=1 and {com1,i, ck1,i}i=1 ∪ ing wit for stmt . Parse the statements as i i 0 0 |S| |R| 0 {com0,i, ck0,i}i=l+1. To show that OHyb2,l−1 ≡ OHyb2,l stmti = ({(pk , comi,k)} , tag , com ) and the i,k k=1 i i we know that the amount aS and type tyS committed witnesses as wit = (j , sk , aS , tyS , ckS , ck0 ). Lring l l i i i i i i i 0 to in comk,l are equal for both k ∈ {0, 1}. The coin keys then enforces pk = TagKGen(ski), tag = ji i ck0 are distributed uniformly at random. Thereby, the TagEval(sk ), com = Commit(ty , a ; ck ) and k,l i i,ji i i i 0 0 0 commitment com1,l is fully defined. com = Commit(ty , ai; ck ) which implies the re- i i i OHyb ≈ OHyb : To show the indistinguisha- maining conditions of the balance experiment, 3 c 4 R bility of the tags, we again define |S| + namely for each i, ChkTag(acc , ski, tag ) = 1 and i,ji i 1 sub-hybrids with OHyb = OHyb to ChkAcc(accR , aS , tyS , ckS ) = 1 hold. With a binding 3,0 3 i,ji i i i OHyb = OHyb . The information in OHyb THC, intermediate commitments com0 commit to the 3,|S| 4 3,l i  |S| |T |  S S l T T same witnesses (a , ty ) in Offer and Seal. is {tag0,i}i=1 ∪ {tag1,i}i=l+1, {acc0,i, ck0,i}i=1 0 0 |S| Proof of Theorem 4 (Offer Privacy). We use a series of and {com1,i, ck1,i}i=1. The indistinguishability hybrids to prove the offer privacy by progressing in in- OHyb3,l−1 ≈c OHyb3,l holds because TagEval is called distinguishable steps from the experiment with b = 0 to with a uniformly random value x + s. According to b = 1. The hybrids are defined as: the related-input pseudorandomness of TAG, tag0,l and 0 tag1,l are indistinguishable. OHyb1 is the same as OffPvA OHyb4 ≡ OHyb5 : To show the equivalence, we define OHyb2 differs in that the aggregatable signature AS |T | + 1 sub-hybrids where each changes one public in Offer is simulated by AsSimLTRS (). The information key of the account. The first sub-hybrid is equal to available to the Adversary are off0 which includes off0 = S S |S| R |Ri| |S| T T T OHyb4,0 = OHyb4 and the last is OHyb4,|T | = OHyb5. {tag0,i, a0,i, ty0,i}i=1, {{acci,j}j=1 }i=1, {acc0,i, ai , tyi , T |T |
In OHyb4,l the information available to the adversary is ck0,i} and the intermediate commitment with coin i=1  T T T l T T T |T |  0 0 |S| {pk1,i, com0,i, ck0,i}i=1 ∪ {pk0,i, com0,i, ck0,i}i=l+1 , key {com0,i, ck0,i}i=1. Everything else in the signature |S| |S| 0 0 |S| T T 0 0 {tag1,i} and {com , ck1,i} . As pk0,l and pk1,l are o0 = ({(r0,i, com0,i, ck0,i)}i=1, a0) is simulated. Val- i=1 1,i i=1 ues indepent of b are ignored, reducing the data to identically distributed, OHyb4,l−1 ≡ OHyb4,l holds.   |S| T T |T | 0 0 |S| OHyb5 ≡ OHyb6 : To show the equivalence, we define {tag0,i}i=1, {acc0,i, ck0,i}i=1 and {com0,i, ck0,i}i=1 |T |+1 sub-hybrids where each commitment and coin key OHyb changes the intermediate commitment to 3 is changed by the same argument as in OHyb ≡ OHyb . 0 0 |S|  |S| T T |T |  2 3 {com1,i, ck1,i} , leaving {tag0,i} , {acc0,i, ck0,i} i=1 i=1 i=1 OHyb6 ≡ OHyb7 holds by the simulatability of AS. OHyb4 changes the tags to the experiment with   b = 1, resulting in {tag }|S| , {accT , ckT }|T | and 1,i i=1 0,i 0,i i=1 Proof of Theorem 5 (Transactions). Similarly to 0 0 |S| {com1,i, ck1,i}i=1 the offer privacy, we prove the transaction pri- OHyb5 : The output accounts consist of a public key and vacy with a set of hybrids. First, simulate with T T T seal a commitment acc0,i = (pk0,i, com0,i). First we change SoK[L ]Sim(stmt(tx), tx) in Seal and AsSimLTRS in  |S| T T T |T |  Offer. Then gradually change the information to the ad- the public keys to {tag1,i}i=1, {pk1,i, com0,i, ck0,i}i=1   versary from {tag }|S| , {accT }|T | and {com0 }|S| 0 0 |S| 0,i i=1 0,i i=1 0,i i=1 and {com1,i, ck1,i}i=1 SwapCT 21

  0 0 0 |S| T |T | as φ2−vr−s+v r +s from which an efficient adversary to the hybrid with b = 1: {tag1,i}i=1, {acc1,i}i=1 and v−v0 0 |S| against the binding property is easily constructed. {com1,i}i=1. Finally change the simulated proofs back to real ones. The hybrids are indistinguishable due to Proof of Theorem 6 (Security). To show the security of the existence of simulators, hiding commitments and our AS scheme, we start with the most simple scenario tags as in the previous proof. of one signature and one message. Then we use the ad- versary A to efficiently construct an adversary against the discrete logarithm problem. Given a challenge chl = γ C Component Security Proofs (G, G ) we proceed as follows. 1. Sample a statement and witness (stmt1, wit1) ∈ RL. 2. Sample a message m ∈ {0, 1}∗ and r ∈ . 3. Calculate C = Gγ Hr1 . Proof of Theorem 9 (Update). We show that THC is 1 1 Zq 1 4. Simulate πT = SoK[Lped]Sim(stmt = C , m ). 5. Cal- binding according to Definition 11. Given a discrete log 1 1 1 γ h1 γ 2 O culate h1 = h(m1||C1) and D1 = G · G . 6. Simulate challenge chl = (G, G ) ∈ G , we define an oracle H for S com π1 = SoK[L ]Sim(stmt = D1, 42). 7. Sign D1 with the adversary to use. Sample a secret sk ←−{$ 0, 1}λ and r1 = SoK[L]Sign(stmt1, wit1,D1). This results in a valid ∗ define a new hash function h : {0, 1} → Zq. On input S T
aggregated signature {r1}, ({(π1 ,D1)}, {(π1 ,C1)}, r) of i, calculate b = h(iksk) mod 2 and return (Gγ )h(iksk) for stmt1 and m1. The adversary A, given the signa- h(iksk) if b = 0 and G otherwise. The output is indistin- ture above, is able to output a new valid signature guishable from a uniformly random distribution over G.  |S| 0S 0 |S| 0T 0 |T | 0  for {r1} ∪ {ri} , ({(π ,D )} , {(π ,C )} , r ) Assume that an efficient adversary A exists, which i=2 i i i=1 j j j=1 0 0 0 0 which uses the same r1 along with possible other sig- returns i, i , v, v , (r, s), (r , s ) ← A O (pp) for which H natures {r }|S| but a set of messages M = {m0 }|T | Commit(ty, v; r, s) = Commit(ty0, v0; r0, s0) ∧ (i 6= i0 ∨ (i = i i=2 j j=1 which does not include m (m 6∈ M). As r is a i0 ∧ v 6= v0)) holds with ty = ComTypeGen(i) and 1 1 1 secure signature, it follows that D0 = D = Gγ · ty0 = ComTypeGen(i0). 1 1 h1 0 |S| O r O 0 r0 G . For all other {Di}i=2 created by A, we use This is equal to H (i)G = H (i )G and com 0 0 0 0 the efficient extractor SoK[L ]E which exists due to HO(i)vGrv+s = HO(i0)v Gr v +s . We have two cases: SoK[Lcom]Verify(π0S ,D0, 42) = 1 to extract {x0 }|S| from For i = i0 the pre-image is equal, so v 6= v0 is true and i i i i=2 0S |S| 0 x0 0 0 0 0 {π } for which D = G i holds. On the message v −v0 6= 0. Then HO(i)v−v = Gr v +s −rv−s. In 1 of the i i=2 i 2 ped S 0 side all proofs are valid SoK[L ]Verify(π ,C , m ) = 1 executions, h(iksk) ≡ 0 mod 2, and thereby (Gγ )v−v = i i i 0 0 T r0v0+s0−rv−s r v −rv and are created by A, as our simulated π1 is invalid G from which we return γ = 0 to chl. v−v for all m0 ∈ M. Therefore, we extract {(s0 , r0)}|T | from For i 6= i0 with different identifiers, it holds i i i=1 0T |T | ped 1 0 {π i }i=1 with SoK[L ]E. As the new signature is valid, with 2 probability, that h(iksk) 6≡ h(i ksk) mod 2. Without loss of generality, assume the products are equal and by comparing exponents of 0 P|T | 0 P|S| 0 HO(i) = Gh(iksk) and HO(i0) = Gγh(i ksk). From G we calculate γ = j=1 sj − h1 − i=2 xi. 0 v  0 v 0 0 0 Gh(iksk)
Grv+s = Gγh(i ksk) Gr v +s we calcu- Proof of Theorem 7 (Simulatability). The witnesses 0 0 0 witi are used only in SoK[L]Sign, for which an efficient late γ = vh(iksk)+rv+s−r v −s and return γ to solve chl. v0h(i0ksk) simulator exists. An efficient simulator AsSim is defined In both cases, independent of the adversary’s choice of by replacing r with r ← SoK[L]Sim(stmt,D ). 0 1 i i i i, i , we have 2 > negl(λ) chance to solve the dlog chal- lenge. Therefore we conclude that no efficient adversary Proof of Theorem 8 (Privacy). The information given against the binding property exists. to the adversary in the experiment about b is Σb, ab. We show that from an efficient adversary A Let Σb be simulated by AsSim. Sets are closed un- against the update Theorem 9, we can derive an ef- der the union operation and thereby reveal nothing ficient Adversary for the binding property of Def. 11 about b. For both b ∈ {0, 1} it holds that ab = $ S |I| T |J| which proceeds as follows: Sample i ←−{0, 1}∗ and ({πb,i,Db,i}i=1, {πb,i,Cb,i}i=1, rb). Again, the union of 0 0 0 $ 0 the sets does not reveal the initial subsets. The random- v, r, s, v , r , s ←− Zq with v 6= v . Then commit ness r is the sum of random values and thereby itself (T,V ) = Commit(ComTypeGen(i), v; r, s) and (T 0,V 0) = b uniformly random. As none of the values is dependent Commit(ComTypeGen(i), v0; r0, s0). Invoke the adversary 0−1 φ on the signer’s identity ub,i, Theorem 8 holds. to get a φ2 for which V · V = G 2 holds. From this calculate the discrete logarithm of H(i) to base G