--- Log opened Thu Sep 18 00:00:43 2025
00:00 -!- vincenzopalazzo [~vincenzop@static.14.246.108.65.clients.your-server.de] has joined #bitcoin-core-dev
00:16 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:23 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
00:28 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
00:28 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:28 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
00:29 -!- f321x [~f321x@user/f321x] has quit [Client Quit]
00:30 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:39 -!- saturday7 [~saturday7@206.83.123.110] has quit [Ping timeout: 244 seconds]
00:40 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
00:43 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:45 -!- janb84 [~janb84@user/janb84] has quit [Ping timeout: 248 seconds]
00:47 -!- janb84 [~janb84@user/janb84] has joined #bitcoin-core-dev
01:13 -!- Guyver2_ [Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:14 -!- rszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
01:16 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Ping timeout: 256 seconds]
01:16 -!- thelounge496669 [~thelounge@149.106.235.56] has quit [Read error: Connection reset by peer]
01:17 -!- robszarka [~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b] has quit [Ping timeout: 260 seconds]
01:23 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
01:27 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:29 -!- saturday7 [~saturday7@206.83.123.110] has quit [Client Quit]
01:32 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:43 -!- Guyver2_ [Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
01:49 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
01:50 -!- Cory51 [~Cory47@user/pasha] has quit [Quit: Client closed]
01:51 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
01:54 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:58 -!- saturday7 [~saturday7@206.83.123.110] has quit [Client Quit]
02:05 -!- vincenzopalazzo [~vincenzop@static.14.246.108.65.clients.your-server.de] has quit [Read error: Connection reset by peer]
02:12 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
02:20 -!- sdfgsdfg3d [~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1] has joined #bitcoin-core-dev
02:53 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
03:22 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
03:25 -!- sdfgsdfg3d [~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1] has quit [Quit: Client closed]
04:07 < sipa> _aj_: hmm, looking at the formula, it's just BASE + (to_send.size() / 1000) * 5, so the adaptive behavior does not kick in until the backlog is 1000 txn
04:08 < sipa> if we think that's too much, maybe it's just the 1000 constant that should be reduced?
04:09 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
04:12 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Client Quit]
04:14 < sipa> any reason not to do (BASE + to_send.size() / 200) ? 
04:48 -!- f321x [~f321x@user/f321x] has quit [Remote host closed the connection]
04:49 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
04:56 -!- robszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
04:59 -!- rszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has quit [Ping timeout: 256 seconds]
05:14 -!- robszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has quit [Quit: Leaving]
05:14 -!- szarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
05:15 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
05:15 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
05:19 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
05:25 < hebasto> #proposedmeetingtopic Support for Ubuntu 22.04 LTS as a build platform
05:39 < _aj_> sipa: the behaviour i was seeing is more the inv queue spiking to ~5000 then sticking there for a little while for a handful of nodes (presumably spy nodes who neer inv us, or poorly connected 0.1sat/vb nodes who don't have another source for many txs), for which i don't think that alternative would help much. i thought the argument that "7 tx/sec was chosen pre-segwit, and we've doubled capacity 
05:39 < _aj_> since then so should have already switched to 14 tx/sec" made sense though? although i guess that argument was in #27630 but not re-stated in the new pr.
05:39 < corebot> https://github.com/bitcoin/bitcoin/issues/27630 | p2p: Increase tx relay rate by sdaftuar · Pull Request #27630 · bitcoin/bitcoin · GitHub
05:40 < _aj_> sipa: iirc i felt like immediately bumping the rate by +1 when the queue was >200 entries was a potential privacy leak, so thought some quantizing was a good idea
05:50 < sipa> _aj_: yeah, i don't object to raising it 2x, but want to reason through it a bit more
05:55 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
05:57 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
06:04 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
06:08 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
06:14 -!- Guest73 [~Guest73@143.105.151.212] has joined #bitcoin-core-dev
06:18 -!- Guest73 [~Guest73@143.105.151.212] has quit [Client Quit]
06:29 < darosior> Relevant to this discussion: https://mainnet.observer/charts/transactions-per-day/
06:30 < darosior> The last setting was chosen in April 2016, when there was between 200-220k transactions a day. Nowadays there is between 400k and 600k transactions a day.
06:40 < darosior> 200k transactions a day is 2.3 tx/s. Why was the value chosen to be thrice as much?
06:41 < sipa> darosior: well you don't want the rate limit to be set to the expected value, because then you'll always have a backlog
06:41 < sipa> so you want some overshoot to account for temporary variations around the average
06:42 < instagibbs> aside: should we hard cap the inv queue size at some count? theoretically hard to hit but unbounded growth (even with fee payers) seems not great
06:42 < darosior> Ok, i was thinking of it as the default value should roughly match usage, and the temporary increase would kick in for periods of above-average usage.
06:45 < darosior> instagibbs: can it really be hit? Because the number of transaction you send will also grow arbitrarily large with the size of inv_to_send
06:46 < sipa> darosior: in the steady state, the size of the queue will be ~200x the number of transactions you receive between any two sends
06:47 < sipa> for sufficiently large inbound tx rate
06:47 < instagibbs> Probably impossible in practice due to rate limiting of peers incoming messages or something else I missed? Have a set of 100 peers send tiny high paying fee txns directly, see what happens to inv queues?
06:48 < darosior> instagibbs: yeah would be interesting to have a functional test for this. I suspect it would just lead you to blast INV messages to your peers.
06:48 < sipa> per peer you're limited by the roundtrip time of an INV-GETDATA-TX cycle, times the number of transactions permitted in txrequest
06:49 < instagibbs> I suppose it would be hard for attacker to get their hands on the txs fast enough, be first to send them to you unilaterally
06:52 < darosior> sipa: sorry could you expand on the ~200x figure? Not sure to follow.
06:53 < sipa> darosior: the formula for how much to send, approximated, is (invs_to_send.size() / 200)
06:53 < sipa> in the steady state, the amount of tx you send equals how many transactions get added to the queue in between two sends
06:54 < sipa> so if you receive say 300 transactions between every two sends, the queue size will tend to grow to a point where invs_to_send.size() / 200 equals 300
06:54 < sipa> which is when invs_to_send.size() == 200 * 300 = 60000
06:55 < darosior> Ok it's the "steady state" definition that i was missing. I wasn't seeing how if you receive on average 2.3 tx per second and send 35 every 5 seconds you end up with a queue of size 200 * 5 * 2.3. Thanks.
06:56 < sipa> darosior: well the steady state is what you end up
06:57 < sipa> the queue will grow until it hits that point
06:59 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
07:04 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Client Quit]
07:06  * darosior clarified with sipa IRL, he was talking about instagibbs' question i was talking about _aj_'s proposal to increase the default rate
07:07 -!- jespada [~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60] has joined #bitcoin-core-dev
07:07 < sipa> _aj_: do we actually care about treating the size of the queue as secret for fingerprinting reasons? because an attacker observing it gets to see the actual transactions too, which seems like a much stronger signal anyway
07:08 < sipa> if not, i'd suggest something simpler like always send the top 20-40% (randomly selected) of the queue?
07:09 < sipa> darosior points out that that may mean never actually sending the bottom part
07:09 < instagibbs> darosior ok them I'm confused now
07:10 < instagibbs> just throwing an idea out there, I've not thought hard about it
07:10 < sipa> instagibbs: my answer to your question is: in the steady state, queue sizes (with the current formula) will grow proportionally with the incoming transaction rate
07:10 < instagibbs> sipa 👍
07:10 < sipa> so they can be unbounded, but only if the incoming transaction rate is unbounded, and txgraph prevents that
07:11 < sipa> eh, txrequest
07:11 < sipa> but the rate can be pretty high
07:11 < darosior> txgraph txrequest txdownload
07:11 < instagibbs> I think it only seems problematic if nodes arent sending invs to you and direct sending
07:11 < darosior> tx* is the new *man
07:12 < sipa> needs more "mini"
07:13 < sipa> minitxman
07:14 < darosior> if we call it mini it cannot grow unbounded
07:15 < sipa> right
07:16 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
07:17 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
07:17 -!- jespada [~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60] has quit [Ping timeout: 244 seconds]
07:17 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
07:26 < darosior> _aj_: so assuming we keep the same mechanism it makes sense to me to increase the default relay rate. This is because we've observed average transaction rate in the past years that were higher than 7 tx/s. But i'm not sure about doubling it though. We've never witnessed a sustained rate anywhere close to 14 tx/s. According to
07:26 < darosior> https://mainnet.observer/charts/transactions-per-day/ the highest we've been using a 30-day moving average is ~7.75 tx/s, and using a 7-day moving average 8.6 tx/s. So it seems that using 14 tx/s would not be different from not having any limit 99.9% of the time?
07:26 < darosior> s/the highest we've been/the highest we've seen/
07:31 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Quit: Christoph_]
07:34 < sipa> another idea: add insertion time into the to_send queue, and always send everything whose insertion time is more than X seconds ago (which becomes some sort of timeout)
07:34 < sipa> plus X% of the highest-feerate stuff in the queue that isn't timed out yet
07:37 < instagibbs> dont have to sort timed out stuff either 
07:37 < instagibbs> iiuc
07:38 < sipa> we may still want to, to guarantee topology
07:38 < sipa> and probably better for privacy anyway
07:38 < instagibbs> ah right
07:38 < instagibbs> doing stuff before sorting can help if you're *dropping* it for various reasons
07:40 < sipa> yet another idea is to see where transactions fit in your mempool (in terms of how many MvB from top), and send everything that's up to say 2 MvB from the top, and X% of the rest
07:44 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
07:45 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
07:48 < _aj_> instagibbs: capping the inv queue isn't great, because we sort high-fee child transactions after low-fee txs that only spend confirmed txs. maybe we could sort better with cluster mempool? alternatively, if we had rebroadcast behaviour, dropping some txs would be less of a problem
07:49 < instagibbs> clearly not optimal, only better than crashing
07:52 < _aj_> sipa: i suspect we don't care about keeping the queue size secret -- we effectively consider the contents of the mempool at inv-send-time public anyway
07:52 < sipa> right
07:52 < sipa> the primary privacy benefit the queueing/batching has is hiding the relative order of transactions
07:54 < _aj_> darosior: "mini-inf, another name for aleph0 or the cardinality of the integers, ..."
07:57 < _aj_> darosior: 2024-04-23 on that graph claims 927010 txs per day, which is 10.7/second
07:57 < sipa> hmmm, i think my conclusion is that we should really set the amount of transaction sent as a function of the time since the last send
07:58 < sipa> because it's a bandwidth consideration... we have some tx send rate that we think would be harmful for (some?) peers, and when we approach that, and can't send everything anymore, we should prefer higher-feerate things
07:59 < sipa> but in addition, from a personal DoS protection perspective, we need to limit the size of the queue
08:00 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:01 < sipa> what about: send_now = std::min(to_send.size(), time_since_last_send * R + (to_send.size() ** 2) / M)
08:01 < sipa> where R is the "everyone can handle this tx rate" number, and M is the maximum queue size
08:03 < sipa> R could be different for outbound and inbound; if not, the number of txn per inv will be lower for outbounds than for inbounds, as they have more frequent sends - but maybe that's ok
08:04 < _aj_> i think the main benefit of the queue is that it allows the network to prioritise relaying the high-pri/high-fee txs at a rate similar to what can be confirmed, relegating low fee backlog txs to only being relayed when there's a lull. my take is that in that context, just dropping the low fee txs and not relaying them at all would be better, provided there's some way for them to get picked back up 
08:04 < _aj_> when the mempool empties out (which could just be "the sending wallet resubmits")
08:05 < sipa> _aj_: agreed, but i think dropping would be bad absent mempool retransmission - i'm not sure how reliably the network deals with resubmission on its own
08:07 < _aj_> sure, bip153/sendtemplate's my answer to that :)
08:07 < _aj_> anyone remember how many txs were in the mempool back when we had huge backlogs?
08:09 < _aj_> hmm, i have significantly fewer txs in my mempool than mempool.space reports (87k vs 130k?)
08:11 < sipa> is there an RPC to get node uptime?
08:12 < sipa> ah, `uptime` ~!
08:12 < fanquake> uptime
08:12 < sipa> that was way too obvious
08:12 < sipa> why isn't it getnodeuptimeinfo ?
08:13 < sipa> _aj_: i have 117230 txn right now on my long-running node's mempool (which was recently updated to 0.1 sat/kvB policy ~33 days ago)
08:13 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
08:14 < sipa> eh
08:14 < sipa> 100 sat/kvB or 0.1 sat/vB
08:17 < fanquake> sipa: how long running?
08:17 < sipa> 33 days
08:18 < _aj_> #10400 ; could have gone into `getinfo`, but that was already being deprecated
08:18 < corebot> https://github.com/bitcoin/bitcoin/issues/10400 | [RPC] Add an uptime command that displays the amount of time (in seconds) bitcoind has been running by rvelhote · Pull Request #10400 · bitcoin/bitcoin · GitHub
08:23 -!- dzxzg [~qualify@user/dzxzg] has quit [Quit: Konversation terminated!]
08:23 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:23 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
08:24 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
08:25 < _aj_> ah, a thought i had was that you could: (a) add a relayed_at timestamp to txs in the mempool, with index; (b) add a relayed_upto timestamp for each peer; (c) add txs to a peer's inv_to_send and update relayed_upto correspondingly in order, but stop once the inv_to_send hits 1000 txs; (d) sort and drain inv_to_send as currently. that way lagging peers will just get worse tx info during bursts, 
08:25 < _aj_> without using up extra memory or compute
08:32 < sipa> the mempool relayed_at index would use memory?
08:32 < _aj_> whether or not peers lag wouldn't change how much memory was used, i mean
08:33 < _aj_> i'm not sure why i wanted a timestamp rather than just the mempool seq number? maybe so you could time things out? or maybe i was just confused
08:35 -!- purpleKarrot [~purpleKar@185.240.173.188] has joined #bitcoin-core-dev
08:36 < _aj_> ohhh, i should read my notes. the idea was to have "rebroadcasting" happen by updating the relayed_at timestamp, but that could mean a parent's relayed_at timestamp was later than one of its children
08:37 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
08:38 < _aj_> (ie, rebroadcasting via existing methods that currently work such as the wallet or sendrawtransaction)
08:39 -!- Cory44 [~Cory51@user/pasha] has joined #bitcoin-core-dev
08:40 -!- dzxzg [~qualify@user/dzxzg] has quit [Quit: Konversation terminated!]
08:42 -!- alvroble [~alvroble@user/alvroble] has joined #bitcoin-core-dev
08:42 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
08:43 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
08:48 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
08:48 -!- BGL [ninety@75.149.171.58] has quit [Ping timeout: 260 seconds]
08:49 -!- enochazariah [~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498] has joined #bitcoin-core-dev
08:49 -!- jeremyrubin [~jeremyrub@ec2-44-199-24-18.compute-1.amazonaws.com] has joined #bitcoin-core-dev
08:49 < QUBIT_ABHAY> hi
08:49 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:49 -!- enochazariah70 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has joined #bitcoin-core-dev
08:51 -!- enochazariah70 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has quit [Client Quit]
08:52 -!- enochazariah89 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has joined #bitcoin-core-dev
08:53 -!- enochazariah24 [~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6] has joined #bitcoin-core-dev
08:53 -!- enochazariah24 [~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6] has quit [Client Quit]
08:53 -!- enochazariah [~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498] has quit [Ping timeout: 250 seconds]
08:54 -!- enochazariah [uid710351@id-710351.hampstead.irccloud.com] has joined #bitcoin-core-dev
08:56 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
08:56 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
08:56 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
08:56 -!- enochazariah89 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has quit [Ping timeout: 250 seconds]
08:57 -!- Cory90 [~Cory44@user/pasha] has joined #bitcoin-core-dev
08:59 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:59 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]
09:00 -!- Cory44 [~Cory51@user/pasha] has quit [Ping timeout: 250 seconds]
09:00 < achow101> #startmeeting
09:00 < corebot> achow101: Meeting started at 2025-09-18T16:00+0000
09:00 < corebot> achow101: Current chairs: achow101
09:00 < corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
09:00 < corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
09:00 < corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
09:00 < Sjors[m]1> hi
09:00 < darosior> hi
09:00 < janb84> hi
09:00 < hebasto> hi
09:00 < dzxzg> hi hi
09:00 < sipa> hi
09:00 < achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
09:00 < instagibbs> hi
09:00 < hodlinator> hi
09:01 < QUBIT_ABHAY> hi
09:01 < pinheadmz> 🪇
09:01 < TheCharlatan> hi
09:01 < abubakarsadiq> hi
09:01 < alvroble> hi
09:01 < Murch[m]> hi
09:01 < achow101> There is 1 preproposed meeting topic this week, any last minute ones to add?
09:01 < brunoerg_> hi
09:01 < QUBIT_ABHAY> #here
09:01 < lightlike> hi
09:01 < laanwj> hi
09:02 < achow101> #topic Kernel WG Update (TheCharlatan)
09:02 < kanzure> hi
09:03 < TheCharlatan> not much to share this week besides wanting to ask for review on the API PR #30595
09:03 < corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
09:03 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
09:03 < eugenesiegel> hi
09:03 < l0rinc> hi
09:03 < TheCharlatan> a bunch of people and teams are building on top of it now, which led to a bunch of improvements on it the past few months. 
09:04 < TheCharlatan> that's all
09:04 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
09:05 < sipa> main PR to review remains sdaftuar's #28676
09:05 < corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
09:05 < sipa> which has been rebased and is getting reviews addressed
09:06 < sipa> in parallel, i have a few other PRs; i think #33157 is close (28676 is rebased on top of that one, so it's a dependency)
09:06 < corebot> https://github.com/bitcoin/bitcoin/issues/33157 | cluster mempool: control/optimize TxGraph memory usage by sipa · Pull Request #33157 · bitcoin/bitcoin · GitHub
09:06 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
09:06 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:07 < sipa> we've been talking with glozow and sdaftuar about package RBF, for after cluster mempool
09:07 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]
09:07 < jonatack> hi
09:07 < sipa> that's it from me, i think
09:07 < instagibbs> sipa I wouldnt mind being included
09:08 < sipa> #include "instagibbs.h"
09:08 < corebot> sipa: Unknown command: #include
09:08 < glozow> from gibbs import insta
09:08 < achow101> #topic Stratum v2 WG Update (sjors)
09:08 < Sjors[m]1> Review welcome on #33374. Would be nice to get in v30, but no need to delay the release for it. 
09:08 < Sjors[m]1> There's also a bunch of fixes that have been backported, not sure when we want to cut rc2?
09:08 < Sjors[m]1> ryanofsky anything you need? Just a subtree update or more?
09:08 < corebot> https://github.com/bitcoin/bitcoin/issues/33374 | mining: add applySolution() to interface by Sjors · Pull Request #33374 · bitcoin/bitcoin · GitHub
09:09 < fanquake> sjors: how are you planning to handle version in the multiprocess subtree going forward?
09:09 < fanquake> *versioning
09:09 < Sjors[m]1> fanquake: do you mean versioning of the interface or of the multiprocess dependency?
09:10 < fanquake> I'm guessing release branches to match Core? Otherwise I'm wondering what the plan is if you need to land bugfixes from multiprocess that wont apply to release branches, due to api changes or similar
09:10 < Sjors[m]1> For the latter we should probably tag whatever is in v30
09:10 < fanquake> We also don't generally backport subtree updates, so this would also be new for multiprocess
09:10 < sipa> if a subtree has a bugfix that matters, it does seem reasonable to backport it
09:11 < fanquake> Sure, but that might have to be selective, rather than a full pull
09:11 < sipa> yeah, makes sense
09:11 < fanquake> so by default isn't a clean backport
09:12 < fanquake> so just wondering what the plan is there, and if anything is going to be done to track things upstream in the multiproess repo
09:12 < Sjors[m]1> Maybe ryanofsky has a specific plan. I would imagine indeed having a seperate branch to track minimal changes if anything needs to be backported to v30.1+
09:13 < fanquake> Ok, can leave it up to you and him to figure out going forward
09:14 < achow101> #topic MuSig2 WG Update (achow101)
09:14 < achow101> No major updates. PR to review is #29675 and I've been addressing comments.
09:14 < 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
09:14 -!- Cory4 [~Cory90@user/pasha] has joined #bitcoin-core-dev
09:15 < achow101> #topic v30.0
09:16 < achow101> Any new issues found in testing rc1?
09:17 < darosior> I think we backported a few issues we found already, any plans on an rc2?
09:17 < achow101> Anything to add or remove from the milestone? https://github.com/bitcoin/bitcoin/milestone/72
09:17 < fanquake> rc2 changes in https://github.com/bitcoin/bitcoin/pull/33424
09:17 < hodlinator> #32132 causes an issue on master and probably rc1 with an extra uninstall entry on Windows.
09:17 < corebot> https://github.com/bitcoin/bitcoin/issues/32132 | build: Remove bitness suffix from Windows installer by hebasto · Pull Request #32132 · bitcoin/bitcoin · GitHub
09:17 -!- l0rinc_ [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
09:18 < fanquake> rc2 backports done so far https://github.com/bitcoin/bitcoin/pull/33356
09:18 -!- Cory21 [~Cory4@user/pasha] has joined #bitcoin-core-dev
09:18 -!- Cory90 [~Cory44@user/pasha] has quit [Ping timeout: 250 seconds]
09:18 < darosior> hodlinator: so should #33422 be added to the milestone?
09:18 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Ping timeout: 256 seconds]
09:18 < corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
09:18 < achow101> added #33422 to the milestone
09:18 < corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
09:18 < darosior> 🤝
09:19 < fanquake> we are so going to be cutting 29.2, 28.3 & maybe 27.3 releases in the near future
09:20 < darosior> 🚢
09:20 < hodlinator> Thanks! That or reverting the one-line change which introduced the issue, could get it in the next release.
09:21 < l0rinc_> Thanks for the reviews of the 2 PRs mentioned last week (#33333 and #33336)
09:21 < corebot> https://github.com/bitcoin/bitcoin/issues/33333 | coins: warn on oversized `-dbcache` by l0rinc · Pull Request #33333 · bitcoin/bitcoin · GitHub
09:21 < corebot> https://github.com/bitcoin/bitcoin/issues/33336 | log: always print initial signature verification state by l0rinc · Pull Request #33336 · bitcoin/bitcoin · GitHub
09:21 < l0rinc_> for the record, I've compared V30 to previous releases (23-29) and it seems V30 is exactly 2x faster than v25 thanks to all the optimization efforts in the past releases, see https://x.com/L0RINC/status/1968392472717033927
09:22 -!- Cory4 [~Cory90@user/pasha] has quit [Ping timeout: 250 seconds]
09:23 < achow101> #topic Support for Ubuntu 22.04 LTS as a build platform (hebasto)
09:23 < hebasto> Ubuntu 22.04 reaches end of standard support in April 2027. See: https://ubuntu.com/about/release-cycle
09:23 < hebasto> By the time Bitcoin Core v31.0 is released, Ubuntu 26.04 LTS will be available.
09:23 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:24 < hebasto> Ubuntu 22.04’s default repositories provide dependency packages that are outdated and problematic to maintain, such as: CMake 3.22.1, Qt 6.2.4, Cap'n Proto 0.8.0
09:24 < hebasto> Furthermore, Ubuntu 22.04’s default repositories do not provide the minimum required Clang version.
09:24 < hebasto> My initial proposed action was to stop considering Ubuntu 22.04 as a build platform starting from the v31 release cycle.
09:24 < hebasto> However, during conversation on IRC on 2025-09-09, sipa argued that we may end "in a situation where some important user chooses not to upgrade because they want to build from source, and they're stuck on an older platform"
09:24 < hebasto> And fanquake pointed on such real world case where "a lot of Armory users are stuck on v27 branch".
09:24 < sipa> do we actually have a "list of build platforms we support"?
09:25 < hebasto> nope, I guess
09:25 < fanquake> we've also since heard that a bunch of nodl (box?) users are also stuck on 27.x
09:25 < achow101> why are they stuck?
09:25 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 258 seconds]
09:25 < hebasto> Considering, that every problematic dependency package can be build by our own depends build subsystem, the remaining issue boils down to the minimum supported CMake version, which is 3.22 now.
09:25 < sipa> my impression is more that for individual upgrades/dependency requirements, we have an ad-hoc discussion for benefits vs. which use/build platforms those would drop
09:25 < hebasto> The question for my fellow collegues is can we ask users who will build Bitcoin Core v31+ from source on Ubuntu 22.04 to install newer CMake from https://cmake.org/download/ or from some other package manager?
09:26 < hebasto> If so, we can bump the minimum supported CMake version in the v31 release cycle up to 3.25, same as in Debian Bookworm (oldstable).
09:26 < darosior> Tangentially, i've had report of people stuck on  27 because of our glibc bump. fanquake also had some. I would suspect there is more. It probably means a lot of people that won't upgrade in case of vulnerability disclosures. I don't know the upsides to breaking support for some platform in this instance, but i'd like to underline there are
09:26 < darosior> substantial downsides to doing so.
09:26 < sipa> fanquake, darosior: but that's due to runtime requirements, not build time?
09:26 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
09:26 < fanquake> Why do we need to bump the minimum required CMake version?
09:26 < hebasto> This gives us a few useful features such as (1) file sets; (2) `COMPILE_WARNING_AS_ERROR`; (3) better support for IPO/LTO; (4) scope management
09:26 < sipa> hebasto: can we use those feature optionally?
09:26 < darosior> achow101: the nodl boxes are stuck because of our glibc bump in 28
09:26 < hebasto> Very useful for ongoing libkernel development
09:26 < sipa> (i'm guessing no from 1 and 4, yes for 2 and 3)
09:27 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
09:27 < fanquake> These seem like things that might be mostly nice for cmake devs/
09:27 < fanquake> *?
09:27 < achow101> I would prefer that we support platforms that are still in use and supported by upstream
09:27 < hebasto> sipa: some of them, yes
09:28 < achow101> if ubuntu 22.04 is supported until 2027, i'd rather not drop support for it until it is eol
09:28 < darosior> sipa: yes, my examples are runtime, that's why i said it's only tangentially related
09:28 < sipa> achow101: agreed
09:28 < darosior> achow101: +1
09:29 < hebasto> achow101: users still able build on ubuntu 22.04; they will need to install newer cmake
09:29 < fanquake> It'd atleast be good to see an example of changes that could be made after dropping. Hard to infer the benefits from that list
09:29 < fanquake> Also, what version are you trying to bump the minimum to?
09:29 < achow101> hebasto: I don't think asking users to update a dependency from external sources is a reasonable ask
09:29 < hebasto> fair
09:30 < sipa> specifically for (2), i think it's not unreasonable to enable it whenever cmake is recent enough, and not otherwise - which will give the benefit for most people who compile, but not break compatibility?
09:30 < fanquake> Oh, I see 3.25
09:30 < fanquake> sipa: not that we already also have that feature
09:30 < fanquake> *note
09:30 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Ping timeout: 250 seconds]
09:30 < fanquake> We just aren't using the CMake *thing*
09:30 < sipa> fanquake: sure, but we can simplify the cmake code with that feature, i assume - which is still possible by using it optionally
09:31 < fanquake> I'd think that'd be more code, if we retain the old way, and add the new way
09:31 < hebasto> ^ true
09:31 < fanquake> unless you mean drop support of the feature for older users
09:31 < sipa> fanquake: no, i mean use the new way, drop the old way
09:32 < hebasto> that needs bump the minimum supported version
09:32 < sipa> because people who care about the feature will almost certainly be on a new platform anyway (they're developers, not builders-on-old-platform-who-just-want-it-to-work)
09:32 < sipa> hebasto: can you not enable it optionally?
09:33 < hebasto> features that depends on cmake policy can be enabled optionally
09:33 < dzxzg> Won't the flag just be ignored if used in a cmake version below 3.24?
09:33 < hebasto> but also there are language features
09:33 < l0rinc_> do we need to add a separate CI build with an old cmake version in that case?
09:33 < hebasto> yes; with more coding
09:34 < sipa> (if we're done with this topic, i'd like to also discuss the possibility of bringing back runtime compatibility with glibc 2.28 (or whatever it is that causes the reports of people unable to upgrade))
09:35 < achow101> how difficult would it be to do that?
09:36 < fanquake> Have to look at undoing a number of changes in Guix
09:36 < fanquake> If people are trying to run on glibc < 2.28, I'm guessing this is on Ubuntu Bionic. Which shipped with 2.27
09:36 < hebasto> if I recall correctly, there were issues with qt as well
09:37 < darosior> One thing they could do to have new-bitcoind compatibility in their old machines would be to dockerize it. It's not impossible, but a bunch more work for them and therefore they're not doing it.
09:37 < fanquake> Bionic went EOL sometime in 2023 I think
09:37 < achow101> The bump was #29987
09:37 < corebot> https://github.com/bitcoin/bitcoin/issues/29987 | guix: build with glibc 2.31 by fanquake · Pull Request #29987 · bitcoin/bitcoin · GitHub
09:38 < fanquake> Would have to check if our current GCC would compile 2.27
09:38 < sipa> hebasto: i'm less concerned about that, i assume people stuck on old platforms tend to use bitcoind as a backend, not the gui
09:39 < fanquake> darosior: or we start shipping a flavour of static musl rel builds 
09:39 < hebasto> I agree, than gui probably should excluded from guix script for that purpose
09:40 < darosior> fanquake: 👁️
09:40 < fanquake> rebased my old branch for doing that earlier today: https://github.com/fanquake/bitcoin/tree/depends_musl_cross_make
09:40 < fanquake> Athough not sure we'd take that approach
09:40 < sipa> fanquake: what are the downsides, besides it being less well tested?
09:41 -!- Cory21 [~Cory4@user/pasha] has quit [Quit: Client closed]
09:41 -!- Cory21 [~Cory21@user/pasha] has joined #bitcoin-core-dev
09:41 < fanquake> Less tested, would need to check if all the targets we support would work
09:41 < darosior> sipa: might not be consensus compatible
09:41 < fanquake> Although I guess if we ship x86_64 and aarch64, that'd probably cover most users
09:41  * darosior hides
09:41 < sipa> darosior: only if there are bugs in it :p
09:42 < sipa> another possibility is having separate static-linux and modern-linux release builds
09:42 < darosior> Differential fuzzing across libc's is something that came up recently when chatting with external people looking into fuzzing Core
09:42 < fanquake> would also mean splitting the guix build in two, either to do a lts & the current build, or some sort of static bitcoind + utils & gui separate
09:42 < sipa> i'm less a fan of that due to splitting testing, though
09:42 < sipa> fanquake: multiprocess gui lalala
09:43 < fanquake> we are already shipping releases built against different libc++ flavours
09:43 < darosior> fanquake: for MacOS, right?
09:43 < fanquake> I will do a POC in any case
09:43 < sipa> fanquake: cool, curious about what you find
09:44 < fanquake> darosior: yea, clang & libc++ for macOS, gcc & libstdc++ for linux
09:44 < sipa> does libc++ have its own libc?
09:44 < darosior> im sure nobody mines on macos :p
09:44 < sipa> or does it use glibc
09:44 < fanquake> they are working on it
09:44 < fanquake> https://libc.llvm.org/
09:44 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
09:44 < sipa> of course they are
09:44 < sipa> what's next, their own kernel?
09:44 < fanquake> It's getting close to the point where you can bootstrap libc++ against it
09:45 < fanquake> we'll ship an LLVM OS container with bitcoind entrypoint
09:45 < darosior> compatibility: solved
09:45 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
09:46 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
09:46 < achow101> Any other topics to discuss?
09:48 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:48 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:49 < achow101> #endmeeting
09:49 < corebot> achow101: Meeting ended at 2025-09-18T16:49+0000
09:49 < corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.log.json
09:49 < corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.log.html
09:49 < corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.html
09:50 < fanquake> For anyone interested, this was a prior look at staticly built bitcoind (with a similar branch): https://github.com/bitcoin/bitcoin/pull/23203
09:50 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
09:51 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Ping timeout: 250 seconds]
09:51 -!- dzxzg [~qualify@user/dzxzg] has quit [Quit: Konversation terminated!]
09:54 -!- l0rinc_ [~l0rinc@user/l0rinc] has quit [Quit: l0rinc_]
09:56 -!- Holz [~Holz@user/Holz] has joined #bitcoin-core-dev
09:57 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
09:59 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
10:00 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
10:02 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
10:02 -!- cman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has quit [Ping timeout: 248 seconds]
10:06 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
10:09 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
10:10 -!- purpleKarrot [~purpleKar@185.240.173.188] has quit [Quit: purpleKarrot]
10:13 -!- BGL [eighty@75.149.171.58] has joined #bitcoin-core-dev
10:24 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Christoph_]
10:31 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
10:32 < darosior> _aj_: re "2024-04-22 on that graph claims 927010 txs per day" -> sure if you use a 1-day moving average but in this case you should rely on the adjustment mechanism, shouldn't you? It seems suboptimal to use the highest, least sustained, transaction rate as the default. Because it means every day of the year except one you will end up not limiting
10:32 < darosior> anything?
10:35 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
10:43 < sipa> darosior: i think the number should be more picked based on what we see averaged over windows of maybe minutes or so?
10:44 < sipa> which i'm guessing can be many times larger
10:44 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 258 seconds]
10:44 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
10:45 < darosior> Isn't it more appropriate for short burst to rely on the dynamic relay rate mechanism, and choose the default for what's most commonly observed?
10:46 < sipa> i think the dynamic rate is to protect against "inv queue growing unbounded", not for normal the this-is-fine rate
10:47 < sipa> like, i assume the network can deal just fine with a fairly nontrivial multiple of the average rate
10:48 < sipa> there's no reason to limit anything when the actual rate is below that, if we don't care about the hiding-size-of-queue privacy
10:49 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
10:51 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
10:54 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
10:56 < darosior> Ok that makes sense to me, thanks.
10:56 < sipa> 11:01:15 < sipa> what about: send_now = std::min(to_send.size(), time_since_last_send * R + (to_send.size() ** 2) / M)
10:57 < sipa> i still like this
10:57 -!- alvroble [~alvroble@user/alvroble] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:01 < darosior> 11:01 <sipa> where R is the "everyone can handle this tx rate" number, and M is the maximum queue size
11:05 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
11:05 < darosior> So assuming R would be our current relay rate, time_since_last_send * R is what we do under normal conditions today. So this only differs in how we clear the queue faster when it gets too large, which today is `to_send.size() / M * 5`.
11:06 < fanquake> Do we want to do this PR for 30? (#28592)
11:06 < corebot> https://github.com/bitcoin/bitcoin/issues/28592 | p2p: Increase tx relay rate by ajtowns · Pull Request #28592 · bitcoin/bitcoin · GitHub
11:06 < darosior> fanquake: i was thinking about it.
11:06 < darosior> It kinda makes sense to go along with reducing the minrelaytxfee
11:06 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
11:07 < fanquake> Will put it on the milestone, can decide
11:07 < darosior> (re sipa's formula) The real difference is taking the square of the size of the queue rather than multiplying it by 5. That makes sense, but does it make that much of a difference in practice? I guess it gives clearer guarantees we won't OOM instagibbs.
11:08 < sipa> darosior: at low rates i think it's more consistent too (by scaling with actual time between sends, not just the average)
11:08 < sipa> but that's a minor point
11:08 < dzxzg> dumb question: why not just be a function of the queue size? is it to set a floor on the relay rate?
11:08 < darosior> Ah right time_since_last_send isn't exactly what we do today
11:09 < sipa> dzxzg: it is a function of the queue size right now
11:09 < sipa> and yes, i think it should be
11:10 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 244 seconds]
11:11 < sipa> currently it is std::min(to_send.size(), B + (to_send.size() / 1000) * 5)
11:12 < darosior> sipa: ACK you formula. I think it makes it easier to reason about the growth of the queue.
11:14 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
11:14 < sipa> dzxzg: i think i don't understand your question
11:15 < dzxzg> sipa: My question is why use `R` instead of only being a function of `M` 
11:15 < dzxzg> sorry not M I mean queue size
11:15 < dzxzg> but I guess then the queue would not clear when it gets smal
11:15 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:16 < sipa> dzxzg: yeah, it'd mean the queue really never completely drains, which seems silly (for propagation speed, etc) when it's low enough that the network can just deal fine with it
11:20 -!- jackielove4u [~jackielov@user/jackielove4u] has joined #bitcoin-core-dev
11:22 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
11:24 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:26 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 258 seconds]
11:28 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
11:28 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:30 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
11:32 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
11:34 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
11:41 -!- jerryf [~jerryf@user/jerryf] has quit [Ping timeout: 272 seconds]
11:41 -!- jerryf [~jerryf@user/jerryf] has joined #bitcoin-core-dev
11:46 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
11:53 -!- Cory21 [~Cory21@user/pasha] has quit [Quit: Client closed]
11:53 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
11:53 -!- Cory21 [~Cory21@user/pasha] has joined #bitcoin-core-dev
11:54 -!- enochazariah [uid710351@id-710351.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
11:56 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
12:00 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Christoph_]
12:07 -!- Cory33 [~Cory21@user/pasha] has joined #bitcoin-core-dev
12:11 -!- Cory21 [~Cory21@user/pasha] has quit [Ping timeout: 250 seconds]
12:23 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:42 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has quit [Ping timeout: 258 seconds]
12:43 -!- hernanmarino [~hernanmar@2800:2330:2840:4de:6ced:6815:210c:cf51] has joined #bitcoin-core-dev
12:54 -!- enochazariah [uid710351@id-710351.hampstead.irccloud.com] has joined #bitcoin-core-dev
13:04 -!- Cory56 [~Cory33@user/pasha] has joined #bitcoin-core-dev
13:08 -!- Cory33 [~Cory21@user/pasha] has quit [Ping timeout: 250 seconds]
13:11 -!- thoragh [~username@user/thoragh] has joined #bitcoin-core-dev
13:18 < hodlinator> I've shaped up #33422 (the one added to the v30 milestone today) a bit and added some illustrative/motivating screenshots. Just waiting for fellow Windows fans to review. :)
13:18 < corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
13:19 -!- hernanmarino [~hernanmar@2800:2330:2840:4de:6ced:6815:210c:cf51] has quit [Ping timeout: 256 seconds]
13:21 -!- hernanmarino [~hernanmar@181.85.54.57] has joined #bitcoin-core-dev
14:14 < dzxzg> ah, ok so the reason the current formula is so bad is that the inbound transaction rate (n) required to sustain a queue size of 1000
14:14 < dzxzg> is n - R = 5
14:15 < dzxzg> with sipa's formula it's n - R = M 
14:16 < dzxzg> (n = R + 5M/M and n = R + M^2/M) 
14:21 < dzxzg> and the time to clear (when n = 0)for a queue k if no new tx'es arrive is sqrt(M / R) * arctan ( k / sqrt(M * R) ) in sipa's suggested formula and (M / 5) * ln|1 + 5k/MR| in the current formula
14:22 < dzxzg> with M=1000 and R=7: 11.95 * arctan(k/83.6) in the quadratic formula and 200 * ln|1 + k/1400| in the linear formula, with arctan(inf) = pi/2, the quadratic formula is bounded to never take longer than ~18.77 seconds to clear the queue if there are no inbound transactions
14:22 < sipa> ... arctan :o
14:23 < sipa> (i didn't expect that function to show up here, not saying it's wrong!)
14:31 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
14:33 < dzxzg> My math could definitely be wrong: I got that from integrating dk / (R + k^2/M) and using  ∫dx/(a^2 + x^2) = 1/a * arctan(x/a) + C
14:38 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
14:42 -!- cman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has joined #bitcoin-core-dev
14:42 -!- conman [~con@180-150-21-3.b49615.mel.static.aussiebb.net] has quit [Ping timeout: 256 seconds]
14:46 -!- Cory56 [~Cory33@user/pasha] has quit [Quit: Client closed]
14:47 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
14:47 -!- Cory56 [~Cory56@user/pasha] has joined #bitcoin-core-dev
14:50 -!- kevkevin [~kevkevin@12.161.6.169] has joined #bitcoin-core-dev
14:53 -!- kevkevin [~kevkevin@12.161.6.169] has quit [Remote host closed the connection]
14:54 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
14:58 -!- thoragh [~username@user/thoragh] has quit [Read error: Connection reset by peer]
15:00 < dzxzg> ah ok, there was a little bit of a mistake in my equilibrium formula above for the current fomula: to sustain a queue size of 1000 you need n - R = 1
15:02 < dzxzg> a new transaction rate of 8 tx/s would cause the queue to grow until it reached 1000 and then stay there 
15:03 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
15:04 -!- enochazariah [uid710351@id-710351.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:04 -!- kevkevin [~kevkevin@12.161.6.169] has joined #bitcoin-core-dev
15:08 -!- kevkevin [~kevkevin@12.161.6.169] has quit [Remote host closed the connection]
15:15 -!- kevkevin [~kevkevin@12.161.6.169] has joined #bitcoin-core-dev
15:25 -!- kevkevin_ [~kevkevin@2607:fb91:bd14:4938:80ac:688:90fb:1d40] has joined #bitcoin-core-dev
15:27 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
15:28 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
15:29 -!- kevkevin [~kevkevin@12.161.6.169] has quit [Ping timeout: 258 seconds]
15:29 -!- kevkevin_ [~kevkevin@2607:fb91:bd14:4938:80ac:688:90fb:1d40] has quit [Remote host closed the connection]
15:56 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Remote host closed the connection]
15:57 -!- aleggg [~aleggg@177.188.150.31] has quit [Remote host closed the connection]
15:57 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
15:58 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
16:02 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
16:02 -!- aleggg [~aleggg@177.188.150.31] has joined #bitcoin-core-dev
16:06 -!- PatBoy [xyz@cryption.cn] has joined #bitcoin-core-dev
16:07 -!- P8tBoy [xyz@cryption.cn] has quit [Quit: ZNC 1.8.2 - https://znc.in]
16:09 -!- Henry151_ [~Henry151@user/henry151] has quit [Remote host closed the connection]
16:09 -!- zumbi [~zumbi@debian/zumbi] has quit [Ping timeout: 260 seconds]
16:10 -!- Henry151 [~Henry151@user/henry151] has joined #bitcoin-core-dev
16:10 -!- zumbi [~zumbi@debian/zumbi] has joined #bitcoin-core-dev
16:12 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
16:19 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
16:28 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Christoph_]
16:43 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
16:54 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Christoph_]
17:33 -!- hernanmarino [~hernanmar@181.85.54.57] has quit [Ping timeout: 256 seconds]
17:33 -!- hernanmarino_ [~hernanmar@2800:2330:2840:65e:fc99:7cc6:ede0:3801] has joined #bitcoin-core-dev
17:39 -!- hernanmarino_ [~hernanmar@2800:2330:2840:65e:fc99:7cc6:ede0:3801] has quit [Ping timeout: 248 seconds]
17:41 -!- hernanmarino [~hernanmar@181.85.54.57] has joined #bitcoin-core-dev
17:55 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
17:59 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
17:59 -!- Cory56 [~Cory56@user/pasha] has quit [Quit: Client closed]
17:59 -!- Cory56 [~Cory56@user/pasha] has joined #bitcoin-core-dev
18:02 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
18:05 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Client Quit]
18:06 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
18:20 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
18:21 -!- entropyx [~blackbox@user/entropyx] has quit [Quit: no love here!]
18:22 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
18:27 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
18:34 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
19:47 < _aj_> sipa: "time_since_last_send * R" not "average_time_between_sends * R" ?
19:51 < _aj_> sipa: if we're happy to increase our INVs quadratically when bursts come in, why not just make the formula be min(1000, inv_to_send.size()) and always send as much as we can? (i think the answer is "to smooth out bursts of low-fee txs so as to avoid wasting the network's validation and relay resources"; and i'm not sure a quadratic increase during bursts fits well with that?)
19:59 -!- kimsh [~kimsh@user/kimsh] has joined #bitcoin-core-dev
20:02 < sipa> _aj_: yeah, time since send, not avg time between sends
20:03 < sipa> and the quadratic term is essentially the "give up on trying to smooth out if it causes too much backlkg"
20:04 < _aj_> "the reason the current formula is so bad" -- i don't think it's "so bad"; i'm only seeing occassional queues of 5000 txs from peers that don't seem to be announcing txs back to me. the original issue was we apparently had a 6h period of sustained 13.9 tx/s announcements of BRC20 things, and i think i was seeing 25k to 60k+ queued txs by some peers; current behaviour is much milder.
20:07 < sipa> yeah, i don't think it's bad in practice - but in theory it can grow very large still i think (but far less than before the /1000*5 term got added)
20:10 < sipa> _aj_: the effect of the quadratic is really "if you're within x% of max queue size, send x% of the actual queue"
20:10 < _aj_> yeah; with normal traffic (<7tx/s) any backlog gets cleared in ~15 minutes
20:10 < _aj_> (down to 1000 entries, anyway)
20:50 -!- mbrochh [uid3052@id-3052.helmsley.irccloud.com] has joined #bitcoin-core-dev
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:08 -!- kimsh [~kimsh@user/kimsh] has quit [Quit: Client closed]
21:46 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
21:50 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: l0rinc]
21:57 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Quit: Christoph_]
22:01 -!- corebot` [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
22:01 -!- corebot [~limnoria@user/core-meetbot] has quit [Ping timeout: 256 seconds]
22:12 < _aj_> hm, some background discussion; https://www.erisian.com.au/bitcoin-core-dev/log-2016-04-11.html#l-240 and #7840
22:12 < corebot`> https://github.com/bitcoin/bitcoin/issues/7840 | Several performance and privacy improvements to inv/mempool handling by sipa · Pull Request #7840 · bitcoin/bitcoin · GitHub
22:20 -!- twistedline [~bitcoin@1tbit.com] has quit [Ping timeout: 258 seconds]
22:28 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 244 seconds]
22:31 -!- roconnor [~quassel@rocq/roconnor] has quit [Ping timeout: 260 seconds]
22:31 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
22:35 -!- l0rinc_ [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
22:36 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Ping timeout: 256 seconds]
22:37 -!- roconnor [~quassel@rocq/roconnor] has joined #bitcoin-core-dev
22:42 -!- jerryf [~jerryf@user/jerryf] has quit [Remote host closed the connection]
22:42 -!- jerryf [~jerryf@user/jerryf] has joined #bitcoin-core-dev
23:07 -!- hugohn______ [sid304114@id-304114.lymington.irccloud.com] has quit [Server closed connection]
23:07 -!- hugohn______ [sid304114@id-304114.lymington.irccloud.com] has joined #bitcoin-core-dev
23:10 -!- Cory56 [~Cory56@user/pasha] has quit [Quit: Client closed]
23:10 -!- Cory56 [~Cory56@user/pasha] has joined #bitcoin-core-dev
23:15 < _aj_> sipa: hmm, what if we tracked the exponential rolling average of relayed txs; `past_avg /= pow(2.0, timedelta/5m); ++past_avg;` in RelayTransaction() or so. could then make our broadcast target be min(queue, max(TARGET_RATE, past_avg), 1000)
23:32 -!- l0rinc_ [~l0rinc@user/l0rinc] has quit [Quit: l0rinc_]
23:36 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
23:37 -!- mbrochh [uid3052@id-3052.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity]
23:46 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
23:49 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Client Quit]
23:49 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
23:55 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Ping timeout: 250 seconds]
--- Log closed Fri Sep 19 00:00:44 2025