aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-07-01random: get rid of GetRand by inliningPieter Wuille
2024-07-01wallet: update mempool conflicts tests + docsishaanam
2024-07-01util: Use SteadyClock in RandAddSeedPerfmonMarcoFalke
2024-07-01random: make GetRand() support entire range (incl. max)Pieter Wuille
The existing code uses GetRand(nMax), with a default value for nMax, where nMax is the range of values (not the maximum!) that the output is allowed to take. This will always miss the last possible value (e.g. GetRand<uint32_t>() will never return 0xffffffff). Fix this, by moving the functionality largely in RandomMixin, and also adding a separate RandomMixin::rand function, which returns a value in the entire (non-negative) range of an integer.
2024-07-01tests: overhaul deterministic test randomnessPieter Wuille
The existing code provides two randomness mechanisms for test purposes: - g_insecure_rand_ctx (with its wrappers InsecureRand*), which during tests is initialized using either zeros (SeedRand::ZEROS), or using environment-provided randomness (SeedRand::SEED). - g_mock_deterministic_tests, which controls some (but not all) of the normal randomness output if set, but then makes it extremely predictable (identical output repeatedly). Replace this with a single mechanism, which retains the SeedRand modes to control all randomness. There is a new internal deterministic PRNG inside the random module, which is used in GetRandBytes() when in test mode, and which is also used to initialize g_insecure_rand_ctx. This means that during tests, all random numbers are made deterministic. There is one exception, GetStrongRandBytes(), which even in test mode still uses the normal PRNG state. This probably opens the door to removing a lot of the ad-hoc "deterministic" mode functions littered through the codebase (by simply running relevant tests in SeedRand::ZEROS mode), but this isn't done yet.
2024-07-01random: convert XoRoShiRo128PlusPlus into full RNGPieter Wuille
Convert XoRoShiRo128PlusPlus into a full RandomMixin-based RNG class, providing all utility functionality that FastRandomContext has. In doing so, it is renamed to InsecureRandomContext, highlighting its non-cryptographic nature. To do this, a fillrand fallback is added to RandomMixin (where it is used by InsecureRandomContext), but FastRandomContext still uses its own fillrand.
2024-07-01random: move XoRoShiRo128PlusPlus into random modulePieter Wuille
This is preparation for making it more generally accessible.
2024-07-01xoroshiro128plusplus: drop comment about nonexisting copy()Pieter Wuille
2024-07-01random: modernize XoRoShiRo128PlusPlus a bitPieter Wuille
Make use of C++20 functions in XoRoShiRo128PlusPlus.
2024-07-01random: add RandomMixin::randbits with compile-known bitsPieter Wuille
In many cases, it is known at compile time how many bits are requested from randbits. Provide a variant of randbits that accepts this number as a template, to make sure the compiler can make use of this knowledge. This is used immediately in rand32() and randbool(), and a few further call sites.
2024-07-01random: Improve RandomMixin::randbitsPieter Wuille
The previous randbits code would, when requesting more randomness than available in its random bits buffer, discard the remaining entropy and generate new. Benchmarks show that it's usually better to first consume the existing randomness and only then generate new ones. This adds some complexity to randbits, but it doesn't weigh up against the reduced need to generate more randomness.
2024-07-01random: refactor: move rand* utilities to RandomMixinPieter Wuille
Rather than make all the useful types of randomness be exclusive to FastRandomContext, move it to a separate RandomMixin class where it can be reused by other RNGs. A Curiously Recurring Template Pattern (CRTP) is used for this, to provide the ability for individual RNG classes to override one or more randomness functions, without needing the runtime-cost of virtual classes. Specifically, RNGs are expected to only provide fillrand and rand64, while all others are derived from those: - randbits - randrange - randbytes - rand32 - rand256 - randbool - rand_uniform_delay - rand_uniform_duration - min(), max(), operator()(), to comply with C++ URBG concept.
2024-07-01random: use BasicByte concept in randbytesPieter Wuille
2024-07-01random: add a few noexcepts to FastRandomContextPieter Wuille
2024-07-01random: move rand256() and randbytes() to .h filePieter Wuille
2024-07-01random: write rand256() in function of fillrand()Pieter Wuille
2024-07-01Merge bitcoin/bitcoin#30237: test: Add Compact Block Encoding test ↵glozow
`ReceiveWithExtraTransactions` covering non-empty `extra_txn` 55eea003af24169c883e1761beb997e151845225 test: Make blockencodings_tests deterministic (AngusP) 4c99301220ab44e98d0d0e1cc8d774d96a25b7aa test: Add ReceiveWithExtraTransactions Compact Block receive test. (AngusP) 4621e7cc8f8e2b71393a2b30d5dbe56165bfb854 test: refactor: Rename extra_txn to const empty_extra_txn as it is empty in all test cases (AngusP) Pull request description: This test uses the `extra_txn` (`vExtraTxnForCompact`) vector of optional orphan/conflicted/etc. transactions to provide transactions to a PartiallyDownloadedBlock that are not otherwise present in the mempool, and check that they are used. This also covers a former nullptr deref bug that was fixed in #29752 (bf031a517c79cec5b43420bcd40291ab0e9f68a8) where the `extra_txn` vec/circular-buffer was null-initialized and not yet filled when dereferenced in `PartiallyDownloadedBlock::InitData`. ACKs for top commit: marcofleon: Code review ACK 55eea003af24169c883e1761beb997e151845225. I ran the `blockencodings` unit test and no issues with the new test case. dergoegge: Code review ACK 55eea003af24169c883e1761beb997e151845225 glozow: ACK 55eea003af24169c883e1761beb997e151845225 Tree-SHA512: d7909c212bb069e1f6184b26390a5000dcc5f2b18e49b86cceccb9f1ec4f874dd43bc9bc92abd4207c71dd78112ba58400042c230c42e93afe55ba51b943262c
2024-07-01Merge bitcoin/bitcoin#30306: fuzz: Improve stability for txorphan and ↵merge-script
mini_miner harnesses e009bf681c0e38a6451afa594ba3c7c8861f61c3 Don't use iterator addresses in IteratorComparator (dergoegge) Pull request description: See #29018. Stability for `txorphan` is now >90%. `mini_miner` needs further investigation, stability still low (although slightly improved by this PR) at ~62%. ACKs for top commit: marcofleon: Tested ACK e009bf681c0e38a6451afa594ba3c7c8861f61c3. Using afl++, stability for `txorphan` went from 82% to ~94% and for `mini_miner` it went from 84% to 97%. I ran them both using the corpora in qa-assets. glozow: utACK e009bf681c0e38a6451afa594ba3c7c8861f61c3 Tree-SHA512: 6d0a20fd7ceedca8e702d8adde5fca500d8b0187147aee8d43b4e9eb5176dcacf60180f42a7158f037d18dbb27e479b6c069a0f3c912226505cbff5aa073a415
2024-07-01Merge bitcoin/bitcoin#30273: fuzz: FuzzedSock::Recv() don't lose bytes from ↵merge-script
MSG_PEEK read 4d81b4de339efbbb68c9785203b699e6e12ecd83 fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read (Vasil Dimov) b51d75ea97ee0d01ee586e40a30cb68c0bf7ffd3 fuzz: simplify FuzzedSock::m_peek_data (Vasil Dimov) Pull request description: Problem: If `FuzzedSock::Recv(N, MSG_PEEK)` is called then `N` bytes would be retrieved from the fuzz provider, saved in `m_peek_data` and returned to the caller (ok). If after this `FuzzedSock::Recv(M, 0)` is called where `M < N` then the first `M` bytes from `m_peek_data` would be returned to the caller (ok), but the remaining `N - M` bytes in `m_peek_data` would be discarded/lost (not ok). They must be returned by a subsequent `Recv()`. To resolve this, only remove the head `N` bytes from `m_peek_data`. --- This is a followup to https://github.com/bitcoin/bitcoin/pull/30211, more specifically: https://github.com/bitcoin/bitcoin/pull/30211#discussion_r1633199919 https://github.com/bitcoin/bitcoin/pull/30211#discussion_r1633216366 ACKs for top commit: marcofleon: ACK 4d81b4de339efbbb68c9785203b699e6e12ecd83. Tested this with the I2P fuzz target and there's no loss in coverage. I think overall this is an improvement in the robustness of `Recv` in `FuzzedSock`. dergoegge: Code review ACK 4d81b4de339efbbb68c9785203b699e6e12ecd83 brunoerg: utACK 4d81b4de339efbbb68c9785203b699e6e12ecd83 Tree-SHA512: 73b5cb396784652447874998850e45899e8cba49dcd2cc96b2d1f63be78e48201ab88a76cf1c3cb880abac57af07f2c65d673a1021ee1a577d0496c3a4b0c5dd
2024-06-30Moved the repeated -printpriority fetching out of AddToBlockLőrinc
AddToBlock was called repeatedly from `addPackageTxs` where the constant value of `printpriority` is recalculated every time. Since its behavior was changed in 400b151, I've named the variable accordingly. This showed up during profiling of AssembleBlock, fetching it once in the constructor results in a measurable speed increase for many iterations. > ./src/bench/bench_bitcoin --filter='AssembleBlock' --min-time=1000 before: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 155,558.97 | 6,428.43 | 0.1% | 1.10 | `AssembleBlock` after: | ns/op | op/s | err% | total | benchmark |--------------------:|--------------------:|--------:|----------:|:---------- | 148,083.68 | 6,752.94 | 0.1% | 1.10 | `AssembleBlock` Co-authored-by: furszy <mfurszy@protonmail.com>
2024-06-29p2p: Start downloading historical blocks from common ancestorMartin Zumsande
Otherwise, if the background tip is not an ancestor of the snapshot, blocks in between that ancestor up to the height of the background tip will never be requested. Co-authored-by: Martin Zumsande <mzumsande@gmail.com> Co-authored-by: Alfonso Roman Zubeldia <19962151+alfonsoromanz@users.noreply.github.com>
2024-06-28scripted-diff: Log parameter interaction not thriceMarcoFalke
-BEGIN VERIFY SCRIPT- sed -i 's/LogPrintf("%s: \(parameter interaction: .*\)", __func__/LogInfo("\1"/g' ./src/init.cpp -END VERIFY SCRIPT-
2024-06-28doc: Fix outdated dev comment about loggingMarcoFalke
2024-06-28wallet: use LogTrace for walletdb log messages at trace levelAnthony Towns
2024-06-27Merge bitcoin/bitcoin#30335: Mining interface followups, reduce cs_main ↵Ryan Ofsky
locking, test rpc bug fix a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed Have testBlockValidity hold cs_main instead of caller (Sjors Provoost) f6dc6db44ddc22ade96a69a02908f14cfb279a37 refactor: use CHECK_NONFATAL to avoid single-use symbol (Sjors Provoost) 5fb2b704897fe10b5bd5ed754a5afd2ddc4a9e1d Drop unneeded lock from createNewBlock (Sjors Provoost) 75ce7637ad75af890581660c0bb3565c3c03bd6c refactor: testBlockValidity make out argument last (Sjors Provoost) 83a9bef0e2acad7655e23d30e1c52412f380d93d Add missing include for mining interface (Sjors Provoost) Pull request description: Followups from #30200 Fixes: - `std::unique_ptr` needs `#include <memory>` (noticed while working on #30332, which has fewer includes than its parent PR that I originally tested with) - Drop lock from createNewBlock that was spuriously added - Have testBlockValidity hold cs_main instead of caller (also fixes a race condition in test-only code) Refactor: - Use CHECK_NONFATAL to avoid single-use symbol (refactor) - move output argument `state` to the end of `testBlockValidity`, see https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1647987176 ACKs for top commit: AngusP: Code Review ACK a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed itornaza: Tested ACK a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed ryanofsky: Code review ACK a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed. Just new error string is added since last review, and a commit message was updated Tree-SHA512: 805e133bb59303fcee107d6f02b3e2761396c290efb731a85e6a29ae56b4b1b9cd28ada9629e979704dcfd98cf35034e7e6b618e29923049eb1eca2f65630e41
2024-06-27Merge bitcoin/bitcoin#28167: init: Add option for rpccookie permissions ↵Ryan Ofsky
(replace 26088) 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe doc: detail -rpccookieperms option (willcl-ark) d2afa2690cceb0012b2aa1960e1cfa497f3103fa test: add rpccookieperms test (willcl-ark) f467aede78533dac60a118e1566138d65522c213 init: add option for rpccookie permissions (willcl-ark) 7df03f1a923e239cea8c9b0d603a9eb00863a40c util: add perm string helper functions (willcl-ark) Pull request description: This PR picks up #26088 by aureleoules which adds a bitcoind launch option `-rpccookieperms` to set the file permissions of the cookie generated by bitcoin core. Example usage to make the generated cookie group-readable: `./src/bitcoind -rpccookieperms=group`. Accepted values for `-rpccookieperms` are `[owner|group|all]`. We let `fs::perms` handle platform-specific permissions changes. ACKs for top commit: achow101: ACK 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe ryanofsky: Code review ACK 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe. Main change since last review is no longer throwing a skip exception in the rpc test on windows, so other checks can run after it, and overall test result is passing, not skipped. Also were clarifying renames and documentation improvements. tdb3: cr ACK 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe Tree-SHA512: e800d59a44aca10e1c58ca69bf3fdde9f6ccf5eab4b7b962645af6d6bc0cfa3a357701e409c8c60d8d7744fcd33a91e77ada11790aa88cd7811ef60fab86ab11
2024-06-27Merge bitcoin/bitcoin#30050: refactor, wallet: get serialized size of ↵Ava Chow
`CRecipient`s directly a9c7300135f0188daa5bce5491e2daf2dd8da8ae move-only: refactor CreateTransactionInternal (josibake) adc6ab25bba42ce9e7ed6bd7599aabb6dead6987 wallet: use CRecipient instead of CTxOut (josibake) Pull request description: Broken out from #28201 --- In order to estimate fees properly, we need to know what the final serialized transaction size will be. This PR refactors `CreateTransactionInternal` to: * Get the serialized size directly from the `CRecipient`: this sets us up in a future PR to calculate the serialized size of silent payment `CTxDestinations` (see https://github.com/bitcoin/bitcoin/pull/28201/commits/797e21c8c1bf393e668eeef8bb7ee9cae1e5e41e) * Use the new `GetSerializeSizeForRecipient` to move the serialize size calculation to *before* coin selection and the output creation to *after* coin selection: this also sets us up for silent payments sending in a future PR in that silent payments outputs cannot be created until after the inputs to the transaction have been selected Aside from the silent payments use case, I think this structure logically makes more sense. As a reminder, move-only commits are best reviewed with something like `git diff -w --color-moved=dimmed-zebra` ACKs for top commit: S3RK: reACK a9c7300135f0188daa5bce5491e2daf2dd8da8ae achow101: ACK a9c7300135f0188daa5bce5491e2daf2dd8da8ae rkrux: tACK [a9c7300](https://github.com/bitcoin/bitcoin/pull/30050/commits/a9c7300135f0188daa5bce5491e2daf2dd8da8ae) Tree-SHA512: 412e1764b98f7428c8530c3a68f55e32063d6b66ab2ff613e1c7e12d49b049807cb60055cfe7f7e8ffe7ac7f0f9931427cbfd3efe7d4f97a5a0f6d1bf1aaac58
2024-06-27[wallet, rpc]: add `max_tx_weight` to tx funding optionsismaelsadeeq
This allows a transaction's weight to be bound under a certain weight if possible and desired. This can be beneficial for future RBF attempts, or whenever a more restricted spend topology is desired. Co-authored-by: Greg Sanders <gsanders87@gmail.com>
2024-06-27init: add option for rpccookie permissionswillcl-ark
Add a bitcoind launch option `-rpccookieperms` to configure the file permissions of the cookie on Unix systems.
2024-06-27util: add perm string helper functionswillcl-ark
PermsToSymbolicString will convert from fs::perms to string type 'rwxrwxrwx'. InterpretPermString will convert from a user-supplied "perm string" such as 'owner', 'group' or 'all, into appropriate fs::perms.
2024-06-27[wallet]: update the data type of `change_output_size`, `change_spend_size` ↵ismaelsadeeq
and `tx_noinputs_size` to `int` - This change ensures consistency in transaction size and weight calculation within the wallet and prevents conversion overflow when calculating `max_selection_weight`.
2024-06-27[doc]: update reason for deducting change output weightismaelsadeeq
`CoinGrinder` will also produce change output, listing all the Coin selection algorithms that produces change output is not maintainable, just infer that remaining algorithms all might produce change.
2024-06-27[refactor]: update coin selection algorithms input parameter `max_weight` nameismaelsadeeq
- This commit renames the coin selection algorithms input parameter `max_weight` to `max_selection_weight` for clarity. The parameter represent the maximum weight of the UTXOs the coin selection algorithm should select, not the transaction maximum weight. - The commit updates the parameter docstring to provide correct description. - Also updates coin selection unit and fuzzing test variables to match the new name.
2024-06-27Have testBlockValidity hold cs_main instead of callerSjors Provoost
The goal of interfaces is to eventually run in their own process, so we can't use EXCLUSIVE_LOCKS_REQUIRED in their declaration. However TestBlockValidaty will crash (in its call to ConnectBlock) if the tip changes from under the proposed block. Have the testBlockValidity implementation hold the lock instead, and non-fatally check for this condition.
2024-06-27refactor: use CHECK_NONFATAL to avoid single-use symbolSjors Provoost
2024-06-27Drop unneeded lock from createNewBlockSjors Provoost
This was added in 4bf2e361da1964f7c278b4939967a0e5afde20b0, but BlockAssembler::CreateNewBlock already locks cs_main internally.
2024-06-26mempool: move LoadMempool/DumpMempool to nodeCory Fields
2024-06-26Change MigrateLegacyToDescriptor to reopen wallet as BERKELEY_ROAva Chow
When we reopen the wallet to do the migration, instead of opening using BDB, open it using the BerkeleyRO implementation.
2024-06-26Merge bitcoin/bitcoin#29833: i2p: fix and improve logsAva Chow
7d3662fbe35032178c5a5e27e73c592268f6e41b i2p: fix log when an interruption happens during `Accept` (brunoerg) 3d3a83fab2bcc5750e5c5854d121e943922fefd8 i2p: log errors properly according to their severity (brunoerg) Pull request description: This PR improves and fixes i2p logs (joint work with vasild). - It replaces `LogPrint` to `LogPrintLevel` so we can log according to the severity. - Fix log when interruption happens during `Accept`. Before this PR, when an interruption happens, it just logs "Error accepting:", no reason is logged as it does for other situations. This PR changes it to log "Accept interrupted". - Log errors according to the severity. Stuff like creating SAM session, destroying SAM session, etc... are logged as 'debug'. ACKs for top commit: achow101: ACK 7d3662fbe35032178c5a5e27e73c592268f6e41b marcofleon: ACK 7d3662fbe35032178c5a5e27e73c592268f6e41b. vasild: ACK 7d3662fbe35032178c5a5e27e73c592268f6e41b Tree-SHA512: 1c3d92108dbc22833f37a78e18b4efd723433d10f28166d17c74eab884cd97e908b4e0a0908fd16288df895eb2eb480f781de37b2ec6a6d414abfb71e0c86fe2
2024-06-26kernel: remove mempool_persist.cppCory Fields
DumpMempool/LoadMempool are not necessary for the kernel
2024-06-26refactor: Remove no longer needed clang-15 workaround for std::spanMarcoFalke
2024-06-26fuzz: Clarify Apple-Clang-16 workaroundMarcoFalke
2024-06-26Merge bitcoin/bitcoin#30334: Update libsecp256k1 subtree to latest masterAva Chow
1408944d2ec9f78e62bf91a5e5a50317ba3060c5 Squashed 'src/secp256k1/' changes from 06bff6dec8..4af241b320 (fanquake) Pull request description: Updates the libsecp256k1 subtree to https://github.com/bitcoin-core/secp256k1/commit/f473c959f08edcb73669142f872d2189950bc54a. This includes a number of CMake related changes, including one that prevents CMake from segfaulting when we were configuring the subtree. A number of these changes have come from the review/discussion in https://github.com/hebasto/bitcoin/pull/192: * https://github.com/bitcoin-core/secp256k1/pull/1529 * https://github.com/bitcoin-core/secp256k1/pull/1532 * https://github.com/bitcoin-core/secp256k1/pull/1535 * https://github.com/bitcoin-core/secp256k1/pull/1543 * https://github.com/bitcoin-core/secp256k1/pull/1545 * https://github.com/bitcoin-core/secp256k1/pull/1546 Also includes: * https://github.com/bitcoin-core/secp256k1/pull/1488 * https://github.com/bitcoin-core/secp256k1/pull/1517 * https://github.com/bitcoin-core/secp256k1/pull/1533 * https://github.com/bitcoin-core/secp256k1/pull/1548 * https://github.com/bitcoin-core/secp256k1/pull/1550 ACKs for top commit: achow101: ACK cc58e958f341d2759fbabe5c9d8cc557e17d587f TheCharlatan: ACK cc58e958f341d2759fbabe5c9d8cc557e17d587f hebasto: re-ACK cc58e958f341d2759fbabe5c9d8cc557e17d587f. real-or-random: utACK cc58e958f341d2759fbabe5c9d8cc557e17d587f Tree-SHA512: 41409bc7f65bd17a9feb5c0455e2de2d291a25e4ce14e4a01fe25fcf9d45c64ddf55f274c17d1c86a63ab6b4870997ab79c65ec2795e5b3b49502823770c500f
2024-06-26Merge bitcoin/bitcoin#30309: wallet: notify when preset + automatic inputs ↵Ava Chow
exceed max weight 72b226882fe2348a9a66aee1d8d21b4e2d275e68 wallet: notify when preset + automatic inputs exceed max weight (furszy) Pull request description: Small change. Found it while finishing my review on #29523. This does not interfere with it. Basically, we are erroring out early when the automatic coin selection process exceeds the maximum weight, but we are not doing so when the user-preselected inputs combined with the wallet-selected inputs exceed the maximum weight. This change avoids signing all inputs before erroring out and introduces test coverage for `fundrawtransaction`. ACKs for top commit: achow101: ACK 72b226882fe2348a9a66aee1d8d21b4e2d275e68 tdb3: re ACK for 72b226882fe2348a9a66aee1d8d21b4e2d275e68 rkrux: tACK [72b2268](https://github.com/bitcoin/bitcoin/pull/30309/commits/72b226882fe2348a9a66aee1d8d21b4e2d275e68) ismaelsadeeq: utACK 72b226882fe2348a9a66aee1d8d21b4e2d275e68 Tree-SHA512: d77be19231023383a9c79a5d66b642dcbc6ebfc31a363e0b9f063c44898720a7859ec211cdbc0914ac7a3bfdf15e52fb8fc20d97f171431f70492c0f159dbc36
2024-06-26Merge bitcoin/bitcoin#30007: chainparams: Add achow101 DNS seedermerge-script
2721d64989c2b2114890586b7efd01ab4b062ca6 chainparams: Add achow101 DNS seeder (Ava Chow) Pull request description: I wrote a [DNS seeder](https://github.com/achow101/dnsseedrs) and have been running it for the past 2 months now. I believe it is ready/good enough to be used as an additional DNS seeder for all of our supported public networks. ACKs for top commit: laanwj: ACK 2721d64989c2b2114890586b7efd01ab4b062ca6 1440000bytes: ~~reACK https://github.com/bitcoin/bitcoin/pull/30007/commits/2721d64989c2b2114890586b7efd01ab4b062ca6~~ mzumsande: ACK 2721d64989c2b2114890586b7efd01ab4b062ca6 willcl-ark: reACK 2721d64989c2b2114890586b7efd01ab4b062ca6 Tree-SHA512: 857a6cf7dd33962f0008a89db4d6b57d3c6aa622704cdcca6ab710babeead3a2970d9a6fa190949c7bbf7cb7d006e814d6314be3d8c8180eed29013c7c1ac7e1
2024-06-26Merge bitcoin/bitcoin#30321: rest: don't copy data when sending binary responsemerge-script
1556d21599a250297d5f20e5249c970340ab08bc rest: don't copy data when sending binary response (Roman Zeyde) Pull request description: Also, change `HTTPRequest::WriteReply` to accept `std::span`. ACKs for top commit: laanwj: re-ACK 1556d21599a250297d5f20e5249c970340ab08bc stickies-v: ACK 1556d21599a250297d5f20e5249c970340ab08bc Tree-SHA512: 3e563d8072f0e1b90b00f85adb140d4e5fef169b6882a837b08d1e8391b64c21bea3c4256c4e2a624ac1fb3d374f12a1cc16dc59b2155ec857728162d1daaceb
2024-06-26refactor: testBlockValidity make out argument lastSjors Provoost
2024-06-26Add missing include for mining interfaceSjors Provoost
Needed for std::unique_ptr
2024-06-26rest: don't copy data when sending binary responseRoman Zeyde
Also, change `HTTPRequest::WriteReply` to accept `std::span`.
2024-06-25Squashed 'src/secp256k1/' changes from 06bff6dec8..4af241b320fanquake
4af241b320 Merge bitcoin-core/secp256k1#1535: build: Replace hardcoded "auto" value with default one f473c959f0 Merge bitcoin-core/secp256k1#1543: cmake: Do not modify build types when integrating by downstream project d403eea484 Merge bitcoin-core/secp256k1#1546: cmake: Rename `SECP256K1_LATE_CFLAGS` and switch to Bitcoin Core's approach d7ae25ce6f Merge bitcoin-core/secp256k1#1550: fix: typos in secp256k1.c 0e2fadb20c fix: typos in secp256k1.c 69b2192ad4 Merge bitcoin-core/secp256k1#1545: cmake: Do not set `CTEST_TEST_TARGET_ALIAS` 5dd637f3cf Merge bitcoin-core/secp256k1#1548: README: mention ellswift module 7454a53736 README: mention ellswift module 4706be2cd0 cmake: Reimplement `SECP256K1_APPEND_CFLAGS` using Bitcoin Core approach c2764dbb99 cmake: Rename `SECP256K1_LATE_CFLAGS` to `SECP256K1_APPEND_CFLAGS` f87a3589f4 cmake: Do not set `CTEST_TEST_TARGET_ALIAS` 158f9e5eae cmake: Do not modify build types when integrating by downstream project 35c0fdc86b Merge bitcoin-core/secp256k1#1529: cmake: Fix cache issue when integrating by downstream project 4392f0f717 Merge bitcoin-core/secp256k1#1533: tests: refactor: tidy up util functions (#1491) bedffd53d8 Merge bitcoin-core/secp256k1#1488: ci: Add native macOS arm64 job 4b8d5eeacf Merge bitcoin-core/secp256k1#1532: cmake: Disable eager MSan in ctime_tests f55703ba49 autotools: Delete unneeded compiler test 396e885886 autotools: Align MSan checking code with CMake's implementation abde59f52d cmake: Report more compiler details in summary 7abf979a43 cmake: Disable `ctime_tests` if build with `-fsanitize=memory` 4d9645bee0 cmake: Remove "AUTO" value of `SECP256K1_ECMULT_GEN_KB` option a06805ee74 cmake: Remove "AUTO" value of `SECP256K1_ECMULT_WINDOW_SIZE` option 1791f6fce4 Merge bitcoin-core/secp256k1#1517: autotools: Disable eager MSan in ctime_tests 26b94ee92a autotools: Remove "auto" value of `--with-ecmult-gen-kb` option 122dbaeb37 autotools: Remove "auto" value of `--with-ecmult-window` option e73f6f8fd9 tests: refactor: drop `secp256k1_` prefix from testrand.h functions 0ee7453a99 tests: refactor: add `testutil_` prefix to testutil.h functions 0c6bc76dcd tests: refactor: move `random_` helpers from tests.c to testutil.h 0fef8479be tests: refactor: rename `random_field_element_magnitude` -> `random_fe_magnitude` 59db007f0f tests: refactor: rename `random_group_element_...` -> `random_ge_...` ebfb82ee2f ci: Add job with -fsanitize-memory-param-retval e1bef0961c configure: Move "experimental" warning to bottom 55e5d975db autotools: Disable eager MSan in ctime_tests ec4c002faa cmake: Simplify `PROJECT_IS_TOP_LEVEL` emulation cae9a7ad14 cmake: Do not set emulated PROJECT_IS_TOP_LEVEL as cache variable 218f0cc93b ci: Add native macOS arm64 job git-subtree-dir: src/secp256k1 git-subtree-split: 4af241b32099067464e015fa66daac5096206dea
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 20:26:48 +0000