kevkevin has quit [Remote host closed the connection]
eugenesiegel has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
kevkevin has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
<glozow>
Could we get a "Tracking issue" label? It'd be a nice way to find all the tracking issues, and make it easier to label an issue as "the place to post updates about a longer-running project"
<glozow>
Also requesting that we do tracking issues for minor releases, as a place to link all the PRs and post updates on bins, tags, etc.
<bitcoin-git>
[bitcoin] fanquake merged pull request #33581: ci: Properly include $FILE_ENV in DEPENDS_HASH (master...ci-depends-hash-file-env) https://github.com/bitcoin/bitcoin/pull/33581
jonatack has quit [Ping timeout: 256 seconds]
<bitcoin-git>
[bitcoin] purpleKarrot opened pull request #33585: cmake: Use builtin support for .manifest files (master...win32-manifest) https://github.com/bitcoin/bitcoin/pull/33585
<sipa>
glozow: yeah, though 28676 is rebased on top of 33157 already, and it doesn't really impact the interface, so 28676 can be reviewed fine right now too
<sipa>
it doesn't need to actually blocked by it
Emc99 has joined #bitcoin-core-dev
<sipa>
that's it from me
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
#29675 has been getting review which I've been addressing. It's got 3 ACKs now so I think it's probably rfm.
<corebot`>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<achow101>
#topic Releases
<achow101>
v30.0rc3 is up, and the tag for final is scheduled for tomorrow. Have any new issues been found in testing?
<achow101>
28.3rc1 and 29.2rc2 are also up for testing as well
sbddesign has joined #bitcoin-core-dev
<achow101>
Or any other topics to discuss this week?
dzxzg2 has quit [Read error: Connection reset by peer]
<phantomcircuit>
sipa, on #33335, the behavior where a tie is broken by wtxid means it's more likely that nodes mempools match miners mempools for compact block reconstruction, tie breaking using random per node values would very likely make compact block reconstruction rates worse, though im not sure exactly how much worse
<corebot`>
https://github.com/bitcoin/bitcoin/issues/33335 | txgraph: randomize order of same-feerate distinct-cluster transactions by sipa · Pull Request #33335 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] bavani-2024-aia opened pull request #33587: No remote repository configured (fatal: 'origin' does not appear to be a git repository)Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/33587
<bitcoin-git>
[bitcoin] DrahtBot closed pull request #33587: No remote repository configured (fatal: 'origin' does not appear to be a git repository)Add files via upload (master...master) https://github.com/bitcoin/bitcoin/pull/33587
<sipa>
phantomcircuit: yeah, i considered that - but i think it really only matters in fairly adverserial settings, and in those, there are many ways to trigger inconsistencies
<sipa>
(plus, wtxid ordering possibly opens an attack vector too, by grinding wtxids)
<phantomcircuit>
sipa, i believe it matters in the non-adversarial setting where nodes mempools are yoyo'ing around being full for a bit and then empty completely, with random ordering the transactions that just barely survived being ejected will be random between nodes while the higher fee transactions will be consistent, but as the mempool drains we'll get into those transactions that were on the edge and have maximally different mempools
kevkevin has quit [Remote host closed the connection]
<instagibbs>
looking at the last PR, IIUC this is only being used for INV ordering
<sipa>
instagibbs: it should affect eviction too
<instagibbs>
gotta re-read clearly
<phantomcircuit>
grinding wtxid's seems like an acceptable issue since it doesn't help skip the queue or anything so unless there's some other issue im missing iono why that matters
<phantomcircuit>
i mean it helps skip the queue but only if you're already at the very end which seems kinda irrelevant
<sipa>
i hadn't really considered eviction here, only INV ordering
<phantomcircuit>
yeah for inv ordering random is better, but for eviction deterministic is better
<instagibbs>
ah hm right, changes ChunkOrder too
<_aj_>
phantomcircuit: are you assuming no one rebroadcasts the evicted txs when they're no longer below the minimum fee?
<sipa>
phantomcircuit: i think the same issue applies already, depending on the ordering of transactions received, you may evict just slightly more or slightly less transactions every time the max is hit
<phantomcircuit>
_aj_, no im assuming that they do actually
<sipa>
random ordering may make it somewhat worse, but i don't think it qualitatively changes anything - mempool ranges which spent lots of time near the eviction point will be inconsistent already
<_aj_>
phantomcircuit: what's the problem you're seeing then?
<phantomcircuit>
_aj_, the issue is when things get evicted and then re-broadcast after the mempool shrinks, then those transactions are the same feerate so won't be replaced and nodes will end up with mempools with transactions that are the same feerate but different transactions, which makes compact block relay worse
<sipa>
i'm pushing back, because having multiple different orderings would be a huge pain, and random is easier just from an abstraction perspective (txgraph doesn't need to be aware of anything but fees/sizes/dependencies)
<_aj_>
phantomcircuit: if the chunks have equal feerates but conflict because the signers of the txs are playing silly games?
<instagibbs>
extremely flat mempools would get completely random evictions?
<sipa>
instagibbs: yup, which is likely preferable over biasing low wtxids
<phantomcircuit>
i haven't considered it enough to say it would effect more than like one block every 300/$MEAN_BLOCK_SIZE blocks
<phantomcircuit>
and only when the feerate is dropping and the mempool is emptying
<sipa>
at least they'll all get slightly degraded relay, as opposed to picking winners and losers that get perfect and terrible relay
<_aj_>
oh, like the top feerate is 10sat/vb, but there's 600MvB of txs between 10sat/vb and 9.9sat/vb?
<_aj_>
but everyone's going to just say "for a feebump to an 11sat/vb i guarantee next block? okay then"
<phantomcircuit>
sipa, so the issue kinda exists now except that there's nodes with larger than default mempools re-broadcasting their entire mempool every so often, so things that get dropped at the edge tend to get re-added
<phantomcircuit>
so as long as the re-adding is deterministic the top part of mempools tends to be similar
<phantomcircuit>
sipa, yeah iono if im even making an argument for something here, just pointing out something that it seems should be considered
<sipa>
also, wtxid ordering is pretty hard to make consistent with chunk ordering; it probably needs something like "among equal-chunk-feerate distinct-cluster transactions, sort by the wtxid of the first transaction in the cluster with that chunk feerate"
<sipa>
it's not a simpe "sort by wtxid"
dzxzg has quit []
dzxzg2 has joined #bitcoin-core-dev
<_aj_>
sipa: sort by the *last* transaction in the chunk?
<phantomcircuit>
_aj_, if the chunks have equal feerates but there's multiple conflicting chunks a deterministic decisions on who "wins" would "fix" that
<sipa>
_aj_: it'd need to be sort by the last transaction in the last chunk in the cluster with the same feerate
<bitcoin-git>
[bitcoin] bavani-2024-aia opened pull request #33588: config.ini headers missing causes test framework failure (master...master) https://github.com/bitcoin/bitcoin/pull/33588
<sipa>
_aj_: otherwise you get inconsistent if there are multiple equal-feerate chunks in a cluster
<_aj_>
phantomcircuit: should only matter if the feerate of the worst chunk in the top 1MvB of the mempool is the same as the feerate of the worst chunk in the mempool, though, which just seems vanishingly unlikely to me? anything else, you'll just be picking the txs up from slightly lower in the mempool which is fine
<phantomcircuit>
sipa, anyways this is my monkey wrench for the day good luck *ducks*
<_aj_>
sipa: sort the chunks in the cluster in the same way though?
<sipa>
_aj_: they may have dependencies between them that require a particular order
sbddesign has quit [Ping timeout: 256 seconds]
eugenesiegel has quit [Quit: Client closed]
<_aj_>
sipa: fair, i guess
<phantomcircuit>
_aj_, no you have to think about it overtime, consider that the bottom feerate cluster is where a tie actually matters, so one of 2 clusters gets evicted, then the overall feerate declines and that cluster ends up being in next mined block, you won't replace the decision you made on which cluster to pick
<phantomcircuit>
i think with re-broadcasts this is only an issue if the clusters are *also* trying to spend the same outputs
<bitcoin-git>
[bitcoin] bavani-2024-aia opened pull request #33589: config.ini headers missing causes test framework failure (master...master) https://github.com/bitcoin/bitcoin/pull/33589
<_aj_>
phantomcircuit: if it's getting mined in the next block, why hasn't it been rebroadcast before then?
jonatack has quit [Ping timeout: 256 seconds]
memset has joined #bitcoin-core-dev
<phantomcircuit>
sipa, actually i guess this is an issue for all feerates regardless if they're mutually exclusive in which case using random values would give an attacker trying to fragment the mempool an advantage
<sipa>
we have no way of making mempools confluent in the case of conflicting transactions received in distinct order
<phantomcircuit>
i think the ordering for eviction has to be consistent to avoid that
<phantomcircuit>
i guess today we don't handle this and just whoever is first wins
<phantomcircuit>
which is kinda a "speed of light wins" tie breaker
<sipa>
sdaftuar points out that today we tie-break eviction by latest received first
<phantomcircuit>
and i guess that prevents a DoS churn issue with grinding wtxids
memset_ has quit [Ping timeout: 272 seconds]
DurchDenMonsun has joined #bitcoin-core-dev
<phantomcircuit>
sipa, so wouldn't that mean we leak the same ordering information you're trying to avoid leaking if nodes can figure out if we have a tx in our mempool?
<sipa>
phantomcircuit: that's already the case due to conflicts, though
jerryf_ has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
DurchDenMonsun has quit [Changing host]
DurchDenMonsun has joined #bitcoin-core-dev
<DurchDenMonsun>
Hi guys, How to disable logs complete in bitcoin core? new to this stuff and just want to run wallet without mining and without wearing out my ssd drive.
memset has quit [Remote host closed the connection]
f321x_ has quit [Quit: f321x_]
memset has joined #bitcoin-core-dev
<sipa>
DurchDenMonsun: you can't disable logging entirely, but just synchronization with the network (downloading, storing, and processing new blocks as they are found) will have a much bigger impact on your drive
Talkless has joined #bitcoin-core-dev
<sdaftuar>
phantomcircuit: my conjecture is that it would be very rare that randomized eviction will cause an issue. i think we can get some kind of sense of whether that is true by measuring how often (on historical data) we might mine a block that would include mempool transactions below the minimum feerate required to be relayed.
<DurchDenMonsun>
Hi sipa: thanks for replaying, any tips how to tweak the config so it will use less writing to my ssd?
<DurchDenMonsun>
for 2 core 4gb ram system.
<sipa>
DurchDenMonsun: this isn't really a place for support, but you can ask questions on https://bitcoin.stackexchange.com (i'm pretty active myself answering questions there)
l0rinc has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
<DurchDenMonsun>
Ok, i'll try that. I also tried to register on bitcointalk, but it seems that the IP I am using has been blacklisted. It's really unfortunate because the biggest ISP in my country provides dynamic IPs to home users.
sbddesign has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 260 seconds]
memset has quit [Remote host closed the connection]
<phantomcircuit>
sipa, yeah i meant that the current state was that we leak the ordering currently
<glozow>
that's what I meant yes
<phantomcircuit>
sdaftuar, that doesn't sound right to me, but im now too tired to really think about the edge off the edge case
<phantomcircuit>
but also it does sound like the thing sipa is proposing isn't strictly worse than ordering based on speed of light race
<Ademan>
congrats y'all
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
thoragh has quit [Read error: Connection reset by peer]
<sipa>
yay
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
<darosior>
\o/
memset_ has joined #bitcoin-core-dev
memset has quit [Ping timeout: 272 seconds]
<bitcoin-git>
[bitcoin] amishhaa opened pull request #33592: Contrib: Updated macdeployqtplus to remove deprecated --deep signing (master...fix-deep-arg) https://github.com/bitcoin/bitcoin/pull/33592
jonatack has quit [Ping timeout: 255 seconds]
jonatack has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] hebasto opened pull request #33593: guix: Use UCRT runtime for Windows release binaries (master...251009-guix-ucrt) https://github.com/bitcoin/bitcoin/pull/33593