--- Log opened Thu May 22 00:00:50 2025
00:08 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
00:18 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:54 -!- Guest52 [~Guest52@114.10.47.60] has joined #bitcoin-core-dev
00:54 -!- Guest52 [~Guest52@114.10.47.60] has quit [Client Quit]
01:27 -!- u0_a2682 [~u0_a268@144.134.58.114] has joined #bitcoin-core-dev
01:30 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Ping timeout: 244 seconds]
01:36 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Quit: Client closed]
02:00 < bitcoin-git> [bitcoin] fanquake pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/87ec923d3a7a...a42faa25d8f7
02:00 < bitcoin-git> bitcoin/master a8e2342 Hennadii Stepanov: cmake: Remove `ENABLE_SSE41` from `bitcoin-build-config.h`
02:00 < bitcoin-git> bitcoin/master 8689628 Hennadii Stepanov: cmake: Remove `ENABLE_AVX2` from `bitcoin-build-config.h`
02:00 < bitcoin-git> bitcoin/master 1e90052 Hennadii Stepanov: cmake: Remove `ENABLE_X86_SHANI` from `bitcoin-build-config.h`
02:00 < bitcoin-git> [bitcoin] fanquake merged pull request #32551: cmake: Remove `ENABLE_{SSE41,AVX2,X86_SHANI,ARM_SHANI}` from `bitcoin-build-config.h` (master...250518-crypto-macros) https://github.com/bitcoin/bitcoin/pull/32551
02:33 < bitcoin-git> [bitcoin] fanquake opened pull request #32584: depends: hard-code necessary c(xx)flags rather than setting them per-host (master...depends_hard_code_flags) https://github.com/bitcoin/bitcoin/pull/32584
02:36 -!- charlie_capt [~charlie_c@119.75.194.99] has joined #bitcoin-core-dev
02:45 -!- tarotfied [~tarotfied@user/tarotfied] has quit [Quit: WeeChat 4.1.1]
03:01 -!- mcey_ [~emcy@185.69.144.38] has joined #bitcoin-core-dev
03:04 -!- tarotfied [~tarotfied@user/tarotfied] has joined #bitcoin-core-dev
03:05 -!- mcey [~emcy@148.252.145.122] has quit [Ping timeout: 276 seconds]
03:06 -!- [[a]TradeTestnet [~a]TradeT@47.214.145.207] has joined #bitcoin-core-dev
03:06 -!- [AtAltQuickCOM [~AtAltQuic@47.214.145.207] has joined #bitcoin-core-dev
03:06 -!- [[ForRealBitcoin [~ForRealB@47.214.145.207] has joined #bitcoin-core-dev
03:18 -!- robszarka [~szarka@2603:3003:4eac:100:28aa:caf5:198d:3518] has quit [Quit: Leaving]
03:18 -!- szarka [~szarka@2603:3003:4eac:100:28aa:caf5:198d:3518] has joined #bitcoin-core-dev
03:43 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e4c0:e915:4356:76e9] has joined #bitcoin-core-dev
03:47 -!- kevkevin [~kevkevin@2601:243:197e:8f10:e4c0:e915:4356:76e9] has quit [Ping timeout: 248 seconds]
03:48 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Quit: Client closed]
03:51 -!- spynxic [~spynxic@spynxic.powered.by.lunarbnc.net] has quit [Ping timeout: 276 seconds]
03:52 -!- spynxic [~spynxic@spynxic.powered.by.lunarbnc.net] has joined #bitcoin-core-dev
03:55 -!- [AtAltQuickCOM [~AtAltQuic@47.214.145.207] has quit [Quit: Client closed]
03:56 -!- charlie_capt [~charlie_c@119.75.194.99] has joined #bitcoin-core-dev
04:01 -!- jespada [~jespada@r190-133-32-136.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
04:05 -!- [[ForRealBitcoin [~ForRealB@47.214.145.207] has quit [Quit: Client closed]
04:05 -!- [[a]TradeTestnet [~a]TradeT@47.214.145.207] has quit [Quit: Client closed]
04:05 < bitcoin-git> [bitcoin] fanquake pushed 23 commits to 29.x: https://github.com/bitcoin/bitcoin/compare/3fad438b8300...589b56192f53
04:05 < bitcoin-git> bitcoin/29.x ca70d5c laanwj: Remove support for RNDR/RNDRRS for aarch64 on Linux
04:05 < bitcoin-git> bitcoin/29.x 85f3e1d Brandon Odiwuor: test: Handle empty string returned by CLI as None in RPC tests
04:05 < bitcoin-git> bitcoin/29.x 64552c8 Hennadii Stepanov: ci: Add workaround for vcpkg's libevent package
04:05 < bitcoin-git> [bitcoin] fanquake merged pull request #32292: [29.x] Backports (29.x...29_x_backports) https://github.com/bitcoin/bitcoin/pull/32292
04:13 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a42faa25d8f7...35bf3f88398d
04:13 < bitcoin-git> bitcoin/master 6b4bcc1 David Gumberg: random: Use modern Windows randomness functions
04:13 < bitcoin-git> bitcoin/master 35bf3f8 merge-script: Merge bitcoin/bitcoin#32400: random: Use modern Windows randomness functio...
04:13 < bitcoin-git> [bitcoin] fanquake merged pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400
04:17 < gmaxwell_> darn thats sad that arm continues to be such a circus of incompatible hardware. :(
04:17 -!- gmaxwell_ is now known as gmaxwell
04:37 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Quit: Client closed]
04:47 -!- _flood [~flooded@146.70.228.164] has joined #bitcoin-core-dev
04:48 -!- flooded [~flooded@146.70.228.164] has quit [Remote host closed the connection]
04:49 < bitcoin-git> [bitcoin] maflcko opened pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
05:09 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has joined #bitcoin-core-dev
05:10 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has quit [Read error: Connection reset by peer]
05:11 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has joined #bitcoin-core-dev
05:16 -!- charlie_capt [~charlie_c@119.75.194.99] has joined #bitcoin-core-dev
05:18 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Client Quit]
05:18 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
05:25 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
05:27 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
05:27 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
05:37 -!- jespada [~jespada@r190-133-32-136.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
05:42 -!- jespada [~jespada@r190-133-32-136.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:04 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
06:07 -!- u0_a268 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has joined #bitcoin-core-dev
06:08 -!- u0_a268 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has quit [Read error: Connection reset by peer]
06:08 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
06:10 -!- u0_a2682 [~u0_a268@144.134.58.114] has quit [Ping timeout: 276 seconds]
06:13 -!- u0_a2682 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has joined #bitcoin-core-dev
06:13 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Read error: Connection reset by peer]
06:13 -!- u0_a2682 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has quit [Read error: Connection reset by peer]
06:14 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
06:17 -!- u0_a2682 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has joined #bitcoin-core-dev
06:18 -!- u0_a2683 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
06:18 -!- u0_a2682 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has quit [Read error: Connection reset by peer]
06:19 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Read error: Connection reset by peer]
06:26 < bitcoin-git> [bitcoin] i-am-yuvi opened pull request #32587: [WIP] test: Fix reorg patterns in mempool tests to use proper fork-based approach (master...2025-05-update_test_reorg_behaviour) https://github.com/bitcoin/bitcoin/pull/32587
06:29 < bitcoin-git> [bitcoin] maflcko opened pull request #32588:  util: Abort on failing CHECK_NONFATAL in debug builds  (master...2505-abort-debug-check-nonfatal) https://github.com/bitcoin/bitcoin/pull/32588
06:30 -!- u0_a268 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has joined #bitcoin-core-dev
06:32 -!- u0_a2682 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
06:32 -!- u0_a268 [~u0_a268@2001:8004:1302:415e:61b8:48e6:8dc6:7314] has quit [Read error: Connection reset by peer]
06:33 -!- u0_a2683 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Ping timeout: 272 seconds]
06:40 -!- u0_a2682 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Ping timeout: 265 seconds]
06:42 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
06:54 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
06:54 -!- jespada [~jespada@r190-133-32-136.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 252 seconds]
06:54 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
06:57 -!- jespada [~jespada@r167-61-220-219.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:57 < bitcoin-git> [bitcoin] fanquake opened pull request #32589: [29.x] More backports (29.x...more_29_backports) https://github.com/bitcoin/bitcoin/pull/32589
07:02 -!- u0_a2682 [~u0_a268@144.134.58.114] has joined #bitcoin-core-dev
07:06 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Ping timeout: 252 seconds]
07:06 < bitcoin-git> [bitcoin] glozow pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/35bf3f88398d...d2c9fc84e171
07:06 < bitcoin-git> bitcoin/master 7bc64a8 Sebastian Falbesoner: test: properly check for per-tx sigops limit
07:06 < bitcoin-git> bitcoin/master d2c9fc8 merge-script: Merge bitcoin/bitcoin#32533: test: properly check for per-tx sigops limit
07:06 < bitcoin-git> [bitcoin] glozow merged pull request #32533: test: properly check for per-tx sigops limit (master...202505-test-exact_per_tx_sigopcost_check) https://github.com/bitcoin/bitcoin/pull/32533
07:07 -!- Guest33 [~Guest33@2607:fb90:4880:d62a:f583:e91c:c0bd:3231] has joined #bitcoin-core-dev
07:08 -!- Guest33 [~Guest33@2607:fb90:4880:d62a:f583:e91c:c0bd:3231] has quit [Client Quit]
07:22 -!- dermoth [~dermoth@user/dermoth] has quit [Remote host closed the connection]
07:25 -!- dermoth [~dermoth@user/dermoth] has joined #bitcoin-core-dev
07:26 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has joined #bitcoin-core-dev
07:26 -!- u0_a2682 [~u0_a268@144.134.58.114] has quit [Read error: Connection reset by peer]
07:45 < bitcoin-git> [bitcoin] instagibbs opened pull request #32591: test: fix and augment block tests of invalid_txs (master...2025-05-fix_invalidtx_test) https://github.com/bitcoin/bitcoin/pull/32591
08:12 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:27 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
08:35 -!- u0_a268 [~u0_a268@2001:8003:709f:5300:d96:86e9:bb42:eac8] has quit [Quit: WeeChat 4.6.2]
08:40 < sipa> #proposedmeetingtopic Statement on transaction relay policy
08:47 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
08:57 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has quit [Remote host closed the connection]
08:57 -!- Emc99 [~Emc99@212.129.83.156] has joined #bitcoin-core-dev
08:58 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-dev
08:59 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
09:00 < achow101> #startmeeting
09:00 < corebot> achow101: Meeting started at 2025-05-22T16: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 < lightlike> hi
09:00 < dzxzg> hi
09:00 < rkrux> hi
09:00 < hebasto> hi
09:00 < abubakarsadiq> 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 < hodlinator> hi
09:00 < johnny9dev> hi
09:00 < TheCharlatan> hi
09:00 < vasild> #here
09:00 < cfields> hi
09:01 < achow101> There are 2 preproposed meeting topics this week. Any last minute ones to add?
09:01 < furszy> hi
09:01 < instagibbs> hi
09:01 < Murch[m]> Hi
09:01 < stickies-v> hi
09:01 < jon_atack> hi
09:01 < achow101> #topic Kernel WG Update (TheCharlatan)
09:01 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has joined #bitcoin-core-dev
09:01 < purpleKarrot> hi
09:02 < TheCharlatan> We've been having more directional conversations on the role of the library within the project, whether it should include the mempool, and whether the library could eventually be split out into a separate repository.
09:02 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
09:02 < TheCharlatan> I'll try to have some demo repositories / draft PRs open about these topics over the next few weeks.
09:03 < glozow> hi
09:03 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
09:03 < TheCharlatan> Other than that, looking for review on #32317 and #31382.
09:03 < corebot> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
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> that's all :)
09:03 < willcl-ark> Hi
09:03 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
09:04 < sipa> Getting some review on the next PR in the txgraph land, #31553 (3rd out of 4, after that the full cluster mempool is likely unblocked)
09:04 < corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
09:04 < instagibbs> DoWork one is necessary I presume?
09:05 < sipa> yeah, that's the 4th one
09:05 < instagibbs> 👍ack
09:05 < sipa> I have also opened #32545, to replace the existing linearization algorithm with SFL (spanning forest linearization), a drop in replacement which apparently performs far better on hard clusters
09:05 < corebot> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
09:06 < sipa> There are some links to the delving posts with motivation and benchmarks.
09:06 < sipa> That's it from me.
09:06 < achow101> #topic MuSig2 WG Update (achow101, rkrux)
09:06 < achow101> #31622 has been merged, we're down to 2 PRs left in this project
09:07 < corebot> achow101: Error: That URL raised <Connection timed out.>
09:07 < achow101> The next PR to review is #31244 which has been getting some review over the past few weeks.
09:07 < corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
09:07 < achow101> The final PR, #29675, is fully rebased and up to date if anyone wants to test that out or if it will help with reviewing 31244.
09:07 < 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:07 < achow101> #topic orphan resolution WG Update (glozow)
09:07 < glozow> I've pushed to #31829 and it is ready for review. It includes the multi-index reimplementation and the new eviction strategies we discussed at coredev. I think it's fine as 1 PR, but open to ideas on reorganizing/splitting.
09:07 < corebot> https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
09:08 < sipa> cool, will look
09:08 < glozow> I talked to marcofleon today about adding a fuzzer for checking that 1p1cs always propagate regardless of spammy peers. But there are various tests etc on that PR as well
09:08 < glozow> sipa: thanks!
09:08 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
09:08 < glozow> that's it from me
09:09 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
09:09 < achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
09:09 < johnny9dev> This week we onboarded a new contributor, goqusan. He will be helping implement the QML components in the wallet views. He's starting with the receive page and added QR encoding. bitcoin-core/gui-qml#454
09:09 < johnny9dev> Christoph has been doing work on the Animations for the wallet and fixed the main transition easing with bitcoin-core/gui-qml#453
09:09 < johnny9dev> For me, I implemented the initialization states for the WalletQmlController and added the first instance of the Skeleton loading animation that Christoph proposed last week. bitcoin-core/gui-qml#454
09:09 < johnny9dev> This following week we'll be focused on getting bitcoin-core/gui-qml#450 mergable, implementing more of the Receive page, and adding input validation and error strings on to the Send page.
09:09 < corebot> https://github.com/bitcoin-core/gui-qml/issues/454 | Add QRImageProvider by goqusan · Pull Request #454 · bitcoin-core/gui-qml · GitHub
09:09 < corebot> https://github.com/bitcoin-core/gui-qml/issues/453 | Change PageStack easing type to InOutCubic by GBKS · Pull Request #453 · bitcoin-core/gui-qml · GitHub
09:09 < corebot> https://github.com/bitcoin-core/gui-qml/issues/454 | Add QRImageProvider by goqusan · Pull Request #454 · bitcoin-core/gui-qml · GitHub
09:09 < corebot> https://github.com/bitcoin-core/gui-qml/issues/450 | Add Multiple Recipients option to the Send form by johnny9 · Pull Request #450 · bitcoin-core/gui-qml · GitHub
09:10 < achow101> #topic project-related MSVC bug reports (hebasto)
09:10 < hebasto> Hi everyone! This is a short announcement.
09:10 < hebasto> To compile Bitcoin Core on Windows, there is currently only one supported option: MSVC.
09:10 < hebasto> As with any other compiler, the development process exposes regressions and new bugs in MSVC.
09:10 < hebasto> However, the process of improving MSVC, from reporting an issue to applying a fix, differs significantly from that of open-source compilers.
09:10 < hebasto> To improve our chances, I encourage anyone with a microsoft account to consider upvoting issue reports related to Bitcoin Core.
09:11 < hebasto> Here is a link to current issues, as well as some that have been closed: https://gist.github.com/hebasto/aa42915f88faa4a0ee02655bb55ee624
09:11 < hebasto> That's it. Thank you!
09:11 < sipa> Does mingw-w64 building not work on Windows?
09:12 < fanquake> You could just use that with the windows subsystem for linux yes
09:12 < hebasto> from within WSL
09:12 < achow101> but not natively with like cygwin or similar?
09:12 < fanquake> I'd encourage devs to do that in any case, so they are actually testing what we are shipping to users
09:13 < hebasto> we tested only MSVC native builds
09:13 < gmaxwell> If it was good enough for Satoshi... ;)
09:15 < achow101> #topic Statement on transaction relay policy (sipa)
09:16 < sipa> Hi.
09:16 < cfields> 👋
09:16 < sipa> I've written a short statement about the relation between Bitcoin Core developments and transaction relay policy, with the help of darosior and glozow
09:16 < sipa> https://gist.github.com/sipa/2521731e65ba779e3ce9f9305c6a538c
09:17 < achow101> planning to post to the website?
09:17 < sipa> I think it would be useful to publish something like this, possibly on the bitcoincore.org website if enough people agree
09:18 < sipa> but i'm open to hearing opinions
09:18 < darosior> Ack.
09:19 < achow101> will review
09:19 < gmaxwell> I couldn't remember if the project had every blocked a widespread active use.  The closest I could find is the dust limit stuff, but that seemed to go in after the penny dust had pretty much stopped AFAICT.
09:19 < gmaxwell> s/every/ever/
09:19 < stickies-v> very nice statement, will think of suggestions but ack for me too, thank you all for writing this up
09:20 < sipa> So, what do people think... have a short period for comments, and then ask who would be willing to put their name under it?
09:20 < dzxzg> "Within transaction relay, this may include adding policies for DoS protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks." I agree with this, but it seems to beg the question, how is demand weighed against DoS potential?
09:20 < sliv3r__> nice statement
09:20 < sipa> dzxzg: thankfully not a question i feel like we've had to answer yet, but a day may come
09:21 < instagibbs> DoS here doesn't mean usage of blockspace you don't like, but cpu/memory/etc
09:21 < gmaxwell> in any case, I think it's a very nice statement, and it feels very much in the tradition of the values I always understood coming from the project.
09:21 < sipa> right, exactly
09:21 < instagibbs> may be important to spell that out
09:21 < achow101> sipa: maybe a week for comments, and next week we can discuss posting to the website and who wants to put their name on it?
09:21 < fanquake> I'm not sure that having a list of names below is going to be beneficial, or is actually needed?
09:21 < darosior> sipa: re what do people think, maybe open a PR on the website for comments?
09:21 < jon_atack> fanquake: agree
09:21 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
09:21 < jon_atack> sipa: well done
09:21 < glozow> I think this can be opened as a PR to the website
09:22 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
09:22 < TheCharlatan> "> Note that this is not condoning non-financial data block space usage." this is what the issue seems to boil down to for users of Bitcoin Core, but I feel like this is not clear enough.
09:22 < sipa> glozow: right now? that would make suggesting corrections easy
09:22 < abubakarsadiq> nicely written, ack
09:23 < sipa> TheCharlatan: happy to hear ideas on making it clearer, but i'm also weary of going into too much detail
09:23 < glozow> sipa: I think so, given people are writing their comments here for specific lines. Perhaps worth doing this review process on the PR
09:23 < darosior> I would say yes because i don't see how waiting before opening the PR to the website would help
09:23 < dzxzg> instagibbs: Sure, whatever you take it to mean, the question would still stand. What if bare multisig outputs were to become popular? But I agree with sipa that maybe this question can be postponed for if/when it arrives
09:23 < fanquake> (if nobody wants their name attached, would we post it anyway? I'd like to think yes, if it represents the software we are shipping)
09:23 < glozow> dzxzg: I don't think bare multisig is a good example of DoS vs demand. Perhaps gigantic transacttions?
09:24 < gmaxwell> dzxzg: those don't fall under the dos banner (uh except related to sigops limit?)
09:24 < instagibbs> dzxzg bare multisig isn't a DoS (except for jank sigops counting), but sure if some new thing came up it would have to be weighed independently 
09:24 < gmaxwell> instagibbs++
09:24 < sliv3r__> won't it end up an open PR like datacarriers' ones?
09:24 < gmaxwell> dzxzg: DOS obviously means to me things like quadratic hashing.
09:24 < instagibbs> like, if dust was being completely ignored (eep)
09:25 < sipa> dzxzg: bare multisig is standard (up to 3 pubkeys), but even if bigger multisig were to become common, my personal opinion would be to relax the policy - it's not DoSy in any way, only (perhaps subjectively) dumb
09:25 < gmaxwell> dzxzg: the closest to 'usage' I see DOS going might be dusting attacks. but generally I expect DOS to mean memory/algorithimic non-linearities.
09:25 < dzxzg> I thought bare multisig had a DoS issue, my mistake. 
09:25 < instagibbs> block building gets annoying, as certain pools have found 😬
09:25 < gmaxwell> sipa: except for sigop counting.
09:25 < darosior> The question of DoS is interesting and i remember discussing it with some other contributors, but debating it now is off topic i think
09:25 < sipa> ah, and bare multisig of course has higher UTXO set impact
09:25 < sipa> that's perhaps a legitimate concern
09:26 < sipa> yeah, seems a bit of tangent today
09:26 < achow101> fanquake: I think the point of having individual names is because it should be perceived as a statement made with group support. possibly there are contributors who disagree with it and would not want their name to be on it, which would be less clear if there was not a list of names attached?
09:26 < gmaxwell> sipa: because dumb consenssus rules count sigops in OUTPUTS...
09:26 < Murch[m]> sipa: Especially due to its use for stamps and them getting spent at an uncommonly low rate
09:26 < gmaxwell> I actually think clarifying dos would be nice and important, but it might not be possible.
09:26 < dzxzg> Sure, I didn't mean to debate it, I was just sharing a question that I had reading the document, sorry for pushing off-topic
09:26 < instagibbs> gmaxwell ++ yeah just saying
09:26 < stickies-v> attaching names could be powerful but only if a large number of contributors are willing to do so, otherwise it could have the opposite effect
09:26 < gmaxwell> The first three alternatives I considered were worse.  "to address vulnerablities in the software or protocol" -- worse.
09:26 < fanquake> achow101: right, but if you end up with, for example, 4 names, that'd be a weird thing to post 
09:26 < sipa> dzxzg: it is a good question, and i don't know the answer :)
09:26 < achow101> and I do think that if no one wanted to put their name on it, we wouldn't post it to the website
09:27 < Murch[m]> fanquake: I think there would be more than four names.
09:27 < glozow> fwiw I don't think the goal of this post is to prescribe what policy is for, I think it's just a statement to clarify a general intention to remove certain kinds of policy and why
09:27 < instagibbs> (or add)
09:27 < achow101> fanquake: yeah, there's definitely a threshold
09:27 < stickies-v> i'm supportive of adding my name, with the only caveat that we probably don't want to create too much precedent of having to sign off blog posts by contributors that support it
09:27 < Murch[m]> Happy to sign, fwiw
09:27 < fanquake> Murch: sure, but it's not clear what the threshhold is
09:28 < sipa> stickies-v: there is precedent, though very rare, and quite long ago
09:28 < gmaxwell> I hope there aren't significant contributors that disagree with this, if there are that should be hammered out (hammer mostly to be applied to contributor). :P
09:28 < achow101> also, having names would allow other people not necessarily involved in the project be able to endorse it as well
09:28 < jon_atack> re names, it could have consequences for those who add (naming and shaming) and for those who do not (didn't show support)
09:28 < darosior> I am happy to put my name on it but i agree with fanquake that it's not necessary. This what the project has always done and published binaries implementing this vision, i think it's fine to have it spelled out without necessarily stating who agrees explicitly or not
09:28 < rkrux> +1 for opening a PR - I'd review it, don't mind signing it
09:28 < fanquake> gmaxwell: that's kind of why I think the names are redundant
09:28 < cfields> achow101: I don't see anything I disagree with, but I also don't feel as though my signature adds any value here. I'm not sure individual names are necessary.
09:28 < gmaxwell> achow101: maybe better to just have another thing where people can lodge their support.
09:28 < jon_atack> omitting the names would avoid that
09:28 < fanquake> if people didn't agree, we'd have a PR, with enough ACKs, to change the software
09:28 < fanquake> and then the project would ship something different
09:29 < fanquake> If that's not the case, then what we are shipping represents the views of the project
09:29 < cfields> yeah, releases with policy changes don't come with statements/signatures :)
09:29 < fanquake> so it seems like any statement on the website, can be from the project, collectively
09:29 < Murch[m]> I’m also fine with presenting this as the view of the project
09:29 < stickies-v> the only reason in this case i'd be supportive of adding names is that it seems some people have a perception of maintainers / some contributors being almighty, and adding names helps show that it's not just a cabal pushing this but has widespread support among contributors
09:30 < darosior> fanquake: +1
09:30 < glozow> I also don't know if signatures are worth putting - people who want to personally endorse it can post it on social media? I think this post can follow our typical governance process for things that go onto the website. If people are strongly opposed then maybe we can have a conversation about something more granular than on/off website.
09:30 < achow101> stickies-v: yes, that
09:30 < stickies-v> but agreed with fanquake that it absolutely shouldn't be necessary
09:30 < gmaxwell> I can say that in the little contribution I've been doing in public outreach I'd like to be able to say that it went in without any opposition from the regular contributors.
09:30 < sipa> i feel there is a bit of a philosophical difference, in that releases represent the contributors' agreement at this very moment, while a post like this is a longer-term vision - and it's good to recognize that it's still a vision of specific people, and the set of people can change over time
09:30 < cfields> maybe fanning the flames, but something like this could potenially be PRd to Core as a guideline, and referenced/copied on the website for visibility. 
09:30 < Murch[m]> And the threshold thing cuts the opposite way. If a couple minor contributors disagree, would we still publish etc?
09:30 < gmaxwell> cfields+1.
09:30 < gmaxwell> Murch[m]: they can also be asked to leave.
09:31 < gmaxwell> There is nothing wrong with people having a different vision!
09:31 < darosior> sipa: people's vision change, i don't think why we should expect a blog post to reflect someone's future vision more so than a binary
09:32 < gmaxwell> presumably if this understanding gets change the document should be amended/marked historical.
09:32 < lightlike> gmaxwell: why would they be asked to leave - there is nothing wrong with people withing the project having a different vision imo
09:32 < glozow> there can be a sentence saying "this only reflects the views of the *current* contributors" etc
09:32 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
09:32 < instagibbs> If your work doesn't touch relay (most don't), I don't know why it would be an issue
09:32 -!- rkrux [~rkrux@user/rkrux] has joined #bitcoin-core-dev
09:32 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has quit [Quit: Christoph_]
09:33 < gmaxwell> lightlike: sometimes, sometimes not! depends on their approach. e.g. having a different view is fine, but not if it's in the form of being obstructionist. Some people historically around the project have had difficulty with that.
09:33 < darosior> lightlike: depends on the compatibility of their vision, the specific things they disagree with, etc.. It's a case by case basis and in any ways i think someone that disagree with everybody else would leave without needing to be asked
09:33 < gmaxwell> hahaha
09:33 < sliv3r__> glozow: that + the date I think would work
09:33 < gmaxwell> but anyways, I apologize for starting a tangent.  
09:33 < achow101> the point of having names is to shape how people will perceive the post, and I think that having the names of people who have not been actively participating in the discussion would help bolster the point that it is actually an opinion of many people in the project, not something being "forced" onto the project
09:34 < achow101> (and it seems highly likely that people not actively participating in the discussion would put their names on it, based on this discussion)
09:34 < Murch[m]> darosior: If only ;)
09:34 < gmaxwell> unfortunately most of the public has no idea who many people are, so unless you're gonna list them along side git blame LOC percentages... 
09:34 < glozow> I'm a little wary of enumerating the people that twitter should channel hatred towards
09:34 < jon_atack> glozow: yep
09:34 < gmaxwell> (As I learned when public comments where accusing me and bluematt of having no idea of how compactblocks works... :P  )
09:34 < sipa> gmaxwell: hahaha
09:35 < darosior> I don't think having names is a good idea, but i also don't feel strongly. Whichever the author chooses.
09:35 < achow101> I think it's also not a good assumption to expect people to understand how ACK/NACKs work with merging changes to both the software and the website
09:36 < sipa> gmaxwell: i think you're right in that "being able to say that it went it without opposition from regular contributors" is important, perhaps more important than having actual names on it
09:36 < instagibbs> names could also be on the PR via ACK, then not on website, halfway 🤷
09:36 < Murch[m]> gmaxwell: To which you obviously replied "Do you have any idea who I am?"
09:36 < gmaxwell> sipa: right I mean that's the point that I think would matter in my discussions. 
09:37 < sipa> ok, will open PR on website, without list of signatories for now, but can be discussed further there
09:37 < gmaxwell> Murch[m]: I really try to not do that ever. holy crap. what a gross thing to do.  I did one time say "don't you know who HE is" pointing at pieter, however. :P
09:37 < Murch[m]> sorry, that was a joke about Charles Hoskinson
09:37 < sipa> The first of his name.
09:37 < darosior> lol
09:37 < gmaxwell> oh really hah
09:37 < instagibbs> Murch[m] oh you need metamask help??
09:37 < instagibbs> dm me
09:37 < ajonas> instagibbs: To better anticipate objections (if any), did you get pushback from your write up? Obviously not the same thing, but you were asked to do that for the group.
09:38 < instagibbs> ajonas we didn't converge on a unified voice in our little group
09:38 < glozow> I think we should review wording on the PR, not do signatures, aim to get a lot of (concept) ACKs, perhaps more than normal (text is easier than code review right?), and then merge when we have rough consensus. The people who ACK'd are supporting it in a public place, which imo is enough.
09:38 < cfields> People will most definitely conflate the a signature on statement with an ACK to the policy changes btw. The former I feel qualified to do, but not the latter. I agree with the guiding principles laid out in the post, but lack the expertise to judge the specific changes.  So I'm +1 for no names.
09:38 < instagibbs> ajonas it's also possible I'm just weak willed and gave up early
09:38 < ajonas> instagibbs: that's tracks
09:38 < gmaxwell> so a problem you will face on the PR is that a lot of total randos will show up and throw mud at it unproductively.
09:38 < gmaxwell> And then there will be false implications that the project didn't broadly support it.
09:39 < gmaxwell> Sorry I don't have a solution, but I almost guarentee this will happen.
09:39 < darosior> Agree with what glozow suggests
09:39 < achow101> gmaxwell: put a comment at the top "if you don't contribute to this project, your comment will be deleted"
09:39 < sipa> gmaxwell: sgtm
09:39 < sipa> eh
09:39 < sipa> glozow: sgtm
09:39 < gmaxwell> can you limit a PR to project members? (obviously contributors are wider...)
09:40 < glozow> perhaps unpopular opinion, but maybe the website repo should have stricter contribution requirements than the bitcoin/bitcoin repo
09:40 < glozow> achow101: yeah or that
09:40 < achow101> there is a roundabout way to make conversation locking let contributors comment, but it requires giving everyone write access
09:40 < gmaxwell> glozow: historically website has had some good help from people who aren't developers, though I agree  with that view.
09:40 < gmaxwell> ugh, damn github.
09:40 < achow101> for the website, I think that's probably fine though since deploying the site has several extra steps that happen off github
09:41 < glozow> gmaxwell: yeah agree. but I think it's perfectly reasonable that this particular PR only seeks input from regular contributors
09:41 < glozow> seek*
09:41 < Murch[m]> And just like predicted, the brigading now lead to development channels becoming more permissioned :p
09:41 < achow101> we can also turn on the "have contributed to this repo before" limit, but that actually probably excludes many regular contributors
09:41 < sliv3r__> what about the statement without names + pgp signatures?
09:41 < gmaxwell> glozow: yes exactly. It's their statement not anyone elses. supportive comments (like mine!) I hope are welcome but could be channeled via recent contributors.
09:42 < achow101> sliv3r__: that's the same thing, but with more friction?
09:42 < Murch[m]> sliv3r__: That’s just extra work on the person that writes the scathing investigative breaking news Twitter article :p
09:42 < glozow> Murch[m]: I get what you're saying and generally agree, but this post isn't development at all. It's contributors agreeing on wording!
09:43 < Murch[m]> glozow: Fair enough
09:43 < Murch[m]> Also, I think it would be easier to lock it to contributors than to delete non-contributors
09:43 < fanquake> I've found the setting that should limit the interaction to people in the frequent contribs group
09:43 < Murch[m]> Maybe "easier" is the wrong word, but less abrasive
09:43 < fanquake> Don't think we need to hand out write access
09:43 < achow101> fanquake: which setting?
09:43 < gmaxwell> The delete has some bad effects which I can discuss later cause its a total tangent.
09:44 < gmaxwell> sipa: authors could also just offer to forward on any comments from contributors that have issues getting to the repo.
09:44 < achow101> fanquake: oh, limit to prior contributors does include org members, so I guess that would be fine too
09:44 < fanquake> achow101: we should be able to restrict to collaborators, where collaborators are in frequent contributors
09:44 < achow101> fanquake: collaborators == write access
09:45 < achow101> (it's stupid, and everyone gets tripped up on this)
09:45 < darosior> Create a Github team, just a third group for maintainers to manage and keep in sync /s
09:45 < fanquake> i can add that team with read access?
09:45 < fanquake> No write access needed
09:45 -!- rkrux [~rkrux@user/rkrux] has quit [Quit: Client closed]
09:45 < achow101> fanquake: I don't think they count as collaborators to github
09:46 < fanquake> 1 sec
09:46 < achow101> i think that's a repo-wide setting
09:46 < fanquake> can everyone still interact here: https://github.com/bitcoin-core/bitcoincore.org
09:47 < fanquake> I've added frequent collaborators as a team, with read access, and restricted interaction on that repo to only collaborators
09:47 < darosior> fanquake: yes https://github.com/bitcoin-core/bitcoincore.org/pull/1135#issuecomment-2901911556
09:47 < achow101> fanquake: that setting includes organization members too
09:47 < gmaxwell> I feel bad for the tangent was there anything else for the agenda? github gnoming can probably be done right after.
09:47 < sipa> gmaxwell: it was the last agenda item
09:47 < achow101> gmaxwell: yes, good point
09:47 < achow101> Any other topics to discuss?
09:48 < achow101> #endmeeting
09:48 < corebot> achow101: Meeting ended at 2025-05-22T16:48+0000
09:48 < corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-22_16_00.log.json
09:48 < corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-22_16_00.log.html
09:48 < corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-05-22_16_00.html
09:49 < jon_atack> achow101: can the meeting header line about #here be dropped
09:49 < achow101> fanquake: try again with the team removed, I think it'll still work
09:49 < achow101> jon_atack: not really
09:49 < jon_atack> unclear if we should be joining meetings with "hi" or #here
09:49 < jon_atack> ok
09:49 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
09:49 < achow101> it doesn't matter, both will be counted as participants
09:49 < fanquake> achow101: yea looks like non-org accounts are still limited, so this should work for what we want to do
09:50 < fanquake> If needed
09:50 < glozow> As a regular reminder: if you feel you should/shouldn't be on the frequent contributors list, please message a maintainer. There is no formal process or cadence / nobody is purposefully excluding people. Sometimes it's just been a while.
09:51 < achow101> jon_atack: it's https://github.com/pronovic/hcoop-meetbot if you want to submit a pr to them, or find the right configuration options for me to set to the turn it off. but afaik, i can't
09:51 < sipa> achow101: woah, i always assumed it was entirely custom
09:52 < achow101> sipa: that's way too much effort :p
09:53 < sipa> achow101: says the person who reimplemented all of apple's executable signing logic?
09:54 < achow101> lol
09:54 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:55 < Murch[m]> gmaxwell: So, your point was that deleting people’s comments would allow them to collect a "victim badge" whereas not letting them post in the first place doesn’t give people access to playing such games?
09:55 -!- Emc99 [~Emc99@212.129.83.156] has quit [Quit: Client closed]
09:55 < jon_atack> achow101: ok
09:55 < achow101> fanquake: I think we should leave turn the interaction limit on when the pr is open, i'd rather preempt the brigading rather than turning it on after the fact
09:56 -!- hensou [~hensou@2001:818:eadb:c00:b37e:fdcd:67c0:5db3] has joined #bitcoin-core-dev
09:57 < stickies-v> hebasto: i upvoted all the unresolved MSVC issues
09:57 < fanquake> Yea I don't mind. We can turn it on at that point
09:57 < bitcoin-git> [bitcoin] fanquake pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/d2c9fc84e171...0a8ab559514f
09:57 < bitcoin-git> bitcoin/master 11fed83 Cory Fields: threading: add LOCK_ARGS macro
09:57 < bitcoin-git> bitcoin/master 4c8c90b Cory Fields: validation: only create a CCheckQueueControl if it's actually going to be ...
09:57 < bitcoin-git> bitcoin/master c3b0e6c Cory Fields: validation: make CCheckQueueControl's CCheckQueue non-optional
09:57 < bitcoin-git> [bitcoin] fanquake merged pull request #32467: checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage (master...checkqueue_control_mandatory) https://github.com/bitcoin/bitcoin/pull/32467
09:59 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0a8ab559514f...2df824f4e62b
09:59 < bitcoin-git> bitcoin/master fa07953 MarcoFalke: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task
09:59 < bitcoin-git> bitcoin/master 2df824f merge-script: Merge bitcoin/bitcoin#32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTION...
09:59 < bitcoin-git> [bitcoin] fanquake merged pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
09:59 < gmaxwell> lightlike: to clarify the 'asked to leave' comment from earlier.  In watching PRs and bitcoin related traffic on social media, I've seen repeated participation from people who are overtly hostile to the project, it's activities, and contributors... including stuff that would get them immediately ejected from any professional enviroment. And while constructive criticism about proposals is 
09:59 < gmaxwell> essential, someone who just hates the project has no business being on the repository at all. That's just not want it's for, its for the project to develop the projects software.  So I was referring to that stuff, just just someone minding their business in GUI strings or what not.
10:01 < hebasto> stickies-v: thanks!
10:05 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
10:07 < gmaxwell> I would hope some earnest niche contributor could agree that the resulting document is the position of _the project_ if it's not their own.
10:09 -!- dzxzg [~dzxzg@user/dzxzg] has quit []
10:12 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has joined #bitcoin-core-dev
10:18 < lightlike> gmaxwell: yes, i don't disagree with that. Though it should be possible for contributors to have fundamentally opposing views wrt one area such as policy (and be vocal about that, without fear of being asked to leave) - as long as they accept it if they don't get their way in the end and don't have that same problem in other areas.
10:20 < gmaxwell> ::nods:: that's why I thought it was useful to clarify what I was referring to.
10:28 < gmaxwell> The underlying principle I, personally, would keep in mind is that the repository exists so that its significant contributors can collaborate and produce the best bitcoin software they can. It does not exist to be fair, inclusive, friendly, to anyone -- except to the (very significant!) extent that those things help to produce good bitcoin software.
10:29 < gmaxwell> and this is my view because simply if it doesn't work that way it will be replaced with something that does.  Exactly like this IRC channel, which functionally replaced #bitcoin-dev, because the other wasn't maintained in a way that preserved the participation of the major participants.
10:40 < gmaxwell> (and I'd recommend the fictional novel "Walkaway" by Cory Doctorow, in spite of my general reservations about his writing, for its musing on the social structures surrounding truly voluntary efforts and collaborations)
10:42 -!- hensou [~hensou@2001:818:eadb:c00:b37e:fdcd:67c0:5db3] has quit [Ping timeout: 268 seconds]
10:51 < bitcoin-git> [gui-qml] hebasto pushed 4 commits to main: https://github.com/bitcoin-core/gui-qml/compare/849d3ae81714...b411e5894145
10:51 < bitcoin-git> gui-qml/main 33c0467 goqusan: qml: Add QRImageProvider
10:51 < bitcoin-git> gui-qml/main 53788b6 goqusan: qml: Add QRImage control
10:51 < bitcoin-git> gui-qml/main f445e65 goqusan: qml: Use QRImage in RequestPayment
10:51 < bitcoin-git> [gui-qml] hebasto merged pull request #454: Add QRImageProvider (main...qrimageprovider) https://github.com/bitcoin-core/gui-qml/pull/454
11:02 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has quit [Quit: Christoph_]
11:06 < gmaxwell> Murch[m]: right. like encountering a closed door might make you sad, but being heaved out the door makes some people feel humilitated and turns them into long term enemies even when it should have been totally expected.
11:07 -!- hensou [~hensou@2001:818:eadb:c00:8a2d:182:4034:89d7] has joined #bitcoin-core-dev
11:09 < lightlike> gmaxwell: that is certainly what open source projects in general should default to - but even if in theory everyone can run their own software, in practice bitcoin core is still the de-facto reference implementation, which makes it a bit unique. As long as most other node impls are not serious alternatives I'd argue that implies at least some additional responsibilities other projects don't have - only up to some point though (e.g. we 
11:09 < lightlike> certainly should not merge things we think are harmful even if everyone else wants them), and it's not clear to me where that point should be.
11:11 < gmaxwell> I think I feel somewhat the opposite, the whole point of bitcoin is defeated if other people control your usage.  So trying to act like a pseudogovernment isn't in Bitcoin's interest, as some people will mistake the pomp and circumstance of power with actual power that should not and must not exist.
11:12 < gmaxwell> I mean obviously there is no point in doing it if people don't actually want to run the result (and development in the project wouldn't continue if people stopped using it-- if people didn't want to work on an impactful system they wouldn't be here, it's so much harder than something inconsequential)
11:13 < bitcoin-git> [bitcoin] theuni opened pull request #32592: threading: remove ancient CRITICAL_SECTION macros (master...remove-critsect) https://github.com/bitcoin/bitcoin/pull/32592
11:13 -!- hensou [~hensou@2001:818:eadb:c00:8a2d:182:4034:89d7] has quit [Ping timeout: 276 seconds]
11:14 < gmaxwell> So I agree to you to at least that extent.  But I've absolutely seen it go wrong, including e.g. one coinbase filing in litigation explaining that bitcoin was decenteralized because anyone can make a pull request. ... and I don't really blame coinbase, it's easy to see how the very elaborate pesudogovernmental procedures in the project got mistaken for the origin of Bitcoin's properties.
11:16 < gmaxwell> So at least for that specific purpose, it would have been better if contributing.md just said "Stuff goes in here if Achow likes it, you can use this repo if you like it, otherwise take a hike"  :P ... cause if coinbases lawyers saw that they'd go okay obviously *this* isn't where bitcoin's properties arise. And instead would have made the case that no one controls the software users run and in 
11:16 < gmaxwell> fact significant effort has gone into preserving/amplifying that power.
11:21 < gmaxwell> lightlike: re serious alternatives: the code the user is running *right now* is a serious alternative to a future release.  A future release with whatever adverse change backed out is a serious alternative -- even a moderately technical user can now reverse apply a diff and build bitcoin core with the help of an LLM. :) And of course people will make alternatives.  And especially if the issue 
11:21 < gmaxwell> of concern is substantive the alternatives will be competent.
11:22 < gmaxwell> The fact that the current alternatives aren't so impressive is just a product that they are driven by their own motivations that don't have much/anything to do with specific bad choices in bitcoin core.
11:25 < gmaxwell> one of the few positive oppturnities in this recent turmoil I think is an chance for people to learn to apply a diff and run a patched copy. That's a skill that any serious bitcoin power user ought to have. and while (IMO) completely unjustified for the current issue, it's exactly what people might need to do in the face of an adverse change.
11:26 < darosior> Lol at the pull request comment. Really hits home, interacted with so many confused people fetishizing them.
11:27 < gmaxwell> 'cause at the day it's not the developers being great people that protects bitcoin (thoug they are!) -- great people can still have guns held to their heads (figuritively or litterally!) or can go crazy.
11:27 < gmaxwell> darosior: yeah they actually copied in most of contributing.md ...
11:27 -!- reasonableD00F [~reasonabl@31.40.215.241] has joined #bitcoin-core-dev
11:29 -!- reasonableD00F [~reasonabl@31.40.215.241] has quit [Client Quit]
11:29 < gmaxwell> I dunno how to manage it though because all this openness and inclusiveness are fantastic tools for making good software, and also important to people's good feelings towards the project. But they just simply can't be where Bitcoin's security comes from.
11:31 -!- reasonableD00F [~reasonabl@31.40.215.241] has joined #bitcoin-core-dev
11:33 -!- reasonableD00F [~reasonabl@31.40.215.241] has quit [Client Quit]
11:33 -!- hensou [~hensou@2001:818:eadb:c00:2121:ac5a:2858:e83d] has joined #bitcoin-core-dev
11:36 < gmaxwell> in BCH which has a far smaller and less resourced community, the main development group decided to add code to direct a portion of mining rewards to a development fund-- a decision they were commited to.  And they were entirely replaced, by a new project that didn't exist before then.  (There were other implementations, but they were mostly 1/2 person projects like the alternative 
11:36 < gmaxwell> implementations in Bitcoin today, the thing that replaced the BCH 'reference implementation' was created in response to the adverse change)  
11:36 < gmaxwell> so I'm entirely not worried about that. I worry more about stuff like the project becoming a zombie, like-- failing to implode when it ought to. :)
11:37 < cfields> jeremyrubin: do you remember why the cuckoocache requires an external lock rather than just using an internal mutex? I'm guessing because not all of the functions require locking?
11:40 < cfields> nm, found a github comment.
11:46 -!- hensou [~hensou@2001:818:eadb:c00:2121:ac5a:2858:e83d] has quit [Ping timeout: 248 seconds]
11:57 -!- Guest10 [~Guest10@196.40.180.242] has joined #bitcoin-core-dev
11:58 -!- Guest10 [~Guest10@196.40.180.242] has quit [Client Quit]
12:01 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has quit [Remote host closed the connection]
12:18 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has joined #bitcoin-core-dev
12:18 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:24 < sipa> darosior: which pull request comment?
12:25 < gmaxwell> my comment about coinbase attributing bitcoin's decenteralization to anyone being able to open a pull request.
12:26 < sipa> ah yes ok, i thought darosior was commenting about a specific PR being mentioned that i missed
12:26 < gmaxwell> I thought that too for a moment.
12:34 -!- cold [~cold@user/cold] has quit [Ping timeout: 260 seconds]
12:34 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 276 seconds]
12:48 -!- cold [~cold@user/cold] has joined #bitcoin-core-dev
12:48 -!- midnight [~midnight@user/midnight] has joined #bitcoin-core-dev
12:51 -!- hensou [~hensou@2001:818:eadb:c00:d599:b41b:c9c2:a4d8] has joined #bitcoin-core-dev
12:52 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has joined #bitcoin-core-dev
12:58 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 244 seconds]
12:59 -!- cold [~cold@user/cold] has quit [Ping timeout: 272 seconds]
13:00 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
13:01 -!- midnight [~midnight@user/midnight] has joined #bitcoin-core-dev
13:01 -!- cold [~cold@user/cold] has joined #bitcoin-core-dev
13:06 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
13:07 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 264 seconds]
13:11 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:24 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
13:29 -!- kevkevin [~kevkevin@2601:243:197e:8f10:f6:4da:44eb:c825] has quit [Remote host closed the connection]
13:35 < bitcoin-git> [bitcoin] achow101 opened pull request #32593: wallet, rpc: Move (Un)LockCoin WalletBatch creation out of RPC (master...improve-lockcoin-interface) https://github.com/bitcoin/bitcoin/pull/32593
13:37 -!- hensou [~hensou@2001:818:eadb:c00:d599:b41b:c9c2:a4d8] has quit [Ping timeout: 272 seconds]
13:40 -!- jespada [~jespada@r167-61-220-219.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
13:43 -!- jespada [~jespada@r167-61-220-219.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
13:52 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
13:52 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has quit [Quit: Christoph_]
13:52 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has joined #bitcoin-core-dev
13:57 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:3ccd:106:9de6:2711] has quit [Ping timeout: 248 seconds]
14:18 < bitcoin-git> [bitcoin] achow101 opened pull request #32594: Getaddrinfo normalized parent (master...getaddrinfo-normalized-parent) https://github.com/bitcoin/bitcoin/pull/32594
14:25 < bitcoin-git> [bitcoin] willcl-ark opened pull request #32595: build: add a depends dependency provider (master...cmake-dependency-provider) https://github.com/bitcoin/bitcoin/pull/32595
14:54 < bitcoin-git> [gui-qml] davidgumberg opened pull request #458: Add missing cstdint declarations (main...5-22-2025-cstdint-qml) https://github.com/bitcoin-core/gui-qml/pull/458
15:04 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
15:30 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Quit: Konversation terminated!]
15:30 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
15:30 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
15:31 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
15:31 -!- w473rm3l0n [~w473rm3l0@user/w473rm3l0n] has joined #bitcoin-core-dev
15:36 -!- Guest47 [~Guest47@2405:4803:fd23:a050:e908:e94b:fe23:9aeb] has joined #bitcoin-core-dev
15:40 -!- Guest47 [~Guest47@2405:4803:fd23:a050:e908:e94b:fe23:9aeb] has quit [Client Quit]
15:46 < bitcoin-git> [bitcoin] theStack opened pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
15:46 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
15:47 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
15:47 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
15:47 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
15:48 < Earnestly> (It's interesting to me that during this topic discussion there was total agreement, there were no dissenting voices despite so much contention (I've been reading more about it).)
15:51 < w473rm3l0n> sipa: re: relay_policy.md, I agree with everything written in the gist. Although it doesn't contain anything new that users haven't already read several times. The only thing that makes it different is that it would be on the core website and likely posted by core's X account.
15:52 < w473rm3l0n> Another factor that could set it apart is if it's signed by developers who are respected in the community and avoid controversies, drama etc.
15:52 < w473rm3l0n> Restricting the pull request will only add fuel to the fire. Instead, changes can be suggested in the gist. A pull request can then be opened and merged with some ACKs from regular contributors.
15:53 < w473rm3l0n> I don't think any such post will make a difference, because some people are unhappy with the way bitcoin core development works and their concerns or perception go beyond just OP_RETURN.
15:54 < Earnestly> That is my perception too, OP_RETURN appears to be the last few straws
15:55 < Earnestly> The gist covers 3 main points, which many people have already seen, discussed, refuted/challenged, etc. The gist doesn't really add anything new
15:56 < Earnestly> (I.e. 1) fee estimation, 2) block prop, 3) avoiding miners using dark pools)
15:57 -!- w473rm3l0n79 [~w473rm3l0@user/w473rm3l0n] has joined #bitcoin-core-dev
15:57 -!- w473rm3l0n79 [~w473rm3l0@user/w473rm3l0n] has quit [Client Quit]
15:59 < Earnestly> From my brief reading of the situation many of the anti-core voices largely think exactly what the gist contains; they don't think core is malicous (some do, ignore) but misguided. Ultimately what I personally think they want is core to /signal/ an anti-spam stance, which core likely does not want to do
16:00 < Earnestly> The logic being that a signal will have a social effect on vc funding of spam activity, preventing them from becoming self-sustaining
16:05 < Earnestly> (Also I'd suggest dropping the language of "brigading", and the pathologysing of users who have grievances, here and elsewhere too. People do see it.)
16:05 < Earnestly> gising*
16:08 -!- w473rm3l0n [~w473rm3l0@user/w473rm3l0n] has quit [Quit: Client closed]
16:40 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Quit: Konversation terminated!]
16:40 -!- dzxzg2 [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
16:47 -!- dzxzg2 [~dzxzg@user/dzxzg] has quit [Ping timeout: 268 seconds]
16:50 -!- dzxzg2 [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
17:04 -!- jespada [~jespada@r167-61-220-219.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 252 seconds]
17:07 -!- emcy__ [~emcy@148.252.132.78] has joined #bitcoin-core-dev
17:09 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
17:10 -!- mcey_ [~emcy@185.69.144.38] has quit [Ping timeout: 276 seconds]
17:18 -!- antanst [~antanst@user/antanst] has quit [Read error: Connection reset by peer]
17:18 -!- antanst9 [~antanst@user/antanst] has joined #bitcoin-core-dev
17:39 < bitcoin-git> [bitcoin] achow101 opened pull request #32597: wallet: Always set descriptor cache upgraded flag for new wallets (master...desc-cache-is-upgraded) https://github.com/bitcoin/bitcoin/pull/32597
17:42 < bitcoin-git> [bitcoin] achow101 opened pull request #32598: walletdb: Log additional exception error messages for corrupted wallets (master...loadwallet-log-runtime_error) https://github.com/bitcoin/bitcoin/pull/32598
18:16 < jon_atack> Would someone with label privileges add the Review club label to the pull for next week's meeting, please?
18:16 < jon_atack> https://github.com/bitcoin/bitcoin/pull/32051
20:14 -!- charlie_capt [~charlie_c@119.75.194.99] has joined #bitcoin-core-dev
20:24 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
20:27 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Quit: Client closed]
20:29 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds]
20:32 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
20:32 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
20:39 -!- maflcko [~none@107.172.8.183] has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
20:44 -!- maflcko [~none@107.172.8.183] has joined #bitcoin-core-dev
20:47 -!- maflcko [~none@107.172.8.183] has quit [Client Quit]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:07 -!- maflcko [~none@107.172.8.183] has joined #bitcoin-core-dev
21:10 -!- Cory80 [~Cory80@user/pasha] has quit [Quit: Client closed]
21:11 -!- Cory80 [~Cory80@user/pasha] has joined #bitcoin-core-dev
21:17 -!- robszarka [~szarka@2603:3003:4eac:100:112e:106d:fa3f:4caa] has joined #bitcoin-core-dev
21:20 -!- szarka [~szarka@2603:3003:4eac:100:28aa:caf5:198d:3518] has quit [Ping timeout: 260 seconds]
21:36 < bitcoin-git> [gui-qml] johnny9 opened pull request #459: Disable forms when loading (main...disable-forms) https://github.com/bitcoin-core/gui-qml/pull/459
21:47 -!- charlie_capt [~charlie_c@119.75.194.99] has joined #bitcoin-core-dev
22:30 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
22:57 -!- charlie_capt [~charlie_c@119.75.194.99] has quit [Quit: Client closed]
23:04 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
23:09 < bitcoin-git> [bitcoin] maflcko closed pull request #32535: rev_32343_wip_nomerge_ci (master...2505-rev_32343_wip_nomerge_ci) https://github.com/bitcoin/bitcoin/pull/32535
23:11 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
23:24 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
23:25 -!- Christoph__ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
23:28 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has quit [Ping timeout: 252 seconds]
23:47 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
--- Log closed Fri May 23 00:00:51 2025