On further thought, I have decided that my suggestion for coin age is useless by itself and I need to add the following to make it work as intended (while coin age remains necessary else the attacker could use a mixer to create new UXTO that escape the decentralized reputation system I will suggest below).
DoS by jamming is the paramount threat to decentralized exchange that needs to be solved first. If this isn't solved, then it isn't worth pursuing because for sure the government will be against exchanges which they can't regulate to enforce KYC, etc (this will become more so in 2017). Governments have unlimited funds to attack with (e.g. $4+ trillion went missing from the DoD budget and finances the DEEP STATE). Please don't tell me that Donald Rumsfeld and Bill Moyers aren't mainstream and reliable sources.
There is no way to solve the jamming problem by relying on the two block chains that are doing the trade, because someone always has to go first, thus someone will always get jammed. If the honest person never goes first, then no one will go first. Simple logic.
The only way I can hope to fix this problem is to have a separate block chain for recording the intention to enter a trade, and with this block chain track those UXTO which are bailing out and thus users can refuse to trade with them. Again this requires the coin age to prevent the attacker from using a mixer to subvert the tracking by UXTO. Also coin age is necessary so someone doesn't get inadvertently blocked forever due to some glitch on their end where they couldn't follow through on the protocol.
One way I contemplated is to have both parties sign the intention to trade, then they post it to this block chain. However, one might sign and the other might not, thus jamming the other party (in terms of computing the signature and the communication latency between the two parties). Also worse is that one party might sign more than one intention to trade or inadvertently do so if the attacker didn't sign immediately but later signed and published it to this block chain.
Thus the first requirement is we need a way for both to sign where the signature isn't valid if they both didn't complete the signing protocol. I am not sure if this can be accomplished. I would need to think about some variant of Shamir's How to Share a Secret crossed with "simultaneous contract signing". Something like a Diffie-Hellman exchange (but that is sharing a symmetric key) where either party can then sign on behalf of both parties proving that the Diffie-Helman exchange occurred.
If the prior paragraph can be achieved, then the jamming that remains is only on latency of the protocol in the prior paragraph, yet this is still a jamming problem. There is no way for the user who is being jammed to share his UXTO blacklist with other users since the attacker could Sybil attack such sharing.
So thus I conclude that decentralized exchange is probably not going to work unless there is some reputation system. But then when I consider reputation system designs, they can also be Sybil attacked. It seems the only possible solution would be a Web of Trust similar to PGP wherein I decide to trust those who trust me and vice versa. But the problem with Web of Trust in this context is the attacker can Sybil attack it by first gaining trust, then violating trust thus causing the Web of Trust to be unstable.
Sigh.
If anyone can think of a solution at the conceptual level (never mind what block chains currently offer), I would love to read it.
So far decentralized exchange looks to be jammable in every design I've contemplated.
You can make it connected with the trade by having the final steps in the protocol release the fee. If the trade doesn't complete both sides lose money.
But my point is the jamming will come before that connection has been established.
Also if both sides lose money when one side bails, then the attacker can cause the innocent party to go bankrupt.
You are ostensibly dismissing the case of the attacker who can charge the cost of the attack to collective. Right at this moment, China's mining cartel controls an estimated 65% of Bitcoin's hashrate and they have vetoed every block size increase (even Classic's reasonable doubling to 2MB), and they apparently have very low electricity costs so it isn't unthinkable that with a "wink and a handshake" this electricity is coming for free from Three Gorges Dam. The fact that I have proven they must have lied about the bandwidth problem (since of course they could put a pool abroad and just relay the hashes across the Great Firewall of China). One motivation could possibly be to force transaction fees higher and reap more profits.
So there is already circumstantial evidence that the attack scenario I am worried about is not impossible.
DoS by jamming is the paramount threat to decentralized exchange that needs to be solved first. If this isn't solved, then it isn't worth pursuing because for sure the government will be against exchanges which they can't regulate to enforce KYC, etc (this will become more so in 2017). Governments have unlimited funds to attack with (e.g. $4+ trillion went missing from the DoD budget and finances the DEEP STATE). Please don't tell me that Donald Rumsfeld and Bill Moyers aren't mainstream and reliable sources.
There is no way to solve the jamming problem by relying on the two block chains that are doing the trade, because someone always has to go first, thus someone will always get jammed. If the honest person never goes first, then no one will go first. Simple logic.
The only way I can hope to fix this problem is to have a separate block chain for recording the intention to enter a trade, and with this block chain track those UXTO which are bailing out and thus users can refuse to trade with them. Again this requires the coin age to prevent the attacker from using a mixer to subvert the tracking by UXTO. Also coin age is necessary so someone doesn't get inadvertently blocked forever due to some glitch on their end where they couldn't follow through on the protocol.
One way I contemplated is to have both parties sign the intention to trade, then they post it to this block chain. However, one might sign and the other might not, thus jamming the other party (in terms of computing the signature and the communication latency between the two parties). Also worse is that one party might sign more than one intention to trade or inadvertently do so if the attacker didn't sign immediately but later signed and published it to this block chain.
Thus the first requirement is we need a way for both to sign where the signature isn't valid if they both didn't complete the signing protocol. I am not sure if this can be accomplished. I would need to think about some variant of Shamir's How to Share a Secret crossed with "simultaneous contract signing". Something like a Diffie-Hellman exchange (but that is sharing a symmetric key) where either party can then sign on behalf of both parties proving that the Diffie-Helman exchange occurred.
If the prior paragraph can be achieved, then the jamming that remains is only on latency of the protocol in the prior paragraph, yet this is still a jamming problem. There is no way for the user who is being jammed to share his UXTO blacklist with other users since the attacker could Sybil attack such sharing.
So thus I conclude that decentralized exchange is probably not going to work unless there is some reputation system. But then when I consider reputation system designs, they can also be Sybil attacked. It seems the only possible solution would be a Web of Trust similar to PGP wherein I decide to trust those who trust me and vice versa. But the problem with Web of Trust in this context is the attacker can Sybil attack it by first gaining trust, then violating trust thus causing the Web of Trust to be unstable.
Sigh.
If anyone can think of a solution at the conceptual level (never mind what block chains currently offer), I would love to read it.
So far decentralized exchange looks to be jammable in every design I've contemplated.
I have my strong intuitive (generative essence) sense that I will find a flaw in any method of using a fee to block the attacker who wants to jam the protocol, because the fee can't be atomic with the trade
You can make it connected with the trade by having the final steps in the protocol release the fee. If the trade doesn't complete both sides lose money.
But my point is the jamming will come before that connection has been established.
Also if both sides lose money when one side bails, then the attacker can cause the innocent party to go bankrupt.
You are ostensibly dismissing the case of the attacker who can charge the cost of the attack to collective. Right at this moment, China's mining cartel controls an estimated 65% of Bitcoin's hashrate and they have vetoed every block size increase (even Classic's reasonable doubling to 2MB), and they apparently have very low electricity costs so it isn't unthinkable that with a "wink and a handshake" this electricity is coming for free from Three Gorges Dam. The fact that I have proven they must have lied about the bandwidth problem (since of course they could put a pool abroad and just relay the hashes across the Great Firewall of China). One motivation could possibly be to force transaction fees higher and reap more profits.
So there is already circumstantial evidence that the attack scenario I am worried about is not impossible.