<bitcoin-git>
bitcoin/master 2c05dc7 dontbyte: Fix link to MurmurHash3.cpp from Austin Appleby
<bitcoin-git>
bitcoin/master ccea0e1 MacroFake: Merge bitcoin/bitcoin#25959: doc: Fix link to MurmurHash3.cpp (moved from ...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25959: doc: Fix link to MurmurHash3.cpp (moved from Google Code to Github) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/25959
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
yanmaani2 has quit [Remote host closed the connection]
yanmaani2 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
SpellChecker has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 255 seconds]
AaronvanW has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
<bitcoin-git>
[bitcoin] stickies-v opened pull request #25971: refactor: Use std::string for thread and index names (master...baseindex-getname-string) https://github.com/bitcoin/bitcoin/pull/25971
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
bitdex_ has quit [Quit: = ""]
ari0x has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 258 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
jonatack has quit [Ping timeout: 255 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Cory has joined #bitcoin-core-dev
Pasha has quit [Ping timeout: 260 seconds]
halosghost has joined #bitcoin-core-dev
elichai2 has quit [Ping timeout: 240 seconds]
elichai2 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #25972: build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set (master...use_cxxflags_with_depends) https://github.com/bitcoin/bitcoin/pull/25972
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
mdguy has joined #bitcoin-core-dev
ElBuda_ has quit [Ping timeout: 244 seconds]
Guyver2 has joined #bitcoin-core-dev
ElBuda_ has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
<vasild>
"I'm not sure what I did wrong" -- maybe you tried -onlynet=cjdns but without -cjdnsreachable?
<vasild>
hmm, should we emit a startup warning or even abort startup if -onlynet=cjdns is given without -cjdnsreachable?
sudoforge has joined #bitcoin-core-dev
<lightlike>
vasild: agree, but do you think it's worth making a PR to change just this? (considering that addpeeraddress RPC is debug-only and mostly for functional tests, which don't currently add cjdns addresses)
<sipa>
Seems reasonable.
<vasild>
I don't know, that is probably subjective, based on how many other more important things you have on your plate :)
<lightlike>
vasild: I think so, we have the same for -onlynet=onion when we don't have a proxy set.
<lightlike>
I can open a PR to do both of these, thanks!
<vasild>
that would be excellent!
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<lightlike>
vasild: we should probably do the equivalent for -onlynet=i2p and missing -i2psam as well, right?
<vasild>
yes, of course!
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
jonatack has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #25974: test, build: Separate `read_json` function into its own module (master...220901-test) https://github.com/bitcoin/bitcoin/pull/25974
PaperSword has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
andytosh1 is now known as andytoshi
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
davidjumberj has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
davidjumberj has quit [Quit: Client closed]
bytes1440000 has joined #bitcoin-core-dev
<bytes1440000>
1. I have less signet coins and faucet allows 0.001 max. If anyone has lot of signet coins and interested to test #24897, please send me some coins to :dig -t txt alice.silentbitco.in
<bytes1440000>
2. I think its been a long time since we discussed funding of contributors who are more active in review. Luke Dashjr has contributed a lot in reviews that were helpful for bitcoin. If anyone avoiding because he is a maintainer of knots, is influenced by less than 25 people who actively contribute to core or past.
<bytes1440000>
Please look at the reviews and see who deserve it. Opensats and others have advertised a lot about them but could never see anyone who pays reviewers or someone working of knots or similar fork.
<bytes1440000>
I will try to get him some funding once exchange is live. Our exchange will only fund reviewers and not committers. However its a responsibility for others to see as well.
bytes1440000 has left #bitcoin-core-dev [#bitcoin-core-dev]
yanmaani2 has quit [Ping timeout: 258 seconds]
evanlinjin has quit [Ping timeout: 258 seconds]
yanmaani2 has joined #bitcoin-core-dev
evanlinjin has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
<luke-jr>
a bit late, but maybe we can squeeze it in in the next hour: would it be difficult to make the new header sync thing optional for bandwidth-bottlenecked nodes?
<sipa>
@[luke-jr] With #25960 you can use the noban permission on a peer to bypass it.
<luke-jr>
sipa: right, but I mean for all nodes/by defautl
<sipa>
Yeah, I understand. Not saying this is equivalent, but it does allow some bypassing if it's really a concern.
<sipa>
Though, if you are that bandwidth starved that this is a problem, you'll have far more difficulty syncing the blocks.
<luke-jr>
true
<lightlike>
Passing a very low -minimumchainwork might alternatively work to bypass? Though that may have other downsides...
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
kexkey has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] luke-jr opened pull request #25976: QA: rpc_blockchain: Test output of getblock verbosity 0, False, and True (master...qa_rpc_getblock_verbose) https://github.com/bitcoin/bitcoin/pull/25976
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
<ariard>
well happy to talk about full-rbf (#25600)
<gribble>
https://github.com/bitcoin/bitcoin/issues/25600 | p2p: Advertise `NODE_FULL_RBF` and connect to 4 outbound full-rbf peers if `-mempoolfullrbf` is set by ariard · Pull Request #25600 · bitcoin/bitcoin · GitHub
<ariard>
(sorry for last week, was geeking out about bitcoin in meatspace at conf)
<jonatack>
(would unblock progress that has been stalled for 3 months)
<fanquake>
achow101: I think the experimental upgradewallet RPC could be good candidate for final feature merge
<jonatack>
In any case, I think 25614 has well enough review that it can be removed from the blockers list.
<luke-jr>
fanquake: merge it then? :p
<fanquake>
we’ve got some time to flesh out more bugs prior to branch off. Worst case could made it more “hidden” for this release. However would be nice to get in and some amount of testing.
<jonatack>
as review isn't what is blocking 25614
<fanquake>
luke-jr: I’m afk for the rest of the day
Talkless has quit [Quit: Konversation terminated!]
<luke-jr>
jonatack: what is?
<jonatack>
luke-jr: someone willing to merge, i guess
<achow101>
jonatack: I'll have a look at it.
<jonatack>
(before, laanwj was merging the work on this)
<jonatack>
achow101: cheers
<luke-jr>
achow101: maybe merge yours too; I'm hesitant to +1 without reviewing it myself, but fanquake agrees with your rtm assessment, so..
<achow101>
luke-jr: will do
<achow101>
#topic full-rbf maximalism vs gentle phase-out of opt-in RBF (ariard)
<core-meetingbot>
topic: full-rbf maximalism vs gentle phase-out of opt-in RBF (ariard)
<ariard>
hey hey
<ariard>
so about full-rbf, i'm interested to have it being functional for the node operators willing to enjoy the benefits of it, likely LN nodes for now
<ariard>
somehow for it to be functional, you need a) full-rbf propagation paths to the miners b) few miners turning on the option
<luke-jr>
pretty sure some miners have mined full RBF for years
<ariard>
to solve a) there is either a.1) you connect to other full-rbf peers manually, a.2) full-rbf is turn on by default
<ariard>
and c) preferential automatic peering (#25600)
<gribble>
https://github.com/bitcoin/bitcoin/issues/25600 | p2p: Advertise `NODE_FULL_RBF` and connect to 4 outbound full-rbf peers if `-mempoolfullrbf` is set by ariard · Pull Request #25600 · bitcoin/bitcoin · GitHub
<luke-jr>
ariard: or d) enough users turn on full RBF manually ;)
<ariard>
luke-jr: there have been miners mining full rbf in the past, hard to say without more data points collected
<ariard>
luke-jr: that's correct, that's also an option
<achow101>
users don't tend to change defaults
<ariard>
however, as a savy technical user, i would be more interested to have my nodes doing preferential automatic peering, and likewise any full-rbf interested node operators
<luke-jr>
I'd have liked to see 25600 in, but it's not ready at a glance :<
<achow101>
i would prefer preferential peering
<gleb>
what's the objective of discussing it here? we had a bunch of discussion in the PR, do you want just more opinions? Or a more *advanced* discussion?
<gleb>
I mean, am i supposed to repeat my comment in the PR? i dunno
<ariard>
luke-jr: yeah just seen the comment, non-reliability of the service bit as been discussed during yesterday review club session
<luke-jr>
policy is arbitrary node preference. it can never be reliable.
<ariard>
gleb: just to bring the awareness of everyone the state of the discussion, there was also a review club session, and if anyone has more thoughts
<luke-jr>
so IMO it's a dead argument against it. but there's no ACKs on the current code either :/
<ariard>
luke-jr: likewise tx-relay is not reliable, and still we have a p2p network
<luke-jr>
indeed
<lightlike>
I don't think anyone suggested to have it as early as 24.0 in any case.
<ariard>
though one could argue we could introduce scoring of our p2p peers, in the same way LN is doing for payment paths and ensure HTLC propagation is reliable
<luke-jr>
lightlike: well, 24.0 is adding full RBF support
<ariard>
(won't argue that now)
<ariard>
lightlike: yeah i agree, more for future releases
<ariard>
in anycase, doing preferential peering, even imperfect, to increase the effiency of our policy rules could be seen as a process change in the way we're releasing policy
<achow101>
we've done preferential peering in the past though, e.g. segwit
<ariard>
so i think it's good to have more feedbacks on that (as I'm worried in the future we have more complex L2-and-policy interactions to handle)
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<ariard>
achow101: sure, it was for consensus though?
<achow101>
iirc it was for both consensus and relay
<luke-jr>
full RBF service bit is pretty established tho, I don't think it sets a precedent for future ideas
<achow101>
so that segwit txs would be properly relayed to miners
<ariard>
iirc, to discover enough peers relaying segwit txn
<luke-jr>
I thought it was to find peers with segwit blocks ;p
<luke-jr>
without access to which we'd have a consensus-level failure
<ariard>
luke-jr: i think we could do that for package relay for 1 or 2 releases, to ensure it's robust and works well before to active for everyone
<instagibbs>
^
<ariard>
but yeah that's another discussion
<instagibbs>
(that was for luke)
<ariard>
luke-jr: i don't remember the exact rational, will check
<achow101>
in any case, I don't think anyone is against preferential peering?
<luke-jr>
achow101: presumably the NACKer is
<ariard>
luke-jr: will answer that one on the PR
<instagibbs>
achow101, it uses more resources, or narrows the nodes you'll connect to if cannibalizing current slots
<lightlike>
achow101: it's not so clear. Some people have expressed that they would prefer changing the default.
<achow101>
I suppose I should actually read the pr
<jonatack>
ariard: will look into your PR
<jonatack>
the discussion on it looks interesting in any case
Kaizen_Kintsugi_ has quit [Ping timeout: 264 seconds]
<ariard>
lightlike: yes, i think it's different if preferential peering is a) re-using the current outbound slots or b) consuming extra-outbound slots), in case of b) that could be seen as node operator pref in the way you're using your slots
<achow101>
even with on by default, I would still like preferential peering as people upgrade
<ariard>
assuming you're connecting to full-rbf signaling peers
<achow101>
but that seems like a discussion for the pr
<ariard>
yeah, i think that's all i wished to bring to awareness :)
<luke-jr>
(will you be taking over meetings in general?)
<ariard>
+1, we can also do rotating chairs among maintainers like we're doing for LN meetings
<achow101>
not sure yet
mdguy has quit [Quit: Leaving]
<luke-jr>
ariard: why maintainers specifically?
<luke-jr>
btw, is github having issues today for anyone else, or just me? :x
<ariard>
luke-jr: or any regular contributor with enough experience of hosting IRC meetings, as long as it's on someone or a group of someone todo, personally i don't care
<ariard>
(otherwise, we're like LN meetings where we take 5min everytime to decide who is hosting today)