e1749b50a3 exclude x11 dir from linting (pasta)
dc1f566fce fmt: run clang-format on hash_x11.h (pasta)
bd8aa04d44 refactor: segregate x11 hashing (pasta)
Pull request description:
## Issue being fixed or feature implemented
Refactor x11 hashing out into it's own header
## What was done?
move x11 hashing out of hash.h, into hash_x11.h and also move those headers crypto/x11 folder
## How Has This Been Tested?
Building
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have added or updated relevant unit/integration/functional/e2e tests
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK e1749b50a3
Tree-SHA512: c5e9ac9995608b1963494a4e6d870bb452972d6c09387c06546623e25c8be26fd2918918fb00fbef0c0356c61f1bed127a469c5adae252792f25bc419c73100b
In upcoming commits, message sending will be split off into a separate
file and stats capabilities will be fleshed out. Prepare for that by
giving it its own directory.
Also get rid of `statsd` namespace, it is entirely unnecessary.
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
c92387232f750397da7d131f262c150a608408c2 refactor: Extract ParseOpCode from ParseScript (João Barbosa)
Pull request description:
Seems more natural to have `mapOpNames` "hidden" in `ParseOpCode` than in `ParseScript`.
A second lookup in `mapOpNames` is also removed.
ACKs for top commit:
laanwj:
ACK c92387232f750397da7d131f262c150a608408c2
theStack:
re-ACK c92387232f750397da7d131f262c150a608408c2
Tree-SHA512: d59d1964760622cf365479d44e3e676aa0bf46b60e77160140d967e012042df92121d3224c7551dc96eff5ff3294598cc6bade82adb3f60d28810e18e60e1257
dcda81c47101196e53e379d965a2692515ef8363 test: add coverage for script parse error in ParseScript (pierrenn)
Pull request description:
Follow up on this suggestion : https://github.com/bitcoin/bitcoin/pull/18416#issuecomment-603966799
This adds a test case to raise the `script parse error` in `ParseScript`.
ACKs for top commit:
instagibbs:
utACK dcda81c471
Tree-SHA512: ae0ef2c00f34cee818c83582f190d5f4043159e922862f2b442b7b895b8ff3ca421533699247c12c367be77813b5205830a771cd47a18e8932807ccace2d6a1c
9c5af58d51 Consolidate redundant implementations of ParseHashStr (Ben Woosley)
Pull request description:
This change:
* adds a length check to all calls to `ParseHashStr`, appropriate given its use to populate
a 256-bit number from a hex str
* allows the caller to handle the failure, which allows for the more
appropriate `JSONRPCError` on failure in `prioritisetransaction` rpc
Relative to #14288
Tree-SHA512: baa791147e5ceb3c30c70df3981aaf807bf7d4a90a0be3625540b59aa4b9a9d303a452bfef18bf167cbb833ef9591b4ef5948bf4a1ce67b421d804ae8d20ea53
e306be742932d4ea5aca0ea4768e54b2fc3dc6a0 Use 72 byte dummy signatures when watching only inputs may be used (Andrew Chow)
48b1473c898129a99212e2db36c61cf93625ea17 Use 71 byte signature for DUMMY_SIGNATURE_CREATOR (Andrew Chow)
18dfea0dd082af18dfb02981b7ee1cd44d514388 Always create 70 byte signatures with low R values (Andrew Chow)
Pull request description:
When creating signatures for transactions, always make one which has a 32 byte or smaller R and 32 byte or smaller S value. This results in signatures that are always less than 71 bytes (32 byte R + 32 byte S + 6 bytes DER + 1 byte sighash) with low R values. In most cases, the signature will be 71 bytes.
Because R is not mutable in the same way that S is, a low R value can only be found by trying different nonces. RFC 6979 for deterministic nonce generation has the option to specify additional entropy, so we simply use that and add a uin32_t counter which we increment in order to try different nonces. Nonces are sill deterministically generated as the nonce used will the be the first one where the counter results in a nonce that results in a low R value. Because different nonces need to be tried, time to produce a signature does increase. On average, it takes twice as long to make a signature as two signatures need to be created, on average, to find one with a low R.
Having a fixed size signature makes size calculations easier and also saves half a byte of transaction size, on average.
DUMMY_SIGNATURE_CREATOR has been modified to produce 71 byte dummy signatures instead of 72 byte signatures.
Tree-SHA512: 3cd791505126ce92da7c631856a97ba0b59e87d9c132feff6e0eef1dc47768e81fbb38bfbe970371bedf9714b7f61a13a5fe9f30f962c81734092a4d19a4ef33
57889e688dd0987a1e087cd48d216a413127601e bitcoin-tx: Stricter check for valid integers (Daniel Kraft)
Pull request description:
Just calling `atoi` to convert strings to integers does not check for valid integers very thoroughly; in particular, it just ignores everything starting from the first non-numeral character. Even a string like "foo" is fine and silently returns 0.
This meant that `bitcoin-tx` would not fail if such a string was passed in various places where an integer is expected (like the `locktime` or an input/output index); this means that it would, for instance, silently accept a typo and interpret it in an unexpected way.
In this change, we use `ParseInt64` for parsing strings to integers, which actually verifies that the full string is valid as number. New tests in the `bitcoin-util-test` cover the new error paths.
This fixes#13599.
Tree-SHA512: 146a0af275e9f57784e5d0582d3defbac35551b54b6b7232f8a0b20db04aa611125e52aa4512ef2f8ed2cafc2a12fe586f9d10ed66d641cff090288f279b1988
619bb05 Squashed 'src/univalue/' changes from 16a1f7f6e..fe805ea74 (MarcoFalke)
Pull request description:
The subtree-merge commit also fixes the whitespace for failing tests, such that bisect doesn't break.
Finally, the bump also includes the changes that accidentally modified our subtree, such that the subtree check should work fine now:
```sh
./contrib/devtools/git-subtree-check.sh src/univalue
Tree-SHA512: 3009d1e52b6f41ef89ecc8a000649f08e44395538703f294995a6e913e3fbfb7813d6bd31fdb4acb6127fd4af99c095bf980a12f1f026bb27cacc66e1487cd1e
ce07638 doc: Add comment to use ValueFromAmount/AmountFromValue for JSON, not utilmoneystr (Wladimir J. van der Laan)
ec05c50 rpc: Use ValueFromAmount instead of FormatMoney in TxToUniv (Wladimir J. van der Laan)
46347ad rpc: Move ValueFromAmount to core_write (Wladimir J. van der Laan)
dac3782 doc: Correct AmountFromValue/ValueFromAmount names (Wladimir J. van der Laan)
Pull request description:
With this, the amounts returned in `decoderawtransaction` will be padded to 8 digits like anywhere else in the API.
This is accomplished by using `ValueFromAmount` in `TxToUniv`, instead of `FormatMoney` which it currently (mistakingly) uses. The `FormatMoney` function is only for debugging/logging use!
To avoid dependency issues, `ValueFromAmount` is moved to `core_write.cpp`, where it also fits better. I don't move `AmountFromValue` to `core_read.cpp` at the same time, as this would have more impact due to the RPCError dependency there.
(n.b.: large number of changed files is solely due to the util_tests JSONs needing update)
Tree-SHA512: 10fc2d27d33a77dbcb57aa7eccd4f53110c05d38eb7df6d40f10f14c08fad4274472e93af75aa59fe68ad0720fdf0930f0108124abef518e0dd162b3d2b2b292
* Merge #8824: Refactor TxToJSON() and ScriptPubKeyToJSON()
0ff9320 refactor TxToJSON() and ScriptPubKeyToJSON() (jonnynewbs)
Tree-SHA512: caf7d590829e221522edd5b1ab8ce67b53a2c6986d3bbe8477eab420b1007bf60f885ed0a25ba9587e468c00768360ddc31db37847e862858573eaed5ed8b0d6
* remove witness and vsize
Signed-off-by: Pasta <Pasta@dash.org>
* Add valueSat
To preserve rpc output format
* Move extrapayload and special tx json output to `TxToUniv`
* Add spent index info
