💬 pinheadmz commented on issue "Avoid pruning blocks with transactions in wallets (even after wallets sync)":
(https://github.com/bitcoin/bitcoin/issues/20384#issuecomment-1492535735)
This looks like another issue that could be addressed by https://github.com/bitcoin/bitcoin/issues/21267

💬 hebasto commented on pull request "depends: harden libevent":
(https://github.com/bitcoin/bitcoin/pull/27118#issuecomment-1492606272)
This PR introduced a regression when building with depends and disabled hardening:
```
$ make -C depends HOST=x86_64-w64-mingw32 NO_QT=1 NO_WALLET=1 NO_ZMQ=1 NO_UPNP=1 NO_NATPMP=1 NO_USDT=1
$ ./configure --disable-hardening CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site
$ make
...
/usr/bin/x86_64-w64-mingw32-ld: /home/hebasto/git/gui/depends/x86_64-w64-mingw32/lib/libevent.a(evutil.o):evutil.c:(.text+0x2975): undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32
...

💬 ishaanam commented on pull request "bumpfee: allow send coins back to yourself":
(https://github.com/bitcoin/bitcoin/pull/27195#discussion_r1154926275)
If I'm understanding this correctly, this means that this could result in the creation of a transaction with 2 outputs that our wallet would identify as change. What would happen if we wanted to bump this transaction again, but keep the outputs the same? Though I haven't tested this, I think that the following will happen:

1. The first output is added as `new_coin_control.destChange`
2. Then we find the second output is also change and over-write the original `destChange` with the second out
...

📝 jonatack opened a pull request: "net: extract Network and BIP155Network logic to node/network"
(https://github.com/bitcoin/bitcoin/pull/27385)
This extracts the `Network` and `BIP155Network` logic to `node/network`. The code has been living between `netaddress` and `netbase`, and some compilation units include these large files when they only use a `Network` enum or related method. Separating the code to a standalone unit in `node` improves code separation, helps with using only what is needed, and may speed up build times.

In draft to check CI/builds/IWYU/assumptions, e.g. perhaps common instead of node.

Possible to-do for a f
...

💬 ishaanam commented on pull request "bumpfee: avoid making bumped transactions with too low fee when replacing outputs":
(https://github.com/bitcoin/bitcoin/pull/27308#issuecomment-1492717965)
ACK 26b4c66418f97b4d13989a5c6cf2a7827af4fc1e

💬 DevAgrawal1112 commented on issue "net: signed-integer-overflow in LocalServiceInfo":
(https://github.com/bitcoin/bitcoin/issues/24049#issuecomment-1492838178)
Since I am new to open source, I would like to know if I need to change int to int64_t for nScore or if I have to work on something else.

📝 DevAgrawal1112 opened a pull request: "#24049 Issue: Update nScore datatype"
(https://github.com/bitcoin/bitcoin/pull/27386)
I had just changed the datatype of nScore from int to int64_t as the issue suggest.

💬 hebasto commented on pull request "#24049 Issue: Update nScore datatype":
(https://github.com/bitcoin/bitcoin/pull/27386#issuecomment-1492877236)
@DevAgrawal1112 Thank you for your contribution!

Did you check the discussion in the previous [attempt](https://github.com/bitcoin/bitcoin/pull/24090) to resolve the issue?

📝 hebasto opened a pull request: "depends, doc: Document `NO_USDT` option"
(https://github.com/bitcoin/bitcoin/pull/27387)
A follow-up for https://github.com/bitcoin/bitcoin/pull/23724.

💬 hebasto commented on pull request "depends, doc: Document `NO_USDT` option":
(https://github.com/bitcoin/bitcoin/pull/27387#issuecomment-1492892759)
cc @0xB10C

⚠️ DRAWCORE opened an issue: "get block or transaction data via rpc api when in the ibd process"
(https://github.com/bitcoin/bitcoin/issues/27388)
### Please describe the feature you'd like to see added.

Can I get the block or transaction data via the rpc api when the bitcoin core is still in the ibd process that has not been finished?
For example , can I get the downloaded block data via calling the `getblock` api while the client is still in the ibd process?

### Is your feature related to a problem, if so please describe it.

_No response_

### Describe the solution you'd like

_No response_

### Describe any alternatives you've consi
...

💬 0xB10C commented on pull request "depends, doc: Document `NO_USDT` option":
(https://github.com/bitcoin/bitcoin/pull/27387#issuecomment-1492918821)
ACK c9aace2bfd180906d528cc2a80bc856685fbc6ca

This also removes a stray `</dd>` from the `NO_NATPMP` docs. Maybe worth mentioning in the OP?

Change looks good to me. I did **not** run a depends build with `NO_USDT` set to test it.

💬 hebasto commented on pull request "depends, doc: Document `NO_USDT` option":
(https://github.com/bitcoin/bitcoin/pull/27387#issuecomment-1492919632)
> This also removes a stray `</dd>` from the `NO_NATPMP` docs. Maybe worth mentioning in the OP?

Done.

> Change looks good to me. I did **not** run a depends build with `NO_USDT` set to test it.

FWIW, we use `NO_USDT` in our other docs:
```
$ git grep -l NO_USDT -- doc
doc/build-freebsd.md
doc/build-openbsd.md
doc/build-unix.md
```

💬 0xB10C commented on issue "Intermittent failures in interface_usdt_mempool.py":
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1492942181)
Had a brief look. The `mempoolrej` log message shows that we indeed rejected the transaction but the test didn't see the reject.

Can't reproduce this locally with about 20 test runs. All pass. Might be a CI timing problem then? Will try playing around with the `bpf.perf_buffer_poll()` timeout.

Will investigate further.

💬 pinheadmz commented on issue "get block or transaction data via rpc api when in the ibd process":
(https://github.com/bitcoin/bitcoin/issues/27388#issuecomment-1492949497)
Yes this should work, did you try it? Here's example commands starting bitcoind in a fresh datadir with `-txindex`:

```
--> bitcoin-cli -datadir=/home/pinheadmz/bcd-test getblockcount
400

--> bitcoin-cli -datadir=/home/pinheadmz/bcd-test getblock 000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a
{
"hash": "000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a",
"confirmations": 9282,
"strippedsize": 215,
"size": 215,
"weight": 860,
"height": 1
...

📝 theStack opened a pull request: "test: refactor: replace unnecessary `BytesIO` uses"
(https://github.com/bitcoin/bitcoin/pull/27389)
Rather than needing to create intermediate stream variables, we can use helper functions like `tx_from_hex` instead or access the result directly, leading both to increased readability and less code.

💬 0xB10C commented on issue "Intermittent failures in interface_usdt_mempool.py":
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-1492956673)
Other CI runs with similar behavior:

- https://cirrus-ci.com/task/6650565413830656?logs=ci#L3531

💬 0xB10C commented on issue "CI, tracing: run tracepoint interface tests in the CI":
(https://github.com/bitcoin/bitcoin/issues/24782#issuecomment-1492963404)
The up coming Ubuntu 23.04 seems to be shipping with an up-to-date bpfcc: https://packages.ubuntu.com/lunar/python3-bpfcc

💬 0xB10C commented on pull request "Move log messages: tx enqueue to mempool, allocation to blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27277#issuecomment-1492964604)
> CI network error https://cirrus-ci.com/task/4864754720702464?logs=ci#L61:
>
> `TimeoutError: [Errno 110] Connection timed out`

Note: The failed connections seems to be to the launchpad.net PPA with a newer bpfcc. Not using this newer PPA to install an up-to-date `bpfcc` causes warnings printed to stderr which means `interface_usdt_coinselection.py` is treated as failed. (The up-coming Ubuntu lunar seems to include an up-to-date bpfcc).

💬 DRAWCORE commented on issue "get block or transaction data via rpc api when in the ibd process":
(https://github.com/bitcoin/bitcoin/issues/27388#issuecomment-1492968313)
> Yes this should work, did you try it? Here's example commands starting bitcoind in a fresh datadir with `-txindex`:
>
> ```
> --> bitcoin-cli -datadir=/home/pinheadmz/bcd-test getblockcount
> 400
>
> --> bitcoin-cli -datadir=/home/pinheadmz/bcd-test getblock 000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a
> {
> "hash": "000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a",
> "confirmations": 9282,
> "strippedsize": 215,
> "size": 215,
> "we
...