mininode now supports witness transactions/blocks, blocktools
has a helper for adding witness commitments to blocks, and script
has a function to calculate hashes for signature under sigversion
1, used by segwit.
Py3 conversion by Marco Falke
Test to make sure upgraded nodes don't ask for non-wit blocks by
Gregory Sanders.
7982fce doc: Mention full UTF-8 support in release notes (Wladimir J. van der Laan)
6bbb4ef test: test utf-8 for labels in wallet (Wladimir J. van der Laan)
a406fcb test: add ensure_ascii setting to AuthServiceProxy (Wladimir J. van der Laan)
60ab9b2 Squashed 'src/univalue/' changes from 2740c4f..f32df99 (Wladimir J. van der Laan)
ff2dcf2 Tests: Edit bloated varint test and add option for 'barely expensive' tests (mrbandrews)
12c5a16 Catch exceptions from non-canonical encoding and print only to log (mrbandrews)
291f8aa Continuing port of java comptool (mrbandrews)
8c9e681 Tests: Rework blockstore to avoid re-serialization. (mrbandrews)
Add a setting ensure_ascii to AuthServiceProxy. This setting,
defaulting to True (backwards compatible),
is passed through to json.dumps. If set to False, non-ASCII characters
>0x80 are not escaped. This is useful for testing server
input processing, as well as slightly more bandwidth friendly in case of
heavy unicode usage.
Previously these functions would infinitely loop if sync failed;
now they have a default timeout of 60 seconds, after which an
AssertionError is raised.
sync_blocks() has also been improved and now compares the tip
hash of each node, rather than just using block count.
We can't change "softforks", but it seems far more logical to use tags
in an object rather than using an "id" field in an array.
For example, to get the csv status before, you need to iterate the
array to find the entry with 'id' field equal to "csv":
jq '.bip9_softforks | map(select(.id == "csv"))[] | .status'
Now:
jq '.bip9_softforks.csv.status'
There is no issue with fork names being incompatible with JSON tags,
since we're selecting them ourselves.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Check the Content-Type header that is returned from the RPC server. Only
if it is `application/json` the data is supposed to be parsed as JSON.
This gives better reporting if the HTTP server happens to return an error that is
not JSON-formatted, which is the case if it happens at a lower level
before JSON-RPC kicks in.
Before: `Unexpected exception caught during testing: No JSON object could be decoded`
After: `JSONRPC error: non-JSON HTTP response with '403 Forbidden' from server`
