Fair and Decentralized Exchange of Digital Goods

02/22/2020 ∙ by Ariel Futoransky, et al. ∙ Wibson Ltd. Grandata 0

We construct a privacy-preserving, distributed and decentralized marketplace where parties can exchange data for tokens. In this market, buyers and sellers make transactions in a blockchain and interact with a third party, called notary, who has the ability to vouch for the authenticity and integrity of the data. We introduce a protocol for the data-token exchange where neither party gains more information than what it is paying for, and the exchange is fair: either both parties gets the other's item or neither does. No third party involvement is required after setup, and no dispute resolution is needed.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Fair exchange, smart contracts and contingent payments have occupied the cryptographic community for decades. They relate to problems where parties exchange a piece of data or a service, for data or payment. We look here upon the problem of selling personal data.

The importance of privacy in digital transactions continues to grow in these times, when marketing is ubiquitous and based on the footprint of digitalized lives. Individuals are willing to loosen their privacy expectations in exchange for a service (e.g., social networks or webmail services) or even money.

Consider a a distributed and decentralized marketplace where some parties can buy personal data. For example, an apparel company is willing to pay for the 2-weeks browsing history of people who went to Coachella Festival, or a financial institution willing to pay for the last places visited by people between the ages of 20 and 35, earning over $150K, in New York City. We are interested in (i) a question that can be encoded in a predicate that we call audience matching criteria, and (ii) a payload, or piece of information, tied to this predicate.

In this market, a buyer publishes an offer that includes an audience match criterion, a payload description, and an amount he is willing to pay for an answer. A trusted third party creates certificates for the sellers, wherein a certificate contains an authenticated answer for an offer (e.g., authenticated audience match value and payload). Each seller receives certificates, and when he receives an offer, he interacts with the buyer to evaluate the audience criterion. When there is a match, the buyer starts a contract in a blockchain and the seller closes the contract. With an atomic swap, tokens are exchanged for the data. This trusted third party can be materialized as a bank, who can certify questions about spending and financial status; or a telecommunications company, which can certify the geographical location of its subscribers (via triangulation with the antennas their cell phones connect to).

Contributions and Related Work

We introduce a decentralized and distributed marketplace for selling personal digital data. The market design we present was used as a blueprint for a real construct, and the abstractions adhere to realistic security problems.

We design an UC-ideal functionality which implements secure exchanges, and a real life protocol that securely realizes this. This protocol is privacy friendly: it hides data and transactions from the public. If parties are honest, then the buyer, and only the buyer, can access this data and the seller gets paid.

The protocol and marketplace formalize an existing data marketplace named Wibson [Travizano et al., 2018, Fernandez et al., 2020]. The secure exchange mechanism was presented in Futoransky et al. [2019]. This marketplace uses an Ethereum side-chain, and a gas efficient protocol named BatPay for the recurrent micropayment of tokens [Mayer et al., 2020]. Users connect through a mobile app in their phones, and check a message board where buyers post their offers. The solution herein needs to conforms with a high standard both in terms of the security and privacy, and in terms of the computational and communication costs. Additionally, this marketplace features a cryptographic primitive called WibsonTree, designed to preserve users’ privacy by allowing them to demonstrate predicates on their personal attributes, without revealing the values of those attributes [Futoransky et al., 2020].

In a fair exchange, two parties wish to exchange a piece of data each holds and is secret to the other. While a result by Cleve [1986] shows that basic fair exchange is impossible in a 2-party setting, modifications and restrictions demonstrate that it is achievable [Asokan et al., 2000, Micali, 2003, Okada et al., 2008, Campanelli et al., 2017].

The setting of the paper differs from the models underlying these articles. Campanelli et al. [2017] uses a blockchain to perform atomic swaps, but moves to use this for providing services, such as Sudoku-puzzle solving through ZK-proofs.

2 A Model for Decentralized Exchange of Digital Goods

