Order format which enables gossip

[cjdelisle]

The order id is nominally a UUID but since the originator of the order can make it up, this id can't be trusted to be unique. As long as there is a full mesh and everyone stores the originator of every order along with the order, this is irrelevant, but if one node can forward an order for another then it falls down.

In a gossip scenario, we should imagine that we want to have orders exist for some period of time and then timeout, unless re-created by their originator. The structure I would use is:

byte[64] signature;
byte[32] pubkey;
uint32 timestamp_secs; // drop if more than 3 hours old or 10 minutes in future
byte[] request_asset_id;
uint64 request_amount;
byte[] offer_asset_id;
uint64 offer_amount;
optional byte[64] replace_order_id;

And the order id would be defined as the hash of the wire encoded structure. Additionally use of two uint64s (request_amount and offer_amount) rather than a float64 (price) dodges the thorny issue of float rounding.

Finally, an order offering 0 for 0 can be defined as a withdrawal order and the use of replace_order_id can define what order is being withdrawn.

[kilrau]

Would be interested in your thoughts here too @LePremierHomme @hatmer

[hatmer]

Given that the OpenDEX specs define Google Protocol Buffers, the byte[] fields will be string.

Special precaution will need to be taken in implementation to ensure that malicious participants cannot cancel other participants' orders.

OrderInvalidation Messages become unneeded which is a nice feature.

I like this idea since it adds clarity and is beneficial for scaling.

[cjdelisle]

Special precaution will need to be taken in implementation to ensure that malicious participants cannot cancel other participants' orders.

Implementations should be required to compare pubkey of an order update to the original and ensure that the timestamp is newer. But those are cheap operations because you need to pull the original order from the map in order to update it anyway.

[hatmer]

A side note: a purely selfish participant will not forward messages. We could perhaps incorporate XUC payments to incentivise forwarding, similar to how Bitcoin users pay fees to incentivise miners to include transactions in blocks.

[LePremierHomme]

@cjdelisle

1. At the moment the order id uniqueness doesn’t need to be trusted, as it is handled separately for every originator, and if the originator fails to apply uniqueness, his order will be dropped. This can be continued to be supported in a gossip scenario where pubkey/signature are applied to every order.
   But the UUID solution was merely temporary IIRC, and I agree that in the gossip model it is better to be changed to be defined as the hash of some fields.

2. request_amount/offer_amount instead of price - sounds good.

3. request_asset_id/offer_asset_id instead of pair_id - sounds good.

4. timestamp_secs-based timeout - sounds good.

5. Finally, an order offering 0 for 0 can be defined as a withdrawal order and the use of replace_order_id can define what order is being withdrawn.

Order Invalidation is currently supported. What you suggest can replace it for full removals, but will impose creating a new order upon partial validation. This actually might be superior since it's keeping orders “immutable”.

@hatmer

A side note: a purely selfish participant will not forward messages. We could perhaps incorporate XUC payments to incentivise forwarding, similar to how Bitcoin users pay fees to incentivise miners to include transactions in blocks.

Cryptocurrency nodes are usually not incentivised to forward gossip messages or to sync historical data. In OpenDEX case, this courtesy might be worse because nodes might have an incentive to not forward messages, to prevent trading competition. It might even make them reverse the recommended taker/maker model where incoming orders are expected to be matched by later own/local orders, and not against existing ones (which are expected to be matched by peers).
But this is not related to the order format, so we can discuss this on a different issue thread.

[hatmer]

Yes, making sure that nodes don't disrupt the network by not gossipping the orders will be a challenge to overcome. The two types of solutions that come to mind are using a trusted core set (probably at least 1/3 of the network) of nodes that always behave correctly, or having an algorithm that can figure out if a peer is not forwarding orders and penalize its reputation.