aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2023-02-15Merge bitcoin-core/gui#711: refactor: Disable unused special members ↵Andrew Chow
functions in `UnlockContext` 9fa43b5af6b180f4b5f76726f443ee60259d2cd0 refactor: Disable unused special members functions in `UnlockContext` (Hennadii Stepanov) Pull request description: Also `UnlockContext::valid` and `UnlockContext::relock` are `const` now. ACKs for top commit: achow101: ACK 9fa43b5af6b180f4b5f76726f443ee60259d2cd0 john-moffett: ACK 9fa43b5af6b180f4b5f76726f443ee60259d2cd0 furszy: ACK 9fa43b5a Tree-SHA512: 6d9fa8208676b9bd5d85b73cb2d3136e7f28ef59e68ee34915ec598458868e302a80b9ef1384c0bf7a4c42f936830c3add9662ca0bae73860a55a25cc374b699
2023-02-15script: remove out-of-date snprintf TODOJon Atack
that was resolved in PR27036 "test: Remove last uses of snprintf and simplify" and while here, fix up 2 words in docs to make the spelling linter green again.
2023-02-15net: remove orphaned CSubNet::SanityCheck()Jon Atack
CSubNet::SanityCheck() was added in #20140, and not removed in #22570 when it became orphaned code.
2023-02-15refactor: remove <util/system.h> include from wallet.hfurszy
Since we no longer store a ref to the global `ArgsManager` inside the wallet, we can move the util/system.h include to the cpp. This dependency removal opened a can of worms, as few other places were, invalidly, depending on the wallet's header including it.
2023-02-15refactor: wallet, remove global 'ArgsManager' accessfurszy
we are not using it anymore
2023-02-15wallet: set '-walletnotify' script instead of access global args managerfurszy
2023-02-15wallet: set keypool_size instead of access global args managerfurszy
2023-02-15Merge bitcoin/bitcoin#26844: Net: Pass `MSG_MORE` flag when sending ↵fanquake
non-final network messages (round 2) 691eaf8873fe2f189153ca637506a0291504c97a Pass MSG_MORE flag when sending non-final network messages (Matt Whitlock) Pull request description: **N.B.:** This is my second attempt at introducing this optimization. #12519 (2018) was closed in deference to switching to doing gathering socket writes using `sendmsg(2)`, which I agree would have superior performance due to fewer syscalls, but that work was apparently abandoned in late 2018. Ever since, Bitcoin Core has continued writing tons of runt packets to the wire. Can we proceed with my halfway solution for now? ---- Since Nagle's algorithm is disabled, each and every call to `send(2)` can potentially generate a separate TCP segment on the wire. This is especially inefficient when sending the tiny header preceding each message payload. Linux implements a `MSG_MORE` flag that tells the kernel not to push the passed data immediately to the connected peer but rather to collect it in the socket's internal transmit buffer where it can be combined with data from successive calls to `send(2)`. Where available, specify this flag when calling `send(2)` in `CConnman::SocketSendData(CNode &)` if the data buffer being sent is not the last one in `node.vSendMsg`. ACKs for top commit: sipa: ACK 691eaf8873fe2f189153ca637506a0291504c97a vasild: ACK 691eaf8873fe2f189153ca637506a0291504c97a Tree-SHA512: 9a7f46bc12edbf78d488f05d1c46760110a24c95af74b627d2604fcd198fa3f511c5956bac36d0034e88c632d432f7d394147e667a11b027af0a30f70a546d70
2023-02-15wallet: reuse change dest when recreating TX with avoidpartialspendsMatthew Zipkin
2023-02-15Merge bitcoin/bitcoin#26153: Reduce wasted pseudorandom bytes in ChaCha20 + ↵fanquake
various improvements 511aa4f1c7508f15cab8d7e58007900ad6fd3d5d Add unit test for ChaCha20's new caching (Pieter Wuille) fb243d25f754da8f01793b41e2d225b917f3e5d7 Improve test vectors for ChaCha20 (Pieter Wuille) 93aee8bbdad808b7009279b67470d496cc26b936 Inline ChaCha20 32-byte specific constants (Pieter Wuille) 62ec713961ade7b58e90c905395558a41e8a59f0 Only support 32-byte keys in ChaCha20{,Aligned} (Pieter Wuille) f21994a02e1cc46d41995581b54222abc655be93 Use ChaCha20Aligned in MuHash3072 code (Pieter Wuille) 5d16f757639e2cc6e81db6e07bc1d5dd74abca6c Use ChaCha20 caching in FastRandomContext (Pieter Wuille) 38eaece67b1bc37b2f502348c5d7537480a34346 Add fuzz test for testing that ChaCha20 works as a stream (Pieter Wuille) 5f05b27841af0bed1b6e7de5f46ffe33e5919e4d Add xoroshiro128++ PRNG (Martin Leitner-Ankerl) 12ff72476ac0dbf8add736ad3fb5fad2eeab156c Make unrestricted ChaCha20 cipher not waste keystream bytes (Pieter Wuille) 6babf402130a8f3ef3058594750aeaa50b8f5044 Rename ChaCha20::Seek -> Seek64 to clarify multiple of 64 (Pieter Wuille) e37bcaa0a6dbb334ab6e817efcb609ccee6edc39 Split ChaCha20 into aligned/unaligned variants (Pieter Wuille) Pull request description: This is an alternative to #25354 (by my benchmarking, somewhat faster), subsumes #25712, and adds additional test vectors. It separates the multiple-of-64-bytes-only "core" logic (which becomes simpler) from a layer around which performs caching/slicing to support arbitrary byte amounts. Both have their uses (in particular, the MuHash3072 code can benefit from multiple-of-64-bytes assumptions), plus the separation results in more readable code. Also, since FastRandomContext effectively had its own (more naive) caching on top of ChaCha20, that can be dropped in favor of ChaCha20's new built-in caching. I thought about rebasing #25712 on top of this, but the changes before are fairly extensive, so redid it instead. ACKs for top commit: ajtowns: ut reACK 511aa4f1c7508f15cab8d7e58007900ad6fd3d5d dhruv: tACK crACK 511aa4f1c7 Tree-SHA512: 3aa80971322a93e780c75a8d35bd39da3a9ea570fbae4491eaf0c45242f5f670a24a592c50ad870d5fd09b9f88ec06e274e8aa3cefd9561d623c63f7198cf2c7
2023-02-15Merge bitcoin-core/gui#603: Add settings.json prune-prev, proxy-prev, ↵Hennadii Stepanov
onion-prev settings 9d3127b11e34131409dab7c08bde5b444d90b2cb Add settings.json prune-prev, proxy-prev, onion-prev settings (Ryan Ofsky) Pull request description: With #602, if proxy and pruning settings are disabled in the GUI and the GUI is restarted, proxy and prune values are not stored anywhere. So if these settings are enabled in the future, default values will be shown, not previous values. This PR stores previous values so they will preserved across restarts. I'm not sure I like this behavior because showing default values seems simpler and safer to me. Previous values may just have been set temporarily and may have never actually worked, and it adds some code complexity to store them. This PR is one way of resolving #596. Other solutions are possible and could be implemented as alternatives. ACKs for top commit: hebasto: ACK 9d3127b11e34131409dab7c08bde5b444d90b2cb, tested on Ubuntu 22.04. vasild: ACK 9d3127b11e34131409dab7c08bde5b444d90b2cb jarolrod: tACK 9d3127b11e34131409dab7c08bde5b444d90b2cb Tree-SHA512: 1778d1819443490c880cfd5c1711d9c5ac75ea3ee8440e2f0ced81d293247163a78ae8aba6027215110aec6533bd7dc6472aeead6796bfbd51bf2354e28f24a9
2023-02-15Merge bitcoin/bitcoin#26584: cli: include local ("unroutable") peers in ↵merge-script
-netinfo table 77192c959816dc8daee138d88bd6f3250ce3bdb6 cli: include local ("unreachable") peers in -netinfo table (Matthew Zipkin) Pull request description: Closes https://github.com/bitcoin/bitcoin/issues/26579 The `-netinfo` dashboard did not list peers that were connected via "unroutable" networks. This included local peers including local-network peers. Personally, I run one bitcoind instance on my network that is used by other services like Wasabi Wallet and LND running on other machines. This PR adds an "npr" (not publicly routable) column to the table of networks (ipv4, ipv6, onion, etc) so that every connection to the node is listed, and the totals are accurate as they relate to max inbound and max outbound limits. Example connecting in regtest mode to one local and one remote peer: ``` Bitcoin Core client v24.99.0-151ce099ea8f-dirty regtest - server 70016/Satoshi:24.99.0/ <-> type net mping ping send recv txn blk hb addrp addrl age id address version in npr 0 0 90 90 1 1 127.0.0.1:59180 70016/Satoshi:24.99.0/ out manual ipv4 63 63 84 84 3 3 0 143.244.175.41 70016/Satoshi:24.0.1/ ms ms sec sec min min min ipv4 ipv6 npr total block manual in 0 0 1 1 out 1 0 0 1 0 1 total 1 0 1 2 Local addresses: n/a ``` ACKs for top commit: jonatack: Re-tested ACK 77192c959816dc8daee138d88bd6f3250ce3bdb6 Tree-SHA512: 78aa68bcff0dbaadb5f0604bf023fe8fd921313bd8276d12581f7655c089466a48765f9e123cb31d7f1d294d5ca45fdefdf8aa220466ff738f32414f41099c06
2023-02-14wallet: ensure that the passphrase is not deleted from memory when being ↵ishaanam
used to rescan `m_relock_mutex` is introduced so that the passphrase is not deleted from memory when the timeout provided in `walletpassphrase` is up, but the wallet is still rescanning.
2023-02-14wallet: keep track of when the passphrase is needed when rescanningishaanam
Wallet passphrases are needed to top up the keypool during a rescan. The following RPCs need the passphrase when rescanning: - `importdescriptors` - `rescanblockchain` The following RPCs use the information about whether or not the passphrase is being used to ensure that full rescans are able to take place: - `walletlock` - `encryptwallet` - `walletpassphrasechange`
2023-02-14refactor: Disable unused special members functions in `UnlockContext`Hennadii Stepanov
2023-02-14descriptors: fix docstring (param [in] vs [out])SomberNight
As in title, these docstrings look incorrect.
2023-02-13Merge bitcoin/bitcoin#27080: Wallet: Zero out wallet master key upon locking ↵Andrew Chow
so it doesn't persist in memory 3a11adc7004d21b3dfe028b190d83add31691c55 Zero out wallet master key upon lock (John Moffett) Pull request description: When an encrypted wallet is locked (for instance via the RPC `walletlock`), the documentation indicates that the key is removed from memory: https://github.com/bitcoin/bitcoin/blob/b92d609fb25637ccda000e182da854d4b762eee9/src/wallet/rpc/encrypt.cpp#L157-L158 However, the vector (a `std::vector<unsigned char, secure_allocator<unsigned char>>`) is merely _cleared_. As it is a member variable, it also stays in scope as long as the wallet is loaded, preventing the secure allocator from deallocating. This allows the key to persist indefinitely in memory. I confirmed this behavior on my macOS machine by using an open-source third party memory inspector ("Bit Slicer"). I was able to find my wallet's master key in Bit Slicer after unlocking and re-locking my encrypted wallet. I then confirmed the key data was at the address in LLDB. This PR manually fills the bytes with zeroes before calling `clear()` by using our `memory_cleanse` function, which is designed to prevent the compiler from optimizing it away. I confirmed that it does remove the data from memory on my machine upon locking. Note: An alternative approach could be to call `vMasterKey.shrink_to_fit()` after the `clear()`, which would trigger the secure allocator's deallocation. However, `shrink_to_fit()` is not _guaranteed_ to actually change the vector's capacity, so I think it's unwise to rely on it. ## Edit: A little more clarity on why this is an improvement. Since `mlock`ed memory is guaranteed not to be swapped to disk and our threat model doesn't consider a super-user monitoring the memory in realtime, why is this an improvement? Most importantly, consider hibernation. Even `mlock`ed memory may get written to disk. From the `mlock` [manpage](https://man7.org/linux/man-pages/man2/mlock.2.html): > (But be aware that the suspend mode on laptops and some desktop computers will save a copy of the system's RAM to disk, regardless of memory locks.) As far as I can tell, this is true of [Windows](https://web.archive.org/web/20190127110059/https://blogs.msdn.microsoft.com/oldnewthing/20140207-00/?p=1833#:~:text=%5BThere%20does%20not%20appear%20to%20be%20any%20guarantee%20that%20the%20memory%20won%27t%20be%20written%20to%20disk%20while%20locked.%20As%20you%20noted%2C%20the%20machine%20may%20be%20hibernated%2C%20or%20it%20may%20be%20running%20in%20a%20VM%20that%20gets%20snapshotted.%20%2DRaymond%5D) and macOS as well. Therefore, a user with a strong OS password and a strong wallet passphrase could still have their keys stolen if a thief takes their (hibernated) machine and reads the permanent storage. ACKs for top commit: S3RK: Code review ACK 3a11adc7004d21b3dfe028b190d83add31691c55 achow101: ACK 3a11adc7004d21b3dfe028b190d83add31691c55 Tree-SHA512: c4e3dab452ad051da74855a13aa711892c9b34c43cc43a45a3b1688ab044e75d715b42843c229219761913b4861abccbcc8d5cb6ac54957d74f6e357f04e8730
2023-02-13Merge bitcoin/bitcoin#27016: mapport: require miniupnpc API version 17 or laterfanquake
b3b673f7048cce1d1368819abb0b58b7c6699fa5 mapport: require miniupnpc API version 17 or later (fanquake) Pull request description: Version 17 is currently the latest version, see: https://github.com/miniupnp/miniupnp/blob/master/miniupnpc/apiversions.txt, and has been available since the release of 2.1. 2.1 or newer is readily available across all distros, see https://repology.org/project/miniupnpc/versions, so drop support for the older API versions. Split out of #22644. ACKs for top commit: hebasto: ACK b3b673f7048cce1d1368819abb0b58b7c6699fa5, tested on Ubuntu 20.04 w/ and w/o [`libminiupnpc-dev`](https://packages.ubuntu.com/focal/libminiupnpc-dev) package. TheCharlatan: ACK b3b673f7048cce1d1368819abb0b58b7c6699fa5 Tree-SHA512: f53b36b82462c4ea83d9b83413dca8097885d1620f7ca0a53a79d6b3d3cf37c7773828b23f4278ccfcc3b14fcb0faffa35f60191b519b04570f3d2783d0303e2
2023-02-13psbt: support externally provided preimages for Miniscript satisfactionAntoine Poinsot
Co-Authored-By: Andrew Chow <github@achow101.com>
2023-02-13Merge bitcoin/bitcoin#27011: Add simulation-based `CCoinsViewCache` fuzzermerge-script
561848aaf2d67791e92754f3d11813bc53959a8f Exercise non-DIRTY spent coins in caches in fuzz test (Pieter Wuille) 59e6828bb5b56a2354a80059d3f660f551f3e207 Add deterministic mode to CCoinsViewCache (Pieter Wuille) b0ff31084006ac7d4a7afba3190ca75f5f8441af Add CCoinsViewCache::SanityCheck() and use it in fuzz test (Pieter Wuille) 3c9cea1340fd1358d6854209d782922864945eb0 Add simulation-based CCoinsViewCache fuzzer (Pieter Wuille) Pull request description: The fuzzer goes through a sequence of operations that get applied to both a real stack of `CCoinsViewCache` objects, and to simulation data, comparing the two at the end. ACKs for top commit: jamesob: re-ACK https://github.com/bitcoin/bitcoin/pull/27011/commits/561848aaf2d67791e92754f3d11813bc53959a8f dergoegge: Code review ACK 561848aaf2d67791e92754f3d11813bc53959a8f Tree-SHA512: 68634f251fdb39436b128ecba093f651bff12ac11508dc9885253e57fd21efd44edf3b22b0f821c228175ec507df7d46c7f9f5404fc1eb8187fdbd136a5d5ee2
2023-02-11qa: add a "smart" Miniscript fuzz targetAntoine Poinsot
At the expense of more complexity, this target generates a valid Miniscript node at every iteration. This target will at first run populate a list of recipe (a map from desired type to possible ways of creating such type) and curate it (remove the unavailable or redundant recipes). Then, at each iteration it will pick a type, choose a manner to create a node of such type from the available recipes, and then pseudo-recursively do the same for the type constraints of the picked recipe. For instance, if it is instructed based on the fuzzer output to create a Miniscript node of type 'Bd', it could choose to create an 'or_i(subA, subB)' nodes with type constraints 'B' for subA and 'Bd' for subB. It then consults the recipes for creating subA and subB, etc... Here is the list of all the existing recipes, by type constraint: B: 0() B: 1() B: older() B: after() B: sha256() B: hash256() B: ripemd160() B: hash160() B: c:(K) B: d:(Vz) B: j:(Bn) B: n:(B) B: and_v(V,B) B: and_b(B,W) B: or_b(Bd,Wd) B: or_d(Bdu,B) B: or_i(B,B) B: andor(Bdu,B,B) B: thresh(Bdu) B: thresh(Bdu,Wdu) B: thresh(Bdu,Wdu,Wdu) B: multi() V: v:(B) V: and_v(V,V) V: or_c(Bdu,V) V: or_i(V,V) V: andor(Bdu,V,V) K: pk_k() K: pk_h() K: and_v(V,K) K: or_i(K,K) K: andor(Bdu,K,K) W: a:(B) W: s:(Bo) Bz: 0() Bz: 1() Bz: older() Bz: after() Bz: n:(Bz) Bz: and_v(Vz,Bz) Bz: or_d(Bzdu,Bz) Bz: andor(Bzdu,Bz,Bz) Bz: thresh(Bzdu) Vz: v:(Bz) Vz: and_v(Vz,Vz) Vz: or_c(Bzdu,Vz) Vz: andor(Bzdu,Vz,Vz) Bo: sha256() Bo: hash256() Bo: ripemd160() Bo: hash160() Bo: c:(Ko) Bo: d:(Vz) Bo: j:(Bon) Bo: n:(Bo) Bo: and_v(Vz,Bo) Bo: and_v(Vo,Bz) Bo: or_d(Bodu,Bz) Bo: or_i(Bz,Bz) Bo: andor(Bzdu,Bo,Bo) Bo: andor(Bodu,Bz,Bz) Bo: thresh(Bodu) Vo: v:(Bo) Vo: and_v(Vz,Vo) Vo: and_v(Vo,Vz) Vo: or_c(Bodu,Vz) Vo: or_i(Vz,Vz) Vo: andor(Bzdu,Vo,Vo) Vo: andor(Bodu,Vz,Vz) Ko: pk_k() Ko: and_v(Vz,Ko) Ko: andor(Bzdu,Ko,Ko) Bn: sha256() Bn: hash256() Bn: ripemd160() Bn: hash160() Bn: c:(Kn) Bn: d:(Vz) Bn: j:(Bn) Bn: n:(Bn) Bn: and_v(Vz,Bn) Bn: and_v(Vn,B) Bn: and_b(Bn,W) Bn: multi() Vn: v:(Bn) Vn: and_v(Vz,Vn) Vn: and_v(Vn,V) Kn: pk_k() Kn: pk_h() Kn: and_v(Vz,Kn) Kn: and_v(Vn,K) Bon: sha256() Bon: hash256() Bon: ripemd160() Bon: hash160() Bon: c:(Kon) Bon: d:(Vz) Bon: j:(Bon) Bon: n:(Bon) Bon: and_v(Vz,Bon) Bon: and_v(Von,Bz) Von: v:(Bon) Von: and_v(Vz,Von) Von: and_v(Von,Vz) Kon: pk_k() Kon: and_v(Vz,Kon) Bd: 0() Bd: sha256() Bd: hash256() Bd: ripemd160() Bd: hash160() Bd: c:(Kd) Bd: d:(Vz) Bd: j:(Bn) Bd: n:(Bd) Bd: and_b(Bd,Wd) Bd: or_b(Bd,Wd) Bd: or_d(Bdu,Bd) Bd: or_i(B,Bd) Bd: or_i(Bd,B) Bd: andor(Bdu,B,Bd) Bd: thresh(Bdu) Bd: thresh(Bdu,Wdu) Bd: thresh(Bdu,Wdu,Wdu) Bd: multi() Kd: pk_k() Kd: pk_h() Kd: or_i(K,Kd) Kd: or_i(Kd,K) Kd: andor(Bdu,K,Kd) Wd: a:(Bd) Wd: s:(Bod) Bzd: 0() Bzd: n:(Bzd) Bzd: or_d(Bzdu,Bzd) Bzd: andor(Bzdu,Bz,Bzd) Bzd: thresh(Bzdu) Bod: sha256() Bod: hash256() Bod: ripemd160() Bod: hash160() Bod: c:(Kod) Bod: d:(Vz) Bod: j:(Bon) Bod: n:(Bod) Bod: or_d(Bodu,Bzd) Bod: or_i(Bz,Bzd) Bod: or_i(Bzd,Bz) Bod: andor(Bzdu,Bo,Bod) Bod: andor(Bodu,Bz,Bzd) Bod: thresh(Bodu) Kod: pk_k() Kod: andor(Bzdu,Ko,Kod) Bu: 0() Bu: 1() Bu: sha256() Bu: hash256() Bu: ripemd160() Bu: hash160() Bu: c:(K) Bu: d:(Vz) Bu: j:(Bnu) Bu: n:(B) Bu: and_v(V,Bu) Bu: and_b(B,W) Bu: or_b(Bd,Wd) Bu: or_d(Bdu,Bu) Bu: or_i(Bu,Bu) Bu: andor(Bdu,Bu,Bu) Bu: thresh(Bdu) Bu: thresh(Bdu,Wdu) Bu: thresh(Bdu,Wdu,Wdu) Bu: multi() Bzu: 0() Bzu: 1() Bzu: n:(Bz) Bzu: and_v(Vz,Bzu) Bzu: or_d(Bzdu,Bzu) Bzu: andor(Bzdu,Bzu,Bzu) Bzu: thresh(Bzdu) Bou: sha256() Bou: hash256() Bou: ripemd160() Bou: hash160() Bou: c:(Ko) Bou: d:(Vz) Bou: j:(Bonu) Bou: n:(Bo) Bou: and_v(Vz,Bou) Bou: and_v(Vo,Bzu) Bou: or_d(Bodu,Bzu) Bou: or_i(Bzu,Bzu) Bou: andor(Bzdu,Bou,Bou) Bou: andor(Bodu,Bzu,Bzu) Bou: thresh(Bodu) Bnu: sha256() Bnu: hash256() Bnu: ripemd160() Bnu: hash160() Bnu: c:(Kn) Bnu: d:(Vz) Bnu: j:(Bnu) Bnu: n:(Bn) Bnu: and_v(Vz,Bnu) Bnu: and_v(Vn,Bu) Bnu: and_b(Bn,W) Bnu: multi() Bonu: sha256() Bonu: hash256() Bonu: ripemd160() Bonu: hash160() Bonu: c:(Kon) Bonu: d:(Vz) Bonu: j:(Bonu) Bonu: n:(Bon) Bonu: and_v(Vz,Bonu) Bonu: and_v(Von,Bzu) Bdu: 0() Bdu: sha256() Bdu: hash256() Bdu: ripemd160() Bdu: hash160() Bdu: c:(Kd) Bdu: d:(Vz) Bdu: j:(Bnu) Bdu: n:(Bd) Bdu: and_b(Bd,Wd) Bdu: or_b(Bd,Wd) Bdu: or_d(Bdu,Bdu) Bdu: or_i(Bu,Bdu) Bdu: or_i(Bdu,Bu) Bdu: andor(Bdu,Bu,Bdu) Bdu: thresh(Bdu) Bdu: thresh(Bdu,Wdu) Bdu: thresh(Bdu,Wdu,Wdu) Bdu: multi() Wdu: a:(Bdu) Wdu: s:(Bodu) Bzdu: 0() Bzdu: n:(Bzd) Bzdu: or_d(Bzdu,Bzdu) Bzdu: andor(Bzdu,Bzu,Bzdu) Bzdu: thresh(Bzdu) Bodu: sha256() Bodu: hash256() Bodu: ripemd160() Bodu: hash160() Bodu: c:(Kod) Bodu: d:(Vz) Bodu: j:(Bonu) Bodu: n:(Bod) Bodu: or_d(Bodu,Bzdu) Bodu: or_i(Bzu,Bzdu) Bodu: or_i(Bzdu,Bzu) Bodu: andor(Bzdu,Bou,Bodu) Bodu: andor(Bodu,Bzu,Bzdu) Bodu: thresh(Bodu) Co-authored-by: Pieter Wuille <pieter.wuille@gmail.com>
2023-02-11qa: add a fuzz target generating random nodes from a binary encodingAntoine Poinsot
This is a "dumb" way of randomly generating a Miniscript node from fuzzer input. It defines a strict binary encoding and will always generate a node defined from the encoding without "helping" to create valid nodes. It will cut through as soon as it encounters an invalid fragment so hopefully the fuzzer can tend to learn the encoding and generate valid nodes with a higher probability. On a valid generated node a number of invariants are checked, especially around the satisfactions and testing them against the Script interpreter. The node generation and testing is modular in order to later introduce other ways to generate nodes from fuzzer inputs with minimal code. Co-Authored-By: Pieter Wuille <pieter@wuille.net>
2023-02-11wallet: check solvability using descriptor in AvailableCoinsAntoine Poinsot
This is a workaround for Miniscript descriptors containing hash challenges. For those we can't mock the signature creator without making OP_EQUAL mockable in the interpreter, so CalculateMaximumInputSize will always return -1 and outputs for these descriptors would appear unsolvable while they actually are.
2023-02-11script/sign: signing support for Miniscripts with hash preimage challengesAntoine Poinsot
Preimages must be externally provided (typically, via a PSBT).
2023-02-11script/sign: signing support for Miniscript with timelocksAntoine Poinsot
2023-02-11script/sign: basic signing support for Miniscript descriptorsAntoine Poinsot
Try to solve a script using the Miniscript satisfier if the legacy solver fails under P2WSH context. Only solve public key and public key hash challenges for now. We don't entirely replace the raw solver and especially rule out trying to solve CHECKMULTISIG-based multisigs with the Miniscript satisfier since some features, such as the transaction input combiner, rely on the specific behaviour of the former.
2023-02-11Align 'e' property of or_d and andor with website specPieter Wuille
2023-02-11Various additional explanations of the satisfaction logic from PieterPieter Wuille
Cherry-picked and squashed from https://github.com/sipa/bitcoin/commits/202302_miniscript_improve. - Explain thresh() and multi() satisfaction algorithms - Comment on and_v dissatisfaction - Mark overcomplete thresh() dissats as malleable and explain - Add comment on unnecessity of Malleable() in and_b dissat
2023-02-11miniscript: satisfaction supportAntoine Poinsot
This introduces the logic to "sign for" a Miniscript. Co-Authored-By: Pieter Wuille <pieter.wuille@gmail.com>
2023-02-10Zero out wallet master key upon lockJohn Moffett
When an encrypted wallet is locked (for instance via the RPC `walletlock`), the docs indicate that the key is removed from memory. However, the vector (with a secure allocator) is merely cleared. This allows the key to persist indefinitely in memory. Instead, manually fill the bytes with zeroes before clearing.
2023-02-10Merge bitcoin/bitcoin#27069: net: add `Ensure{any}Banman`merge-script
2d955ff006b8949017fe617c35cfc1cfe117db6e net: add `Ensure{any}Banman` (brunoerg) Pull request description: This PR adds `Ensure{any}Banman` functions to avoid code repetition and make it cleaner. Same approach as done with argsman, chainman, connman and others. ACKs for top commit: davidgumberg: ACK [2d955ff](https://github.com/bitcoin/bitcoin/commit/2d955ff006b8949017fe617c35cfc1cfe117db6e) Tree-SHA512: 0beb7125312168a3df130c1793a1412ab423ef0f46023bfe2a121630c79df7e55d3d143fcf053bd09e2d96e9385a7a04594635da3e5c6be0c5d3a9cafbe3b631
2023-02-10refactor, validation: Add ChainstateManagerOpts db optionsRyan Ofsky
Use ChainstateManagerOpts struct to remove ArgsManager uses from validation.cpp. This commit does not change behavior.
2023-02-10refactor, txdb: Use DBParams struct in CBlockTreeDBRyan Ofsky
Use DBParams struct to remove ArgsManager uses from txdb. To reduce size of this commit, this moves references to gArgs variable out of txdb.cpp to calling code in chainstate.cpp. But these moves are temporary. The gArgs references in chainstate.cpp are moved out to calling code in init.cpp in later commits. This commit does not change behavior.
2023-02-10refactor, txdb: Add CoinsViewOptions structRyan Ofsky
Add CoinsViewOptions struct to remove ArgsManager uses from txdb. To reduce size of this commit, this moves references to gArgs variable out of txdb.cpp to calling code in validation.cpp. But these moves are temporary. The gArgs references in validation.cpp are moved out to calling code in init.cpp in later commits. This commit does not change behavior.
2023-02-10refactor, dbwrapper: Add DBParams and DBOptions structsRyan Ofsky
Add DBParams and DBOptions structs to remove ArgsManager uses from dbwrapper. To reduce size of this commit, this moves references to gArgs variable out of dbwrapper.cpp to calling code in txdb.cpp. But these moves are temporary. The gArgs references in txdb.cpp are moved out to calling code in init.cpp in later commits. This commit does not change behavior.
2023-02-09De-duplicate add_coin methods to a test util helperJon Atack
2023-02-09Create InsecureRandMoneyAmount() test util helperJon Atack
to generate semi-random CAmounts up to MAX_MONEY rather than only uint32, and use it in the unit tests.
2023-02-09net: add `Ensure{any}Banman`brunoerg
it adds `Ensure{any}Banman` functions to avoid code repetition and make it cleaner. Similar approach as done with argsman, chainman, connman and others.
2023-02-09Merge bitcoin-core/gui#701: Persist Mask Values optionHennadii Stepanov
4de02def844102c08b65bf1311a333e7aca482b9 qt: Persist Mask Values option (Andrew Chow) Pull request description: The mask values option is memory only. If a user has enabled this option, it's reasonable to expect that they would want to have it enabled on the next start. ACKs for top commit: RandyMcMillan: tACK https://github.com/bitcoin-core/gui/commit/4de02def844102c08b65bf1311a333e7aca482b9 jarolrod: tACK 4de02def844102c08b65bf1311a333e7aca482b9 pablomartin4btc: > tACK [4de02de](https://github.com/bitcoin-core/gui/commit/4de02def844102c08b65bf1311a333e7aca482b9) john-moffett: tACK 4de02def844102c08b65bf1311a333e7aca482b9 Tree-SHA512: 247deb78df4911516625bf8b25d752feb480ce30eb31335cf9baeb07b7c6c225fcc37d5c45de62d6e6895ec10c7eefabb15527e3c9723a3b8ddda1e12ebbf46b
2023-02-07Merge bitcoin-core/gui#697: Remove reindex special case from the progress ↵MarcoFalke
bar label faff2ba4f80fad5af63a31559fd4065e631a8166 Remove reindex special case from the progress bar label (MarcoFalke) Pull request description: The user knows which option they passed to the program, so it seems overly verbose to offer the user feedback whether or not they passed `-reindex`. Treat it as `DISK`, like all other cases that are treated as `DISK`: * `-reindex-chainstate` * `-loadblock` ACKs for top commit: john-moffett: Re-ACK faff2ba4f80fad5af63a31559fd4065e631a8166 hebasto: ACK faff2ba4f80fad5af63a31559fd4065e631a8166, I have reviewed the code and it looks OK, I agree it can be merged. Tree-SHA512: 7f110c4beb1451d26f32da3a60150dac91c8a7b8d1c01749017204712b73cc1b77578af492930e4b6704097a73ed051f77bc39d8f60e0ff15a797a201805312e
2023-02-07Merge bitcoin/bitcoin#17127: util: Set safe permissions for data directory ↵fanquake
and `wallets/` subdir c9ba4f9ecb1a282d98e7456a84ca84362b161757 test: Add test for file system permissions (Hennadii Stepanov) 581f16ef3404274cb5c1a79dd3d6ee7b584f9844 Apply default umask in `SetupEnvironment()` (Hennadii Stepanov) 8a6219e54379911605aed860519e0194f1433b72 Remove `-sysperms` option (Hennadii Stepanov) Pull request description: On master (1e7564eca8a688f39c75540877ec3bdfdde766b1) docs say: ``` $ ./src/bitcoind -help | grep -A 3 sysperms -sysperms Create new files with system default permissions, instead of umask 077 (only effective with disabled wallet functionality) ``` Basing on that, one could expect that running `bitcoind` first time will create data directory and `wallets/` subdirectory with safe 0700 permissions. But that is not the case: ``` $ stat .bitcoin | grep id Access: (0775/drwxrwxr-x) Uid: ( 1000/ hebasto) Gid: ( 1000/ hebasto) $ stat .bitcoin/wallets | grep id Access: (0775/drwxrwxr-x) Uid: ( 1000/ hebasto) Gid: ( 1000/ hebasto) ``` Both directories, in fact, are created with system default permissions. With this PR: ``` $ stat .bitcoin/wallets | grep id Access: (0700/drwx------) Uid: ( 1000/ hebasto) Gid: ( 1000/ hebasto) $ stat .bitcoin/wallets | grep id Access: (0700/drwx------) Uid: ( 1000/ hebasto) Gid: ( 1000/ hebasto) ``` --- This PR: - is alternative to bitcoin/bitcoin#13389 - fixes bitcoin/bitcoin#15902 - fixes bitcoin/bitcoin#22595 - closes bitcoin/bitcoin#13371 - reverts bitcoin/bitcoin#4286 Changes in behavior: removed `-sysperms` command-line argument / configure option. The related discussions are here: - https://github.com/bitcoin/bitcoin/pull/13389#issuecomment-395306690 - https://github.com/bitcoin/bitcoin/pull/13389#issuecomment-539906114 - https://github.com/bitcoin/bitcoin/pull/13389#discussion_r279160472 If users rely on non-default access permissions, they could use `chmod`. ACKs for top commit: john-moffett: ACK c9ba4f9ecb1a282d98e7456a84ca84362b161757 willcl-ark: ACK c9ba4f9ecb1a282d98e7456a84ca84362b161757 Tree-SHA512: 96c745339e6bd0e4d7bf65daf9a721e2e1945b2b0ab74ca0f66576d0dc358b5de8eb8cdb89fe2160f3b19c39d2798bb8b291784316085dc73a27102d3415bd57
2023-02-07Remove reindex special case from the progress bar labelMarcoFalke
2023-02-06Move random test util code from setup_common to randomJon Atack
as many of the unit tests don't use this code
2023-02-06Merge bitcoin/bitcoin#26345: refactor: modernize the implementation of uint256.*Andrew Chow
935acdcc79d1dc5ac04a83b92e5919ddbfa29329 refactor: modernize the implementation of uint256.* (pasta) Pull request description: - Constructors of uint256 to utilize Span instead of requiring a std::vector - converts m_data into a std::array - Prefers using `WIDTH` instead of `sizeof(m_data)` - make all the things constexpr - replace C style functions with c++ equivalents - memset -> std::fill This may also be replaced by std::memset, but I think that std::fill is more idiomatic of modern c++ and readable. - memcpy -> std::copy Note: In practice, implementations of std::copy avoid multiple assignments and use bulk copy functions such as std::memmove if the value type is TriviallyCopyable and the iterator types satisfy LegacyContiguousIterator. (https://en.cppreference.com/w/cpp/algorithm/copy) This could also likely be replaced by std::memcpy, but as said above, I believe the using std::copy is the more c++ way to do anything and is almost guaranteed to compile to the same asm - memcmp -> std::memcmp ACKs for top commit: achow101: ACK 935acdcc79d1dc5ac04a83b92e5919ddbfa29329 hebasto: Approach ACK 935acdcc79d1dc5ac04a83b92e5919ddbfa29329. aureleoules: reACK 935acdcc79d1dc5ac04a83b92e5919ddbfa29329 john-moffett: ACK 935acdcc79d1dc5ac04a83b92e5919ddbfa29329 stickies-v: Approach ACK 935acdcc7 Tree-SHA512: 4f1ba54ff2198eea0e505d41e73d552c84c60f6878d5c85a94a8ab57f39afc94ef8d79258e7afd01fa84ec2a99f4404bb877eecd671f65e1ee9273f3129fc650
2023-02-06Apply default umask in `SetupEnvironment()`Hennadii Stepanov
This change makes all filesystem artifacts--files and directories--being created with the default umask.
2023-02-06Merge bitcoin/bitcoin#27036: test: Remove last uses of snprintf and simplifyMarcoFalke
b8032293e67a3b61ecad531412be5330f7cb39e3 Remove use of snprintf and simplify (John Moffett) Pull request description: These are the only remaining uses of `snprintf` in our project, and they can cause unexpected issues -- for example, see https://github.com/bitcoin/bitcoin/issues/27014. Change them to use our `ToString` (which uses a locale-independent version of `std::to_string`) to convert an `int` to `std::string`. Also remove resulting unused parts of `StringContentsSerializer`. Closes https://github.com/bitcoin/bitcoin/issues/27014 ACKs for top commit: Sjors: tACK b8032293e67a3b61ecad531412be5330f7cb39e3, fixes #27014. Tree-SHA512: c903977e654711929decafe8887d0de13b38a340d7082875acc5d41950d834dcfde074e9cabecaf5f9a760f62c34322297b4b156af29761650ef5803b1a54b59
2023-02-05Merge bitcoin/bitcoin#27030: Update nanobench to version v4.3.10fanquake
82f895d7b540ae421f80305a4f7cbb42905fb2c6 Update nanobench to version v4.3.10 (Martin Leitner-Ankerl) Pull request description: Nothing has changed that would affect Bitcoin's usage of nanobench. Here is a detailed list of the changes * Plenty of clang-tidy updates * documentation updates * faster Rng::shuffle * Enable perf counters on older kernels * Raise default minimum epoch time to 1ms (doesn't effect bitcoin's usage) * Add support for custom information per benchmark ACKs for top commit: hebasto: ACK 82f895d7b540ae421f80305a4f7cbb42905fb2c6, I've reviewed the code, all related changes from #26642 have been implemented. Tree-SHA512: 942518398809a2794617a347ab8182b784a8e822e84de5af078b2531eabb438412d687cac22a21936585e60e07138a89b41c28c9750744c05a3d1053f55cad01
2023-02-05Merge bitcoin/bitcoin#27009: validation: Skip VerifyDB checks of level >=3 ↵fanquake
if dbcache is too small fe683f352480245add0b27fe7efef5fef4c1e8c3 log: Log VerifyDB Progress over multiple lines (Martin Zumsande) 61431e3a57b5613d8715c93c6eae0058e0217eaa validation: Skip VerifyDB checks of level >=3 if dbcache is too small (Martin Zumsande) Pull request description: This is the first two commits from #25574, leaving out all changes to `-verifychain` error-handling : - The Problem of [25563](https://github.com/bitcoin/bitcoin/issues/25563) is that when we skip blocks at level 3 due to an insufficient dbcache (skipping some `DisconnectBlock()` calls), we would still attempt the level 4 checks, attempting to reconnect a block that was never disconnected, leading to an assert in `ConnectBlock()`. Fix this by not attempting level 4 checks in this case. - Logging of verification progress is now split over multiple lines. This is more verbose, but now each update has its own timestamp, and other threads logging concurrently will no longer lead to mangled output. This can be tested with a small `dbcache` value, for example: `bitcoind -signet -dbcache=10` `bitcoin-cli -signet verifychain 4 1000` Fixes #25563 ACKs for top commit: MarcoFalke: review ACK fe683f352480245add0b27fe7efef5fef4c1e8c3 🗄 john-moffett: ACK fe683f352480245add0b27fe7efef5fef4c1e8c3 Tree-SHA512: 3e2e0f8b73cbc518a0fa17912c1956da437787aab95001c110b01048472e0dfe4783c44df22bd903d198069dd2f6b02bfdf74e0b934c7a776f144c2e86cb818a
2023-02-05Remove `-sysperms` optionHennadii Stepanov
This change effectively reverts commits from https://github.com/bitcoin/bitcoin/pull/4286. Users, who rely on non-default access permissions, should use `chmod` command.
2023-02-03Merge bitcoin/bitcoin#25966: test: Remove redundant testAndrew Chow
fb1c6c14c11ccd4833c1a24f77c507f098d369ad test: Remove redundant test (yancy) Pull request description: I can't think of any reason to keep this test case around labeled [fix me](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L242). The test was originally added [here](https://github.com/bitcoin/bitcoin/commit/4566ab75f277612425337bf7786c1d3a410d894a) however there was never an assertion about the coins that should be selected, only that a solution is found (which is a redundant solution to the test [above](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L222)). The comment was later added here to [fix](https://github.com/bitcoin/bitcoin/commit/384273260a6ccbcf79dade0830011f528e5a1581) it, however it's unclear what exactly it's testing. A test was later added [here](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L366) where if the [long term fee](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L357) is less than the current [fee](https://github.com/bitcoin/bitcoin/blob/master/src/wallet/test/coinselector_tests.cpp#L356), then select fewer UTXOs, which may have been the original intent. ACKs for top commit: S3RK: ACK fb1c6c14c11ccd4833c1a24f77c507f098d369ad Zero-1729: Concept ACK fb1c6c14c11ccd4833c1a24f77c507f098d369ad achow101: ACK fb1c6c14c11ccd4833c1a24f77c507f098d369ad Tree-SHA512: bce2cdae669c144ffaa130237a1643e3b6728e13d603cebf5d9493c4c7c68b3635868e4d93d210783c2ded2a871f185ca09a2053168c05b26a1e056ff6edf68f
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-09 20:29:32 +0000