Although script_valid.json and script_invalid.json are loaded correctly by the
JSON interpreter used by bitcoin core, these same files are often used by other
libraries and do not necessarily load correctly due to the fact that newlines
contained inside strings are not valid and must instead use the escape
character \n. The files tx_valid.json and tx_invalid.json handle this
correctly, so I've changed the formatting in script_valid.json and
script_invalid.json to mirror those files.
362001c Move CHECKMULTISIG order tests out of automatically generated block (Pieter Wuille)
f67a9ce Use deterministically generated script tests (Pieter Wuille)
Now that signing is deterministic, we can require exact correspondence between the
automatically generated tests and the ones read from JSON. Do this, and update
the tests to those deterministic versions. Note that some flag changes weren't
correctly applied before.
1. Remove the default format (binary) because `rest/block/<hash>/Hex` would end up delivering binary data.
2. List available formats when chosen format was not found (reduces need for documentation)
3. Change url syntax to dot extension like format chosing (like `rest/tx/<hash>.json`
9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true. (Ruben Dario Ponticelli)
a2d0fc6 Fix IsInitialBlockDownload which was broken by headers first. (Ruben Dario Ponticelli)
5dc713b [REST] set REST API behind "-rest" option (Jonas Schnelli)
78bdc81 [REST] give an appropriate response in warmup phase (Jonas Schnelli)
210eba9 [REST] fix headersonly flag for BINARY responses (Jonas Schnelli)
- add newly added variables to the constructor init
- move an already existing bool also to constructor init
- move a connect call to setClientModel and add a NULL pointer check
There are 3 pieces of data that are maintained on disk. The actual block
and undo data, the block index (which can refer to positions on disk),
and the chainstate (which refers to the best block hash).
Earlier, there was no guarantee that blocks were written to disk before
block index entries referring to them were written. This commit introduces
dirty flags for block index data, and delays writing entries until the actual
block data is flushed.
With this stricter ordering in writes, it is now safe to not always flush
after every block, so there is no need for the IsInitialBlockDownload()
check there - instead we just write whenever enough time has passed or
the cache size grows too large. Also updating the wallet's best known block
is delayed until this is done, otherwise the wallet may end up referring to an
unknown block.
In addition, only do a write inside the block processing loop if necessary
(because of cache size exceeded). Otherwise, move the writing to a point
after processing is done, after relaying.
