💬 techy2 commented on issue "automake script error building 32 bit depends libevent-2.1.12":
(https://github.com/bitcoin/bitcoin/issues/30311#issuecomment-2185279562)
Last run was attempt at cross compile on ubuntu 18.04 64 bit host attempting cross compile
Xeon X5690
192 gigs memory
1 T disk
autoconf 2.69
automake 1.16.1
gcc 10.3.0
python3 3.6.9

seems like a no-win situation, X64 won't do the 32 bit build and the focal-32 system gcc-10.5 can not find 'cc1' gcc -print-prog-name=cc1 does not provide a path

suggestions?

💬 techy2 commented on issue "automake script error building 32 bit depends libevent-2.1.12":
(https://github.com/bitcoin/bitcoin/issues/30311#issuecomment-2185325521)
taking a look at focal32 expected path for cc1, it is not there. Installed gcc 10.5.0 once again and succeeded in populating /usr/lib/gcc/i686-linux-gnu/10/cc1
works now on focal32

However the failure to cross compile on the x64 platform is an issue

--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
from the config log does not look right to me for an 1686 cross build

📝 paplorinc opened a pull request: "optimizations: Reduce cache lookups in CCoinsViewCache::FetchCoin"
(https://github.com/bitcoin/bitcoin/pull/30326)
Enhanced efficiency and readability of `CCoinsViewCache::FetchCoin` by replacing separate `find()` and `emplace()` calls with a single `try_emplace()`, reducing map lookups and potential insertions.

`AssembleBlock` shows `FetchCoin` as one of its bottlenecks:
<img src="https://github.com/bitcoin/bitcoin/assets/1841944/79c7f480-aac2-46da-9ac9-526a02a8eafa">

These changes result in a modest performance improvement:

Before:
| ns/op | op/s | err% | tota
...

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1650196258)
Hm, not sure how much it is known but it is referenced in other places already, like the `getblock` RPC help. And I'm not sure if a more generic text helps more people because it's a quite technical reason and I don't know how to explain it in a way that works for everyone and is still concise. With the term undo data people at least have something they can search on Bitcoin SE etc.

💬 edilmedeiros commented on pull request "[26.x] upnp: fix build with miniupnpc 2.2.8":
(https://github.com/bitcoin/bitcoin/pull/30319#issuecomment-2185496229)
ACK 10413ac46c07d3a45dc9d71818f59ffdb1129032

💬 romanz commented on pull request "rest: don't copy block data when sending binary response":
(https://github.com/bitcoin/bitcoin/pull/30321#discussion_r1650328599)
Added https://github.com/bitcoin/bitcoin/commit/9c9375cf3b581c31f047b87a2c05507dc7b31804 with a few more fixes.

👍 rkrux approved a pull request: "wallet: notify when preset + automatic inputs exceed max weight"
(https://github.com/bitcoin/bitcoin/pull/30309#pullrequestreview-2134800855)
tACK [72b2268](https://github.com/bitcoin/bitcoin/pull/30309/commits/72b226882fe2348a9a66aee1d8d21b4e2d275e68)

Reran make and all functional tests. Thanks @furszy for addressing my comments quickly!

> Basically, we are erroring out early when the automatic coin selection process exceeds the maximum weight

I ended up going through the coin selection algorithms and found all of them honouring the max weight criteria in case of automatic coin selection in `coinselection`:
- https://githu
...

💬 rkrux commented on pull request "wallet: notify when preset + automatic inputs exceed max weight":
(https://github.com/bitcoin/bitcoin/pull/30309#discussion_r1650435604)
Any specific reason to generate 1472 outputs when 1471 are picked?

💬 rkrux commented on pull request "wallet: notify when preset + automatic inputs exceed max weight":
(https://github.com/bitcoin/bitcoin/pull/30309#discussion_r1650434123)
Thanks for adding a functional test for `send()` as well.

👍 rkrux approved a pull request: "[test]: prevent `create_self_transfer` failure when target weight is below tx weight"
(https://github.com/bitcoin/bitcoin/pull/30322#pullrequestreview-2134883494)
reACK [7d5afbb](https://github.com/bitcoin/bitcoin/pull/30322/commits/7d5afbb5627d754af5db3a2bd4beb5cf0f400b2c)

@ismaelsadeeq Thanks for quickly addressing my comments, these multiple small commits helped in thorough review of the PR.

👍 willcl-ark approved a pull request: "contrib: Fixup verify-binaries OS platform parsing"
(https://github.com/bitcoin/bitcoin/pull/30147#pullrequestreview-2135153143)
ACK a2fc9ddee9cbaeffb3c460973bab3c2dd734db55

Compared changes since last review using `git range-diff 8135632...a2fc9ddee9cbaeffb3c460973bab3c2dd734db55`, which added the `difflib` helper and updated the commit message.

📝 paplorinc converted_to_draft a pull request: "optimization: Switch CTxMemPool::CalculateDescendants from set to vector to reduce transaction hash calculations"
(https://github.com/bitcoin/bitcoin/pull/30325)
Profiling `BlockAssemblerAddPackageTxns` indicated excessive hash recalculations:
<img src="https://github.com/bitcoin/bitcoin/assets/1841944/e1687162-30b5-47b6-83b3-d234cd156395">

The original implementation used a set to manage the stack of transactions for a depth-first traversal of its child transactions. However, since we're already filtering via `setDescendants` before adding them to `stage`, duplicates cannot exist anyway. Therefore, we can change it to a simple vector, providing effi
...

👋 paplorinc's pull request is ready for review: "optimization: Switch CTxMemPool::CalculateDescendants from set to vector to reduce transaction hash calculations"
(https://github.com/bitcoin/bitcoin/pull/30325)

👋 paplorinc's pull request is ready for review: "optimization: Reduce cache lookups in CCoinsViewCache::FetchCoin"
(https://github.com/bitcoin/bitcoin/pull/30326)

💬 rkrux commented on pull request "wallet: notify when preset + automatic inputs exceed max weight":
(https://github.com/bitcoin/bitcoin/pull/30309#issuecomment-2186203543)
> tACK [72b2268](https://github.com/bitcoin/bitcoin/pull/30309/commits/72b226882fe2348a9a66aee1d8d21b4e2d275e68)
>
> Reran make and all functional tests. Thanks @furszy for addressing my comments quickly!
>
> > Basically, we are erroring out early when the automatic coin selection process exceeds the maximum weight
>
> I ended up going through the coin selection algorithms and found all of them honouring the max weight criteria in case of automatic coin selection in `coinselection`:
>
...

👋 fanquake's pull request is ready for review: "[27.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/30305)

👍 willcl-ark approved a pull request: "[27.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/30305#pullrequestreview-2135426523)
ACK b3093eb755c00f0dc6c71d8384c9078603ef4862

Manually compared each backported commit with its original version.

👍 stickies-v approved a pull request: "[27.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/30305#pullrequestreview-2135517444)
ACK b3093eb755c00f0dc6c71d8384c9078603ef4862

All backports are clean, except:
- 0d524b14847f94d6e19413fde27f12e39e34694c backported from 9eea51d9058ad638861aa4b94c1c6e71caeb8765: `win64-native` CI steps `Clone fuzz corpus` and `RUun fuzz binaries` aren't backported, they are part of #29774

💬 stickies-v commented on pull request "[27.x] More backports":
(https://github.com/bitcoin/bitcoin/pull/30305#discussion_r1650871619)
I know we usually do it this way, but what's the harm in just making this (and other references, except for the git tag) `27.2rc1` right away?

💬 fanquake commented on pull request "[27.x] More backports":
(https://github.com/bitcoin/bitcoin/pull/30305#discussion_r1650873155)
The next release might not be 27.2. It could be 27.1.1 etc.