aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
2022-04-19Merge bitcoin/bitcoin#24776: docs: update /rest/chaininfo doc referring to ↵MarcoFalke
RPC help 1d95b5c78368575c8885a5bf659cdb4d6261f124 doc: cleanups to mempool rest endpoints (brunoerg) b941dec0a975d441fe08117e84d72aca4c5731bc docs: update `/rest/chaininfo` doc referring to RPC help (brunoerg) Pull request description: Internally, `/rest/chaininfo` gets the infos from `getblockchaininfo` and I just realized the documentation of it in `REST-interface.md` is outdated compared to the `getblockchaininfo` RPC one. This PR removes the documentation of the fields and adds a reference to the RPC help. ACKs for top commit: jonatack: ACK 1d95b5c78368575c8885a5bf659cdb4d6261f124 Tree-SHA512: 643db202e13e8372105460b0871facb11586dc0ff5e86ec9e105a178bcfeefa3555bb047cd28cfaeb3e747f5a2055e27961813c9e299ba7b2d36151e81049507
2022-04-18doc: cleanups to mempool rest endpointsbrunoerg
2022-04-18docs: update `/rest/chaininfo` doc referring to RPC helpbrunoerg
2022-04-15Merge bitcoin/bitcoin#24172: doc: Add pre-splitoff translation update to ↵laanwj
`release-process.md` 6e328ff8d044ac0d0b6e10e842b2b0ad7503f296 doc: Add pre-splitoff translation update to release-process.md (Hennadii Stepanov) Pull request description: This step is required to keep translations in the master branch updated. Branches: - 0.20 -- bitcoin/bitcoin#18492 - 0.21 -- bitcoin/bitcoin#20058, bitcoin/bitcoin#20256 - 22.x -- accidentally missed ACKs for top commit: laanwj: ACK 6e328ff8d044ac0d0b6e10e842b2b0ad7503f296 Tree-SHA512: d9131a6841b2077783b8be4086aa1c87c45978f0c18b141c5e4c62c84ea3e699d666e3c7c446cf0d6d88cc2967139201155d13a71e829039871e8dc424e5c931
2022-04-08Update RPC argument and field naming guideline in developer notesJon Atack
Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
2022-04-08Merge bitcoin/bitcoin#24770: Put lock logging behind DEBUG_LOCKCONTENTION ↵fanquake
preprocessor directive 43947333315d07f59e1247bd76e0ba9d35a99e31 Add DEBUG_LOCKCONTENTION documentation to the developer notes (Jon Atack) 39a34b6877945908759f6a2322f60852e521e2ee Put lock logging behind DEBUG_LOCKCONTENTION preprocessor directive (Jon Atack) Pull request description: This is a more minimal, no-frills version of #24734 for backport. The other fixes and improvements in that pull can be done after. *Copy of the PR 24734 description:* PRs #22736, #22904 and #23223 changed lock contention logging from a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive to a runtime `lock` log category and improved the logging output. This changed the locking from using `lock()` to `try_lock()`: - `void Mutex::UniqueLock::lock()` acquires the mutex and blocks until it gains access to it - `bool Mutex::UniqueLock::try_lock()` doesn't block but instead immediately returns whether it acquired the mutex; it may be used by `lock()` internally as part of the deadlock-avoidance algorithm In theory the cost of `try_lock` might be essentially the [same](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-697) relative to `lock`. The test-and-set logic of these calls is purported to be ~ constant time, optimised and light/quick if used carefully (i.e. no mutex convoying), compared to system calls, memory/cache coherency and fences, wait queues, and (particularly) lock contentions. See the discussion around https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-902851054 and after with respect to performance/cost aspects. However, there are reasonable concerns (see [here](https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691277896) and [here](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-620)) that `Base::try_lock()` may be potentially [costly](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-700) or [risky](https://github.com/bitcoin/bitcoin/pull/22904#issuecomment-930484001) compared to `Base::lock()` in this very frequently called code. One alternative to keep the run-time lock logging would be to gate the `try_lock` call behind the logging conditional, for example as proposed in https://github.com/bitcoin/bitcoin/commit/ccd73de1dd969097d34634c2be2fc32b03fbd09e and ACKed [here](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-901980815). However, this would add the [cost](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-910102353) of `if (LogAcceptCategory(BCLog::LOCK))` to the hotspot, instead of replacing `lock` with `try_lock`, for the most frequent happy path (non-contention). It turns out we can keep the advantages of the runtime lock contention logging (the ability to turn it on/off at runtime) while out of prudence putting the `try_lock()` call and `lock` logging category behind a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive, and also still retain the lock logging enhancements of the mentioned PRs, as suggested in https://github.com/bitcoin/bitcoin/pull/24734#issuecomment-1085785480 by W. J. van der Laan, in https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691280693, and in the linked IRC discussion. Proposed here and for backport to v23. ACKs for top commit: laanwj: Code review ACK 43947333315d07f59e1247bd76e0ba9d35a99e31 Tree-SHA512: 89b1271cae1dca0eb251914b1a60fc5b68320aab4a3939c57eec3a33a3c8f01688f05d95dfc31f91d71a6ed80cfe2d67b77ff14742611cc206175e47b2e5d3b1
2022-04-07lint: codespell 2.1.0fanquake
2022-04-07Merge bitcoin/bitcoin#24152: policy / validation: CPFP fee bumping within ↵fanquake
packages 9bebf35e269b2a918df27708565ecd0c5bd3f116 [validation] don't package validate if not policy or missing inputs (glozow) 51edcffa0e156dba06191a8d5c636ba01fa5b65f [unit test] package feerate and package cpfp (glozow) 1b93748c937e870e7574a8e120a85bee6f9013ff [validation] try individual validation before package validation (glozow) 17a8ffd8020375d60428695858558f2be264aa36 [packages/policy] use package feerate in package validation (glozow) 09f32cffa6c3e8b2d77281a5983ffe8f482a5945 [docs] package feerate (glozow) Pull request description: Part of #22290, aka [Package Mempool Accept](https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a). This enables CPFP fee bumping in child-with-unconfirmed-parents packages by introducing [package feerate](https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#fee-related-checks-use-package-feerate) (total modified fees divided by total virtual size) and using it in place of individual feerate. We also always [validate individual transactions first](https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#always-try-individual-submission-first) to avoid incentive-incompatible policies like "parents pay for children" or "siblings pay for siblings" behavior. ACKs for top commit: instagibbs: reACK https://github.com/bitcoin/bitcoin/pull/24152/commits/9bebf35e269b2a918df27708565ecd0c5bd3f116 mzumsande: Code review ACK 9bebf35e269b2a918df27708565ecd0c5bd3f116 t-bast: ACK https://github.com/bitcoin/bitcoin/pull/24152/commits/9bebf35e269b2a918df27708565ecd0c5bd3f116 Tree-SHA512: 5117cfcc3ce55c00384d9e8003a0589ceac1e6f738b1c299007d9cd9cdd2d7c530d31cfd23658b041a6604d39073bcc6e81f0639a300082a92097682a6ea8c8f
2022-04-06Merge bitcoin/bitcoin#24681: build: Bump libevent minimum version up to 2.1.8fanquake
e40779a4fee03c6c455149bd8e9d1a7ccd991450 refactor: Remove outdated libevent logging code (Fabian Jahr) 0598f36852199d0cee8fe9e676a2e0bec3ebf624 refactor: account for requiring libevent 2.1.8+ (fanquake) aaf72d62c18f9cb325c150cf0cc21abb201607c8 build: Bump libevent minimum version up to 2.1.8 (Hennadii Stepanov) Pull request description: Required to support new functionality in bitcoin/bitcoin#19420. `libevent` availability: https://repology.org/project/libevent/versions ACKs for top commit: laanwj: Code review ACK e40779a4fee03c6c455149bd8e9d1a7ccd991450 fanquake: ACK e40779a4fee03c6c455149bd8e9d1a7ccd991450 Tree-SHA512: ccb14ea2f591484a3df5bc4a19f4f5400ef6b1cfb7dc45dd99f96cb948748215ed3b5debc34869763c91b8c7a26993fdb9b870950c0743c4d01038ab27c5e4e2
2022-04-06Merge bitcoin/bitcoin#24652: doc: rewrite OpenBSD build docs for 7.0fanquake
a2b56dcd1fa102dcb3023cd2af63075525789453 doc: update OpenBSD build docs for 7.0 (fanquake) Pull request description: Removes redundant notes for setting `CC` &`CXX` now that Clang is well and truly the base compiler. See: https://www.openbsd.org/70.html > Disabled base-gcc on amd64. Cleans up the wallet docs, i.e #23446. Make the notes more similar to the FreeBSD notes. ACKs for top commit: shaavan: ACK a2b56dcd1fa102dcb3023cd2af63075525789453 theStack: ACK a2b56dcd1fa102dcb3023cd2af63075525789453 Tree-SHA512: a0494de3b168e5c35f541edf62dcb42529b23387febbe4c004eb82ef9aff6f97def43b6cd5c91e13612c5247767d79553efcd21b9792ccb6a9608302c5d082f1
2022-04-06Merge bitcoin/bitcoin#24098: rest: Use query parameters to control resource ↵MarcoFalke
loading 54b39cfb342d10a448d49299c715e3a25c2aca4a Add release notes (stickies-v) f959fc0397c3f3615e99bc28d2df549d9d52f277 Update /<count>/ endpoints to use a '?count=' query parameter instead (stickies-v) a09497614e9bb603fff36286d9611a25b23eeb02 Add GetQueryParameter helper function (stickies-v) fff771ee864975cee8c831651239bac95503c37a Handle query string when parsing data format (stickies-v) c1aad1b3b95b7c6bdf05e0c2095aba2f2db8310b scripted-diff: rename RetFormat to RESTResponseFormat (stickies-v) 9f1c54787c81177dd56a31c881a9ad2834a122dc Refactoring: move declarations to rest.h (stickies-v) Pull request description: In RESTful APIs, [typically](https://rapidapi.com/blog/api-glossary/parameters/query/) path parameters (e.g. `/some/unique/resource/`) are used to represent resources, and query parameters (e.g. `?sort=asc`) are used to control how these resources are being loaded through e.g. sorting, pagination, filtering, ... As first [discussed in #17631](https://github.com/bitcoin/bitcoin/pull/17631#discussion_r733031180), the [current REST api](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) contains two endpoints `/headers/` and `/blockfilterheaders/` that rather unexpectedly use path parameters to control how many (filter) headers are returned in the response. While this is no critical issue, it is unintuitive and we are still early enough to easily phase this behaviour out and ensure new endpoints (if any) do not have to stick to non-standard behaviour just for internal consistency. In this PR, a new `HTTPRequest::GetQueryParameter` method is introduced to easily parse query parameters, as well as two new `/headers/` and `/blockfilterheaders/` endpoints that use a count query parameter are introduced. The old path parameter-based endpoints are kept without too much overhead, but the documentation now points to the new query parameter-based endpoints as the default interface to encourage standardness. ## Behaviour change ### New endpoints and default values `/headers/` and `/blockfilterheaders/` now have 2 new endpoints that contain query parameters (`?count=<count>`) instead of path parameters (`/<count>/`), as described in REST-interface.md. Since query parameters can easily have default values, I have set this at 5 for both endpoints. **headers** `GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>` should now be used instead of `GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` **blockfilterheaders** `GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>` should now be used instead of `GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` ### Some previously invalid API calls are now valid API calls that contained query strings in the URI could not be parsed prior to this PR. This PR changes behaviour in that previously invalid calls (e.g. `GET /rest/headers/5/somehash.json?someunusedparam=foo`) would now become valid, as the query parameters are properly parsed, and discarded if unused. For example, prior to this PR, adding an irrelevant `someparam` parameter would be illegal: ``` GET /rest/headers/5/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true -> Invalid hash: 0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true ``` **This behaviour change affects all rest endpoints, not just the 2 new ones introduced here.** *(Note: I'd be open to implementing additional logic to refuse requests containing unrecognized query parameters to minimize behaviour change, but for the endpoints that we currently have I don't really see the point for that added complexity. E.g. I don't see any scenarios where misspelling a parameter could lead to harmful outcomes)* ## Using the REST API To run the API HTTP server, start a bitcoind instance with the `-rest` flag enabled. To use the `blockfilterheaders` endpoint, you'll also need to set `-blockfilterindex=1`: ``` ./bitcoind -signet -rest -blockfilterindex=1 ``` As soon as bitcoind is fully up and running, you should be able to query the API, for example by using curl on the command line: ```curl "127.0.0.1:38332/rest/chaininfo.json"```. To more easily parse the JSON output, you can also use tools like 'jq' or `json_pp`, e.g.: ``` curl -s "localhost:38332/rest/blockfilterheaders/basic/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?count=2" | json_pp . ``` ## To do - [x] update `doc/release-notes` ## Feedback This is my first PR (hooray!). Please don't hold back on any feedback/comments/nits/... you may have, big or small, whether they are code, process, language, ... related. I welcome private messages too if there's anything you don't want to clutter the PR with. I'm here to learn and am grateful for everyone's input. ACKs for top commit: stickies-v: I've had to push a tiny doc update to `REST-interface.md` (`git range-diff 219d728 9aac438 54b39cf`) since this was not merged for v23, but since there are no significant changes beyond theStack and jnewbery's ACKs I think this PR is now ready to be considered for merging? @MarcoFalke jnewbery: ACK 54b39cfb342d10a448d49299c715e3a25c2aca4a theStack: re-ACK 54b39cfb342d10a448d49299c715e3a25c2aca4a Tree-SHA512: 3b393ffde34f25605ca12c0b1300799a19684b816a1d03aed38b0f5439df47bfe6a589ffbcd7b83fd2def6c9d00a1bae5e45b1d18df4ae998c617c709990f83f
2022-04-05Add release notesstickies-v
2022-04-05Update /<count>/ endpoints to use a '?count=' query parameter insteadstickies-v
In most RESTful APIs, path parameters are used to represent resources, and query parameters are used to control how these resources are being filtered/sorted/... The old /<count>/ functionality is kept alive to maintain backwards compatibility, but new paths with query parameters are introduced and documented as the default interface so future API methods don't break consistency by using query parameters.
2022-04-05Merge bitcoin/bitcoin#24710: Add concrete steps in doc/cjdns.md to easily ↵laanwj
find a friend 6a02355ae9e830ea40b5408acc564e9eb1da1378 Add and improve informational links in doc/cjdns.md (Jon Atack) 19538dd41ecd9f593ad56f1f5f3a2cb45ad2b4ef Add concrete steps in doc/cjdns.md to easily find a friend (Jon Atack) Pull request description: and improve the informational links. CJDNS functions with a friend-of-a-friend topology and a key hurdle to getting started is to find a public peer and set up an outbound connection to it. This update makes doing it much easier for people getting started. Credit to Vasil Dimov for an [IRC suggestion in October 2021](https://www.erisian.com.au/bitcoin-core-dev/log-2021-10-04.html#l-469) and to stickies-v for IRC discussions this week and the [testing guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide) that led me to redo these steps, provide feedback at https://github.com/bitcoin/bitcoin/issues/24706 and refine the added documentation here. ACKs for top commit: dunxen: ACK 6a02355 stickies-v: re-ACK [6a02355](https://github.com/bitcoin/bitcoin/commit/6a02355ae9e830ea40b5408acc564e9eb1da1378) even though I wasn't opposed to the "friend" terminology since it's the language CJDNS seems to use to denominate the peers you connect to directly in general. Not worth bikeshedding over though. lsilva01: Strong ACK 6a02355 Tree-SHA512: b2fa2a200a6a55a709486f7ed2d3830cabffbbffa61a0d211fcb666a918b5754d4e99a58c32909fe58540598066e6ff67bf2fa2fcd56b1b5dcff3c2162f6d962
2022-04-05Add DEBUG_LOCKCONTENTION documentation to the developer notesJon Atack
2022-04-05Merge bitcoin/bitcoin#24583: doc: Add template for empty release notesMarcoFalke
fa4943e8df2e1048a5030f1d93776ca2b9da7b8a doc: Add template for empty release notes (MarcoFalke) Pull request description: * Move release process notes from the release notes to the release process documentation * Clarify that wallet RPC or Settings related release notes snippets should not be duplicated. I think it should be sufficient to only mention them in the wallet section and leave them out from the general RPC section. * Create an empty template to ensure the release notes can be cleared with a single `cp` command. Also, this ensures that the "no duplication" note isn't deleted again. (We used to have it in at least the 22.0 and 21.0 release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md#updated-settings , but it was lost in the 23.0 notes) ACKs for top commit: laanwj: ACK fa4943e8df2e1048a5030f1d93776ca2b9da7b8a Tree-SHA512: 808e100ee1e371f7746a479ddfb237c6895935cffefc0e49033505492a03288013d5c20386af30f2a7dca8ad0c0628bdb6673dcb5cc4fcf4d0183b0ec65ce941
2022-04-04Merge bitcoin/bitcoin#24668: build, qt: bump Qt5 version to 5.15.3fanquake
7f6042849c976ef1c7ac90c6aa8982ee1492a4bf build, qt: use one patch per line in depends/packages/qt.mk (Pavol Rusnak) 826cbc470fbb1dabbb287fa2b5b6705b41e133d3 build, qt: drop fix_no_printer.patch (Hennadii Stepanov) ef20add4c98674183720d9631ac780f9a248b487 build, qt: bump Qt5 version to 5.15.3 (Pavol Rusnak) Pull request description: build, qt: bump Qt5 version to 5.15.3 Qt 5.15.3 release is a patch release made on the top of Qt 5.15.2. As a patch release, Qt 5.15.3 does not add any new functionality but provides bug fixes and other improvements. https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.3/release-note.md * dropped patches: - patches/qt/dont_use_avx_android_x86_64.patch - patches/qt/fix_bigsur_style.patch * adjusted patches: - patches/qt/fix_android_jni_static.patch - patches/qt/fix_limits_header.patch - patches/qt/use_android_ndk23.patch ACKs for top commit: hebasto: ACK 7f6042849c976ef1c7ac90c6aa8982ee1492a4bf fanquake: ACK 7f6042849c976ef1c7ac90c6aa8982ee1492a4bf Tree-SHA512: dd79475901bc9636fb0ce2424f63ddfe8ab5f85f7f35ac64b0e8708042793c19663be1abdcaef6be95e30bae8aa9e6da4389d768de5c102ded8ab61b3d02b07b
2022-04-02Merge bitcoin/bitcoin#24594: doc: update release-process.mdfanquake
ac45a43d894a50ada785c658c261446d6b881224 doc: update release-process.md (gruve-p) Pull request description: ACKs for top commit: achow101: ACK ac45a43d894a50ada785c658c261446d6b881224 Tree-SHA512: eb49310e5645fcab47c6a268221b688d0ae4ffb1cc6d66fc097da1feb61aa894fb00065c20cd2413b775b598f8c955d48240608107776e4f1016703d52a81212
2022-04-01[docs] package feerateglozow
2022-04-01build, qt: bump Qt5 version to 5.15.3Pavol Rusnak
Qt 5.15.3 release is a patch release made on the top of Qt 5.15.2. As a patch release, Qt 5.15.3 does not add any new functionality but provides bug fixes and other improvements. https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.3/release-note.md * dropped patches: - patches/qt/dont_use_avx_android_x86_64.patch - patches/qt/fix_bigsur_style.patch * adjusted patches: - patches/qt/fix_android_jni_static.patch - patches/qt/fix_limits_header.patch - patches/qt/use_android_ndk23.patch Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
2022-04-01Add and improve informational links in doc/cjdns.mdJon Atack
2022-04-01Add concrete steps in doc/cjdns.md to easily find a friendJon Atack
2022-03-30Merge bitcoin/bitcoin#24118: Add 'sendall' RPC née sweepMarcoFalke
bb84b7145b31dbfdcb4cf0b9b6e612a57e573993 add tests for no recipient and using send_max while inputs are specified (ishaanam) 49090ec4025152c847be8a5ab6aa6f379e345260 Add sendall RPC née sweep (Murch) 902793c7772e5bdd5aae5b0d20a32c02a1a6dc7c Extract FinishTransaction from send() (Murch) 6d2208a3f6849a3732af6ff010eeea629b9b10d0 Extract interpretation of fee estimation arguments (Murch) a31d75e5fb5c1304445d698595079e29f3cd3a3a Elaborate error messages for outdated options (Murch) 35ed094e4b0e0554e609709f6ca1f7d17096882c Extract prevention of outdated option names (Murch) Pull request description: Add sendall RPC née sweep _Motivation_ Currently, the wallet uses a fSubtractFeeAmount (SFFO) flag on the recipients objects for all forms of sending calls. According to the commit discussion, this flag was chiefly introduced to permit sweeping without manually calculating the fees of transactions. However, the flag leads to unintuitive behavior and makes it more complicated to test many wallet RPCs exhaustively. We proposed to introduce a dedicated `sendall` RPC with the intention to cover this functionality. Since the proposal, it was discovered in further discussion that our proposed `sendall` rpc and SFFO have subtly different scopes of operation. • sendall: Use _given UTXOs_ to pay a destination the remainder after fees. • SFFO: Use a _given budget_ to pay an address the remainder after fees. While `sendall` will simplify cases of spending a given set of UTXOs such as paying the value from one or more specific UTXOs, emptying a wallet, or burning dust, we realized that there are some cases in which SFFO is used to pay other parties from a limited budget, which can often lead to the creation of change outputs. This cannot be easily replicated using `sendall` as it would require manual computation of the appropriate change amount. As such, sendall cannot replace all uses of SFFO, but it still has a different use case and will aid in simplifying some wallet calls and numerous wallet tests. _Sendall call details_ The proposed sendall call builds a transaction from a specific subset of the wallet's UTXO pool (by default all of them) and assigns the funds to one or more receivers. Receivers can either be specified with a given amount or receive an equal share of the remaining unassigned funds. At least one recipient must be provided without assigned amount to collect the remainder. The `sendall` call will never create change. The call has a `send_max` option that changes the default behavior of spending all UTXOs ("no UTXO left behind"), to maximizing the output amount of the transaction by skipping uneconomic UTXOs. The `send_max` option is incompatible with providing a specific set of inputs. --- Edit: Replaced OP with latest commit message to reflect my updated motivation of the proposal. ACKs for top commit: achow101: re-ACK bb84b7145b31dbfdcb4cf0b9b6e612a57e573993 Tree-SHA512: 20aaf75d268cb4b144f5d6437d33ec7b5f989256b3daeeb768ae1e7f39dc6b962af8223c5cb42ecc72dc38cecd921c53c077bc0ec300b994e902412213dd2cc3
2022-03-29Add sendall RPC née sweepMurch
_Motivation_ Currently, the wallet uses a fSubtractFeeAmount (SFFO) flag on the recipients objects for all forms of sending calls. According to the commit discussion, this flag was chiefly introduced to permit sweeping without manually calculating the fees of transactions. However, the flag leads to unintuitive behavior and makes it more complicated to test many wallet RPCs exhaustively. We proposed to introduce a dedicated `sendall` RPC with the intention to cover this functionality. Since the proposal, it was discovered in further discussion that our proposed `sendall` rpc and SFFO have subtly different scopes of operation. • sendall: Use _specific UTXOs_ to pay a destination the remainder after fees. • SFFO: Use a _specific budget_ to pay an address the remainder after fees. While `sendall` will simplify cases of spending from specific UTXOs, emptying a wallet, or burning dust, we realized that there are some cases in which SFFO is used to pay other parties from a limited budget, which can often lead to the creation of change outputs. This cannot be easily replicated using `sendall` as it would require manual computation of the appropriate change amount. As such, sendall cannot replace all uses of SFFO, but it still has a different use case and will aid in simplifying some wallet calls and numerous wallet tests. _Sendall call details_ The proposed sendall call builds a transaction from a specific subset of the wallet's UTXO pool (by default all of them) and assigns the funds to one or more receivers. Receivers can either be specified with a specific amount or receive an equal share of the remaining unassigned funds. At least one recipient must be provided without assigned amount to collect the remainder. The `sendall` call will never create change. The call has a `send_max` option that changes the default behavior of spending all UTXOs ("no UTXO left behind"), to maximizing the output amount of the transaction by skipping uneconomic UTXOs. The `send_max` option is incompatible with providing a specific set of inputs.
2022-03-28doc: update OpenBSD build docs for 7.0fanquake
Removes redundant notes for setting CC & CXX now that Clang is well and truly the base compiler. Cleans up the wallet docs, i.e #23446. Make the notes more similar to FreeBSD.
2022-03-26build: Bump libevent minimum version up to 2.1.8Hennadii Stepanov
Required to support new functionality.
2022-03-25Merge bitcoin/bitcoin#24665: doc: document clang tidy named argsfanquake
7e22d80af333b202939bcb2631082006c097bf22 addrman: fix incorrect named args (fanquake) 67f654ef612c8dbefb969e6e67c286ea2c2e82d6 doc: Document clang-tidy in dev notes (MarcoFalke) Pull request description: The documentation, and a single commit extracted from #24661. Motivation: > Incorrect named args are source of bugs, like https://github.com/bitcoin/bitcoin/pull/22979. > To allow them being checked by clang-tidy, use a format it can understand. ACKs for top commit: glozow: ACK 7e22d80af333b202939bcb2631082006c097bf22 Tree-SHA512: 4037fcea59fdf583b171bce7ad350299fe5f9feb3c398413432168f3b9a185e51884d5b30e4b4ab9c6c5bb896c178cfaee1d78d5b4f0034cd70121c9ea4184b7
2022-03-25doc: update release-process.mdgruve-p
2022-03-25[doc] release notes for random change targetglozow
2022-03-25doc: Document clang-tidy in dev notesMarcoFalke
2022-03-25Merge bitcoin/bitcoin#24600: doc: mention that BDB is for the legacy wallet ↵fanquake
in build-freebsd.md b5ba3b5b2cbec4db94037baad960410fe98f3fdd doc: mention that BDB is for the legacy wallet in build-freebsd.md (fanquake) Pull request description: Re-order legacy and descriptor wallet section. Remove prelude that pointlessly repeats the same info. Cleanup configure examples. FreeBSD version of https://github.com/bitcoin/bitcoin/pull/23446. ACKs for top commit: shaavan: ACK b5ba3b5b2cbec4db94037baad960410fe98f3fdd Tree-SHA512: ed85acee5c1b933b57d038d144768da1c4b1f1cfd441d9191353b82d50af16adb10aabb3b4661dc9aee54405ab3af2b800e39f9973261a041b2cf0db8675b5c4
2022-03-24doc, init: add links to doc/cjdns.mdJon Atack
2022-03-24Merge bitcoin/bitcoin#24555: doc: create initial doc/cjdns.md for CJDNS ↵laanwj
how-to documentation f44efc3e2c5664825d7bd071f9dc38b5b9111ae1 doc: update i2p.md with cjdns, improve local addresses section (Jon Atack) 3bf6f0cf2cb3a958e7cc346760009af50c2fa304 doc: update tor.md with cjdns and getnodeaddresses, fix tor grep, (Jon Atack) ed15848475a10fcacaef4eeb38cd7f93ce038c47 doc: create initial doc/cjdns.md for cjdns how-to documentation (Jon Atack) Pull request description: and update and improve doc/tor.md and doc/i2p.md. Adapted in part from the CJDNS description in https://github.com/bitcoin/bitcoin/pull/23077 and feedback by Vasil Dimov and from the CJDNS documentation and feedback by Caleb James DeLisle. Targets backport to v23.x. Co-authored-by: Vasil Dimov <vd@FreeBSD.org> ACKs for top commit: vasild: ACK f44efc3e2c5664825d7bd071f9dc38b5b9111ae1 lsilva01: ACK f44efc3 Tree-SHA512: 7b7c69f76bc8a5705d324892f32bfe0eb21bcf048054748053eca167c65a2121f6332f40ac6ff98c955e6e8b53233c74c365d887c364ef1d5944f1c49675a6b4
2022-03-24doc: mention that BDB is for the legacy wallet in build-netbsd.mdfanquake
Re-order legacy and descriptor wallet section. Add an additional configure example. NetBSD version of #23446.
2022-03-23doc: mention that BDB is for the legacy wallet in build-freebsd.mdfanquake
Re-order legacy and descriptor wallet section. Remove prelude that pointlessly reqpeats the same info. Cleanup configure examples.
2022-03-22doc: remove unneeded documentation on basic package management on FreeBSDjessebarton
This is in reference to #24618
2022-03-22doc: update i2p.md with cjdns, improve local addresses sectionJon Atack
2022-03-22doc: update tor.md with cjdns and getnodeaddresses, fix tor grep,Jon Atack
and improve local addresses section
2022-03-22doc: create initial doc/cjdns.md for cjdns how-to documentationJon Atack
Adapted in part from the CJDNS description in #23077 by Vasil Dimov and from CJDNS documentation and feedback by Caleb James DeLisle. Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
2022-03-18doc: clarify that BDB is only required for the legacy walletfanquake
2022-03-17Merge bitcoin/bitcoin#24585: doc: mention that BDB is for the legacy wallet ↵MarcoFalke
in build-osx.md 57f3f5cecfac45b3f399ff174905dca25ca556b5 doc: s/Compiler/Dependency in dependencies.md (fanquake) bf846779caf13673d4daca190a652c4e14b2200b doc: cleanup wallet docs in build-osx.md (fanquake) Pull request description: Re-order legacy and descriptor wallet section. Installing sqlite isn't required (the version pre-installed on macOS is just as good as what will be installed via `brew`). Remove prelude that pointlessly repeats the same info. Basically the macOS version of #23446. Includes a small fixup from #23565. ACKs for top commit: RandyMcMillan: ACK 57f3f5c hebasto: ACK 57f3f5cecfac45b3f399ff174905dca25ca556b5, I have reviewed the changes and they look OK, I agree they can be merged. Tree-SHA512: a1ca5f73aa4f4f56de747fd9669bce572c1d7d23925afb47b5d963314df1738762ea26428c040e9c706d288eb7e775227d2387a322cda065885b89c6a619314f
2022-03-17doc: Add template for empty release notesMarcoFalke
2022-03-16Merge bitcoin/bitcoin#24588: doc: Drop a note about Intel-based Macsfanquake
e359ba6b35edebf02b968fe60cae48473ed88826 doc: Drop a note about Intel-based Macs (Hennadii Stepanov) Pull request description: The work on building stuff during the recent months made the removed note obsolete. ACKs for top commit: fanquake: ACK e359ba6b35edebf02b968fe60cae48473ed88826 Tree-SHA512: 8cf851c8602ef004c9ca009a97345b828bacbb6ecf1eee803d3ce64870a9766c196849b8843237e7bc1be5697de928b759a6dfa0407022c144d23d0293322200
2022-03-16Merge bitcoin/bitcoin#24519: doc: update multisig-tutorial.md to descriptor ↵Andrew Chow
wallet by default 5347c9732ff24bfcdcd62d0291972c86c80558dc doc: update multisig-tutorial.md to default wallet type (Jon Atack) Pull request description: Follow-up to #24281 and https://github.com/bitcoin/bitcoin/pull/24281#issuecomment-1033996386. The default wallet type was changed to descriptor wallets in #23002. ACKs for top commit: laanwj: ACK 5347c9732ff24bfcdcd62d0291972c86c80558dc michaelfolkson: ACK 5347c9732ff24bfcdcd62d0291972c86c80558dc achow101: ACK 5347c9732ff24bfcdcd62d0291972c86c80558dc theStack: Concept and code-review ACK 5347c9732ff24bfcdcd62d0291972c86c80558dc Tree-SHA512: 8074a33ad253ecb7d3f78645a00c808c7c224996cc1748067928aa59ef31a58f24fcfc75169494b26a19c7fbbf23bbd78516ab4102bc52fa92f08f1f49b18b63
2022-03-16doc: Drop a note about Intel-based MacsHennadii Stepanov
2022-03-16doc: s/Compiler/Dependency in dependencies.mdfanquake
2022-03-16doc: cleanup wallet docs in build-osx.mdfanquake
Re-order legacy and descriptor wallet section. Installing sqlite isn't required. Remove prelude that pointlessly reqpeats the same info.
2022-03-16doc: rework dependencies.mdfanquake
2022-03-12Merge bitcoin/bitcoin#24164: build: Bump minimum required clang/libc++ to 8.0MarcoFalke
fae20e6b50306f91c74037e915aa0ab75a0a6b3b Revert "Avoid the use of P0083R3 std::set::merge" (MarcoFalke) fab53b5fd45cf55a1d4d313e46ffce7396c9590e ci/doc: Set minimum required clang/libc++ version to 8.0 (MarcoFalke) Pull request description: This is not for 23.0, but for 24.0. It comes with the following benefits: * Can use C++17 P0083R3 std::set::merge from libc++ 8.0 * No longer need to provide support for clang-7, which already fails to compile on some architectures (https://github.com/bitcoin/bitcoin/issues/21294#issuecomment-998098483) This should be fine, given that all supported operating systems ship with at least clang-10: * CentOS 8: clang-12 * Stretch: https://packages.debian.org/stretch/clang-11 * Buster: https://packages.debian.org/buster-backports/clang-11 * Bionic: https://packages.ubuntu.com/bionic-updates/clang-10 * Focal: https://packages.ubuntu.com/focal/clang-10 ACKs for top commit: fanquake: ACK fae20e6b50306f91c74037e915aa0ab75a0a6b3b - I think this is fine to do. I would be surprised if in another 6 months time someone was stuck on a system we supported, needing to compile Core, and only had access to Clang 7 or older. As mentioned in the PR description, all systems we currently support, already support multiple newer versions of Clang. hebasto: ACK fae20e6b50306f91c74037e915aa0ab75a0a6b3b, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: 3b4c6c130ff40dd7e84934af076863415e5dd661d823c72e3e3832566c65be6e877a7ef9164bbcf394bcea4b897fc29a48db0f231c22ace0e2c9b5638659a628
2022-03-10doc: remove Boost LDFLAGS from netBSD build docsfanquake
We no-longer link against any Boost libs, so we shouldn't need to use any Boost linker flags.
generated by cgit v1.2.3 (git 2.26.2) at 2024-07-19 11:36:42 +0000