aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
2024-06-17Merge bitcoin/bitcoin#28984: Cluster size 2 package rbfAva Chow
94ed4fbf8e1a396c650b5134d396d6c0be35ce10 Add release note for size 2 package rbf (Greg Sanders) afd52d8e63ed323a159ea49fd1f10542abeacb97 doc: update package RBF comment (Greg Sanders) 6e3c4394cfadf32c06c8c4732d136ca10c316721 mempool: Improve logging of replaced transactions (Greg Sanders) d3466e4cc5051c314873dd14ec8f7a88494c0780 CheckPackageMempoolAcceptResult: Check package rbf invariants (Greg Sanders) 316d7b63c97144ba3e21201315c784852210f8ff Fuzz: pass mempool to CheckPackageMempoolAcceptResult (Greg Sanders) 4d15bcf448eb3c4451b63e8f78cc61f3f9f9b639 [test] package rbf (glozow) dc21f61c72e5a97d974ca2c5cb70b8328f4fab2a [policy] package rbf (Suhas Daftuar) 5da396781589177d4ceb3b4b59c9f309a5e4d029 PackageV3Checks: Relax assumptions (Greg Sanders) Pull request description: Allows any 2 transaction package with no in-mempool ancestors to do package RBF when directly conflicting with other mempool clusters of size two or less. Proposed validation steps: 1) If the transaction package is of size 1, legacy rbf rules apply. 2) Otherwise the transaction package consists of a (parent, child) pair with no other in-mempool ancestors (or descendants, obviously), so it is also going to create a cluster of size 2. If larger, fail. 3) The package rbf may not evict more than 100 transactions from the mempool(bip125 rule 5) 4) The package is a single chunk 5) Every directly conflicted mempool transaction is connected to at most 1 other in-mempool transaction (ie the cluster size of the conflict is at most 2). 6) Diagram check: We ensure that the replacement is strictly superior, improving the mempool 7) The total fee of the package, minus the total fee of what is being evicted, is at least the minrelayfee * size of the package (equivalent to bip125 rule 3 and 4) Post-cluster mempool this will likely be expanded to general package rbf, but this is what we can safely support today. ACKs for top commit: achow101: ACK 94ed4fbf8e1a396c650b5134d396d6c0be35ce10 glozow: reACK 94ed4fbf8e via range-diff ismaelsadeeq: re-ACK 94ed4fbf8e1a396c650b5134d396d6c0be35ce10 theStack: Code-review ACK 94ed4fbf8e1a396c650b5134d396d6c0be35ce10 murchandamus: utACK 94ed4fbf8e1a396c650b5134d396d6c0be35ce10 Tree-SHA512: 9bd383e695964f362f147482bbf73b1e77c4d792bda2e91d7f30d74b3540a09146a5528baf86854a113005581e8c75f04737302517b7d5124296bd7a151e3992
2024-06-17Merge bitcoin/bitcoin#30058: Encapsulate warnings in generalized ↵Ava Chow
node::Warnings and remove globals 260f8da71a35232d859d7705861fc1a88bfbbe81 refactor: remove warnings globals (stickies-v) 9c4b0b7ce459765fa1a63b410c3423b90f0d2a5f node: update uiInterface whenever warnings updated (stickies-v) b071ad9770b7ae7fc718dcbfdc8f62dffbf6cfee introduce and use the generalized `node::Warnings` interface (stickies-v) 20e616f86444d00712ac7eb840666e2b0378af4a move-only: move warnings from common to node (stickies-v) bed29c481aebeb2b0160450c63c03cc68fb89bc6 refactor: remove unnecessary AppendWarning helper function (stickies-v) Pull request description: This PR: - moves warnings from common to the node library and into the node namespace (as suggested in https://github.com/bitcoin/bitcoin/pull/29845#discussion_r1570069541) - generalizes the warnings interface to `Warnings::Set()` and `Warnings::Unset()` methods, instead of having a separate function and globals for each warning. As a result, this simplifies the `kernel::Notifications` interface. - removes warnings.cpp from the kernel library - removes warning globals - adds testing for the warning logic Behaviour change introduced: - the `-alertnotify` command is executed for all `KernelNotifications::warningSet` calls, which now also covers the `LARGE_WORK_INVALID_CHAIN` warning - the GUI is updated automatically whenever a warning is (un)set, covering some code paths where it previously wouldn't be, e.g. when `node::AbortNode()` is called, or for the `LARGE_WORK_INVALID_CHAIN` warning Some discussion points: - ~is `const std::string& id` the best way to refer to warnings? Enums are an obvious alternative, but since we need to define warnings across libraries, strings seem like a straightforward solution.~ _edit: updated approach to use `node::Warning` and `kernel::Warning` enums._ ACKs for top commit: achow101: ACK 260f8da71a35232d859d7705861fc1a88bfbbe81 ryanofsky: Code review ACK 260f8da71a35232d859d7705861fc1a88bfbbe81. Only change since last review was rebasing TheCharlatan: Re-ACK 260f8da71a35232d859d7705861fc1a88bfbbe81 Tree-SHA512: a3fcedaee0d3ad64e9c111aeb30665162f98e0e72acd6a70b76ff2ddf4f0a34da4f97ce353c322a1668ca6ee4d8a81cc6e6d170c5bbeb7a43cffdaf66646b588
2024-06-14Merge bitcoin/bitcoin#30276: doc: archive release notes for v27.1merge-script
e71a21b641541f4751ac1ea7fd7d33f20a629636 doc: archive release notes for v27.1 (fanquake) Pull request description: ACKs for top commit: benalleng: ACK for e71a21b Tree-SHA512: a89231d09b442e5e1755135a475030648a81bb0c331eec8d9c7a27a633f64fd0449dcfe8939c0d43cc5133ad0ab85acda7de757594986f9c93fe6f90efc11a02
2024-06-13Add release note for size 2 package rbfGreg Sanders
2024-06-13doc: update package RBF commentGreg Sanders
2024-06-13introduce and use the generalized `node::Warnings` interfacestickies-v
Instead of having separate warning functions (and globals) for each different warning that can be raised, encapsulate this logic into a single class and allow to (un)set any number of warnings. Introduces behaviour change: - the `-alertnotify` command is executed for all `KernelNotifications::warningSet` calls, which now also covers the `LARGE_WORK_INVALID_CHAIN` warning. - previously, warnings were returned based on a predetermined order, e.g. with the "pre-release test build" warning always first. This is no longer the case, and Warnings::GetMessages() will return messages sorted by the id of the warning. Removes warnings.cpp from kernel.
2024-06-12Merge bitcoin/bitcoin#29015: kernel: Streamline util libraryAva Chow
c7376babd19d0c858fef93ebd58338abd530c1f4 doc: Clarify distinction between util and common libraries in libraries.md (Ryan Ofsky) 4f74c59334d496f28e1a5c0d84c412f9020b366f util: Move util/string.h functions to util namespace (Ryan Ofsky) 4d05d3f3b42a41525aa6ec44b90f543dfab53ecf util: add TransactionError includes and namespace declarations (Ryan Ofsky) 680eafdc74021c1e0893c3a62404e607fd4724f5 util: move fees.h and error.h to common/messages.h (Ryan Ofsky) 02e62c6c9af4beabaeea58fb1ea3ad0dc5094678 common: Add PSBTError enum (Ryan Ofsky) 0d44c44ae33434f366229c612d6edeedf7658963 util: move error.h TransactionError enum to node/types.h (Ryan Ofsky) 9bcce2608dd2515dc35a0f0866abc9d43903c795 util: move spanparsing.h to script/parsing.h (Ryan Ofsky) 6dd2ad47922694d2ab84bad4dac9dd442c5df617 util: move spanparsing.h Split functions to string.h (Ryan Ofsky) 23cc8ddff472d259605d7790ba98a1900e77efab util: move HexStr and HexDigit from util to crypto (TheCharlatan) 6861f954f8ff42c87ad638037adae86a5bd89600 util: move util/message to common/signmessage (Ryan Ofsky) cc5f29fbea15d33e4d1aa95591253c6b86953fe7 build: move memory_cleanse from util to crypto (Ryan Ofsky) 5b9309420cc9721a0d5745b6ad3166a4bdbd1508 build: move chainparamsbase from util to common (Ryan Ofsky) ffa27af24da81a97d6c4912ae0e10bc5b6f17f69 test: Add check-deps.sh script to check for unexpected library dependencies (Ryan Ofsky) Pull request description: Remove `fees.h`, `errors.h`, and `spanparsing.h` from the util library. Specifically: - Move `Split` functions from `util/spanparsing.h` to `util/string.h`, using `util` namespace for clarity. - Move remaining spanparsing functions to `script/parsing.h` since they are used for descriptor and miniscript parsing. - Combine `util/fees.h` and `util/errors.h` into `common/messages.h` so there is a place for simple functions that generate user messages to live, and these functions are not part of the util library. Motivation for this change is that the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications. These changes should also improve code organization and make functions easier to discover. Some of these same moves are (or were) part of #28690, but did not help with code organization, or made it worse, so it is better to move them and clean them up in the same PR so code only has to change one time. ACKs for top commit: achow101: ACK c7376babd19d0c858fef93ebd58338abd530c1f4 TheCharlatan: Re-ACK c7376babd19d0c858fef93ebd58338abd530c1f4 hebasto: re-ACK c7376babd19d0c858fef93ebd58338abd530c1f4. Tree-SHA512: 5bcef16c1255463b1b69270548711e7ff78ca0dd34e300b95e3ca1ce52ceb34f83d9ddb2839e83800ba36b200de30396e504bbb04fa02c6d0c24a16d06ae523d
2024-06-12doc: archive release notes for v27.1fanquake
2024-06-12Merge bitcoin/bitcoin#29325: consensus: Store transaction nVersion as uint32_tmerge-script
429ec1aaaaafab150f11e27fcf132a99b57c4fc7 refactor: Rename CTransaction::nVersion to version (Ava Chow) 27e70f1f5be1f536f2314cd2ea42b4f80d927fbd consensus: Store transaction nVersion as uint32_t (Ava Chow) Pull request description: Given that the use of a transaction's nVersion is always as an unsigned int, it doesn't make sense to store it as signed and then cast it to unsigned everywhere it is used and displayed. Since a few alternative implementations have recently been revealed to have made an error with this signedness that would have resulted in consensus failure, I think it makes sense for us to just make this always unsigned to make it clear that the version is treated as unsigned. This would also help us avoid future potential issues with signedness of this value. I believe that this is safe and does not actually change what transactions would or would not be considered both standard and consensus valid. Within consensus, the only use of the version in consensus is in BIP68 validation which was already casting it to uint32_t. Within policy, although it is used as a signed int for the transaction version number check, I do not think that this change would change standardness. Standard transactions are limited to the range [1, 2]. Negative numbers would have fallen under the < 1 condition, but by making it unsigned, they are still non-standard under the > 2 condition. Unsigned and signed ints are serialized and unserialized the same way so there is no change in serialization. ACKs for top commit: maflcko: ACK 429ec1aaaaafab150f11e27fcf132a99b57c4fc7 🐿 glozow: ACK 429ec1aaaa shaavan: ACK 429ec1aaaaafab150f11e27fcf132a99b57c4fc7 💯 Tree-SHA512: 0bcd92a245d7d16c3665d2d4e815a4ef28207ad4a1fb46c6f0203cdafeab1b82c4e95e4bdce7805d80a4f4a46074f6542abad708e970550d38a00d759e3dcef1
2024-06-10doc: add release note for 29091 and 29165fanquake
2024-06-10Merge bitcoin/bitcoin#30257: build: Remove --enable-gprofmerge-script
fa780e1c25e8e98253e32d93db65f78a0092433f build: Remove --enable-gprof (MarcoFalke) Pull request description: It is unclear what benefit this option has, given that: * `gprof` requires re-compilation (`perf` and other tools can instead be used on existing executables) * `gprof` requires hardening to be disabled * `gprof` doesn't work with `clang` * `perf` is documented in the dev-notes, and test notes, and embedded into the functional test framework; `gprof` isn't * Anyone really wanting to use it could pass the required flags to `./configure` * I couldn't find any mention of the use of `gprof` in the discussions in this repo, apart from the initial pull request adding it (cfaac2a60f3ac63ae8deccb03d88bd559449b78c) * Keeping it means that it needs to be maintained and ported to CMake Fix all issues by removing it. ACKs for top commit: TheCharlatan: ACK fa780e1c25e8e98253e32d93db65f78a0092433f hebasto: ACK fa780e1c25e8e98253e32d93db65f78a0092433f, I have reviewed the code and it looks OK. willcl-ark: crACK fa780e1c25e8e98253e32d93db65f78a0092433f Tree-SHA512: 0a9ff363ac2bec8b743878a4e3147f18bc16823d00c5007568432c36320bd0199b13b6d0ce828a9a83c2cc434c058afaa64eb2eccfbd93ed85b81ce10c41760c
2024-06-10Merge bitcoin/bitcoin#30227: doc: fixup deps doc after #30198merge-script
e6636ff4ec594a38f2e2c4bda3a9549bbc07118e doc: fixup deps doc after #30198 (fanquake) Pull request description: Forgotten in #30198. Addresses: https://github.com/bitcoin/bitcoin/pull/30198#issuecomment-2148087913. ACKs for top commit: TheCharlatan: ACK e6636ff4ec594a38f2e2c4bda3a9549bbc07118e Tree-SHA512: 138cba946d0482f11b604a8197177e74f4384c1962dee1d50af6baad40ceb9d064a148244d652d8e140f955f95457f7d0ffdb0e179f8622e71c57cb91c44af29
2024-06-09build: Remove --enable-gprofMarcoFalke
This reverts cfaac2a60f3ac63ae8deccb03d88bd559449b78c
2024-06-08Merge bitcoin/bitcoin#30238: json-rpc 2.0 followups: docs, tests, climerge-script
1f6ab1215bbb1f8a5f1743c3c413b95ad08090df minor: remove unnecessary semicolons from RPC content type examples (Matthew Zipkin) b22529529823c0cb5916ac318c8536e9107b7e78 test: use json-rpc 2.0 in all functional tests by default (Matthew Zipkin) 391843b0297db03d71a8d88ab77609e2ad230bf2 bitcoin-cli: use json-rpc 2.0 (Matthew Zipkin) d39bdf339772166a5545ae811e58b7764af093a8 test: remove unused variable in interface_rpc.py (Matthew Zipkin) 0ead71df8c83a2f9eae1220544ec84dcf38a0326 doc: update and link for JSON-RPC 2.0 (Matthew Zipkin) Pull request description: This is a follow-up to #27101. - Addresses [post-merge comments ](https://github.com/bitcoin/bitcoin/pull/27101#discussion_r1606723428) - bitcoin-cli uses JSON-RPC 2.0 - functional tests use JSON-RPC 2.0 by default (exceptions are in the regression tests added by #27101) ACKs for top commit: tdb3: ACK 1f6ab1215bbb1f8a5f1743c3c413b95ad08090df cbergqvist: ACK 1f6ab1215bbb1f8a5f1743c3c413b95ad08090df Tree-SHA512: 49bf14c70464081280216ece538a2f5ec810bac80a86a83ad3284f0f1b017edf755a1a74a45be279effe00218170cafde7c2de58aed07097a95c2c6b837a6b6c
2024-06-07refactor: Rename CTransaction::nVersion to versionAva Chow
In order to ensure that the change of nVersion to a uint32_t in the previous commit has no effect, rename nVersion to version in this commit so that reviewers can easily spot if a spot was missed or if there is a check somewhere whose semantics have changed.
2024-06-07Merge bitcoin/bitcoin#29496: policy: bump TX_MAX_STANDARD_VERSION to 3Ava Chow
30a01134cdec37e7467fcd6eee8b0ae3890a131c [doc] update bips.md for 431 (glozow) 9dbe6a03f0d6e70ccdf8e8715f888c0c17216bee [test] wallet uses CURRENT_VERSION which is 2 (glozow) 539404fe0fc0346b3aa77c330b38a5a0ad6565b2 [policy] make v3 transactions standard (glozow) 052ede75aff5c9f3a0a422ef413852eabeecc665 [refactor] use TRUC_VERSION in place of 3 (glozow) Pull request description: Make `nVersion=3` (which is currently nonstandard on mainnet) standard. Note that we will treat these transactions as Topologically Restricted Until Confirmation (TRUC). Spec is in BIP 431 and implementation is in #28948, #29306, and #29873 See #27463 for overall project tracking, and #29319 for information about relevance to cluster mempool. ACKs for top commit: sdaftuar: utACK 30a01134c achow101: ACK 30a01134cdec37e7467fcd6eee8b0ae3890a131c instagibbs: utACK 30a01134cdec37e7467fcd6eee8b0ae3890a131c murchandamus: ACK 30a01134cdec37e7467fcd6eee8b0ae3890a131c ismaelsadeeq: ACK 30a01134cdec37e7467fcd6eee8b0ae3890a131c 🛰️ Tree-SHA512: 2a4aec0442c860e792a061d83e36483c1f1b426f946efbdf664c8db97a596e498b535707e1d3a900218429486ea69fd4552e3d476526a6883cbd5556c6534b48
2024-06-07minor: remove unnecessary semicolons from RPC content type examplesMatthew Zipkin
2024-06-07doc: update and link for JSON-RPC 2.0Matthew Zipkin
2024-06-05doc: fixup deps doc after #30198fanquake
2024-06-04Merge bitcoin/bitcoin#30154: doc: update mention of generating bitcoin.confAva Chow
9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2 Link to gen-bitcoin-conf.sh instead of bitcoin.conf placeholder (Epic Curious) Pull request description: Closes #30153. This PR updates `doc/init.md` to mention generating an example bitcoin.conf instead of referencing the placeholder `share/examples/bitcoin.conf`. Also changes the code-formatted text to a markdown link. ## Background - Two years ago, `share/examples/bitcoin.conf` was replaced with [a placeholder file](https://github.com/bitcoin/bitcoin/commit/b483084d866c16d97a34251ae652bac94f85f61d). To see an example `bitcoin.conf`, the user now runs the `contrib/devtools/gen-bitcoin-conf.sh` script, which replaces the placeholder file with the parsed contents of `bitcoind --help`. - The instructions in `init.md` about an example `bitcoin.conf` haven't changed significantly since they were [added almost 10 years ago](https://github.com/bitcoin/bitcoin/blame/234bfbf6a5fcba37e510e9cb6c1f2a629cd0290e/doc/init.md#L39). They should be updated to improve clarity. ACKs for top commit: edilmedeiros: ACK 9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2 kevkevinpal: reACK [9013e2b](https://github.com/bitcoin/bitcoin/pull/30154/commits/9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2) achow101: ACK 9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2 stickies-v: ACK 9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2 tdb3: ACK for 9013e2b97e8f50d2be63ce740c42d0b0e0b9b7f2 Tree-SHA512: 5ac5ad672ad181d574e19e29c3727fb9e5373282444fae09b42d113d5c8915cb2829d496212638cdc4b70540b7e1794a751fcdc9539f956a594cddd70c8fd747
2024-06-03Merge bitcoin/bitcoin#30215: doc: JSON-RPC request Content-Type is ↵merge-script
application/json 3c08e11c3ea4499e8d20609e2417cac859b3e98e doc: JSON-RPC request Content-Type is application/json (Luke Dashjr) Pull request description: Specify json content type in RPC examples. Picks up #29946. Which needed rebasing and the commit message fixing, ACKs for top commit: laanwj: ACK 3c08e11c3ea4499e8d20609e2417cac859b3e98e tdb3: ACK for 3c08e11c3ea4499e8d20609e2417cac859b3e98e Tree-SHA512: 770bbbc0fb324cb63628980b13583cabf02e75079851850170587fb6eca41a70b01dcedaf1926bb6488eb9816a3cc6616fe8cee8c4b7e09aa39b7df5834ca0ec
2024-06-03Merge bitcoin/bitcoin#30167: doc, rpc: Release notes and follow-ups for #29612merge-script
efc1b5be8a4696c0db19ba18316b2d4ed09e10f2 test: Add coverage for txid coins count check when loading snapshot (Fabian Jahr) 6b6084850b8c2ebcdbeecdb406e8732adaa6d23c assumeutxo: Add network magic ctor param to SnapshotMetadata (Fabian Jahr) 1f1f9984555d49f07ae20cb3a8153a177c546beb assumeutxo: Deserialize trailing byte instead of Txid (Fabian Jahr) 359967e310794e0bbdbe2bca38ee440a88bc4f43 doc: Add release notes for #29612 (Fabian Jahr) Pull request description: This adds release notes for #29612 and addresses post-merge review comments. ACKs for top commit: maflcko: utACK efc1b5be8a4696c0db19ba18316b2d4ed09e10f2 theStack: utACK efc1b5be8a4696c0db19ba18316b2d4ed09e10f2 Tree-SHA512: 3b270202e4f7b2576090ef1d970fd54a6840d96fc3621dddd28e888fb8696a97ff69af2e000bcee3b364316ca3f6e2a9b2f1694c6184f0e704dc487823127ce4
2024-06-02[doc] update bips.md for 431glozow
2024-05-31doc: JSON-RPC request Content-Type is application/jsonLuke Dashjr
Specify json content type in RPC examples
2024-05-30build: remove --enable-lcov-branch-coveragefanquake
This supports lcov 2.x in the sense that we are no-longer hardcoding version specific options, and instead will use the `LCOV_OPTS` variable (which is the more correct/flexible thing to do in any case). It's also quite likely that devs are already having to pass extra options to lcov 2.x, given it's more stringent in terms of coverage generation and error checking. See this thread for an example: https://github.com/linux-test-project/lcov/issues/238. Added an example to the developer notes. Tested on one machine (LCOV 2.0, gcc 13.2) with: ```bash ./autogen.sh ./configure --enable-lcov CXXFLAGS="-fprofile-update=prefer-atomic" LCOV_OPTS="--rc branch_coverage=1 --ignore-errors mismatch" make make cov <snip> Processing file src/netaddress.cpp lines=521 hit=480 functions=72 hit=72 branches=675 hit=499 Overall coverage rate: lines......: 81.8% (79362 of 97002 lines) functions......: 77.8% (10356 of 13310 functions) branches......: 49.6% (130628 of 263196 branches) ``` and another machine (LCOV 2.1, Clang 18.1.3) with: ```bash ./autogen.sh ./configure --enable-lcov CC=clang CXX=clang++ LCOV_OPTS="--rc branch_coverage=1 --ignore-errors mismatch,inconsistent" make make cov <snip> Processing file src/util/strencodings.cpp lines=315 hit=311 functions=38 hit=38 branches=425 hit=357 Overall coverage rate: source files: 622 lines.......: 79.8% (70311 of 88132 lines) functions...: 78.1% (13968 of 17881 functions) branches....: 44.5% (157551 of 354317 branches) Message summary: 101 warning messages: count: 1 inconsistent: 100 3528 ignore messages: inconsistent: 3528 ```
2024-05-30Merge bitcoin/bitcoin#30049: build, test, doc: Temporarily remove ↵merge-script
Android-related stuff 5deb0b024e14c7c63d405c651d1ca323560a1c21 build, test, doc: Temporarily remove Android-related stuff (Hennadii Stepanov) Pull request description: Previously, our Android builds were geared towards generating APKs, which relied on Qt. However, after migrating to C++20, compiling for Android became unfeasible due to Qt 5.15's compatibility limitations with NDK only up to r25, which includes an outdated embedded libc++ (see https://github.com/bitcoin/bitcoin/issues/29360). All removed stuff will be reinstated after migrating the build system to CMake and upgrading Qt to version 6.x. This PR makes possible a clean migration to the CMake-based build system as it removes code, which is not used at this moment. ACKs for top commit: vasild: ACK 5deb0b024e14c7c63d405c651d1ca323560a1c21 fanquake: ACK 5deb0b024e14c7c63d405c651d1ca323560a1c21 - given none of this is currently tested/wont compile. Can be revisted in future. Tree-SHA512: 3bc2ccfe881e11cc1d78c27acd6f1d86cfba86821ef3bb5eca2e80d978fdfa13659ec82284dcaadc507e2394524dea91d4b8f81d0030c1cef9708df8be76bf07
2024-05-24doc: Add release notes for #29612Fabian Jahr
2024-05-24Merge bitcoin/bitcoin#30072: refactor prep for package rbfglozow
2fd34ba504957331f5a08614b6e1f8317260f04d Add sanity checks for various ATMPArgs booleans (Greg Sanders) 20d8936d8bb6137a5a3722d34e0d7ae756031009 [refactor] make some members MemPoolAccept-wide (glozow) cbbfe719b223b9e05398227cef68c99eb97670bd cpfp carveout is excluded in packages (glozow) 69f7ab05bafec1cf06fd7a58351f78e32bbfa2cf Add m_allow_sibling_eviction as separate ATMPArgs flag (Greg Sanders) 57ee3029ddadaee5cb48224e0a87f704b7971bd8 Add description for m_test_accept (Greg Sanders) Pull request description: First few commits of https://github.com/bitcoin/bitcoin/pull/28984 to set the stage for the package RBF logic. These refactors are preparation for evaluating an RBF in a multi-proposed-transaction context instead of only a single proposed transaction. Also, carveouts and sibling evictions only should work in single RBF cases so add logic to preclude multi-tx cases in the future. No behavior changes aside from bailing earlier from failed carve-outs. ACKs for top commit: glozow: reACK 2fd34ba504957331f5a08614b6e1f8317260f04d via range-diff sr-gi: utACK [2fd34ba](https://github.com/bitcoin/bitcoin/pull/30072/commits/2fd34ba504957331f5a08614b6e1f8317260f04d) theStack: re-ACK 2fd34ba504957331f5a08614b6e1f8317260f04d Tree-SHA512: 5071c5b8d9b8d2c9faa278c8c4df31de288cb407a68e4d55544c588caff6c86160cce7825453549c6ed69e29d9ccb5ee2d4a518b18f563bfb12f2ced073fe42a
2024-05-23Link to gen-bitcoin-conf.sh instead of bitcoin.conf placeholderEpic Curious
2024-05-23Merge bitcoin/bitcoin#27064: system: use %LOCALAPPDATA% as default datadir ↵Ava Chow
on windows 84900ac34f6888b7a851d0a6a5885192155f865c doc: add release-notes-27064.md (Matthew Zipkin) 855dd8d592c951a2b3239867ffbf66bb8677d470 system: use %LOCALAPPDATA% as default datadir on windows (Matthew Zipkin) Pull request description: Closes https://github.com/bitcoin/bitcoin/issues/2391 This PR changes the default datadir location on Windows from `C:\Users\Username\AppData\Roaming\Bitcoin` to `C:\Users\Username\AppData\Local\Bitcoin`. This change only applies to fresh installs. To preserve backwards compatibility, on startup we check for the existence of `C:\Users\Username\AppData\Roaming\Bitcoin\chainstate` and if it is there, we continue using the "Roaming" directory as the default datadir location. [Note that in Windows 11 this change may be moot:](https://learn.microsoft.com/en-us/uwp/api/windows.storage.applicationdata.roamingfolder?view=winrt-22621) > Roaming data and settings is no longer supported as of Windows 11. The recommended replacement is [Azure App Service](https://learn.microsoft.com/en-us/azure/app-service/). Azure App Service is widely supported, well documented, reliable, and supports cross-platform/cross-ecosystem scenarios such as iOS, Android and web. Settings stored here no longer roam (as of Windows 11), but the settings store is still available. ACKs for top commit: achow101: ACK 84900ac34f6888b7a851d0a6a5885192155f865c BenWestgate: crACK https://github.com/bitcoin/bitcoin/commit/84900ac34f6888b7a851d0a6a5885192155f865c hebasto: re-ACK 84900ac34f6888b7a851d0a6a5885192155f865c, only addressed feedback since my recent [review](https://github.com/bitcoin/bitcoin/pull/27064#pullrequestreview-2028718273). Tree-SHA512: 807c6e89571287e2c8f4934229aec91ef28e7d0a675234acf1b7d085c24c7b73a08b6e345fbfc9038e6239187b6b69c08490ddaa1c057de5ea975c4a000bba42
2024-05-23cpfp carveout is excluded in packagesglozow
The behavior is not new, but this rule exits earlier than before. Previously, a carve out could have been granted in PreChecks() but then nullified in PackageMempoolChecks() when CheckPackageLimits() is called with the default limits.
2024-05-20doc: Update NetBSD Build GuideHennadii Stepanov
2024-05-16doc: Clarify distinction between util and common libraries in libraries.mdRyan Ofsky
Also describe crypto library which was previously unmentioned
2024-05-16Merge bitcoin/bitcoin#27101: Support JSON-RPC 2.0 when requested by clientRyan Ofsky
cbc6c440e3811d342fa570713702900b3e3e75b9 doc: add comments and release-notes for JSON-RPC 2.0 (Matthew Zipkin) e7ee80dcf2b68684eae96070875ea13a60e3e7b0 rpc: JSON-RPC 2.0 should not respond to "notifications" (Matthew Zipkin) bf1a1f1662427fbf1a43bb951364eface469bdb7 rpc: Avoid returning HTTP errors for JSON-RPC 2.0 requests (Matthew Zipkin) 466b90562f4785de74b548f7c4a256069e2aaf43 rpc: Add "jsonrpc" field and drop null "result"/"error" fields (Matthew Zipkin) 2ca1460ae3a7217eaa8c5972515bf622bedadfce rpc: identify JSON-RPC 2.0 requests (Matthew Zipkin) a64a2b77e09bff784a2635ba19ff4aa6582bb5a5 rpc: refactor single/batch requests (Matthew Zipkin) df6e3756d6feaf1856e7886820b70874209fd90b rpc: Avoid copies in JSONRPCReplyObj() (Matthew Zipkin) 09416f9ec445e4d6bb277400758083b0b4e8b174 test: cover JSONRPC 2.0 requests, batches, and notifications (Matthew Zipkin) 4202c170da37a3203e05a9f39f303d7df19b6d81 test: refactor interface_rpc.py (Matthew Zipkin) Pull request description: Closes https://github.com/bitcoin/bitcoin/issues/2960 Bitcoin Core's JSONRPC server behaves with a special blend of 1.0, 1.1 and 2.0 behaviors. This introduces compliance issues with more strict clients. There are the major misbehaviors that I found: - returning non-200 HTTP codes for RPC errors like "Method not found" (this is not a server error or an HTTP error) - returning both `"error"` and `"result"` fields together in a response object. - different error-handling behavior for single and batched RPC requests (batches contain errors in the response but single requests will actually throw HTTP errors) https://github.com/bitcoin/bitcoin/pull/15495 added regression tests after a discussion in https://github.com/bitcoin/bitcoin/pull/15381 to kinda lock in our RPC behavior to preserve backwards compatibility. https://github.com/bitcoin/bitcoin/pull/12435 was an attempt to allow strict 2.0 compliance behind a flag, but was abandoned. The approach in this PR is not strict and preserves backwards compatibility in a familiar bitcoin-y way: all old behavior is preserved, but new rules are applied to clients that opt in. One of the rules in the [JSON RPC 2.0 spec](https://www.jsonrpc.org/specification#request_object) is that the kv pair `"jsonrpc": "2.0"` must be present in the request. Well, let's just use that to trigger strict 2.0 behavior! When that kv pair is included in a request object, the [response will adhere to strict JSON-RPC 2.0 rules](https://www.jsonrpc.org/specification#response_object), essentially: - always return HTTP 200 "OK" unless there really is a server error or malformed request - either return `"error"` OR `"result"` but never both - same behavior for single and batch requests If this is merged next steps can be: - Refactor bitcoin-cli to always use strict 2.0 - Refactor the python test framework to always use strict 2.0 for everything - Begin deprecation process for 1.0/1.1 behavior (?) If we can one day remove the old 1.0/1.1 behavior we can clean up the rpc code quite a bit. ACKs for top commit: cbergqvist: re ACK cbc6c440e3811d342fa570713702900b3e3e75b9 ryanofsky: Code review ACK cbc6c440e3811d342fa570713702900b3e3e75b9. Just suggested changes since the last review: changing uncaught exception error code from PARSE_ERROR to MISC_ERROR, renaming a few things, and adding comments. tdb3: re ACK for cbc6c440e3811d342fa570713702900b3e3e75b9 Tree-SHA512: 0b702ed32368b34b29ad570d090951a7aeb56e3b0f2baf745bd32fdc58ef68fee6b0b8fad901f1ca42573ed714b150303829cddad4a34ca7ad847350feeedb36
2024-05-14doc: add comments and release-notes for JSON-RPC 2.0Matthew Zipkin
2024-05-08Merge bitcoin/bitcoin#30025: doc: fix broken relative md linksmerge-script
4b9f49da2b120e81516ddc3dc577d7a2e58e02d3 doc: fix broken relative md links (willcl-ark) Pull request description: These relative links in our documentation are broken, fix them. ACKs for top commit: maflcko: ACK 4b9f49da2b120e81516ddc3dc577d7a2e58e02d3 ryanofsky: Code review ACK 4b9f49da2b120e81516ddc3dc577d7a2e58e02d3. Thanks for the updates! ismaelsadeeq: Re ACK 4b9f49da2b120e81516ddc3dc577d7a2e58e02d3 Tree-SHA512: df4ef5ddece6c21125ce719ed6a4f69aba4f884c353ff7a8445ecb6438ed6bf0ff8268a1ae19cdd910adaadc189c6861c445b4d469f92ee81874d810dcbd0846
2024-05-06Merge bitcoin/bitcoin#29845: rpc: return warnings as an array instead of ↵Ava Chow
just a single one 42fb5311b19582361409d65c6fddeadbee14bb97 rpc: return warnings as an array instead of just a single one (stickies-v) Pull request description: The RPC documentation for `getblockchaininfo`, `getmininginfo` and `getnetworkinfo` states that "warnings" returns "any network and blockchain warnings". In practice, only a single warning (i.e. the latest one that is set) is returned, the other ones are ignored. Fix that by returning all warnings as an array. As a side benefit, clean up the GetWarnings() logic. Since this PR changes the RPC result schema, I've added release notes. Users can temporarily revert to the old results by using `-deprecatedrpc=warnings`, until it's removed in a future version. --- Some historical context from git log: - when `GetWarnings` was introduced in 401926283a200994ecd7df8eae8ced8e0b067c46, it was used in the `getinfo` RPC, where only a [single error/warning was returned](https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46#diff-7442c48d42cd5455a79915a0f00cce5e13359db46437a32b812876edb0a5ccddR250) (similar to how it is now). - later on, "warnings" RPC response fields were introduced, e.g. in ef2a3de25c882396e1776b554878d2784b6b7391, with the description [stating](https://github.com/bitcoin/bitcoin/commit/ef2a3de25c882396e1776b554878d2784b6b7391#diff-1021bd3c74415ad9719bd764ad6ca35af5dfb33b1cd863c0be49bdf52518af54R411) that it returned "any network warnings" but in practice still only a single warning was returned ACKs for top commit: achow101: re-ACK 42fb5311b19582361409d65c6fddeadbee14bb97 tdb3: Re ACK for 42fb5311b19582361409d65c6fddeadbee14bb97 TheCharlatan: ACK 42fb5311b19582361409d65c6fddeadbee14bb97 maflcko: ACK 42fb5311b19582361409d65c6fddeadbee14bb97 🔺 Tree-SHA512: 4225ed8979cd5f030dec785a80e7452a041ad5703445da79d2906ada983ed0bbe7b15889d663d75aae4a77d92e302c93e93eca185c7bd47c9cce29e12f752bd3
2024-05-06build, test, doc: Temporarily remove Android-related stuffHennadii Stepanov
Previously, our Android builds were geared towards generating APKs, which relied on Qt. However, after migrating to C++20, compiling for Android became unfeasible due to Qt 5.15's compatibility limitations with NDK only up to r25, which includes an outdated embedded libc++. All removed stuff will be reinstated after migrating the build system to CMake and upgrading Qt to version 6.x."
2024-05-03doc: fix broken relative md linkswillcl-ark
These relative links in our documentation are broken, fix them.
2024-05-02Merge bitcoin/bitcoin#29934: doc: add LLVM instruction for macOS < 13merge-script
22574046c90c0662f3aa9b1baea074aff54f92a9 doc: add LLVM instruction for macOS < 13 (Sjors Provoost) Pull request description: #29208 bumped clang to 14, which users of old macOS versions need to install manually. This PR adds instructions. Xcode 14.3.1 ships clang 14.0.3 (14.0.0 is broken, see #29918): https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework) The system requirements for that is macOS Ventura 13.0 or later: https://developer.apple.com/documentation/xcode-release-notes/xcode-14_3_1-release-notes# Homebrew itself officially supports macOS 12 or later, but _may_ still work on macOS 11: https://docs.brew.sh/Installation Fwiw macOS 11 Big Sur last got an update in September 2023, so Apple has not _entirely_ written it off: https://en.wikipedia.org/wiki/MacOS_Big_Sur ACKs for top commit: maflcko: utACK 22574046c90c0662f3aa9b1baea074aff54f92a9 TheCharlatan: ACK 22574046c90c0662f3aa9b1baea074aff54f92a9 Tree-SHA512: 5b4bcc71966d1da84bc4da32da89e0dea9f519f37d9e14e169140c92af044b33f404f01ae7d10f53ab5345dd51ac404c161389efef93da5cacbfd52a43881695
2024-05-02Merge bitcoin/bitcoin#29707: depends: build miniupnpc with CMakemerge-script
5195baa60087ee366290887ad982fc491e14c111 depends: fix miniupnpc snprintf usage on Windows (fanquake) 3c2d440f1497f60bb444326f51383df244dcdfe9 depends: switch miniupnpc to CMake (Cory Fields) f5618c79d9e7af05c2987044dc2da03697f8bb89 depends: add upstream CMake patch to miniupnpc (fanquake) 6866b571ab96f03ca0775424e45458c5731f230f depends: miniupnpc 2.2.7 (fanquake) Pull request description: This picks up one of the changes from #29232, which is a switch to building miniupnpc with CMake. It includes an update to the most recent version of miniupnpc (2.2.7), which means we can drop one patch from that commit, and includes a new patch for a change I've upstreamed https://github.com/miniupnp/miniupnp/pull/721, as well as some suggestions from the previous PR. ACKs for top commit: theuni: ACK 5195baa60087ee366290887ad982fc491e14c111. TheCharlatan: utACK 5195baa60087ee366290887ad982fc491e14c111 Tree-SHA512: 5b27e132cd5eed285e9be34c8b96893417d92a1ae55c99345c9a89e1c1c5e40e4bc840bc061b879758b2b11fcb520cd98c3da985c1e153f2e5380cf63efe2d69
2024-05-01rpc: return warnings as an array instead of just a single onestickies-v
The RPC documentation for `getblockchaininfo`, `getmininginfo` and `getnetworkinfo` states that "warnings" returns "any network and blockchain warnings". In practice, only a single warning is returned. Fix that by returning all warnings as an array. As a side benefit, cleans up the GetWarnings() logic.
2024-04-30Merge bitcoin/bitcoin#29645: doc: update release-process.mdAva Chow
1ea8674316f2dce0005f6094b6ee111b045dd770 [doc] update release-process.md and backports section of CONTRIBUTING (glozow) Pull request description: While doing various release process things for the first time, I noticed some of our docs are outdated and/or confusing. ACKs for top commit: achow101: ACK 1ea8674316f2dce0005f6094b6ee111b045dd770 Tree-SHA512: 4ad10d4ce2c33fe15cb02599353107bb72ecb867aefc6c120cfd5cdea42aa8fa3783f9e0218c2f3815f030e0694cc8fb24011ce88358a0206cb07416a256a962
2024-04-30Merge bitcoin/bitcoin#29813: doc: i2p: improve `-i2pacceptincoming` mentionAva Chow
2179e2c3209a41c1419f1f5ed6270a0dad68b50d doc: i2p: improve `-i2pacceptincoming` mention (brunoerg) Pull request description: In i2p documentation, it says that "the first time Bitcoin Core connects to the I2P router, it automatically generates a persistent I2P address and its corresponding private key by default _**or if `-i2pacceptincoming=1` is set**_". This is weird, because `-i2pacceptincoming=1` by itself does not have any effect. Moreover, `-i2pacceptincoming` is 1 by default anyway. ACKs for top commit: laanwj: This documentation change is correct and makes the documentation slightly shorter, thus easier to read. ACK 2179e2c3209a41c1419f1f5ed6270a0dad68b50d davidgumberg: ACK https://github.com/bitcoin/bitcoin/pull/29813/commits/2179e2c3209a41c1419f1f5ed6270a0dad68b50d achow101: ACK 2179e2c3209a41c1419f1f5ed6270a0dad68b50d byaye: ACK 2179e2c3209a41c1419f1f5ed6270a0dad68b50d Tree-SHA512: 18a6a627343fb0aa824029d99df8a232153ba288ce94ec8c5da25693885237381fba505ea1e71c756b2a611243a302d319ca7ae03b526020cd6588710fc2ac17
2024-04-30doc: add release-notes-27064.mdMatthew Zipkin
2024-04-30system: use %LOCALAPPDATA% as default datadir on windowsMatthew Zipkin
2024-04-30depends: miniupnpc 2.2.7fanquake
Includes a temporary patch to fix the Windows Autotools build. See https://miniupnp.tuxfamily.org/files/changelog.php?file=miniupnpc-2.2.7.tar.gz.
2024-04-29doc: add LLVM instruction for macOS < 13Sjors Provoost
2024-04-27build: Bump clang minimum supported version to 15MarcoFalke
2024-04-25Merge bitcoin/bitcoin#29708: depends: build libnatpmp with CMakemerge-script
3c1ae3ee33d4d9dbea046d5ab8ee924a12982759 depends: switch libnatpmp to CMake (Cory Fields) 72ba7b5d263b6d909ae59040536a499a596237c2 depends: libnatpmp f2433bec24ca3d3f22a8a7840728a3ac177f94ba (fanquake) Pull request description: This picks up one of the changes from https://github.com/bitcoin/bitcoin/pull/29232, which is a switch to building libnatpmp with CMake. It includes an update to the most recent version of libnatpmp (https://github.com/miniupnp/libnatpmp/commit/f2433bec24ca3d3f22a8a7840728a3ac177f94ba), which includes (https://github.com/miniupnp/libnatpmp/pull/43). From an initial look I couldn't find any significant difference between the Autotools and CMake produced libs. ACKs for top commit: m3dwards: ACK https://github.com/bitcoin/bitcoin/pull/29708/commits/3c1ae3ee33d4d9dbea046d5ab8ee924a12982759 hebasto: ACK 3c1ae3ee33d4d9dbea046d5ab8ee924a12982759. TheCharlatan: ACK 3c1ae3ee33d4d9dbea046d5ab8ee924a12982759 Tree-SHA512: 1dd9d9933a5fceb9f8c4e1d68cd5cb4456a10a6dd27a6f6316f14493f9d2efad981ef8be9570c09ca82d45163aebd7f4cb2b2449989ec6084268ddba9a564c83
generated by cgit v1.2.3 (git 2.26.2) at 2024-09-12 21:51:34 +0000