- Unicode header IDs filter
- Change some links to use the new ID formula
(It matches the GitHub-Flavored Markdown standard closely.)
- Build script changes
Avoid confusing use of "secret key" and add some relevant links.
Also, it's no longer true (and hasn't been for a long time) that transaction signatures are different every time. That was from before rippled started using deterministic nonces ([RFC6979](https://tools.ietf.org/html/rfc6979)).
sign - Fix formatting
Fix a typo, and update a "default" value to current style guidelines.
sign - missing "a"
Addresses changes implemented in https://github.com/ripple/rippled/pull/2642
- Missing fields result in `invalidParams`
- Accounts not found in the ledger result in `{src/dst}ActNotFound`
A trailing comma was left in the last item of the `result.problems` array in the JSON-RPC example response of noripple_check.
I'm actually creating json files with the examples to mock responses in unit tests for the library I'm writing, so my tests found it. I wouldn't have noticed otherwise. I'm grateful we have example responses to review and copy!
Similar to PR #409 except the deprecated `ledger` param was used in the websocket request example, while `ledger_index` was used in the JSON example.
This PR removes those parameters on both examples. I also removed the word `Optional` from the `Type` column since the convention seems to be to indicate that in the description field.
Note: The Commandline request example has `[ledger_index]`, however the syntax suggests it's an optional argument and not an flagged option (i.e. `--ledger_index=current`), so it seems proper to leave that as is.
The `ledger` parameter is now `ledger_index`, which is optional and defaults to current. This PR removes the `ledger` param from the example requests.
I had opened a PR to simply change `ledger` to `ledger_index`, however the conventions of the API docs seem to only use required parameters, so I closed that PR and created this one instead.
The `hotwallet` parameter of `gateway-balances()` didn't seem like the type of parameter that needs to be required. I tested the API w/o it and it returned successfully.
