[Cryptography] Proposal of a fair contract signing protocol

Natanael natanael.l at gmail.com
Sun Jun 12 21:23:54 EDT 2016


Den 13 jun 2016 02:20 skrev "Ron Garret" <ron at flownet.com>:

> 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.

A signs, encrypts with a unique secret key, encrypts the key with a
proof-of-work style time puzzle (parallelization resistant) that takes at
least X time on a single CPU core to compute, where X exceeds the agreed
timeout (the puzzles can be built in parallel, just create many small
chains and encrypt the start of each with the end of another - and throwing
away some bits make it probabilistic and increases the work factor through
bruteforce guessing).
A creates a Zero-knowledge proof of correctness, showing that his signature
under this scheme is valid as agreed, verifiable before the plaintext
becomes accessible.
Demand a signature in response from B within the timeout period.
You can also use cryptographic timestamping of the initiation, etc, so that
you can prove you published your responses as agreed - anybody who cancels
will fail to publish within the time period (to publish a valid response is
by definition to NOT cancel).

The issues remain that ZKP is untested, incredibly slow to generate and
that your usecases are very limited.

Best case: the timeout is weeks to months, but you sign early and share the
key directly after receiving the counter-signature, in a context where you
can predict the maximal single core performance against the puzzle and
where the contents automatically become non-sensitive after the timeout /
deadline. Hardly relevant in any other usecase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160613/2ca4353f/attachment.html>


More information about the cryptography mailing list