pyth has quit [Read error: Connection reset by peer]
pyth has joined #bitcoin-core-dev
pyth has quit [Ping timeout: 260 seconds]
pyth has joined #bitcoin-core-dev
sanket1729_web has joined #bitcoin-core-dev
sanket1729_web has quit [Client Quit]
sanket1729_web has joined #bitcoin-core-dev
sanket1729_web has quit [Quit: Client closed]
adiabat_ has quit [Ping timeout: 252 seconds]
sanket1729_web has joined #bitcoin-core-dev
adiabat_ has joined #bitcoin-core-dev
sanket1729_web has quit [Quit: Client closed]
sanket1729_web has joined #bitcoin-core-dev
sanket1729_web has quit [Client Quit]
sanket1729_web has joined #bitcoin-core-dev
Guest36 has joined #bitcoin-core-dev
Guest36 has quit [Client Quit]
Guest36 has joined #bitcoin-core-dev
Guest36 has quit [Client Quit]
hacker4web3bitco has joined #bitcoin-core-dev
hacker4web3bitco has quit [Changing host]
hacker4web3bitco has joined #bitcoin-core-dev
vasild_ is now known as vasild
<hacker4web3bitco>
Hi folks, I'm new to learn bitcoin core, ask a question, is there any doc about the cluster mempool implementation? I'm reading the code but struggles with the data structures relationship (bwtween like TxGraph, Cluster, DepGraph etc)
Guyver2 has left #bitcoin-core-dev [Closing Window]
<bitcoin-git>
bitcoin/master 6e5fc2b Hennadii Stepanov: test: Reintroduce Windows support in `system_tests/run_command` test
<bitcoin-git>
bitcoin/master 719fa9f Hennadii Stepanov: build: Re-enable external signer support for Windows
<bitcoin-git>
bitcoin/master 3a18075 Hennadii Stepanov: ci: Drop `-DENABLE_EXTERNAL_SIGNER=ON` configure option
<bitcoin-git>
[bitcoin] fanquake merged pull request #29868: Reintroduce external signer support for Windows (master...240414-win-subprocess) https://github.com/bitcoin/bitcoin/pull/29868
<bitcoin-git>
[bitcoin] fanquake opened pull request #32568: depends: use "mkdir -p" when installing xproto (master...alpine_MKDIRPROG) https://github.com/bitcoin/bitcoin/pull/32568
hacker4web3bitco has joined #bitcoin-core-dev
hacker4web3bitco has quit [Quit: Client closed]
<sipa>
maflcko: i find the LLM linter comments that drahtbot gives remarkably useful (not always correct, but even when not, they seem to indicate a misunderstanding that a human could make too)... is there any way to get more than 2-3 of them?
hacker4web3bitco has joined #bitcoin-core-dev
hacker4web3bitco has quit [Quit: Client closed]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<bitcoin-git>
[bitcoin] maflcko closed pull request #32501: RPC: removeprunedfunds should take an array of txids (master...removeprunedfunds-array) https://github.com/bitcoin/bitcoin/pull/32501
<maflcko>
sipa: Ah, good to hear it isn't completely useless
<maflcko>
Though, sometimes it comes up with stuff that is completely made up (doesn't exist in the diff)
<maflcko>
The number is capped at 5, so if you only get 2-3, then it didn't find more in that run. (The runs are not deterministic)
jespada has joined #bitcoin-core-dev
<gmaxwell>
maflcko: as the author it's probably pretty easy to ignore totally imaginary ones. :P
hacker4web3bitco has joined #bitcoin-core-dev
<hacker4web3bitco>
Hi I saw the code of cluster mempool has been merged, but seems it is not active for now? why?
<sipa>
but there are a number of prerequisite PRs before that
<hacker4web3bitco>
gotcha
<maflcko>
gmaxwell: Yeah, as long as the false positives are rare, it should be easy to ignore
<hacker4web3bitco>
sipa I saw there are discussions about the linearization algorithm, will the min-cut one or the span forest one be applied?
<gmaxwell>
There is a PR for the spanning forrest algorithim, and I don't think sipa intends to continue his development of the min-cut one currently.
<gmaxwell>
though functionally, other than the algorithim internals, it doesn't much matter which the codebase uses. Maybe in the future someone will make an even better one.
rszarka has quit [Quit: Leaving]
szarka has joined #bitcoin-core-dev
hacker4web3bitco has quit [Quit: Client closed]
hacker4web3bitco has joined #bitcoin-core-dev
hacker4web3bitco has quit [Client Quit]
hacker4web3bitco has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
<hacker4web3bitco>
gmaxwell I see, I'll skip that part for now
<sipa>
maflcko: my strategy so far is every time i push a PR anyway, i go over all the LLM linter comments and address them too (if i can find them, sometimes they're indeed imaginary)... but it always comes up with new ones :p
<sipa>
hacker4web3bitco: i just opened #32454 with the spanning forest algorithm
<sipa>
eugenesiegel: one use case is a business having a bridge node (connected to both internal nodes and the public P2P network), where internal wallet nodes create transactions and broadcast and rebroadthem
<sipa>
if a wallet in the internal network tries to rebroadcast, the bridge node will just ignore it, and not relay the rebroadcast
<eugenesiegel>
sipa: hmm, makes sense -- I'm guessing there could be other use cases as well that I don't know about. since these peers do have more permissions and are more "trusted", where is the line drawn as far as what they can do to the local bitcoind instance?
<gmaxwell>
eugenesiegel: there are just a very few things, you can see them enumerated in net_permissions.h
<sipa>
eugenesiegel: i think the line is: permission flags correspond to an assumption that the specified node is trusted not to exhibit a certain kind of DoSy behavior
<sipa>
but i don't think we should for example ever have a permission flag that results in not validating transactions or blocks from said peer
<gmaxwell>
and they also mostly I think correspond to behavior where the p2p protocol was made more restricted or more rate limited but doing so would potentially mess up someones 'internal' use.
<sipa>
Yeah, when txrequest was introduced we reduced the total amount of simultaneously-tracked transactions being relayed from 50000 to 5000 or so IIRC, but there was a potential concern that some internal corporaty setup might exist that every so often dumps an enormous amount of transactions at once on the network - so with a net permission that was allowed to be bypassed
<sipa>
that said, i don't know of any actual usage of these flags
<gmaxwell>
Or like mempool was a p2p feature that was removed.
<brunoerg>
Another use case is to speed up tx relay/mempool sync on functional tests.
<sipa>
it may be because they're only used inside non-open source setups or test environments
<gmaxwell>
yeah I wouldn't be surprised if ~no one uses them in practice. There are a bunch of bitcoin core features that are probably unused, but it's not really possible to tell beyond removing it and seeing who complains. :P
<eugenesiegel>
Interesting, that makes a lot of sense that these were to preserve behavior prior to rate-limit / restrictive functionality
<eugenesiegel>
rate-limiting*
<gmaxwell>
(even if they were used when deployed, e.g. someone used them to keep an existing setup working, but they subsiquently redid it and forgot the option existed)
<sipa>
gmaxwell: still, it's nice to have them when the change is introduced because we might not know... having the flag means that *if* someone complains you can respond that they can just turn on the flag, rather than not upgrade, or build a patched version
<gmaxwell>
absolutely.
<eugenesiegel>
I was looking into this because of the change from int32 -> int64 in the addrman and was wondering if a peer with the ADDR permission could crash the node. However, if the node operator has given a malicious node this permission, good luck I guess
<eugenesiegel>
could crash the node prior to the patch*
<gmaxwell>
I mean I also like some of these in theory, but I suspect in practice almost no one does configurations that elaborate. like whitelisted friend nodes would be nice and make me feel safer against some accidental screwup in banning logic (well, thats much less of an issue now that banning is less of a thing)
<eugenesiegel>
I think there could be one sufficiently paranoid person that uses these options. I do like that these options are available though
<gmaxwell>
eugenesiegel: regarding vulnerablities, I think it's a mixed bag. They sound pretty benign and so it might not be hard to trick someone into enabling one. Of course, if the result really just is a clean crash then meh.
<gmaxwell>
eugenesiegel: but like if there was an RCE behind one of these it would be concerning indeed.
<gmaxwell>
I'd like to hope that bitcoin core is secure against an extended threat model where a social engineer can convince a user to make safe sounding settings changes and the result is hopefully no worse than a denial of service.
pablomartin_ has joined #bitcoin-core-dev
<gmaxwell>
certantly scammers on social media respond to users technical questions and try to get them to do stuff.
<gmaxwell>
fortunately most users resist "send me your wallet" :P
<sipa>
gmaxwell: selection bias! those users who don't resist this stop being users
<sipa>
or survivership bias, i guess
<eugenesiegel>
gmaxwell: thanks, the clarification for DoS vs. RCE puts things into a little more perspective. I should look into the historical RCEs because those classes of bugs are super interesting to me
<gmaxwell>
it's been a minute but we did see attackers have people set rpcuser/password. part of the bind dance was to make that harder.
<gmaxwell>
eugenesiegel: there have been close to none. uhh. upnp was I think (but took wumpus a LONG time to figure out how). I'm drawing a blank beyond that.
<sipa>
upnp is also the only thing i can come up with
<eugenesiegel>
hmm maybe I'm just thinking of the upnp one then
<gmaxwell>
the heartbleed one was an information leak that could have been almost as bad though IIRC there were some mitigating factors.
<gmaxwell>
but of course you never know for sure if something it's exploitable.
<darosior>
sipa: re net permissions flags "that said, i don't know of any actual usage of these flags" -> BTCPayServer needs some whitelisting because they use the p2p interface of your node, as far as i remember.
szarka has quit [Read error: Connection reset by peer]
szarka has joined #bitcoin-core-dev
aleggg has quit [Ping timeout: 272 seconds]
aleggg has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
Guest41 has quit [Ping timeout: 240 seconds]
Cory10 has quit [Quit: Client closed]
Cory10 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fjahr opened pull request #32575: RFC: refactor: Split multithreaded case out of CheckInputScripts (master...2025-05-CheckInputScript-split) https://github.com/bitcoin/bitcoin/pull/32575
<bitcoin-git>
[bitcoin] fjahr closed pull request #32133: RFC: Accept non-std transactions in Testnet4 by default again (master...2025-03-nonstd-testnet) https://github.com/bitcoin/bitcoin/pull/32133
Christoph_ has quit [Quit: Christoph_]
Cory10 has quit [Quit: Client closed]
Cory10 has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
Holz has quit [Ping timeout: 252 seconds]
Cory10 has quit [Quit: Client closed]
Cory10 has joined #bitcoin-core-dev
ThePlebRoad has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest41 has joined #bitcoin-core-dev
AtleoS has joined #bitcoin-core-dev
pablomartin_ has joined #bitcoin-core-dev
pablomartin_ has quit [Read error: Connection reset by peer]