We use the Universal Composable Security framework [Canetti, 2001] to formalize the notion of a marketplace. We use the –hybrid model, where parties are allowed to register and retrieve public keys from a certification authority [Canetti, 2003]. We use the plain communication model with unauthenticated asynchronous communication, without guaranteed delivery and with possible replay (see for example Canetti [2000]). Furthermore, we restrict attacks to static Byzantine corruptions.

The protocol is played by two main parties, a seller and a buyer . A third party, the notary , vouches for the authenticity of data. That is, the notary may provide a seller with a ‘certificate’ which includes data and an audience match value binded to the seller’s id. A fourth party, , plays the role of a blockchain. It is known [Badertscher et al., 2017, Garay et al., 2015, Kiayias et al., 2015]

that not all the properties of a blockchain are captured by an Interactive Turing Machine (ITM). Nonetheless, we model the blockchain as an ITM for the sake of simplicity, capturing some of its properties.

Parties have an account with the blockchain that is binded to their , i.e., they registered a signature verification public key with and has retrieved them all. Furthermore, we assume that the notary is known by all parties, i.e., they know that the id is associated with a notary that can sign data and this data ought to be trusted. stores a table (ledger) where each party id is associated with an amount of tokens the party owns, and publishes updates on each output. Assume that on initialization, receives the initial state of the ledger. At any point is allowed to make token transfers from one account to the other, or to momentarily immobilize a token. We assume no tokens are created or removed. In order to model the blockchain’s ability to multicast messages, we assume that writes messages to a ‘public’ tape, and the adversary may decide deliver it to any party, like it does with any message. Similarly, we assume that buyers multicast messages and the adversary may decide what to do with them.

The blockchain, , executes a contract: it receives messages of the form


When receives a –message, if this is the first contact with this and the sender has N tokens for payment, then immobilizes N tokens, and puts the message in its public tape. When receiving a –message, checks for a stored –message which has not been closed, he checks if . If equality holds, transfers N tokens from sender of the Open message to sender of the Close message, and considers the contract closed. Else, ignores the -message and wait for a new one.

We assume that we are given a function defining all audience criteria. For a seller attribute and a buyer attribute , can be evaluated in polynomial time and if, and only if, matches the criterion defined by . We assume that all the negotiation details are encoded in and , including the price offered by the buyer, which for the sake of simplicity, we have fixed at 1 token.


Let be an encryption scheme and a collision-resistant hash function. We require that offers semantic security and remains safe even if an adversary is given (cf. Futoransky et al. [2006]). This standard requirement in practice does not follow from the definitions. Nonetheless, this can be attained for example starting from a secure block cipher [Boneh and Shoup, 2020], a mode of operation that allows transmitting messages of polinomially-bounded length (with a resulting semantically-secure symmetric cipher), and with the (preimage-resistant) hash function constructed from (see Black et al. [2002]).

Let be the ideal-process secure message transmission functionality of Canetti [2001] and let be a real-life protocol securely realizing , e.g., the protocol of op. cit. constructed out of a public-key encryption scheme that is semantically secure against chosen plaintext attack. We assume the leakage function for to provide the adversary with the message header and the size of the secret (non-header) portion of the message. Let be the signature ideal functionality of Canetti [2003] and let be a signature scheme which is eu-cma; hence this protocol securely realizes [Goldwasser et al., 1988, Canetti, 2003]).

3 The Secure Exchange Functionality

We introduce the (abstract) ideal functionality that enables secure exchanges. The protocol has three steps, during setup the notary receives an input consisting in the of a seller , a piece of data (or message) , and the seller’s attribute ; next comes the offer where the buyer advertises an audience criterion through an attribute ; and finally, the seller responds to the offer and the exchange takes place.

Functionality Upon receiving from check that and that no other message was received with the same . If is uncorrupted, send to the adversary. Upon receiving from the adversary, send to and store . If the seller has been corrupted, send to the adversary and store . Upon receiving an offer from a buyer, forward to the adversary. Each time the adversary sends a message send to party with id and store the message. Upon receiving , retrieve (if any) a stored certificate with id , and an offer with id . If , send the message to the adversary. Upon receiving from the adversary, transfer 1 token from to . Upon receiving from the adversary when the is uncorrupted, send to , or upon receiving from the adversary when is corrupted, send to ; then abort.

