[Cryptography] Proposal of a fair contract signing protocol

[Allen]

On Fri, Jun 24, 2016 at 6:56 PM, mok-kong shen <mok-kong.shen at t-online.de>
wrote:

> Did you read what in step 1 Alice promises to do if Bob commits? If Bob
> commits in step 2 and Alice doesn't do step 3 then she breaks her
> promise and Bob could suit her. Note once again that if a contract
> doesn't come into being for technical or human reasons, my definition
> of unfairness is never touched upon, for the definition assumes a
> valid document, i.e. step 3 is completed.
>

I read what you specifically said constitutes a valid contract: the
published outputs from Step 3.  Now you want to amend your definition to
say that Step 1 constitutes an enforceable "promise" by Alice?  Under your
amended definition, if Step 1 constitutes an enforceable "promise", then
after Step 1, only Alice is bound and Bob is not.  That is pretty clearly
an unfair protocol.

>From the beginning, this proposed protocol has been ambiguous, non-specific
and incomplete.  I personally believe that any effort to complete the
protocol by making it specific, unambiguous and complete will simply
demonstrate that, without relying on a third party, it is not possible to
construct a "fair" protocol in the sense that no party is bound while the
other is not, that at no time does the completion of the contract depend on
the action of only one party which he or she may defer or fail to complete,
and that at all times when a valid contract exists, both parties are
equally able to enforce it.  If you would like to repost the entire
proposed protocol, making it 100% specific, unambiguous and complete, with
every single condition or combination of conditions that constitute a valid
contract fully specified, including all inputs and complete abbreviated
tests for validity, then I'll look at it one more time.  But please make
sure it complete, fully specified and works as advertised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160624/be18ad75/attachment.html>