<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Step 1: Alice formulates a contract document C, assigns to it a unique<br>
identifier, generates with visual cryptography a pair (X, Y), signs X<br>
and sends a message containing signed(Alice, X) and Y and a promise<br>
(a conditioned commitment) that she will sign Y in case Bob signs X and<br>
Y, to Bob.</blockquote><div><br></div><div>As you stated previously, Alice's "promise" is enforceable in court by Bob, so as soon as Alice sends her promise, she is bound while Bob is not, and therefore the protocol fails any reasonable definition of "fairness".<br><br></div><div>Also note that to the extent your protocol depends on "time", i.e., that actions must be taken within a certain time, a third party notary would be required to certify the timestamps, since it is not possible for the parties to do this themselves.<br><br></div><div>Finally, the protocol is still insufficiently specified IMO, in that it does not include a clear and complete discussion of all the different scenarios and conditions that can arise during the execution of the protocol and how those would be handled.<br><br></div><div>I think this thread has run its course and no further discussion would be beneficial, since no progress has been made at fixing the protocol or addressing its shortcomings despite the many emails pointing out the various issues.<br></div></div><br></div></div>