Figure 1: The ideal functionality .

The ideal functionality shown in Fig. 1 gives the adversary the power to decide who gets the offers, as the adversary controls the communication network, and hence also if the seller’s message, which closes the transaction, reaches the blockchain, and if the blockchain’s message can reach or .

4 The Secure Exchange Protocol

Let . The protocol in the -hybrid model goes as follows.

  1. When the notary receives an input , he computes , the ciphertext , the hashes , and invokes with to receive a signature . When done, sends to via .

  2. Upon receiving , the seller invokes with and waits for , next he invokes with and waits for an answer. If the signature is valid, and , he outputs .

  3. When receives , he multicasts .

  4. Upon receiving , and if it is the first offer with this , a seller stores the message and outputs .

  5. When the seller receives ,he looks in his storage for a certificate and an offer with these ids. If he finds them and , sends the message to via and stores .

  6. When the buyer receives a –message, he invokes with waits to receive a tag , he invokes with waits to receive an affirmative verification, and if this happens checks that . If anything fails, he ignores. Else, he sends the message to .

  7. Upon receiving a –message, checks if the sender has a balance of at least one token and ignores of he does not. Else, immobilizes a token from the sender and multicasts the –message.

  8. Upon reading a –message for a for a stored pair , retreives the key associated to and sends to .

  9. Upon receiving from , the blockchain looks for an associated –message and ignores if not found or if it is already closed. Else, he computes . If it agrees with , then he multicasts in his public tape and transfers the immobilized token to and modifies the ledger to reflect this change.

  10. Upon reading , outputs .

  11. Upon reading in the new state of the ledger that he was payed, the seller outputs .

5 The Main Result

We now prove that the real-life protocol securely realizes the ideal functionality.

Theorem 1.

Protocol securely realizes in the –hybrid model.


By the UC composition theorem it suffices to show that securely realizes functionality in the –hybrid model. Let be a –hybrid model adversary. We define an ideal-process adversary (e.g., a simulator) such that the execution in the ideal-process model and in the -hybrid models are indistinguishable by any environment . The simulator runs an execution with the environment and, in parallel, simulates a virtual copy of the hybrid adversary . That is, acts as an interface between and by imitating a copy of a real execution of for , incorporating ’s ideal-model interactions and forwarding ’s messages to .

Assume no corruptions happens.

When receives from the ideal functionality , computes:

  • ,

  • a random string of size ,

  • ,

  • the hashes ,

and simulates sending to .

When answers with , simulates sending

to through .111Note that only needs the size of the message and not its contents, to simulate this for , e.g., he can send a string of s of the correct size and cannot distinguish one from the other. If delivers a –message, then simulates sending to . If the hybrid adversary answers , then simulates sending to and mimics verification algorithm. If the verification checks out, sends to .

When receives from functionality , he simulates multicasting . Next, each time delivers the message to a party with id , sends to .

Upon receiving from the ideal functionality, simulates sending to through . Upon delivering a –message, the ideal-process adversary simulates sending to the hybrid adversary. Party waits for to answer with , then simulates by sending to

and waits for to deliver this to . When this happens, the ideal-process adversary checks if has at least one token in its account, and ignores if there is less. Else ‘immobilizes’ one simulated token, and simulates multicasting the –message. When delivers this message to , the ideal-process adversary simulates sending to . Upon delivering a –message with id , verifies that and if this happens, sends to and simulates putting this message in its public tape. Upon the adversary delivers this message, sends to the ideal functionality .

In order to conclude that the result follows in the uncorrupted case, first notice that the delays in message delivery are incorporated by simulator so that all outputs are synchronized. Second, note that the hybrid adversary learns the headers:

  • ,

  • ,

  • the size ,

  • the size .

He also learns the full contents of

  • ,

  • ,

  • ,

  • and who receives the first of these messages.

These are computationally indistinguishable and thus the result follows.

Assume corrupts .

In that case corrupts and has dummy output what outputs. When receives from the ideal functionality , he simulates the environment sending this to the simulated as input. Moreover, simulates the other parties for . In particular, if the simulated sends a message

