aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)Author
2022-05-25Merge bitcoin/bitcoin#24757: build, ci: add `DEBUG_LOCKCONTENTION` to ↵fanquake
--enable-debug and CI bd5dbc30dbef10f0fb4508b461e77787213aa0de doc: update developer notes wrt --enable-debug and DEBUG_LOCKCONTENTION (Jon Atack) 345647c4da12b5a0f9c6fd7e519df743264f5611 ci: add DEBUG_LOCKCONTENTION to CI task containing DEBUG_LOCKORDER (Jon Atack) 247d17033f2727e9f7d5dddecaea37c46f1230ee build: add DEBUG_LOCKCONTENTION to --enable-debug configuration (Jon Atack) Pull request description: - Add `DEBUG_LOCKCONTENTION` flag to the `--enable-debug` configuration - Add `DEBUG_LOCKCONTENTION` to the native tsan CI task that contains `DEBUG_LOCKORDER` (verified that the CI has all logging categories enabled by default, except libevent and leveldb) - Update the developer notes that `--enable-debug` configures `DEBUG_LOCKCONTENTION` Related to https://github.com/bitcoin/bitcoin/issues/24709. Top commit has no ACKs. Tree-SHA512: 8e9c068d9a4841ad1ab08a2bf4ce96d6fee195e458f6802852cba0d71deb9a485059d355ac8bd1fc15410437f19503b77fc425bf53a1d48dc82a43a979daad17
2022-05-23Merge bitcoin/bitcoin#25122: rpc: getreceivedbylabel, return early if no ↵Andrew Chow
addresses were found in the address book baa3ddc49c46d00e3e0de06e494656f0f00b0ee8 doc: add release notes about `getreceivedbylabel` returning an error if the label is not in the address book. (furszy) 8897a21658ad93f7b628eb2a3411fec2265d73fb rpc: getreceivedbylabel, don't loop over the entire wallet txs map if no destinations were found for the input label. (furszy) Pull request description: Built on top of #23662, coming from comment https://github.com/bitcoin/bitcoin/pull/23662#pullrequestreview-971407999. If `wallet.GetLabelAddresses()` returns an empty vector (the wallet does not have stored destinations with that label in the addressbook) or if none of the returned destinations are from the wallet, we can return the function right away. Otherwise, we are walking through all the wallet txs + outputs for no reason (`output_scripts` is empty). ACKs for top commit: achow101: ACK baa3ddc49c46d00e3e0de06e494656f0f00b0ee8 theStack: re-ACK baa3ddc49c46d00e3e0de06e494656f0f00b0ee8 w0xlt: ACK https://github.com/bitcoin/bitcoin/pull/25122/commits/baa3ddc49c46d00e3e0de06e494656f0f00b0ee8 Tree-SHA512: 00e10365b179bf008da2f3ef8fbb3ee04a330426374020e3f2d0151b16991baba4ef2b944e4659452f3e4d6cb20f128d0918ddf0453933a25a4d9fd8414a1911
2022-05-20doc: add release notes about `getreceivedbylabel` returning an error if the ↵furszy
label is not in the address book.
2022-05-20doc: remove passing `--disable-external-signer` in OpenBSD build guideSebastian Falbesoner
Since the Boost.Process usage check was added to the build system (commit abc057c6030b2a0ddab46835a7801054da677781), passing the option `--disable-external-signer` explicitly is not needed anymore on OpenBSD; The configure script will automatically detect that including <boost/process.hpp> leads to a compile error and disable external signer support accordingly.
2022-05-20doc: update developer notes wrt --enable-debug and DEBUG_LOCKCONTENTIONJon Atack
2022-05-19doc: add release notes about removal of the `deprecatedrpc=exclude_coinbase`Sebastian Falbesoner
2022-05-18Add link to NetBSD releaseMarnix
2022-05-17Merge bitcoin/bitcoin#25114: rpc: remove deprecated "softforks" field from ↵MacroFake
getblockchaininfo a01b92ad8672dcf4369ee9cf36a6b0157d73786c doc: add release notes about removal of the `deprecatedrpc=softforks` flag (Sebastian Falbesoner) 8c5533c7a953e79b423b465905dbfaa45ad60a49 rpc: remove deprecated "softforks" field from getblockchaininfo (Sebastian Falbesoner) Pull request description: Information on soft fork status has been moved from the `getblockchaininfo` RPC to the `getdeploymentinfo` RPC in #23508. The "softfork" result in `getblockchaininfo` was still available for 23.0 with the `-deprecatedrpc=softforks` configuration option, but this can be fully removed now for the next release (24.0). ACKs for top commit: shaavan: ACK a01b92ad8672dcf4369ee9cf36a6b0157d73786c ajtowns: ACK a01b92ad8672dcf4369ee9cf36a6b0157d73786c Tree-SHA512: 692d9d02fdf0b3c18376644a85b24b57efebf612738084c01ef47d47e41861e773688613a808e81f10ab6eec340de00eef96987a1e34d612aaf7f0a0b134d89e
2022-05-13doc: add release notes about removal of the `deprecatedrpc=softforks` flagSebastian Falbesoner
2022-05-10Add clang lifetimebound section to developer notesJon Atack
2022-05-10Add C++ functions and methods section to developer notesJon Atack
Credit for some parts to the Google C++ Style Guide "Inputs and Outputs" section at https://google.github.io/styleguide/cppguide.html#Inputs_and_Outputs Co-authored-by: laanwj <126646+laanwj@users.noreply.github.com>
2022-05-09Link in developer notes style to internal interface exceptionJon Atack
2022-05-09Prefer Python for scripts in developer notesJon Atack
along with a few miscellaneous touch-ups.
2022-05-06Remove obsolete BDB ENABLE_WALLET section in developer notesJon Atack
2022-05-05Merge bitcoin/bitcoin#25006: guix: consolidate kernel headers to 5.15, ↵fanquake
specify 3.2.0 as minimum supported eb02713efc1751e2c4b60f72f5b407e2bc35af34 doc: add minimum required kernel version to dependencies.md (fanquake) dcad5f70f111e32cf39d39b9d71366a48b3686e2 guix: consolidate kernel headers to 5.15 (fanquake) Pull request description: Our minimum supported kernel version is currently defined by Guix, as the version passed to the [`--enable-kernel=`](https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html) option when configuring glibc. That version is [currently set to 3.2.0](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=34e9eae68c9583acce5abc4100add3d88932a5ae#n776): ```scheme ;; This is the default for most architectures as of GNU libc 2.26, ;; but we specify it explicitly for clarity and consistency. See ;; "kernel-features.h" in the GNU libc for details. "--enable-kernel=3.2.0" ``` and has been that way since we started using Guix (i.e from Guix 1.3.0, with the release v22.0). Passing `--enable-kernel` defines `__LINUX_KERNEL_VERSION` inside glibc, which is then used to determine supported features & syscall usage. For example, some defines in `unix/sysv/linux/kernel-features.h`, from glibc version 2.24, where glibcs default supported kernel version was still 2.6.32 (it's more modern as of recent releases): ```cpp #ifndef __LINUX_KERNEL_VERSION /* We assume the worst; all kernels should be supported. */ # define __LINUX_KERNEL_VERSION0 #endif /* Support for various CLOEXEC and NONBLOCK flags was added in 2.6.23. */ #define __ASSUME_O_CLOEXEC1 /* prlimit64 is available in 2.6.36. */ #if __LINUX_KERNEL_VERSION >= 0x020624 # define __ASSUME_PRLIMIT641 #endif ``` Note that because we currently specify the `5.15` headers, the exact version being used, i.e 5.15.x, changes when we update our time-machine commit, as Guix updates all it's header packages as new point releases become available. Currently it is [`5.15.28`](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm?id=34e9eae68c9583acce5abc4100add3d88932a5ae#n380). The changelog for the 5.15 headers is available [here](https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.36). Similar to glibc, it may currently be possible to build and run bitcoind against older kernels, however, for the purposes of documenting what we support for our release binaries, I can't see a reason to document anything other than the version that we are targeting when building the glibc used to build the release binaries. Guix Build (on x86_64): ```bash 22ff2d3a72d337c4eccbfa4c834a67c7c3397f225aedb71a3c636f2708964e93 guix-build-eb02713efc17/output/aarch64-linux-gnu/SHA256SUMS.part e316b2d0806183e0e51a25722f48af85d145b1581f44f68b925d9f484a5aa0d3 guix-build-eb02713efc17/output/aarch64-linux-gnu/bitcoin-eb02713efc17-aarch64-linux-gnu-debug.tar.gz da667d935d9331c5cbca2e0e334cd7e56202ee294553459672fa50f13f501c4d guix-build-eb02713efc17/output/aarch64-linux-gnu/bitcoin-eb02713efc17-aarch64-linux-gnu.tar.gz f44f2921f3dac2c545806dffb579137fb9eeeee15671395f6a7f817ed6213143 guix-build-eb02713efc17/output/arm-linux-gnueabihf/SHA256SUMS.part 101bab25ab2a6c36729cdf840264a85700cc3cfa23d3900b0bee0ac9ae637e8d guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf-debug.tar.gz 9f7338ee42234949ef3104c6cb2b8a723d616a46d0047d833062adc92e3b6b72 guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf.tar.gz 5ca08e7b38c4dd4456145602f25b015c164c0cd0317dd2a26855dc0495605418 guix-build-eb02713efc17/output/arm64-apple-darwin/SHA256SUMS.part 186c9e2df4034472107964e835ee7a05777c7a0fa5e0db12b5740f18e732d7d5 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.dmg 4e252c7775662777ddcb0a1b0efac6b6e71c25479d6b44b821199ae00abd18ca guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.tar.gz 4360342994d54839bbf5fb4d86c6c0b0a3cbcef68b0d2c991aab6e81301638e7 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin.tar.gz f354822050cd625de7445cfa317475cfad90a7e39d135c5b99950ee69969f445 guix-build-eb02713efc17/output/dist-archive/bitcoin-eb02713efc17.tar.gz aa864574dd692bb40df95e17c08113f5bcd04b7d5997a2f74ca0557cae3edfcd guix-build-eb02713efc17/output/powerpc64-linux-gnu/SHA256SUMS.part 45df2a4ec5592834fd08d36068cd0968de281870cb9df48cc4783078b85985dd guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu-debug.tar.gz 2bc1c481635ac073d61f51db425576a42a54b16218a00e5f80579426dbf9677b guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu.tar.gz 403d7790e611d3e07b25e02549c9f50e51fff2e1a323605db4f9a569712771a7 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/SHA256SUMS.part db40032c3b25d95012496f1b3fa5df7f207dcbeefa510bd140b96df4dfd84c88 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu-debug.tar.gz eea8b4ee96dc8a9813b727550bf07202a6f9cba99605247813beb5251c7f2623 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu.tar.gz 7164e539d25c300b993a620caacdcef659bb6a7c4775a873e30ee645c9ceed15 guix-build-eb02713efc17/output/riscv64-linux-gnu/SHA256SUMS.part 3ae271e6fb94e5d4e46a402508a02d659e879d222c6696e57c78530157eb39ae guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu-debug.tar.gz 8c37d0b790c28b692804b360605baec4371af4f080c0024ba75f06c0096a4356 guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu.tar.gz 51bbf04cb32b579ba5609fe3ef24e9901f8d49e3311fe9776ee1fdb644f7e0b1 guix-build-eb02713efc17/output/x86_64-apple-darwin/SHA256SUMS.part 8e81f8badb0cff1aa430a899065cf9744b4b2d45addb8e30606a2f8bf08faa26 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.dmg 8b4120b6d83c03dae34b0b5a189522d01c523ab005d816339fdfddf9c412ef15 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.tar.gz 26e633faba4f05f51f4e0bffaa2bbbf8c2d5d134d6777c9395bf9b65af6a808c guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin.tar.gz 16c96d1f349ca3fbf5ffb8e00d5defe1af5a14abb6f61abdbd367e9a5e99bf33 guix-build-eb02713efc17/output/x86_64-linux-gnu/SHA256SUMS.part faa203c9c3943c2f30ca3f4f30c3eee52e38ac9a2f15c6303b0c8ff0be146e07 guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu-debug.tar.gz b5cf5154ac0e2138a4ccbc7639026d909e606b9f55c5859ae54d941eb950759b guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu.tar.gz bc14a09399ef3a6d9696116ddda6509b6cb1726719dfd462106cb9d2fde32efc guix-build-eb02713efc17/output/x86_64-w64-mingw32/SHA256SUMS.part 7c0a773f0e892e41fe8f7b299be655e53f110a64bd6e77c2e7a6b4c699605498 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-debug.zip 27f6a50394c61c0efa2f3afe655a265c64a34249041ef0090f9043cd4cdc8c71 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-setup-unsigned.exe dd5bb661a9d99bbc2c2c7256996b26bef116b2e61b7497ada26b3322550d53cb guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-unsigned.tar.gz 84d5068dd59180498473263d757192a422859c0704a2e45a762d1635e49efb80 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64.zip ``` Guix build (on arm64): ```bash 2bbcf455381d4be6bb402c705dba5655de3e1b62a0ed1dbbfcb573450a63d148 guix-build-eb02713efc17/output/arm-linux-gnueabihf/SHA256SUMS.part c9d982eb6c9efc752fffb3a1d2b14e8cc4d9e2cf4c03c2f02eb320d04f52a86d guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf-debug.tar.gz 0c0b3122dcdc051bee1022dc9b0cf7771b7f6b30fa3e7369c97907d8c10d7ea3 guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf.tar.gz 5388f8a7525ed49d11569988e598a0ec68ddcaf9b35cff0c8bcb02187b0fbaad guix-build-eb02713efc17/output/arm64-apple-darwin/SHA256SUMS.part 16b745e2b2e036d65b549be740116d9b6e819730cc76075f01bdbc4beb166724 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.dmg 18eaede02d12dcbb83003272b5b79a08a10067a326542687ab445bfc623ce9e8 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.tar.gz 5fb73968c7ea50c9642d3cddcd745a512be3043ada314b8a1fc94f179744a1d8 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin.tar.gz f354822050cd625de7445cfa317475cfad90a7e39d135c5b99950ee69969f445 guix-build-eb02713efc17/output/dist-archive/bitcoin-eb02713efc17.tar.gz fad672b9e5d372ba5511c14ed48ef77bcf303d475f35680bd4a668fee150225a guix-build-eb02713efc17/output/powerpc64-linux-gnu/SHA256SUMS.part 246aa854e87675a0b90cc14f7b6affcfefabfc0f79edd3dc96ae6b98010b8b1c guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu-debug.tar.gz 90e968e0bab84e80a9f2fe9498eea7c59d8908f5a16accd93d7f9318a7098ce0 guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu.tar.gz 65f0c018d882d7fc845a9bb1581824b17e7ecf0df7081ab2538f0e617e120a8b guix-build-eb02713efc17/output/powerpc64le-linux-gnu/SHA256SUMS.part 0bf7fcd127180e5e04112914747496db535226bf05126690f259fa0cf2a96642 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu-debug.tar.gz 14fc3e17dfa903f83e44f970c8b4e4726e7476c59d0fffdec815a1c80ec1b51a guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu.tar.gz 9018f95b54d0643d734260b6eb69ee5f086c98e62f25dd579675b467a844793d guix-build-eb02713efc17/output/riscv64-linux-gnu/SHA256SUMS.part e1f2b3678c22103d7b89cbbeec9b2863c9c6f749ff4cbedd74cb6e62598c0a04 guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu-debug.tar.gz bf9fa35119344dfc93048196dd9cd5bb230b0785350ae5150bb4bdb28fd8423d guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu.tar.gz 51bbf04cb32b579ba5609fe3ef24e9901f8d49e3311fe9776ee1fdb644f7e0b1 guix-build-eb02713efc17/output/x86_64-apple-darwin/SHA256SUMS.part 8e81f8badb0cff1aa430a899065cf9744b4b2d45addb8e30606a2f8bf08faa26 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.dmg 8b4120b6d83c03dae34b0b5a189522d01c523ab005d816339fdfddf9c412ef15 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.tar.gz 26e633faba4f05f51f4e0bffaa2bbbf8c2d5d134d6777c9395bf9b65af6a808c guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin.tar.gz 6e5828e2efa4e951b147b8de42f79dee1652933e04c50093bd31ee375c0c4ca9 guix-build-eb02713efc17/output/x86_64-linux-gnu/SHA256SUMS.part 3d3af1d078eee6f66aac2af891fd7d7a77abc3d7164a807d0a7cc44f15e52b9d guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu-debug.tar.gz 13f452bc65194de16fa91ed87be9790ed0d1a178deefb102fa54d3f9832b8c25 guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu.tar.gz 1673b5fca6687ea0f196a5f2ce2b79662b3efe01b71f341fc596069a1ade610c guix-build-eb02713efc17/output/x86_64-w64-mingw32/SHA256SUMS.part d6228bdfb4fbc7b895ed4f0c30e1343c3392bd6e8e5ed33a973887ba0bb749ba guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-debug.zip 27f6a50394c61c0efa2f3afe655a265c64a34249041ef0090f9043cd4cdc8c71 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-setup-unsigned.exe dd5bb661a9d99bbc2c2c7256996b26bef116b2e61b7497ada26b3322550d53cb guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-unsigned.tar.gz 50a68d3644dbe5cb5de21993cd0e8992ab9c6aa88c009a75e5d5a55180476ea6 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64.zip ``` ACKs for top commit: laanwj: ACK eb02713efc1751e2c4b60f72f5b407e2bc35af34 dongcarl: Code Review ACK eb02713efc1751e2c4b60f72f5b407e2bc35af34 vincenzopalazzo: ACK https://github.com/bitcoin/bitcoin/pull/25006/commits/eb02713efc1751e2c4b60f72f5b407e2bc35af34 Tree-SHA512: afee459d881d3231b72711b0beec5410d6b37deb0d94aa0aaca13010f54bf95fadaf7e5081ea8b9c6975a9e2b8be48b761e3b6ce284c06f82be2210db1156e96
2022-05-04doc: update devtools, release-process readmesjosibake
include running `gen-bitcoin-conf.sh` as part of the release process.
2022-05-02doc: update bitcoin-conf.mdJosiah Baker
include instructions on how to run the script
2022-04-28doc: add minimum required kernel version to dependencies.mdfanquake
This matches the version of the kernel targeted when we build the glibcs we use for release builds in Guix. Other versions / scenerios may work, but for documentation purposes, this is the version that makes sense to document, and something we can claim to officially support.
2022-04-26Merge bitcoin/bitcoin#24644: wallet: add tracepoints and algorithm ↵fanquake
information to coin selection ab5af9ca7293239ffc24ea7e23159b8184543f94 test: Add test for coinselection tracepoints (Andrew Chow) ca02b68e8a7147f80cbe84b0742908b0b0faa04d doc: document coin selection tracepoints (Andrew Chow) 8e3f39e4fa2d8c63bc697c9ebd303965fcccea55 wallet: Add some tracepoints for coin selection (Andrew Chow) 15b58383d0029c4ae7b487e03cd451e1580eb91d wallet: compute waste for SelectionResults of preset inputs (Andrew Chow) 912f1ed181161b0365776cd490b63137aaad708a wallet: track which coin selection algorithm produced a SelectionResult (Andrew Chow) Pull request description: Tracepoints can be useful for coin selection as they would allow us to observe what is being selected, selection parameters, and calculation results. So this PR adds 4 new tracepoints: 1. After `SelectCoins` returns in order to observe the `SelectionResult` 2. After the first `CreateTransactionInternal` to observe the created transaction 3. Prior to the second `CreateTransactionInternal` to notify that the optimistic avoid partial spends selection is occurring 4. After the second `CreateTransactionInternal` to observe the created transaction and inform which solution is being used. This PR also adds an algorithm enum to `SelectionResult` so that the first tracepoint will be able to report which algorithm was used to produce that result. The primary use case for these tracepoints is in running coin selection simulations. The script I use to run these simulations use these tracepoints in order to gather data on the algorithm used and the calculated waste. ACKs for top commit: jb55: crACK ab5af9ca7293239ffc24ea7e23159b8184543f94 josibake: crACK https://github.com/bitcoin/bitcoin/pull/24644/commits/ab5af9ca7293239ffc24ea7e23159b8184543f94 0xB10C: ACK ab5af9ca7293239ffc24ea7e23159b8184543f94. Code reviewed, ran the `interface_usdt_coinselection.py` test, and tested with the above bpftrace script (updated `%d` -> `%ld` where necessary, ty achow101). Tree-SHA512: a4bf7a910cdf464622f2f3b5d44c15b891f24852df6e7f8c5b177fe3d8aaa4a1164593a24c3960eb22b16544fa7140e5c745345367b9e291b78395084c0ac8ff
2022-04-25doc: Add 23.0 release noteslaanwj
2022-04-21Merge bitcoin/bitcoin#24936: test: compare `/mempool/contents` response with ↵MarcoFalke
`getrawmempool` RPC bef61496ab5e12e38ac5794cd0836723af070ab5 test: compare `/mempool/contents` response with `getrawmempool` RPC (brunoerg) 5bc5cbaf310f60e89c72e8ecf3f6187c85499027 doc: add reference to `getrawmempool` RPC in `/mempool/contents` REST doc (brunoerg) Pull request description: This PR is similar to #24797, it compares `/mempool/contents` REST response with `getrawmempool` RPC (verbose=True) since they use the same `MempoolToJSON` function. Also, adds a reference to `getrawmempool` RPC help to get details about the fields from `/mempool/contents`. ACKs for top commit: 0xB10C: ACK bef6149 Tree-SHA512: b7e9e9c765ee837986ba167b9234a9b95c9ef0a9ebcc2a03d50f6be6d3aba1480bd77c78111d95df1e4023cde6dfc64bf1e7908d9e5b6f96ca46b76611a4a9b4
2022-04-21doc: document coin selection tracepointsAndrew Chow
2022-04-21Merge bitcoin/bitcoin#24586: doc: add more info to dependencies.mdfanquake
abcb8769bf1d8ed227e6abddd7250a613e91277d doc: add more info to dependencies.md (Pavol Rusnak) Pull request description: Follow-up to https://github.com/bitcoin/bitcoin/pull/23565 I added more info to dependencies.md - especially links to `depends/packages/*.mk` files and link to PRs where used versions were bumped. Preview at: https://github.com/prusnak/bitcoin/blob/dependencies/doc/dependencies.md ACKs for top commit: fanquake: ACK abcb8769bf1d8ed227e6abddd7250a613e91277d - I didn't click on or test all of the links, but this looks ok. Tree-SHA512: e91deb639afebeb37f7bf05dddad8f70547b51688e938a30692e59dbd7c9e49d52b7f9bfacb74ef60c98862b6f8f444199d0ae06973c42dc647314bc1ffc22d5
2022-04-20doc: add reference to `getrawmempool` RPC in `/mempool/contents` REST docbrunoerg
2022-04-20 doc: add more info to dependencies.mdPavol Rusnak
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.
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-05 08:36:56 +0000