DEx Phase 2.0 - is it valid to desire more tokens than there are?

[marv-engine]

For instance, if tx50 (Fixed Issue) was used to issue 100 Centurions, is 101 a valid value for Amount desired in tx21?

I don't think the same question applies to tokens issued with tx55 (Grant tokens) because the number issued can change at any time.

[marv-engine]

As I think about it, it seems to be ok because the following scenario is possible (though maybe not realistic):

1. A1: 101 MSC for sale, desire 101 Centurions
2. A2: 75 Centurions for sale, desire 75 MSC
   • 75 of each transferred to the other address
   • A1's order is now 26 MSC for sale, desire 26 Centurions
3. A1 sends 30 Centurions to A2 for some reason
4. A2: 30 Centurions for sale, desire 30 MSC
   • 26 of each transferred to the other address
   • A1 has now received 101 Centurions (75 + 26)
   • A2: now 4 Centurions for sale, desire 4 MSC

Any flaws in the logic or arithmetic?

[m21]

I would allow it:

1. Dream on - like on normal Dex you can "desire" 50 Million BTC.
2. Any (artificial) restrictions on field values will limit the choice of price ratios.

[zathras-crypto]

Agreed, you are simply expressing a desired value. More complexity than necessary to add filters here.

If you express to high a desired value (eg more tokens than exist) you are simply pricing too high and won't find any matches (ie no harm done)

[marv-engine]

My questions such as this start with determining what's the correct thing to do. Complexity is an implementation issue, which plays a part only if the aspect in question is correct.

[dexX7]

@marv-engine: complexity is generally used to characterize something with many parts where those parts interact with each other in multiple ways. The complexity of an implementation is one aspect that should not have weight or a mention in the spec imho (some decisions of @dacoinminster were based on this though), but the complexity on an abstract and logical level should. Transactions should be optimized with the goal of less potential states and minimal dependencies.

In my opinion desiering an amount that might not be available should be valid and this is not only based on complexity, but because a transaction in this context expresses an intend and not a command. I use those words freely and this is of course up to interpretation, but some examples:

"User A has a balance of 10 MSC and then sends 20 MSC." - This statement is false and there is no situation where something like this would be possible, because a user can only send what he or she owns. A transaction that tries to send 20 MSC in this context should be invalid.

"User B intends to buy something." - This does not depend on what the user intends to buy and the meaning wouldn't change, even if it's impossible to satisfy the desire.

Two more: a crowdsale of tokens X (main ecosystem) that can be paid for by some other tokens Y (main ecosystem) should be valid, even if those tokens to pay with do not exist. On the other hand: a transaction that would create a crowdsale where main ecosystem tokens are demanded, but test ecosystem tokens issued, should be invalid.