achow101 changed the topic of #bitcoin-core-dev to: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Weekly Meeting Thursday @ 16:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
bitdex has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
S3RK has quit [Ping timeout: 260 seconds]
S3RK has joined #bitcoin-core-dev
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
entropyx has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
theariard has joined #bitcoin-core-dev
theariard has quit [Changing host]
theariard has joined #bitcoin-core-dev
<theariard> won’t be present to this thurs. meeting, as it’s may 1st and schedule to be afk
<theariard> but i’ll try to attend next one may 8th to talk about the mod guidelines...
zeropoint has quit [Quit: leaving]
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] monlovesmango opened pull request #32389: doc: Fix test_bitcoin path (master...doc-fix-test_bitcoin-path) https://github.com/bitcoin/bitcoin/pull/32389
robobub has quit [Quit: Connection closed for inactivity]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
mcey_ has quit [Ping timeout: 244 seconds]
Guest47 has joined #bitcoin-core-dev
Guest47 has quit [Client Quit]
Talkless has quit [Quit: Konversation terminated!]
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
instagibbs has quit [Ping timeout: 252 seconds]
jamesob15665 has quit [Ping timeout: 252 seconds]
jamesob443688173 has quit [Ping timeout: 252 seconds]
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
jamesob15665 has joined #bitcoin-core-dev
jamesob443688173 has joined #bitcoin-core-dev
instagibbs has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
Christoph_ has quit [Client Quit]
pseudoramdom has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
tinova41 has joined #bitcoin-core-dev
tinova4 has quit [Ping timeout: 252 seconds]
darosior has quit [Ping timeout: 252 seconds]
kerm|t has quit [Ping timeout: 252 seconds]
tinova41 is now known as tinova4
darosior has joined #bitcoin-core-dev
kerm|t has joined #bitcoin-core-dev
cmirror has quit [Ping timeout: 252 seconds]
pseudoramdom has quit [Remote host closed the connection]
pseudoramdom has joined #bitcoin-core-dev
Guest70 has joined #bitcoin-core-dev
Guest70 has quit [Client Quit]
Christoph_ has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 276 seconds]
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 268 seconds]
pseudoramdom has joined #bitcoin-core-dev
robszarka has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 272 seconds]
szarka has quit [Ping timeout: 276 seconds]
Guyver2 has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
greypw1495085720 has joined #bitcoin-core-dev
greypw1495085720 has quit [Client Quit]
greypw1495085720 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
pseudoramdom has quit [Ping timeout: 276 seconds]
<bitcoin-git> [bitcoin] AndreaLanfranchi opened pull request #32392: Update .gitignore (master...gitignore) https://github.com/bitcoin/bitcoin/pull/32392
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Remote host closed the connection]
pseudoramdom has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake closed pull request #32392: Update .gitignore (master...gitignore) https://github.com/bitcoin/bitcoin/pull/32392
Christoph_ has quit [Quit: Christoph_]
pseudoramdom has quit [Ping timeout: 276 seconds]
pseudoramdom has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/68ac9f116c02...fc6346dbc8dc
<bitcoin-git> bitcoin/master 6cbc28b monlovesmango: doc: Fix test_bitcoin path
<bitcoin-git> bitcoin/master fc6346d merge-script: Merge bitcoin/bitcoin#32389: doc: Fix test_bitcoin path
<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
pseudoramdom has quit [Ping timeout: 248 seconds]
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 260 seconds]
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 245 seconds]
<TheCharlatan> I'm looking for some block index size comparisons. Could some of you post the size of their blocks/index?
<fanquake> 294mb
<sipa> $ du -sh ~/.bitcoin/blocks/index/
<sipa> 116M /home/site/.bitcoin/blocks/index/
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 260 seconds]
jespada has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 248 seconds]
PaperSword has quit [Quit: PaperSword]
kevkevin has joined #bitcoin-core-dev
<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
pseudoramdom has joined #bitcoin-core-dev
<vasild> TheCharlatan: 208M on one machine and 122M on another (that is `du -sh`, depends on the filesystem block size)
kevkevin has quit [Remote host closed the connection]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<vasild> not much, it has just a few files
pseudoramdom has quit [Ping timeout: 245 seconds]
jespada has joined #bitcoin-core-dev
<vasild> and 113M on a pruned node
kevkevin has joined #bitcoin-core-dev
Cory55 has quit [Quit: Client closed]
Cory55 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
<TheCharlatan> Thanks, interesting to see this magnitude of variance.
donal has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
pseudoramdom has quit [Ping timeout: 260 seconds]
donal has quit [Quit: Client closed]
bitdex has quit [Quit: = ""]
donal has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
<laanwj> 123M here. some difference based on the file system block size is expected, but i don't think it should come out double?
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
<laanwj> as i understand, pruning shouldn't make a difference, block files are deleted but the blocks remain in the block index
brunoerg has joined #bitcoin-core-dev
<instagibbs> don't remember the command but topic: we should decide a direction on OP_RETURN stuff
<laanwj> so the larger ones are interesting, maybe it's for long-running nodes which have a lot of stale blocks from reorgs
<laanwj> the command is #topic <topic>
<instagibbs> #topic let's decide a direction on OP_RETURN policy
reverseengineer has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
<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"
pseudoramdom has quit [Ping timeout: 252 seconds]
<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. ?
<reverseengineer> I downloaded the blocks without pruning
jespada_ has joined #bitcoin-core-dev
donal has quit [Quit: Client closed]
jespada has quit [Ping timeout: 245 seconds]
<_aj_> fanquake: du -bh .bitcoin/blocks/index/ ?
<reverseengineer> 193MB
TorTanicc has joined #bitcoin-core-dev
<_aj_> instagibbs, laanwj: aren't you thinking of #proposedmeetingtopic ?
<instagibbs> the world may never know
TorTanicc has quit [Client Quit]
banananananananz has joined #bitcoin-core-dev
banananananananz has quit [Client Quit]
<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.
<laanwj> _aj_: oh, oops, yes, #topic is a command but it sets the current topic it doesn't propose one
<laanwj> anyhow, it's probably clear by now
<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
<reverseengineer> thank you laanwj
reverseengineer has quit [Read error: Connection reset by peer]
bugs_ has joined #bitcoin-core-dev
pseudoramdom has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
<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
jon_atack has quit [Ping timeout: 252 seconds]
eugenesiegel has quit [Ping timeout: 240 seconds]
<fanquake> _aj_: yea
<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
aleggg has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
<_aj_> fanquake: even -bh says ~300MB? weird
<fanquake> _aj_: this is bsd du, on a macos box, so there's no -b
<_aj_> fanquake: haha, sucks to be you
<fanquake> I can check some others later
<_aj_> fanquake: find .bitcoin/blocks/index -printf "%s\n" | (x=0; while read a; do x=$(($x+$a)); done; echo $((x/1024/1024)) )
<fanquake> _aj_: did you think BSD find would be so useful to implement -printf
<_aj_> can't you use homebrew or something to upgrade to the 90s?
<fanquake> yea there's probably a g prefixed tool floating around somewhere
<laanwj> fanquake: here's a python version: https://gist.github.com/laanwj/0ebfea4a32cfe3bbeff8b05fb2a5d788
aleggg has joined #bitcoin-core-dev
sebastianvstaa has joined #bitcoin-core-dev
zeropoint has joined #bitcoin-core-dev
Emc99 has joined #bitcoin-core-dev
rkrux has joined #bitcoin-core-dev
<achow101> #startmeeting
<corebot> achow101: Meeting started at 2025-05-01T16:00+0000
<corebot> achow101: Current chairs: achow101
<corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
<corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
<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
<rkrux> hi
<TheCharlatan> hi
<stickies-v> hi
<johnny9dev> hi
<jonatack> hi
<instagibbs> hi
<hodlinator> hi
<cfields> hi
<pinheadmz> Hi
<kevkevin_> hi
<achow101> There are 2 pre-proposed meeting topics this week. Any last minute ones to add?
<sr_gi[m]> hi
<kanzure> hi
<willcl-ark> hi
bugs_ has quit [Quit: Leaving]
<lightlike> Hi
<Murch[m]> Hi
<marcofleon> hi
<achow101> #topic Erlay WG Update (sr_gi, gleb)
<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.
<laanwj> hi
<sr_gi[m]> That's it on my end
<achow101> #topic Kernel WG Update (TheCharlatan)
<TheCharlatan> Still looking for review on #40595 and #31382
<corebot> TheCharlatan: Error: That URL raised <HTTP Error 404: Not Found>
<corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
<TheCharlatan> Woops #30595 :P
<corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
<TheCharlatan> Over the past week I have been working on replacing the BlockTreeDB's leveldb with a flat file store.
<TheCharlatan> This is possible, because we don't ever delete from that data structure.
<TheCharlatan> I am working on PRing this soon to gather comments and completed the migration code today.
<TheCharlatan> The change was mostly motivated by kernel applications having to shutdown a node first before being able to read from its block store.
<TheCharlatan> This is not possible currently because leveldb does not allow different processes to read/write while the db is open on another.
<TheCharlatan> It does also bring some storage improvements and allows nodes to startup a bit faster.
<brunoerg> hi
<sipa> hi
<TheCharlatan> that's all
<cfields> nice :)
<willcl-ark> cool!
<darosior> hi
<achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
<theStack> hi
<Sjors[m]> hi
<sipa> Not much to report.
<sipa> Hopefully the mining/eviction PR goes in soon.
<vasild> hi
<glozow> hi
<sipa> Mostly doing more research on better linearization algorithms.
pseudoramdom has quit [Remote host closed the connection]
<achow101> #topic Stratum v2 WG Update (sjors)
<sipa> Nothing from sdaftuar.
pseudoramdom has joined #bitcoin-core-dev
<achow101> Sjors[m]: ?
<Sjors[m]> yes
<Sjors[m]> Not much to report
<Sjors[m]> Please keep reviewing multiprocess stuff
<achow101> #topic MuSig2 WG Update (achow101, rkrux)
<achow101> #31243 was merged, the next PR to review is #31244
<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
<corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
<achow101> #topic Legacy Wallet Removal WG Update (achow101, furszy)
<achow101> #31250 was merged so legacy wallets can finally no longer be created or loaded
<corebot> https://github.com/bitcoin/bitcoin/issues/31250 | wallet: Disable creating and loading legacy wallets by achow101 · Pull Request #31250 · bitcoin/bitcoin · GitHub
<achow101> The next and final major PR in this project is #28710 to delete (almost) everything
<corebot> https://github.com/bitcoin/bitcoin/issues/28710 | Remove the legacy wallet and BDB dependency by achow101 · Pull Request #28710 · bitcoin/bitcoin · GitHub
pseudoramdom has quit [Ping timeout: 272 seconds]
cotsuka has quit [Remote host closed the connection]
<achow101> There are still several things that can be removed after in followups, e.g. GUI watchonly wallet things
<achow101> #topic orphan resolution WG Update (glozow)
<glozow> No updates, have been busy with other things
<achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
cotsuka has joined #bitcoin-core-dev
<johnny9dev> Fixed remaining issues with bitcoin-core/gui-qml#448 and it is ready to be merged.
<corebot> https://github.com/bitcoin-core/gui-qml/issues/448 | Introduce Coin Selection page by johnny9 · Pull Request #448 · bitcoin-core/gui-qml · GitHub
<johnny9dev> That's all for now
<achow101> #topic moving the repo to bitcoin-core (achow101)
<achow101> After last week's meeting, I opened #32340 for further discussion
<corebot> https://github.com/bitcoin/bitcoin/issues/32340 | Moving this repo to bitcoin-core · Issue #32340 · bitcoin/bitcoin · GitHub
<achow101> It doesn't seem like any new discussion really happened there
<achow101> Now that it has been a week, how do people feel about moving the repo?
<vasild> did anything happen with the bip repo in the meantime, e.g. did bip people decide to move it away from bitcoin/bips?
<achow101> nope
<jonatack> vasild: no
<instagibbs> does crickets mean ack/nack or pure indifference
<darosior> achow101: i wanted to chime in but didn't get to it. Can we punt for another week?
<achow101> darosior: you can chime in now :)
<jonatack> ACK for me, as i commented in that issue
eugenesiegel has joined #bitcoin-core-dev
<stickies-v> not necessarily opposed but doesn't feel important pushing this through atm, let's just move bips and move on for now?
<willcl-ark> I think a little more time might be prudent here
<darosior> The perspective of "this is unnecessarily risky" is growing on me
<fanquake> optics-wise, I don't think it's a good time to move anything around
<achow101> one thing I want to point out is that the recent temp bans being issued do affect the bips repo too
<glozow> I would like more time
<TheCharlatan> yeah, great timing ^^
<achow101> okay, punt for another week
<stickies-v> i don't think next week is going to be significantly different
<furszy> +1 on moving the bips repo only - if that's needed due to the recent temp bans
<TheCharlatan> what will be the name of the repo in the bitcoin-core org?
<stickies-v> if the bips ban issue is fixed, there's no real urgency here?
<achow101> TheCharlatan: we can bikeshed that.. I like bitcoin-core/bitcoin-core
<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.
<achow101> moving the bips repo is up to the bip editors decide
<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.
<stickies-v> Murch[m]: but the bip editor's can't get ban permissions in the bitcoin org?
<jonatack> achow101: agree with your naming suggestion
<cfields> s/will/would/
<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
<Murch[m]> stickies-v: I have mentioned that, yes
<cfields> achow101: ok, thanks. I'd suggest updating the issue to make that explicit.
<laanwj> bitcoin-core/bitcoin-core sgtm
<Murch[m]> stickies-v: We also have had less brigading in the past
<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.
<glozow> I thought it was quite clear we wouldn't transfer ownership of the org
<laanwj> yes
<jonatack> I agree the project owners in bitcoin/ would not need to be changed.
<achow101> TheCharlatan: the url will still redirect
<cfields> 👍
<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
<glozow> TheCharlatan: +1
<jonatack> Banning hasn't been needed over the past year, until recently
<TheCharlatan> yeah, but you end up with either bitcoin or bitcoin-core on your machine.
<jonatack> in a single event
<glozow> that's not true, banning happens all the time
<jonatack> in the BIPs
<Murch[m]> glozow: Yeah, I think the ownership being retained by Bitcoin Core maintainers is understood
<darosior> Yeah it was a single event, and wasn't really effective anyways
<achow101> jonatack: I've definitely banned several spammers from the bips repo over the past year
<Murch[m]> Sure, but Spam is a clear-cut issue
<darosior> For low value spam ban can be effective, but in this case they can just be banned from the whole org
<jonatack> right
<achow101> yes, just saying that there have been bans issued for obvious spam in the bips repo, without the bips editors asking
<Murch[m]> It is my impression that the BIP Editors would be fine with remaining in the current org/repo at this time.
<jonatack> achow101: yes, and it's helpful. only referring to the fortunately very rare non-trivial bans.
<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…
<jonatack> I think the BIPs case is separate from the bitcoin core one.
<achow101> ok, so i'll add this as a topic again next week, and if anyone has thoughts, please comment in the issue
<achow101> #topic let's decide a direction on OP_RETURN policy (instagibbs)
<instagibbs> hi
<instagibbs> The recent OP_RETURN policy discussion has been heated and has many viewpoints.
<instagibbs> I'm not going to recapitulate all background to the topic, that's DYOR stuff.
<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.
<instagibbs> That said I see roughly four options of varying credulity ahead of us:
<instagibbs> 0) Decide as a project that we will not modify this relay policy, close PRs indefinitely
<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)
<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.
<instagibbs> 3) Remove limits entirely (~Peter Todd's PR)
<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.
<instagibbs> That's it. Thanks for listening to my ted talk
<Sjors[m]> I think anything short of (3) will just keep bringing back the drama.
pseudoramdom has joined #bitcoin-core-dev
<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.
<glozow> I don't think (1) makes any sense. (0) is giving in to drama
<Sjors[m]> (though avoiding drama isn't necessarily a good criterion)
<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
<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.
<achow101> configurability here is basically just a placebo
<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
<Sjors[m]> vasild: except the documentation would have to list the downsides of not using the default, such as interfering with compact block relay
<instagibbs> from scratch I'd argue heavily against an argument
<darosior> I don't think keeping the option makes any sense once we switch the default to be no restriction.
<glozow> configurability at the cost of compact block reconstruction is irresponsible on our part imo
<eugenesiegel> I don't have much to add, but I agree with glozow
<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
<Sjors[m]> Also - as someone argued recent - it's arguably dishonest to ship an option knowing it doesn't work, i.e. a placebo.
<sipa> my belief is: you should only provide configuration knobs when you can give advice on when someone should use it
<achow101> I prefer 3 or 0, don't want to revisit this ever again
<instagibbs> ^ fair
<darosior> sipa: +1. And i don't think it holds in this case.
<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.
<achow101> TheCharlatan: a loud minority will, but they probably already have
<Sjors[m]> TheCharlatan: I doubt it
<sipa> or they don't run a node at all
<jonatack> perhaps consider spending time exlaining the issues involved to the outer community, if perception of bitcoin core is a criteria
<glozow> I wrote a comment about splitting out the option-removal part of Peter's PR. I think it's been buried though
<Sjors[m]> We don't collect network metrics, but I suppose you could find out with some well crafted transaction broadcasts.
pseudoramdom has quit [Ping timeout: 276 seconds]
<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.
<instagibbs> jonatack we should communicate whatever the result is for sure
<jonatack> beforehand, in a way that doesn't disenfranchise people
<darosior> jonatack: spent some time this week doing just that, see https://antoinep.com/posts/relay_policy_drama
<glozow> can you explain on what "disenfranchise" means?
<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
<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.
<glozow> explain/expand
<jonatack> darosior: i read that, and it was very good until the last 3 sections imo
<jonatack> then it reverted to a tone that imo doesn't reach across the aisle effectively
<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
<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
<Sjors[m]> As a proxy for churn away from Core
<jonatack> Murch[m]: yes, i've been swamped with private questions by users and the community as well
<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.
<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.
<sipa> ^
eugenesiegel has quit [Quit: Client closed]
eugenesiegel has joined #bitcoin-core-dev
<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
<Murch[m]> glozow: 💯
<darosior> glozow president
<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
<instagibbs> We can workshop the reasoning
<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
<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.
pseudoramdom has joined #bitcoin-core-dev
<BlueMatt[m]> glozow: Not only right, but *important*. Sitting around and watching people fill the utxo set with garbage isn’t really acceptable.
<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.
<instagibbs> You don't have to love Citrea's design, but actively reducing harm should be the default where possible.
<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.
<jonatack> darosior: i mean reaching effectively across the aisle rathen than preaching to the choir, in a way that connects
<achow101> glozow: the expiry is when someone unlocks it (there is no expiry on locking issues/prs)
<glozow> ok. when should we unlock it then?
<pinheadmz> There needs to be more effective educational outreach
<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)?
<pinheadmz> I think before the PR is reopened
<pinheadmz> Or, counter propaganda ie why utxo bloat is worse
<Sjors[m]> glozow: I do think it's better to merge it with some open nits, and improve those later.
<achow101> glozow: the request was for a day, so basically after this meeting. unless it should be locked for longer
<instagibbs> pinheadmz I think drafting the "we're doing this and here's why" before unlocking is a good idea
<Sjors[m]> Not a huge rush either, but it touches a lot of tests, so might end up needing a rebase.
<TheCharlatan> +1 instagibbs
<Murch[m]> instagibbs: How is this different from the posts in the mailing list and the PR explaining all that exactly?
<darosior> instagibbs: +1
<instagibbs> If you have something to sign off on, I'll sign off on it
pseudoramdom has quit [Remote host closed the connection]
<pinheadmz> Murch those media are not properly formatted for all the users