Misc DEx clarifications

[zathras-crypto]

Topic 1 - Regular DEx should be restricted to one sell offer per address period, not one sell offer per currency. Allowing concurrent MSC & TMSC sells from the same address allows concurrent accepts from the same address for MSC & TMSC. In the scenario that a user has open accepts to the same seller for both MSC & TMSC, there is no order of precedence defined as to which accept a BTC payment should be applied to. We could do via transaction indexing, or provide weighting to MSC, but the simplest model is to simply say concurrent MSC & TMSC sells are not allowed (not particularly restrictive in my view) as this follows the approach for crowdsales.

Topic 2 - The sentence restricting buys-from-self should be removed. Initially I was pro blocking buys-from-self however DexX has made a very good case against blocking buys-from-self (related to not 'skipping' price levels if owned by same person during auto-matching). Same rule should be applied to both DEx & Meta-DEx. All current codebases currently allow buys-from-self.

Topic 3 - We should explicitly define that any DEx trades that result in a zero amount on one side of the trade are invalid. Eg 0.1 MSC for 0 SP is invalid. 0.1 MSC for 0.0000001 SP is valid.

Please discuss :)

[dexX7]

Fully agree. +1

[ghost]

Agreed on Topic 1 & 2

Regarding Topic 3 - we should keep in mind that if we make a choice for the user ( such as invalidate MSC purchases for metaDex) this behavior cannot be applied to normal BTC payments (there won't be a 'refund' if the user makes a mistake in this ecosystem [MSC/BTC] ) which is only due to the fact we are exerting some control over the ecosystem to 'do the right thing' and refund the user's money. The behavior may be desirable, however, to just not refund the user in this case to match the behavior of the Bitcoin ecosystem.

[zathras-crypto]

Re topic 3 - if you send 0.01BTC at a unitprice of say 100000000BTC/MSC the amount of MSC purchased with be 0. Whether the transaction is invalidated, or validated with a value of 0 purchased is the same in my book - both cases the user loses the BTC and receives nothing in return. Thus: 0 purchased - invalid and 0 purchased - valid are the same thing in my book (BTC lost either way), invalid/valid is semantics only here I think.

[m21]

Topic 1 - fully agreed as well. Please disallow concurrent selloffers from same address.

There is currently an ambiguity on how the payment is applied which is actually different in several implementations from what I've heard: chronologically (per accept order), sequentially (currency 1=MSC, 2=TMSC) or perhaps even randomly somewhere.

[marv-engine]

Re Topic 1- there's also a conflict if one address has an active sell offer (tx20) and a crowdsale (tx51) that accepts bitcoins. Which one gets the bitcoins that are sent to this address? (My thought is to use a new tx that is a ledger advice transaction, e.g. it lets the user express "the next Send from this address to that address is to be applied to that address's open txNN". The advice could include the amount that will be sent and/or a time limit in blocks that this advice applies. This has a cost, but it has more benefit.)

Re Topic 2 - why is it the right thing to allow buys & trades with self? Is it just that "All current codebases currently allow buys-from-self."?

Re Topic 3 - agree, dEx trades that result in "zero amount on one side of the trade are invalid."

[dexX7]

Re: self-trades:

Say, on the meta-DEx, first field is price:

21.50 XLTC/XBTC (available, 80, belongs to user C)
21.00 XLTC/XBTC (available: 30, belongs to user B)
20.00 XLTC/XBTC (available: 50, belongs to user A)

If user D creates an inverted order to buy 75 token at a price of maximal 22.00 XLTC/XBTC, then the updated orderbook would look like this:

21.50 XLTC/XBTC (available, 80, belongs to user C)
21.00 XLTC/XBTC (available: 5, belongs to user B)

But what would happen, if not user D, but user A had issued the order? The first price level would be skipped, if self trades were disallowed:

21.50 XLTC/XBTC (available, 35, belongs to user C)
20.00 XLTC/XBTC (available: 50, belongs to user A) < skipped

Does that make sense? I don't think so, especially not, if it's hidden in the UI which order belongs to whom. From an outside perspective it looks like orders are for some reason skipped.

[marv-engine]

Is there any reason why a user would deliberately do a self-trade using meta-dEx (tx21)? I can't think of any. It's a non-productive transaction that the user would not be able to opt out of. There are reasons why a user would not want to do a self-trade. As for "it looks like orders are for some reason skipped" - that can be addressed with explanatory text in the UI, and all the tx information is available to a user so he could see the details if he wanted to.

[dexX7]

I don't have an argument for self-trading, but also none against. I tend to prefer to allow things instead of disallowing them, but all that aside, skipping trades is a strong argument imho. Why do you think it might be more reasonable to disallow it explicitly?

[marv-engine]

Why do you think it might be more reasonable to disallow it explicitly?

Because:

1. the user doesn't have a way to say "Don't match with my own orders"
2. the order is no longer available to other, "real" buyers
3. the buyer didn't net more coins - that could be harder to explain to the user
4. when he eventually realizes what happened, the buyer has to repost the order (and pay another tx fee) which goes to the end of the line
5. no one gains any value from a self-trade (other than a miner)
6. I don't think anyone would find it a satisfying experience
7. Tx22 (accept a sell offer) says "The purchaser’s address must be different than the seller’s address."

The Transferring Coins text says "Transfers are unconditional payments from one Mastercoin address to another address, ...", but the validity checks don't require that the receiving address be different from the sending address.

[dexX7]

Thanks, but that's still not reasonable. Skipping orders basically means you sell at a lower price and at the same time you're buying at a higher price. If you are already selling MSC for 0.2 BTC/MSC, would you want to buy for 0.22 BTC/MSC?

This actually leads me to an idea.. one could invert the position this way (via self trade) quickly. Instead of cancel/new order, one order where you'd buy your own tokens (to cancel) + some more (which you wanted to buy) is sufficient.

[marv-engine]

@dexX7 I still don't understand why anyone would want to buy anything from himself.

Something else I don't understand - if a user is selling A for B, why would he want to buy A for B?

[dexX7]

I still don't understand why anyone would want to buy anything from himself. ... if a user is selling A for B, why would he want to buy A for B?

Right, this is what I meant with "I have not really an argument for this" and either way: with or without self-trades there is no use-case (which I know of) which justifies selling and buying at the same time (given a similar or worse price). Assuming users act reasonable, it doesn't matter anyway.

So this is not really a question of "why should one do it", but "which choice has less downsides or a lower cost [to implement]". The argument in this context was that skipping orders may create the impression of a broken matching engine. zathras mentioned all explorers currently allow self-trading, so the second argument is "the additional logic required to block self-trades explicitly" (which is not limited to the current explorers, but also required in new ones).

[marv-engine]

I prefer to avoid unproductive transactions that have negative side effects, e.g. buying from oneself, and I'm more comfortable providing an explanation why.

@zathras-crypto @faizkhan00 does your tx22 code enforce this? If not, why not?

Tx22 (accept a sell offer) says "The purchaser’s address must be different than the seller’s address."

[ghost]

currently the code does not enforce restrictions to send to self, but the proposed changes in the OP suggest restrictions that make this finalization (codewise and spec) clear

[dacoinminster]

OK - I've read through this. I think the right things to do are:

1) If an address tries to do two things at once which accept bitcoins, the second operation is invalid. This fixes all collisions between selling MSC, selling TMSC, and crowdfunding 2) No matter what we do with the "buys from self" logic, there are big downsides. I don't see a clear winner. So, I believe we should do what is simpler in code: allow buys from self. The REAL solution is that our UIs should warn people if they are about to execute a trade which could result in a buy-from-self.

[marv-engine]

Allowing buys from self is simpler to code in the protocol because it puts all the burden on the UI code to warn the user, and then the burden transfers to the user if the trade goes thru. The user now has to recognize what happened and then reissue the tx21, and go to the end of the line.

[dexX7]

... avoid unproductive transactions that have negative side effects, e.g. buying from oneself ...

Marv, just to make sure: do you acknowledge the reasons for self-trading, but prefer no self-trading for the reasons you outlined above or is it unclear and seems just silly? I just want to make sure, because it's not my intent to weight arguments against each other or "defend" either side, but to give an explanation to the rather short introduction of the first post. :)

My points are in particular: no self trading has negative effects, too and there is especially no reason for an user to create orders which result in skipping.

[dacoinminster]

Several of us discussed this on Sococo, and the consensus seemed to be that we would allow these self-buys. However, the discussion was still going when my laptop suddenly started having problems and I got kicked off. Was there more after I left?

[marv-engine]

@dacoinminster I'll update the spec to reflect your recommendations above.