4

Alice and Bob publicly choose the messages $M_A$ and $M_B$ and independently sign them (Alice privately signs $M_A$, Bob signs $M_B$).

Now Alice and Bob are looking for a protocol that allows them to:

  1. Make sure the other party's signature is valid (in a malicious adversary model)

  2. Only reveal their own signature if they're guaranteed by the protocol to learn the other party's signature as well (atomic reveal)

  3. Not rely on a trusted dealer

Is there such a protocol possible to construct? Can it be extended to N parties instead of 2? Can it work with an ECDSA signature scheme?

Edit: After researching the topic more and thanks to the answers below, I found out this is commonly known as a (strong) fair-exchange protocol and it's impossible in the two-party setup without a trusted third party. However, optimistic fair exchange protocols are possible and they only rely on a trusted party if one of the participants attempts to cheat.

Lucian Boca
  • 282
  • 1
  • 8

3 Answers3

4

This can be achieved using fair exchange protocols, which seek to ensure that either Alice and Bob both get what they want or neither of them does.

Alpha Bravo
  • 101
  • 8
3

I believe this impossible. (Edit: Major edit below)

Let's assume this is implemented by Alice and Bob sending messages to each other, how many messages would it take.

We will show if it is possible with n messages then it must be possible with n-1.

If it is possible with n messages, without loss of generality let the last message be from Alice to Bob . At this point Alice no longer receives any information so she must have already everything she needs to reveal, she may therefor choose not to send the last message. If Bob is still able to reveal as well then it is possible to solve with n-1 messages.

Via induction it is possible with 0 messages which is obviously impossible.

Edit: My above answer is technically correct. Which is the worst kind of lie. As Dragos and Alpha Baravo point out, there is a lot of literature on fair exchange protocols.

So How do we work around the impossibility? Several options but the one which I believe matches most closely the question is to be more flexible with what it means to have everything needed to reveal.

The proof assumes you either can or can not reveal while in reality once you have a commitment you can reveal the underlying with enough computation. If we put a hard threshold on computational ability the above proof stands.If we make a weaker requirement, if Alice can reveal with some amount of work Bob can reveal without much more work the problem becomes solvable:

Each side has a random key protecting what is to be revealed, each side supplies a Zero Knowledge proof of having such a key. The keys are gradually revealed, each time with ZK proof the prefix is correct. If the proof doesn't pan out in one iteration the first diverging party has only a limited advantage in brute forcing the remaining key.

Meir Maor
  • 12,053
  • 1
  • 24
  • 55
0

TLDR; Practically, either

  • Schnorr mu-sig on both messages + adaptor between two messages:
    • where $msg_A$ has $Pub_A=adaptPub(msg_B, Pub_{Bob} + Pub_{Alice})$ adapted to $msg_B$ pubkey $Pub_B = Pub_{Bob} + Pub_{Alice}$.
    • Mus-sig on $msg_B$, which is $Sig_{Bob} + Sig_{Alice}$ is then transformable to mu-sig on $msg_A$ as $sig_A = adaptPk(msg_B, Sig_{Bob} + Sig_{Alice})$.
    • It is called "Schnorr adaptor signatures", the algorithm for adaptPub and adaptPk is trivial and on the internet.
    • Interactive signing process ($+$ operation) is symmetric, can be done in any order (but with Schnorr nonce R pre-commitments, adaptation would need an R pre-commitment too).
  • or, if messages pubkeys cannot be modified (they committed already): Bitcoin "barrier escrow" conditioned atomically on BOTH individual message's signatures to unlock mutual security deposit. Message signature can be adapted to transaction signature (tied to a message content and pubkey). Existing, committed, message pubkey can be adapted to transaction output pubkey. Two pubkeys can be summed into one - thus giving atomicity.

    • Note: you can only adapt pubkeys/signatures one way - known pubkey to "special" derived one. Cannot adapt arbitrary signature to even your own pubkey (it would break security of that signature). That is why messages with committed pub-keys would require bitcoin contract.

In both cases - you have to know or be able to enumerate content of the message in order to adapt pubkey for it. Both parties have to pre-commit and exchange $R$ (nonce) per signing session.

In one sentence: For specially tweaked pub-keys, mutually signing $msg_A$ - would automatically reveal signature for $msg_B$.

Modern cryptography to the rescue!

Long version:

There is a special case with Bitcoin DLC (and any atomic swap). In simple case of binary option, there are two transactions to atomically sign: one that would benefit Alice, another that would benefit Bob.

Naive implementation of this contract would allow Alice to avoid signing as soon as Bob revealed signature for transaction that would only benefit Alice.

Turns-out, while it is impossible to sign CET-transaction that would benefit counterparty while getting the opposite signature in return (it's a dead-lock, an infinite waiting loop), in Bitcoin you can use HTLC: lock outputs unless two pre-images are provided.

Then the scheme goes almost as easy as commitments in Schnorr musig. Both Alice and Bob publish commitment-hashes (in any order). Then they create CET transactions: each locked with BOTH hashes (each script is OP_SHA256 <commitment1> OP_EQUALVERIFY OP_SHA256 <commitment2> OP_EQUALVERIFY). After this - they can exchange pre-images in any order - one pre-image cannot do anything. It is either MAD (mutually assured destruction) of funds or two pre-images (agreement). One pre-image won't work.

This still requires an extra security deposit - since pre-images cannot be swapped atomically (unless some SMPC decryption exists), so party would have to be penalized for non-participation.

So, while signing two messages with a curve or RSA symmetrically is impossible. More complicated scheme with committing hashes is.

It is not limited to blockchain or cryptocurrency. Anyone can be verifier of authenticity - using preimage-commitment scheme.

Interpreter of the proof just must understand commitment protocol where on top of signature - two preimages of two hashes is required (or two signatures of two public keys).

As part of every message you about to co-sign of course (have to pre-commit co-signers in each message content), it ain't magic :).

This scheme, combined with Schnorr adaptor signatures would also allow to swap private keys atomically (or rather reveal them to public). This would require a security deposit, penalty for non-participation. Basically Bitcoin allows you to create outputs that are only unlockable by publishing private key (cannot sign with it - only publish, see Schnorr adaptor) to a given public key.

If Alice and Bob create transaction that requires their both private keys to unlock their escrow - then the only way to get their funds back - would be to reveal PKs.

Schnorr also allows you to adapt a signature to a message known in advance (e.g. data from Oracle) as a signature for BTC-transaction. That's where your problem gets solved practically - create barrier escrow locked with signatures for message A and B.

Put funds together into this escrow locked with sigs to your custom messages. Either of parties does not participate - they both loose funds.

Example of Shnorr adaptor signature use for Contract Oracle. Don't be confused - no third-party needed for your scheme above, since Alice and Bob are mutual oracles themselves. Schnorr can work even off-chain without miners. I just added webdoc to clarify Schnorr math.

dk14
  • 101
  • 3