| Age | Commit message (Collapse) | Author |
|---|
|
fa9af218780b7960d756db80c57222e5bf2137b1 scripted-diff: Use getInt<T> over get_int/get_int64 (MacroFake)
Pull request description:
Seems better to see the return type directly and be able to modify it easier, as the return type is used for exceptions (in-range checking and parsing feedback).
ACKs for top commit:
fanquake:
ACK fa9af218780b7960d756db80c57222e5bf2137b1
Tree-SHA512: 284aa2527d0f663ca01550115025c9c64c787531d595f866c718f6ad09b9b0cac1e683a7d77f8009b75de990fd37166b44063ffa83fba8a04e9a31600b4c2725
|
|
indexing
7171ebc7cbd911fa7ccad732ea7f73bce30928ee index: Don't commit a best block before indexing it during sync (Martin Zumsande)
Pull request description:
This changes the periodic commit of the best block during the index sync phase to use the already indexed predecessor of the current block index, instead of committing the current one that will only be indexed (by calling `WriteBlock()`) after committing the best block.
The previous code would leave the index database in an inconsistent state until the block is actually indexed - if an unclean shutdown happened at just this point in time, the index could get corrupted because at next startup, we'd assume that we have already indexed this block.
ACKs for top commit:
ryanofsky:
Code review ACK 7171ebc7cbd911fa7ccad732ea7f73bce30928ee. Looks great! Just commit message changes since last review
Tree-SHA512: a008de511dd6a1731b7fdf6a90add48d1e53f7f7d6402672adb83e362677fc5b9f5cd021d3111728cb41d73f1b9c2140db79d7e183df0ab359cda8c01b0ef928
|
|
Committing a block prior to indexing would leave the index database
in an inconsistent state until it is indexed, which could corrupt the
index in case of a unclean shutdown. Thus commit its predecessor.
Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
|
|
support for v1 compact blocks)
bf6526f4a0ab30f77952ecdee90cd77dd9ba06f6 [test] Remove segwit argument from build_block_on_tip() (John Newbery)
c65bf50b44a38bc55224d8967e0df7af60ea4f1b Remove fUseWTXID parameter from CBlockHeaderAndShortTxIDs constructor (John Newbery)
Pull request description:
This implements two of the suggestions from code reviews of PR 20799:
- Remove fUseWTXID parameter from CBlockHeaderAndShortTxIDs constructor
- Remove segwit argument from build_block_on_tip()
ACKs for top commit:
dergoegge:
Code review ACK bf6526f4a0ab30f77952ecdee90cd77dd9ba06f6
naumenkogs:
ACK bf6526f4a0ab30f77952ecdee90cd77dd9ba06f6
Tree-SHA512: d553791d1364b9e655183755e829b195c9b47f59c62371dbae49d9c0f8d84fec58cf18f4dde89591672ef5658e18c9cf0206c2efd70606980f87e506bc3bd4e5
|
|
inbound block-relay-only connections
9db82f1bca0bb51c2180ca4a4ad63ba490e79da4 [net processing] Don't initialize TxRelay for non-tx-relay peers. (John Newbery)
b0a4ac9c26f60fd4993d89f45cafffaa389db2d4 [net processing] Add m_tx_relay_mutex to protect m_tx_relay ptr (John Newbery)
290a8dab0288344fa5731ec2ffd09478e9420a2f [net processing] Comment all TxRelay members (John Newbery)
42e3250497b03478d61cd6bfe6cd904de73d57b1 [net processing] [refactor] Move m_next_send_feefilter and m_fee_filter_sent (John Newbery)
Pull request description:
block-relay-only connections are additional outbound connections that bitcoind makes since v0.19. They participate in block relay, but do not propagate transactions or addresses. They were introduced in #15759.
When creating an outbound block-relay-only connection, since we know that we're never going to announce transactions over that connection, we can save on memory usage by not a `TxRelay` data structure for that connection. When receiving an inbound connection, we don't know whether the connection was opened by the peer as block-relay-only or not, and therefore we always construct a `TxRelay` data structure for inbound connections.
However, it is possible to tell whether an inbound connection will ever request that we start announcing transactions to it. The `fRelay` field in the `version` message may be set to `0` to indicate that the peer does not wish to receive transaction announcements. The peer may later request that we start announcing transactions to it by sending a `filterload` or `filterclear` message, **but only if we have offered `NODE_BLOOM` services to that peer**. `NODE_BLOOM` services are disabled by default, and it has been recommended for some time that users not enable `NODE_BLOOM` services on public connections, for privacy and anti-DoS reasons.
Therefore, if we have not offered `NODE_BLOOM` to the peer _and_ it has set `fRelay` to `0`, then we know that it will never request transaction announcements, and that we can save resources by not initializing the `TxRelay` data structure.
ACKs for top commit:
MarcoFalke:
review ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4 🖖
dergoegge:
Code review ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4
naumenkogs:
ACK 9db82f1bca0bb51c2180ca4a4ad63ba490e79da4
Tree-SHA512: 83a449a56cd6bf6ad05369f5ab91516e51b8c471c07ae38c886d51461e942d492ca34ae63d329c46e56d96d0baf59a3e34233e4289868f911db3b567072bdc41
|
|
a runtime flag
b953ea6cc691ba61bf08eb186e76e7e8b7ba8120 rpc: Put undocumented JSON failure mode behind a runtime flag (Suhail Saqan)
Pull request description:
Fixes #24695 (Put undocumented JSON failure mode behind a runtime flag)
ACKs for top commit:
luke-jr:
utACK b953ea6cc691ba61bf08eb186e76e7e8b7ba8120
vincenzopalazzo:
ACK https://github.com/bitcoin/bitcoin/pull/25161/commits/b953ea6cc691ba61bf08eb186e76e7e8b7ba8120
Tree-SHA512: 2005ee1b1f3b637918390b2ecd4166f2fd8c86e3c59fba3da8a0cbd5b1dffd03190c92f6dca3c489ecce4276eaf3108b2edcf9cd6224b713adb52f5bb848163b
|
|
rpc: Put undocumented JSON failure mode behind a runtime flag
|
|
ac6fbf2c83578129a0397d0d0dc9b1c6bdb30701 tidy: use modernize-use-default-member-init (fanquake)
7aa40f55636be565441a9e0af8de0a346bfa4da2 refactor: use C++11 default initializers (fanquake)
Pull request description:
Refactor and then enable [`modernize-use-default-member-init`](https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-default-member-init.html) in our `clang-tidy` job.
Top commit has no ACKs.
Tree-SHA512: 536b406f20639f8c588fe9e96175ec60c7bb825506b2670b562370b2f572801c24203c483443be3c199e1b958c0765d4532e57c57a4e78689162a1dd422d844f
|
|
-BEGIN VERIFY SCRIPT-
sed -i 's|\<get_int64\>|getInt<int64_t>|g' $(git grep -l get_int ':(exclude)src/univalue')
sed -i 's|\<get_int\>|getInt<int>|g' $(git grep -l get_int ':(exclude)src/univalue')
-END VERIFY SCRIPT-
|
|
Delay initializing the TxRelay data structure for a peer until we receive
a version message from that peer. At that point we'll know whether it
will ever relay transactions. We only initialize the m_tx_relay
data structure if:
- this isn't an outbound block-relay-only connection; AND
- fRelay=true OR we're offering NODE_BLOOM to this peer
(NODE_BLOOM means that the peer may turn on tx relay later)
|
|
|
|
This fully comments all the TxRelay members. The only significant change
is to the comment for m_relay_txs. Previously the comment stated that
one of the purposes of the field was that "We don't relay tx invs before
receiving the peer's version message". However, even without the
m_relay_txs flag, we would not send transactions to the peer before
receiving the `version` message, since SendMessages() returns
immediately if fSuccessfullyConnected is not set to true, which only
happens once a `version` and `verack` message have been received.
|
|
Move m_next_send_feefilter and m_fee_filter_sent out of the `TxRelay`
data structure. All of the other members of `TxRelay` are related to
sending transactions _to_ the peer, whereas m_fee_filter_sent and
m_next_send_feefilter are both related to receiving transactions _from_
the peer. A node's tx relay behaviour is not always symmetrical (eg a
blocksonly node will ignore incoming transactions, but may still send
out its own transactions), so it doesn't make sense to group the
feefilter sending data with the TxRelay data in a single structure.
This does not change behaviour, since IsBlockOnlyConn() is always equal
to !peer.m_tx_relay. We still don't send feefilter messages to outbound
block-relay-only peers (tested in p2p_feefilter.py).
|
|
time durations
3a998d2e37bf76667b08cd947807ada1305520d7 Use steady_clock in ConnectAndCallRPC and inline time call in loop conditional (Jon Atack)
3799d2dcdd736dd24850b192e1b264bee1cd5e5a Fix -rpcwait with -netinfo printing negative time durations (Jon Atack)
Pull request description:
- Fix `bitcoin-cli -rpcwait -netinfo 1` returning negative time durations on its first invocation after node startup in the "send", "recv", and "age" columns (potentially the "txn" and "blk" columns also). To reproduce, start bitcoind on mainnet (for a longer startup time) and run `bitcoin-cli -rpcwait -netinfo <n>` where n is 1 or larger. The negative time durations are larger with a slower CPU speed or e.g. higher `checkblocks`/`checklevel` config option settings.
Examples:
```
<-> type net mping ping send recv txn blk hb addrp addrl age id
out manual onion -126 -126 -2 0
ms ms sec sec min min min
```
```
<-> type net mping ping send recv txn blk hb addrp addrl age id
out manual cjdns -64 -64 -1 0
ms ms sec sec min min min
```
```
<-> type net mping ping send recv txn blk hb addrp addrl age id
out manual ipv4 -89 -89 * . -1 0
ms ms sec sec min min min
```
```
<-> type net mping ping send recv txn blk hb addrp addrl age id
out manual ipv6 -133 * . -2 0
ms ms sec sec min min min
```
- Use `steady_clock` in ConnectAndCallRPC and inline the time call in the loop conditional to avoid unnecessary invocations and an unneeded local variable allocation.
ACKs for top commit:
MarcoFalke:
cr ACK 3a998d2e37bf76667b08cd947807ada1305520d7
Tree-SHA512: 141430d47189ad9f646ce8e51cb31c21b395f6294bb27ba9f7ae4c1e1505a63209a4a19662a0b462806437a9cfd07f1ea114e775adc2872d87397fe823f8b8dc
|
|
from non-test/benchmarking code
a55db4ea1cf10e0ab4a6eb5cd1dd3bd95626fba0 Add more proper thread safety annotations (Hennadii Stepanov)
8cfe93e3fcf263bf059f738d5e7d9c94901a7c5a Add proper thread safety annotation to `CWallet::GetTxConflicts()` (Hennadii Stepanov)
ca446f2c59720c1575aeeab9c9d636d98ce8528c Add proper thread safety annotation to `CachedTxGetAvailableCredit()` (Hennadii Stepanov)
Pull request description:
In non-test/benchmarking code, there are three cases of the `NO_THREAD_SAFETY_ANALYSIS` annotation which are accompanied with `TODO` comments.
This PR adds proper thread safety annotations instead of `NO_THREAD_SAFETY_ANALYSIS`.
ACKs for top commit:
laanwj:
Code review ACK a55db4ea1cf10e0ab4a6eb5cd1dd3bd95626fba0
Tree-SHA512: 806d72eebc1edf088bfa435c8cd11465be0de6789798dd92abd008425516768acb864a73d834a49d412bb10f7fccfb47473f998cb72739dab6caeef6bcfaf191
|
|
|
|
|
|
ada8358ef54aaa04c9182afe115d8046c801bdde Sanitize port in `addpeeraddress()` (amadeuszpawlik)
Pull request description:
In connection to #22087, it has been [pointed out](https://github.com/bitcoin/bitcoin/pull/22087#pullrequestreview-674786285) that `addpeeraddress` needs to get its port-value sanitized.
ACKs for top commit:
fanquake:
ACK ada8358ef54aaa04c9182afe115d8046c801bdde
Tree-SHA512: 48771cd4f6940aa7840fa23488565c09dea86bd5ec5a5a1fc0374afb4857aebcd2a1f51e2d4cb7348460e0ad9793dc5d2962df457084ed2b8d8142cae650003f
|
|
`make check`
4f31c21b7f384e50e0af8275e831085d1d69b386 bench: Make all arguments -kebab-case (laanwj)
652b54e53220fedf2c342e428617bcbd2022964d bench: Add `--sanity-check` flag, use it in `make check` (laanwj)
Pull request description:
The benchmarks are run as part of `make check` for a crash-sanity check. The actual results are being ignored. So only run them for one iteration.
This makes the `bench_bitcoin` part take 2m00 instead of 5m20 here. Which is still too long (imo), but this needs to be solved in the `WalletLoading*` benchmarks which take that long per iteration.
Also change all `bench_bitcoin` arguments to kebab-case to be consistent with the other tools (in a separate commit).
ACKs for top commit:
jonatack:
ACK 4f31c21b7f384e50e0af8275e831085d1d69b386 on the sanity-check version per `git diff c52a71e 4f31c28` (modulo s/--sanity check/--sanity-check/ in src/bench/bench.cpp::L61)
hebasto:
ACK 4f31c21b7f384e50e0af8275e831085d1d69b386, tested on Ubuntu 22.04.
Tree-SHA512: 2661d130fd82e57c9041755190997a4af588fadddcdd05e04fd024f75da1202480e9feab5764566e8dfe7930e8ae0ec71e93f40ac373274953d274072723980d
|
|
to avoid unnecessary invocations and an unneeded local variable allocation.
|
|
Fixes negative time duration values in the "send", "recv",
and "age" columns (potentially the "txn" and "blk" columns also)
for the first run of -rpcwait -netinfo after bitcoind startup.
To reproduce, start bitcoind on mainnet and run
`bitcoin-cli -rpcwait -netinfo <n>` where n is 1 or larger.
The negative times will be larger/more apparent with a slower
CPU speed or e.g. higher checkblocks/checklevel config option
settings.
|
|
CreateTransaction() as optional struct
4c5ceb040cf50d24201903a9200fb23be88d96fb wallet: CreateTransaction(): return out-params as (optional) struct (Sebastian Falbesoner)
c9fdaa5e3ae09b45be6a5c2d4ee6b1e8cef9d8a8 wallet: CreateTransactionInternal(): return out-params as (optional) struct (Sebastian Falbesoner)
Pull request description:
The method `CWallet::CreateTransaction` currently returns several values in the form of out-parameters:
* the actual newly created transaction (`CTransactionRef& tx`)
* its required fee (`CAmount& nFeeRate`)
* the position of the change output (`int& nChangePosInOut`) -- as the name suggests, this is both an in- and out-param
By returning these values in an optional structure (which returns no value a.k.a. `std::nullopt` if an error occured), the interfaces is shorter, cleaner (requested change position is now in-param and can be passed by value) and callers don't have to create dummy variables for results that they are not interested in.
Note that the names of the replaced out-variables were kept in `CreateTransactionInternal` to keep the diff minimal. Also, the fee calculation data (`FeeCalculation& fee_calc_out`) would be another candidate to put into the structure, but `FeeCalculation` is currently an opaque data type in the wallet interface and I think it should stay that way.
As a potential follow-up, I think it would make sense to also do the same refactoring for `CWallet::FundTransaction`, which has a very similar parameter structure.
Suggested by laanwj in https://github.com/bitcoin/bitcoin/pull/20588#issuecomment-739838428.
ACKs for top commit:
achow101:
re-ACK 4c5ceb040cf50d24201903a9200fb23be88d96fb
Xekyo:
ACK 4c5ceb040cf50d24201903a9200fb23be88d96fb
w0xlt:
crACK https://github.com/bitcoin/bitcoin/pull/20640/commits/4c5ceb040cf50d24201903a9200fb23be88d96fb
Tree-SHA512: 27e5348bbf4f698713002d40c834dcda59c711c93207113e14522fc6d9ae7f4d8edf1ef6d214c5dd62bb52943d342878960ca333728828bf39b645a27d55d524
|
|
All uses of CBlockHeaderAndShortTxIDs in the product code are
constructed with fUseWTXID=true, so remove the parameter.
There is one use of the CBlockHeaderAndShortTxIDs constructor with
fUseWTXID=false in the unit tests. This is used to construct a
CBlockHeaderAndShortTxIDs for a block with only the coinbase
transaction, so setting fUseWTXID to true or false makes no difference.
Suggested in https://github.com/bitcoin/bitcoin/pull/20799#pullrequestreview-963480278
|
|
This is customary for UNIX-style arguments, and more consistent with our
other tools
|
|
The benchmarks are run as part of `make check` for a minimum sanity
check. The actual results are being ignored. So only run them for one
iteration.
This makes the `bench_bitcoin` part take 2m00 instead of 5m20 here.
Which is still too long (imo), but this needs to be solved in the
`WalletLoading*` benchmarks which take that long per iteration.
|
|
`m_most_recent_block_mutex` with Mutex
83003ffe049a432f6fa4127e054f073127e70b90 refactor: replace RecursiveMutex `m_most_recent_block_mutex` with Mutex (Sebastian Falbesoner)
8edd0d31ac683378135a9839e5d4172b82f8f5b8 refactor: reduce scope of lock `m_most_recent_block_mutex` (Sebastian Falbesoner)
Pull request description:
This PR is related to #19303 and gets rid of the RecursiveMutex `m_most_recent_block_mutex`. All of the critical sections (5 in total) only directly access the guarded elements, i.e. it is not possible that within one section another one is called, and we can use a regular Mutex:
https://github.com/bitcoin/bitcoin/blob/b019cdc036343a437fd7ced85467bd95f48d84c4/src/net_processing.cpp#L1650-L1655
https://github.com/bitcoin/bitcoin/blob/b019cdc036343a437fd7ced85467bd95f48d84c4/src/net_processing.cpp#L1861-L1865
https://github.com/bitcoin/bitcoin/blob/b019cdc036343a437fd7ced85467bd95f48d84c4/src/net_processing.cpp#L3149-L3152
https://github.com/bitcoin/bitcoin/blob/b019cdc036343a437fd7ced85467bd95f48d84c4/src/net_processing.cpp#L3201-L3206
https://github.com/bitcoin/bitcoin/blob/b019cdc036343a437fd7ced85467bd95f48d84c4/src/net_processing.cpp#L4763-L4769
The scope of the last critical section is reduced in the first commit, in order to avoid calling the non-trivial method `CConnman::PushMessage` while the lock is held.
ACKs for top commit:
furszy:
Code ACK 83003ffe with a small comment.
hebasto:
ACK 83003ffe049a432f6fa4127e054f073127e70b90
w0xlt:
ACK https://github.com/bitcoin/bitcoin/pull/24062/commits/83003ffe049a432f6fa4127e054f073127e70b90
Tree-SHA512: 3df290cafd2f6c4d40afb9f14e822a77d9c1828e66f5e2233f3ac1deccc2b0a8290bc5fb8eb992f49d39e887b50bc0e9aad63e05db2d870791a8d409fb95695f
|
|
getblockchaininfo
a01b92ad8672dcf4369ee9cf36a6b0157d73786c doc: add release notes about removal of the `deprecatedrpc=softforks` flag (Sebastian Falbesoner)
8c5533c7a953e79b423b465905dbfaa45ad60a49 rpc: remove deprecated "softforks" field from getblockchaininfo (Sebastian Falbesoner)
Pull request description:
Information on soft fork status has been moved from the `getblockchaininfo` RPC to the `getdeploymentinfo` RPC in #23508. The "softfork" result in `getblockchaininfo` was still available for 23.0 with the `-deprecatedrpc=softforks` configuration option, but this can be fully removed now for the next release (24.0).
ACKs for top commit:
shaavan:
ACK a01b92ad8672dcf4369ee9cf36a6b0157d73786c
ajtowns:
ACK a01b92ad8672dcf4369ee9cf36a6b0157d73786c
Tree-SHA512: 692d9d02fdf0b3c18376644a85b24b57efebf612738084c01ef47d47e41861e773688613a808e81f10ab6eec340de00eef96987a1e34d612aaf7f0a0b134d89e
|
|
ExternalSigner::SignTransaction
2a22f034ca3298c9f86d1edd4283a0bea18dfbbe parsing external signer master fingerprint string as bytes instead of caring for lower/upper case in ExternalSigner::SignTransaction (avirgovi)
Pull request description:
Some external signers scripts may provide master fingerprint in uppercase format. In that case core will fail with `Signer fingerprint 00000000 does not match any of the inputs` as it only works with lowercase format. Even if the fingerprints match, yet one is lowercase the other uppercase.
ExternalSigner::SignTransaction is the only place where it is needed IMO, as changing it in other places may break the communication with the external signer (i.e. enumerating with lowercase may not find the device).
ACKs for top commit:
achow101:
ACK 2a22f034ca3298c9f86d1edd4283a0bea18dfbbe
theStack:
Code-review ACK 2a22f034ca3298c9f86d1edd4283a0bea18dfbbe
Sjors:
utACK 2a22f034ca3298c9f86d1edd4283a0bea18dfbbe
Tree-SHA512: f3d84b83fb0b5e06c405eaf9bf20a2fa864bf4172fd4de113b80b9b9a525a76f2f8cf63031b480358b3a7666023a2aef131fb89ff50448c66df3ed541da10f99
|
|
registering for signals
ba10b90915dae6a802ecb0f80f72a1a9ea5a4c67 Wallet: Ensure m_attaching_chain is set before registering for signals (Luke Dashjr)
Pull request description:
Avoids a race where chainStateFlushed could be called before rescanning began, yet rescan gets interrupted or fails
Followup for #24984 avoiding a race between registering and setting the flag.
ACKs for top commit:
mzumsande:
Code Review ACK ba10b90915dae6a802ecb0f80f72a1a9ea5a4c67
achow101:
ACK ba10b90915dae6a802ecb0f80f72a1a9ea5a4c67
Tree-SHA512: 1d2fa2db189d3e87f2d0863cf2ab62166094436483f0da16760b1083a4743bf08e476a3277e0d36564213d65dd6f0a1fc16a4bf68d3338c991a14d1de9fc0fee
|
|
|
|
|
|
|
|
performance
f336ff7f213564909cf5f9742618cc6ec87600fd rpc: avoid expensive `IsMine` calls in `GetReceived` tally (Sebastian Falbesoner)
a7b65af2a4450663d4a20a617c59dac87b34fb36 rpc: avoid scriptPubKey<->CTxDestination conversions in `GetReceived` tally (Sebastian Falbesoner)
Pull request description:
The RPC calls `getreceivedbyaddress`/`getreceivedbylabel` both use the internal helper function `GetReceived` which was introduced in PR #17579 to deduplicate tallying code. For every wallet-related transaction output, the following unnecessary operations are currently performed in the tally loop, leading to a quite bad performance (as reported in #23645):
- converting from CScript -> TxDestination (`ExtractDestination(...)`), converting from TxDestination -> CScript (`CWallet::IsMine(const CTxDestination& dest)`); this can be avoided by directly using output scripts in the search set instead of addresses (first commit)
- checking if the iterated output script belongs to the wallet by calling `IsMine`; this can be avoided by only adding addresses to the search set which fulfil `IsMine` in the first place (second commit)
### Benchmark results
The functional test [wallet_pr23662.py](https://github.com/theStack/bitcoin/blob/pr23662_benchmarks/test/functional/wallet_pr23662.py) (not part of this PR) creates transactions with 15000 different addresses:
- 5000 outputs (500 txs with 10 outputs each) with label set, IsMine set (received)
- 5000 outputs (500 txs with 10 outputs each) with label set, IsMine not set (sent)
- 5000 outputs (500 txs with 10 outputs each) without label set, IsMine not set (sent)
Then, the time is measured for calling `getreceivedbyaddress` and `getreceivedbylabel`, the latter with two variants. Results on my machine:
| branch | `getreceivedbyaddress` (single) | `getreceivedbylabel` (single) | `getreceivedbylabel` (10000) |
|--------------------|---------------------------------|-------------------------------|------------------------------|
| master | 406.13ms | 425.33ms | 446.58ms |
| PR (first commit) | 367.18ms | 365.81ms | 426.33ms |
| PR (second commit) | 3.96ms | 4.83ms | 339.69ms |
Fixes #23645.
ACKs for top commit:
achow101:
ACK f336ff7f213564909cf5f9742618cc6ec87600fd
w0xlt:
ACK https://github.com/bitcoin/bitcoin/pull/23662/commits/f336ff7f213564909cf5f9742618cc6ec87600fd
furszy:
Code ACK f336ff7f
Tree-SHA512: 9cbf402b9e269713bd3feda9e31719d9dca8a0dfd526de12fd3d561711589195d0c50143432c65dae279c4eab90a4fc3f99e29fbc0452fefe05113e92d129b8f
|
|
|
|
|
|
11e79084845a78e2421ea3abafe0de5a54ca2bde prevector: only allow trivially copyable types (Martin Leitner-Ankerl)
Pull request description:
prevector uses `memmove` to move around data, that means it can only be used with types that are trivially copyable. That implies that the types are trivially destructible, thus the checks for `is_trivially_destructible` are not needed.
ACKs for top commit:
w0xlt:
ACK https://github.com/bitcoin/bitcoin/pull/24962/commits/11e79084845a78e2421ea3abafe0de5a54ca2bde
MarcoFalke:
review ACK 11e79084845a78e2421ea3abafe0de5a54ca2bde 🏯
ajtowns:
ACK 11e79084845a78e2421ea3abafe0de5a54ca2bde -- code review only
Tree-SHA512: cbb4d8bfa095100677874b552d92c324c7d6354fcf7adab2ed52f57bd1793762871798b5288064ed1af2d2903a0ec9dbfec48d99955fc428f18cc28d6840dccc
|
|
fae3200bbf2a0f4482ec6f5f2ada9534f6c82709 test: Slim down versionbits_tests.cpp (MacroFake)
Pull request description:
Seems confusing to spin up a full chainman that isn't even used.
Fix that by only spinning up logging. Also, remove the chainman include and comment.
ACKs for top commit:
fanquake:
ACK fae3200bbf2a0f4482ec6f5f2ada9534f6c82709
Tree-SHA512: 35261e9116c0c276f807453db3d635d83916ec2ffd99cf5641f8732736a30a542213096dcec550ef4522d97b3cafe384fdc6068138bc0b577c66fa61256719f8
|
|
In each of the critical sections, only the the guarded variables are
accessed, without any chance that within one section another one is
called. Hence, we can use an ordinary Mutex instead of RecursiveMutex.
|
|
fa347a906685df1d44cafa3e6cc7fdd2ace68ff5 rpc: Fix implicit-integer-sign-change in gettxout (MacroFake)
Pull request description:
ACKs for top commit:
theStack:
Code-review ACK fa347a906685df1d44cafa3e6cc7fdd2ace68ff5
Tree-SHA512: 2a1128f714119b6b6cfeb20ee59c4f46404d5a83942253c73de64b0289a7d41e4437cf77d19b1cf623e2dd15fbaa1ec7acd03cc5d6dde41b3c7d06a082073ea1
|
|
This avoids calling the non-trivial method
`CConnman::PushMessage` within the critical section.
|
|
436ce0233c276e263dcb441255dc0b881cb39cfb sync.h: strengthen AssertLockNotHeld assertion (Anthony Towns)
7d73f58e9cea8f4b0bc16512983898fddde3d764 Increase threadsafety annotation coverage (Anthony Towns)
Pull request description:
This changes `AssertLockNotHeld` so that it is annotated with the negative capability for the mutex it refers to. clang applies negative capabilities recursively, so this helps avoid forgetting to annotate functions.
Note that this can't reasonably be used for globals, because clang would require every function to be annotated with `EXCLUSIVE_LOCKS_REQUIRED(!g_mutex)` for each global mutex. At present, the only global mutexes that use `AssertLockNotHeld` are `RecursiveMutex` so we treat that as an exception in order to avoid having to add an excessive number of negative annotations.
ACKs for top commit:
vasild:
ACK 436ce0233c276e263dcb441255dc0b881cb39cfb
MarcoFalke:
review ACK 436ce0233c276e263dcb441255dc0b881cb39cfb 🌺
Tree-SHA512: 5f16d098790a36b5277324d5ee89cdc87033c19b11c7943c2f630a41c2e3998eb39d356a763e857f4d8fefb6c0c02291f720bb6769bcbdf5e2cd765bf266ab8c
|
|
blocks
a50e34c367608fcec9697893981bfa294a7c08d1 [net processing] Remove redundant nodestate->m_sendcmpct check in MaybeSetPeerAsAnnouncingHeaderAndIDs() (John Newbery)
bb985a7b6abee503852c61eec74ca3a29f582815 [net processing] Only relay blocks by cmpctblock and cache for fast relay if segwit is enabled (John Newbery)
3b6bfbce386f61dcbb366f08cfff55c3882f429c [net processing] Rename CNodeState compact block members (John Newbery)
d0e97741748aaaad2a89ca42e4898e7f01308b35 [net processing] Tidy up `sendcmpct` processing (John Newbery)
30c3a01874cf51d987a0ae2bb699bf50d82768ff [net processing] fPreferHeaderAndIDs implies fProvidesHeaderAndIDs (John Newbery)
b486f721767d07c1e2eaf8deaf96b732b0a858dd [net processing] Remove fWantsCmpctWitness (John Newbery)
a45d53cab556505048c387429fd07188e4c40c3d [net processing] Remove fSupportsDesiredCmpctVersion (John Newbery)
25edb2b7bd4c41156fba09d0033a978e362435af [net processing] Simplify `sendcmpct` processing (John Newbery)
42882fc8fc2ef5c58eb963f7f1e852dd43de6c65 [net processing] Only accept `sendcmpct` with version=2 (John Newbery)
16730b64bb4a11995d792f626c8a63318e5eaeeb [net processing] Only advertise support for version 2 compact blocks (John Newbery)
cba909eaf938a775a9bd2dd994d06aba175e8713 [net] Stop testing version 1 compact blocks. (John Newbery)
Pull request description:
Compact blocks are used for efficient relay of blocks, either through High Bandwidth or Low Bandwidth mode. See [BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) for full details.
For compact block relay to work, the receiver must have a mempool containing transactions which are likely to be included in the block. The receiver uses these transactions to reconstruct the block from the short transaction ids included in the `cmpctblock` message. Compact blocks are therefore only useful for relaying blocks at or near the tip of the block chain. For older blocks, the recipient won't have the transactions in their mempool and so would need to request them using a `getblocktxn` message. In such cases, just requesting the full block is more efficient.
BIP 152 supports two versions: version 1 (without witnesses) and version 2 (with witnesses). Version 2 is required to reconstruct segwit blocks. Segwit was activated in August 2017, and providing non-witness blocks to peers is no longer useful. Since the witnesses are not included, the peer would not be able to fully validate all the consensus rules on the provided block.
Therefore, stop supporting version 1 compact blocks. Ignore `sendcmpct` messages with version=1, and don't advertise support by sending `sendcmpct` with version=1. Only send `sendcmpct` to peers with `NODE_WITNESS`. Respond to all requests for compact blocks or blocktxns with witness-serialized blocks and transactions.
ACKs for top commit:
dergoegge:
ACK a50e34c367608fcec9697893981bfa294a7c08d1 - Only changes since my last review were a rebase and some nits.
MarcoFalke:
re-ACK a50e34c367608fcec9697893981bfa294a7c08d after rebase 👓
Tree-SHA512: 8ad73acaa374d56ee9f28ca0a9d64b8630793d22fc8c942a1ee15551d4d80f76f3ba937682f85f22ec8ca82efae98a92de75a7e2f5a97499d8f9c7e4f2833c86
|
|
getblockchaininfo's pruneheight result
06822f86545a0e946fdc266c57955f98d163a8bc Bugfix: RPC/blockchain: Correct description of getblockchaininfo's pruneheight result (Luke Dashjr)
Pull request description:
It is possible that lower blocks are complete due to being stored in the same file as blocks not yet eligible for pruning.
Not really satisfied with this new description, so suggestions for better phasing welcome :)
(Split out of #24629)
ACKs for top commit:
theStack:
Code-review ACK 06822f86545a0e946fdc266c57955f98d163a8bc
Tree-SHA512: 755a5a40d065ad77f4ac2c19c0b3502eceb3162034823ee7ce1668100d97e8a2bfb822ac381feb7afd13e653cd08a81d5fa505575531757457d6d22c909a6510
|
|
a class, drop unused forward declarations
ca1ac1f0e0fbabbe97666aca94024afb8104da06 scripted-diff: Rename MainSignalsInstance() class to MainSignalsImpl() (Jon Atack)
2aaec2352d14753e1f2d4bf4b11bbe6ad42edf5c refactor: remove unused forward declarations in validationinterface.h (Jon Atack)
23854f84024c292164ce49b3fefee2a9b4fe0831 refactor: make MainSignalsInstance() a class (Jon Atack)
Pull request description:
Make MainSignalsInstance a class, rename it to MainSignalsImpl, use Doxygen documentation for it, and remove no longer used forward declarations in src/validationinterface.h.
----
MainSignalsInstance was created in 3a19fed9db5 and originally was a collection of boost::signals methods moved to validationinterface.cpp, in order to no longer need to include boost/signals in validationinterface.h.
MainSignalsInstance then evolved in d6815a23131 to become class-like:
- [C.8: Use class rather than struct if any member is non-public](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-class)
- [C.2: Use class if the class has an invariant; use struct if the data members can vary independently](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c2-use-class-if-the-class-has-an-invariant-use-struct-if-the-data-members-can-vary-independently)
- A class has the advantage of default private access, as opposed to public for a struct.
ACKs for top commit:
furszy:
Code ACK ca1ac1f
promag:
Code review ACK ca1ac1f0e0fbabbe97666aca94024afb8104da06.
danielabrozzoni:
Code review ACK ca1ac1f0e0fbabbe97666aca94024afb8104da06
Tree-SHA512: 25f85e2b582fe8c269e6cf384a4aa29350b97ea6477edf3c63591e4f68a97364f7fb2fc4ad2764f61ff86b27353e31d2f12eed7a23368a247e4cf271c7e133ea
|
|
MaybeSetPeerAsAnnouncingHeaderAndIDs()
|
|
segwit is enabled
This introduces an early exit in PeerManagerImpl::NewPoWValidBlock() if
segwit has not been activated for the block. This means that we won't cache the
block/compact block for fast relay and won't relay the cmpctblock
immediately to peers that have requested hb compact blocks. This is fine
because any block where segwit is not yet activated is buried deep in
the chain, and so compact block relay will not be effective.
It's ok not to cache the block/compact block for fast relay for the same
reason - the block must be very deeply buried in the block chain.
ProcessBlockAvailability() also won't get called for all nodes. This is
also fine, since that function only updates hashLastUnknownBlock
and pindexBestKnownBlock, and is called early in every SendMessages()
call.
|
|
fPreferHeaderAndIDs -> m_requested_hb_cmpctblocks
fProvidesHeaderAndIDs -> m_provides_cmpctblocks
|
|
- use better local variable names
- drop unnecessary if statements
|
|
Remove all if(fProvidesHeaderAndIDs) conditionals inside
if(fPreferHeaderAndIDs) conditionals.
|
|
It is now completely redundant with fProvidesHeadersAndIDs.
|
