💬 rkrux commented on pull request "[test]: prevent `create_self_transfer` failure when target weight is below tx weight":
(https://github.com/bitcoin/bitcoin/pull/30322#discussion_r1650041737)
```
"""Pad a transaction with extra outputs until it reaches a target weight (or higher by
at most BULK_TX_PADDING_OFFSET WU).
```

💬 rkrux commented on pull request "[test]: prevent `create_self_transfer` failure when target weight is below tx weight":
(https://github.com/bitcoin/bitcoin/pull/30322#discussion_r1650041551)
Thanks for this change, I recall highlighting in the previous PR.

💬 ismaelsadeeq commented on pull request "[test]: prevent `create_self_transfer` failure when target weight is below tx weight":
(https://github.com/bitcoin/bitcoin/pull/30322#discussion_r1650068106)
Yes, updated.

💬 ismaelsadeeq commented on pull request "[test]: prevent `create_self_transfer` failure when target weight is below tx weight":
(https://github.com/bitcoin/bitcoin/pull/30322#discussion_r1650068246)
good catch, updated thanks.

📝 paplorinc opened a pull request: "Moved repeated `-printpriority` fetching out of AddToBlock"
(https://github.com/bitcoin/bitcoin/pull/30324)
`AddToBlock` was called repeatedly from `addPackageTxs` where the constant value of `printpriority` is recalculated every time.

<img src="https://github.com/bitcoin/bitcoin/assets/1841944/6fd89647-7b6c-4f44-bd04-98d16cd2a938">

This showed up during profiling of AssembleBlock, fetching it once in the constructor results in a measurable speed increase for many iterations.

> ./src/bench/bench_bitcoin --filter='AssembleBlock' --min-time=1000

before:
|               ns/op |              
...

👋 paplorinc's pull request is ready for review: "Moved repeated `-printpriority` fetching out of AddToBlock"
(https://github.com/bitcoin/bitcoin/pull/30324)

📝 paplorinc opened a pull request: "Optimization: Switch CTxMemPool::CalculateDescendants from set to deque to reduce transaction hash calculations"
(https://github.com/bitcoin/bitcoin/pull/30325)
Profiling `BlockAssemblerAddPackageTxns` indicated excessive hash recalculations which were eliminated by the deque.

<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 by `setDescendants` count, duplicates cannot exist in stage anyway.
Therefore, we can change it to a double
...

💬 BenWestgate commented on pull request "contrib: Fixup verify-binaries OS platform parsing":
(https://github.com/bitcoin/bitcoin/pull/30147#discussion_r1650116355)
Incorporated.

📝 paplorinc reopened a pull request: "refactor: Preallocate addresses in GetAddr based on nNodes"
(https://github.com/bitcoin/bitcoin/pull/29608)
Closely related to https://github.com/bitcoin/bitcoin/pull/29578/files

Before:
```
| ns/op | op/s | err% | total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
| 76,852.79 | 13,011.89 | 0.4% | 1.07 | `AddrManGetAddr`
| 76,598.21 | 13,055.14 | 0.2% | 1.07 | `AddrManGetAddr`
| 76,296.32 | 13,106.79 | 0.1% | 1.07 | `AddrManGetAd
...

💬 paplorinc commented on pull request "refactor: Preallocate addresses in GetAddr based on nNodes":
(https://github.com/bitcoin/bitcoin/pull/29608#issuecomment-2185115697)
Reopening since https://github.com/bitcoin/bitcoin/pull/29578 was closed without merging

💬 furszy commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1650127334)
q: is the "undo data" term well known outside of core? It seems to be an implementation detail to me. Maybe, could write this differently: "The block data will be stored alone; there will be no available information associated with the outputs this block spent. This limits the usage.. etc".

💬 techy2 commented on issue "automake script error building 32 bit depends libevent-2.1.12":
(https://github.com/bitcoin/bitcoin/issues/30311#issuecomment-2185253218)
Did all that, does not make any difference
executing this command line for depends
make HOST=i686-pc-linux-gnu -j8

however, config.log says this, see attached
configure:3745: $? = 0
configure:3734: gcc -m32 -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0
...

💬 Andredreyer1 commented on issue "automake script error building 32 bit depends libevent-2.1.12":
(https://github.com/bitcoin/bitcoin/issues/30311#issuecomment-2185254617)
Thanks

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

💬 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.