<p dir="ltr"><br>
Den 13 jun 2016 02:20 skrev "Ron Garret" <<a href="mailto:ron@flownet.com">ron@flownet.com</a>>:</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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).<br>
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.<br>
Demand a signature in response from B within the timeout period. <br>
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). </p>
<p dir="ltr">The issues remain that ZKP is untested, incredibly slow to generate and that your usecases are very limited.</p>
<p dir="ltr">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. </p>