Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
stickies-v
left a comment
There was a problem hiding this comment.
ACK 234f32860dd0e450e214c93af09e9dd9df20e9ea
|
perhaps add #28791 |
|
Backports LGTM d055adad985752c5ae3cf9dd0f509c83850e6c5b but it seems that the commit messages are different than usual? It doesn't seem like we have formal documentation on this, but keeping things uniform helps keep scripts simple (e.g. compiling a list of all pulls that are backported from
|
d055ada to
62694d7
Compare
|
fixed commit messages. |
|
Lets add #29127, so if we decide to, we can test macOS notarization: #15774 (comment). |
Instead of reaching into the mapTx data structure, use a helper method that provides the required vector of CTxMemPoolEntry pointers. Github-Pull: bitcoin#28391 Rebased-From: 453b481
A Bitcoin Core node may only connect to a peer destination via I2P if both sides have sessions with the same encryption type. The encryption type is a property of the session, not the destination. Sessions may support multiple encryption types. As Bitcoin Core is not currently setting the I2P encryption type when creating sessions, it is using the older default, ElGamal (type 0). This pull updates Bitcoin Core to use both ECIES-X25519 and ElGamal (types 4 and 0, respectively). This allows to connect to I2P peers with either type, and the newer, faster ECIES-X25519 will be preferred. See also the recently updated section "Signature and Encryption Types" in https://geti2p.net/en/docs/api/samv3 Thanks and credit to zzzi2p (https://github.com/zzzi2p) for reporting. Closes bitcoin#29197. Github-Pull: bitcoin#29200 Rebased-From: 9d72891
Log at the top before incrementing so that this log isn't printed when there's only 1 tx. Github-Pull: bitcoin#29227 Rebased-From: eb78ea4
…xoutset` Github-Pull: bitcoin#28791 Rebased-From: cdc6ac4
…empool Test that wallet rescans process transactions topologically, even if a parent's entry into the mempool is later than that of its child. This behavior is important because IsFromMe requires the ability to look up a transaction's inputs. Github-Pull: bitcoin#29179 Rebased-From: c3d02be
…in mempool Test that wallet rescans process transactions topologically, even if a parent's entry into the mempool is later than that of its child. This behavior is important because IsFromMe requires the ability to look up a transaction's inputs. Co-authored-by: furszy <[email protected]> Github-Pull: bitcoin#29179 Rebased-From: df30247
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer. Github-Pull: bitcoin#29127 Rebased-From: 4fdd836
62694d7 to
11f3a7e
Compare
Backports for 26.x. Includes:
loadtxoutset#28791