[Cryptography] Proposal of a fair contract signing protocol
mok-kong.shen at t-online.de
Mon Jun 13 17:50:05 EDT 2016
Am 12.06.2016 um 21:43 schrieb Ron Garret:
> On Jun 12, 2016, at 11:21 AM, mok-kong shen <mok-kong.shen at t-online.de> wrote:
>> Am 12.06.2016 um 20:13 schrieb mok-kong shen:
>>> Am 12.06.2016 um 05:34 schrieb Ron Garret:
>>>> On Jun 11, 2016, at 1:45 AM, mok-kong shen <mok-kong.shen at t-online.de>
>>>>> [Addendum:] Remark: The message sent by Alice in step (1) looks like
>>>>> the following and is as a whole piece encrypted with Bob's public key
>>>>> and signed by Alice.
>>>>> ...... some text ...... Here is the X-part of VC signed by me:
>>>>> signed(Alice,X) ......Here is the Y-part of VC: Y ......
>>>>> some text ……
>>>> This doesn’t work because:
>>>>> Note that after step (2) Alice cannot innocently refuse to perform step
>>>>> (3), since the pair (X,Y) stems from her.
>>>> Alice can refuse by (falsely) claiming that she sent (S(X), Z) instead
>>>> of (S(X), Y). If this were not the case (i.e. if Alice could not
>>>> plausibly make this false claim), then Alice would already be
>>>> committed after sending (S(X), Y), and the protocol would cease to be
>>> But her message to Bob was sent with signcryption, i.e. with her
>>> signature ensuring the correctness of its content (which includes Y).
>> [Addendum:] Sorry I forgot to write:
>> To your 2nd point, one could explicitly have the convention that only signed(A, U) means A commits to U, nothing else.
> In that case, Alice is not committed after Bob signs (but Bob is) and again, the protocol is unfair.
Sorry, I don't yet see your point. Bob has the freedom to commit or
not commit. If he chooses to commit, then Alice is immediately obliged
to commit. Isn't that good enough?
M. K. Shen
> The details don’t matter. Logically, there are only two possibilities:
> 1. Alice is actually committed after Bob signs, in which case the protocol is unfair to Alice.
> 2. Alice is not actually committed after Bob signs, in which case the protocol is unfair to Bob.
> This is the reason that in real life, commitment protocols work by the first party extending an offer with a time limit for acceptance, and the second party either accepting the offer (in which case the first party is bound — i.e. option 1 above) or making a counter-offer, in which cast they become the offering party and the protocol iterates. The protocol is fair not because the commitment happens simultaneously, but because the offering party controls the offer and thus cannot be coerced into agreeing to terms that they do not actually accept.
> What you have is not a fair commitment protocol, but rather a protocol where an offering party (Alice) can reneg on their offer by not completing the protocol, but her defection can be publicly proven. This may be useful, but it isn’t “fair” in the sense that it imposes time-symmetric commitments on the parties.
> There are real-world examples of your kind of protocol too. When you buy something from a merchant, there is a period of time where either you have paid but have not yet taken possession of the goods, in which case the merchant can reneg by refusing to hand the goods over, or there is a period of time where you have taken possession but not yet paid, in which case the merchant is extending you credit, and you can reneg by defaulting on the debt. Defections are rare enough that there is usually no formal method for dealing with them for everyday retail transactions. In cases where it really matters, like buying real estate, a trusted third party (an escrow agent) is employed to effect the transfer. If someone truly came up with a way to produce a fair commitment protocol that did not require a trusted third party, it would destroy the escrow industry. That is another reason that I strongly suspect it’s not possible.
More information about the cryptography