through to , then the ideal-process adversary continues the simulation as in the uncorrupted case.

The corruption of the notary can only influence the certificate sent to the seller, which is the only message sent by the notary. If sends a certificate which does not have the correct format, or the signature validation is not passed:

then the seller ignores the message. Assume then that all these controls are passed. Then the simulator continues as in the uncorrupted case: simulates sending the –message to . If the adversary delivers this message, sends to the ideal functionality . Hence, both the and pay for .

Assume the hybrid adversary corrupts .

In this case the simulator corrupts . Additionally he has output what outputs. When receives from the ideal functionality , he proceeds analogously to the uncorrupted case, changing the fake values for real ones. More precisely, simulates key generation, encryption and hashing with the real values, and then invoking with . Upon obtaining from the hybrid adversary, simulates sending

from to through . (Note that here holds and , generates , computes and –same as .) When the hybrid adversary delivers the message, sends to the ideal functionality .

Upon receiving , continues like in the uncorrupted case.

Upon receiving from , simulates receiving the same message from the environment. If the corrupted seller, , sends a message

to through , the ideal-process adversary simulates sending

to the hybrid adversary and if answers with , then simulates sending and ignores if the signature validation is not passed. Else, simulates by sending to

If the hybrid adversary delivers the message, simulates writing this message to its public tape. When the hybrid adversary delivers the message to the , waits for to send to . checks if and ignores if it does not hold. Else, the ideal-process adversary sends to and simulates writing to its public tape. If delivers, sends to the ideal functionality . Again, can’t distinguish the hybrid from ideal-process protocol executions.

The cases where the adversary corrupts or multiple parties is left out for the sake of brevity, thus concluding the proof.

6 Conclusion

Here we proposed a solution to the problem of trading real-world private information using only cryptographic protocols and a public blockchain to guarantee the fairness of transactions. We described a protocol that we call “Secure Exchange of Digital Goods” [Futoransky et al., 2019] between a data buyer and a data seller . The protocol relies on a trusted third party , which also plays the role of notary in the context of a decentralized Privacy-Preserving Data Marketplace (dPDM) such as the Wibson Marketplace [Travizano et al., 2018, Fernandez et al., 2020].

This protocol converts the exchange of data into an atomic transaction where two things happen simultaneously:

  • The buyer gets access to the data, by learning the key that enables him to decrypt (previously received encrypted data).

  • The seller gets paid for his data by revealing the key.

There exists some open questions that cannot be addressed completely in this paper, but are worth posing to understand the value of the model. For example, can we modify the protocol so that or are not shared? How can we allow a seller to close a contract if he does not have currency (e.g., Ethereum gas) to pay for the transaction? We have actually developed a solution for this problem in [Mayer et al., 2020].

