<maflcko>
jamesob: I guess it is a question of how much the "local" docker image should mirror the CI task behavior. Currently compilation is cached locally, but that can be changed to just compile every time, because it is fast.
brunoerg has quit [Ping timeout: 256 seconds]
<maflcko>
Also, you should be able to move RUN install.sh up to right after COPY install.sh, to get the same speedup
GregTonoski has quit [Quit: Client closed]
utzig has joined #bitcoin-core-dev
JozefH has quit [Ping timeout: 250 seconds]
<maflcko>
Ok, that'd also require splitting up install.sh into two steps
Retropex has joined #bitcoin-core-dev
utzig has quit [Ping timeout: 276 seconds]
ns-xvrn has joined #bitcoin-core-dev
wk057 has joined #bitcoin-core-dev
<reardencode>
if there's any discussion of lnhance at today's meeting, I'm available.
<glozow>
I'm also writing a doc (bip?) and trying to index all the discussion comments / questions / answers.
GregTonoski has joined #bitcoin-core-dev
wk057 has quit [Changing host]
wk057 has joined #bitcoin-core-dev
<instagibbs>
I think it'd be helpful for #28984 if I split off the cluster mempool-y diagram checking parts, if no one objects I'll open that part only?
<Murch[m]>
achow101: Could you please add CoinGrinder?
<Murch[m]>
The code is pretty mature now and I’d love to get it merged before 27, in case the fees shoot up again
<achow101>
Murch[m]: added
<Murch[m]>
Thanks!
<achow101>
#topic spam threats and protection in Bitcoin Core (GregTonoski)
<GregTonoski>
Is there any plan to harden anti-spam measures in Bitcoin Core in the next version, perhaps?
<reardencode>
I'd suggest removing all limits on OP_RETURN size/count to reduce impacts on the UTXO set and mitigate long term consequences of the current scamtoken craze.
<luke-jr>
that's the wrong direction
<achow101>
probably not. as has been stated many times, many contributors do not think that changing policy rules will have an effect
<wk057>
It doesn't seem to make sense to increase limits for OP_RETURN beyond the original scope of why OP_RETURN was made standard in the first place.
<luke-jr>
achow101: which is nonsense
<achow101>
it's clearly a controversial topic, I don't think rehashing the same argument here is going to be useful
<Murch[m]>
OP_RETURN was introduced to give a valve for people using more detrimental ways of putting data in the blockchain such as bare multisig
<achow101>
unless there is something new to say, I would suggest that we move on from this topic
<luke-jr>
achow101: intentionally leaving a vulnerability being actively exploited in, is not acceptable
<wk057>
achow101: there have been serveral new suggestions in #29187 that merit consideration
<GregTonoski>
2023 was a year of spam in Bitcoin. Isn't it important topic to discuss?
pB6102 has joined #bitcoin-core-dev
<dergoegge>
not everyone considers it a vulnerability
<instagibbs>
ok we're aware that a PR exists, that's all that's required here
<achow101>
wk057: they can be discussed if/when such PRs are opened
<luke-jr>
dergoegge: objectively it is
<Earnestly>
(It's a tad disingenuous to shut down discussion merely because it's controversial; if there is genuine misunderstanding those need to be surfaced. Lots of people are watching and want resolution on this.)
<josie>
what is the goal of bringing this topic? calling other peoples opinions on the matter nonsense and continuing to claim there is a vulnerability (when others dont share that view) is not a discussion
<_aj_>
instagibbs: the above was an issue, the prior PR is closed, there hasn't been a new PR filed yet, aiui
<luke-jr>
josie: if you disagree, you can set datacarriersize=4000000; it's not an excuse to deny others a fix
<Murch[m]>
I don’t think a policy change by default is going to get merged
<instagibbs>
_aj_ tracking issue even better
pB6102 has quit [Client Quit]
<Murch[m]>
I could see a new option that makes your node treat inscriptions as non-standard that is off by default be considered
<_aj_>
achow101: (off-topic: tnx for the merge)
<Murch[m]>
Then people who want that can gimp their own node
pB6102 has joined #bitcoin-core-dev
<wk057>
it's objectively a vulnerability. the ability to inject data into a system in an unintended way is pretty much the most common exploit in existence. saying it's not a vulnerability is odd.
<Earnestly>
achow101: If the filters are behind a flag, and people can choose to use it, why would that necessarily be a blocker? Does there need to be more robust evidence that the filters prevent the behaviour it's designed to stop?
<_aj_>
wk057: "unintended" is not an objective criterion
<achow101>
Earnestly: never said that it was
<instagibbs>
again, this is nothing new, there is nothing to discuss here
<Earnestly>
I see, so a PR adding such a feature would be fine
jkjkjk has joined #bitcoin-core-dev
<wk057>
instagibbs: it merits discussion. since the original PR was closed for being "controverial", then finding a solution that checks all the boxes would merit discussion for an obvious issue.
<GregTonoski>
Pieter Wuille said that 4MB block is ""pathological" . It occurred in 2023.
<luke-jr>
_aj_: it pretty much is, at least in this case; pretending it was intended is dishonest
<instagibbs>
And I'm done engaging with this. thanks.
test__ has joined #bitcoin-core-dev
<_aj_>
luke-jr: the people sending the spam certainly intend it
<achow101>
wk057: since there is an issue open, discussing in that issue should be sufficient
<luke-jr>
_aj_: pfft, so does every attacker
<Earnestly>
I certainly don't want to store this data on my node, is there anything I can do to mitigate it?
<sipa>
Earnestly: run a pruned node
<achow101>
especially since discussion here is transient
<Earnestly>
sipa: I do, but I don't want to process it (I also want to keep historical nodes as well)
<instagibbs>
Is this the last topic?
<achow101>
instagibbs: no
<reardencode>
Earnestly: rot13maxi made a script to invalidate blocks containing inscriptions. it'll put you on your own fork of bitcoin.
<wk057>
achow101: seems this is a broad enough topic to warrant at least some realtime developer discussion to make the solutions that would be acceptable for merge more obvious before dev effort is expended on something that has no hope of merging
<glozow>
fwiw I disagree that this is a vulnerability. I already reviewed 28408 and summarized all of the arguments for/against it, concluding it shouldn't be merged. I have a writeup on my notes repo. I plan on reviewing and opening PRs that I think are important, and this discussion isn't changing that.
<glozow>
#proposedmeetingtopic note to use new logging macros (#28318)
<luke-jr>
glozow: every argument against it, has been amply refuted already
<sipa>
luke-jr: people clearly disagree with you here
<Earnestly>
glozow: Why wouldn't be considered as such if a specific sequence of operators are selected specifically to bypass OP_RETURN, why don't they just use op_return?
<wk057>
glozow: you seem to have conveniently skipped over some key points in your summary, but that PR is closed, so the discussion is to determine the best way forward from here without wasting additional developer resources
<glozow>
luke-jr: having read through all of the comments and mailing list posts and a lot of twitter, I disagree.
<reardencode>
Earnestly: they don't use OP_RETURN because it is limited to 80 bytes - hence my suggestion.
<Earnestly>
reardencode: Why was it limited?
<achow101>
wk057: from the existing discussions on the topic, there generally seems to be agreement that a default off option to enable such filters may be acceptable, at least more so than the datacarriersize change
flooded has quit [Ping timeout: 256 seconds]
<Murch[m]>
achow101: Thanks, it was just a summary of above: Make it a default-off optional new configuration option that only applies to inscriptions, and I could see it get merge.
<achow101>
wk057: does that sufficiently resolve your desire to have a discussion here?
<wk057>
achow101: default off option doesn't address the issue. I agree it should be an option, but default off doesn't actually solve anything.
<luke-jr>
achow101: Murch[m]: so we add a new option for every new spam scheme?
<_aj_>
luke-jr: for any that are controversial, certainly
<Murch[m]>
If you think that is a useful way of spending your time, be my guest
<luke-jr>
refusing to admit it's a vulnerability, and making such crazy suggestions, just strikes me as dishonesty, sorry
<Earnestly>
luke-jr: Would it be possible to provide a more generic mechanism that reads in a set of rules, in some DSL format, that can be used to filter?
<_aj_>
luke-jr: (and spammers will naturally try to make them all controversial, so...)
<wk057>
that was what I was writing. so everyone who wants to address a vulnerability needs to get a PR approved for a new option that defaults to allowing exploitation of that vulnerability? that doesn't seem reasonable.
<Earnestly>
In that manner you can then add new rules to this file to catch any new mechanisms used to bypass the original limit
<wk057>
The people exploiting a bug shouldn't really get a say in whether or not the bug is fixed.
<Murch[m]>
I think the topic is now "note to use new logging macros (#28318)", though
<Earnestly>
luke-jr: So instead of having to hardcode a set of rules directly in the codebase they can be expressed as a file
<_aj_>
Murch[m]: that was proposed, not switched to
<Murch[m]>
ah, you’re right
<achow101>
I think the specific details regarding the implementation of such a flag can be discussed in its PR, once open
<sipa>
sigh, there is economic demand for block space, whether you like it or not - the buyers and sellers of that space both want the transaction to occur, i don't see what anyone thinks they can do about that
<dergoegge>
can we move on?
<instagibbs>
dergoegge +1
<kevkevin>
dergoegge +1
<brunoerg>
dergoegge +1
<josie>
dergoegge +1
<glozow>
dergoegge +1
<achow101>
#topic bip324 defaults for 27.0 (achow101)
<Murch[m]>
dergoegge: +1
<wk057>
achow101: since there's been development time on the original PR that's been "spinning wheels", it would make sense to try to limit further wasted efforts
<achow101>
The 27.0 feature freeze is in a month, so what defaults should we try to get for bip324 in before then?
<instagibbs>
re:bip324, did all the open testing PRs get merged? it seems t obe getting reasonable runtime as I've seen both incoming and outgoing v3 connections
<instagibbs>
v2
<sipa>
there is the big functional test PR, #24748
<sipa>
which i consider the one blocker to enabling bip324 b
<sipa>
y default
<instagibbs>
that was my impression as well
<achow101>
I think it would be good to have v2transport enable trying v2 for all outbound connections. as it is now, people don't seem to fully get that the only way to have a v2 outbound is with the addnode rpc
<_aj_>
sipa: so it should go on the high-pri list?
<sipa>
achow101: not anymore since #29058
<gribble>
https://github.com/bitcoin/bitcoin/issues/29058 | net, cli: use v2transport for manual/addrfetch connections, add to -netinfo by mzumsande · Pull Request #29058 · bitcoin/bitcoin · GitHub
<achow101>
-addnode is still needed though
<josie>
_aj_ +1, was surprised the func test PR was still open
PatBoy has joined #bitcoin-core-dev
<lightlike>
achow101: -connect also works now
Guest59 has joined #bitcoin-core-dev
<instagibbs>
i have a non-manual outbound v2 on v26, did I previously -connect it or something?
<sipa>
achow101: for automatic connections, if both sides run with `-v2transport`, and the service flag propagated ahead of time, a bip324 connection will be used
<instagibbs>
sipa ah ok 👍
Guest19 has joined #bitcoin-core-dev
pB6102 has quit [Quit: Client closed]
<glozow>
_aj_: added
<achow101>
sipa: really? my previously addnode'd connections don't seem to use v2 after I restart
<sipa>
achow101: i was talking about automatic connections, not manual ones
<jonatack>
Would be good for someone to open a PR to simplify the API for level based logging after that merge
<lightlike>
there will be tons of conflicts. maybe do it after the branch-off or something?
<achow101>
lightlike: good point
<_aj_>
lightlike: it's a scripted diff so should be easy to maintain until the branch off
Chris_Stewart_5 has quit [Ping timeout: 264 seconds]
<achow101>
Any other topics to discuss?
<fanquake>
Why is after branch off better?
<fanquake>
There's still the same number of conflicts
<fanquake>
and backports are now just harder to do
itme_brain has joined #bitcoin-core-dev
<jonatack>
The goal and review feedback I gave was to have a unified interface of one single Log() macro.
<_aj_>
after feature freeze maybe
<maflcko>
It will be a scripted-diff, but not a refactor, right? The log output will change slightly, to include "warning" or "error" prefixes?
<_aj_>
maflcko: a refactor, log output won't change
<lightlike>
fanquake: so that higher-prioritised projects that still need to get into v27 are not delayed by this.
<glozow>
jonatack: hm, I don't really think that'd be better. This way we use the same macro the vast majority of the time, and don't need to pass in an arg for all of them.
<fanquake>
lightlike: right, not sure there would be "tons" of conflicts in the high-prio PRs though? I'll take a look
<jonatack>
on the blockers list. Oh well :)
<achow101>
jonatack: there's only one ack, and (althought not explicitly said) a nack
<_aj_>
jonatack: that PR had unaddressed feedback since september...
<achow101>
and no activity for a long time
<maflcko>
jonatack: Is it still relevant after the merge?
<maflcko>
Wasn't "NONE" removed anyway?
<_aj_>
maflcko: aspects of it are, yes
<maflcko>
ok
<glozow>
ISTM the project ended up choosing an alternate approach maybe just close that PR? we don't need more logging fragmentation
test__ is now known as _flood
<jonatack>
glozow: a single Log(level, category) is a simple as it gets. Multiple macros with differing APIs requires developers to remember more context, and necessitates more code, docs, and test coverage
<stickies-v>
a single function doesn't equal a simple interface though
Guest44 has quit [Client Quit]
<lightlike>
fanquake: I think there is no PR yet with the scripted diff, so probably best to open that and look just how many conflicts threre actually are.
<jonatack>
The new APIs don't all take the same arguments. Devs will have to remember which macros take which parameters. Etc.
<achow101>
I already don't remember what macros take which parameters, so that's nothing new
<_aj_>
lightlike: +1
Guest59 has quit [Quit: Client closed]
<jamesob>
jonatack: yeah, that I do have beef with - left some commentary in the recent PR
<jonatack>
jamesob: yes
<achow101>
anyways, open prs and let's discuss there
<maflcko>
Seems a bit early when there are still outstanding bugs and crashes, no?
<jamesob>
So it's not really clear to me what the criteria is for when we're ready to merge the assumeutxo PRs. IMO it's pretty low risk to do so and let "expert users" start calling the RPC to make use of it
<sipa>
shouldn't we figure out distribution/P2P fetching of chainstates before nailing that down, as it may mean we need to change serialization format?
<jamesob>
Are there bugs and crashes?
<maflcko>
Yes
<sipa>
i guess it's fair that there is no problem changing the format afterwards
<jamesob>
sipa: I think that will take a very long time to do
<jamesob>
maflcko: mind actually referencing the bugs and crashes?
<jonatack>
glozow: just close which PR, please? The bugfix is still relevant.
<fanquake>
also need to decide about things like #28598
<gribble>
https://github.com/bitcoin/bitcoin/issues/28598 | assumeutxo: Ensure transactions are not presented as confirmed until background sync is complete · Issue #28598 · bitcoin/bitcoin · GitHub
<jamesob>
I'm aware of a number of refactoring/cleanup/test PRs that are proposed, some of which IMO are matters of taste
<maflcko>
jamesob: Sorry, I am looking for it ...
<instagibbs>
there should probably(still?) be a tracking issue sounds like
<jamesob>
Anyway, I'm not saying we should merge the params now - but it would be nice to develop an understanding of when we're ready for expert users to start trying it out for real
<maflcko>
#28791
<gribble>
https://github.com/bitcoin/bitcoin/issues/28791 | snapshots: dont core dump when running -checkblockindex after `loadtxoutset` by maaku · Pull Request #28791 · bitcoin/bitcoin · GitHub
<jamesob>
I really don't think it should just hang out waiting for a P2P scheme to come along, or for the dump format to change
<_aj_>
i don't see any "bugs and crashes" in the open issues list under a search for assumeutxo? be good to add an issue if there's not one already
<sipa>
jamesob: i'm not saying wait for it, i'm saying work on it!
<maflcko>
_aj_: "crash" -> "core dump"
<jamesob>
sipa: ain't gonna be me!
<sipa>
but fair enough, if we expect that not to happen anytime soon, it may be reasonable to go for a "experts use only" deployment before that part is fleshed out
<jamesob>
maflcko: thanks for the link
<achow101>
I think enabling it for the rpc should be fine to do prior to figuring out distribution
<achow101>
Anything else to discuss in our last few minutes today?
<jamesob>
I'll review that Sjors wallet PR
<_aj_>
so fix known crash bugs, then add mainnet params/update testnet/signet params?
<achow101>
sounds like it
<fanquake>
then decide on how to represent this to users. if anything needs changing or not
<instagibbs>
experimental "add footgun here", let pre-packaged node distros try it out, seems natural
<achow101>
#endmeeting
<_aj_>
maflcko: "assumeutxo" -> "loadtxoutset" was what i actually needed
<jamesob>
instagibbs: right
<jonatack>
achow101: "I already don't remember what macros take which parameters, so that's nothing new" -> right, the idea was to fix that.
<_aj_>
unconditional logging just takes the message, conditional logging takes a category. unconditional levels are Error, Warning and Info
<_aj_>
which levels are unconditional is something you need to know anyway, or you'll flood people's logs
<jonatack>
unconditional logging depends on what level the user specifies
<_aj_>
right, so we should fix that too
<jonatack>
yes. but not hardcode it into moar macros ;)
puchka has quit [Ping timeout: 276 seconds]
<jonatack>
I do appreciate that you added the -loglevelalways option
<jonatack>
as that option is the default I expected the logging to take, but I can at least still use the logging that way
<bitcoin-git>
[bitcoin] Sjors opened pull request #29229: Make (Read/Write)BinaryFile work with char vector (master...2024/01/rw-binary-file) https://github.com/bitcoin/bitcoin/pull/29229
<jonatack>
I don't think a scripted-diff to update all the macros is a good idea until the API is finished and simpler.
puchka has joined #bitcoin-core-dev
achow101 has quit [Remote host closed the connection]
achow101 has joined #bitcoin-core-dev
achow101 has quit [Remote host closed the connection]
pietre has joined #bitcoin-core-dev
itme_brain has left #bitcoin-core-dev [WeeChat 4.0.4]
JesterHodl has quit [Quit: Client closed]
achow101 has joined #bitcoin-core-dev
<Sjors[m]>
I've been focused on Stratum v2 stuff, but I'll try to keep my other PR's up to date as well.
preimage has joined #bitcoin-core-dev
pietre has quit [Quit: Client closed]
wk057 has quit [Remote host closed the connection]
itme_brain has left #bitcoin-core-dev [#bitcoin-core-dev]
<jonatack>
s/buggy/incomplete/
<bitcoin-git>
[bitcoin] jonatack opened pull request #29230: doc: update -loglevel help following merge of PR 28318 (master...2024-01-fix-loglevel-help) https://github.com/bitcoin/bitcoin/pull/29230
<bitcoin-git>
bitcoin/master 37324ae Sebastian Falbesoner: test: use `skip_if_platform_not_linux` helper where possible
<bitcoin-git>
bitcoin/master 4c65ac9 Sebastian Falbesoner: test: detect OS consistently using `platform.system()`
<bitcoin-git>
bitcoin/master 878d914 Sebastian Falbesoner: doc: test: mention OS detection preferences in style guideline
<bitcoin-git>
[bitcoin] achow101 merged pull request #29034: test: detect OS in functional tests consistently using `platform.system()` (master...202312-test-consolidate_os_detection_in_python) https://github.com/bitcoin/bitcoin/pull/29034
salvatoshi has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] fanquake opened pull request #29233: build: depends move macOS C(XX) FLAGS out of C & CXX (master...dedup_macos_flags) https://github.com/bitcoin/bitcoin/pull/29233
AaronvanW has joined #bitcoin-core-dev
Aaronvan_ has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 256 seconds]
Aaronvan_ is now known as AaronvanW
<jamesob>
fanquake maflcko: can't really grok that msvc wallet failure... don't understand why windows would be unique there
<fanquake>
Yea it's rare for Windows to ever behave uniquely
szkl has quit [Quit: Connection closed for inactivity]
<jamesob>
oh hm, maybe something about windows doesn't permit multiple readers on the same wallet file
<jamesob>
any clue why it wouldn't have failed in the PR's CI run?
abubakarsadiq has quit [Quit: Connection closed for inactivity]
GregTonoski has joined #bitcoin-core-dev
<sforza>
everyone on stackexchange is just getting robbed and scammed
<sforza>
i dont want to be there
<sforza>
no one knows what theyre doing on stackexchange, apparently.
<sipa>
this is off topic here
<sforza>
ok
DarrylTheFiish has quit [Ping timeout: 264 seconds]
Talkless has quit [Quit: Konversation terminated!]
GregTonoski has quit [Quit: Client closed]
szkl has joined #bitcoin-core-dev
Guest99 has joined #bitcoin-core-dev
Guest99 has quit [Client Quit]
<jamesob>
man the tone has been pretty prickly around the project lately
x11u has joined #bitcoin-core-dev
Guest15 has joined #bitcoin-core-dev
<x11u>
exit
x11u has quit [Quit: WeeChat 3.8]
Guest15 has quit [Client Quit]
x11u has joined #bitcoin-core-dev
x11u has quit [Client Quit]
<bitcoin-git>
[bitcoin] jamesob opened pull request #29238: test: unbreak: exclude windows from wallet_assumeutxo (master...2024-01-au-wallet-fix) https://github.com/bitcoin/bitcoin/pull/29238
<bitcoin-git>
[bitcoin] sipa opened pull request #29239: Make v2transaction default for addnode RPC when enabled (master...202401_default_addnode_bip324) https://github.com/bitcoin/bitcoin/pull/29239
x11u has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
salvatoshi_ has joined #bitcoin-core-dev
test__ has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 256 seconds]
flooded has quit [Ping timeout: 240 seconds]
pablomartin4btc has quit [Ping timeout: 264 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
x11u has quit [Quit: WeeChat 3.8]
brunoerg has joined #bitcoin-core-dev
x11u has joined #bitcoin-core-dev
vysn has quit [Remote host closed the connection]
salvatoshi__ has joined #bitcoin-core-dev
salvatoshi_ has quit [Ping timeout: 256 seconds]
kevkevin has quit [Remote host closed the connection]