17:00:10 <svanstaa> #startmeeting 
17:00:10 <corebot`> svanstaa: Meeting started at 2026-04-08T17:00+0000
17:00:11 <corebot`> svanstaa: Current chairs: svanstaa
17:00:12 <corebot`> svanstaa: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
17:00:13 <corebot`> svanstaa: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
17:00:14 <corebot`> svanstaa: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
17:00:23 <marcofleon> hi
17:00:26 <svanstaa> Hi everyone, and welcome to the Bitcoin Core Review Club, today about the 31.0 Release Testing Guide!
17:00:45 <svanstaa> Thanks you for joining. Even if you are here for the first time, feel free to say hi!
17:00:46 <itamar30> Hi, first time ever...
17:00:46 <janb84> hi
17:00:50 <marcofleon> woo!
17:00:55 <sdmg15> Hi, first time :)
17:01:04 <carloantinarella> Hello everyone!
17:01:05 <svanstaa> Great!
17:01:39 <svanstaa> Also, do not ask for permission to speak, just speak up :)
17:01:53 <svanstaa> Here's the link to the testing guide: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide
17:02:18 <sdmg15> I've done the steps described in the testing guide, and created an asciinema recording https://asciinema.org/a/906191
17:03:10 <svanstaa> @sdmg15 that is an innovative way to  go about it
17:04:06 <svanstaa> Lets go through this chapter by chapter
17:04:20 <svanstaa> First preparations:   https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide#preparation
17:05:01 <svanstaa> Who had issus or comments on building the client, and setting up the test environment?
17:05:10 <svanstaa> *issues
17:06:56 <marcofleon> The steps were laid out clearly for me, nicely done svanstaa
17:07:26 <carloantinarella> I only tried compiling from source, no issues whatsoever
17:07:35 <svanstaa> Great! Ok, lets look at 1. Mempool
17:08:02 <svanstaa> Who did the test? Any issues or peculiar observations?
17:09:11 <sdmg15> I think the 1.3 Cluster mempool: Cluster Limits Enforcement is the one I struggled testing
17:09:17 <svanstaa> Why did we set up the child txn with a higher fee than the parent?
17:09:34 <svanstaa> @sdmg15. where did you get stuck?
17:10:00 <svanstaa> (this was the tricky one, I admit)
17:10:23 <sdmg15> The issue was just that I created a script.sh and then had to export the aliase commands :)
17:10:44 <janb84> sdmg15: didn't a simple copy and paste didn't work ?
17:11:30 <sdmg15> Haven't tried copy-pasting, since the script was long I just thought I should put it in a file
17:12:24 <svanstaa> Did it show expected behaviour then?
17:13:35 <sdmg15> Yes I saw the expected behavior, in my recording too. thanks for the instructions.
17:13:35 <carloantinarella> I also had similar issue with aliases. Aliases are lost if you execute as a separate script. I sourced it instead and it worked fine
17:13:43 <itamar30> I first tried copy and paste, but the program stopped and my terminal closed
17:14:33 <janb84> ok lessens learned for the next guide :) tnx all
17:14:48 <svanstaa> :)
17:14:50 <marcofleon> Child txn had a higher fee than the parent to ensure they were merged as a single chunk
17:15:06 <svanstaa> @marcofleon correct!
17:15:22 <marcofleon> Hoping my terminology is correct...
17:15:36 <svanstaa> @janb84 yes we will keep the test cases simpler next time
17:16:41 <svanstaa> on to the next one: 2. private broadcast
17:16:47 <svanstaa> What was this about?
17:17:58 <svanstaa> Quick summary, and observed behaviour?
17:18:53 <sdmg15> From my understanding it's help people  broadcast transaction over secured networks like Tor and I2P
17:19:28 <sdmg15> And you could enforce that to your client by enabling the option
17:20:15 <svanstaa> Correct. How did we test this? It was not the straightforward way
17:21:04 <svanstaa> That would have been to install and sent out a private transaction on testnet, but we deemed that out of scope for this tutorial
17:22:44 <svanstaa> Cheap solution: just test that the client refuses to sent out any transaction when TOR/I2P is not present while -privatebroadcast is set :)
17:23:14 <svanstaa> Next topic Updated RPCs
17:23:26 <marcofleon> Good call for the private broadcast test
17:23:45 <marcofleon> Is it even a thing to connect over tor for regtest? Not sure if i've ever tried that
17:24:24 <marcofleon> Just a local chain, so wouldn't really make sense
17:24:49 <svanstaa> @marcofleon yes, it would have needed running testnet as well
17:25:05 <svanstaa> AFAIK, that wouldnt work on regtest
17:25:15 <svanstaa> that's why we left that out
17:26:10 <svanstaa> who ran the test of the updated getblock RPC?
17:27:15 <sdmg15> I did
17:28:04 <marcofleon> I've given it a try on mainnet
17:29:24 <svanstaa> Nice. Bonus question: why was output of the coinbase_tx object added at logging verbosity level 1?
17:31:12 <janb84> Miners ?
17:31:26 <sdmg15> I don't know what BIP54 is all about, but from the PR it helps making the scan faster?
17:31:36 <marcofleon> at higher verbosities you would just see the full coinbase tx right?
17:31:54 <marcofleon> so it made sense to add at level 1 I think
17:32:01 <svanstaa> It said so in the linked PR#34512: making it easier to check for BIP54 compliance, without an overhead of logging messages
17:32:02 <corebot`> svanstaa: Error: That URL raised <HTTP Error 404: Not Found>
17:32:30 <marcofleon> ah nice
17:32:33 <marcofleon> #34512 
17:32:37 <corebot`> https://github.com/bitcoin/bitcoin/issues/34512 | rpc: add coinbase_tx field to getblock by Sjors · Pull Request #34512 · bitcoin/bitcoin · GitHub
17:32:38 <svanstaa> @marcofleon yes correct, at level 2 too much output of stuff you don'T need for that use case
17:33:32 <svanstaa> @sdmg15 BIP54 is also known as The Great consensus Cleanup. It is a soft fork that solves 4 known bugs
17:35:23 <svanstaa> Looking at the coinbase transaction can identify if the block is BIP54 compliant
17:35:46 <svanstaa> Next chapter 4. txospenderindex
17:35:48 <marcofleon> Last I heard it's just Consensus Cleanup these days. But still great to me at least
17:36:45 <svanstaa> @marcofleon haha, was it renamed? Didnt notice. I thinnk Consensus cleanup works just as well :)
17:37:10 <svanstaa> Who tried activating -txospenderindex? What is it good for?
17:38:56 <carloantinarella> -txospenderindex should be good for second layer protocols. Also in this case motivation is clearly explained in the PR introducing it
17:38:58 <sdmg15> The PR is from 2022 wow
17:39:49 <svanstaa> @carloantir . yes, correct. As it should be in any good PR :)
17:39:55 <marcofleon> only took four years 😅
17:40:46 <svanstaa> move slow and don't break things :)
17:41:00 <marcofleon> The index keeps track of which txs spent which outpoints  yes?
17:41:27 <svanstaa> yes, correct
17:42:20 <marcofleon> I've been syncing it for the last couple hours on my node :)
17:42:43 <marcofleon> only 300k blocks to go
17:42:57 <svanstaa> Nice, it can take a few hours
17:43:24 <svanstaa> who  has it synced completely already?
17:43:45 <carloantinarella> Is it independent from -txindex?
17:44:28 <svanstaa> @carloantir yes, that is a different index.  You can both on and off independently from each other
17:44:39 <svanstaa> *turn both
17:45:27 <svanstaa> (ok, this was a trick question, as syncing the txospenderindex is a prerequisite for running the tests)
17:45:56 <svanstaa> should have warned earlier that this is best run overnight :)
17:46:16 <svanstaa> ok, on to  section 5: Settings
17:46:40 <svanstaa> who fiddled with the dbcache settings? What is it for anyway?
17:48:42 <carloantinarella> I think this is an update due to the fact that more than 4096 MiB of RAM is now very common
17:49:24 <janb84> carloantinarella: that has been quite a debate, if having more ram is common ;)
17:49:43 <svanstaa> @carloantir Yes, correct. The 450MB size has been around for many years, hardware has advanced
17:49:56 <carloantinarella> I love debates, but I lost this one '=D
17:50:46 <svanstaa> Any unusual or unexpected behaviour observed here?
17:51:08 <marcofleon> the new default is 1024?
17:51:27 <svanstaa> yes, correct
17:52:42 <svanstaa> on to https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide#52-embedded-asmap--asmap-now-loads-bundled-data
17:52:43 <marcofleon> I'm not sure what's optimal, but I'll usually set dbcache to half my ram for ibd, and then set it to 1024 (even before this update)
17:52:43 <corebot`> svanstaa: Error: That URL raised <HTTP Error 404: Not Found>
17:53:25 <svanstaa> @marcofleon those look like sensible values
17:54:21 <svanstaa> who tried the -asmap option in 5.2? What does it change?
17:55:17 <sdmg15> I struggle understanding what are asmaps useful for but yeah I did run the tests
17:55:55 <svanstaa> The main reason in too make eclipse attacks more difficult
17:57:01 <svanstaa> If you chose your peers wisely (from all different corner of the web), it will become impossible for an attacker to eclipse you by spinning up hundreds of malicious nodes on e.g. AWS
17:57:32 <sdmg15> Oh I see interesting
17:58:03 <sipa> sdmg15: it's basically a "map of the internet", with information about what organizations (ISPs, hosting providers, companies, ...) control which ranges of IP addresses. By being aware of this information, Bitcoin Core can bias its connection making in a way such that the connections are to diverse sets of organizations, making it harder for a single one or a small number from dominating all
17:58:09 <sipa> information you see
17:58:15 <svanstaa> It has now become a more permanent feature, with the ASMAP data collected for that release baked into the binaries
17:59:12 <sdmg15> It's clear now thanks.
17:59:33 <carloantinarella> Does it also speed up txs propagation over the network because of geographical diversity?
18:00:16 <svanstaa> @carloantir that also seems possible, but not completely sure
18:00:28 <svanstaa> maybe @fjahr can chime in  later
18:01:08 <sipa> carloantinarella: unlikely, i think; propagation speed is dominated by the few fastest connections you have
18:01:32 <svanstaa> @sipa thanks for clarification!
18:01:58 <sipa> and in general, eclipse resistance is in conflict with propagation speed - for fast propagation you ideally want few connections to the fastest nodes possible, rather than many diverse ones
18:02:08 <svanstaa> That's it for today. Thaks you all for joining. Of course you can continue to discuss here, I will come back later to check for open questions
18:02:13 <svanstaa> #endmeeting