aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-09-25validation: Disable CheckForkWarningConditions for background chainstateMartin Zumsande
The comparison of m_best_invalid with the tip of the respective chainstate makes no sense for the background chainstate, and can lead to incorrect error messages. Github-Pull: bitcoin/bitcoin#30962 Rebased-From: c0a0c72b4d68a4f0c53c2c4b95f4d6e399f8e4ee
2024-09-24test: Use shell builtins in run_command test caseAva Chow
Github-Pull: bitcoin/bitcoin#30952 Rebased-From: 7bd3ee62f6d6f59ca599e85f81776d282dee1539
2024-09-16streams: remove AutoFile::Get() entirelyPieter Wuille
Co-Authored-By: David Gumberg <davidzgumberg@gmail.com> Github-Pull: bitcoin/bitcoin#30884 Rebased-From: a240e150e837b5a95ed19765a2e8b7c5b6013f35
2024-09-16streams: cache file position within AutoFilePieter Wuille
Github-Pull: bitcoin/bitcoin#30884 Rebased-From: e624a9bef16b6335fd119c10698352b59bf2930a
2024-09-16qt: Translations updateHennadii Stepanov
The recent translations from Transifex.com 28.x fetched with the bitcoin-maintainer-tools/update-translations.py tool. Github-Pull: bitcoin/bitcoin#30899 Rebased-From: ae0529576147a1a5bee992574e2cefc8a1fa37d0
2024-09-13gui: fix crash when closing walletfurszy
The crash occurs because 'WalletController::removeAndDeleteWallet' is called twice for the same wallet model: first in the GUI's button connected function 'WalletController::closeWallet', and then again when the backend emits the 'WalletModel::unload' signal. This causes the issue because 'removeAndDeleteWallet' inlines an erase(std::remove()). So, if 'std::remove' returns an iterator to the end (indicating the element wasn't found because it was already erased), the subsequent call to 'erase' leads to an undefined behavior. Github-Pull: bitcoin-core/gui#835 Rebased-From: a965f2bc07a3588f8c2b8d6a542961562e3f5d0e
2024-09-11assumeUTXO: fix peers disconnection during syncfurszy
Because AssumeUTXO nodes prioritize tip synchronization, they relay their local address through the network before completing the background chain sync. This, combined with the advertising of full-node service (NODE_NETWORK), can result in an honest peer in IBD connecting to the AssumeUTXO node (while syncing) and requesting an historical block the node does not have. This behavior leads to an abrupt disconnection due to perceived unresponsiveness (lack of response) from the AssumeUTXO node. This lack of response occurs because nodes ignore getdata requests when they do not have the block data available (further discussion can be found in PR 30385). Fix this by refraining from signaling full-node service support while the background chain is being synced. During this period, the node will only signal 'NODE_NETWORK_LIMITED' support. Then, full-node ('NODE_NETWORK') support will be re-enabled once the background chain sync is completed. Github-Pull: bitcoin/bitcoin#30807 Rebased-From: 6d5812e5c852c233bd7ead2ceef051f8567619ed
2024-09-06test: Work around boost compilation errorMarcoFalke
Github-Pull: bitcoin/bitcoin#30834 Rebased-From: fa9d7d5d205ada8915cbbc29599ab8e7bf1fffe0
2024-09-05test: fixing failing system_tests/run_command under some LocalesJadi
the run_command test under system_tests fails if the locale is anything other than English ones because results such as "No such file or directory" will be different under Non-English locales. On the old version, a `ls nonexistingfile` was used to generate the error output which is not ideal. In the current version we are using a Python one-liner to generate a non 0 zero return value and "err" on stderr and check the expected value against this. fixes #30608 Github-Pull: #30788 Rebased-From: ae48a22a3df086fb59843b7b814619ed5df7557b
2024-08-27Merge bitcoin/bitcoin#30695: seeds: Add additional seed source and bump ↵Ava Chow
uptime requirements for Onion and I2P nodes b061b3510585a1fe113cc9d1af65852b155aba45 seeds: Regenerate mainnet seeds (virtu) 02dc45c506f78eae96b5fe8e8e4899b45811da05 seeds: Pull nodes from Luke's seeder (virtu) 7a2068a0ff9eec2bab436b47eba37fd34b71bba4 seeds: Pull nodes from virtu's crawler (virtu) Pull request description: This builds on #30008 and adds data [exported](https://github.com/virtu/seed-exporter) by [my crawler](https://github.com/virtu/p2p-crawler) an additional source for seed nodes. Data covers all supported network types. [edit: Added Luke's seeder as input as well.] ### Motivation - Further decentralizes the seed node selection process (in the long term potentially enabling an _n_-source threshold for nodes to prevent a single source from entering malicious nodes) - No longer need to manually curate seed node list for any network type: See last paragraph of OP in #30008. My crawler has been [discovering the handful of available cjdns nodes](https://21.ninja/reachable-nodes/nodes-by-net-type/) for around two months, all but one of which meet the reliability criteria. - Alignment of uptime requirements for Onion and I2P nodes with those of clearnet nodes to 50%: If I'm reading the code correctly, seeders appear to optimize for up-to-dateness by using [lower connection timeouts](https://github.com/achow101/dnsseedrs/blob/3c1a63c6723819871d76fe0fbd2155fe5a5bb171/src/crawl.rs#L349) than [Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/bc87ad98543299e1990ee1994d0653df3ac70093/src/netbase.cpp#L40C27-L40C48) to maximize throughput. Since my crawler does not have the same timeliness requirements, it opts for accuracy by using generous timeouts. As a result, its data contains additional eligible Onion (and other darknet nodes), as is shown in the histogram below. Around 4500 Onion nodes are discovered so far (blue); my data adds ~6400 more (orange); ~ 1500 nodes take longer than the default 20-second Bitcoin Core timeout and won't qualify as "good". ![Connection time histogram for Onion nodes](https://github.com/user-attachments/assets/c3513604-aa48-4c75-b51d-13421eaed9eb) Here's the current results with 512 nodes for all networks except cjdns: <details> <summary>Using the extra data</summary> ``` IPv4 IPv6 Onion I2P CJDNS Pass 10335 2531 11545 1589 10 Initial 10335 2531 11545 1589 10 Skip entries with invalid address 5639 1431 11163 1589 8 After removing duplicates 5606 1417 11163 1589 8 Enforce minimal number of blocks 5606 1417 11163 1589 8 Require service bit 1 4873 1228 11163 1589 8 Require minimum uptime 4846 1225 11161 1588 8 Require a known and recent user agent 4846 1225 11161 1588 8 Filter out hosts with multiple bitcoin ports 512 512 512 512 8 Look up ASNs and limit results per ASN and per net ``` </details> <details> <summary>Before</summary> ``` IPv4 IPv6 Onion I2P CJDNS Pass 5772 1323 443 0 2 Initial 5772 1323 443 0 2 Skip entries with invalid address 4758 1110 443 0 2 After removing duplicates 4723 1094 443 0 2 Enforce minimal number of blocks 4723 1094 443 0 2 Require service bit 1 3732 867 443 0 2 Require minimum uptime 3718 864 443 0 2 Require a known and recent user agent 3718 864 443 0 2 Filter out hosts with multiple bitcoin ports 512 409 443 0 2 Look up ASNs and limit results per ASN and per net ``` </details> ### To dos - [x] Remove manual nodes and update README - [x] Mark nodes with connection times exceeding Bitcoin Core's default as bad in [exporter](https://github.com/virtu/seed-exporter): [done](https://github.com/virtu/seed-exporter/pull/12) - [x] Regenerate mainnet seeds - [x] Rebase, then remove WIP label once #30008 gets merged ACKs for top commit: achow101: ACK b061b3510585a1fe113cc9d1af65852b155aba45 fjahr: utACK b061b3510585a1fe113cc9d1af65852b155aba45 Tree-SHA512: 63e86220787251c7e8d2d5957bad69352e19ae17d7b9b2d27d8acddfec5bdafe588edb68d77d19c57f25f149de723e2eeadded0c8cf13eaca22dc33bd8cf92a0
2024-08-27Merge bitcoin/bitcoin#30697: Bugfix: Ensure Atomicity in Wallet Settings ↵Ava Chow
Updates from Chain Interface 1b41d45d462d856a9d0b44ae0039bbb2cd78407c wallet: bugfix: ensure atomicity in settings updates (ismaelsadeeq) Pull request description: This PR fixes #30620. As outlined in the issue, creating two wallets with `load_on_startup=true` simultaneously results in only one wallet being added to the startup file. The current issue arises because the wallet settings update process involves: 1. Obtaining the settings value while acquiring the settings lock. 2. Modifying the settings value. 3. Overwriting the settings value while acquiring the settings lock again. This sequence is not thread-safe. Different threads could modify the same base value simultaneously, overwriting data from other workers without realizing it. The PR attempts to fix this by modifying the chain interface's `updateRwSetting` method to accept a function that will be called with the settings reference. This function will either update or delete the setting and return an enum indicating whether the settings need to be overwritten in this or not. Additionally, this PR introduces two new methods to the chain interface: - `overwriteRwSetting`: This method replaces the setting with a new value. Used in `VerifyWallets` - `deleteRwSettings`: This method completely erases a specified setting. This method is currently used only in `overwriteRwSetting`. These changes ensure that updates are race-free across all clients. ACKs for top commit: achow101: ACK 1b41d45d462d856a9d0b44ae0039bbb2cd78407c furszy: self-code-ACK https://github.com/bitcoin/bitcoin/commit/1b41d45d462d856a9d0b44ae0039bbb2cd78407c Tree-SHA512: 50cda612b782aeb5e03e2cf63cc44779a013de1c535b883b57af4de22f24b0de80b4edecbcda235413baec0a12bdf0e5750fb6731c9e67d32e742d8c63f08c13
2024-08-27Merge bitcoin/bitcoin#30720: chainparams: Remove seed.bitcoinstats.commerge-script
c88a7dc53e3be7489605c3326cf768df5437393a chainparams: Remove seed.bitcoinstats.com (Ava Chow) Pull request description: This seeder no longer appears to be serving sufficient addresses. Fixes #29911 ACKs for top commit: 1440000bytes: ACK https://github.com/bitcoin/bitcoin/pull/30720/commits/c88a7dc53e3be7489605c3326cf768df5437393a virtu: ACK https://github.com/bitcoin/bitcoin/commit/c88a7dc53e3be7489605c3326cf768df5437393a mzumsande: ACK c88a7dc53e3be7489605c3326cf768df5437393a BrandonOdiwuor: ACK c88a7dc53e3be7489605c3326cf768df5437393a Tree-SHA512: 23db3a217bbc3cd96785f17bd2b1db886392cc864dfc00498fa30e69df414ad02cb35f34cd6b7e8adab7c024a7efa8fd4a39b8b8ef274d95974cb16eb1c39a5b
2024-08-27seeds: Regenerate mainnet seedsvirtu
Regenerate mainnet seeds from new sources without the need for hardcoded data. Result has 512 nodes from each network type except cjdns, for which only eight nodes were found that match the seed node criteria.
2024-08-26Merge bitcoin/bitcoin#30008: seeds: Pull additional nodes from my seeder and ↵Ava Chow
update fixed seeds 41ad84a00c20f54b520aab7f6f975231da0ee2d0 seeds: Use fjahr's more up to date asmap (Ava Chow) d8fd1e0fafa144a9ff96fc646cf9f21e220d5cd6 seeds: Fixed seeds update (Ava Chow) f1f24d72141dcd2955420195135cabe5092017ff seeds: Add testnet4 fixed seeds file (Ava Chow) 8ace71c73750e3b537784178f3fc299447c461ed seeds: Remove manual onion and i2p seeds (Ava Chow) ed5b86cbe47676276f8ff1a48001d5ecd560e153 seeds: Add testnet instructions (Ava Chow) 0676515397fcc8fb580973047e60279ce65bec48 seeds: Also pull from achow101 seeder (Ava Chow) 5bab3175a663610070c1000dd4211a58490e5023 makeseeds: Configurable minimum blocks for testnet4's smaller chain (Ava Chow) d2465dfac68f96ffdaad88a0bd4891ed37cbfdfc makeseeds: Shuffle ips after parsing (Ava Chow) af550b3a0fd406f175f197ea9867b41ff4e97af4 makeseeds: Support CJDNS (Ava Chow) d5a8c4c4bd76f296f4d744184dc80a6a6a0731bd makeseeds: Update user agent regex (Ava Chow) Pull request description: The [DNS seeder](https://github.com/achow101/dnsseedrs) that I wrote collects statistics on node reliability in the same way that sipa's seeder does, and also outputs this information in the same file format. Thus it can also be used in our fixed seeds update scripts. My seeder additionally crawls onion v3, i2p, and cjdns, so will now be able to set those fixed seeds automatically rather than curating manual lists. In doing this update, I've found that `makeseeds.py` is missing newer versions from the regex as well as cjdns support; both of these have been updated. I also noticed that the testnet fixed seeds are all manually curated and sipa's seeder does not appear to publish any testnet data. Since I am also running the seeder for testnet, I've added the commands to generate testnet fixed seeds from my seeder's data too. Lastly, I've updated all of the fixed seeds. However, since my seeder has not found any cjdns nodes that met the reliability criteria (possibly due to connectivity issues present in those networks), I've left the previous manual seeds for that network. ACKs for top commit: fjahr: re-ACK 41ad84a00c20f54b520aab7f6f975231da0ee2d0 virtu: ACK [41ad84a](https://github.com/bitcoin/bitcoin/commit/41ad84a00c20f54b520aab7f6f975231da0ee2d0) Tree-SHA512: 6ba0141f053d9d6ae7d8c9574f061be38f3e65b28de1d6660c1885ab942623b5a0ec70754b4fcfc5d98fe970f5f179a940d5880b5061ed698f7932500e01d3ee
2024-08-26chainparams: Remove seed.bitcoinstats.comAva Chow
This seeder no longer appears to be serving sufficient addresses.
2024-08-26wallet: bugfix: ensure atomicity in settings updatesismaelsadeeq
- Settings updates were not thread-safe, as they were executed in three separate steps: 1) Obtain settings value while acquiring the settings lock. 2) Modify settings value. 3) Overwrite settings value while acquiring the settings lock. This approach allowed concurrent threads to modify the same base value simultaneously, leading to data loss. When this occurred, the final settings state would only reflect the changes from the last thread that completed the operation, overwriting updates from other threads. Fix this by making the settings update operation atomic. - Add test coverage for this behavior. Co-authored-by: furszy <matiasfurszyfer@protonmail.com>
2024-08-26qt: 28.0 translations updateHennadii Stepanov
2024-08-24Merge bitcoin/bitcoin#30651: fuzz: remove repeated word in notemerge-script
3f05a1068d10ffe0f2859cd20c5fc9bc8efa1c70 remove repeated word in note (sunerok) Pull request description: Fix typo. ACKs for top commit: maflcko: ACK 3f05a1068d10ffe0f2859cd20c5fc9bc8efa1c70 danielabrozzoni: ACK 3f05a1068d10ffe0f2859cd20c5fc9bc8efa1c70 Tree-SHA512: 709d96ed18608c0ea788b4f0696abad79ab1b81c4f266487d16bbe4cfca5b99b8f7f9a58f830866db9695aa3aebcc6442098b1533d85507729af99709a53d26a
2024-08-24Merge bitcoin/bitcoin#30687: test: replace deprecated secp256k1 context ↵merge-script
flags usage 60055f1abc4b4ad5f66a2fcf2e61c65efc777036 test: replace deprecated secp256k1 context flags usage (Sebastian Falbesoner) Pull request description: The flags `SECP256K1_CONTEXT_{SIGN,VERIFY}` have been marked as deprecated since libsecp256k1 version 0.2 (released in December 2022), with the recommendation to use SECP256K1_CONTEXT_NONE instead, see https://github.com/bitcoin-core/secp256k1/pull/1126 and https://github.com/bitcoin-core/secp256k1/blob/1988855079fa8161521b86515e77965120fdc734/CHANGELOG.md?plain=1#L132. Note that in contrast to other deprecated functions/variables, these defines don't have a deprecated attribute and hence don't lead to a compiler warning (see https://github.com/bitcoin-core/secp256k1/pull/1126#discussion_r922105271), so they are not easily detected. ACKs for top commit: TheCharlatan: ACK 60055f1abc4b4ad5f66a2fcf2e61c65efc777036 ismaelsadeeq: utACK 60055f1abc4b4ad5f66a2fcf2e61c65efc777036 tdb3: light CR and test ACK 60055f1abc4b4ad5f66a2fcf2e61c65efc777036 Tree-SHA512: d93cf49e018a58469620c0d2f50242141f22dabc70afb2a7cd64e416f4f55588714510ae5a877376dd1e6b6f7494261969489af4b18a1c9dff0d0dfdf93f1fa8
2024-08-22Merge bitcoin/bitcoin#30658: kernel: pre-28.x chainparams and headerssync updateglozow
221809b81cfcecb04050915eebacffda2599da42 headerssync: Update headerssync configuration (Ava Chow) c2707446f745015d279af663e181219757ad6eb7 params: Update assumevalid and minimum chainwork (Ava Chow) 255d4514d3cd9f545f1d3eca5bbda8d8c90ee351 params: Update chainTxData (Ava Chow) 6a5bdae3225117651708aa430e04b6da58387cf2 params: Update assumed blockchain and chainstate sizes (Ava Chow) Pull request description: Update chainparams and headerssync parameters for the pre-28.x branching, per https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-branch-off ACKs for top commit: fjahr: re-ACK 221809b81cfcecb04050915eebacffda2599da42 Sjors: re-ACK 221809b81cfcecb04050915eebacffda2599da42 glozow: ACK 221809b81cfcecb04050915eebacffda2599da42 marcofleon: ACK 221809b81cfcecb04050915eebacffda2599da42 Tree-SHA512: 5106d59f46dbe167fffa339519e52975ae5bfd7e52202d76ec058da0d4e8bf87355e90678f7ace7c8c402a2f7264050a0355680b9f727c7962ff60e8fcdb3a90
2024-08-22Merge bitcoin/bitcoin#30681: Have miner account for timewarp mitigation, ↵Ava Chow
activate on regtest, lower nPowTargetTimespan to 144 and add test 59ff17e5af4e382cbe16f183767beef1bdcd9131 miner: adjust clock to timewarp rule (Sjors Provoost) e929054e12210353812f440c685a23329e7040f7 Add timewarp attack mitigation test (Sjors Provoost) e85f386c4b157b7d1ac16aface9bd2c614e62b46 consensus: enable BIP94 on regtest (Sjors Provoost) dd154b05689c60fad45df0df6d31cec12e09ab21 consensus: lower regtest nPowTargetTimespan to 144 (Sjors Provoost) Pull request description: Because #30647 reduced the timewarp attack threshold from 7200s to 600s, our miner code will fail to propose a block template (on testnet4) if the last block of the previous period has a timestamp two hours in the future. This PR fixes that and also adds a test. The non-test changes in the last commit should be in v28, otherwise miners have to patch it themselves. If necessary I can split that out into a separate PR, but I prefer to get the tests in as well. In order to add the test, we activate BIP94 on regtest. In order for the test to run faster, we reduce its difficulty retarget period to 144, the same number that's already used for softfork activation logic. Regtest does not actually adjust its difficulty, so this change has no effect (except for `getnetworkhashps`, see commit). An alternative approach would be to run this test on testnet4, by hardcoding its first 2015 in the test suite. But since the timewarp mitigation is a serious candidate for a future mainnet softfork, it seems better to just deploy it on regtest. The next commits add a test and fix the miner code. The `MAX_TIMEWARP` constant is moved to `consensus.h` so both validation and miner code have access to it. ACKs for top commit: achow101: ACK 59ff17e5af4e382cbe16f183767beef1bdcd9131 fjahr: ACK 59ff17e5af4e382cbe16f183767beef1bdcd9131 glozow: ACK 59ff17e5af4e382cbe16f183767beef1bdcd9131 Tree-SHA512: 50af9fdcba9b0d5c57e1efd5feffd870bd11b5318f1f8b0aabf684657f2d33ab108d5f00b1475fe0d38e8e0badc97249ef8dda20c7f47fcc1698bc1008798830
2024-08-21Fix maybe-uninitialized warning in IsSpentKeyAva Chow
2024-08-20Merge bitcoin/bitcoin#30644: fuzz: Faster utxo_snapshot fuzz targetAva Chow
fa899fb7aa8a14acecadd8936ad5824fa0f697ff fuzz: Speed up utxo_snapshot fuzz target (MarcoFalke) fa386642b4dfd88f74488c288c7886494d69f4ed fuzz: Speed up utxo_snapshot by lazy re-init (MarcoFalke) fa645c7a861ffa83a53a459263b6a620defe31f9 fuzz: Remove unused DataStream object (MarcoFalke) fae8c73d9e4eba4603447bb52b6e3e760fbf15f8 test: Disallow fee_estimator construction in ChainTestingSetup (MarcoFalke) Pull request description: Two commits to speed up unit and fuzz tests. Can be tested by running the fuzz target and looking at the time it took, or by looking at the flamegraph. For example: ``` FUZZ=utxo_snapshot perf record -g --call-graph dwarf ./src/test/fuzz/fuzz -runs=100 hotspot ./perf.data ACKs for top commit: TheCharlatan: Re-ACK fa899fb7aa8a14acecadd8936ad5824fa0f697ff marcofleon: Re ACK fa899fb7aa8a14acecadd8936ad5824fa0f697ff brunoerg: ACK fa899fb7aa8a14acecadd8936ad5824fa0f697ff Tree-SHA512: d3a771bb12d7ef491eee61ca47325dd1cea5c20b6ad42554babf13ec98d03bef8e7786159d077e59cc7ab8112495037b0f6e55edae65b871c7cf1708687cf717
2024-08-21test: replace deprecated secp256k1 context flags usageSebastian Falbesoner
The flags SECP256K1_CONTEXT_{SIGN,VERIFY} have been deprecated since libsecp256k1 version 0.2 (released in December 2022), with the recommendation to use SECP256K1_CONTEXT_NONE instead.
2024-08-20miner: adjust clock to timewarp ruleSjors Provoost
2024-08-20consensus: enable BIP94 on regtestSjors Provoost
2024-08-20consensus: lower regtest nPowTargetTimespan to 144Sjors Provoost
This currently has no effect due to fPowNoRetargeting, except for the getnetworkhashps when called with -1. It will when the next commit enforces the timewarp attack mitigation on regtest.
2024-08-20fuzz: Speed up utxo_snapshot fuzz targetMarcoFalke
This speeds up the fuzz target, which allows "valid" inputs. It does not affect the "INVALID" fuzz target.
2024-08-19Merge bitcoin/bitcoin#30647: Move maximum timewarp attack threshold back to ↵Ava Chow
600s from 7200s 16e95bda86302af20cfb314a2c0252256d01f750 Move maximum timewarp attack threshold back to 600s from 7200s (Matt Corallo) Pull request description: In 6bfa26048dbafb91e9ca63ea8d3960271e798098 the testnet4 timewarp attack fix block time variation was increased from the Great Consensus Cleanup value of 600s to 7200s on the thesis that this allows miners to always create blocks with the current time. Sadly, doing so does allow for some nonzero inflation, even if not a huge amount. While it could be that some hardware ignores the timestamp provided to it over Stratum and forces the block header timestamp to the current time, I'm not aware of any such hardware, and it would also likely suffer from random invalid blocks due to relying on NTP anyway, making its existence highly unlikely. This leaves the only concern being pools, but most of those rely on work generated by Bitcoin Core (in one way or another, though when spy mining possibly not), and it seems likely that they will also not suffer any lost work. While its possible that a pool does generate invalid work due to spy mining or otherwise custom logic, it seems unlikely that a substantial portion of hashrate would do so, making the difference somewhat academic (any pool that screws this up will only do so once and the network would come out just fine). Further, while we may end up deciding these assumptions were invalid and we should instead use 7200s, it seems prudent to try with the value we "want" on testnet4, giving us the ability to learn if the compatibility concerns are an issue before we go to mainnet. ACKs for top commit: fjahr: tACK 16e95bda86302af20cfb314a2c0252256d01f750 achow101: ACK 16e95bda86302af20cfb314a2c0252256d01f750 murchandamus: crACK 16e95bda86302af20cfb314a2c0252256d01f750 Tree-SHA512: ae46d03b728b6e23cb6ace64c9813bc01c01e38dd7f159cf0fab53b331ef84b3b811edab225453ccdfedb53b242f55b0efd69829782657490fe393d24dacbeb2
2024-08-16Merge bitcoin/bitcoin#30621: wallet: fix blank legacy detectionglozow
6ed424f2db609f9f39ec1d1da2077c7616f3a0c2 wallet: fix, detect blank legacy wallets in IsLegacy (furszy) Pull request description: Blank legacy wallets do not have active SPKM. They can only be detected by checking the descriptors' flag or the db format. This enables the migration of blank legacy wallets in the GUI. To test this: 1) Create a blank legacy wallet. 2) Try to migrate it using the GUI's toolbar "Migrate Wallet" button. -> In master: The button will be disabled because `CWallet::IsLegacy()` returns false for blank legacy wallet. -> In this PR: the button will be enabled, allowing the migration of legacy wallets. ACKs for top commit: achow101: ACK 6ed424f2db609f9f39ec1d1da2077c7616f3a0c2 tdb3: ACK 6ed424f2db609f9f39ec1d1da2077c7616f3a0c2 glozow: ACK 6ed424f2db609f9f39ec1d1da2077c7616f3a0c2 Tree-SHA512: c06c4c4c2e546ccb033287b9aa3aee4ca36b47aeb2fac6fbed5de774b65caef9c818fc8dfdaac6ce78839b2d5d642a5632a5b44c5e889ea169ced80ed50501a7
2024-08-16seeds: Fixed seeds updateAva Chow
Update the fixed seeds for both mainnet and testnet
2024-08-16headerssync: Update headerssync configurationAva Chow
2024-08-16params: Update assumevalid and minimum chainworkAva Chow
2024-08-16params: Update chainTxDataAva Chow
2024-08-16params: Update assumed blockchain and chainstate sizesAva Chow
2024-08-16fuzz: Speed up utxo_snapshot by lazy re-initMarcoFalke
The re-init is expensive, so skip it if there is no need. Also, add an even faster fuzz target utxo_snapshot_invalid, which does not need any re-init at all.
2024-08-15Merge bitcoin/bitcoin#30659: wallet: fix UnloadWallet thread safety assumptionsAva Chow
f550a8e035b4603787273ea250f403f6f0be453f Rename ReleaseWallet to FlushAndDeleteWallet (furszy) 64e736d79efc7201768244fc297084f70c0bebc1 wallet: WaitForDeleteWallet, do not expect thread safety (Ryan Ofsky) 8872b4a6ca91a83bf8d5a118fb808c043b9e879d wallet: rename UnloadWallet to WaitForDeleteWallet (furszy) 5d15485aafefdc759ba97e039bb1b9ccac267358 wallet: unload, notify GUI as soon as possible (furszy) Pull request description: Coming from #29073. Applied ryanofsky suggested changes on https://github.com/bitcoin/bitcoin/issues/29073#issuecomment-2274237242 with few modifications coming from https://github.com/bitcoin/bitcoin/pull/18338#issuecomment-605060348. The only point I did not tackle from https://github.com/bitcoin/bitcoin/pull/18338#issuecomment-605060348 is: > * Move log print and flush out of ReleaseWallet into CWallet destructor Because it would mean every `CWallet` object would flush data to disk during destruction. Which is not necessary for wallet tool utilities and unit tests. ACKs for top commit: achow101: ACK f550a8e035b4603787273ea250f403f6f0be453f ryanofsky: Code review ACK f550a8e035b4603787273ea250f403f6f0be453f. Just a simple rename since last review ismaelsadeeq: Re-ACK f550a8e035b4603787273ea250f403f6f0be453f Tree-SHA512: e2eb69bf36883c514f601f4838ae6a41113996b9559abf8dc2b46e16bbcdad401195ac0f2b9d1fb55a10e78bb8ea9953788a168c80474e3f101350d208cb3bd2
2024-08-15Rename ReleaseWallet to FlushAndDeleteWalletfurszy
To better describe the function's behavior. And add wallet name to logprint.
2024-08-15fuzz: Remove unused DataStream objectMarcoFalke
2024-08-14wallet: WaitForDeleteWallet, do not expect thread safetyRyan Ofsky
Multiple threads could try to delete the wallet at the same time.
2024-08-14wallet: rename UnloadWallet to WaitForDeleteWalletfurszy
And update function's documentation.
2024-08-14wallet: unload, notify GUI as soon as possiblefurszy
Releases wallet shared pointers prior to doing the final settings update and prevent GUI races trying to access a wallet that is no longer loaded.
2024-08-14Merge bitcoin/bitcoin#28553: validation: assumeutxo params mainnetAva Chow
1610643c8b37a9f674b236cfa79abf8f8aaf1410 chainparams: add mainnet assumeutxo param at height 840_000 (Sjors Provoost) Pull request description: This adds snapshot parameters for mainnet block 840,000. You can generate the snapshot yourself using `./contrib/devtools/utxo_snapshot.sh` or download my torrent: * torrent: `magnet:?xt=urn:btih:596c26cc709e213fdfec997183ff67067241440c&dn=utxo-840000.dat&tr=udp%3A%2F%2Ftracker.bitcoin.sprovoost.nl%3A6969` It would be a good idea to test: 1. That you can produce the same snapshot file, sha256 sum: ``` dc4bb43d58d6a25e91eae93eb052d72e3318bd98ec62a5d0c11817cefbba177b utxo-840000.dat ``` 2. That the snapshot works ACKs for top commit: fjahr: re-ACK 1610643c8b37a9f674b236cfa79abf8f8aaf1410 achow101: ACK 1610643c8b37a9f674b236cfa79abf8f8aaf1410 theStack: Tested ACK 1610643c8b37a9f674b236cfa79abf8f8aaf1410 mzumsande: tested ACK 1610643c8b37a9f674b236cfa79abf8f8aaf1410 willcl-ark: tACK 1610643c8b37a9f674b236cfa79abf8f8aaf1410 Tree-SHA512: 581d8e86379bb044324f04f8559dd0a8946b6e2b145d5f25b38727b30b8cf13d6ac3c8777ff06554d3cf1a072809f7b5fbd693239868578f25dceafe5ba5f57c
2024-08-14Merge bitcoin/bitcoin#30648: doc: Deduplicate list of possible chain strings ↵Ava Chow
in RPC help texts 9b297555207b4ea54bc0051f09c7084797aa9def Deduplicate list of chain strings in RPC help texts (Martin Saposnic) Pull request description: As mentioned in issue https://github.com/bitcoin/bitcoin/issues/30645: Many command line parameter and RPC help texts currently contain the list of chain/network names hardcoded ("main, test, testnet4, signet, regtest"), which is error-prone as it can easily happen to miss an instance if the list ever changes again. This PR deduplicates the list of possible chain/network strings in RPC/parameter help texts, and it creates a macro `LIST_CHAIN_NAMES` in src/chainparamsbase.h. In the future, there is only 1 place where that list of possible values lives, so maintainability is improved and errors are avoided. All three places where this change impacts: ``` ./bitcoin-cli --help ./bitcoin-cli help getblockchaininfo ./bitcoin-cli help getmininginfo ``` They all return the correct string `"main, test, testnet4, signet, regtest"` See https://github.com/bitcoin/bitcoin/pull/30642#discussion_r1714711575 ACKs for top commit: maflcko: lgtm ACK 9b297555207b4ea54bc0051f09c7084797aa9def achow101: ACK 9b297555207b4ea54bc0051f09c7084797aa9def MarnixCroes: ACK 9b297555207b4ea54bc0051f09c7084797aa9def theStack: ACK 9b297555207b4ea54bc0051f09c7084797aa9def danielabrozzoni: ACK 9b297555207b4ea54bc0051f09c7084797aa9def Tree-SHA512: 1e961bcbe40b0f17a87a2437eb4ba1bb89468fd1b5a39599d72a00ef75cb4009e7d2f05d0a621bb904fecf681c55b8a219fcfe4d44d5d27f27cdda20882b1323
2024-08-14qt: Update translation source file for v28.0 string freezeHennadii Stepanov
The diff is produced by running `make -C src translate`.
2024-08-14Merge bitcoin-core/gui#824: Migrate legacy wallets that are not loadedHennadii Stepanov
8f2522d242961ceb9e79672aa43e856863a1a6dd gui: Use menu for wallet migration (Ava Chow) d56a450bf5172e2c3f4b9a2786e71268019e1277 gui: Use wallet name for wallet migration rather than WalletModel (Ava Chow) c3918583dd5fcd9001136da2192e02e092128901 gui: don't remove wallet manually before migration (furszy) bfba63880fbb1108b73540faeb0620ba24b8cdd0 gui: Consolidate wallet display name to GUIUtil function (Ava Chow) 28fc562f2692af4f37f918d4ae31c4d115e03aee wallet, interfaces: Include database format in listWalletDir (Ava Chow) Pull request description: Currently the Migrate Wallet menu item can only be used to migrate the currently loaded wallet. This is not suitable for the future when legacy wallets can no longer be loaded at all, but should still be able to be migrated. This PR changes that menu item into a menu list like Open Wallet and lets users migrate any legacy wallet in their wallet directory regardless of the wallets loaded. One issue I ran into was dealing with encrypted wallets. Ideally, we would detect whether a wallet is encrypted, and prompt the user for their passphrase at that time. However, that's actually difficult to do in the GUI since migration will unload the wallet if it was already loaded, and reload it without connecting it to any signals or interfaces. Only then can it detect whether a wallet is encrypted, but then there is no `WalletModel` or even an `interfaces::Wallet` that the GUI could use to unlock it via a callback. To deal with this, I've opted to just add a button to the migration dialog box that has the user enter their passphrase first, along with instructional text to use that button if their wallet was encrypted. If the user enters the wrong passphrase or clicked the other button that does not prompt for the passphrase, migration will fail with a message indicating that the passphrase was incorrect. ACKs for top commit: hebasto: ACK 8f2522d242961ceb9e79672aa43e856863a1a6dd. furszy: ACK 8f2522d Tree-SHA512: a0e3b70dbfcacb89617956510ebcea94cad8617a987c68fe39fa16ac1721190b7cf7afc156c39b9032920cfb67b5d4ca28791681f5021d92d16acc691387afa1
2024-08-13gui: Use menu for wallet migrationAva Chow
Once legacy wallets can no longer be loaded, we need to be able to migrate them without loading. Thus we should use a menu that lists the wallets in the wallet directory instead of an action which migrates the currently loaded wallet.
2024-08-13remove repeated word in notesunerok
2024-08-13Move maximum timewarp attack threshold back to 600s from 7200sMatt Corallo
In 6bfa26048dbafb91e9ca63ea8d3960271e798098 the testnet4 timewarp attack fix block time variation was increased from the Great Consensus Cleanup value of 600s to 7200s on the thesis that this allows miners to always create blocks with the current time. Sadly, doing so does allow for some nonzero inflation, even if not a huge amount. While it could be that some hardware ignores the timestamp provided to it over Stratum and forces the block header timestamp to the current time, I'm not aware of any such hardware, and it would also likely suffer from random invalid blocks due to relying on NTP anyway, making its existence highly unlikely. This leaves the only concern being pools, but most of those rely on work generated by Bitcoin Core (in one way or another, though when spy mining possibly not), and it seems likely that they will also not suffer any lost work. While its possible that a pool does generate invalid work due to spy mining or otherwise custom logic, it seems unlikely that a substantial portion of hashrate would do so, making the difference somewhat academic (any pool that screws this up will only do so once and the network would come out just fine). Further, while we may end up deciding these assumptions were invalid and we should instead use 7200s, it seems prudent to try with the value we "want" on testnet4, giving us the ability to learn if the compatibility concerns are an issue before we go to mainnet.
2024-08-13Deduplicate list of chain strings in RPC help textsMartin Saposnic
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-14 17:55:59 +0000