Cryptographically-verifiable delivery disputes

[jkleinne]

Given:

Pd : Price of the Product
h(d): Hash ( SHA3/keccak256 ) of the Product
ID : Contract Nonce or hashIdentifier for that particular agreement
enc: encrypt
[B/S]pub: Buyer/Seller public key
[B/S]pri: Buyer/Seller private key

Delivery:
The Seller sends an encrypted version of d, namely, encBpub (encSpri (d, ID)), to the interested Buyer, possibly on an off-chain channel.

Accept/Reject Delivery:
The Buyer decrypts the data d, then hashes it to check if it matches the previously known h(d). The Buyer then provides a response to the Smart Contract; in this response, it either:

• Accepts delivery of the Product.
• Rejects delivery, claims that the Seller has cheated, and tries to prove it by sending encBpri (d, ID) to the Smart Contract.

Reconciliation:
This step is undertaken by the Smart Contract after hearing from the Buyer in the previous step.

• In case of Acceptance: Both the Seller collateral and the Buyer collateral are refunded to corresponding parties. The Seller also receives the price Pd for the product.

• In case of Complaint: The Smart Contract will decrypt encSpri (d, ID) using the Seller’s public key Spub. If the Buyer submits a garbage string, then the Smart Contract will slash both deposits, along with the payment. Then it first compares ID to ensure that the ciphertext was corresponding to this transaction. It then hashes d and find h(d), which is then compared with the one that the Seller uploaded while generating the smart contract.

  • If a mismatch is found, then the Seller has cheated, and loses its deposit: it is used to pay for the gas consumed in this reconciliation step, and the rest is slashed (burned). The Buyer gets back its deposit as well as the payment for the product.
  • If the hashes match, then the Buyer made a frivolous complaint, and loses its deposit: it is used to pay for the gas consume in this reconciliation step, the Product payment Pd is sent to the Seller, and the rest is slashed (burned).

[1] “Solving the Buyer and Seller’s Dilemma: A Dual-Deposit Escrow Smart Contract for Provably Cheat-Proof Delivery and Payment for a Digital Good without a Trusted Mediator | IEEE Conference Publication | IEEE Xplore.” https://ieeexplore.ieee.org/document/8751482 (accessed Jun. 18, 2021).


[2] S. Goldfeder, J. Bonneau, R. Gennaro, and A. Narayanan, “Escrow Protocols for Cryptocurrencies: How to Buy Physical Goods Using Bitcoin,” in Financial Cryptography and Data Security, vol. 10322, A. Kiayias, Ed. Cham: Springer International Publishing, 2017, pp. 321–339. doi: 10.1007/978-3-319-70972-7_18.

[jkleinne]

Initial naive implementation without Kleros integration: #12

[jkleinne]

[jkleinne]

The goal is for the protocol to enforce honest behavior or penalty via game-theoretic means. If the Seller tries to send incorrect goods, they risk losing their deposit; if the Buyer complains maliciously, they lose theirs. The hashing ensures the item delivered is exactly what was advertised at contract setup.

Current limitations:

• On-Chain revelation of the product in case of dispute
  • If the Buyer lodges a complaint, the Buyer (or the smart contract) must reveal d to verify h(d)
  • This is fine for small or non-sensitive digital items, but for proprietary or large data, it may be undesirable or infeasible
  • Mitigation: Use zero-knowledge proofs [1] or hashed partial reveals so that entire data d need not appear publicly
• Off-Chain delivery risks
  • Because delivery is off-chain, if the Buyer claims they never received d, it becomes a “my word vs. yours” unless the cryptographic structure somehow demonstrates that the Seller indeed sent the correct ciphertext
  • Typically, the protocol asserts: if the ciphertext is validly signed by the Seller, it’s proof the Seller intended to deliver. Buyer can only claim non-delivery if they can show it was nonsense
• Complexity: The smart contracts must handle deposit logic, hashing, dispute resolution, and correct signature/encryption verification which can also be more costly

[1] https://www.di.ens.fr/~nitulesc/files/Survey-SNARKs.pdf