This is a bunch of "raw ideas" to solve the limited-allowed-jurisdiction situation DEX's (exchanges with centralized hosting) located in many countries must abide by. Please share the idea around as I hope people who could make it happen will consider it. I will never make anything like this happen, but I just hope to see something like it happen.
I am sure the idea is not new, but now might be a good time because of the recent "Anyhedge" code developments? Don't like one or more of my sub-ideas? No worries, I have no intention to try to have any control over development of this project. Do it any way you want.
****** The D-Dex *********
A Distributed Decentralized non-custodial Exchange
Distributing the hosting to provide the DEX with censorship resistance is the dream here. I suggest it be hosted by 100,000? computers* each with a special DDex wallet that can trade and hold all the crypto's and tokens the exchange can trade. The host computer would get a small fee (see below). The chance of a trade being hosted in a particular wallet could be random (or random with modified chances based on past-performance and/or hosting resources offered by that computer and/or time since last opportunity to be a host). The last modifier could be used to keep industrial efforts to dominate and partly centralize the hosting less effective? A diverse and widely dispersed set of hosts seems like a good goal.
Since this does not require massive computational power I hope it would be easy to keep this "ASIC resistant" enough to let regular people participate as hosts even if this becomes popular. Can one computer have more than one wallet? Trying to stop this might be difficult with virtual machines and such. I think it might dilute the resources a computer was offering to the network by reusing the same resources but the wallet might be able to monitor that?
Hosting incentives and fees
Hosting would be funded by a TX fee of (0.01%?) of each trade. The fee would be paid by the one that offers the trade and be denominated in the token they are offering. A minimum fee of the smallest amount of the token could turn out to be too large if a whole token is the smallest division. I have not really thought up the solution to that yet. Maybe a toggle to allow BCH to be used for the fee with a warning reminder about the minimum fee (when the fee is a large amount compared to the number of traded items?) and that BCH is an option?.
Ongoing development and marketing might be funded from the trades as well if that is planned in from the beginning? A maximum, shrinking maximum or time limit might be good. The team with commit access would be able to change this (or anything else) since they would be in control. So picking those "benevolent rulers" would be very important.... They might come up with a way they can govern each other, but I would rather we did not need to hope they mean well and will continue to do that. My next idea makes this difficult.
Securely-anonymous accounts and keeping them that way
For the project and the developers safety, I think a good way to set this up would be to have the development team consist of many people, but the accounts with "commit access" or comparable powers (that could be used to destroy or limit the DDex) should be newly created anonymous accounts ready to "pull a Satoshi" if the situation gets too hot for comfort.
Making securely-anonymous accounts is not easy and may not be safe to try to use on Github if they require JavaScript be enabled to make posts on the site (I have not checked on this). I believe hostile-government backdoor access into sites like Github could allow trojans inserted with JavaScript that help de-anonymize users. Governments that do not already have this access can often get this access when they claim they have a "need" for it or strong-arm site owners they capture. I mention this in case there might be a better place (for privacy) to do the development.
There might be an automated? provision that any that become known to the public lose their commit-power to protect the project from outside influences? It might also be ideal to have the project lock itself down so no changes can be made at some point? This would solve the centralized-development concern.
* Controlling the number of wallets
I am also proposing a requirement that one or more "Drop", "Spice" or other native token(s) "staked" in the wallet (plus some minimum computer resources available) would allow the wallet to host trades on the network. This "key" allows the number of hosts to be controlled if the token has no further "minting ability". It also adds value and demand for the Key tokens. If the hosting becomes popular this limit makes the chances of any one computer getting to host a trade higher. If more are needed due to massive adoption, the staking requirement can be lowered to 0.5 tokens or some other amount. The staked token can always be recovered disabling that wallet's hosting ability.
(a light on the wallet dashboard?: Green = Hosting enabled, Red = no token staked, Yellow = token staked but computer resources insufficient to join the network.)
Why DROP or Spice?
The people friendly to DeToken or Spice might help support or encourage support for the project (maybe anonymously for liability reasons) if their "drop" or "Spice" token was chosen as the native token. I really like those ideas because I own some Drop/Spice, I also think the developers familiar with those tokens know people who are up to making this idea happen and I believe in those team's goals and understanding of the legal situation. Also, I do not want to make something that is a potential competitor to those teams ongoing business ideas without trying to make it beneficial to at least one of them.
If the team chose to create a new native token instead (DDex or D-Dex?) I suggest at least 2 decimals and a permanently limited supply under 300 thousand. I would also appreciate receiving a bunch of them for suggesting some of the ideas for this project (and because I am broke and unable to buy any).
Why not BCH?
Why not BCH as the native token? Because there are too many of them to allow them to be used to limit the number of wallet hosts without having the "staking requirement" be so many BCH (something like 1/100,00th of total supply) you might have to be rich to become a host. Making the hosts rich by adding value to the currently inexpensive SLP token they have staked is a concern, but may be less concerning if the number of tokens staked can be lowered because the total supply is not too high.
Initial funding of development
A flipstarter might work well to fund this if respected people proposed to support the creation by a specific anonymous team.
How to get a trustworthy Anonymous team?
I am concerned this might get set up by scammers or by people unable to resist the lure of easy money once it becomes popular. The anonymous control aspect has real potential drawbacks. A possible solution might be to have a group of people vouch for each anonymous account. Having a person of a group know who it is but have no one else know which person knows could be a solution. To do that, three or more different groups of 10+ known-trustworthy people could be set up and have one of the (3 or more) anon' accounts dox themselves to one person in their designated group. Then the group would pass out voting tokens or some other way of voting anonymously. Then they all vote "yes" if they know and trust the person and "No" if they do not know who it is. One Yes vote would approve the account. Two or more "yes" votes would disqualify the account for being too well known. This idea is un-vetted and just a recent thought.
Thanks for considering these ideas.
I would be happy to help with more brainstorming (especially if you see some difficulty that makes you think the idea is not feasible).
Edit: I think optimizing the network and wallet for use from TOR without requiring Javascripts be enabled would be ideal even if very difficult.
