Cancel-everything: should only cancel all of one ecosystem

[dexX7]

1. A1 starts with 50.0 MSC, 50.0 TMSC, 50 MIndiv1 and 50.0 TDiv1
2. A1 offers 50.0 MSC for 50.0 MDiv1
3. A1 offers 50.0 TMSC for 50 TIndiv1
4. A1 cancels everything in the test ecosystem (50.0 TMSC, 50 TIndiv1)

This should only cancel the offer in the test ecosystem, but it appears to cancel-everything and the scope is not limited to the given ecosystem.

Related test lines: test_cancel_everything_scope.py#L143-L540

[zathras-crypto]

Interesting point - spec is ambiguous on this - I actually agree with DexX on what I think is good behaviour but spec doesn't explicitly state that it is eco dependent, rather giving impression everything is cancelled regardless of anything else:

"CANCEL-EVERYTHING cancels all open orders for all currencies."

[dexX7]

Hm. The reason I tend to believe it's limited to one ecosystem is the note about an explicit ecosystem field here:

OmniLayer/spec#284 (comment)

[ghost]

I think for consistency with not allowing cross-ecosystem trades in tx21, the cancel's should also only apply to one ecosystem (with cross-ecosystem behaviors being removed)

[m21]

Then the spec needs to be changed to indicate that? I am fine either way.
@marv-engine

[dexX7]

It's currently undefined and ambigious.

[dacoinminster]

I think it is not limited to an ecosystem currently, and the spec should
reflect that.

On Mon, Dec 1, 2014 at 9:49 AM, dexX7 [email protected] wrote:

It's currently undefined and ambigious.

—
Reply to this email directly or view it on GitHub
#219 (comment)
.

[dexX7]

@dacoinminster: it's not a question, if it is limited to an ecosystem, but if it should be. Unless exceptional circumstances are given, current behavior should not dictate what ends up in the spec, but the other way around and adding such a limitation seems trivial and should not have any weight here.

I created OmniLayer/spec#290 and if you have an opinion on this, please go ahead.

[dacoinminster]

Well, changing the code is more than trivial - it affects not just the spec
and code, but also RPC interface. When the code gets ahead of the spec I
tend to go with the code unless there is an obvious problem with the way it
was implemented. Perhaps this slightly violates the "sandbox" intention of
Test MSC, but I'd point out that most testing is now taking place on
testnet, so we probably shouldn't care.

That said, if the devs want to change this for some reason, I have no
objection to changing the spec too.

I'll paste this comment in issue #290 too.

On Mon, Dec 1, 2014 at 12:55 PM, dexX7 [email protected] wrote:

@dacoinminster https://github.com/dacoinminster: it's not a question,
if it is limited to an ecosystem, but if it should be. Unless
exceptional circumstances are given, current behavior should not dictate
what ends up in the spec, but the other way around and adding such a
limitation seems trivial and should not have any weight here.

I created OmniLayer/spec#290
OmniLayer/spec#290 and if you have an
opinion on this, please go ahead.

—
Reply to this email directly or view it on GitHub
#219 (comment)
.

[dexX7]

Addressed by #223.

[marv-engine]

I'm just seeing this now but my thinking is that all actions take place
within an ecosystem, which had to be clearly indicated in the tx message.

On Monday, December 1, 2014, Michael [email protected] wrote:

Then the spec needs to be changed to indicate that? I am fine either way.
@marv-engine https://github.com/marv-engine

—
Reply to this email directly or view it on GitHub
#219 (comment)
.

Marv Schneider
VP, User Experience/Product Usability
Engine, Inc.
[email protected]