Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ’¬ hebasto commented on pull request "ci, iwyu: Treat warnings as errors for `src/init` and `src/policy`":
(https://github.com/bitcoin/bitcoin/pull/33725#issuecomment-3462818493)
> > this pull request conflicts with the following ones:
> > #33629 (Cluster mempool by sdaftuar)
> > #33591 (Cluster mempool followups by sdaftuar)
>
> I think if you want to continue these refactors, it might be better if you picked code that doesn't conflict with Cluster Mempool or Kernel work, or things we are trying to ship in `v31`.

I agree, and when I noticed these conflicts, I checked that those PRs don't have any ACKs yet.

> Could instead do directories that rarely change, li
...
πŸ’¬ hebasto commented on pull request "ci, iwyu: Treat warnings as errors for `src/init` and `src/policy`":
(https://github.com/bitcoin/bitcoin/pull/33725#discussion_r2474367441)
We use a tiny part of Boost, which seems quite stable. So I don’t think it’s worth the effort.
πŸ’¬ umrashrf commented on issue "Can I compile on OSX Tahoe?":
(https://github.com/bitcoin/bitcoin/issues/33733#issuecomment-3462842254)
@hebasto I first put the output to a file so I can resue it later.

```
% cat configure.log.3 | grep -i boost
-- Performing Test NO_DIAGNOSTICS_BOOST_NO_CXX98_FUNCTION_BASE
-- Performing Test NO_DIAGNOSTICS_BOOST_NO_CXX98_FUNCTION_BASE - Failed
Boost_DIR:PATH=/opt/homebrew/opt/boost/lib/cmake/Boost-1.89.0
boost_headers_DIR:PATH=/opt/homebrew/opt/boost/lib/cmake/boost_headers-1.89.0
```
πŸ’¬ hebasto commented on issue "Can I compile on OSX Tahoe?":
(https://github.com/bitcoin/bitcoin/issues/33733#issuecomment-3462861458)
@umrashrf

I have a guess, and to confirm it, I'd ask you to try configuring and building with the additional `-DENABLE_WALLET=OFF` option.
πŸ’¬ 00w1 commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3462899397)
> Luke-jr's seed returns knots 29.2 nodes, and yet he claims knots 29.2 is based on the same code it currently won't return. https://x.com/LukeDashjr/status/1977355254510256135 even though the issue is now known to luke-jr the behavior hasn't been corrected.

I have been trying to resolve `dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us` since last 15 minutes but it did not return any knots v29.2 node IP address in the response. Others who reviewed https://github.com/bitcoin/bitcoin/pull/33723 did n
...
⚠️ 00w1 opened an issue: "Remove *petertodd.net DNS seed for testnet and mainnet"
(https://github.com/bitcoin/bitcoin/issues/33736)
Creating an issue based on @glozow's suggestion in https://github.com/bitcoin/bitcoin/pull/33730#issuecomment-3461843402

Some [emails](https://agorism.dev/petertodd-emails.txt) were leaked on bitcointalk and Peter Todd acknowledged that they are not fake. His communication with someone about bitcoin development and privacy who claims to work for government agencies potentially violates the DNS seed policy.

> A DNS seed operating organization or person is expected to follow good host security p
...
πŸ’¬ achow101 commented on issue "Remove *petertodd.net DNS seed for testnet and mainnet":
(https://github.com/bitcoin/bitcoin/issues/33736#issuecomment-3463006389)
Can you cite where in those emails you believe this part of the policy is being violated? I searched for "dns" and "seed" and got no results. I searched for "server" and don't see anything that seems to discuss handing over any DNS seed infrastructure to someone else.
πŸ‘ pinheadmz approved a pull request: "http: replace WorkQueue and single threads handling for ThreadPool"
(https://github.com/bitcoin/bitcoin/pull/33689#pullrequestreview-3395201777)
ACK f5eca8d5252a68f0fbc8b5efec021c75744555b6

minor changes since last ack

<details><summary>Show Signature</summary>

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

ACK f5eca8d5252a68f0fbc8b5efec021c75744555b6
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmkCWuYACgkQ5+KYS2KJ
yTpb9RAAgxNlDQlqkVfnIK2Xt8BQmRsiG+1KHQGJA2d3RHoxjFg2129fj47y5i+t
GlatlcsXEcibI2D0F22sKSzY1u0LWy4GYLI1d12JAIewA99n/lRr1ktDk3v64pp8
kldvYpd8UBs7DCHSJhPs4HbOPgwIILPASdSbQTb+6m48X5jg+cu+yMBu
...
πŸ€” polespinasa reviewed a pull request: "fees: enable `CBlockPolicyEstimator` return sub 1 sat/vb fee rate estimates"
(https://github.com/bitcoin/bitcoin/pull/33199#pullrequestreview-3394935535)
Just some nits and questions :=)
πŸ’¬ polespinasa commented on pull request "fees: enable `CBlockPolicyEstimator` return sub 1 sat/vb fee rate estimates":
(https://github.com/bitcoin/bitcoin/pull/33199#discussion_r2474344669)
Is a1a1bfa2445da11369323b649253f81d288f2813 necessary?
Won't old versions be able to read the file even if estimations are sub 1sat/vb?

just curiosity, how is this number chosen? Related to release number?
πŸ’¬ polespinasa commented on pull request "fees: enable `CBlockPolicyEstimator` return sub 1 sat/vb fee rate estimates":
(https://github.com/bitcoin/bitcoin/pull/33199#discussion_r2474331227)
nit: I would keep the original first sentence: `The MIN_BUCKET_FEERATE should just be set to the lowest reasonable feerate we might want to track` + `which should be DEFAULT_MIN_RELAY_TX_FEE.`
πŸ’¬ polespinasa commented on pull request "fees: enable `CBlockPolicyEstimator` return sub 1 sat/vb fee rate estimates":
(https://github.com/bitcoin/bitcoin/pull/33199#discussion_r2474566135)
this changes feel out of scope for this pr
πŸ’¬ gmaxwell commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3463141404)
Odd. I connected to it in a loop and eventually got a "/Satoshi:29.2.0/Knots:20251010/" -- also other knots versions and yet yours shows no knots at all?
πŸ’¬ furszy commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2474671206)
true. Closing this.
πŸ’¬ andrewtoth commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2474735112)
I mean pick up that it's being written by multiple threads if something breaks the assumptions in this test. It seems like an ok idea. Or am I wrong?
πŸ’¬ Sjors commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3463296694)
I share the concerns, but at the same time it will be a while before we ship a new release. So I prefer to just wait a few days / weeks to hear a clear answer from Luke himself, preferably here on Github and not some gated social media platform that I can't read :-)
πŸ’¬ polespinasa commented on pull request "fees: rpc: `estimatesmartfee` now returns a fee rate estimate during low network activity":
(https://github.com/bitcoin/bitcoin/pull/32395#issuecomment-3463307304)
Is this necessary? doesn't #31664 and the mempool forecaster fix this?
If the block estimator does not have enough info, it can fallback to the mempool forecaster that will return the min feerate to enter the block template it creates?
πŸ’¬ ajtowns commented on pull request "doc: better document NetEventsInterface and the deletion of "CNode"s":
(https://github.com/bitcoin/bitcoin/pull/32278#discussion_r2474399807)
I think this would be better phrased as requirements for implementers of the interface, rather than the user of the interface. ie: "For a given `CNode`, the methods will be called in the following order:". (Both `CNode` and `NetEventsInterface` are interfaces the net module offers, so the appropriate documentation is how they work and what you need to do to implement NetEventsInterface, not how net.cpp needs to be implemented)
πŸ’¬ ajtowns commented on pull request "doc: better document NetEventsInterface and the deletion of "CNode"s":
(https://github.com/bitcoin/bitcoin/pull/32278#discussion_r2474449300)
I'd phrase this as:

Destroying objects from this list works as follows (see DisconnectNodes(), DeleteNode()):
* we will close the socket, release locks, and reset global info relating to the connection
* the node will be moved from `m_nodes` to `m_nodes_disconnected`, preventing future calls to `ProcessMessages()` and `SendMessages()` for this node, and decrementing the reference count
* we will wait for GetRefCount() to return `<= 0` indicating there are no other references to this nod
...