--- Log opened Thu May 01 00:00:30 2025
00:00 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
00:05 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 268 seconds]
00:16 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
00:22 -!- robszarka [~szarka@2603:3003:4eac:100:a42d:5114:b601:d074] has joined #bitcoin-core-dev
00:24 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 272 seconds]
00:25 -!- szarka [~szarka@2603:3003:4eac:100:54dd:7a72:5af6:5bbc] has quit [Ping timeout: 276 seconds]
00:38 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:40 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
01:32 -!- greypw1495085720 [~greypw@user/greypw] has joined #bitcoin-core-dev
01:32 -!- greypw1495085720 [~greypw@user/greypw] has quit [Client Quit]
01:33 -!- greypw1495085720 [~greypw@user/greypw] has joined #bitcoin-core-dev
01:35 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
01:42 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 276 seconds]
01:54 < bitcoin-git> [bitcoin] AndreaLanfranchi opened pull request #32392: Update .gitignore (master...gitignore) https://github.com/bitcoin/bitcoin/pull/32392
01:59 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
02:05 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Remote host closed the connection]
02:06 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
02:07 < bitcoin-git> [bitcoin] fanquake closed pull request #32392: Update .gitignore (master...gitignore) https://github.com/bitcoin/bitcoin/pull/32392
02:09 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:c1:cbfb:120:4bb2] has quit [Quit: Christoph_]
02:20 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 276 seconds]
02:21 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
02:21 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/68ac9f116c02...fc6346dbc8dc
02:21 < bitcoin-git> bitcoin/master 6cbc28b monlovesmango: doc: Fix test_bitcoin path
02:21 < bitcoin-git> bitcoin/master fc6346d merge-script: Merge bitcoin/bitcoin#32389: doc: Fix test_bitcoin path
02:21 < bitcoin-git> [bitcoin] fanquake merged pull request #32389: doc: Fix test_bitcoin path (master...doc-fix-test_bitcoin-path) https://github.com/bitcoin/bitcoin/pull/32389
02:40 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 248 seconds]
02:44 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
02:49 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 260 seconds]
03:22 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
03:27 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 245 seconds]
03:27 < TheCharlatan> I'm looking for some block index size comparisons. Could some of you post the size of their blocks/index?
03:42 < fanquake> 294mb
03:46 < sipa> $ du -sh ~/.bitcoin/blocks/index/
03:46 < sipa> 116M    /home/site/.bitcoin/blocks/index/
03:56 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
04:00 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 260 seconds]
04:01 -!- jespada [~jespada@r190-133-55-103.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
04:15 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
04:19 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 248 seconds]
04:48 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
04:56 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:04 < bitcoin-git> [bitcoin] vasild opened pull request #32394: net: make m_nodes_mutex non-recursive (master...m_nodes_mutex) https://github.com/bitcoin/bitcoin/pull/32394
05:06 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
05:07 < vasild> TheCharlatan: 208M on one machine and 122M on another (that is `du -sh`, depends on the filesystem block size)
05:08 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
05:10 -!- jespada [~jespada@r190-133-55-103.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
05:10 < vasild> not much, it has just a few files
05:11 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 245 seconds]
05:11 -!- jespada [~jespada@r190-133-55-103.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
05:11 < vasild> and 113M on a pruned node
05:12 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:13 -!- Cory55 [~Cory55@user/pasha] has quit [Quit: Client closed]
05:14 -!- Cory55 [~Cory55@user/pasha] has joined #bitcoin-core-dev
05:14 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1002] has quit [Ping timeout: 265 seconds]
05:19 < TheCharlatan> Thanks, interesting to see this magnitude of variance. 
05:30 -!- donal [~donal@109.78.237.48] has joined #bitcoin-core-dev
05:32 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
05:37 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 260 seconds]
05:37 -!- donal [~donal@109.78.237.48] has quit [Quit: Client closed]
05:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:39 -!- donal [~donal@user/donal] has joined #bitcoin-core-dev
05:44 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
05:57 < laanwj> 123M here. some difference based on the file system block size is expected, but i don't think it should come out double?
05:58 -!- kevkevin_ [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:58 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Read error: Connection reset by peer]
06:09 < laanwj> as i understand, pruning shouldn't make a difference, block files are deleted but the blocks remain in the block index
06:10 -!- brunoerg [~brunoerg@169.150.201.26] has joined #bitcoin-core-dev
06:13 < instagibbs> don't remember the command but topic: we should decide a direction on OP_RETURN stuff
06:13 < laanwj> so the larger ones are interesting, maybe it's for long-running nodes which have a lot of stale blocks from reorgs
06:14 < laanwj> the command is #topic <topic>
06:15 < instagibbs> #topic let's decide a direction on OP_RETURN policy
06:39 -!- reverseengineer [~reverseen@user/reverseengineer] has joined #bitcoin-core-dev
06:44 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:c1:cbfb:120:4bb2] has joined #bitcoin-core-dev
06:47 < jeremyrubin> tbh i don't really care to get involved in whatever the thing is, but I think the GH thread should probably get unlocked, maybe someone should just comment "will be reopened after a 48h cooldown"
06:50 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 252 seconds]
06:51 < reverseengineer> Did the Btc blk magic signature change or why do I, upon reading the first 4 bytes of blk000001.dat get s.o like d3f5 etc etc. ?
06:52 < reverseengineer> I downloaded the blocks without pruning
06:53 -!- jespada_ [~jespada@r179-25-202-180.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:53 -!- donal [~donal@user/donal] has quit [Quit: Client closed]
06:54 -!- jespada [~jespada@r190-133-55-103.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 245 seconds]
06:55 < _aj_> fanquake: du -bh .bitcoin/blocks/index/ ?
06:56 < reverseengineer> 193MB
06:58 -!- TorTanicc [~TorTanicc@109.175.166.195] has joined #bitcoin-core-dev
06:58 < _aj_> instagibbs, laanwj: aren't you thinking of #proposedmeetingtopic ?
06:58 < instagibbs> the world may never know
06:59 -!- TorTanicc [~TorTanicc@109.175.166.195] has quit [Client Quit]
07:00 -!- banananananananz [~sdhfosduk@109.175.166.195] has joined #bitcoin-core-dev
07:00 -!- banananananananz [~sdhfosduk@109.175.166.195] has quit [Client Quit]
07:02 < reverseengineer> _aj_: I rule out corrupt blocks because the latest blocks show the same first bytes. The issue is that due to this issue I can't read the size of blocks etc. 
07:04 < laanwj> _aj_: oh, oops, yes, #topic is a command but it sets the current topic it doesn't propose one
07:05 < laanwj> anyhow, it's probably clear by now
07:07 < laanwj> reverseengineer: newer versions of bitcoind xor the blocks on disk to avoid false positives with virus scanners, see `contrib/linearize/linearize-data.py` how to handle this 
07:10 < reverseengineer> thank you laanwj 
07:15 -!- reverseengineer [~reverseen@user/reverseengineer] has quit [Read error: Connection reset by peer]
07:45 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:04 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
08:06 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
08:13 < bitcoin-git> [bitcoin] ismaelsadeeq opened pull request #32395: fees: rpc: `estimatesmartfee` now returns a fee rate estimate during low network activity (master...04-2025-fee-estimate-with-low-network-activity) https://github.com/bitcoin/bitcoin/pull/32395
08:17 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
08:22 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Ping timeout: 240 seconds]
08:25 < fanquake> _aj_: yea
08:28 < bitcoin-git> [bitcoin] hebasto opened pull request #32396: cmake: Add application manifests when cross-compiling for Windows (master...250501-app-manifest) https://github.com/bitcoin/bitcoin/pull/32396
08:36 -!- aleggg [~aleggg@187.101.224.222] has quit [Remote host closed the connection]
08:37 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
08:39 < _aj_> fanquake: even -bh says ~300MB? weird
08:39 < fanquake> _aj_: this is bsd du, on a macos box, so there's no -b
08:40 < _aj_> fanquake: haha, sucks to be you
08:40 < fanquake> I can check some others later
08:42 < _aj_> fanquake: find .bitcoin/blocks/index -printf "%s\n" | (x=0; while read a; do x=$(($x+$a)); done; echo $((x/1024/1024)) )
08:45 < fanquake> _aj_: did you think BSD find would be so useful to implement -printf
08:46 < _aj_> can't you use homebrew or something to upgrade to the 90s?
08:47 < fanquake> yea there's probably a g prefixed tool floating around somewhere
08:47 < laanwj> fanquake: here's a python version: https://gist.github.com/laanwj/0ebfea4a32cfe3bbeff8b05fb2a5d788
08:51 -!- aleggg [~aleggg@187.101.224.222] has joined #bitcoin-core-dev
08:54 -!- sebastianvstaa [~sebastian@45.86.202.151] has joined #bitcoin-core-dev
08:55 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:58 -!- Emc99 [~Emc99@212.129.80.110] has joined #bitcoin-core-dev
08:59 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-dev
09:00 < achow101> #startmeeting
09:00 < corebot> achow101: Meeting started at 2025-05-01T16: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 < achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto 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 < rkrux> hi
09:00 < TheCharlatan> hi
09:00 < stickies-v> hi
09:00 < johnny9dev> hi
09:00 < jonatack> hi
09:00 < instagibbs> hi
09:00 < hodlinator> hi
09:00 < cfields> hi
09:00 < pinheadmz> Hi
09:00 < kevkevin_> hi
09:00 < achow101> There are 2 pre-proposed meeting topics this week. Any last minute ones to add?
09:00 < sr_gi[m]> hi
09:00 < kanzure> hi
09:00 < willcl-ark> hi
09:00 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
09:00 < lightlike> Hi
09:00 < Murch[m]> Hi
09:00 < marcofleon> hi
09:01 < achow101> #topic Erlay WG Update (sr_gi, gleb)
09:02 < sr_gi[m]> I've been moving forward with Warnet simulations, small-scale on my local setup for now. Now that the experiments are design I should be moving to bigger scale experiments SoonTM. Nothing substantial to report so far.
09:03 < laanwj> hi
09:03 < sr_gi[m]> That's it on my end
09:03 < achow101> #topic Kernel WG Update (TheCharlatan)
09:03 < TheCharlatan> Still looking for review on #40595 and #31382
09:03 < corebot> TheCharlatan: Error: That URL raised <HTTP Error 404: Not Found>
09:03 < corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
09:03 < TheCharlatan> Woops #30595 :P
09:04 < corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
09:04 < TheCharlatan> Over the past week I have been working on replacing the BlockTreeDB's leveldb with a flat file store.
09:04 < TheCharlatan> This is possible, because we don't ever delete from that data structure.
09:04 < TheCharlatan> I am working on PRing this soon to gather comments and completed the migration code today.
09:04 < TheCharlatan> The change was mostly motivated by kernel applications having to shutdown a node first before being able to read from its block store.
09:04 < TheCharlatan> This is not possible currently because leveldb does not allow different processes to read/write while the db is open on another.
09:04 < TheCharlatan> It does also bring some storage improvements and allows nodes to startup a bit faster. 
09:04 < brunoerg> hi
09:04 < sipa> hi
09:05 < TheCharlatan> that's all
09:05 < cfields> nice :)
09:05 < willcl-ark> cool!
09:05 < darosior> hi
09:05 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
09:05 < theStack> hi 
09:06 < Sjors[m]> hi
09:06 < sipa> Not much to report.
09:06 < sipa> Hopefully the mining/eviction PR goes in soon.
09:06 < vasild> hi
09:06 < glozow> hi
09:06 < sipa> Mostly doing more research on better linearization algorithms.
09:08 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Remote host closed the connection]
09:09 < achow101> #topic Stratum v2 WG Update (sjors)
09:09 < sipa> Nothing from sdaftuar.
09:10 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
09:12 < achow101> Sjors[m]: ?
09:13 < Sjors[m]> yes
09:13 < Sjors[m]> Not much to report
09:13 < Sjors[m]> Please keep reviewing multiprocess stuff
09:14 < achow101> #topic MuSig2 WG Update (achow101, rkrux)
09:14 < achow101> #31243 was merged, the next PR to review is #31244
09:14 < corebot> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
09:14 < corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
09:14 < achow101> #topic Legacy Wallet Removal WG Update (achow101, furszy)
09:14 < achow101> #31250 was merged so legacy wallets can finally no longer be created or loaded
09:14 < corebot> https://github.com/bitcoin/bitcoin/issues/31250 | wallet: Disable creating and loading legacy wallets by achow101 · Pull Request #31250 · bitcoin/bitcoin · GitHub
09:14 < achow101> The next and final major PR in this project is #28710 to delete (almost) everything
09:14 < corebot> https://github.com/bitcoin/bitcoin/issues/28710 | Remove the legacy wallet and BDB dependency by achow101 · Pull Request #28710 · bitcoin/bitcoin · GitHub
09:15 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 272 seconds]
09:15 -!- cotsuka [~cotsuka@user/cotsuka] has quit [Remote host closed the connection]
09:15 < achow101> There are still several things that can be removed after in followups, e.g. GUI watchonly wallet things
09:15 < achow101> #topic orphan resolution WG Update (glozow)
09:15 < glozow> No updates, have been busy with other things
09:16 < achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
09:16 -!- cotsuka [~cotsuka@user/cotsuka] has joined #bitcoin-core-dev
09:16 < johnny9dev> Fixed remaining issues with bitcoin-core/gui-qml#448 and it is ready to be merged.
09:16 < corebot> https://github.com/bitcoin-core/gui-qml/issues/448 | Introduce Coin Selection page by johnny9 · Pull Request #448 · bitcoin-core/gui-qml · GitHub
09:19 < johnny9dev> That's all for now
09:19 < achow101> #topic moving the repo to bitcoin-core (achow101)
09:19 < achow101> After last week's meeting, I opened #32340 for further discussion
09:19 < corebot> https://github.com/bitcoin/bitcoin/issues/32340 | Moving this repo to bitcoin-core · Issue #32340 · bitcoin/bitcoin · GitHub
09:19 < achow101> It doesn't seem like any new discussion really happened there
09:19 < achow101> Now that it has been a week, how do people feel about moving the repo?
09:20 < vasild> did anything happen with the bip repo in the meantime, e.g. did bip people decide to move it away from bitcoin/bips?
09:20 < achow101> nope
09:20 < jonatack> vasild: no
09:21 < instagibbs> does crickets mean ack/nack or pure indifference 
09:21 < darosior> achow101: i wanted to chime in but didn't get to it. Can we punt for another week?
09:21 < achow101> darosior: you can chime in now :)
09:21 < jonatack> ACK for me, as i commented in that issue
09:21 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
09:21 < stickies-v> not necessarily opposed but doesn't feel important pushing this through atm, let's just move bips and move on for now?
09:21 < willcl-ark> I think a little more time might be prudent here
09:21 < darosior> The perspective of "this is unnecessarily risky" is growing on me
09:22 < fanquake> optics-wise, I don't think it's a good time to move anything around
09:22 < achow101> one thing I want to point out is that the recent temp bans being issued do affect the bips repo too
09:22 < glozow> I would like more time
09:22 < TheCharlatan> yeah, great timing ^^
09:22 < achow101> okay, punt for another week
09:22 < stickies-v> i don't think next week is going to be significantly different
09:23 < furszy> +1 on moving the bips repo only - if that's needed due to the recent temp bans
09:23 < TheCharlatan> what will be the name of the repo in the bitcoin-core org?
09:23 < stickies-v> if the bips ban issue is fixed, there's no real urgency here?
09:23 < achow101> TheCharlatan: we can bikeshed that.. I like bitcoin-core/bitcoin-core
09:23 < Murch[m]> Some BIP Editors appear to think that the bitcoin org is the correct place for BIPs while Bitcoin Core should move out. Others seem fine with the move.
09:23 < achow101> moving the bips repo is up to the bip editors decide
09:23 < cfields> it's unclear to me on the issue if the org will transfer ownership or retain the current owners? As that was brought up las week, that's the bigger concern to me.
09:23 < stickies-v> Murch[m]: but the bip editor's can't get ban permissions in the bitcoin org?
09:23 < jonatack> achow101: agree with your naming suggestion
09:24 < cfields> s/will/would/
09:24 < achow101> cfields: I think the general sentiment is that the current owners of bitcoin/ will remain so, and no new ones will be added, regardless of any moves
09:24 < Murch[m]> stickies-v: I have mentioned that, yes
09:24 < cfields> achow101: ok, thanks. I'd suggest updating the issue to make that explicit.
09:24 < laanwj> bitcoin-core/bitcoin-core sgtm
09:24 < Murch[m]> stickies-v: We also have had less brigading in the past
09:25 < TheCharlatan> I'd like to keep /bitcoin. It would also make easier to maintain any existing cloning documentation, i.e. no need to handle the renamed dir.
09:25 < glozow> I thought it was quite clear we wouldn't transfer ownership of the org
09:25 < laanwj> yes
09:25 < jonatack> I agree the project owners in bitcoin/ would not need to be changed.
09:25 < achow101> TheCharlatan: the url will still redirect
09:25 < cfields> 👍
09:25 < Murch[m]> The Ordinals proposal had some, and there is a tiny bit on BIP 177, but we have so far done fine with just hiding a few comments
09:25 < glozow> TheCharlatan: +1
09:25 < jonatack> Banning hasn't been needed over the past year, until recently
09:25 < TheCharlatan> yeah, but you end up with either bitcoin or bitcoin-core on your machine.
09:26 < jonatack> in a single event
09:26 < glozow> that's not true, banning happens all the time
09:26 < jonatack> in the BIPs
09:26 < Murch[m]> glozow: Yeah, I think the ownership being retained by Bitcoin Core maintainers is understood
09:26 < darosior> Yeah it was a single event, and wasn't really effective anyways
09:26 < achow101> jonatack: I've definitely banned several spammers from the bips repo over the past year
09:27 < Murch[m]> Sure, but Spam is a clear-cut issue
09:27 < darosior> For low value spam ban can be effective, but in this case they can just be banned from the whole org
09:27 < jonatack> right
09:27 < achow101> yes, just saying that there have been bans issued for obvious spam in the bips repo, without the bips editors asking
09:28 < Murch[m]> It is my impression that the BIP Editors would be fine with remaining in the current org/repo at this time.
09:28 < jonatack> achow101: yes, and it's helpful. only referring to the fortunately very rare non-trivial bans.
09:29 < Murch[m]> There was a little bit of a debate about the bans in the past days affecting the BIPs repo as well, but I don’t think any of the affected parties were actively contributing to the BIPs repo at the time and the bans were short…
09:30 < jonatack> I think the BIPs case is separate from the bitcoin core one.
09:30 < achow101> ok, so i'll add this as a topic again next week, and if anyone has thoughts, please comment in the issue
09:31 < achow101> #topic let's decide a direction on OP_RETURN policy (instagibbs)
09:31 < instagibbs> hi
09:31 < instagibbs> The recent OP_RETURN policy discussion has been heated and has many viewpoints. 
09:31 < instagibbs> I'm not going to recapitulate all background to the topic, that's DYOR stuff.
09:31 < instagibbs> Unfortunately, we have to make a choice and we need input from regular contributors who have put thought into relay concerns. Letting the topic linger with no clear direction just breeds resentment and saps the project's energy by wasting time and attention on what otherwise is a smaller problem.
09:31 < instagibbs> That said I see roughly four options of varying credulity ahead of us:
09:31 < instagibbs> 0) Decide as a project that we will not modify this relay policy, close PRs indefinitely
09:32 < instagibbs> 1) Decide that OP_RETURN expansion results in too much arbitrary data publishing, and double-down on transaction filtering. Make it a project priority. (to be clear, this was rejected as a group repeatedly with 0 volunteers)
09:32 < instagibbs> 2) Decide to adjust priority "dial" minimally to something we find "appropriate" for known uses to reduce harm we are aware of, and ship it. Likely to be revisited in future.
09:32 < instagibbs> 3) Remove limits entirely (~Peter Todd's PR)
09:32 < instagibbs> Regardless of my biases for one or the other, as a project we should actively pick one, and we need consistent contributors to speak up if they disagree with the direction. Once direction is set, the rest of the details are straight forward and we can get back to real business.
09:32 < instagibbs> That's it. Thanks for listening to my ted talk
09:32 < Sjors[m]> I think anything short of (3) will just keep bringing back the drama.
09:33 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
09:33 < vasild> I guess the most liberal is to have this configurable in Bitcoin Core so users can set whatever mempool policy they wish. This way Bitcoin Core developers will not be perceived as imposing their views on the node operators.
09:33 < glozow> I don't think (1) makes any sense. (0) is giving in to drama
09:33 < Sjors[m]> (though avoiding drama isn't necessarily a good criterion)
09:34 < glozow> vasild: it is mostly configurable already. But long term I think it's a footgun to give options for users to... reject transactions that will likely be mined
09:34 < darosior> Storm in a tea pot. I don't think we should give in to bullies and do what we believe is good for actual Bitcoin Core and Bitcoin network users, ie the silent majority. I think we should merge Todd's PR and call it a day.
09:34 < achow101> configurability here is basically just a placebo
09:34 < instagibbs> vasild fwiw going forward we don't add these kinds of arguments if it doesnt achieve its aims and causes block prop to suffer
09:34 < Sjors[m]> vasild: except the documentation would have to list the downsides of not using the default, such as interfering with compact block relay
09:35 < instagibbs> from scratch I'd argue heavily against an argument
09:35 < darosior> I don't think keeping the option makes any sense once we switch the default to be no restriction.
09:35 < glozow> configurability at the cost of compact block reconstruction is irresponsible on our part imo
09:35 < eugenesiegel> I don't have much to add, but I agree with glozow
09:36 < instagibbs> I'm fine enough with 2, but prefer 3 out of humility of not knowing the next zk proof size people want to use, and do not want to revisit this again
09:36 < Sjors[m]> Also - as someone argued recent - it's arguably dishonest to ship an option knowing it doesn't work, i.e. a placebo.
09:36 < sipa> my belief is: you should only provide configuration knobs when you can give advice on when someone should use it
09:36 < achow101> I prefer 3 or 0, don't want to revisit this ever again
09:36 < instagibbs> ^ fair
09:37 < darosior> sipa: +1. And i don't think it holds in this case.
09:37 < TheCharlatan> is the reality that if configuration options are removed, a significant portion of the user base will switch to another implementation? Then I'm not sure if it is entirely irresponsible.
09:37 < achow101> TheCharlatan: a loud minority will, but they probably already have
09:37 < Sjors[m]> TheCharlatan: I doubt it
09:37 < sipa> or they don't run a node at all
09:38 < jonatack> perhaps consider spending time exlaining the issues involved to the outer community, if perception of bitcoin core is a criteria
09:38 < glozow> I wrote a comment about splitting out the option-removal part of Peter's PR. I think it's been buried  though
09:38 < Sjors[m]> We don't collect network metrics, but I suppose you could find out with some well crafted transaction broadcasts.
09:38 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Ping timeout: 276 seconds]
09:38 < darosior> If default is no restriction we can't expect providing a knob to have any global effect (defaults are sticky). So the user setting it would just shoot themselves in the foot: either blinding them to unconfirmed transactions they compete with for block space, harming block reconstruction, or both. Therefore i don't think the knob should exist.
09:38 < instagibbs> jonatack we should communicate whatever the result is for sure
09:38 < jonatack> beforehand, in a way that doesn't disenfranchise people
09:38 < darosior> jonatack: spent some time this week doing just that, see https://antoinep.com/posts/relay_policy_drama
09:39 < glozow> can you explain on what "disenfranchise" means?
09:39 < achow101> Sjors[m]: with mempoolfullrbf, it didn't take particularly long or especially well crafted broadcasts to get txs to relay, even when a majority of the network hadn't turned it on/upgraded yet
09:39 < willcl-ark> I've yet to see a well-reasoned/data-driven arguement as to why having these transactions arrive to your node in a block, vs via your mempool, makes anything better. Having a knob to twiddle that setting does seem pretty pointless to me, so would also prefer 0 or 3.
09:39 < glozow> explain/expand
09:39 < jonatack> darosior: i read that, and it was very good until the last 3 sections imo
09:39 < jonatack> then it reverted to a tone that imo doesn't reach across the aisle effectively
09:39 < Sjors[m]> achow101: I don't mean that the filtering would work, just that we could measure how many nodes actually encorce an OP_RETURN limit
09:39 < Murch[m]> jonatack: I have already spent several hours explaining this week, there are a lot of misconceptions being spread by popular social media participants, though
09:40 < Sjors[m]> As a proxy for churn away from Core
09:40 < jonatack> Murch[m]: yes, i've been swamped with private questions by users and the community as well
09:40 < instagibbs> Pick a direction, draft a reasoning for it, PR can do normal review for implementation details only, remove any comments about direction since they're off topic.
09:41 < glozow> I do think we can do more on the outreach part of this PR, but don't think it's productive to try to convince all of the twitter people. Particularly ones who are clearly not interested in engaging productively.
09:41 < sipa> ^
09:41 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
09:41 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
09:41 < glozow> In general, I don't think popular opinion should stop us from doing what is right. And I don't even think this is a popular opinion tbh, more of a loud one
09:41 < Murch[m]> glozow: 💯
09:42 < darosior> glozow president
09:42 < jonatack> it's more effective beforehand, but now that it's become widespread drama, i think reaching out with a tone like willcl-ark's recent meta comment is a good approach
09:42 < instagibbs> We can workshop the reasoning
09:42 < jonatack> https://github.com/bitcoin-core/meta/issues/19#issuecomment-2844984370
09:42 < sr_gi[m]> willcl-ark: +1. I think the argument that people against removing the limit are "ok" with transactions over the limit being included in blocks, but they are completely against them ever touching their mempool doesn't make sense. Specially when the alternative storing the same type of data in unspendable transactions that needs to live on the UTXO set potentially forever 
09:43 < darosior> jonatack: i dispute that "reaching out" wasn't done. I explained the rationale on the mailing list. Todd only opened the PR days after that.
09:43 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has joined #bitcoin-core-dev
09:43 < BlueMatt[m]> glozow: Not only right, but *important*. Sitting around and watching people fill the utxo set with garbage isn’t really acceptable.
09:43 < darosior> And if "reaching out" means appeasing people who are motivated by hurting the project and its contributors, then sorry but no i won't do that.
09:44 < instagibbs> You don't have to love Citrea's design, but actively reducing harm should be the default where possible.
09:44 < glozow> Currently the PR is locked for cooldown (fanquake what is the expiry for that?). I think that should be respected by everyone and we should never merge PRs that are locked. But afterward we should treat it like any other PR. Weigh in with your technical opinions and we'll decide; the garbage brigading can be ignored.
09:44 < jonatack> darosior: i mean reaching effectively across the aisle rathen than preaching to the choir, in a way that connects 
09:45 < achow101> glozow: the expiry is when someone unlocks it (there is no expiry on locking issues/prs)
09:45 < glozow> ok. when should we unlock it then?
09:45 < pinheadmz> There needs to be more effective educational outreach
09:45 < Murch[m]> It sounds to me that there a) appears to be a majority for 0 or 3, and a bunch of proponents for dropping the limit. Is there anyone arguing for the opposite (0)?
09:45 < pinheadmz> I think before the PR is reopened
09:45 < pinheadmz> Or, counter propaganda ie why utxo bloat is worse
09:45 < Sjors[m]> glozow: I do think it's better to merge it with some open nits, and improve those later.
09:46 < achow101> glozow: the request was for a day, so basically after this meeting. unless it should be locked for longer
09:46 < instagibbs> pinheadmz I think drafting the "we're doing this and here's why" before unlocking is a good idea
09:46 < Sjors[m]> Not a huge rush either, but it touches a lot of tests, so might end up needing a rebase.
09:46 < TheCharlatan> +1 instagibbs
09:46 < Murch[m]> instagibbs: How is this different from the posts in the mailing list and the PR explaining all that exactly?
09:46 < darosior> instagibbs: +1
09:46 < instagibbs> If you have something to sign off on, I'll sign off on it
09:46 -!- pseudoramdom [~pseudoram@2601:640:8b00:2d59:8062:3489:c56d:f6e8] has quit [Remote host closed the connection]
09:46 < pinheadmz> Murch those media are not properly formatted for all the users
09:47 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
09:47 < pinheadmz> Users don't read ML they read tweets
09:47 < darosior> I'm annoyed that it makes it bigger of a deal than it is, but hey
09:47 < achow101> Sjors[m]: the conflict list appears to be quite small. there may be silent conflicts though
09:47 < instagibbs> darosior ship has sailed my man
09:47 < Sjors[m]> Maybe also point out the v30 branch-off is many months away. A well reasoned argument on the mailinglist could convince us to revert even months later.
09:48 < Murch[m]> pinheadmz: okay sure, but there do seem to be some people here that don’t seem to support dropping the limit, so I’m not sure Bitcoin Core can put out a blog post. Where would this be posted and by whom?
09:48 < Murch[m]> Sjors: I would not make that argument in public after seeing how that discussion went with mempoolfullrbf
09:49 < Sjors[m]> Murch: it takes the urgency away
09:49 < pinheadmz> Maybe instagibbs idea is more fitting. "We made this call and here's why"
09:49 < pinheadmz> But make sure it lists tradeoffs too
09:49 < Sjors[m]> But might make life for mailinglist moderators annoying.
09:49 < Murch[m]> I think I’d rather leave the PR open a few more weeks to collect more input than to offer reverting it later
09:49 < jonatack> My guess is the most diplomatic and humble approach would be to close it for now and begin engaging constructively, with the option to try a bit later.
09:49 < pinheadmz> Most importantly the users seem to think big opreturn means bigger blocks which means harder to run nodes
09:49 < instagibbs> pinheadmz no perfect options, but we're picking an options whether wer like it or not 
09:49 < pinheadmz> That's such an easy thing to teach users about
09:50 < glozow> I think we could have a longer discussion about whether a prescriptive "filter" for good/bad practices still has a place in mempool policy, because this probably isn't the last of this flavor of disagreement. But perhaps for another day.
09:50 < Sjors[m]> Murch: that's fine too, if we can announce a specific intented merge-by date
09:50 < jonatack> The way it is done matters a lot to the outer community who want to feel heard and listened to. IMO.
09:50 < Murch[m]> pinheadmz: Which is funny, because OP_RETURN is not weight-discounted, so makes blocks smaller…
09:50 < instagibbs> glozow imo it's one of the last actually useful expansions that is in conflict with "paternalism" of policy
09:50 < glozow> I don't think we should give up *again*. That's why we closed it in 2023
09:50 < instagibbs> taproot is so relaxed
09:50 < pinheadmz> jonatack: +1
09:50 < darosior> How about:
09:50 < darosior> 1. PR gets re-opened
09:50 < darosior> 2. Every regular contributor who thinks this should be merged goes, ACK with rationale
09:50 < darosior> 3. After merging maintainers email the mailing list thread with their and everyone's rationale
09:50 < pinheadmz> Be mature. Close. Teach. Reopen
09:52 < darosior> Comparable to signing off on a blog post or something, without treating it as too exceptional either. Maintainers aren't caught on the spot because they can point to the support of all regular contributors.
09:52 < instagibbs> pinheadmz wanna spearhead a doc with me?
09:52 < instagibbs> I'll raise my hand
09:52 < pinheadmz> Sure
09:52 < jonatack> People think it will be merged despite all the nacks and objections. If core shows humility and patience imo it would surprise people and improve things. 
09:53 < TheCharlatan> instagibbs, I'd be interested too.
09:53 < instagibbs> And to be clear, people are allowed to disagree, please speak up if you're just being sheepish. This is for the health of the project more than the feature itself.
09:53 < Sjors[m]> I tend to agree with jonatack that a few weeks delay might help, and doesn't hurt given that achow101 pointed out it's unlikely to need many rebased
09:53 < lightlike> jonatack: or it would show that brigading works, and therefore invite more of it
09:53 < darosior> jonatack: i have yet to see a good technical argument against it. We should weigh objection on their own merit and not give in just because people are harassing us. The count of NACKs is meaningless.
09:53 < instagibbs> TheCharlatan 👍
09:53 < glozow> I'll join on the doc
09:54 < darosior> instagibbs: +100
09:54 < achow101> i don't think there's any urgency to merge or close the pr
09:54 < darosior> (not to join the doc, for your last statement)
09:54 < darosior> Also, to be clear this type of transaction in Citrea is very unlikely to end up onchain
09:54 < darosior> I raised the point because it illustrates an issue with our policy, not because there is urgency
09:54 < jonatack> lightlike: i think the process hasn't helped in this case, as willcl-ark wrote in bitcoin/meta a couple hours ago
09:55 < darosior> But the more we wait the less probable it is that people will use the less harmful way of storing data..
09:55 < instagibbs> Maybe this can be spun into positive outreach to app devs too?
09:55 < Sjors[m]> As long as the effect of brigading is a mere delay, I'm not too worried about that messaging.
09:55 < sipa> darosior: i don't think days or weeks matter here
09:55 < sipa> but months may
09:55 < instagibbs> sipa +1
09:55 < Murch[m]> darosior: EIther  way, it would only go out with the 0.30.0 release in October/November, so whether we merge this week or revisit in two weeks doesn’t really matter much
09:55 < TheCharlatan> darosior, we at least have time to the next release, no?
09:56 < darosior> Yes. just pointing out that also from their point of view there is a lot of uncertainty. The harmful way of doing it is certain to work for them.
09:56 < TheCharlatan> ah
09:56 < furszy> darosior: if they don't use the less harmful way (when available) it means they have no incentive to do it?
09:56 < Sjors[m]> A few weeks should be enough to get darosior on Joe Rogan and explain it :-)
09:56 < darosior> Murch[m]: can get them to start allocating dev resources to take advantage of it. At least they know it will happen 
09:56 < sipa> darosior: i don't think that's a good reason to let us influence our choices
09:57 < sipa> there is very good probability that citrea, or whatever individual project, just doesn't take off
09:57 < Sjors[m]> And more practically, it means several rounds of bitcoin podcasts can go through the issue and hopefully convince more people.
09:57 < fanquake> instagibbs: Is this doc / write up is going to go up on the website?
09:57 < darosior> sipa: yes again i'm not really concerned about Citrea's specific transactions
09:57 < Murch[m]> Giving people more time to understand the whole picture before revisiting the PR seems like a good idea and it doesn’t prevent us from doing what we think is right eventually
09:57 < sipa> right, likewise
09:57 < glozow> furszy: no, it means that our current "best practices" policy rules are prescriptive, but a poor reflection of best practices actually are
09:58 < Sjors[m]> It might not take off, but it does we have a six month delay in dealing with it. And once projects like this are deployed, it's harder for them to adjust - and really not worth it.
09:58 < Murch[m]> Responding with education to brigading and widespread misconceptions doesn’t feel like caving to the brigading to me. Closing the PR would, though.
09:58 < BlueMatt[m]> yea, letting this slip into the next release is really not okay, there's very nontrivial cost to the bitcoin system
09:58 < darosior> furszy: we should try to make the less harmful way be at least as cheap as the harmful way. We can do that byte-wise (and even better). But uncertainty is a cost too
09:58 < glozow> fanquake: I don't really think so tbh. But we'll need to write a release note so we can probably expand a little there?
09:59 < instagibbs> fanquake glozow as long as people go on podcasts I think that'll do more ;)
09:59 < fanquake> glozow: where will it go then?
09:59 < instagibbs> just needs to be public
09:59 < darosior> fanquake: release notes?
09:59 < pinheadmz> Needs to be treatable
09:59 < achow101> can also just be a super long comment in the pr?
09:59 < glozow> can we just post it on social media? does it need to go through official channels?
09:59 < pinheadmz> *tweet able
09:59 < pinheadmz> With clickbait title
09:59 < fanquake> So when it's being distributed, we are going to link to a gh pr, tell people to look at the rel notes in the diff?
09:59 < Murch[m]> The upcoming Optech newsletter will cover this debate, anyone want to come on the podcast on Tuesday to talk to me about it?
10:00 -!- Emc97 [~Emc99@212.129.80.110] has joined #bitcoin-core-dev
10:00 < darosior> pinheadmz: haha +1
10:00 < pinheadmz> Trick twitter users  into learning something
10:00 < fanquake> It seems odd that if as a project, we are deciding to do something, we wouldn't want to put that information in the most prominent communication channels we have
10:00 < fanquake> i.e the blog on the website
10:00 < BlueMatt[m]> Murch[m]: sure, if you want someone who doenst work on bitcoin core i can :)
10:00 < fanquake> and then link to if from our twitter
10:01 < BlueMatt[m]> oh wait ill be on a plane
10:01 < instagibbs> website is fine, did you want it on website
10:01 < glozow> a lot of people are not free on tuesday because they're flying to this conference where people are gathering to talk about mempool stuff
10:01 < achow101> i think we can decide where to post it after its written. the contents may help to decide the location
10:01 < instagibbs> yes we're going to have a mempool bloodbath next week
10:01 < instagibbs> should be awesome
10:01 < fanquake> instagibbs: I'm trying to figure out why it wouldn't go on the website
10:01 < fanquake> Seems like the only & obvious place
10:01 < Sjors[m]> glozow: that conference sounds like a good place to record some panels, assuming anyone who opposed this is there
10:02 < fanquake> If it's a change related to the software we are shipping from that same website
10:02 < darosior> If it's smaller than 1MiB i know where we could post it
10:02 < glozow> LOL
10:02 < pinheadmz> LOL
10:02 < instagibbs> fanquake I think it would be good there, sets the tone for the project 
10:02 < Murch[m]> fanquake: I have the impression that a few people here are not in favor, but nobody substantiated that when I asked earlier, so maybe not
10:02 < glozow> It just kind of feels... too official?
10:02 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
10:02 < fanquake> well the code change is going into the official binaries?
10:03 < BlueMatt[m]> the website has been used in the past for "~everyone agrees on this statement"
10:03 < instagibbs> I think it is official, in that we can disagree and move on.
10:03 < darosior> Yeah it seems to me there is much more important topic we could have a stance on, than Twitter nonsense about OP_RETURNs
10:03 < glozow> When is the last time we've written a blog post about why we merged a PR that wasn't fixing a vuln?
10:03 < darosior> But also i'm not opposed to having on the website, better than nothing
10:03 < fanquake> it seems like that is the case here though? Otherwise it wouldn't be merged?
10:03 < instagibbs> I'm not sure our past history is good example :)
10:03 < lightlike> segwit faq?
10:03 < BlueMatt[m]> i mean it can be a more general statement on policy
10:03 -!- Emc99 [~Emc99@212.129.80.110] has quit [Ping timeout: 240 seconds]
10:03 < BlueMatt[m]> it doesn't have to be *specifically* about the pr here
10:04 < Sjors[m]> https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/
10:04 < achow101> glozow: 2017 i think
10:04 < pinheadmz> this is a progressive change
10:04 < glozow> yeah
10:04 < pinheadmz> and its in response to user feedback, its a win for the users
10:04 < darosior> BlueMatt[m]: +1 i think communicating on how we see relay policy as a project would be great
10:05 < instagibbs> The people that disagree with this generally think the direction of the last 10 years is wrong, nothing new here
10:05 < achow101> anyways, we're past the scheduled end time, so I'll end the meeting here
10:05 < instagibbs> BlueMatt[m] I'll work on integrating that 👍
10:05 < instagibbs> thanks everyone
10:05 < achow101> #endmeeting
10:05 < corebot> achow101: Meeting ended at 2025-05-01T17:05+0000
10:05 < corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-01_16_00.log.json
10:05 < corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-01_16_00.log.html
10:05 < corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-01_16_00.html
10:05 < glozow> mempool manifesto wg?
10:05 < Murch[m]> lol
10:05 < achow101> lol, we can add that to the list
10:06 < Murch[m]> Have fun at BTC++
10:06 < BlueMatt[m]> we wont 😂
10:06 < Murch[m]> I’m sure you will have plenty of time to practice explaining it
10:06 < instagibbs> I will, because BlueMatt[m] will be miserable
10:06 < jonatack> btc++ is the mempool bloodbath? if so, i think there mill be people to debate with there
10:06 < achow101> jonatack: i think that's why it will be a bloodbath
10:06 < jonatack> ah, got it
10:07 < Murch[m]> I think Luke is giving two talks on policy, so yeah, there will be people that disagree there
10:08 < Sjors[m]> I survived OP_NEXT in the headquarters of the King of Ossification without a scratch, ya'll be fine.
10:08 < achow101> should the pr be unlocked now?
10:08 < instagibbs> Sjors[m] I saw you wearing that wizard hat
10:08 < instagibbs> (this is misinfo)
10:09 < jonatack> Sjors[m]: several of us indeed
10:09 < jonatack> hope to see some positive debates at btc++
10:09 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Quit: Client closed]
10:10 < pinheadmz> #restartmeeting
10:10 < pinheadmz> should we unlock the PR or not?
10:10 < pinheadmz> I guess not, not today ?
10:10 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
10:11 < instagibbs> Whatever is less painful for maintainers, PR comments aren't changing the direction 
10:11 < Sjors[m]> instagibbs: neh I got a black one at their November event
10:11 < Murch[m]> Maybe open it, and if it’s still a flood of vacuous crap, just close it again
10:11 < pinheadmz> i vote stay locked
10:11 < Murch[m]> instagibbs: FTFY: ~maintainers~ moderators
10:11 < instagibbs> right, people not me taking on the burden 
10:12 < pinheadmz> honestly if anyone has actual code feedback just email it to ptodd
10:12 < Murch[m]> haha
10:12 < instagibbs> retro, I like it
10:12 < Murch[m]> Leave it closed until the statement is out?
10:13 < achow101> :shrug: locked or unlocked, doesn't particularly bother me. I don't think it actually puts a burden on the maintainers, rather more on the mods. I've unsubscribed from it anyways.
10:14 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
10:14 < pinheadmz> stay locked then
10:14 < achow101> alrighty
10:14 < lightlike> but opening just for one comment by a regular, and close it again right after is not a good look imo
10:14 < pinheadmz> like i said, productive feedback can go through other channels
10:15 < pinheadmz> and well have a new place for everyone to argue soon
10:15 < instagibbs> achow101 yep, anyone who matters has tuned out :)
10:15 < instagibbs> Well, not everyone, 90%+
10:15 < willcl-ark> I think it could be re-opened tomorrow. Gives a full 24h cooldown to people before jumping back in
10:16 < achow101> willcl-ark: it's been locked for at least 24h
10:16 < willcl-ark> yeah but AFAIK still doing the rounds on social media etc.
10:18 < achow101> lightlike: indeed, and we shouldn't do that
10:18 < achow101> (just noticed it happened)
10:18 < glozow> lightlike: +1
10:27 -!- Emc97 [~Emc99@212.129.80.110] has quit [Quit: Client closed]
10:32 -!- jespada_ [~jespada@r179-25-202-180.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:33 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
10:33 -!- jespada [~jespada@r179-25-202-180.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
10:34 < bitcoin-git> [bitcoin] Brotcrunsher opened pull request #32397: doc: Add hint about avoiding spaces in paths when building on Windows (master...HintNoSpace) https://github.com/bitcoin/bitcoin/pull/32397
10:36 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Client Quit]
10:37 -!- sebastianvstaa [~sebastian@45.86.202.151] has quit [Quit: Client closed]
10:39 < jonatack> pinheadmz: instagibbs: i volunteer to do a final review of the doc if you'd like
10:40 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:c1:cbfb:120:4bb2] has quit [Quit: Christoph_]
10:40 < instagibbs> once shaped up substantially it'll be posted here as a gist or equivalent 👍
10:41 < jonatack> cool, or a midway check if that can be helpful
10:57 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
10:58 -!- dviola [~diego@user/dviola] has quit [Ping timeout: 276 seconds]
10:59 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
11:09 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has quit [Ping timeout: 240 seconds]
11:11 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1002] has joined #bitcoin-core-dev
11:13 -!- diego [~diego@2804:14c:5781:836f::871] has joined #bitcoin-core-dev
11:14 -!- brunoerg [~brunoerg@169.150.201.26] has quit [Ping timeout: 252 seconds]
11:16 -!- diego [~diego@2804:14c:5781:836f::871] has quit [Max SendQ exceeded]
11:26 -!- diego [~diego@2804:14c:5781:836f::871] has joined #bitcoin-core-dev
11:27 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:32 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
11:36 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:40 < Murch[m]> errrr, either open it for everyone or leave it closed for everyone, but unlocking it for one-sided contributions seems like a surefire way to exacerbate this whole waste of time drama
11:40 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:41 < Murch[m]> Ah, I see now what lightlike was referring to.
11:42 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
11:44 < Murch[m]> Like are you trying to give other people more ammunition to take potshots?
11:44 < Murch[m]> that just undermines the work of those that have been doing outreach for the past two days to educate and try to build understanding for the bigger picture
11:45 < Murch[m]> srsly.
11:45 < achow101> we had a discussion, the comment is removed
11:45 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 268 seconds]
11:52 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
11:59 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:c1:cbfb:120:4bb2] has joined #bitcoin-core-dev
11:59 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:c1:cbfb:120:4bb2] has quit [Client Quit]
12:00 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
12:11 < bitcoin-git> [bitcoin] strmfos opened pull request #32398: chore(ci): bump docker/build-push-action to v6.16.0 (master...master) https://github.com/bitcoin/bitcoin/pull/32398
12:11 < bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/fc6346dbc8dc...5b8046a6e893
12:11 < bitcoin-git> bitcoin/master 0ad7d7a Andrew Toth: test: chainstate write test for periodic chainstate flush
12:11 < bitcoin-git> bitcoin/master d73bd9f Andrew Toth: validation: write chainstate to disk every hour
12:11 < bitcoin-git> bitcoin/master b557fa7 Andrew Toth: refactor: rename fDoFullFlush to should_write
12:11 < bitcoin-git> [bitcoin] achow101 merged pull request #30611: validation: write chainstate to disk every hour (master...write-chainstate-every-hour) https://github.com/bitcoin/bitcoin/pull/30611
12:12 < bitcoin-git> [bitcoin] fanquake closed pull request #32398: chore(ci): bump docker/build-push-action to v6.16.0 (master...master) https://github.com/bitcoin/bitcoin/pull/32398
12:16 -!- diego [~diego@2804:14c:5781:836f::871] has quit [Ping timeout: 248 seconds]
12:20 -!- diego [~diego@177.34.235.126] has joined #bitcoin-core-dev
12:25 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
12:26 -!- jadi [~jadi@d23-16-146-102.bchsia.telus.net] has joined #bitcoin-core-dev
12:41 -!- jadi [~jadi@d23-16-146-102.bchsia.telus.net] has quit [Remote host closed the connection]
12:45 -!- aleggg [~aleggg@187.101.224.222] has quit [Ping timeout: 244 seconds]
12:49 -!- aleggg [~aleggg@187.101.224.222] has joined #bitcoin-core-dev
13:18 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
13:31 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
14:05 -!- jespada [~jespada@r179-25-202-180.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
14:19 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
14:26 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
14:34 -!- Guest69 [~Guest69@2601:643:867e:3e10:bdce:afde:a7c8:a6ea] has joined #bitcoin-core-dev
14:34 -!- Guest69 [~Guest69@2601:643:867e:3e10:bdce:afde:a7c8:a6ea] has quit [Client Quit]
15:42 < bitcoin-git> [bitcoin] mzumsande opened pull request #32399: cli: add -usefile option (master...202505_cli_loadfile) https://github.com/bitcoin/bitcoin/pull/32399
15:53 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
15:58 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
16:03 -!- Cory55 [~Cory55@user/pasha] has quit [Quit: Client closed]
16:04 -!- Cory55 [~Cory55@user/pasha] has joined #bitcoin-core-dev
16:25 -!- robszarka [~szarka@2603:3003:4eac:100:a42d:5114:b601:d074] has quit [Quit: Leaving]
16:25 -!- szarka [~szarka@2603:3003:4eac:100:a42d:5114:b601:d074] has joined #bitcoin-core-dev
16:54 < badkat> can anybody guide me to get into bitcoin network again? my last interaction to this blockchain was in 2013 
17:06 -!- LainIwakura [~LainIwaku@user/LainIwakura] has joined #bitcoin-core-dev
17:48 -!- neutrino1 [~neutrino7@user/neutrino777] has joined #bitcoin-core-dev
17:51 -!- neutrino777 [~neutrino7@user/neutrino777] has quit [Ping timeout: 268 seconds]
18:00 < bitcoin-git> [bitcoin] davidgumberg opened pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400
18:18 -!- diego [~diego@177.34.235.126] has left #bitcoin-core-dev []
18:19 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
18:35 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:03 -!- synexic [~syn@toucht.one] has quit [Ping timeout: 248 seconds]
19:46 -!- synexic [~syn@toucht.one] has joined #bitcoin-core-dev
20:00 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has joined #bitcoin-core-dev
20:02 -!- adil1 [~Thunderbi@2402:d000:8134:2f97:7ccd:e659:94e2:d938] has joined #bitcoin-core-dev
20:04 -!- adil1 [~Thunderbi@2402:d000:8134:2f97:7ccd:e659:94e2:d938] has quit [Client Quit]
20:05 -!- adil [~Thunderbi@2402:d000:8134:2f97:c384:1f18:9ca6:4eff] has quit [Ping timeout: 252 seconds]
20:48 -!- adil [~Thunderbi@2402:4000:b1c1:8d85:3497:c22e:b01d:407c] has joined #bitcoin-core-dev
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:28 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
21:44 -!- adil1 [~Thunderbi@2402:4000:b1c1:8d85:3497:c22e:b01d:407c] has joined #bitcoin-core-dev
21:48 -!- adil [~Thunderbi@2402:4000:b1c1:8d85:3497:c22e:b01d:407c] has quit [Ping timeout: 252 seconds]
21:48 -!- adil1 [~Thunderbi@2402:4000:b1c1:8d85:3497:c22e:b01d:407c] has quit [Ping timeout: 260 seconds]
21:49 -!- adil [~Thunderbi@2402:4000:b1c1:d787:3497:c22e:b01d:407c] has joined #bitcoin-core-dev
21:51 -!- adil [~Thunderbi@2402:4000:b1c1:d787:3497:c22e:b01d:407c] has quit [Client Quit]
21:52 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
21:59 -!- kevkevin_ [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
22:07 -!- Cory55 [~Cory55@user/pasha] has quit [Quit: Client closed]
22:08 -!- Cory55 [~Cory55@user/pasha] has joined #bitcoin-core-dev
22:25 -!- LainIwakura [~LainIwaku@user/LainIwakura] has quit [Ping timeout: 240 seconds]
22:29 < vasild> Technically, I am in favor of "3) Remove limits entirely (~Peter Todd's PR)". IMO that is the correct technical decision. However this has become political now. Enforcing the correct technical decision on disagreeing people is not politically correct. Now, if those disagreeing are a loud minority, what would making this configurable do? I guess it would make them happy and wouldn't have an impact 
22:29 < vasild> network-wide. That sounds technically and politically correct to me.
22:45 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
23:09 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
23:09 -!- LainIwakura [~LainIwaku@user/LainIwakura] has joined #bitcoin-core-dev
23:22 -!- LainIwakura [~LainIwaku@user/LainIwakura] has quit [Ping timeout: 240 seconds]
23:23 < Murch[m]> Giving people a knob to turn that doesn't do anything useful and just harms them is kinda wrong
23:23 -!- sliv3r__- [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
23:23 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Read error: Connection reset by peer]
23:24 -!- Cory37 [~Cory55@user/pasha] has joined #bitcoin-core-dev
23:28 -!- Cory55 [~Cory55@user/pasha] has quit [Ping timeout: 240 seconds]
23:35 < _aj_> Murch[m]: does the person turning the knob get a say in whether they consider it to be harming them?
23:39 -!- LainIwakura [~LainIwaku@user/LainIwakura] has joined #bitcoin-core-dev
23:44 -!- LainIwakura [~LainIwaku@user/LainIwakura] has quit [Quit: Client closed]
23:48 -!- neutrino777 [~neutrino7@user/neutrino777] has joined #bitcoin-core-dev
23:51 -!- neutrino1 [~neutrino7@user/neutrino777] has quit [Ping timeout: 252 seconds]
--- Log closed Fri May 02 00:00:30 2025