Arbitrary order within blockheight in get_history

[dagurval]

Rationale: This was useful for wallets when topological order was enforced. But with CTOR this no longer serves purpose.

The clients are also able to determine this order themselves after CTOR activation.

[cculianu]

But with CTOR this no longer serves purpose.

Yes it does. It specifies a fixed ordering for get_history which is useful for simple clients that just concatenate the history they receive to compute the status hash.

In fact I think that the status_hash specification says to compute the hash using the order of the tx's as they came in from get_history e.g. blockchain order.

EDIT: See here: https://bitcoincash.network/electrum/protocol-basics.html#status

The clients are also able to determine this order themselves after CTOR activation.

Perhaps -- but that just puts extra onus on the clients. Why make life harder for the clients?

It's nice for the client to know the history will arrive in blockchain order. This ordering is required for the status_hash.

So.. they don't have to do any extra processing/sorting/etc themselves in order to compute the scripthash_status_hash.

With this change it just gets harder to implement a client. Ideally Electrum Cash protocol can even be used by very light scripts to do blockchain querying / address watching, etc.

I disagree with this change. I think it makes implementing a client harder. The server should give the same dog food to the client it expects back (eg, for computing status hashes).

[cculianu]

I want to reiterate in a summary why I think this change is a step backwards:

• It's imperative that all server implementations agree on the same status_hash calculation given the same history. This is so that clients can switch servers without having to download huge histories every time. If the status hashes don't change when switching servers, clients don't download the history redundantly.
• In order for that to be the case, it's easiest on light clients for the get_history to return the history in the same order as used for calculating the status_hash

I suspect you suggested this change because at present ElectrsCash does not return the history in the proper order (I have observed this to be the case), and I suspect that perhaps you are tempted to relax the spec/restriction for that reason.

If you do that, then you will have to relax the status_hash specification as well. And that's just a bad idea given my first bullet point above.

So.. I think it would be a step backward to change the spec as suggested in this PR.

[cculianu]

Also I want to point out that all existing installations of Electron Cash assume get_history is already in the proper order and do no sorting.

There are 10k or more installations of this client out there. And not everybody updates to latest.

So if we relax this restriction, all older clients will redundantly download history each time they connect to a different server because they assume get_history is in order and they use this ordering to calculate the status_hash.

What's more -- for blocks and tx's in a history before the Nov. 15 2018 fork -- there is no CTOR. Histories before that date cannot be arbitrarily ordered -- they must come in blockchain order.

Anyway, I hope my long exposition here has convinced you this is a bad idea.

[dagurval]

This was a bad idea, thanks for the feedback