The implementation of the above protocol implies costs to all intervening parties. Each transaction costs at least the computation of a hash, and if this turns to be expensive, the protocol needs to be optimized. This can be done with the BatPay smart contract [Mayer et al., 2020].


  • Asokan et al. [2000] Nadarajah Asokan, Victor Shoup, and Michael Waidner. Optimistic fair exchange of digital signatures. IEEE Journal on Selected Areas in communications, 18(4):593–610, 2000.
  • Badertscher et al. [2017] Christian Badertscher, Ueli Maurer, Daniel Tschudi, and Vassilis Zikas. Bitcoin as a transaction ledger: A composable treatment. Cryptology ePrint Archive, Report 2017/149, 2017. https://eprint.iacr.org/2017/149.
  • Black et al. [2002] John Black, Phillip Rogaway, and Thomas Shrimpton. Black-box analysis of the block-cipher-based hash-function constructions from PGV. In Annual International Cryptology Conference, pages 320–335. Springer, 2002.
  • Boneh and Shoup [2020] Dan Boneh and Viktor Shoup. A Graduate Course in Applied Cryptography. 2020. Published online, see https://toc.cryptobook.us/.
  • Campanelli et al. [2017] Matteo Campanelli, Rosario Gennaro, Steven Goldfeder, and Luca Nizzardo. Zero-knowledge contingent payments revisited: Attacks and payments for services. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pages 229–243. ACM, 2017.
  • Canetti [2000] Ran Canetti. Universally composable security: A new paradigm for cryptographic protocols. Cryptology ePrint Archive, Report 2000/067, 2000. https://eprint.iacr.org/2000/067.
  • Canetti [2001] Ran Canetti. Universally composable security: A new paradigm for cryptographic protocols. In Proceedings 42nd IEEE Symposium on Foundations of Computer Science, pages 136–145. IEEE, 2001.
  • Canetti [2003] Ran Canetti. Universally composable signatures, certification and authentication. Cryptology ePrint Archive, Report 2003/239, 2003. https://eprint.iacr.org/2003/239.
  • Cleve [1986] Richard Cleve. Limits on the security of coin flips when half the processors are faulty. In

    Proceedings of the eighteenth annual ACM symposium on Theory of computing

    , pages 364–369. ACM, 1986.
  • Fernandez et al. [2020] Daniel Fernandez, Ariel Futoransky, Gustavo Ajzenman, Matias Travizano, and Carlos Sarraute. Wibson protocol for secure data exchange and batch payments. arXiv:2001.08832, 2020.
  • Futoransky et al. [2006] Ariel Futoransky, Emiliano Kargieman, Carlos Sarraute, and Ariel Waissbein. Foundations and applications for secure triggers. ACM Transactions on Information and System Security (TISSEC), 9(1):94–112, 2006.
  • Futoransky et al. [2019] Ariel Futoransky, Carlos Sarraute, Ariel Waissbein, Daniel Fernandez, Matias Travizano, and Martin Minnoni. Secure exchange of digital goods in a decentralized data marketplace. In Proceedings of the 2019 Argentine Symposium on Big Data (AGRANDA), pages 38–44, 2019.
  • Futoransky et al. [2020] Ariel Futoransky, Carlos Sarraute, Ariel Waissbein, Matias Travizano, and Daniel Fernandez. WibsonTree: Efficiently preserving seller’s privacy in a decentralized data marketplace. arXiv:2002.03810, 2020.
  • Garay et al. [2015] Juán Garay, Agelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and applications. In E. Oswald and M. Fischlin, editors, Advances in Cryptology - EUROCRYPT 2015, volume 9057. Springer, Berlin, Heidelberg, 2015.
  • Goldwasser et al. [1988] Shafi Goldwasser, Silvio Micali, and Ronald L. Rivest. A digital signature scheme secure against adaptive chosen-message attacks. SIAM J. Comput., 17(2):281–308, April 1988. ISSN 0097-5397.
  • Kiayias et al. [2015] Aggelos Kiayias, Hong-Sheng Zhou, and Vassilis Zikas. Fair and robust multi-party computation using a global transaction ledger. Cryptology ePrint Archive, Report 2015/574, 2015. https://eprint.iacr.org/2015/574.
  • Mayer et al. [2020] Hartwig Mayer, Ismael Bejarano, Daniel Fernandez, Gustavo Ajzenman, Nicolas Ayala, Nahuel Santoalla, Carlos Sarraute, and Ariel Futoransky. BatPay: a gas efficient protocol for the recurrent micropayment of ERC20 tokens. arXiv:2002.02316, 2020.
  • Micali [2003] Silvio Micali. Simple and fast optimistic protocols for fair electronic exchange. In Proceedings of the twenty-second annual symposium on Principles of distributed computing, pages 12–19, 2003.
  • Okada et al. [2008] Yusuke Okada, Yoshifumi Manabe, and Tatsuaki Okamoto. An optimistic fair exchange protocol and its security in the universal composability framework. International Journal of Applied Cryptography, 1(1):70–77, 2008.
  • Travizano et al. [2018] Matias Travizano, Carlos Sarraute, Gustavo Ajzenman, and Martin Minnoni. Wibson: A decentralized data marketplace. In Proceedings of SIGBPS 2018 Workshop on Blockchain and Smart Contract, 2018.