💬 theuni commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2619854239)
> I think the depends source-package thing is elegant and neat. But in the cross-compiled case, it effectively nullifies the effect of vendoring the code. Changes to the local libmultiprocess won't be picked up without rebuilding depends. I think this could be improved by always using our internal target libmultiprocess, but selectively with an internel/external native one? In that case, I don't think the non-native libmultiprocess in depends needs to exist?

Basically (unless I'm missing some
...

💬 vasild commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1932753931)
> `@param[out] cancel_recv Should always be set upon return`

I think the problem was that `HTTPServer::EventReadyToSend()` could end up not setting `cancel_recv` in which case it remains uninitialized, containing a "random" value from the stack at the caller (which was probably `true`, so it canceled all receives from the client, never receiving anything causing an infinite loop):

```cpp
bool cancel_recv;

EventReadyToSend(node_id, cancel_recv);


...

💬 naiyoma commented on pull request "test: Add test for rpcwhitelistdefault":
(https://github.com/bitcoin/bitcoin/pull/29858#discussion_r1932762333)
rpcwhitelistdefault=1 revokes permissions for all users, including the __cookie__ user. Since the cookie user is required during the node restart process (for getblockcount and getmempoolinfo), I had to explicitly whitelist

💬 naiyoma commented on pull request "test: Add test for rpcwhitelistdefault":
(https://github.com/bitcoin/bitcoin/pull/29858#discussion_r1932768623)
I've just realized that I need to remove` getblockchaininfo `from the whitelist, it's unused.

💬 naiyoma commented on pull request "test: Add test for rpcwhitelistdefault":
(https://github.com/bitcoin/bitcoin/pull/29858#discussion_r1932801596)
this function will fail without the whitelist https://github.com/bitcoin/bitcoin/blob/master/test/functional/test_framework/test_node.py#L264

💬 pinheadmz commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#discussion_r1932812651)
awesome thank you

💬 pinheadmz commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#issuecomment-2619994736)
Something else I see using Sockman is in the `mempool_limit` functional test, we call `getrawtransaction` and expect around 540,000 bytes back. The call to `send()` returns the total amount of bytes immediately, but it requires 60-70 TCP packets to actually transmit the response. I think what I'm seeing in wireshark is that this transmission is incomplete when I close the HTTP connection with `CloseConnection()` which closes the underlying socket. The client waits 120 seconds for the rest of its
...

💬 darosior commented on pull request "rpc: fix mintime field testnet4":
(https://github.com/bitcoin/bitcoin/pull/31600#issuecomment-2619996977)
What's the state of this? I'd love this to not miss the 29.0 deadline, in order to be as widely available to miners if a timewarp fix ever gets proposed, and given that miners may take years to upgrade.

@Sjors's last message reads like he agrees with me and was going to make the change, so i was waiting on that. Pinged him and turns out he was waiting to see if anybody was going to chime in about his last message. @fjahr @tdb3 since you previously ACKed this do you have an opinion? @luke-jr a
...

💬 naiyoma commented on pull request "test: Add test for rpcwhitelistdefault":
(https://github.com/bitcoin/bitcoin/pull/29858#issuecomment-2620001641)
hey @ismaelsadeeq and @rkrux thanks for the reviews! I'll be sure to incorporate the suggestion in the follow-up.

💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2620013263)
Thanks for the feedback and clearing things up. Will be interested to see the EXTERNAL_MPGEN option and maybe eliminate one of the depends packages.

> I think the depends source-package thing is elegant and neat. But in the cross-compiled case, it effectively nullifies the effect of vendoring the code. Changes to the local libmultiprocess won't be picked up without rebuilding depends.

I don't think "effectively nullifies the effect of vendoring" is true at all, unless you have some differe
...

💬 luke-jr commented on pull request "rpc: fix mintime field testnet4":
(https://github.com/bitcoin/bitcoin/pull/31600#issuecomment-2620052882)
"allowed" isn't necessarily consensus rules. It would be strictly BIP 23 compatible to just reject rpc submissions with an earlier time. I don't think we need to go that far though - probably fine to tolerate it

💬 ryanofsky commented on pull request "multiprocess: Add libmultiprocess git subtree":
(https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2620090133)
Few other things I wanted to reply to.

re: https://github.com/bitcoin/bitcoin/pull/31741#issuecomment-2619837571

> Correct. Even if it's not desirable to check these into master, it would be _very_ useful to have them in release branches so that they end up in release tarballs. It's very common for source packages to be pre-bootstrapped, and that's exactly what this would do.

Honestly as a long time gentoo and nixos user, this sounds pretty bad to me. I want my package manager to build
...

⚠️ texasspurstar opened an issue: "build: broken CMake *flags output"
(https://github.com/bitcoin/bitcoin/issues/31749)
### Please describe the feature you'd like to see added.

Seen in CI runs, i.e https://cirrus-ci.com/task/5616358949388288?logs=configure#L309:

C++ compiler flags .................... -O2 -g -std=c++20 -fPIC -fdebug-prefix-map=/tmp/cirrus-ci-build/bitcoin-core/src=. -fmacro-prefix-map=/tmp/cirrus-ci-build/bitcoin-core/src=. -Werror $<$<COMPILE_LANG_AND_ID:CUDA,NVIDIA>:SHELL:-Xcompiler -pthread> $<$<AND:$<NOT:$<COMPILE_LANG_AND_ID:CUDA,NVIDIA>>,$<NOT:$<COMPILE_LANGUAGE:Swift>>>:-pthread> -Wall -
...

✅ fanquake closed an issue: "build: broken CMake *flags output"
(https://github.com/bitcoin/bitcoin/issues/31749)

🤔 ismaelsadeeq reviewed a pull request: "RPC: improve SFFO arg parsing, error catching and coverage"
(https://github.com/bitcoin/bitcoin/pull/30844#pullrequestreview-2579487271)
Code review and Tested ACK cddcbaf81e8e3d107cd321ee2c9a7fd786a8917e

⚠️ Alward0 opened an issue: "Key events of bitcoin "
(https://github.com/bitcoin/bitcoin/issues/31750)
The history of **Satoshi Nakamoto**, the pseudonymous creator of Bitcoin, is shrouded in mystery. Despite extensive speculation and investigation, no one has definitively uncovered Satoshi's true identity. Here’s what is known about Satoshi Nakamoto based on available information:

---

### **Key Events in Satoshi Nakamoto's History**
1. **October 2008**:
- Satoshi Nakamoto published the **Bitcoin whitepaper**, titled *"Bitcoin: A Peer-to-Peer Electronic Cash System,"* on a cryptography maili
...

✅ pinheadmz closed an issue: "Key events of bitcoin "
(https://github.com/bitcoin/bitcoin/issues/31750)

:lock: fanquake locked an issue: "Key events of bitcoin "
(https://github.com/bitcoin/bitcoin/issues/31750)

💬 darosior commented on issue "RFC: Multiprocess binaries and packaging options":
(https://github.com/bitcoin/bitcoin/issues/30983#issuecomment-2620155964)
I don't think the cons of option 3 are necessary to get its pros. How about simply keeping `bitcoind` and `bitcoin-qt` which would start `-node`, `-wallet` and `-gui` binaries from `libexec`? The bigger binaries are a consequence of wanting to be able to disable IPC through a runtime option. It's an internal, why is it something we would want to make possible for the user to change? And why should we keep releasing the large binaries? If we do, when do we stop? I think that *once we are confiden
...

💬 mzumsande commented on issue "test: intermittent issue in p2p_1p1c_network.py ":
(https://github.com/bitcoin/bitcoin/issues/31721#issuecomment-2620169640)
I think that the following is happening:
- Orphan is announced to node 1 by python peer, but it doesn't send the tx.
- submitpackage is executed on node 0, which will sequentially schedule `RelayTransaction`, first for the parent, then for the child.
- Usually parent and child are put together in one inv, but if the node sends out an inv in between these two `RelayTransaction` calls, the inv for the child may arrive after the tx for the parent was received - since we now only do orphan resolutio
...