Elliot.

I don't think it makes sense to require the signer list to be ordered when submitting transactions that modify the list. As @thejohnfreeman suggested, each new amendment carries some cost....

> Thoughts regarding the version flag: if that same flag would also change the behaviour of other version related options, one would never be able to use the previous (current,...

Note, I'm not saying that this is a perfect solution or avoids all potential problems. We are just trying to make the best trade-off given our goals and constraints. Using...

I think it's fine to have this use `"ripplerpc": "3.0"`. In fact, that might actually be preferable; I hadn't thought of it as an option before. `ripplerpc` affects HTTP, but...

I would wait for confirmation from @WietseWind before merging, though :)

Also, it's important that this gets documented on xrpl.org. We should also document the difference between ripplerpc 1.0 and 2.0, if we haven't already.

If we want to follow the HTTP status codes: - `200 OK` means the request was successfully received, understood, and accepted. The response includes the requested resource - `503 Service...

Instead of "uri", a better name for the field might be "source"

> How about replacing the `uri` field with `source_peer` and `source_url`. The `source_peer` field would reference the peer that **first provided the list**, and the `source_url` field would be filled...

@niso1985 - After getting `telINSUF_FEE_P`, does your transaction ultimately succeed (after some time)? You'll need to query (e.g. using `tx`) to see if that's the case. `telINSUF_FEE_P` is a provisional...