Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
If transactions are being added to the mempool at a rate faster than 7tx/s
(INVENTORY_BROADCAST_PER_SECOND) then peers' inventory_to_send queue can
become relatively large. If this happens, increase the number of txids
we include in an INV message (normally capped at 35) by 5 for each 1000
txids in the queue.
This will tend to clear a temporary excess out reasonably quickly; an
excess of 4000 invs to send will be cleared down to 1000 in about 30
minutes, while an excess of 20000 invs would be cleared down to 1000 in
about 60 minutes.
Github-Pull: #27610
Rebased-From: 5b3406094f2679dfb3763de4414257268565b943
|
|
We use CompareDepthAndScore to choose an order of txs to inv. Rather
than sorting txs that have been evicted from the mempool at the end
of the list, sort them at the beginning so they are removed from
the queue immediately.
Github-Pull: #27610
Rebased-From: 228e9201efb5574b1b96bb924de1d2e8dd1317f3
|
|
Github-Pull: #27608
Rebased-From: 52e52071e01f4e98d87a47e1d5f3c5c3cc6dbaf4
|
|
03a16a1da09f45721c799c719e48350dfe12ae88 doc: update release notes for 24.1rc2 (fanquake)
f344c66053f1f1c24c0dac3ecc9570bea5c7fa0a doc: update manual pages for v24.1rc2 (fanquake)
4451e899881f2ae6b46c13ff87618d45a6fa982f build: bump version to v24.1rc2 (fanquake)
Pull request description:
rc1 (tagged > a month ago) was mostly a no-op, due to lack of binaries. While some are up now, [albeit at the wrong URL](https://bitcoincore.org/bin/bitcoin-24.1rc1/), there seems no point continuing the rc1 cycle, when we already have additional changes backported (#27474), and we've also received no bug reports/feedback from anyone who did test.
So bump the version, and cut an rc2.
ACKs for top commit:
achow101:
ACK 03a16a1da09f45721c799c719e48350dfe12ae88
gruve-p:
ACK https://github.com/bitcoin/bitcoin/pull/27486/commits/03a16a1da09f45721c799c719e48350dfe12ae88
hebasto:
ACK 03a16a1da09f45721c799c719e48350dfe12ae88, I have reviewed the code and it looks OK.
Tree-SHA512: f49072149ecabb02b034b1c4d7319a80f93a8c7a29a2b7ec27dff0c257742d08d48fbf266399ce71769cec992902b7d53fc26bb5ffc8681728dc8685cbba25d9
|
|
|
|
|
|
|
|
dc711fbd32653b09e196f72942106114a32353f4 doc: update 24.1 release notes (fanquake)
fc8c1a8deb80913ff353c878f494c9eaf28061c0 doc: fix/improve warning helps in {create,load,unload,restore}wallet (Jon Atack)
3a26b19df25ca99a9a58ae5398f6f423ac074368 bugfix: rest: avoid segfault for invalid URI (pablomartin4btc)
c40b1da2fd64bb10f120f85966b44f0d2bb315f8 depends: fix compiling bdb with clang-16 on aarch64 (fanquake)
0bac52d5cfaf1a3beb99b780ed7446e2faba877f Don't return OutputType::UNKNOWN in ParseOutputType (Pttn)
Pull request description:
Backports:
* https://github.com/bitcoin/bitcoin/pull/27279 (only f73782a9032a462a71569e9424db9bf9eeababf3)
* https://github.com/bitcoin/bitcoin/pull/27462
* https://github.com/bitcoin/bitcoin/pull/27468
* https://github.com/bitcoin/bitcoin/pull/27473
ACKs for top commit:
stickies-v:
ACK dc711fbd32653b09e196f72942106114a32353f4
hebasto:
re-ACK dc711fbd32653b09e196f72942106114a32353f4
jonatack:
ACK dc711fbd32653b09e196f72942106114a32353f4
Tree-SHA512: 72c673be82689e3c3a1c2564a1fdd6afe0b357b7aa8bec9524fe6999804fbccf310da0b074e647af14b753e5e695024e268fe4f69aa58747f541f7f429ebede6
|
|
|
|
- clarify that there can be multiple warning messages
- specify the correct wallet action
- describe the use of newlines as delimiters
Github-Pull: #27279
Rebased-From: f73782a9032a462a71569e9424db9bf9eeababf3
|
|
`evhttp_uri_parse` can return a nullptr, for example when the URI
contains invalid characters (e.g. "%").
`GetQueryParameterFromUri` passes the output of `evhttp_uri_parse`
straight into `evhttp_uri_get_query`, which means that anyone calling
a REST endpoint in which query parameters are used (e.g. `rest_headers`)
can cause a segfault.
This bugfix is designed to be minimal and without additional behaviour change.
Github-Pull: #27468
Rebased-From: 11422cc5720c8d73a87600de8fe8abb156db80dc
|
|
Compiling bdb with clang-16 on aarch64 (hardware) currently fails:
```bash
make -C depends/ bdb CC=clang CXX=clang++
...
checking for mutexes... UNIX/fcntl
configure: WARNING: NO SHARED LATCH IMPLEMENTATION FOUND FOR THIS PLATFORM.
configure: error: Unable to find a mutex implementation
```
Looking at config.log we've got:
```bash
configure:18704: checking for mutexes
configure:18815: clang -o conftest -pipe -std=c11 -O2 -Wno-error=implicit-function-declaration -Wno-error=format-security -I/bitcoin/depends/aarch64-unknown-linux-gnu/include -D_GNU_SOURCE -D_REENTRANT -L/bitcoin/depends/aarch64-unknown-linux-gnu/lib conftest.c -lpthread >&5
conftest.c:45:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
main() {
^
int
conftest.c:50:2: warning: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
exit (
^
conftest.c:50:2: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'
1 warning and 1 error generated.
```
Clang-16 changed `-Wimplicit-function-declaration` and `-Wimplicit-int`
warnings into errors, see:
https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#potentially-breaking-changes.
> The -Wimplicit-function-declaration and -Wimplicit-int warnings now
> default to an error in C99, C11, and C17. As of C2x, support for implicit
> function declarations and implicit int has been removed, and the
> warning options will have no effect. Specifying -Wimplicit-int in
> C89 mode will now issue warnings instead of being a noop.
Github-Pull: #27462
Rebased-From: f8b8458276983f8fc1e2a47c4d00c1e30633067d
|
|
Fixes https://github.com/bitcoin/bitcoin/issues/27472
Signed-off-by: Pttn <28868425+Pttn@users.noreply.github.com>
Github-Pull: #27473
Rebased-From: 0d6383fda04a99726654945a737bbb1369e0e44a
|
|
932a609312cb7b72bf5f23112763ab933a54389c doc: add initial release notes for v24.1 (fanquake)
cc4e3158c9e7840151fe7b6209ba5f7ea5f103c3 doc: update manual pages for v24.1rc1 (fanquake)
787affb9ea04651a682acf8d09342d6e843fdd0f doc: update version in bips.md to v24.1 (fanquake)
5077e02263cf47749583f22dc2bc609878d8290a build: bump version to v24.1rc1 (fanquake)
Pull request description:
Bump the version number to v24.1rc1.
Regenerate the man pages.
Update the version number in bips.md.
Move the v24.0.1 release notes to doc/release-notes.
Add initial release notes for v24.1.
Merged changes to the 24.x branch since v24.0.1:
- https://github.com/bitcoin/bitcoin/pull/26457
- https://github.com/bitcoin/bitcoin/pull/26735
- https://github.com/bitcoin/bitcoin/pull/26878
- https://github.com/bitcoin/bitcoin/pull/26880
ACKs for top commit:
achow101:
ACK 932a609312cb7b72bf5f23112763ab933a54389c
Tree-SHA512: b90fd7c8f22c8fb096864e47cb79eaf5878524739a3b5c1d495c8c196b70d08c7b95fbfb1dfcdddf507bd8a72a5d133ecbe6ae898bbe70931f404afd0807b707
|
|
a2f8a839d9b071f9c90ed5e3db2d30f90993992d qt: 24.1rc1 translations update (Hennadii Stepanov)
Pull request description:
This PR pulls the recent translations from the [Transifex.com](https://www.transifex.com/bitcoin/bitcoin) using the [`bitcoin-maintainer-tools/update-translations.py`](https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/main/update-translations.py) tool.
According to our [Release Process docs](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-release-candidate), it is supposed to be merged before `v24.1rc1` tagging (#27247).
Will keep this PR updated regularly until merging.
The Dutch translation `bitcoin_nl.ts` has been damaged, therefore its changes were rejected manually.
ACKs for top commit:
stickies-v:
I'm not familiar with the translations process and I couldn't verify that `bitcoin_nl.ts` is damaged, but if this constitutes sufficient review then ACK a2f8a839d9b071f9c90ed5e3db2d30f90993992d
Tree-SHA512: d914d158c4a4b62a2c37040f5cc0602ef749a7bf658af0e364a0d2cb52b802a00863496751cf3db42d74e8950c49969ee9dd03c5c3fee79860113389f36ee483
|
|
|
|
Move historical 24.0.1 to doc/release-notes.
|
|
|
|
|
|
|
|
784a754aa47ce10c6fd99c09cdfc76ee9bc91652 wallet, rpc: Update migratewallet help text for encrypted wallets (Andrew Chow)
debcfe313a22fddc2a6247c55f3c7893f6134c05 tests: Tests for migrating wallets by name, and providing passphrase (Andrew Chow)
ccc72fecd7287471bf8c3858a4e6c2ddadb64863 wallet: Be able to unlock the wallet for migration (Andrew Chow)
50dd8b13dfc070b550680617e76eff1c09af3a58 rpc: Allow users to specify wallet name for migratewallet (Andrew Chow)
648b06256da65b4513977e351aabf3e5c06ce060 wallet: Allow MigrateLegacyToDescriptor to take a wallet name (Andrew Chow)
ab3bd457cdb5c5ee2626081d703d675c2573f28a i2p: use consistent number of tunnels with i2pd and Java I2P (Vasil Dimov)
29cdf42226c0983076701552b351f08351dd54a5 i2p: lower the number of tunnels for transient sessions (Vasil Dimov)
5027e93b6a1e5a5c87b9450c60e2a4572eb32653 i2p: reuse created I2P sessions if not used (Vasil Dimov)
a62c541ae8a579d19b8fc55bbb922f0939ab6110 wallet: reuse change dest when recreating TX with avoidpartialspends (Matthew Zipkin)
64e7db6f4f256656f4d78a96b07e51f7d5c6d526 Zero out wallet master key upon lock (John Moffett)
b7e242ecb3aa0074aea753e5bc9f8d22674e8294 Correctly limit overview transaction list (John Moffett)
cff67180b3ba9ab53e01d44769059aa5559c01f7 depends: fix systemtap download URL (fanquake)
7cf73dfed5757819c0a5485ae05e8e1a57528a0e Add missing includes to fix gcc-13 compile error (MarcoFalke)
07397cdedeffb4da0aedd454d4539d65a0204291 addrdb: Only call Serialize() once (Martin Zumsande)
91f83dbeb197fc0fff574d9e29b4560b1d236bec hash: add HashedSourceWriter (Martin Zumsande)
5c824ac5e1e35f77e323319849b03ac9d8cf45d3 For feebump, ignore abandoned descendant spends (John Moffett)
428dcd51e6adab564ffb87ed678317924868572f wallet: Skip rescanning if wallet is more recent than tip (Andrew Chow)
cbcdafa471da3d1edd183143ae9d433627ef16dd test: wallet: check that labels are migrated to watchonly wallet (Sebastian Falbesoner)
342abfb3f4368fcdb67f3002c5558d4106d9bf83 wallet: fully migrate address book entries for watchonly/solvable wallets (Sebastian Falbesoner)
Pull request description:
Backports:
* https://github.com/bitcoin/bitcoin/pull/26595
* https://github.com/bitcoin/bitcoin/pull/26675
* https://github.com/bitcoin/bitcoin/pull/26679
* https://github.com/bitcoin/bitcoin/pull/26761
* https://github.com/bitcoin/bitcoin/pull/26837
* https://github.com/bitcoin/bitcoin/pull/26909
* https://github.com/bitcoin/bitcoin/pull/26924
* https://github.com/bitcoin/bitcoin/pull/26944
* https://github.com/bitcoin-core/gui/pull/704
* https://github.com/bitcoin/bitcoin/pull/27053
* https://github.com/bitcoin/bitcoin/pull/27080
ACKs for top commit:
instagibbs:
ACK https://github.com/bitcoin/bitcoin/pull/26878/commits/784a754aa47ce10c6fd99c09cdfc76ee9bc91652
achow101:
ACK 784a754aa47ce10c6fd99c09cdfc76ee9bc91652
hebasto:
ACK 784a754aa47ce10c6fd99c09cdfc76ee9bc91652, I've made backporting locally and got a diff between my branch and this PR as follows:
Tree-SHA512: 8ea84aa02d7907ff1e202e1302b441ce9ed2198bf383620ad40056a5d7e8ea88e1047abef0b92d85648016bf9b3195c974be3806ccebd85bef4f85c326869e43
|
|
Github-Pull: #26595
Rebased-From: 9486509be65f09174a0cb50a337cac58a0c09de4
|
|
Github-Pull: #26595
Rebased-From: aaf02b5721a8b5d3d9280dc3146fa5e44ea671b6
|
|
Since migration reloads the wallet, the wallet will always be locked
unless the passphrase is given. migratewallet can now take the
passphrase in order to unlock the wallet for migration.
Github-Pull: #26595
Rebased-From: 7fd125b27d48e410509f3009e2eb9fa5cd6729dd
|
|
Github-Pull: #26595
Rebased-From: 6bdbc5ff590de18dfb47c31190baad879f68fef7
|
|
An overload of MigrateLegacyToDescriptor is added which takes the wallet
name. The original that took a wallet pointer is still available, it
just gets the name, closes the wallet, and calls the new overload.
Github-Pull: #26595
Reabsed-From: dbfa34540372033d95036a02b7025ddd33f540aa
|
|
The default number of tunnels in the Java implementation is 2 and in the
C++ i2pd it is 5. Pick a mid-number (3) and explicitly set it in order
to get a consistent behavior with both routers. Do this for persistent
sessions which are created once at startup and can be used to open up
to ~10 outbound connections and can accept up to ~125 incoming
connections. Transient sessions already set number of tunnels to 1.
Suggested in:
https://github.com/bitcoin/bitcoin/issues/26754#issuecomment-1367356129
https://geti2p.net/en/docs/api/samv3
Alleviates: https://github.com/bitcoin/bitcoin/issues/26754
Github-Pull: #26837
Rebased-From: 3c1de032de01e551992975eb374465300a655f44
|
|
This will lower the load on the I2P network. Since we use one transient
session for connecting to just one peer, a higher number of tunnels is
unnecessary.
This was suggested in:
https://github.com/bitcoin/bitcoin/issues/26754#issuecomment-1365449401
https://github.com/bitcoin/bitcoin/issues/26754#issuecomment-1367356129
The options are documented in:
https://geti2p.net/en/docs/protocol/i2cp#options
A tunnel is unidirectional, so even if we make a single outbound
connection we still need an inbound tunnel to receive the messages sent
to us over that connection.
Alleviates: https://github.com/bitcoin/bitcoin/issues/26754
Github-Pull: #26837
Rebased-From: 801b405f85b413631427c2d8cc1f8447309ea5d8
|
|
In the case of `i2pacceptincoming=0` we use transient addresses
(destinations) for ourselves for each outbound connection. It may
happen that we
* create the session (and thus our address/destination too)
* fail to connect to the particular peer (e.g. if they are offline)
* dispose the unused session.
This puts unnecessary load on the I2P network because session creation
is not cheap. Is exaggerated if `onlynet=i2p` is used in which case we
will be trying to connect to I2P peers more often.
To help with this, save the created but unused sessions and pick them
later instead of creating new ones.
Alleviates: https://github.com/bitcoin/bitcoin/issues/26754
Github-Pull: #26837
Rebased-From: b906b64eb76643feaede1da5987a0c4d466c581b
|
|
Github-Pull: #27053
Rebased-From: 14b4921a91920df25b19ff420bfe2bff8c56f71e
|
|
When an encrypted wallet is locked (for instance via the
RPC `walletlock`), the docs indicate that the key is
removed from memory. However, the vector (with a secure
allocator) is merely cleared. This allows the key to persist
indefinitely in memory. Instead, manually fill the bytes with
zeroes before clearing.
Github-Pull: #27080
Rebased-From: 3a11adc7004d21b3dfe028b190d83add31691c55
|
|
The way that the main overview page limits the number
of transactions displayed (currently 5) is not
an appropriate use of Qt. If it's run with a DEBUG
build of Qt, it'll result in a segfault in certain
relatively common situations. Instead of artificially
limiting the rowCount() in the subclassed proxy
filter, we hide/unhide the rows in the displaying
QListView upon any changes in the sorted proxy filter.
Github-Pull: bitcoin-core/gui/pull/704
Rebased-From: 08209c039ff4ca5be4982da7a2ab7a624117ce1a
|
|
Github-Pull: #26944
Rebased-From: d81ca6619a5d05472af7f59e36cd100dd04a3a01
|
|
Github-Pull: #26924
Rebased-From: fadeb6b103cb441e0e91ef506ef29febabb10715
|
|
The previous logic would call it once for serializing into the filestream,
and then again for serializing into the hasher. If AddrMan was changed
in between these calls by another thread, the resulting peers.dat would
be corrupt with non-matching checksum and data.
Fix this by using HashedSourceWriter, which writes the data
to the underlying stream and keeps track of the hash in one go.
Github-Pull: #26909
Rebased-From: 5eabb61b2386d00e93e6bbb2f493a56d1b326ad9
|
|
This class is the counterpart to CHashVerifier, in that it
writes data to an underlying source stream,
while keeping a hash of the written data.
Github-Pull: #26909
Rebased-From: da6c7aeca38e1d0ab5839a374c26af0504d603fc
|
|
To be eligible for fee-bumping, a transaction must not have any
of its outputs (eg - change) spent in other unconfirmed transactions
in the wallet. However, this check should not apply to abandoned
transactions.
A new test case is added to cover this case.
Github-Pull: #26675
Rebased-From: f9ce0eadf4eb58d1e2207c27fabe69a5642482e7
|
|
If a wallet has key birthdates that are more recent than the currrent
chain tip, or a bestblock height higher than the current tip, we should
not attempt to rescan as there is nothing to scan for.
Github-Pull: #26679
Rebased-From: 378400953424598fd78ccec5ba8cc38bc253c550
|
|
Github-Pull: #26761
Rebased-From: 730e14a317ae45fe871c8d6f44a51936756bbbea
|
|
Currently `migratewallet` migrates the address book (i.e. labels and
purposes) for watchonly and solvable wallets only in RAM, but doesn't
persist them on disk. Fix this by adding another loop for both of the
special wallet types after which writes the corresponding NAME and
PURPOSE entries to the database in a single batch.
Github-Pull: #26761
Rebased-From: d5f4ae7fac0bceb0c9ad939b9a4fbdb85da0bf95
|
|
peer without CNodeStateStats
e72313e6b3fbf865e0eaa9aee0a555b7a7fe6850 rpc: Require NodeStateStats object in getpeerinfo (Martin Zumsande)
Pull request description:
Backports #26515.
ACKs for top commit:
fanquake:
ACK e72313e6b3fbf865e0eaa9aee0a555b7a7fe6850
Tree-SHA512: 28e885ea299fe8a3a7538628d413c434bc42c251a2c1ae238bca0652709f5bd781eb157675171ab538f6e2f6f720f1c184200ac3857f6c78f48858949eed49da
|
|
95ec9604a443e2182d9c0eeba36293d57b37e1f9 ci: Use `macos-ventura-xcode:14.1` image for "macOS native" task (Hennadii Stepanov)
50ad39d9d049d99ecce8a41553e0578950617265 ci: Make `getopt` path architecture agnostic (Hennadii Stepanov)
ce2a072ba846cc497b9823c6359e7230a268e137 ci: Allow PIP_PACKAGES on centos (MacroFake)
644c0304f56171ef2bac595ab67344f45733e169 ci: Remove unused package (MacroFake)
Pull request description:
ACKs for top commit:
fanquake:
ACK 95ec9604a443e2182d9c0eeba36293d57b37e1f9 did the same for 23.x & in #26878.
Tree-SHA512: 086fbe2f2a39e210cc41076d42fb911abdd720a2824fcaaacfaf50345c90d23b9f9f8b0a06e4f85cced0a8fdf0e5f5a7a3a00a05edbc267574893975dfc7c061
|
|
Github-Pull: #26388
Rebased-From: da168934741b776bce07d5503ca2344d300723b3
|
|
Github-Pull: #26388
Rebased-From: 702836530ffa351e863b1b1300fd2e559a14ef23
|
|
This was added in 7fc5e865b93af59364e9c8bf75ec68b4decc7e5d but I can't
see a reason why this should be forbidden.
Github-Pull: #26234
Rebased-From: fa6054e952f4522b98dc89609033950a3cbfd06c
|
|
Address feedback from https://github.com/bitcoin/bitcoin/pull/24561/files#r985719812
Github-Pull: #26234
Rebased-From: fac085a05cc518b14271353128bb1fa830b3c612
|
|
There is no situation in which CNodeStateStats could be
missing for a legitimate reason - this can only happen if
there is a race condition between peer disconnection and
the getpeerinfo call, in which case the disconnected peer
doesn't need to be included in the response.
Github-Pull: bitcoin#26515
Rebased-From: 6fefd49
|