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
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
Saturday7 has joined #bitcoin-core-dev
saturday- has quit [Ping timeout: 246 seconds]
jonatack has quit [Ping timeout: 252 seconds]
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 244 seconds]
saturday- has joined #bitcoin-core-dev
Saturday7 has quit [Ping timeout: 244 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 246 seconds]
SpellChecker has quit [Ping timeout: 264 seconds]
SpellChecker_ has joined #bitcoin-core-dev
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 264 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
saturday- has quit [Ping timeout: 248 seconds]
eval-exec has joined #bitcoin-core-dev
Saturday7 has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
Saturday7 has quit [Ping timeout: 248 seconds]
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
otoburb has quit [Quit: leaving]
Saturday7 has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
dviola has quit [Read error: Connection reset by peer]
diego has joined #bitcoin-core-dev
diego has left #bitcoin-core-dev [#bitcoin-core-dev]
dviola has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 244 seconds]
mcey_ has quit [Remote host closed the connection]
mcey_ has joined #bitcoin-core-dev
BrandonOdiwuor has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
pyth has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 248 seconds]
bitdex has joined #bitcoin-core-dev
otoburb has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
BrandonOdiwuor has quit [Ping timeout: 240 seconds]
Guyver2 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 276 seconds]
kevkevin has joined #bitcoin-core-dev
eval-exec has joined #bitcoin-core-dev
Cory93 has quit [Quit: Client closed]
Cory93 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
Cory93 has quit [Quit: Client closed]
Cory93 has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
Guest84 has joined #bitcoin-core-dev
Guest84 has quit [Client Quit]
eval-exec has joined #bitcoin-core-dev
aleggg has quit [Remote host closed the connection]
aleggg has joined #bitcoin-core-dev
Cory93 has quit [Quit: Client closed]
Cory93 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 245 seconds]
kevkevin has joined #bitcoin-core-dev
SpellChecker_ is now known as SpellChecker
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
eval-exec1 has joined #bitcoin-core-dev
Guyver2 has quit [Remote host closed the connection]
eval-exec has quit [Ping timeout: 244 seconds]
eval-exec1 is now known as eval-exec
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 272 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 246 seconds]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake closed pull request #31735: Fix compilation errors in blockchain.cpp related to serialization, UTXO dumping, and path conversion (master...master) https://github.com/bitcoin/bitcoin/pull/31735
kevkevin has quit [Ping timeout: 248 seconds]
kevkevin has joined #bitcoin-core-dev
Cory93 has quit [Quit: Client closed]
Cory93 has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
<cfields> ryanofsky: ok if I work on vendoring libmultiprocess? Or have you already started?
<ryanofsky> i'm basically done, about to push some prs
<cfields> oh great, will review yours instead then :)
<ryanofsky> thank you!
eval-exec has quit [Ping timeout: 244 seconds]
Emc99 has joined #bitcoin-core-dev
Emc99 has quit [Client Quit]
<Sjors[m]> ryanofsky: can you do make a PR for bumping multiprocess master that's separate from vendoring?
<ryanofsky> yes, plan is to open two prs
<Sjors[m]> Thanks
bugs_ has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
luke-jr_ has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 252 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
preimage has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<bitcoin-git> [bitcoin] ryanofsky opened pull request #31740: depends: Update libmultiprocess library before converting to subtree (master...pr/bumptree) https://github.com/bitcoin/bitcoin/pull/31740
jonatack has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] ryanofsky opened pull request #31741: multiprocess: Add libmultiprocess git subtree (master...pr/subtree) https://github.com/bitcoin/bitcoin/pull/31741
Cory93 has quit [Quit: Client closed]
Cory93 has joined #bitcoin-core-dev
<cfields> ryanofsky: yeeesh, I didn't realize that CMake has _no concept_ of build-side tools during cross-compile :\
<cfields> that's... crazy. And makes this messy :(
preimage has quit [Ping timeout: 252 seconds]
<ryanofsky> i'm actually very happen with the current solution, there is basically very little change to anything. i was expecting it to be much messier
<ryanofsky> i did look into using https://cmake.org/cmake/help/latest/module/ExternalProject.html as an alternative to let cmake cross compile the code generator but by contrast that did seem very messy
<cfields> ok, I'll reserve judgement. It just didn't look anything like I expected because I wasn't aware of that.
preimage has joined #bitcoin-core-dev
<cfields> right, yeah, I was just reading up on that approach.
<hebasto> cfields: qt resolved a similar problem by requiring to have a native qt installed before cross building
<cfields> hebasto: right, in the case of depends it makes sense to split them up and have them hard-coded because those steps are automated. This one unfortunately is user-facing.
<cfields> ryanofsky: thanks for the pr. I haven't really experimented with building this stuff that much, just once a long time ago. So I'm catching myself up now on how it all works together.
<ryanofsky> of course, and let me know if you run into any snags. I can probably help and also explain anything the build is doing since build system code is not the most readable
<fanquake> I think ideally we won’t end up with just having a 3rd different (supported) way to use multiprocess. Which would seem to be the case with this PR. Will have to look at the details tomorrow though
<cfields> no worries, i'll try to figure it out myself first. may take a while, but that'll force me to understand it :)
<cfields> right, agreed.
<cfields> ok, but tldr the high-level hack is that depends is using our own source-tree has a "package", right?
zeropoint has joined #bitcoin-core-dev
<ryanofsky> yes, i don't see it as a hack, i think it useful to be able to use a local directory as a package and it was pretty trivial to implement
<cfields> nm, I see the comment now.
<ryanofsky> it is respecting build ids and everything so if directory contents change downstream dependencies are rebuilt
<cfields> ack
ghost43 has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 264 seconds]
SpellChecker has joined #bitcoin-core-dev
ghost43_ has quit [Ping timeout: 264 seconds]
Guest57 has joined #bitcoin-core-dev
Guest57 has quit [Quit: Client closed]
<cfields> ryanofsky: are the generated source files platform-specific, or could they (in theory) be committed to the repo?
<ryanofsky> no, they are not platform specific, and you can see them by building with -DBUILD_MULTIPROCESS=ON and running find -name '*.capnp.*'
<cfields> hmm, I wonder if committing them would be a more reasonable approach, then? With a build target for generating them locally, same as we do for (for ex) qt translations.
<cfields> I assume we won't be updating them that frequently?
jespada has joined #bitcoin-core-dev
<ryanofsky> during development they are updated every time you add a method or struct field, method parameter etc. it is definitely convenient to just update the source and just run make
Talkless has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<sipa> i'm trying to add a new binary (just for experimentation, not something that ever needs to be PR'ed), i copied the {,src/}CMakeLists.txt logic for bitcoin-tx, and a new binary gets built which runs, but when i try to invoke any random.h function, i get this error:
<sipa> /usr/bin/ld: util/libbitcoin_util.a(clientversion.cpp.o): in function `std::_Function_base::_M_empty() const':
<sipa> /usr/include/c++/14/bits/std_function.h:247:(.text+0x12a8): undefined reference to `G_TRANSLATION_FUN[abi:cxx11]'
<sipa> /usr/bin/ld: /usr/include/c++/14/bits/std_function.h:247:(.text+0x1db5): undefined reference to `G_TRANSLATION_FUN[abi:cxx11]'
<sipa> anyone have a clue?
<bitcoin-git> [bitcoin] jurraca opened pull request #31742: contrib: fix BUILDDIR in gen-bitcoin-conf script and gen-manpages.py (master...fix-builddir) https://github.com/bitcoin/bitcoin/pull/31742
<glozow> sipa instagibbs i got about halfway implementing what you described (currently running fuzzer on my helper funcs). I was trying to break it this weekend and couldn’t come up with anything. (eg if peers can work together to exceed limits or keep things in orphanage forever. or if it’s possible to get into a state where we can’t find anything to evict which is where i got stuck last time I tried to make eviction smarter)
<ryanofsky> sipa, you need to add `#include <util/translation.h>` and `const TranslateFn G_TRANSLATION_FUN{nullptr};`
<ryanofsky> rn any executable which uses libbitcoin_util needs these
<glozow> ^just a progress report, i promise i’m working on it!
<sipa> ryanofsky: oh, i totally missed that G_TRANSLATION_FUN could be something in our codebase, it sounded like a strange linker magic thing
<sipa> thank you!
<sipa> glozow: cool!
<instagibbs> cool! I think I've convinced myself, assuming pretty reasonable assumptions, we won't do "any worse" vs today.
<instagibbs> Precluding the scenarios where people are doing a lot of beefy CPFPing children in a short window for whatever reason
Guest27 has joined #bitcoin-core-dev
<sipa> an observation that sdaftuar which i didn't consider: generally "orphan packages" over 400 kWU will fail to reconstruct just to ancestor/descendant vsize limits in the mempool
<instagibbs> you're left with 4kwu after that, so it would be a weird package for sure
<sipa> ok, or set the reservation tot 404 kWU i guess
<sipa> but the point is that ~400 kWU reservation per peer should be enough, as long as there is just a single orphan package in flight at a time from any given peer
Guest27 has quit [Ping timeout: 240 seconds]
<instagibbs> if the reservation was 4MWU that is ~10 max weight txns, and thus packages. If the "average case" orphan is 40kWU instead, that would put us at ~100. I think that's likely an overshoot of the actual average.
<sipa> indeed
<sipa> I still think a higher reservation for outbounds is acceptable (~4 WMU)
<glozow> yeah I think doing 400kwu per peer was what we were thinking, but we had been saying 10x that for outbounds
<instagibbs> yeah I'm referring to outbound mostly here, "one honest outbound"
<glozow> are we thinking we don’t need to give outbounds extra?
<sipa> glozow: i guess my thinking is "we don't need to give outbounds (as much) extra, but we can, so why not?
<instagibbs> im thinking extra like sipa says, to be clear, I just don't want to do worse if all outbounds are relatively in sync
<glozow> right
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<glozow> we could brainstorm a “popular orphan” score for automatic protection or lower likelihood of eviction maybe? but future work
<glozow> (to mitigate the “outbounds in sync” thing)
<instagibbs> yeah we can complicate things later...
<instagibbs> "do no harm" was my only concern for now
<sipa> glozow: the "evict one announcer among those whose usage/reservation ratio is maximal" idea will sort of naturally mean that things announced by many peers don't actually get evicted easily
<sipa> (with high probability)
<instagibbs> IIRC your idea means nothing would be dropped in non-attack/unusual load scenarios
<sipa> but it doesn't take within-peers relations into account (like one parent orphan with many child orphans... terminology is confusing, how can orphans have parents?)
<sipa> anyway, i don't think any of this is all that important short-term
bytes1440000 has joined #bitcoin-core-dev
<bytes1440000> Banning me wont work. I don't need to explain it. Please get better at your job that you are so arrogant about. Last Pull request that got CVE in 2018 was also reviewed by sipa so..
jespada has joined #bitcoin-core-dev
jespada has quit [Client Quit]
bytes1440000 has quit [Quit: Client closed]
jonatack has quit [Ping timeout: 244 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Excess Flood]
pyth has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
pyth has joined #bitcoin-core-dev
pyth has quit [Remote host closed the connection]
pyth has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/0a931a9787b1...b0869648aa92
<bitcoin-git> bitcoin/master 91ce8ce Pieter Wuille: Add benchmark for MuHash finalization
<bitcoin-git> bitcoin/master a26ce62 Pieter Wuille: Safegcd based modular inverse for Num3072
<bitcoin-git> bitcoin/master f588328 Pieter Wuille: Add a fuzz test for Num3072 multiplication and inversion
<bitcoin-git> [bitcoin] achow101 merged pull request #21590: Safegcd-based modular inverses in MuHash3072 (master...202101_muhash_safegcd) https://github.com/bitcoin/bitcoin/pull/21590
<achow101> sipa: iirc muhash is only used by the coinstats index currently?
<achow101> cause that was a hell of a pr for something rather inconsequential lol
<sipa> achow101: eh, i think at the time I wrote it was is was considered for using for other things too
pyth has quit [Read error: Connection reset by peer]
pyth has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
pyth has quit [Remote host closed the connection]
pyth has joined #bitcoin-core-dev
preimage has quit [Quit: WeeChat 4.5.1]
pyth has quit [Remote host closed the connection]
pyth has joined #bitcoin-core-dev
pyth has quit [Remote host closed the connection]
Guest51 has joined #bitcoin-core-dev
btc_haircomber has joined #bitcoin-core-dev
btc_haircomber has quit [Changing host]
btc_haircomber has joined #bitcoin-core-dev
<btc_haircomber> hello guys
<btc_haircomber> anybody know about natasha otomoski
Guest51 has quit [Quit: Client closed]
btc_haircomber has quit [Quit: Client closed]
Guest40 has joined #bitcoin-core-dev
Guest40 has quit [Client Quit]