bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<fanquake>
I've pushed up a tag for v0.21.2rc1
<fanquake>
Hopefully everyone remembers how to gitian buildd
vasild has quit [Ping timeout: 244 seconds]
<achow101>
\o/
vasild has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
vysn has quit [Remote host closed the connection]
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #22686: wallet: Use GetSelectionAmount in ApproximateBestSubset (master...use-getselectionvalue) https://github.com/bitcoin/bitcoin/pull/22686
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
cold has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 256 seconds]
sipsorcery has joined #bitcoin-core-dev
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
<fanquake>
sipa / wumpus: can you block ljkt7334
sipsorcery has quit [Read error: Connection reset by peer]
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 268 seconds]
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 248 seconds]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kuler has quit [Remote host closed the connection]
<laanwj>
congrats on your first tag fanquake
<_aj_>
#fanquake
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 256 seconds]
belcher_ has joined #bitcoin-core-dev
belcher has quit [Ping timeout: 248 seconds]
kuler has joined #bitcoin-core-dev
belcher_ is now known as belcher
bomb-on has joined #bitcoin-core-dev
b10c has joined #bitcoin-core-dev
bomb-on has quit [Quit: aллилѹіа!]
babasancheti has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
kuler has quit [Remote host closed the connection]
kuler has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
kuler has quit [Remote host closed the connection]
kuler has joined #bitcoin-core-dev
earnestly has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 252 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #22688: contrb: use `keyserver.ubuntu.com` to retrieve builder keys (master...use_ubuntu_keyserver) https://github.com/bitcoin/bitcoin/pull/22688
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<vasild>
What's the preferred way to choose (hopefully) unused ports in the functional tests, in addition to p2p and rpc?
<vasild>
Just hardcoding a seemingly random port and binding to it seems like a bad idea - will collide with something sooner or later.
<darosior>
vasild: bind to 0? The kernel will give you an available port
<vasild>
:-O
<vasild>
I wasn't aware of that
sipsorcery has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
<vasild>
darosior: it is not a generic solution because in many cases we want to tell bitcoind (from tests): "please bind on port 1234" and then we try to connect to 1234 from the tests, so bitcoind would have to bind to 0 and somehow report the port it got. But in my case where I do the bind() from the python testing framework it may work, trying...
AaronvanW has quit [Remote host closed the connection]
<darosior>
It may be a bit racy but in the first scenario you could always do a dummy bind() on the Python side (with SO_REUSEADDR to avoid waiting) to get an available port and pass that to bitcoind. There is very little chance a process on the host machine would decide to bind to this port in the meantime
jonatack has joined #bitcoin-core-dev
<vasild>
darosior: yeah, but that's not necessary as for now I am just looking at the simpler scenario where the listener is the python code
bomb-on has quit [Quit: aллилѹіа!]
<vasild>
darosior: It works! Excellent suggestion, thanks!
lkqwejhhgasdjhgn has joined #bitcoin-core-dev
<laanwj>
we need some standard way in the test framework for tests to request extra ports, i guess
<laanwj>
make sure they're all given out in a similar way to minimize clashes
vasild has quit [Ping timeout: 244 seconds]
prayank has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
belcher has quit [Quit: Leaving]
bomb-on has joined #bitcoin-core-dev
prayank has quit [Ping timeout: 252 seconds]
bitdex has quit [Ping timeout: 244 seconds]
belcher has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
Guest2525 has joined #bitcoin-core-dev
Guest2525 has quit [Client Quit]
<laanwj>
i guess some of the tests (such as the socks proxy one) already need an extra port
<vasild>
laanwj: "make sure they're all given out in a similar way to minimize clashes" -- indeed!
<vasild>
we lack such a way, maybe introduce extra_port(node_number) in addition to p2p_port(node_number) and rpc_port(node_number)
<vasild>
a workaround trick would be to use p2p_port(n) with n > number of nodes used in the test and n < MAX_NODES (12)
<vasild>
e.g. if a test uses 3 nodes, then p2p_port(4) is going to be free
<laanwj>
that might be a good idea, can't think of any issue with that
<laanwj>
though it will be important to comment the intent in the code when doing that, to make future maintainers not scratch their head :)
vysn has joined #bitcoin-core-dev
prayank has quit [Read error: Connection reset by peer]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<shiza>
laanwj: Ah, I was trying to capture the attention on the upcoming 0.21 release notes.
<shiza>
I think there's a new release manager for that, just trying to keep an extra eye.
<luke-jr>
I think #21848 introduces a bug in the case the user has configured a large (>4 GB) mempool with high descendant limits, and spams his mempool with >4 GB of chained transactions
<laanwj>
anything to add/remove, or that is ready for merge?
<jonatack>
i'm going through #21526 commit-by-commit right now. spent some time while my machine was blocked gitian building today to catch up on the context and progress.
<core-meetingbot>
topic: The state of assumeutxo (jamesob)
<jamesob>
many of you are probably familiar with assumeutxo (#15606). I think this is a pretty high-value feature that not only solves some existing problems today (e.g. people offering GPG-signed datadirs to speed bootstrapping in various thirdparty projects, linear-time IBD which isn't scalable), but also promises some interesting optimizations down the road (e.g. parallel n chainstate validation a la utreexo).
<jamesob>
(worth noting that AU has also helped other interesting projects like chainstate deglobalization and so indirectly libbitcoinkernel)
<jamesob>
the draft implementation of this has been under review for almost two and a half years now, and I'm a little concerned with the rate of progress - especially relative to the effort needed to keep the change rebased. At this rate it feels like it'll be another two years before the feature is actually available to end users.
<jamesob>
15606 has recently undergone thorough review by ryanofsky, and subsequently I made a number of improvements based on his feedback. I think the PR is in a pretty good state, with functional tests, scripts, release notes, doc etc. and I'd like to do anything I can to help get it reviewed and merged in a timely way.
<jamesob>
if others could look the PR over I'd be really thankful, and I'm curious if anyone has any good ideas for how we might expedite the process so that assumeutxo isn't in progress for another few years; e.g. should I be doing larger PRs so as to consolidate review/test cycles?
<jonatack>
jamesob: it might be helpful to clarify in the 15606 where 21526 fits in the roadmap
<laanwj>
we should be able to merge feature PRs quicker while we're early in the 23.0 release cycle
<jamesob>
jonatack: sure - 21526 is just the first few commits of 15606; the latter represents the complete set of commits needed to implement assumeutxo
<laanwj>
but I guess it's all bottlenecked by review as usual
<jonatack>
jamesob: i ended up ~figuring it out by going through the various docs
<luke-jr>
I think smaller PRs would go faster, but maybe it's just me
<jonatack>
yes
<laanwj>
there's definitely a compromise there, too small PRs and people get tired of reviewing them if there's no clear forward progress
<jamesob>
luke-jr: that's what I've been trying to do, but smaller PRs seem to take almost a fixed amount of time in overhead, and part of me wonders if it doesn't make sense to amortize review and test
<jamesob>
e.g. the taproot PRs were fairly large and everyone was able to focus review/test on just a few PRs
<laanwj>
but too many changes at once and everyone just puts it off
<laanwj>
yes
<jonatack>
jamesob: istm that there has some ongoing (and good) redesigning too that bubbles back across the changes
<jamesob>
istm?
<jonatack>
it seems to me. so that adds time but if the result is better...
<laanwj>
i agree it's taking very long
<jamesob>
there have certainly been some minor redesigns, but I would say they are essentially marginal refactors done for clarity
<jamesob>
but of course I don't want to merge anything doesn't meet our standards
<jamesob>
I'm just concerned that this has taken 2.5 years and I'm _maybe_ halfway through
<laanwj>
you definitely didn't pick the easiest thing to integrate
<jamesob>
haha, that's fair
<sipa>
yeah, and it's something pretty invasive that many people perhaps aren't very keen on touching
<jonatack>
yes, just been trying to catch up today on the context. progress could very well accelerate at a tipping point of "it's ready" :)
<luke-jr>
I've avoided it because it feels huge, though looking at the current diff maybe not too bad
<sipa>
(by which i don't mean it shouldn't be done - just that reviewers tend to focus on other more shortterm things)
<jamesob>
well hey as long as you guys will write me attestations for sponsors that this thing is worth devoting time to lol
<jamesob>
anyway, thanks for the consideration
<laanwj>
thanks for the update!
<laanwj>
i really hope it won't take another two years
<laanwj>
any other topics for today?
<michaelfolkson>
As laanwj says next few months seems like a good opportunity to make speedier progress as things seem to be quieter
<larryruane>
there's something of a paradox, because when something is well-written (as I suspect this is), people are reluctant to review because they suspect they won't come up with anything to suggest
vasild has quit [Ping timeout: 244 seconds]
<jamesob>
larryruane: I've proposed a number of bugs over the years so that absolutely shouldn't be the case :P
<larryruane>
haha
<michaelfolkson>
Higher up the priority list now (perhaps)
b10c has quit [Quit: Connection closed for inactivity]
vasild has joined #bitcoin-core-dev
<jonatack>
PR 22648 (the I2P doc one) depends in part on the -onlynet bugfix PR 22651, so it's best if that one is merged or postponed first
<jonatack>
so the documentation in 22648 is correct
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[gui] luke-jr opened pull request #404: Fix various edge case bugs in QValidatedLineEdit (master...bugfix_qvalidlineedit) https://github.com/bitcoin-core/gui/pull/404
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]