.#28261
Closed
Doodoobrown23 wants to merge 128 commits intobitcoin:masterfrom
Closed
Conversation
ab4a32b doc: update version number in bips.md to v24.0 (fanquake) bd44c69 doc: Generate example bitcoin conf for 24.0rc1 (fanquake) 0637169 doc: Generate manual pages for 24.0rc1 (fanquake) 7869b16 build: Bump version to 24.0rc1 (fanquake) Pull request description: Bump the version to 24.0rc1 Generate the man pages. Generate the example bitcoin conf file. Update the version number in bips.md. ACKs for top commit: achow101: ACK ab4a32b Tree-SHA512: bb26216a4114b3c7e7a4b44abfee78a119b4b310b36bfac5124aa6cfc2d0a27ad30fa4b0d490fc214281973dde2c220e3c00e99b110ea5c6ccbe906f17ae3c89
…y help category faf5bb8 doc: Move -permitbaremultisig to the relay help category (MacroFake) Pull request description: Identical commit from bitcoin#26119 ACKs for top commit: glozow: ACK faf5bb8 jarolrod: ACK faf5bb8 Tree-SHA512: 42d3fd541703cbea7d2afff54dc7a42dac475c70c59ed124aba59cae6a87898040d964201e6cc6098e202f7b87bfa98513b3efd3c25d9fe52dc0ef55f3540bef
…bmitWalletTransactions fad6157 Fix nNextResend data race in ResubmitWalletTransactions (MacroFake) Pull request description: Identical commit id from bitcoin#26132 Top commit has no ACKs. Tree-SHA512: 9404e2e10ba059c412e282abbf9bef581cf5ddcac36cf05da1dff3927b5015e12469238c402c28308a774fdd969d1039e595d5e2caca0902977ae0a72746ff43
…onlynet but are unreachable 68209a7 rpc: make addpeeraddress work with cjdns addresses (Martin Zumsande) a8a9ed6 init: Abort if i2p/cjdns are chosen via -onlynet but unreachable (Martin Zumsande) Pull request description: Identical commit from bitcoin#25989 ACKs for top commit: fanquake: ACK 68209a7 Tree-SHA512: eec335df06b4c209cfe3473cb623828effd00c45a5dd605bb920edd265de1c789627482b005a51e89b8fc79cc4c5d26ff1fc306f2e4573897c5c7f083aa22861
fa4ba04 fuzz: Remove no-op call to get() (MacroFake) fa64228 fuzz: Avoid timeout in bitdeque fuzz target (MacroFake) Pull request description: Identical commit from bitcoin#26012 Not strictly required for 24.x, but I guess it can't hurt to avoid timeouts. Top commit has no ACKs. Tree-SHA512: 4d4bfb645e3513bf22cc9c64bdcbde2ad9e28b5a07ab07a02fbfa19df02147b371d2ca794ab3a095c22b66781832055e0de3af908aaead4c26ea12189e05cbe3
…ssage a60d9eb Bugfix: Wallet: Lock cs_wallet for SignMessage (Luke Dashjr) Pull request description: (Clean merge of bitcoin#26130 to 24.x branch) Top commit has no ACKs. Tree-SHA512: 821e19d222cc1eb9a6b957ec87d48cfb00b2c5b8182682ac57d9c76785b667ad9c71444e6bf0f53177c06d5fb39e72dbfc82d7debe4b1597699eefaf3001d08d
faeea28 test: Avoid race in disconnect_nodes helper (MacroFake) Pull request description: Backport of bitcoin#26138 ACKs for top commit: fanquake: ACK faeea28 Tree-SHA512: f967c38750220bd6c245db953055f8e6d5402b3a24081ca03795a8403c2ed4eab772b2e9c2d3b581c3bc55d191dd4e22711b5f97d39856d676f10799fc64a9c7
…rget to avoid OOM fa5752d fuzz: Limit outpoints.size in txorphan target to avoid OOM (MacroFake) Pull request description: Identical commit from bitcoin#26216 ACKs for top commit: fanquake: ACK fa5752d Tree-SHA512: fa9bd1defb71b6bc2c62a6cdec5958576cafa0b41cdfebe11d48dd13505eb4a5e0e1d2ce55c0ed561d2a872dab6bb10bd71d941899b3b0eb0b2c38e6b3691ed5
…checking target 2730ed2 test: Check external coin effective value is used in CoinSelection (Aurèle Oulès) 21f96f4 wallet: Use correct effective value when checking target (Aurèle Oulès) Pull request description: backport of bitcoin#26203 ACKs for top commit: jarolrod: ACK 2730ed2 Tree-SHA512: ce84ac8d47861f290a26d572512467e89ec6ac27973d954d76245b6c6fdea01e36f2e0bce41599abfe14d0014335ebd17b990177771803de39406097973186ca
c186034 qt: 24.0rc2 translations update (Hennadii Stepanov) Pull request description: This PR pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-core/bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool, and it is supposed to be merged just before `v24.0rc2` tagging. Top commit has no ACKs. Tree-SHA512: 4c31452dd36509b0c1f0f5f499b9a3add53409a592d70625c14d7e249de48e7fce65777c9a78882bd37dc345362f45fbae117aa80cec342e6352fc43ad9306c3
GitHub-Pull: bitcoin#26124 Rebased-From: d3d6a18
GitHub-Pull: bitcoin#26149 Rebased-From: 648f695
Follow-up to bitcoin#25717. The commit "Utilize anti-DoS headers download strategy" changed how this bool variable is computed, so that its value is now the opposite of what it should be. GitHub-Pull: bitcoin#26172 Rebased-From: bdcafb9
Our required Python version 3.6.12 does not support `capture_output` as a subprocess.run argument; this was added in python 3.7. We can emulate it by setting stdout and stderr to subprocess.PIPE Github-Pull: bitcoin#26212 Rebased-From: be59bd1
Since commit f08c9fb from PR bitcoin#21726, index `BlockUntilSyncedToCurrentChain` behavior has been less reliable, and there has also been a race condition in the `coinstatsindex_initial_sync` unit test. It seems better for `BlockUntilSyncedToCurrentChain` to actually wait for the last connected block to be fully processed, than to be able to return before prune locks are set, so this switches the order of `m_best_block_index = block;` and `UpdatePruneLock` statements in `SetBestBlockIndex` to make it more reliable. Also since commit f08c9fb, there has been a race condition in the `coinstatsindex_initial_sync` test. Before that commit, the atomic index best block pointer `m_best_block_index` was updated as the last step of `BaseIndex::BlockConnected`, so `BlockUntilSyncedToCurrentChain` could safely be used in tests to wait for the last `BlockConnected` notification to be finished before stopping and destroying the index. But after that commit, calling `BlockUntilSyncedToCurrentChain` is no longer sufficient, and there is a race between the test shutdown code which destroys the index object and the new code introduced in that commit calling `AllowPrune()` and `GetName()` on the index object. Reproducibility instructions for this are in bitcoin#25365 (comment) This commit fixes the `coinstatsindex_initial_sync` race condition, even though it will require an additional change to silence TSAN false positives, bitcoin#26188, after it is fixed. So this partially addresses but does not resolve the bug reporting TSAN errors bitcoin#25365. There is no known race condition outside of test code currently, because the bitcoind `Shutdown` function calls `FlushBackgroundCallbacks` not `BlockUntilSyncedToCurrentChain` to safely shut down. Co-authored-by: Vasil Dimov <vd@FreeBSD.org> Co-authored-by: MacroFake <falke.marco@gmail.com> Github-Pull: bitcoin#26215 Rebased-From: 8891949
ReacceptWalletTransactions is replaced by ResubmitWalletTransactions which already handles acquiring the necessary locks internally. Github-Pull: bitcoin#26205 Rebased-From: 01f3534
Moves the logic of whether or not transactions should actually be resent out of the function that's resending them. This reduces responsibilities of ResubmitWalletTransactions and allows carving out the updating of m_next_resend in a future commit. Github-Pull: bitcoin#26205 Rebased-From: 7fbde8a
We only want to relay our resubmitted transactions once every 12-36h. By separating the timer update logic out of ResubmitWalletTransactions and into MaybeResendWalletTxs we avoid non-relay calls (previously in the separate ReacceptWalletTransactions function) from resetting that timer. Github-Pull: bitcoin#26205 Rebased-From: 9245f45
Since m_next_resend is now only called from MaybeResendWalletTxs() we don't have any potential race conditions anymore, so the usage of std::atomic can be reverted. Github-Pull: bitcoin#26205 Rebased-From: b01682a
Github-Pull: bitcoin#25858 Rebased-From: 0652dc5
Merging should be checking that the current PSBTOutput doesn't have a taptree and the other one's is copied over. The original merging had this inverted and would remove m_tap_tree if the other did not have it. Github-Pull: bitcoin#25858 Rebased-From: 7df6e1b
Github-Pull: bitcoin#25858 Rebased-From: 22c051c
Instead of having an entire TaprootBuilder which may or may not be complete, and could potentially have future changes that interact oddly with taproot tree tuples, have m_tap_tree be just the tuples. When needed in other a TaprootBuilder for actual use, the tuples will be added to a a TaprootBuilder that, in the future, can take in whatever other data is needed as well. Github-Pull: bitcoin#25858 Rebased-From: 0577d42
Github-Pull: bitcoin#26761 Rebased-From: 730e14a
If a wallet has key birthdates that are more recent than the currrent chain tip, or a bestblock height higher than the current tip, we should not attempt to rescan as there is nothing to scan for. Github-Pull: bitcoin#26679 Rebased-From: 3784009
To be eligible for fee-bumping, a transaction must not have any of its outputs (eg - change) spent in other unconfirmed transactions in the wallet. However, this check should not apply to abandoned transactions. A new test case is added to cover this case. Github-Pull: bitcoin#26675 Rebased-From: f9ce0ea
This class is the counterpart to CHashVerifier, in that it writes data to an underlying source stream, while keeping a hash of the written data. Github-Pull: bitcoin#26909 Rebased-From: da6c7ae
The previous logic would call it once for serializing into the filestream, and then again for serializing into the hasher. If AddrMan was changed in between these calls by another thread, the resulting peers.dat would be corrupt with non-matching checksum and data. Fix this by using HashedSourceWriter, which writes the data to the underlying stream and keeps track of the hash in one go. Github-Pull: bitcoin#26909 Rebased-From: 5eabb61
Github-Pull: bitcoin#26924 Rebased-From: fadeb6b
Github-Pull: bitcoin#26944 Rebased-From: d81ca66
The way that the main overview page limits the number of transactions displayed (currently 5) is not an appropriate use of Qt. If it's run with a DEBUG build of Qt, it'll result in a segfault in certain relatively common situations. Instead of artificially limiting the rowCount() in the subclassed proxy filter, we hide/unhide the rows in the displaying QListView upon any changes in the sorted proxy filter. Github-Pull: bitcoin-core/gui/pull/704 Rebased-From: 08209c0
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. Github-Pull: bitcoin#27080 Rebased-From: 3a11adc
Github-Pull: bitcoin#27053 Rebased-From: 14b4921
In the case of `i2pacceptincoming=0` we use transient addresses (destinations) for ourselves for each outbound connection. It may happen that we * create the session (and thus our address/destination too) * fail to connect to the particular peer (e.g. if they are offline) * dispose the unused session. This puts unnecessary load on the I2P network because session creation is not cheap. Is exaggerated if `onlynet=i2p` is used in which case we will be trying to connect to I2P peers more often. To help with this, save the created but unused sessions and pick them later instead of creating new ones. Alleviates: bitcoin#26754 Github-Pull: bitcoin#26837 Rebased-From: b906b64
This will lower the load on the I2P network. Since we use one transient session for connecting to just one peer, a higher number of tunnels is unnecessary. This was suggested in: bitcoin#26754 (comment) bitcoin#26754 (comment) The options are documented in: https://geti2p.net/en/docs/protocol/i2cp#options A tunnel is unidirectional, so even if we make a single outbound connection we still need an inbound tunnel to receive the messages sent to us over that connection. Alleviates: bitcoin#26754 Github-Pull: bitcoin#26837 Rebased-From: 801b405
The default number of tunnels in the Java implementation is 2 and in the C++ i2pd it is 5. Pick a mid-number (3) and explicitly set it in order to get a consistent behavior with both routers. Do this for persistent sessions which are created once at startup and can be used to open up to ~10 outbound connections and can accept up to ~125 incoming connections. Transient sessions already set number of tunnels to 1. Suggested in: bitcoin#26754 (comment) https://geti2p.net/en/docs/api/samv3 Alleviates: bitcoin#26754 Github-Pull: bitcoin#26837 Rebased-From: 3c1de03
An overload of MigrateLegacyToDescriptor is added which takes the wallet name. The original that took a wallet pointer is still available, it just gets the name, closes the wallet, and calls the new overload. Github-Pull: bitcoin#26595 Reabsed-From: dbfa345
Github-Pull: bitcoin#26595 Rebased-From: 6bdbc5f
Since migration reloads the wallet, the wallet will always be locked unless the passphrase is given. migratewallet can now take the passphrase in order to unlock the wallet for migration. Github-Pull: bitcoin#26595 Rebased-From: 7fd125b
Github-Pull: bitcoin#26595 Rebased-From: aaf02b5
Github-Pull: bitcoin#26595 Rebased-From: 9486509
784a754 wallet, rpc: Update migratewallet help text for encrypted wallets (Andrew Chow) debcfe3 tests: Tests for migrating wallets by name, and providing passphrase (Andrew Chow) ccc72fe wallet: Be able to unlock the wallet for migration (Andrew Chow) 50dd8b1 rpc: Allow users to specify wallet name for migratewallet (Andrew Chow) 648b062 wallet: Allow MigrateLegacyToDescriptor to take a wallet name (Andrew Chow) ab3bd45 i2p: use consistent number of tunnels with i2pd and Java I2P (Vasil Dimov) 29cdf42 i2p: lower the number of tunnels for transient sessions (Vasil Dimov) 5027e93 i2p: reuse created I2P sessions if not used (Vasil Dimov) a62c541 wallet: reuse change dest when recreating TX with avoidpartialspends (Matthew Zipkin) 64e7db6 Zero out wallet master key upon lock (John Moffett) b7e242e Correctly limit overview transaction list (John Moffett) cff6718 depends: fix systemtap download URL (fanquake) 7cf73df Add missing includes to fix gcc-13 compile error (MarcoFalke) 07397cd addrdb: Only call Serialize() once (Martin Zumsande) 91f83db hash: add HashedSourceWriter (Martin Zumsande) 5c824ac For feebump, ignore abandoned descendant spends (John Moffett) 428dcd5 wallet: Skip rescanning if wallet is more recent than tip (Andrew Chow) cbcdafa test: wallet: check that labels are migrated to watchonly wallet (Sebastian Falbesoner) 342abfb wallet: fully migrate address book entries for watchonly/solvable wallets (Sebastian Falbesoner) Pull request description: Backports: * bitcoin#26595 * bitcoin#26675 * bitcoin#26679 * bitcoin#26761 * bitcoin#26837 * bitcoin#26909 * bitcoin#26924 * bitcoin#26944 * bitcoin-core/gui#704 * bitcoin#27053 * bitcoin#27080 ACKs for top commit: instagibbs: ACK bitcoin@784a754 achow101: ACK 784a754 hebasto: ACK 784a754, I've made backporting locally and got a diff between my branch and this PR as follows: Tree-SHA512: 8ea84aa02d7907ff1e202e1302b441ce9ed2198bf383620ad40056a5d7e8ea88e1047abef0b92d85648016bf9b3195c974be3806ccebd85bef4f85c326869e43
Move historical 24.0.1 to doc/release-notes.
a2f8a83 qt: 24.1rc1 translations update (Hennadii Stepanov) Pull request description: This PR pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool. According to our [Release Process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-release-candidate), it is supposed to be merged before `v24.1rc1` tagging (bitcoin#27247). Will keep this PR updated regularly until merging. The Dutch translation `bitcoin_nl.ts` has been damaged, therefore its changes were rejected manually. ACKs for top commit: stickies-v: I'm not familiar with the translations process and I couldn't verify that `bitcoin_nl.ts` is damaged, but if this constitutes sufficient review then ACK a2f8a83 Tree-SHA512: d914d158c4a4b62a2c37040f5cc0602ef749a7bf658af0e364a0d2cb52b802a00863496751cf3db42d74e8950c49969ee9dd03c5c3fee79860113389f36ee483
932a609 doc: add initial release notes for v24.1 (fanquake) cc4e315 doc: update manual pages for v24.1rc1 (fanquake) 787affb doc: update version in bips.md to v24.1 (fanquake) 5077e02 build: bump version to v24.1rc1 (fanquake) Pull request description: Bump the version number to v24.1rc1. Regenerate the man pages. Update the version number in bips.md. Move the v24.0.1 release notes to doc/release-notes. Add initial release notes for v24.1. Merged changes to the 24.x branch since v24.0.1: - bitcoin#26457 - bitcoin#26735 - bitcoin#26878 - bitcoin#26880 ACKs for top commit: achow101: ACK 932a609 Tree-SHA512: b90fd7c8f22c8fb096864e47cb79eaf5878524739a3b5c1d495c8c196b70d08c7b95fbfb1dfcdddf507bd8a72a5d133ecbe6ae898bbe70931f404afd0807b707
Contributor
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.