--- Log opened Thu Dec 05 00:00:09 2024
00:01 -!- aleggg [~aleggg@189.114.82.114] has quit [Ping timeout: 255 seconds]
00:20 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
00:20 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
00:30 < bitcoin-git> [bitcoin] TheCharlatan opened pull request #31425: RFC: Riscv bare metal CI job (master...bare_metal_support) https://github.com/bitcoin/bitcoin/pull/31425
00:37 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
00:37 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
00:41 -!- otoburb [~otoburb@user/otoburb] has quit [Ping timeout: 248 seconds]
00:42 -!- otoburb [~otoburb@user/otoburb] has joined #bitcoin-core-dev
00:42 -!- itsarjn [~itsarjn@user/itsarjn] has quit [Remote host closed the connection]
00:43 -!- itsarjn [~itsarjn@user/itsarjn] has joined #bitcoin-core-dev
00:44 -!- Guyver2 [Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:02 -!- Guyver2 [Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
01:14 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
01:14 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
01:25 -!- sebastianvstaa [~sebastian@dsl-212-100-46-253.pool.bitel.net] has joined #bitcoin-core-dev
01:41 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:42 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
01:45 -!- Flow [~none@gentoo/developer/flow] has quit [Ping timeout: 272 seconds]
01:55 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
01:56 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Client Quit]
02:02 -!- brad_ [~brad@200.68.141.10] has quit [Ping timeout: 260 seconds]
02:05 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
02:05 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
02:11 -!- itsarjn [~itsarjn@user/itsarjn] has quit [Remote host closed the connection]
02:12 -!- itsarjn [~itsarjn@user/itsarjn] has joined #bitcoin-core-dev
02:18 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
02:21 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 248 seconds]
02:37 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
02:37 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
02:41 -!- Zenton_ [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
02:41 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-dev
02:49 -!- Flow [~none@gentoo/developer/flow] has joined #bitcoin-core-dev
02:59 -!- Zenton__ [~Zenton@user/zenton] has quit [Remote host closed the connection]
02:59 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-dev
03:15 -!- Zenton__ [~Zenton@user/zenton] has quit [Remote host closed the connection]
03:15 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-dev
03:27 < bitcoin-git> [bitcoin] willcl-ark opened pull request #31427: lint: bump MLC to v0.19.0 (master...bump-mlc) https://github.com/bitcoin/bitcoin/pull/31427
03:36 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
03:37 -!- Zenton__ [~Zenton@user/zenton] has quit [Ping timeout: 246 seconds]
03:40 -!- chinggg [~chinggg@141.5.46.6] has joined #bitcoin-core-dev
03:45 -!- kevkevin [~kevkevin@2601:243:197e:8f10:3581:7920:80d9:4fec] has joined #bitcoin-core-dev
03:49 -!- kevkevin [~kevkevin@2601:243:197e:8f10:3581:7920:80d9:4fec] has quit [Ping timeout: 260 seconds]
03:53 -!- SpellChecker_ [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
03:56 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Ping timeout: 264 seconds]
04:23 -!- AlHqz [~AlHqz@190.57.84.236] has joined #bitcoin-core-dev
04:24 -!- AlHqz [~AlHqz@190.57.84.236] has quit [Client Quit]
04:28 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
04:28 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
04:36 -!- chinggg [~chinggg@141.5.46.6] has quit [Ping timeout: 240 seconds]
04:41 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
04:49 < bitcoin-git> [bitcoin] glozow pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e8cc790fe2a2...083770adbe7d
04:49 < bitcoin-git> bitcoin/master 0f84cdd Greg Sanders: func: test orphan parent is re-requested from 2nd peer
04:49 < bitcoin-git> bitcoin/master 083770a glozow: Merge bitcoin/bitcoin#31414: test: orphan parent is re-requested from 2nd ...
04:49 < bitcoin-git> [bitcoin] glozow merged pull request #31414: test: orphan parent is re-requested from 2nd peer (master...2024-12-double-request-orphan-parent) https://github.com/bitcoin/bitcoin/pull/31414
04:51 -!- sebastianvstaa [~sebastian@dsl-212-100-46-253.pool.bitel.net] has quit [Quit: Client closed]
05:00 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
05:03 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 272 seconds]
05:07 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9e2:4262:46ee:c0d] has joined #bitcoin-core-dev
05:12 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9e2:4262:46ee:c0d] has quit [Ping timeout: 260 seconds]
05:18 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
05:23 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
05:24 -!- emcy__ [~emcy@148.252.129.219] has joined #bitcoin-core-dev
05:27 -!- mcey_ [~emcy@148.252.146.200] has quit [Ping timeout: 248 seconds]
05:29 -!- greypw14 [~greypw@user/greypw] has quit [Remote host closed the connection]
05:34 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
05:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:45 -!- kevkevin [~kevkevin@2601:243:197e:8f10:80b1:579f:79ae:fda2] has joined #bitcoin-core-dev
05:50 -!- kevkevin [~kevkevin@2601:243:197e:8f10:80b1:579f:79ae:fda2] has quit [Ping timeout: 248 seconds]
05:52 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 276 seconds]
05:56 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
05:57 -!- Emc99 [~Emc99@212.129.73.228] has joined #bitcoin-core-dev
05:59 -!- nymius [~nymius@user/nymius] has joined #bitcoin-core-dev
05:59 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
05:59 -!- nymius [~nymius@user/nymius] has quit [Client Quit]
05:59 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
05:59 -!- nymius [~nymius@user/nymius] has joined #bitcoin-core-dev
06:00 < achow101> #startmeeting
06:00 < b10c> hi
06:00 < 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 maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
06:00 < hodlinator> hi
06:00 < sipa> hi
06:00 < nymius> hi
06:00 < vasild> hi
06:00 < jonatack> hi
06:00 < tdb3> hi
06:00 < brunoerg> hi
06:00 < instagibbs> hi
06:00 -!- sebastianvstaa [~sebastian@212.100.46.253] has joined #bitcoin-core-dev
06:01 < achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add?
06:01 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
06:01 < jarolrod> Hi
06:01 < theStack> hi
06:01 < dergoegge> can we get marcofleon added to the meeting ping list?
06:01 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
06:01 < fjahr> hi
06:01 < marcofleon> hi
06:02 < hebasto> hi
06:02 < achow101> dergoegge: marcofleon: added
06:02 < marcofleon> thanks
06:02 < dergoegge> cheers
06:02 < achow101> For future reference, I just copy-paste from https://github.com/bitcoin-core/bitcoin-devwiki/wiki/IRC-Meeting-Cheat-Sheet which should be editable by everyone in the org
06:03 < dergoegge> ah i see, thanks
06:03 < achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
06:03 < gleb> Hi
06:03 < willcl-ark> hi
06:03 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:04 < gleb> On erlay we currently have a list of design questions we’re discussing in the WG
06:05 < gleb> Im personally spending a bunch of time rebasing the full implementation
06:05 < gleb> Sergi is working on the simulations
06:05 < gleb> That’s it
06:05 < maxedw> hi
06:05 < achow101> #topic Fuzzing WG Update (dergoegge)
06:06 < glozow> hi. sorry i’m late
06:06 < dergoegge> no real update
06:06 < dergoegge> https://github.com/guidovranken/cryptofuzz/ was deleted 1 or 2 weeks ago and i'm not sure how we're gonna replace that wrt fuzzing secp
06:06 < instagibbs> oof
06:07 < achow101> why was it deleted?
06:07 < sipa> we had a student work on writing a libfuzzer-based harness for libsecp256k1 some time ago, which would be able to do more low-level things
06:07 < fanquake> the crypto fuzz maintainer nuked all his repos
06:07 < dergoegge> not entirely sure this is all we know: https://github.com/google/oss-fuzz/pull/12746
06:07 < sipa> it never progressed past being a prototype, but it'd be nice if someone picked it up
06:08 < dergoegge> sipa: cool! i think the cool thing about cryptofuzz was the differential oracle
06:08 < sipa> dergoegge: yeah, i'm aware
06:08 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
06:08 < dergoegge> we have a fork of cryptofuzz (latest commit afaik) but i would assume it's not trivial to maintain 
06:08 < vasild> "In light of the EU Product Liability Directive and other speech criminalizations I am ceasing all my publications including FOSS contributions."
06:08 < furszy> hi
06:09 < achow101> yeesh
06:09 < fanquake> dergoegge: it’s missing my last upstream fix but otherwise up to date yea
06:09 < sipa> some portion of the kinds of things cryptofuzz could catch are also covered by wycheproof
06:09 < fjahr> dergoegge: does it make sense to put it under a core org?
06:10 < fanquake> not unless someone is planning to maintain it
06:10 < fjahr> at least until another, better maintained for emerges
06:10 < fjahr> for someone to start it needs to be available somewhere
06:11 < dergoegge> https://github.com/fanquake/cryptofuzz
06:11 < fjahr> that works
06:11 < cfields> hi
06:11 < dergoegge> fanquake: you're the maintainer now
06:12 < achow101> There appear to be other forks too:https://github.com/google/oss-fuzz/pull/12765#issuecomment-2520199032
06:12 < fanquake> If also suggest that if someone wants to re-add it to oss-fuzz, to bot re-add it to the bitcoin-core project, but keep it separate
06:13 < fanquake> As the majority of our build failures came from crypto-fuzz, but that isn’t needed for core, so would just break out build
06:13 < brunoerg> the MozillaSecurity fork seems active
06:13 < fanquake> So keeping it separate means our fuzzers don’t break when the secp  cryptofuzz build does
06:14 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
06:14 < achow101> it seems like the libsecp folks are looking into it
06:14 < achow101> let's move on
06:14 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
06:14 < sipa> hi
06:15 < sipa> since last meeting i have opened #31363
06:15 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
06:15 < instagibbs> how much work remains to get a glimpse of end to end usage
06:16 < sipa> it implements (part of) the "medium level" layer: sort of a whole-mempool representation of the transaction graph, but very stripped down in functionality (it knows only fees, sizes, dependencies, and represents transactions as abstract handle "Ref" objects, no txids, no ctransaction, ...)
06:17 < sipa> it's tested by a single simulation fuzz test, which compares the behavior of it with a naive reimplementation (mostly) which treats the entire mempool as a single depgraph
06:17 < sipa> instagibbs: you mean in terms of what is left to do at the txgraph level, or what is left for cluster mempool as a whole?
06:17 < instagibbs> latter
06:18 < sipa> so i'm working on extending txgraph to be fully featured (i have some non-pr'ed stuff that is ready already) so it provides enough functionality (specifically, it needs mining/eviction, and a way to deal with reorgs that might otherwise violate policy limits)
06:19 < sipa> after that, i think sdaftuar is planning to rebase #28676 on txgraph
06:19 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
06:19 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:20 < sipa> then there are a few "optimizations" that we'll probably want soon, but aren't blockers for more progress on the mempool side (e.g. reducing memory usage for small clusters in txgraph, and a way to do background relinearization, ...)
06:20 < instagibbs> taking that as Two Weeks, thanks
06:20 < sipa> yeah, (tm)
06:20 < bitcoin-git> [bitcoin] maflcko opened pull request #31428: ci: Allow build dir on CI host (master...2412-ci-build) https://github.com/bitcoin/bitcoin/pull/31428
06:20 < sipa> in either case, 31363 is the thing to review now
06:21 < sipa> based on feedback, i'm happy to split off more parts, split off commits, ... whatever helps
06:22 < sipa> perhaps also an interesting update that won't affect things in the too near future: during bitcoin research week at chaincode, some researchers came up with an idea for how optimal cluster linearization may be doable in polynomial time
06:22 < glozow> sipa: do you think that algo would require a refactor? or could it just be an edit to cluster_linearize.h?
06:22 < sipa> depending on how things evolve there, the approach may end up being too slow to run inside our "relay-time" linearization logic, so it wouldn't really affect our guarantees or cluster size limit
06:23 < instagibbs> sipa interested to learn how th relaxation was shown to be optimal :)
06:23 < glozow> (assuming you want to incorporate it)
06:23 < sipa> but it may mean that a background relinearization can practically linearize everything optimally
06:23 < instagibbs> that's awesome
06:23 < sipa> glozow: it'd be pretty much a drop-in replacement for some code in cluster_linearize.h
06:23 < glozow> awesome! so it could be worked on in parallel
06:24 < sipa> instagibbs: i can give you a quick intuition, but let's do that after the meeting
06:24 < instagibbs> yeah offline
06:24 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
06:24 < sipa> that's it from me, unless sdaftuar still appears and has an update
06:24 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:25 < achow101> #topic MuSig2 WG Update (achow101)
06:25 < achow101> No updates, waiting for further review of #31242 and #31243
06:25 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
06:25 <@gribble`> 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
06:25 < achow101> #topic Legacy Wallet Removal WG Update (achow101)
06:25 < achow101> furszy found a few additional edge cases in migration and opened #31374 and #31378 to handle those. These are the current PRs to review.
06:25 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31374 | wallet: fix crash during watch-only wallet migration by furszy · Pull Request #31374 · bitcoin/bitcoin · GitHub
06:25 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31378 | wallet: fix crash during migration due to invalid multisig descriptors by furszy · Pull Request #31378 · bitcoin/bitcoin · GitHub
06:25 < achow101> #30328 has also gotten some review but is now waiting on 31374 and 31378 as those add tests that we want for 30328
06:25 <@gribble`> https://github.com/bitcoin/bitcoin/issues/30328 | wallet: Remove IsMine from migration code by achow101 · Pull Request #30328 · bitcoin/bitcoin · GitHub
06:26 < achow101> #topic package relay WG Update (glozow)
06:27 < glozow> I've put up the next PR for making orphan resolution more robust by trying with all candidate peers, #31397. It is getting some review (thanks!!). We have a meeting 2h from now in #bitcoin-core-pr-reviews. I'm also happy to do a video call walkthrough if enough people are interested? lmk.
06:27 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31397 | p2p: track and use all potential peers for orphan resolution by glozow · Pull Request #31397 · bitcoin/bitcoin · GitHub
06:27 < glozow> #28031 is rebased, and it includes the next step which would be to make `TxDownloadManager` internally thread-safe
06:27 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28031 | Package Relay 1/3: Introduce TxDownloadManager and improve orphan-handling by glozow · Pull Request #28031 · bitcoin/bitcoin · GitHub
06:28 < glozow> The step after that would be orphanage protection and more thinking around how we can limit per-peer usage of orphanage
06:28 < glozow> Separately, #31385 may be of interest to mempool folks and users. It relaxes the "all unconf parents must be present" requirement for package validation.
06:28 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31385 | package validation: relax the package-not-child-with-unconfirmed-parents rule by glozow · Pull Request #31385 · bitcoin/bitcoin · GitHub
06:28 < sipa> glozow: i'm interested, but i've been quite out of the loop w.r.t. orphan handling... is there a writeup/pr/... that would help to get up to speed?
06:29 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
06:29 < glozow> sipa: I think https://github.com/bitcoin-core/bitcoin-devwiki/wiki/%5BP2P%5D-known-TxOrphanage-problems is the most comprehensive explainer for the problems we are looking at solving
06:29 < sipa> cool will have a look
06:29 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:30 < glozow> We have a (very old and quiet) group chat as a WG for this stuff so anybody feel free to lmk if you want to join.
06:31 < sipa> sure you can add me
06:32 < glozow> Great!
06:32 < glozow> That's it from me I think
06:32 < achow101> Any other topics to discuss?
06:34 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 245 seconds]
06:34 < stevenroose> Does Core allow for changing the 100-block coinbase maturity in regtest? It is 100 blocks in regtest, right?
06:34 < achow101> #endmeeting
06:34 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:35 < stevenroose> Tired of so many years having to scroll by hundreds of getblock logs of my wallets syncing empty blocks in tests ..
06:35 < stevenroose> Ah, sorry to interrupt the meeting (almost)
06:35 < achow101> stevenroose: it's hardcoded
06:35 < sipa> it'd need to be made a consensus parameter
06:35 < jonatack> stevenroose: grep for the COINBASE_MATURITY constant
06:36 < sipa> which is doable i guess, but i'm not sure i see a pressing need
06:36 < jonatack> test/functional/test_framework/blocktools.py:59:COINBASE_MATURITY = 100
06:37 < jonatack> oops sorry, functional tests, different topic
06:37 < instagibbs> sipa ok you can try explaining like I haven't thought about QPs/LPs in like 15 years
06:38 < sipa> instagibbs: yeah!
06:38 < instagibbs> my naive thought would result in an exact MILP, or eps-close LP, but obviously we care about optimal linearizations, so I'll let ya give it a try
06:38 -!- darosior [~darosior@109.205.214.46] has joined #bitcoin-core-dev
06:38 < instagibbs> (and MILP would probably be stupid slow)
06:39 < _aj_> stevenroose: test_framework/test_framework.py has code to generate and cache a 199-block-long chain which makes things faster, though i guess you might still see getblock entries in your logs
06:39 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
06:39 < sipa> so we start with the problem of trying to find the highest-feerate topologically-valid subset (if you can do that repeatedly, you can linearize, just move the highest-feerate subset to the front; *if* an optimal linearization exists, this must find it)
06:39 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
06:40 < sipa> which is: given a number n of transaction with fees (fee_1, fee_2, ..., fee_n) and sizes (size_1, size_2, ..., size_n), and dependencies: (par_1, chl_1), (par_2, chl_2), ...
06:41 < sipa> we're looking for boolean variables x_1, x_2, x_3, such that sum(fee_i * x_i) / sum(size_i * x_i) is maximized (and the denominator is nonzero; zero would mean empty set)
06:41 < sipa> and the constraint that for every (par_i, chl_i) pair, (x_{chl_i} => x_{par_i})
06:42 < sipa> sounds right?
06:42 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
06:42 < _aj_> ("=>" -- implies, not greater-or-equal?)
06:42 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
06:42 < sipa> _aj_: yeah, just taking x_i to be booleans, so => is implication
06:42 < instagibbs> ah, ok yeah
06:42 < instagibbs> think im tracking
06:43 < sipa> but (x_{par_i} >= x_{chl_i}) would be equivalent if you think of booleans as {0, 1} integers
06:44 < sipa> and as you already know, the first step is relaxing the domain of the x_i variables to be real non-negative numbers instead
06:44 < instagibbs> mhmm
06:44 < stevenroose> _aj_: yeah wallets will still parse them all to sync.
06:44 < stevenroose> But thanks :)
06:45 < sipa> it's clear that multiplying all x_i's by the same constant won't change the solution, but it's perhaps less clear that allowed *distinct* real numbers for each of the x_i (not all exactly 1.0) won't introduce solutions to the problem that don'
06:45 -!- Emc99 [~Emc99@212.129.73.228] has quit [Ping timeout: 240 seconds]
06:45 < sipa> 't actually correspond to solutions of the optimal subset problem
06:45 < sipa> i'll get back to that, ok?
06:45 < stevenroose> sipa: yeah wouldn't want to mess with consensus parameters for this case. though there's so many other ones, that was my main question of it was one or not. thanks
06:45 < _aj_> stevenroose: use one wallet for mining and a different one for testing, and compact block filters so the wallets only look at relevant blocks?
06:46 < stevenroose> I'm talking about other wallets like BDK. If they don't support birthdays (or the granularity of the birthday support is not block based but rough time based) it will still sync the entire regtest chain.
06:47 < sipa> instagibbs: with me so far?
06:47 < _aj_> stevenroose: backdate the blocks on regtest, mine a few at current time, and time based birthdays shoud be fine?
06:48 < instagibbs> sipa think so! one step of the optimization we already do, how do bool relaxed get optimal results, you will tell me
06:48 < sipa> ok, one more step before we arrive at the LP problem
06:48 < stevenroose> _aj_: interesting suggestions :)
06:49 < sipa> because scaling all x_i by the same constant doesn't change the solution, we can choose a normalization constraint that (arbitrarily) picks one scaling for them
06:49 < stevenroose> _aj_: we use bdk and afaik it doesn't support birthdays yet
06:49 < stevenroose> I can just settle to love with the noise for another few years.
06:50 < sipa> and the key insight is that the normalization constaint can be: set the denominator of the goal to 1 (sum(x_i * size_i) = 1), because it makes the goal function (the only part of the problem that's nonlinear) linear
06:51 < sipa> it could also be something else, as long as it's linear; e.g. (sum(x_i * size_i) = sum(size_i)) which can be simplified to sum((x_i - 1) * size_i) = 0, for example... doesn't matter; but we'll continue with sum(x_i * size_i) = 1
06:51 < sipa> alright?
06:52 < instagibbs> this step will take me a minute
06:52 < stevenroose> Also, achow101, is it normal that the wallet is pretty slow? https://nitter.poast.org/stevenroose3/status/1864675671143743942 
06:53 < sipa> observe that multiplying all x_i by say 2 doesn't change (a) the validity of any constraint and (b) doesn't change the goal function (numerator and denominator both double)
06:53 < stevenroose> Colleague tells me it takes over 15 seconds on his machine to generate 100 blocks and I couldn't believe it. It took 5 secs on my beefy workstation as well. 
06:54 < _aj_> stevenroose: bdk apparently supports compact block filters though https://bitcoindevkit.org/blog/compact-filters-demo/
06:55 < sipa> so if we for example just said sum(x_i) = 1, nothing really changes - among all solutions which only differ by an (identical) scaling of all x_i values, it just picks one of them
06:55 < instagibbs> ah wait, the original formulation isn't a LP(or QP or whatever) at all yet, so you're working on turning it into one?
06:55 < instagibbs> im backtracking sorry lol
06:55 < sipa> indeed
06:55 < instagibbs> ho ho ho ok re-reading a third time
06:55 < sipa> 🎅
06:56 < achow101> stevenroose: try having a smaller wallet
06:56 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
06:56 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
06:57 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
06:57 < sipa> instagibbs: sorry, maybe i started too far back and should just have jumped to showing how the LP problem matches optimal sets
06:58 < sipa> but maybe there are other people reading along who don't yet know what the LP formulation is
06:58 < instagibbs> how do you set the denominator to a value without solving the LP, clearly missing something heh
06:59 < stevenroose> achow101: it's empty. they're regtests wallet on an empty chain. just that all of them spam all the rpc interactions for the 100+ (104 generally) block we have to generate to get some coin. I miss elements' initialfreecoin :D 
06:59 < instagibbs> maybe the final LP will be illuminating yeah
06:59 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-dev
06:59 < sipa> instagibbs: we literally just add a constraint to the problem: sum(size_i * x_i) = 1
06:59 < instagibbs> ok, so this by itself isn't turning it into an LP, you're just stating the constraint
06:59 < instagibbs> ?
06:59 < sipa> adding that constraint doesn't affect the solution space, because all it does is pick among every set of equivalent solutions, one canonical one
06:59 < sipa> indeed
06:59 < sipa> you agree with that?
06:59 < instagibbs> got it, I keep jumping ahead it seems yes
07:00 < sipa> ok!
07:00 < instagibbs> are we an LP yet are we an LP yet etc
07:00 < sipa> last step: we can replace the goal function from max sum(fee_i * x_i)/sum(size_i * x_i) to just max sum(fee_i * xi)
07:00 -!- Zenton__ [~Zenton@user/zenton] has quit [Remote host closed the connection]
07:00 < sipa> because we *know* the denominator is 1 (that's a constraint of the problem, which we leave in place)
07:00 < instagibbs> mmmmmm
07:01 < _aj_> (VCs are going to be so excited that bitcoin-core-dev is finally focussed on LPs)
07:01 -!- Zenton_ [~Zenton@user/zenton] has quit [Ping timeout: 248 seconds]
07:01 < sipa> haha
07:02 < sipa> like, clearly dividing by something we know equals 1 doesn't change the result
07:02 < instagibbs> I'm persuaded
07:02 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
07:02 < instagibbs> yeah that's teh trick I was missing
07:02 < instagibbs> shove it in as a linear constraint
07:02 < bitcoin-git> [bitcoin] hebasto opened pull request #31429: cmake: Support user-defined C++ standard (master...241205-standard) https://github.com/bitcoin/bitcoin/pull/31429
07:02 < sipa> we did of course skip one part: showing that the relaxation to real numbers doesn't introduce *additional* solutions to the problem which are *more* optimal, but don't correspond to our real problem
07:03 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
07:04 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
07:04 < instagibbs> 👍
07:04 < sipa> to convince you that we didn't, i'm going to show you that *every* solution the LP problem (optimal and non-optimal) corresponds to a convex combination (a linear combination, where all coefficients are being 0 and 1, and which sum up to 1) of topologically-valid subsets... and thus that the goal function applies to them will also be a convex combination of those subset's feerates, which thus 
07:04 < sipa> cannot possibly be more than the highest feerate of any of them
07:05 < sipa> when i say "convex combination" you can also think "weighted average"
07:05 < sipa> which can't be more than the maximum of any of the values being averaged
07:06 < sipa> ok
07:07 < sipa> let's say T_1, T_2, T_3, ..., T_m are the non-empty topologically valid subsets of our graph (in the real problem space, not the LP one)... there are clearly only a finite number of them as the graph is finite, but it could be exponential
07:08 < sipa> and call v_1, v_2, v_3, ..., v_m the corresponding LP solutions: v_k is the vector of (x_1, x_2, ..., x_n) where x_i=0 if i is not in T_i, and x_i=1/sum(size_j for j in T_k) if i is in T_i
07:09 < sipa> so that's just the vector of the boolean solutions, but rescaled so that sum(x_i * size_i)=1 holds
07:10 < sipa> so all the v_k are solutions to the LP problem... not necessarily the only ones, but just the ones that correspond to a single topologically-valid set
07:11 -!- Guest48 [~Guest48@outit03.fbk.eu] has joined #bitcoin-core-dev
07:11 < sipa> sorry this part is slightly technical and maybe not that easy to convey over text, but i promise it gets better
07:12 < _aj_> every valid solution to the LP problem would correspond with one of those v_k's in some sense -- they'd have all the same x_i=0 values, but some of the non-zero x_i's might have different values, no?
07:12 < instagibbs> to retread a bit, your contention is that any solution that has x_i as 0 implies exclusion, and any non-0 x_i inclusion?
07:12 < instagibbs> or am I jumping ahead again
07:12 < sipa> yeah :)
07:13 < sipa> look at the set of all possible LP solutions (optimal and non-optimal)
07:13 < instagibbs> ok, not convinced, but I can understand the words separately :P
07:13 < sipa> do you agree that the v_k vectors i've given you are all part of that set?
07:13 -!- Guest48 [~Guest48@outit03.fbk.eu] has quit [Client Quit]
07:13 < sipa> so every v_k consists of 0s and all-identical nonzeros
07:14 < sipa> they cannot have distinct non-zero values
07:14 < instagibbs> I can stipulate because you're saying it's true haha, this part might need full writeup and me staring at it
07:15 < sipa> say you have a graph {A,B,C} and B depends on C, so our T's are: T_1={A}, T_2={C}, T_3={B,C}, T_4={A,C}, T_5={A,B,C}
07:15 < sipa> all the same size
07:15 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
07:16 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
07:16 < sipa> then the v's are: v_1=(1,0,0), v_2=(0,0,1), v_3=(0,1/2,1/2), v_4=(1/2,0,1/2), v_5=(1/3,1/3,1/3)
07:16 < sipa> do you see that these are all solutions of the LP problem?
07:16 < instagibbs> C depends on B* I presume
07:17 < instagibbs> or no
07:17 < sipa> B depends on C
07:17 < sipa> i'm never including B without also include C, but C can appear on its own
07:17 < _aj_> instagibbs: (he defined them to have all-identitcal nonzeros, x_i=1/divisor; and that satisfies all the constraints. since he defined them that way, they "cannot" have different values...)
07:18 < sipa> all i'm asking is: do you agree these are solutions to the LP problem
07:18 < sipa> i'm not asking to see that the optimal one is among them
07:18 < sipa> nor am i asking to see that they're the only solutions to the LP problem (which wouldn't be true, but that's jumping ahead)
07:18 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
07:19 < instagibbs> probably yeah
07:19 < sipa> B depends on C, so one of the constraints is x_3 >= x_2, which is true for all of them
07:19 < instagibbs> I can re-read the argument later to fully convince, continue
07:20 < sipa> and the normalized constraint holds because all sizes are one so it's just sum(x_i)=1
07:20 < sipa> etc
07:20 < sipa> ok, for each of these v_k solutions, the goal function g(v) = sum(fee_i*v_i) equals the feerate of the corresponding T_k
07:21 < sipa> i should write g(x) = sum(fee_i*x_i), sorry for variable switch
07:21 < sipa> and each v_k is one possible x
07:24 < sipa> or put otherwise: among all these v_k's (and excluding any other LP solutions, which might be even better) the optimal one is the one corresponding to the highest-feerate topologically-valid subset (in the real problem)
07:24 < instagibbs> huh ok
07:25 < sipa> like these v_k's are just the corresponding solutions to the boolean problem we started with, but rescaled so that the sum(x_i size_i) = 1 constraint holds
07:25 < sipa> and we know rescaling doesn't change feerate
07:25 < instagibbs> claim seems clear, thanks
07:25 < sipa> OKAY
07:26 < sipa> the next step is showing that *every* LP solution can be written as a weighted average of one or more of these v_k's
07:27 < sipa> because of linearity, if that is true, then the goal function sum(fee_i * x_i) in each LP solution is also a weighted average of the goal function of some of these v_k's, which cannot exceed the feerate of the highest topologically-valid subset of the graph
07:27 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has joined #bitcoin-core-dev
07:28 < sipa> that's jumping ahead, i haven't shown that every LP is a weighted average of v_k's yet, but do you see that if that's the case, we are done?
07:30 < instagibbs> sure
07:30 < sipa> okay
07:30 < sipa> given a solution x to the LP problem (any solution, optimal or not), which is a vector with components (x_1, x_2, ..., x_n)
07:30 < sipa> find the smallest nonzero x_i
07:31 < sipa> call that alpha
07:32 < sipa> observe that the set of nonzero x_i's must be topological: if a child x_i is included, the parent x_j must be nonzero too
07:32 < sipa> so this set of nonzero x_i's must correspond to some T_k, which has a correspond v_k, which we can subtract from x
07:33 < sipa> sorry, alpha is the ratio between the smallest nonzero x_i and the nonzero values in v_k
07:34 -!- Murch[m] [~murch@user/murch] has changed host
07:34 < sipa> so x' = x - alpha*v_k is nonnegative still, and also still topological (parents are higher than children, we've subtractedf the same amount from all parents and children, so parents are still higher than children)
07:35 < sipa> so we can keep repeating this... find the set of nonzero values in x', find the corresponding v_k, subtract a multiple of v_k from it, and continue until the whole x is 0
07:36 < sipa> every time we've subtracted a non-negative multiple of a v_k
07:37 < _aj_> x' is no longer an LP solution because it violates the sum(x'_i*size_i) = 1 constraint?
07:37 < sipa> _aj_: correct!
07:37 < sipa> it's a solution to the LP problem if you ignore the normalization constraint, though
07:38 < _aj_> so eg if i had (2/5, 1/5, 2/5) then B is the smallest; non-zeroes correspond to (1/3,1/3,1/3) in v_5, scale and subtract gives me (1/5,0,1/5), which matches v_4
07:38 -!- nymius [~nymius@user/nymius] has quit [Quit: nymius]
07:38 < sipa> exactly
07:39 < sipa> and the first alpha would be 3/5, the second alpha would be 2/5
07:40 < sipa> which form the coefficients of the weighted average
07:40 < sipa> i guess i don't really have a super tight argument why the alphas sum up to 1, but they have to
07:42 < instagibbs> _aj_ thanks for the example, was helpful
07:43 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
07:43 < _aj_> sipa: consider the highest value initially (either of the 2/5), it's reduced in each step, until it's eventually zero; i think that forces it to end up at 1? i don't have my head around the alphas though
07:44 < vasild> (lldb) p ~((unsigned)0)
07:44 < vasild> (unsigned int) 4294967295
07:44 < sipa> _aj_: the highest value is not necessarily reduced in every step
07:44 < vasild> as expected, but what is this:
07:44 < vasild> (lldb) p ~((unsigned short)0)
07:44 < vasild> (int) -1
07:44 < _aj_> sipa: huh?
07:45 < sipa> vasild: integer promotion; any operand argument smaller than int gets converted to int
07:45 < vasild> Why not 65535?
07:45 < sipa> vasild: the most nonsensical feature in C and C++, probably
07:46 < sipa> _aj_: oh, wait, yes!
07:46 < vasild> probably this is the reason for https://api.cirrus-ci.com/v1/task/5685829642747904/logs/ci.log 
07:46 < vasild> [01:27:57.782] /ci_container_base/src/util/bitset.h:369:34: runtime error: implicit conversion from type 'int' of value -1 (32-bit, signed) to type 'value_type' (aka 'unsigned short') changed the value to 65535 (16-bit, unsigned)
07:47 < vasild> unsigned short variable = ~I{0}; // where I is unsigned short
07:47 < sipa> vasild: https://en.cppreference.com/w/c/language/conversion:
07:47 < sipa> Integer promotion is the implicit conversion of a value of any integer type with rank less or equal to rank of int or of a bit-field of type _Bool(until C23)bool(since C23), int, signed int, unsigned int, to the value of type int or unsigned int.
07:47 < sipa> If int can represent the entire range of values of the original type (or the range of values of the original bit-field), the value is converted to type int. Otherwise the value is converted to unsigned int. 
07:48 < vasild> sipa: do you mind if I change that ~I{0} in bitset.h to std::numeric_limits<I>::max()?
07:48 < instagibbs> ok, so it cannot *exceed*, but since it's a relaxation, it cannot *underperform*?
07:48 < sipa> vasild: i'd prefer I(~I{0})
07:49 < vasild> ok, will PR it shortly to fix the fuzz CI (not sure why it failed now or whether it failed before)
07:49 < _aj_> what's the "relaxation"?
07:49 < sipa> instagibbs: all we're trying to get to is that every LP solution x can be written as sum(alpha_k * v_k), where all alphas are non-negative, and sum up to 1
07:49 < _aj_> from bools to reals?
07:50 < sipa> and if that's the case, then every LP's solution's goal function cannot exceed the highest-feerate topological subset, because the goal function on the v_k's cannot exceed that
07:50 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.4.4]
07:50 < sipa> and thus, the relaxation of allowing non-negative real x_i instead of booleans doesn't introduce any solutions that are *even better* than the highest-feerate topologically-valid subset one
07:52 < instagibbs> I was zooming out a bit to restate that LP relaxations theoretically do not result in worse objective values
07:52 < instagibbs> sorry if too obvious...
07:52 < dergoegge> vasild: i ran into the same issue on an early draft of #31093 (https://github.com/bitcoin/bitcoin/pull/31093#issuecomment-2416333030)
07:52 < dergoegge> and i fixed it with "I(~I{0})"
07:52 < dergoegge> in my case it was triggered by replacing the Assumes with asserts, and my guess was it had something to do with compiler optimizations (which might also be the case for you with the additional std library flags...)
07:52 <@gribble`> https://github.com/bitcoin/bitcoin/issues/31093 | Introduce `g_fuzzing` global for fuzzing checks by dergoegge · Pull Request #31093 · bitcoin/bitcoin · GitHub
07:52 < _aj_> (no such thing as too obvious)
07:52 < sipa> instagibbs: that's indeed what we're trying to get to
07:53 < vasild> dergoegge: sounds feasible, but then I could reproduce locally on master without extra hardening flags, probably clang 20 (which I use locally) makes a difference
07:53 < sipa> vasild: i would also be ok with a suppression, because this isn't UB
07:54 < _aj_> sipa: that's a nice argument, much more constructive than i was thinking/expecting ("if they're unequal, some value is higher, which if it's a child vs a parent is invalid; if it's a parent vs a child, should drop the child to zero, blahblahhandwave")
07:54 -!- itsarjn [~itsarjn@user/itsarjn] has quit [Remote host closed the connection]
07:55 -!- lucasbalieiro [~lucasbali@187.99.228.77] has joined #bitcoin-core-dev
07:55 < sipa> instagibbs, _aj_: maybe an argument for why the alphas sum up to one: if instead of just subtracting alpha*v_k, you rescale: x' = (x - alpha*v_k) / (1 - alpha), you get an actual LP solution after every step
07:55 < sipa> and then you need not sum of alphas, but sum of partial products of alphas is 1
07:55 < instagibbs> sipa having trouble framing my point better, but I've convinced myself that trivially a relaxation cannot do what I was thinking of, excluding numerical fun
07:56 < sipa> _aj_: yeah, that's basically dongning's argument
07:56 < sipa> i found mine more constructive, but they're probably equivalent in some sense
07:56 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
07:58 < sipa> _aj_: but to be clear, it *is* possible that the optimal LP solution consists of unique x_i's; however, this will imply it's a weighted average between distinct solutions, each of which corresponds to an optimal feerate topologically-valid subset, so the overall set of nonzero element is still optimal and topological
07:58 < sipa> e.g. A=2/1, B=2/1, C=1/1, A and B both depend on C
07:59 < sipa> it's possible your solution is a weighted average between (1/2,0,1/2) and (0,1/2,1/2), both of which are optimal-feerate topologically-valid subsets
07:59 < sipa> uhhhh
07:59 < sipa> i just realized this examples disproves me
08:00 < sipa> oh, no!
08:00 < sipa> {A,B,C} is actually better than {A,C} and {B,C}, this is a bad example, sorry
08:00 -!- sebastianvstaa [~sebastian@212.100.46.253] has quit [Quit: Client closed]
08:01 < sipa> say the super simple example: {A,B}, no dependencies, both have fee and size 1
08:01 < bitcoin-git> [bitcoin] vasild opened pull request #31431: util: use explicit cast in MultiIntBitSet::Fill() (master...fuzz_bitset_silence_warning) https://github.com/bitcoin/bitcoin/pull/31431
08:02 < sipa> the v_ks are all optimal: (1,0), (0,1), and (1/2,1/2)... but it *is* possible that the optimal LP solution is say (1/3,2/3), which is a non-equal weighted average between (1,0) and (0,1)
08:02 < sipa> but that's fine because the set of nonzero elements is {A,B}, which is still a solution
08:03 < _aj_> for (1/3, 2/3) i'd be tempted to follow your proof approach and take the last set (0,1/3) as the LP's recommendation to try to get something smaller. doesn't help if the LP recommends (1/2, 1/2) though.
08:04 < sipa> since we want *minimal-size* highest-feerate topologically-valid subsets, you probably want the set of all the highest values, rather than just the nonzero ones
08:05 < sipa> and even that isn't enough, because of the (1/2,1/2) example... which can be improved by doing connected-component analysis on the solution
08:05 < sipa> sadly, even that is not enough, because the two sets which were (by a remarkable coincidence) exactly equally mixed could be dependent on one another
08:06 < sipa> if you want to fix even that, you need to do trial removals "can i forcibly set this x_i to 0, and find an equally-good solution?" for every nonzero x_i
08:08 < _aj_> could do it for the non-parents (of nonzero x_i's) only and get a first pass answer
08:09 < _aj_> i feel like the other cluster mempooly techniques will probably already deal with that in most cases too
08:09 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
08:09 < _aj_> though in most cases you probably don't have exact equality anyway, so...
08:09 < sipa> yeah
08:10 < sipa> i wonder if postlinearization + chunking doesn't suffice
08:10 < _aj_> there's probably some edge case where it doesn't
08:10 < sipa> probably
08:11 < _aj_> does suhas or someone have some super complicated cluster examples to throw at an LP implementation?
08:11 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 248 seconds]
08:11 < sipa> he's working on a fuzzer that tests things through an LP-solving library
08:18 < _aj_> (oh, the alphas sum to one via scaling thing i like. you can argue that each step is taking a weighted average between two valid solutions, so if your original was the best, it must equal both the things you're averaging at each step, afaics)
08:19 -!- Zenton_ [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
08:19 -!- __DuBPiRaTe__ [~E_bomb@2600:6c50:7f7f:d89a:bc1a:df18:b7c7:a7b5] has joined #bitcoin-core-dev
08:19 -!- lucasbalieiro [~lucasbali@187.99.228.77] has quit [Ping timeout: 252 seconds]
08:19 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
08:19 < sipa> yup
08:19 < sipa> that's a nice way of explaining it
08:19 < _aj_> (so your original combined solution is equally good as the final v_k you ended up with that has equal weighting for all the elements that had the highest x_i values)
08:24 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
08:24 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
08:31 -!- gribble` is now known as gribble
08:32 < sipa> huh, this makes it much easier: https://en.wikipedia.org/wiki/Linear-fractional_programming
08:32 < sipa> one can generally convert a LFP problem (like LP, but the goal is the ratio of two linear expressions) to an LP problem
08:33 < sipa> so i think we can instead just reason about solutions to the LFP formulation
08:34 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/083770adbe7d...6a1e613e853d
08:34 < bitcoin-git> bitcoin/master 811a65d willcl-ark: lint: bump MLC to v0.19.0
08:34 < bitcoin-git> bitcoin/master f6afca4 willcl-ark: lint: use clearer wording on error message
08:34 < bitcoin-git> bitcoin/master 6a1e613 merge-script: Merge bitcoin/bitcoin#31427: lint: bump MLC to v0.19.0
08:34 < bitcoin-git> [bitcoin] fanquake merged pull request #31427: lint: bump MLC to v0.19.0 (master...bump-mlc) https://github.com/bitcoin/bitcoin/pull/31427
08:41 -!- sebastianvstaa [~sebastian@212.100.46.253] has joined #bitcoin-core-dev
08:46 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has joined #bitcoin-core-dev
08:47 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:48 -!- itsarjn [~itsarjn@user/itsarjn] has joined #bitcoin-core-dev
08:48 < sipa> because then you don't need the alphas to add up to 1
08:57 -!- Zenton__ [~Zenton@user/zenton] has joined #bitcoin-core-dev
08:57 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
08:59 -!- Zenton_ [~Zenton@user/zenton] has quit [Ping timeout: 246 seconds]
08:59 -!- Emc99 [~Emc99@212.129.73.228] has joined #bitcoin-core-dev
09:01 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-dev
09:11 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has quit [Ping timeout: 252 seconds]
09:17 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6a1e613e853d...6d973f86f755
09:17 < bitcoin-git> bitcoin/master cccca8a MarcoFalke: test: Avoid logging error when logging error
09:17 < bitcoin-git> bitcoin/master 6d973f8 merge-script: Merge bitcoin/bitcoin#31408: test: Avoid logging error when logging error
09:17 < bitcoin-git> [bitcoin] fanquake merged pull request #31408: test: Avoid logging error when logging error (master...2412-test-log-err) https://github.com/bitcoin/bitcoin/pull/31408
09:20 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
09:21 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:31 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has quit [Quit: Client closed]
09:31 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has joined #bitcoin-core-dev
09:35 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
09:36 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
09:38 -!- Zenton__ [~Zenton@user/zenton] has quit [Ping timeout: 248 seconds]
09:49 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
09:53 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
10:01 -!- Emc99 [~Emc99@212.129.73.228] has quit [Quit: Client closed]
10:02 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit []
10:05 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
10:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:22 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
10:25 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
10:26 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
10:27 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
10:38 -!- Guest89 [~Guest89@2a0a:ef40:db:2e01:794b:c586:7f44:b19d] has joined #bitcoin-core-dev
10:38 -!- Guest89 [~Guest89@2a0a:ef40:db:2e01:794b:c586:7f44:b19d] has quit [Client Quit]
10:55 -!- Zenton [~Zenton@user/zenton] has quit [Remote host closed the connection]
10:55 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
10:55 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
11:04 -!- Zenton [~Zenton@user/zenton] has quit [Read error: Connection reset by peer]
11:05 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
11:09 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
11:10 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
11:11 -!- Zenton [~Zenton@user/zenton] has quit [Ping timeout: 248 seconds]
11:16 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
11:20 -!- chinggg [~chinggg@cspsrv00-ext.mpi-sp.org] has quit [Ping timeout: 240 seconds]
11:33 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
11:38 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
11:44 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
11:49 -!- darosior [~darosior@109.205.214.46] has quit [Ping timeout: 252 seconds]
11:50 -!- darosior [~darosior@109.205.214.46] has joined #bitcoin-core-dev
11:54 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
12:05 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
12:06 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
12:09 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
12:15 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 276 seconds]
12:22 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
12:25 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
12:26 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
12:28 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
12:31 -!- itsarjn [~itsarjn@user/itsarjn] has quit [Remote host closed the connection]
12:33 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
12:45 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
12:47 < bitcoin-git> [bitcoin] ryanofsky pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6d973f86f755...2eccb8bc5e22
12:47 < bitcoin-git> bitcoin/master f42ec0f Ava Chow: wallet: Check specified wallet exists before migration
12:47 < bitcoin-git> bitcoin/master 55347a5 Ava Chow: test: Rework migratewallet to use previous release (v28.0)
12:47 < bitcoin-git> bitcoin/master 2eccb8b Ryan Ofsky: Merge bitcoin/bitcoin#31248: test: Rework wallet_migration.py to use previ...
12:48 < bitcoin-git> [bitcoin] ryanofsky merged pull request #31248: test: Rework wallet_migration.py to use previous releases (master...migratewallet-prev-rels) https://github.com/bitcoin/bitcoin/pull/31248
12:49 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
12:51 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
12:52 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
13:09 < achow101> 28.1rc1 bins posted
13:11 -!- sebastianvstaa [~sebastian@212.100.46.253] has quit [Ping timeout: 240 seconds]
13:13 < dviola> the qt 5.x issue that I mentioned sometime back has been fixed by this commit apparently: https://invent.kde.org/qt/qt/qtbase/-/commit/2529f7f0c2333d437089c775c9c30f624d1fd5bc
13:14 < dviola> the one where fonts were getting vanished after turning my monitor off/on
13:27 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
13:28 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has quit [Remote host closed the connection]
13:29 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
13:53 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
13:58 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 265 seconds]
14:32 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.4.4]
14:37 -!- tinova4 [~tinova@217.160.209.135] has quit [Quit: Ping timeout (120 seconds)]
14:37 -!- tinova4 [~tinova@217.160.209.135] has joined #bitcoin-core-dev
14:44 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:03 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
15:04 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
15:08 < bitcoin-git> [bitcoin] hodlinator opened pull request #31433: test: #31212 follow up (spelling, refactor) (master...2024/12/31212_follow_up) https://github.com/bitcoin/bitcoin/pull/31433
15:09 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 255 seconds]
15:17 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has joined #bitcoin-core-dev
15:26 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has quit [Ping timeout: 276 seconds]
15:54 -!- twistedline [~bitcoin@185.193.125.44] has quit []
15:59 -!- twistedline [~bitcoin@185.193.125.44] has joined #bitcoin-core-dev
16:17 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
16:28 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
16:29 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
16:31 < stevenroose> achow101: https://gist.github.com/stevenroose/a7b2b0aab4b80af08a935cf6cbf32d29
16:31 < stevenroose> That -unsafesqlitesync changes everything, pretty crazy. Is that a known thing, or are we on a bad sqlite version or so?
16:34 -!- Zenton_ [~Zenton@user/zenton] has quit [Ping timeout: 252 seconds]
16:56 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
17:01 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
17:03 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has joined #bitcoin-core-dev
17:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 264 seconds]
17:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-dev
17:11 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has joined #bitcoin-core-dev
17:12 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Ping timeout: 245 seconds]
17:13 -!- kanzure [~kanzure@user/kanzure] has quit [Ping timeout: 245 seconds]
17:15 -!- kanzure [~kanzure@user/kanzure] has joined #bitcoin-core-dev
17:25 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-dev
17:41 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
17:49 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has quit [Remote host closed the connection]
17:50 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has joined #bitcoin-core-dev
17:56 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has quit [Ping timeout: 260 seconds]
18:03 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
18:07 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 265 seconds]
18:19 -!- __DuBPiRaTe__ [~E_bomb@2600:6c50:7f7f:d89a:bc1a:df18:b7c7:a7b5] has quit [Remote host closed the connection]
18:22 < achow101> stevenroose: it's known, our test framework uses that too
18:36 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has joined #bitcoin-core-dev
18:39 -!- Zenton [~Zenton@user/zenton] has joined #bitcoin-core-dev
18:43 -!- kevkevin [~kevkevin@c-73-111-168-5.hsd1.il.comcast.net] has quit [Ping timeout: 246 seconds]
18:54 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:11 -!- Netsplit *.net <-> *.split quits: ghost43, kanzure, MyNetAz, bitdex, adiabat_, SpellChecker_, saturday-, johnzweng, theStack, sdaftuar,  (+2 more, use /NETSPLIT to show all of them)
19:12 -!- Netsplit *.net <-> *.split quits: jonatack, kerm|t, jeremyrubin, jespada, maxedw, dviola, amiti___, jesseposner, da2ce7, cold,  (+133 more, use /NETSPLIT to show all of them)
19:12 -!- Artea [~Lufia@artea.pt] has quit [Max SendQ exceeded]
19:13 -!- dodo [~dodo@user/dodo] has quit [Quit: dodo]
19:19 -!- gnusha [~gnusha@user/gnusha] has joined #bitcoin-core-dev
19:19 -!- Topic for #bitcoin-core-dev: 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 @ 14:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:19 -!- Topic set by achow101 [] [Thu May 25 07:25:40 2023]
19:19 -!- Irssi: #bitcoin-core-dev: Total of 159 nicks [2 ops, 0 halfops, 0 voices, 157 normal]
19:19 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
19:19 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has joined #bitcoin-core-dev
19:19 -!- b10c [~quassel@user/b10c] has changed host
19:20 -!- freesprung512697 [~freesprun@user/freesprung] has joined #bitcoin-core-dev
19:20 -!- Channel #bitcoin-core-dev created Wed May 19 06:52:47 2021
19:20 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
19:20 -!- katsu [~0x0ff@user/0x0ff/x-0302470] has joined #bitcoin-core-dev
19:22 -!- Irssi: Join to #bitcoin-core-dev was synced in 143 secs
19:34 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 264 seconds]
19:34 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
19:36 -!- Artea [~Lufia@artea.pt] has joined #bitcoin-core-dev
20:21 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
20:26 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
20:28 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
20:41 -!- itsarjn [~itsarjn@user/itsarjn] has joined #bitcoin-core-dev
20:53 -!- Guest13 [~Guest13@2601:602:8d83:6220:6c9e:675d:a209:d2e9] has joined #bitcoin-core-dev
20:54 -!- Guest13 [~Guest13@2601:602:8d83:6220:6c9e:675d:a209:d2e9] has quit [Client Quit]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:15 -!- Talkless [~Talkless@mail.dargis.net] has quit [Remote host closed the connection]
21:17 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has quit [Remote host closed the connection]
21:19 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has joined #bitcoin-core-dev
21:22 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has quit [Remote host closed the connection]
21:22 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has joined #bitcoin-core-dev
21:23 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has quit [Remote host closed the connection]
21:24 -!- eval-exec [~Thunderbi@107.182.187.217.16clouds.com] has joined #bitcoin-core-dev
21:28 -!- Guest25 [~Guest25@2409:40c2:11a:1be8:ccfe:1eff:fec0:74bd] has joined #bitcoin-core-dev
21:29 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
21:29 -!- Guest25 [~Guest25@2409:40c2:11a:1be8:ccfe:1eff:fec0:74bd] has quit [Client Quit]
21:33 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has joined #bitcoin-core-dev
21:34 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
21:37 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has quit [Ping timeout: 246 seconds]
22:01 -!- mcey [~emcy@148.252.129.219] has joined #bitcoin-core-dev
22:02 -!- emcy__ [~emcy@148.252.129.219] has quit [Remote host closed the connection]
22:07 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
22:09 -!- ioannis [ion-@user/ion-] has quit [Remote host closed the connection]
22:26 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
22:30 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 260 seconds]
22:37 < dviola> ehh.. not really, doesn't look like the bug is fixed, was just not easily reproducible
22:47 -!- robobub [uid248673@id-248673.uxbridge.irccloud.com] has joined #bitcoin-core-dev
23:03 -!- zzz123 [~zzz123@user/zzz123] has joined #bitcoin-core-dev
23:09 < zzz123> https://github.com/visualbasic6/drain/blob/main/drain-btc.py#L110
23:10 < zzz123> it isn't normal/correct/fair to withhold credit re: block header range spamming for cpu dos
23:10 < zzz123> i independently discovered it after hypothetical hackers theorized similarities years earlier - and realized it with attack code
23:11 < zzz123> but because i pissed ava off, or because there was a miscommunication somewhere, despite that literal code being referenced in this cve https://nvd.nist.gov/vuln/detail/CVE-2023-33297 where in the references you will see my github (visualbasic6) and x/twitter (123456) - so, who is refusing to issue me credit? am i being blackballed? i just want it
23:11 < zzz123> for my resume. what's up here?
23:12 < zzz123> someone evidently tested it against one of the antpool machines; triggering their security team to lose their minds: https://github.com/bitcoin/bitcoin/issues/27623
23:13 < zzz123> to not issue credit - particularly when there's not even a bug bounty program - is diabolical
23:16 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
23:16 < zzz123> bbl - in the interim give https://x.com/123456/status/1864931738108998074 a peek. i'm banned from the mailing list and github. blackballed in bitcoin. sad. i just want credit, man.
23:21 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 252 seconds]
23:24 -!- Zenton_ [~Zenton@user/zenton] has quit [Remote host closed the connection]
23:24 -!- Zenton_ [~Zenton@user/zenton] has joined #bitcoin-core-dev
23:30 -!- ioannis [ion-@user/ion-] has joined #bitcoin-core-dev
23:34 -!- ioannis [ion-@user/ion-] has quit [Ping timeout: 248 seconds]
23:54 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has joined #bitcoin-core-dev
23:59 -!- kevkevin [~kevkevin@2601:243:197e:8f10:9082:cc39:1f3a:b549] has quit [Ping timeout: 260 seconds]
--- Log closed Fri Dec 06 00:00:11 2024