Accept strings containing decimal values, in addition to bare values.
Useful from JSON-RPC implementations where it's not possible to have
direct control over the text of numbers (e.g. where numbers are always
doubles), and it's still desired to send an exact value.
This would allow users to post JSON content with numbers encoded like
`{"value": "0.00000001"}` instead of `{"value": 0.00000001}` which some
php/python encoders wrap into 1e-8, or worse.
JSON makes no distinction between numbers and reals, and our code
doesn't need to do so either.
This removes VREAL, as well as its specific post-processing in
`UniValue::write`. Non-monetary amounts do not need to be forcibly
formatted with 8 decimals, so the extra roundtrip was unnecessary
(and potentially loses precision).
Zcash: cherry-picked from commit 7650449a6777710cf818d41862626164da0cd412
Left over from 2aee461930
Since unspendable outputs can't be spent, there is no threshold at which it would be uneconomic to spend them.
This primarily targets transaction outputs with `OP_RETURN`.
---
Initially based on:
commit 9cf0ae26350033d43d5dd3c95054c0d1b1641eda
Author: zathras-crypto <zathrasc@gmail.com>
Date: Wed Mar 25 02:04:02 2015 -0700
Changes:
- cherry-picked on top of bitcoin:master
- added RPC test for fundrawtransaction
I've never liked the chain-specific exception to having to set a
password. It gives issues with #6388 which makes it valid to
set no password in every case (as it enables random cookie authentication).
This pull removes the flag, so that all chains are regarded the same.
It also removes the username==password test, which doesn't provide any
substantial extra security.
request object before returning an error so that id value can
be used in the response.
Prior to this commit, RPC commands sent during Bitcoin's
warmup/startup phase were responded to with a JSON-RPC error
with an id of null, which violated the JSON-RPC 2.0 spec:
id: This member is REQUIRED. It MUST be the same as the value
of the id member in the Request Object. If there was an error
in detecting the id in the Request object (e.g. Parse
error/Invalid Request), it MUST be Null.
For leveldb "An iterator operates on a snapshot of the database taken
when the iterator is created". This means that it is unnecessary to
lock out other threads while computing statistics, and neither to hold
cs_main for the whole time. Let the thread run free.
Univalue's parsing of \u escape sequences did not handle NUL characters
correctly. They were, effectively, dropped. The extended test-case
fails with the old code, and is fixed with this patch.
Test prioritisetransaction
After talking with @str4d about #1884 , I wrote a test for prioritisetransaction. It uses small blocks (11kb), and checks whether a transaction makes it into the next block after being prioritized by that node.
Should this be improved with a larger number of txs in the mempool, or by testing over multiple runs?
As for getblocktemplate(), it seems to return the prioritized transaction within the block size set by the node (about 50 txs fit in an 11kb block), but the block "sizelimit" it displays is set at 2 MB in `rpcmining.cpp` line 690:
```
result.push_back(Pair("sizelimit", (int64_t)MAX_BLOCK_SIZE));
```
This was quite confusing, I didn't think the `-blockmaxsize` parameter I was setting was working for awhile.
Jack Grigg