Upgrade to bitcoin v28 #12
Open
Conversation
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
189c987 Showing local addresses on the Node Window (Jadi) a5d7aff net: Providing an interface for mapLocalHost (Jadi) Pull request description: This change adds a new row to the Node Window (debugwindow.ui) under the Network section which shows the LocalAddresses. fixes bitcoin#564 <!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md --> <!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. --> <!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. --> ACKs for top commit: pablomartin4btc: re-ACK 189c987 furszy: utACK 189c987 Tree-SHA512: 93f201bc6d21d81b27b87be050a447b841f01e3efb69b9eca2cc7af103023d7cd69eb5e16e2875855573ef51a5bf74a6ee6028636c1b6798cb4bb11567cb4996
- Add description that indicates the fee estimation modes behaviour. - This description will be returned in the RPC's help texts.
… a standard output script for spending 75648ce test: add P2A ProduceSignature coverage (Greg Sanders) 7998ce6 Add release note for P2A output feature (Greg Sanders) 71c9b02 test: add P2A coverage for decodescript (Greg Sanders) 1349e9e test: Add anchor mempool acceptance test (Greg Sanders) 9d89209 policy: stop 3rd party wtxid malleability of anchor spend (Greg Sanders) b60aaf8 policy: make anchor spend standard (Greg Sanders) 455fca8 policy: Add OP_1 <0x4e73> as a standard output type (Greg Sanders) Pull request description: This is a sub-feature taken out of the original proposal for ephemeral anchors bitcoin#30239 This PR makes *spending* of `OP_1 <0x4e73>` (i.e. `bc1pfeessrawgf`) standard. Creation of this output type is already standard. Any future witness output types are considered relay-standard to create, but not to spend. This preserves upgrade hooks, such as a completely new output type for a softfork such as BIP341. It also gives us a bit of room to use a new output type for policy uses. This particular sized witness program has no other known use-cases (https://bitcoin.stackexchange.com/a/110664/17078), s it affords insufficient cryptographic security for a secure commitment to data, such as a script or a public key. This makes this type of output "keyless", or unauthenticated. As a witness program, the `scriptSig` of the input MUST be blank, by BIP141. This helps ensure txid-stability of the spending transaction, which may be required for smart contracting wallets. If we do not use segwit, a miner can simply insert an `OP_NOP` in the `scriptSig` without effecting the result of program execution. An additional relay restriction is to disallow non-empty witness data, which an adversary may use to penalize the "honest" transactor when RBF'ing the transaction due to the incremental fee requirement of RBF rules. The intended use-case for this output type is to "anchor" the transaction with a spending child to bring exogenous CPFP fees into the transaction package, encouraging the inclusion of the package in a block. The minimal size of creation and spending of this output makes it an attractive contrast to outputs like `p2sh(OP_TRUE)` and `p2wsh(OP_TRUE)` which are significantly larger in vbyte terms. Combined with TRUC transactions which limits the size of child transactions significantly, this is an attractive option for presigned transactions that need to be fee-bumped after the fact. ACKs for top commit: sdaftuar: utACK 75648ce theStack: re-ACK 75648ce ismaelsadeeq: re-ACK 75648ce via [diff](https://github.com/bitcoin/bitcoin/compare/e7ce6dc070c0319cbb868d41cadd836b2e6ca9db..75648cea5a9032b3d388cbebacb94d908e08924e) glozow: ACK 75648ce tdb3: ACK 75648ce Tree-SHA512: d529de23d20857e6cdb40fa611d0446b49989eaafed06c28280e8fd1897f1ed8d89a4eabbec1bbf8df3d319910066c3dbbba5a70a87ff0b2967d5205db32ad1e
Enable full rbf (mempool policy) by default and update tests accordingly.
This stems from a requirement for the g++ minimum supported version being >= 11.
Add benchmarks for signing with null and non-null merkle_root arguments. Null and non-null merkle_root arguments will apply the taptweaks H_TapTweak(P) and H_TapTweak(P | merkle_root), respectively, to the private key during signing. This benchmark is added to verify there are no significant performance changes after moving the taptweak signing logic in a later commit. Co-authored-by: l0rinc <[email protected]>
Sanity check that using CKey/CPubKey directly vs using secp256k1_keypair objects returns the same results for BIP341 key tweaking. Co-authored-by: l0rinc <[email protected]>
Add a `KeyPair` class which wraps the `secp256k1_keypair`. This keeps the secret data in secure memory and enables passing the `KeyPair` object directly to libsecp256k1 functions expecting a `secp256k1_keypair`. Motivation: when passing `CKeys` for taproot outputs to libsecp256k1 functions, the first step is to create a `secp256k1_keypair` data type and use that instead. This is so the libsecp256k1 function can determine if the key needs to be negated, e.g., when signing. This is a bit clunky in that it creates an extra step when using a `CKey` for a taproot output and also involves copying the secret data into a temporary object, which the caller must then take care to cleanse. In addition, the logic for applying the merkle_root tweak currently only exists in the `SignSchnorr` function. In a later commit, we will add the merkle_root tweaking logic to this function, which will make the merkle_root logic reusable outside of signing by using the `KeyPair` class directly. Co-authored-by: Cory Fields <[email protected]>
Follow-up to bitcoin#30436. uint256 string representation was wrongfully documented as little-endian due to them being reversed by GetHex() etc, and base_blob::Compare() giving most significance to the beginning of the internal array. They are closer to "big-endian", but this commit tries to be even more precise than that. uint256_tests.cpp - Avoid using variable from the left side of the condition in the right side. setup_common.cpp - Skip needless ArithToUint256-conversion.
Make special cases explicit in GetLogCategory() and LogCategoryToStr() functions. Simplify the LOG_CATEGORIES_BY_STR and LOG_CATEGORIES_BY_FLAG mappings and LogCategoriesList() function. This makes the maps `LOG_CATEGORIES_BY_STR` and `LOG_CATEGORIES_BY_FLAG` consistent (one is exactly the opposite of the other).
…E instead of 0 * Make the standalone function `LogCategoryToStr()` private inside `logging.cpp` (aka `static`) - it is only used in that file. * Make the method `Logger::GetLogPrefix()` `private` - it is only used within the class. * Use `BCLog::NONE` to initialize `m_categories` instead of `0`. We later check whether it is `BCLog::NONE` (in `Logger::DefaultShrinkDebugFile()`).
Current logging RPC method documentation claims to accept "0" and "none" categories, but the "none" argument is actually rejected and the "0" argument is ignored. Update the implementation to refuse both categories, and remove the help text claiming to support them.
Move `SignSchnorr` to `KeyPair`. This makes `CKey::SignSchnorr` now
compute a `KeyPair` object and then call `KeyPair::SignSchorr`. The
notable changes are:
* Move the merkle_root tweaking out of the sign function and into
the KeyPair constructor
* Remove the temporary secp256k1_keypair object and have the
functions access m_keypair->data() directly
Reuse existing BIP340 tests, as there should be no behavior change between the two
Replace early returns in KeyPair::KeyPair() with asserts. The if statements imply there is an error we are handling, but keypair_xonly_pub and xonly_pubkey_serialize can only fail if the keypair object is malformed, i.e., it was created with a bad secret key. Since we check that the keypair was created successfully before attempting to extract the public key, using asserts more accurately documents what we expect here and removes untested branches from the code.
Also update types of assumeutxo chainparams and some related local variables for consistency. Co-authored-by: russeree <[email protected]>
-BEGIN VERIFY SCRIPT- sed -i 's/nChainTx/m_chain_tx_count/g' $(git grep -l 'nChainTx' ./src) sed -i 's/nTxCount/tx_count/g' $(git grep -l 'nTxCount' ./src) -END VERIFY SCRIPT-
a7432dd logging: clarify -debug and -debugexclude descriptions (Anthony Towns) 74dd33c rpc: make logging method reject "0" category and correct the help text (Vasil Dimov) 8c6f3bf logging, refactor: minor encapsulation improvement and use BCLog::NONE instead of 0 (Vasil Dimov) 160706a logging, refactor: make category special cases explicit (Ryan Ofsky) Pull request description: * Move special cases from `LOG_CATEGORIES_BY_STR` to `GetLogCategory()` (suggested [here](bitcoin#29419 (comment))). * Remove `"none"` and `"0"` from RPC `logging` help because that help text was wrong. `"none"` resulted in an error and `"0"` was ignored itself (contrary to what the help text suggested). * Remove unused `LOG_CATEGORIES_BY_STR[""]` (suggested [here](bitcoin#29419 (comment))). This is a followup to bitcoin#29419, addressing leftover suggestions + more. ACKs for top commit: LarryRuane: ACK a7432dd ryanofsky: Code review ACK a7432dd. Only changes since last review are removing dead if statement and adding AJ's suggested -debug and -debugexclude help improvements, which look accurate and much more clear. Tree-SHA512: 41b997b06fccdb4c1d31f57d4752c83caa744cb3280276a337ef4a9b7012a04eb945071db6b8fad24c6a6cf8761f2f800fe6d8f3d8836f5b39c25e4f11c85bf0
73e3fa1 doc + test: Correct uint256 hex string endianness (Hodlinator) Pull request description: This PR is a follow-up to bitcoin#30436. Only changes test-code and modifies/adds comments. Byte order of hex string representation was wrongfully documented as little-endian, but are in fact closer to "big-endian" (endianness is a memory-order concept rather than a numeric concept). `[arith_]uint256` both store their data in arrays with little-endian byte order (`arith_uint256` has host byte order within each `uint32_t` element). **uint256_tests.cpp** - Avoid using variable from the left side of the condition in the right side. Credits to @maflcko: bitcoin#30436 (comment) **setup_common.cpp** - Skip needless ArithToUint256-conversion. Credits to @stickies-v: bitcoin#30436 (comment) --- <details> <summary> ## Logical reasoning for endianness </summary> 1. Comparing an `arith_uint256` (`base_uint<256>`) to a `uint64_t` compares the beginning of the array, and verifies the remaining elements are zero. ```C++ template <unsigned int BITS> bool base_uint<BITS>::EqualTo(uint64_t b) const { for (int i = WIDTH - 1; i >= 2; i--) { if (pn[i]) return false; } if (pn[1] != (b >> 32)) return false; if (pn[0] != (b & 0xfffffffful)) return false; return true; } ``` ...that is consistent with little endian ordering of the array. 2. They have the same endianness (but `arith_*` has host-ordering of each `uint32_t` element): ```C++ arith_uint256 UintToArith256(const uint256 &a) { arith_uint256 b; for(int x=0; x<b.WIDTH; ++x) b.pn[x] = ReadLE32(a.begin() + x*4); return b; } ``` ### String conversions The reversal of order which happens when converting hex-strings <=> uint256 means strings are actually closer to big-endian, see the end of `base_blob<BITS>::SetHexDeprecated`: ```C++ unsigned char* p1 = m_data.data(); unsigned char* pend = p1 + WIDTH; while (digits > 0 && p1 < pend) { *p1 = ::HexDigit(trimmed[--digits]); if (digits > 0) { *p1 |= ((unsigned char)::HexDigit(trimmed[--digits]) << 4); p1++; } } ``` Same reversal here: ```C++ template <unsigned int BITS> std::string base_blob<BITS>::GetHex() const { uint8_t m_data_rev[WIDTH]; for (int i = 0; i < WIDTH; ++i) { m_data_rev[i] = m_data[WIDTH - 1 - i]; } return HexStr(m_data_rev); } ``` It now makes sense to me that `SetHexDeprecated`, upon receiving a shorter hex string that requires zero-padding, would pad as if the missing hex chars where towards the end of the little-endian byte array, as they are the most significant bytes. "Big-endian" string representation is also consistent with the case where `SetHexDeprecated` receives too many hex digits and discards the leftmost ones, as a form of integer narrowing takes place. ### How I got it wrong in bitcoin#30436 Previously I used the less than (`<`) comparison to prove endianness, but for `uint256` it uses `memcmp` and thereby gives priority to the *lower* bytes at the beginning of the array. ```C++ constexpr int Compare(const base_blob& other) const { return std::memcmp(m_data.data(), other.m_data.data(), WIDTH); } ``` `arith_uint256` is different in that it begins by comparing the bytes from the end, as it is using little endian representation, where the bytes toward the end are more significant. ```C++ template <unsigned int BITS> int base_uint<BITS>::CompareTo(const base_uint<BITS>& b) const { for (int i = WIDTH - 1; i >= 0; i--) { if (pn[i] < b.pn[i]) return -1; if (pn[i] > b.pn[i]) return 1; } return 0; } ``` (The commit documents that `base_blob::Compare()` is doing lexicographic ordering unlike the `arith_*`-variant which is doing numeric ordering). </details> ACKs for top commit: paplorinc: ACK 73e3fa1 ryanofsky: Code review ACK 73e3fa1 Tree-SHA512: 121630c37ab01aa7f7097f10322ab37da3cbc0696a6bbdbf2bbd6db180dc5938c7ed91003aaa2df7cf4a4106f973f5118ba541b5e077cf3588aa641bbd528f4e
…earizations bbcee5a clusterlin: improve rechunking in LinearizationChunking (optimization) (Pieter Wuille) 04d7a04 clusterlin: add MergeLinearizations function + fuzz test + benchmark (Pieter Wuille) 4f8958d clusterlin: add PostLinearize + benchmarks + fuzz tests (Pieter Wuille) 0e2812d clusterlin: add algorithms for connectedness/connected components (Pieter Wuille) 0e52728 clusterlin: rename Intersect -> IntersectPrefixes (Pieter Wuille) Pull request description: Part of cluster mempool: bitcoin#30289 Depends on bitcoin#30126, and was split off from it. bitcoin#28676 depends on this. This adds the algorithms for merging & postprocessing linearizations. The `PostLinearize(depgraph, linearization)` function performs an in-place improvement of `linearization`, using two iterations of the [Linearization post-processing](https://delvingbitcoin.org/t/linearization-post-processing-o-n-2-fancy-chunking/201/8) algorithm. The first running from back to front, the second from front to back. The `MergeLinearizations(depgraph, linearization1, linearization2)` function computes a new linearization for the provided cluster, given two existing linearizations for that cluster, which is at least as good as both inputs. The algorithm is described at a high level in [merging incomparable linearizations](https://delvingbitcoin.org/t/merging-incomparable-linearizations/209). For background and references, see [Introduction to cluster linearization](https://delvingbitcoin.org/t/introduction-to-cluster-linearization/1032). ACKs for top commit: sdaftuar: ACK bbcee5a glozow: code review ACK bbcee5a instagibbs: ACK bitcoin@bbcee5a Tree-SHA512: d2b5a3f132d1ef22ddf9c56421ab8b397efe45b3c4c705548dda56f5b39fe4b8f57a0d2a4c65b338462d80bb5b9b84a9a39efa1b4f390420a8005ce31817774e
bd45bc6 doc: Point release notes to wiki draft (Ava Chow) 27b6300 examples: Generate example bitcoin.conf (Ava Chow) 08887d3 doc: Generate manpages (Ava Chow) 6974e30 build: Bump to 28.0rc1 (Ava Chow) Pull request description: * Bump version to 28.0rc1 * Generated manpages * Generated example bitcoin.conf * Point release notes to wiki ACKs for top commit: hebasto: ACK bd45bc6. Tree-SHA512: c3cd28b003ead64631b8c2d1bdbf7403d4d9f53ee5ccdc448d89ca25941678f6d1d8966c2f9a92fa021c815b3e36a84056342caa4eaacdab371f0d581e4e58dc
Github-Pull: bitcoin#30714 Rebased-From: bd7ce05
…k.py Github-Pull: bitcoin#30761 Rebased-From: fa247e6
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 bitcoin#30608 Github-Pull: bitcoin#30788 Rebased-From: ae48a22
Currently, builds of libevent in depends, using CMake, fail on some systems, like Alpine, with the following: ```bash /bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c: In function 'evmap_signal_add_': /bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c:456:31: error: 'NSIG' undeclared (first use in this function) 456 | if (sig < 0 || sig >= NSIG) ``` From what I can tell the `_GNU_SOURCE` "detection" in libevents CMake build system, never? really worked, and it's not clear what a nice fix is. For now, always use `_GNU_SOURCE` when building libevent in depends. Github-Pull: bitcoin#30743 Rebased-From: 5567754
b2a1379 depends: build libevent with -D_GNU_SOURCE (fanquake) 199bb09 test: fixing failing system_tests/run_command under some Locales (Jadi) 342baab test: Avoid intermittent timeout in p2p_headers_sync_with_minchainwork.py (MarcoFalke) 5577d5a test: fix `TestShell` initialization (late follow-up for bitcoin#30463) (Sebastian Falbesoner) Pull request description: Backports: * bitcoin#30714 * bitcoin#30743 * bitcoin#30761 * bitcoin#30788 ACKs for top commit: willcl-ark: ACK b2a1379 achow101: ACK b2a1379 stickies-v: ACK b2a1379 Tree-SHA512: bf08ac0c613395def974a1b287345d4a64edc066c14f8c9f0184478b0e33e48333760eeb6e96b6b5fbafbb21b40d01875e3f526213a2734e226b2e111d71f3a3
Github-Pull: bitcoin#30834 Rebased-From: fa9d7d5
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#30807
Rebased-From: 6d5812e
Exercising and verifying the following points: 1. An IBD node can sync headers from an AssumeUTXO node at any time. 2. IBD nodes do not request historical blocks from AssumeUTXO nodes while they are syncing the background-chain. 3. The assumeUTXO node dynamically adjusts the network services it offers according to its state. 4. IBD nodes can fully sync from AssumeUTXO nodes after they finish the background-chain sync. Github-Pull: bitcoin#30807 Rebased-From: 992f83b
Github-Pull: bitcoin#30880 Rebased-From: 19f4a7c
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: a965f2b
The recent translations from Transifex.com 28.x fetched with the bitcoin-maintainer-tools/update-translations.py tool. Github-Pull: bitcoin#30899 Rebased-From: ae05295
Github-Pull: bitcoin#30884 Rebased-From: e624a9b
Co-Authored-By: David Gumberg <[email protected]> Github-Pull: bitcoin#30884 Rebased-From: a240e15
06a7df7 doc: Generate manpages (Ava Chow) 5315886 build: Bump to 28.0rc2 (Ava Chow) ff95cb3 streams: remove AutoFile::Get() entirely (Pieter Wuille) 8229e98 streams: cache file position within AutoFile (Pieter Wuille) 1b853fd qt: Translations update (Hennadii Stepanov) 674dded gui: fix crash when closing wallet (furszy) d39262e test: Wait for local services to update in feature_assumeutxo (Fabian Jahr) b329ed7 test: add coverage for assumeUTXO honest peers disconnection (furszy) c6b5db1 assumeUTXO: fix peers disconnection during sync (furszy) 598415b test: Work around boost compilation error (MarcoFalke) Pull request description: * bitcoin#30834 * bitcoin#30807 * bitcoin#30880 * bitcoin-core/gui#835 * bitcoin#30899 * bitcoin#30884 ACKs for top commit: stickies-v: ACK 06a7df7 hebasto: ACK 06a7df7, I've backported the listed PRs locally. The only merge conflict I faced was in bitcoin#30807. It was trivial to resolve. Tree-SHA512: 779d734b50fdce379a20865ba30c969def028963ba51da0f497ddf1b5375e1f6166365295f226c1a07bab8be0c1aa0a6a3296fc6acd9fcf17bcc4874aac980a6
Github-Pull: bitcoin#30952 Rebased-From: 7bd3ee6
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#30962 Rebased-From: c0a0c72
5de225f doc: 28.0 Release Notes (Ava Chow) 98745e0 doc: generate manpages (Ava Chow) 5feef9c build: Bump to 28.0 (Ava Chow) 7fcd7b8 validation: Disable CheckForkWarningConditions for background chainstate (Martin Zumsande) e24a25d test: Use shell builtins in run_command test case (Ava Chow) Pull request description: * bitcoin#30952 * bitcoin#30962 * Finalize 28.0 (or rc3 if additional backports are needed) ACKs for top commit: sipa: utACK 5de225f Tree-SHA512: b42948a04d4250f2c9ef3331a39a4c3d7de9ceb9f4f294dd283599d08f3e2b7147297ef9ec1c4276e291a015fc2daa5a72c1f1c33fb517e8ea5c740c4459bf32
Bitcoin Core 28.0 final Tree-SHA512: b42948a04d4250f2c9ef3331a39a4c3d7de9ceb9f4f294dd283599d08f3e2b7147297ef9ec1c4276e291a015fc2daa5a72c1f1c33fb517e8ea5c740c4459bf32
fixes #11 Adds BIP94 compatibility to DGW.
Open
modified: ../build-aux/m4/bitcoin_qt.m4
modified: ../build_msvc/README.md
modified: ../configure.ac
modified: Makefile.am
modified: Makefile.test.include
modified: chainparamsseeds.h
modified: common/args.cpp
modified: dbwrapper.h
modified: hash.h
modified: hashdb.cpp
modified: headerssync.cpp
modified: headerssync.h
modified: init.cpp
modified: kernel/chainparams.cpp
modified: net_processing.cpp
modified: node/blockstorage.cpp
modified: node/chainstate.cpp
modified: pow.cpp
modified: pow.h
new file: qt/Makefile
modified: qt/bitcoinamountfield.cpp
new file: qt/test/Makefile
modified: qt/test/wallettests.cpp
modified: rpc/external_signer.cpp
modified: rpc/net.cpp
new file: test/Makefile
modified: validation.cpp
modified: ../test/functional/feature_proxy.py
main files ammended to enable compilation of executables see commited changes :
--------------------------------------------------------
-ammended src/Makefile.am -see committed changes
-ammended Makefile.test.include
-missing function in pow.cpp: CalculateNextWorkRequired
-init.cpp added phashdb.reset()
-chain.cpp added phashdb.reset(); phashdb.reset(new CHashDB(nBlockTreeDBCache, false, fReset))
-added Makefiles in following directories due to autogen error:
configure.ac:1691: error: required file 'src/qt/Makefile' not found
configure.ac:1692: error: required file 'src/qt/test/Makefile' not found
configure.ac:1693: error: required file 'src/test/Makefile' not found
-removed merge conflict in:
build-aux/m4/bitcoin_qt.m4
src/qt/test/wallettests.cpp
src/rpc/net.cpp
test/functional/feature_proxy.py
build_msvc/README.md
-add at node/chainstate.cpp in function static ChainstateLoadResult CompleteChainstateInitialization:
//leveldb cache
phashdb.reset();
phashdb.reset(new CHashDB(cache_sizes.block_tree_db, false, options.wipe_block_tree_db))
update src/test/fuzz/headerssync.cpp modified: src/Makefile.am deleted: src/crypto/yespower/optimizer.c deleted: src/crypto/yespower/optimizer.h modified: src/crypto/yespower/yespower-opt.c modified: src/crypto/yespower/yespower.c modified: src/crypto/yespower/yespower.h modified: src/headerssync.cpp modified: src/headerssync.h modified: src/test/fuzz/headerssync.cpp
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Whive Core version 28.0 is now available from:
This release includes all new features, various bug fixes and performance
improvements, as well as updated translations from Bitcoin version 28.0
Please report bugs using the issue tracker at GitHub:
https://github.com/whiveio/whive/issues
Compatibility
Bitcoin Core is supported and extensively tested on operating systems
using the Linux Kernel 3.17+, macOS 11.0+, and Windows 7 and newer. Bitcoin
Core should also work on most other UNIX-like systems but is not as
frequently tested on them. It is not recommended to use Bitcoin Core on
unsupported systems.
Notable changes
Testnet4/BIP94 support
Support for Testnet4 as specified in BIP94
has been added. The network can be selected with the
-testnet4option andthe section header is also named
[testnet4].While the intention is to phase out support for Testnet3 in an upcoming
version, support for it is still available via the known options in this
release. (bitcoin#29775)
Windows Data Directory
The default data directory on Windows has been moved from
C:\Users\Username\AppData\Roaming\Bitcointo
C:\Users\Username\AppData\Local\Bitcoin. Bitcoin Core will check the existenceof the old directory first and continue to use that directory for backwards
compatibility if it is present. (bitcoin#27064)
JSON-RPC 2.0 Support
The JSON-RPC server now recognizes JSON-RPC 2.0 requests and responds with
strict adherence to the specification.
See JSON-RPC-interface.md for details. (bitcoin#27101)
JSON-RPC clients may need to be updated to be compatible with the JSON-RPC server.
Please open an issue on GitHub if any compatibility issues are found.
libbitcoinconsensus Removal
The libbitcoin-consensus library was deprecated in 27.0 and is now completely removed. (bitcoin#29648)
P2P and Network Changes
Previously if Bitcoin Core was listening for P2P connections, either using
default settings or via
bind=addr:portit would always also bind to127.0.0.1:8334to listen for Tor connections. It was not possible to switchthis off, even if the node didn't use Tor. This has been changed and now
bind=addr:portresults in binding onaddr:portonly. The default behaviorof binding to
0.0.0.0:8333and127.0.0.1:8334has not been changed.If you are using a
bind=...configuration withoutbind=...=onionand relyon the previous implied behavior to accept incoming Tor connections at
127.0.0.1:8334, you need to now make this explicit by usingbind=... bind=127.0.0.1:8334=onion. (Make it possible to disable Tor binds and abort startup on bind failure bitcoin/bitcoin#22729)Bitcoin Core will now fail to start up if any of its P2P binds fail, rather
than the previous behaviour where it would only abort startup if all P2P
binds had failed. (Make it possible to disable Tor binds and abort startup on bind failure bitcoin/bitcoin#22729)
UNIX domain sockets can now be used for proxy connections. Set
-onionor-proxyto the local socket path with the prefix
unix:(e.g.-onion=unix:/home/me/torsocket).(net: support unix domain sockets for -proxy and -onion bitcoin/bitcoin#27375)
UNIX socket paths are now accepted for
-zmqpubrawblockand-zmqpubrawtxwiththe format
-zmqpubrawtx=unix:/path/to/file(ZMQ: Support UNIX domain sockets bitcoin/bitcoin#27679)Additional "in" and "out" flags have been added to
-whitelistto control whetherpermissions apply to inbound connections and/or manual ones (default: inbound only). (p2p: Allow whitelisting manual connections bitcoin/bitcoin#27114)
Transactions having a feerate that is too low will be opportunistically paired with
their child transactions and submitted as a package, thus enabling the node to download
1-parent-1-child packages using the existing transaction relay protocol. Combined with
other mempool policies, this change allows limited "package relay" when a parent transaction
is below the mempool minimum feerate. Topologically Restricted Until Confirmation (TRUC)
parents are additionally allowed to be below the minimum relay feerate (i.e., pay 0 fees).
Use the
submitpackageRPC to submit packages directly to the node. Warning: this P2Pfeature is limited (unlike the
submitpackageinterface, a child with multiple unconfirmedparents is not supported) and not yet reliable under adversarial conditions. (p2p: opportunistically accept 1-parent-1-child packages bitcoin/bitcoin#28970)
Mempool Policy Changes
Transactions with version number set to 3 are now treated as standard on all networks (policy: bump TX_MAX_STANDARD_VERSION to 3 bitcoin/bitcoin#29496),
subject to opt-in Topologically Restricted Until Confirmation (TRUC) transaction policy as
described in BIP 431. The
policy includes limits on spending unconfirmed outputs (v3 transaction policy for anti-pinning bitcoin/bitcoin#28948), eviction of a previous descendant
if a more incentive-compatible one is submitted (policy: enable sibling eviction for v3 transactions bitcoin/bitcoin#29306), and a maximum transaction size of 10,000vB
(policy: restrict all TRUC (v3) transactions to 10kvB bitcoin/bitcoin#29873). These restrictions simplify the assessment of incentive compatibility of accepting or
replacing TRUC transactions, thus ensuring any replacements are more profitable for the node and
making fee-bumping more reliable.
Pay To Anchor (P2A) is a new standard witness output type for spending,
a newly recognised output template. This allows for key-less anchor
outputs, with compact spending conditions for additional efficiencies on
top of an equivalent
sh(OP_TRUE)output, in addition to the txid stabilityof the spending transaction.
N.B. propagation of this output spending on the network will be limited
until a sufficient number of nodes on the network adopt this upgrade. (policy: Add PayToAnchor(P2A),
OP_1 <0x4e73>as a standard output script for spending bitcoin/bitcoin#30352)Limited package RBF is now enabled, where the proposed conflicting package would result in
a connected component, aka cluster, of size 2 in the mempool. All clusters being conflicted
against must be of size 2 or lower. (Cluster size 2 package rbf bitcoin/bitcoin#28984)
The default value of the
-mempoolfullrbfconfiguration option has been changed from 0 to 1,i.e.
mempoolfullrbf=1. (policy: enable full-rbf by default bitcoin/bitcoin#30493)Updated RPCs
The
dumptxoutsetRPC now returns the UTXO set dump in a new andimproved format. Correspondingly, the
loadtxoutsetRPC now expectsthis new format in the dumps it tries to load. Dumps with the old
format are no longer supported and need to be recreated using the
new format to be usable. (rpc: Optimize serialization and enhance metadata of dumptxoutset output bitcoin/bitcoin#29612)
AssumeUTXO mainnet parameters have been added for height 840,000.
This means the
loadtxoutsetRPC can now be used on mainnet withthe matching UTXO set from that height. (validation: assumeutxo params mainnet bitcoin/bitcoin#28553)
The
warningsfield ingetblockchaininfo,getmininginfoandgetnetworkinfonow returns all the active node warnings as an arrayof strings, instead of a single warning. The current behaviour
can be temporarily restored by running Bitcoin Core with the configuration
option
-deprecatedrpc=warnings. (rpc: return warnings as an array instead of just a single one bitcoin/bitcoin#29845)Previously when using the
sendrawtransactionRPC and specifying outputsthat are already in the UTXO set, an RPC error code of
-27with themessage "Transaction already in block chain" was returned in response.
The error message has been changed to "Transaction outputs already in utxo set"
to more accurately describe the source of the issue. (rename TransactionError:ALREADY_IN_CHAIN bitcoin/bitcoin#30212)
The default mode for the
estimatesmartfeeRPC has been updated fromconservativetoeconomical,which is expected to reduce over-estimation for many users, particularly if Replace-by-Fee is an option.
For users that require high confidence in their fee estimates at the cost of potentially over-estimating,
the
conservativemode remains available. (Fee Estimation: changeestimatesmartfeedefault mode toeconomicalbitcoin/bitcoin#30275)RPC
scantxoutsetnow returns 2 new fields in the "unspents" JSON array:blockhashandconfirmations.See the scantxoutset help for details. (rpc: add utxo's blockhash and number of confirmations to scantxoutset output bitcoin/bitcoin#30515)
RPC
submitpackagenow allows 2 new arguments to be passed:maxfeerateandmaxburnamount. See thesubtmitpackage help for details. (RPC: Add maxfeerate and maxburnamount args to submitpackage bitcoin/bitcoin#28950)
Changes to wallet-related RPCs can be found in the Wallet section below.
Updated REST APIs
/rest/getutxoshas been improved by rejectingtruncated or overly large txids and malformed outpoint indices via raising
an HTTP_BAD_REQUEST "Parse error". These requests were previously handled
silently. (rest: Reject truncated hex txid early in getutxos parsing bitcoin/bitcoin#30482, rest: Reject negative outpoint index early in getutxos parsing bitcoin/bitcoin#30444)
Build System
GCC 11.1 or later, or Clang 16.0 or later,
are now required to compile Bitcoin Core. (build: Bump g++ minimum supported version to 11 bitcoin/bitcoin#29091, build: Bump clang minimum supported version to 16 bitcoin/bitcoin#30263)
The minimum required glibc to run Bitcoin Core is now
2.31. This means that RHEL 8 and Ubuntu 18.04 (Bionic)
are no-longer supported. (guix: build with glibc 2.31 bitcoin/bitcoin#29987)
--enable-lcov-branch-coveragehas been removed, givenincompatibilities between lcov version 1 & 2.
LCOV_OPTSshould be used to set any options instead. (build: remove
--enable-lcov-branch-coveragebitcoin/bitcoin#30192)Updated Settings
-alertnotify, an alert can now be raised multipletimes instead of just once. Previously, it was only raised when unknown
new consensus rules were activated. Its scope has now been increased to
include all kernel warnings. Specifically, alerts will now also be raised
when an invalid chain with a large amount of work has been detected.
Additional warnings may be added in the future. (Encapsulate warnings in generalized node::Warnings and remove globals bitcoin/bitcoin#30058)
Changes to GUI or wallet related settings can be found in the GUI or Wallet section below.
Wallet
The wallet now detects when wallet transactions conflict with the mempool. Mempool-conflicting
transactions can be seen in the
"mempoolconflicts"field ofgettransaction. The inputsof mempool-conflicted transactions can now be respent without manually abandoning the
transactions when the parent transaction is dropped from the mempool, which can cause wallet
balances to appear higher. (wallet: track mempool conflicts with wallet transactions bitcoin/bitcoin#27307)
A new
max_tx_weightoption has been added to the RPCsfundrawtransaction,walletcreatefundedpsbt, andsend.It specifies the maximum transaction weight. If the limit is exceeded during funding, the transaction will not be built.
The default value is 4,000,000 WU. (Wallet: Add
max_tx_weightto transaction funding options (take 2) bitcoin/bitcoin#29523)A new
createwalletdescriptorRPC allows users to add new automatically generateddescriptors to their wallet. This can be used to upgrade wallets created prior to the
introduction of a new standard descriptor, such as taproot. (wallet: Add
createwalletdescriptorandgethdkeysRPCs for adding new automatically generated descriptors bitcoin/bitcoin#29130)A new RPC
gethdkeyslists all of the BIP32 HD keys in use by all of the descriptors in the wallet.These keys can be used in conjunction with
createwalletdescriptorto create and add single keydescriptors to the wallet for a particular key that the wallet already knows. (wallet: Add
createwalletdescriptorandgethdkeysRPCs for adding new automatically generated descriptors bitcoin/bitcoin#29130)The
sendallRPC can now spend unconfirmed change and will include additional fees as necessaryfor the resulting transaction to bump the unconfirmed transactions' feerates to the specified feerate. (wallet, rpc: document and update
sendallbehavior around unconfirmed inputs bitcoin/bitcoin#28979)In RPC
bumpfee, if afee_rateis specified, the feerate is no longer restrictedto following the wallet's incremental feerate of 5 sat/vb. The feerate must still be
at least the sum of the original fee and the mempool's incremental feerate. (bumpfee: ignore WALLET_INCREMENTAL_RELAY_FEE when user specifies fee_rate bitcoin/bitcoin#27969)
GUI Changes
The "Migrate Wallet" menu allows users to migrate any legacy wallet in their wallet
directory, regardless of the wallets loaded. (gui#824)
The "Information" window now displays the maximum mempool size along with the
mempool usage. (gui#825)
Low-level Changes
Tests
The BIP94 timewarp attack mitigation is now active on the
regtestnetwork. (Have miner account for timewarp mitigation, activate on regtest, lower nPowTargetTimespan to 144 and add test bitcoin/bitcoin#30681)A new
-testdatadiroption has been added totest_bitcointo allow specifying thelocation of unit test data directories. (test: test_bitcoin: allow -testdatadir=<datadir> bitcoin/bitcoin#26564)
Blockstorage
Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key.
Refer to the
-blocksxorhelp for more details. (blockstorage: XOR blocksdir *.dat files bitcoin/bitcoin#28052)Chainstate
empty the database cache. The cache will remain populated longer, which significantly
reduces the time for initial block download to complete. (Don't empty dbcache on prune flushes: >30% faster IBD bitcoin/bitcoin#28280)
Dependencies
Builders will no longer need Boost.Process to build with external signer support. (Replace Boost.Process with cpp-subprocess bitcoin/bitcoin#28981)