Post
Topic
Board Development & Technical Discussion
Re: Atomic swaps using cut and choose
by
TPTB_need_war
on 19/02/2016, 17:36:15 UTC
Sorry I have thought deeply and there is no solution for decentralized exchange. Although I love it ideologically and I was very positive on you doing it, I unfortunately have to conclude that is not viable and should be abandoned. I am trying to help you not waste time on deadends. I invested my effort precisely because I wanted to help you.

Sorry, you are wrong. Maybe it will be the first time this happens? I believe that it is quite difficult to prove a negative, in spite of your claims. While I just need to make it work, and since I have quite a lot of techniques at my disposal, I am very optimistic I will get it to work.

I wrote that because I see an inviolable generative essence that there is no reference point. Both parties to the exchange trade are equal in status without a trusted third party. You can see this has been proven by academics for any "simultaneous contract signing". I had seen a PPT with references to the literature and can't find it now, but for example here is another paper:

I’m Not Signing That!
James Heather and Daniel Hill

1 Introduction
Often it is desirable to have a procedure to allow two parties to sign a contract
simultaneously. The obvious danger of having one party sign before the other is
that the second party may refuse to sign until it becomes to his advantage to do
so. For instance, suppose the contract is for Alice to buy 1,000 shares in Fudge
Labs, Inc., from Bob, at £1 per share, in a year’s time. If Alice signs first, Bob
may then delay signing until the end of the year. If the price has fallen, he will
sign, the contract will be binding on both parties, and he will make a profit; if
the price has risen, he will not sign. A similar problem will arise if Bob signs
first. Because the market changes over time, anything that allows one party the
option of delaying the decision on whether to commit will cause problems.
Simultaneity in message transmission is, in most practical situations, im-
possible to achieve, making cryptographic contract-signing protocols difficult to
realize. A trusted third party can be employed to receive the two signatures and
then distribute them, but it is clearly advantageous to construct a protocol that
does not require action on the part of a third party unless there is suspicion of
foul play by one of the parties involved in the contract.
In this paper, we examine a cryptographic contract-signing protocol that
aims to solve these problems by making the probability that one party can
abuse the protocol arbitrarily small. We demonstrate that the protocol has a
curious weakness: two rational agents whose rationality is common knowledge
will refuse to run the protocol at all.

Or this paper (which you may want to read as it talks about probabilistic solutions):

Quote from: Kremer, S., Raskin, J.F.: Game Analysis of Abuse-free Contract Signing
In 1980, Even and Jacobi [8] showed no deterministic contract signing protocol exists, without participation of a trusted third party (TTP).



You have no economically viable attack.

Only of we ignore externalities (external economic motivation). The same applies to the erroneous claim that proof-of-stake is as secure as proof-of-work.

Just because something is possible, that doesnt mean it is certain to happen, especially when it is economically non-viable.

As non-viable as Nxt being controlled by a dictator and Bitshares being controlled by two centralized exchanges.


The question is what will the real world failure rate be. I claim that NOBODY is able to predict this ahead of time.

IMHO, we should endeavor to analyze that before expending great effort on implementation.

Btw, I am not belittling the toolset you've developed, our shared ideological motivation, etc.. Just trying to be level-headed and rational.

My point was that purely DE will not work. You and TierNolan are apparently proposing a slightly centralized design with a trusted third party. It is well known in literature that TTP and/or probabilistic protocol is necessary.