--- Log opened Wed May 14 00:00:42 2025
00:18 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
00:20 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 265 seconds]
00:20 -!- PaperSword1 is now known as PaperSword
00:23 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has quit [Quit: adil]
00:23 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has joined #bitcoin-core-dev
00:52 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has quit [Ping timeout: 272 seconds]
00:54 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has joined #bitcoin-core-dev
00:56 < bitcoin-git> [bitcoin] maflcko opened pull request #32490: refactor: Remove UB in prevector reverse iterators (master...2505-less-UB) https://github.com/bitcoin/bitcoin/pull/32490
00:58 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
01:03 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
01:26 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
01:29 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
01:31 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 276 seconds]
01:34 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
01:53 < bitcoin-git> [bitcoin] fanquake opened pull request #32491: build: document why we check for `std::system` (master...document_std_system) https://github.com/bitcoin/bitcoin/pull/32491
01:56 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has quit [Quit: Christoph_]
02:01 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has joined #bitcoin-core-dev
02:12 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has quit [Ping timeout: 260 seconds]
02:13 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
02:15 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
02:16 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-dev
02:16 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has quit [Quit: adil]
02:17 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has joined #bitcoin-core-dev
02:32 -!- Guest5203 [~diego@177.34.235.126] has left #bitcoin-core-dev []
02:33 -!- dviola [~diego@user/dviola] has joined #bitcoin-core-dev
02:53 -!- robobub [uid248673@id-248673.uxbridge.irccloud.com] has quit [Quit: Connection closed for inactivity]
02:58 < bitcoin-git> [bitcoin] fanquake opened pull request #32492: test: add skip_if_running_under_valgrind() (master...functional_tracepoints_skip_valgrind) https://github.com/bitcoin/bitcoin/pull/32492
03:03 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
03:21 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
03:26 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:30 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
03:33 -!- antanst [~antanst@user/antanst] has quit [Quit: The Lounge - https://thelounge.chat]
03:34 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
03:35 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
03:35 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
03:36 -!- Cory38 [~Cory38@user/pasha] has quit [Client Quit]
03:36 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
03:36 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f9d8910539a2...8a65f0389464
03:36 < bitcoin-git> bitcoin/master fa427ff MarcoFalke: fuzz: Properly setup wallet in wallet_fees target
03:36 < bitcoin-git> bitcoin/master 8a65f03 merge-script: Merge bitcoin/bitcoin#32488: fuzz: Properly setup wallet in wallet_fees ta...
03:36 < bitcoin-git> [bitcoin] fanquake merged pull request #32488: fuzz: Properly setup wallet in wallet_fees target (master...2505-fuzz-fix) https://github.com/bitcoin/bitcoin/pull/32488
03:40 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
03:44 -!- antanst [~antanst@user/antanst] has joined #bitcoin-core-dev
03:45 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
03:45 -!- Guest1757 [~ubuntu@197.237.108.217] has joined #bitcoin-core-dev
03:46 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 244 seconds]
03:46 -!- PaperSword1 is now known as PaperSword
03:59 -!- Holz_ [~Holz@user/Holz] has quit [Ping timeout: 244 seconds]
04:22 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
04:24 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
04:28 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
04:31 -!- adil [~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a] has quit [Quit: adil]
04:37 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
04:45 < bitcoin-git> [bitcoin] fanquake opened pull request #32496: depends: add Qt `-ltcg` for Darwin, drop it for Windows (master...depends_qt_ltcg) https://github.com/bitcoin/bitcoin/pull/32496
04:51 -!- Holz [~Holz@user/Holz] has joined #bitcoin-core-dev
04:56 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
04:59 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
05:08 -!- brunoerg [~brunoerg@2804:14d:5285:8318:658c:4bd4:bb3e:dfdb] has quit [Remote host closed the connection]
05:17 -!- BitcoinHobbyist [~BitcoinHo@c94-140.i12-24.melita.com] has joined #bitcoin-core-dev
05:19 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
05:20 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Client Quit]
05:24 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/8a65f0389464...33dfbbdff69d
05:24 < bitcoin-git> bitcoin/master 07350e2 Martin Zumsande: test: Fix intermittent failure in wallet_basic.py
05:24 < bitcoin-git> bitcoin/master e7ad86e Martin Zumsande: test: fix another intermittent failure in wallet_basic.py
05:24 < bitcoin-git> bitcoin/master 33dfbbd merge-script: Merge bitcoin/bitcoin#32483: test: fix two intermittent failures in wallet...
05:24 < bitcoin-git> [bitcoin] fanquake merged pull request #32483: test: fix two intermittent failures in wallet_basic.py (master...202505_fix_wallet_basic) https://github.com/bitcoin/bitcoin/pull/32483
05:25 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
05:40 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-dev
05:49 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Quit: Textual IRC Client: www.textualapp.com]
05:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-dev
05:53 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
05:55 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
05:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Ping timeout: 260 seconds]
05:59 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:00 -!- seaner [~sean@203-132-94-86.ip4.superloop.au] has quit [Ping timeout: 252 seconds]
06:01 < bitcoin-git> [bitcoin] l0rinc opened pull request #32497: merkle: pre‑reserve leaves to prevent reallocs with odd vtx count (master...l0rinc/pre‑reserve-merkle-leaves-to-max) https://github.com/bitcoin/bitcoin/pull/32497
06:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-dev
06:03 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
06:05 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
06:08 -!- Guest1757 [~ubuntu@197.237.108.217] has quit [Ping timeout: 248 seconds]
06:08 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has joined #bitcoin-core-dev
06:15 -!- BitcoinHobbyist [~BitcoinHo@c94-140.i12-24.melita.com] has quit [Quit: Client closed]
06:15 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:15 -!- Guest3748 [~ubuntu@197.237.108.217] has joined #bitcoin-core-dev
06:16 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Client Quit]
06:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
06:18 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 260 seconds]
06:18 -!- PaperSword1 is now known as PaperSword
06:19 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
06:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
06:26 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 245 seconds]
06:36 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
06:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Remote host closed the connection]
06:44 -!- BitcoinHobbyist [~BitcoinHo@c94-140.i12-24.melita.com] has joined #bitcoin-core-dev
06:46 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
06:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has joined #bitcoin-core-dev
06:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad] has quit [Remote host closed the connection]
06:50 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
07:04 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
07:04 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
07:05 < bitcoin-git> [bitcoin] ryanofsky pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33dfbbdff69d...f1d78a3087fb
07:05 < bitcoin-git> bitcoin/master a04f17a Sjors Provoost: doc: warn that CheckBlock() underestimates sigops
07:05 < bitcoin-git> bitcoin/master f1d78a3 Ryan Ofsky: Merge bitcoin/bitcoin#31624: doc: warn that CheckBlock() underestimates si...
07:05 < bitcoin-git> [bitcoin] ryanofsky merged pull request #31624: doc: warn that CheckBlock() underestimates sigops (master...2025/01/doc-sigops) https://github.com/bitcoin/bitcoin/pull/31624
07:06 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
07:08 -!- saturday- [~saturday7@59.167.129.22] has quit [Ping timeout: 244 seconds]
07:10 < bitcoin-git> [bitcoin] fanquake opened pull request #32498: doc: remove Carls substitute server from Guix docs (master...remove_carl_substitute_server) https://github.com/bitcoin/bitcoin/pull/32498
07:15 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
07:15 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Read error: Connection reset by peer]
07:16 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
07:23 -!- saturday7 [~saturday7@59.167.129.22] has joined #bitcoin-core-dev
07:28 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
07:32 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
07:32 -!- brunoerg [~brunoerg@2804:14d:5285:8318:d4e4:cda8:a7c:8076] has joined #bitcoin-core-dev
07:32 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
07:33 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
07:41 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit []
07:44 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
07:44 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
07:56 < bitcoin-git> [bitcoin] hebasto opened pull request #32499: cmake: Restrict MSVC-specific workaround to affected versions (master...250514-msvc-bug) https://github.com/bitcoin/bitcoin/pull/32499
07:58 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
07:58 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-dev
08:06 < bitcoin-git> [bitcoin] fanquake opened pull request #32500: init: drop `-upnp` (master...drop_upnp_opt) https://github.com/bitcoin/bitcoin/pull/32500
08:13 < PaperSword> @glozow, sorry about X, just saying. None the less back to building.
08:15 -!- BitcoinHobbyist [~BitcoinHo@c94-140.i12-24.melita.com] has quit [Quit: Client closed]
08:17 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:20 -!- saikasyap [~saikasyap@131-193-212-63.east.wireless.uic.edu] has joined #bitcoin-core-dev
08:21 < instagibbs> sipa re:#31553 second commit allows oversized singleton clusters, can you remind me why you/we chose this? 
08:21 < corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
08:22 < instagibbs> ah right, nvm ofc
08:22 < instagibbs> reorg adding in stuff blindly 
08:44 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Remote host closed the connection]
08:44 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
08:47 < gmaxwell> I've still never really understood why reorgs can't be handled by a list of "non-conflicted transactions which were previously confirmed which must be reconfirmed with the highest priority" and absolutely no computational complexity or limits on that list.. and then a mempool of additional never-confirmed transactions which treats everything in that list of deconfirmed as confirmed, and is 
08:47 < gmaxwell> managed as the mempool normally is.
08:48 < gmaxwell> so then in a reorg a block is filled by trying to stuff back in all the deconfirmed transactions (in their original order from the node's perspective), and then filling in what remains from the mempool.
08:50 < gmaxwell> And with a disclosed note that in the event of a reorg, the mining logic favors reconfirming transactions over income maximization on the basis that system health is better for the miner's bottom line than scraping out the absoulte highest income...
08:50 < _aj_> if there's a higher fee(rate) conflict with one of those transactions, a miner will probably prefer to mine that conflict rather than confirming the old one at "highest priority" ?
08:51 < gmaxwell> _aj_: I don't really think so, particularly given that the reorg is a very rare event... but someone having a significant theft as a result of reorg may be incredibly damaging to the miner.  Like great you got 0.001 BTC more but the public drama means all the bitcoin you earned is now worth 10% less.
08:53 < instagibbs> you'd still have to deal with oversizedness, so I think this is a question about how things are shoved back into txgraph vs the proposed trimming function?
08:54 < gmaxwell> It might be the case that if the difference was some huge bogon fee they might prefer it but (1) if there is a bogon fee it's probably some theft attempt, and (2) all this is so rare the expected cost of making the pro-social move is negligible, and a lot more could be earned by doing stuff like making template update latency non-terrible (it's very terrible today, high fee txn are often missed 
08:54 < gmaxwell> 10s of seconds after they're well relayed).
08:54 < gmaxwell> instagibbs: oversizedness in what sense?  
08:54 < instagibbs> cluster size/count  (count being most important)
08:55 < gmaxwell> That's my point. no you shouldn't.
08:55 < instagibbs> hm
08:55 < gmaxwell> There should just be a vector of txn that were previously confirmed and non-conflicted (so still consensus value).. and block building logic should just stuff them all back in.  Mempool should treat them as confirmed, not a part of clusters.
08:56 < instagibbs> so you have a bunch of stuff you can't actually tell how good it is, you get a new tx, you'll just ignore that too?
08:56 < gmaxwell> Perhaps I'm just stupid, would not be the first time.  I had this covo with sipa before and got a response like yours, and I don't get it.
08:56 < instagibbs> ditto hah
08:57 < gmaxwell> instagibbs: I think mempool should treat previously (non-conflicted) confirmed stuff as confirmed, and mining should work on reconfirming all that stuff.   Then you don't have to worry about it violating cluster limits, etc. because it's not part of clusters.  
08:58 < gmaxwell> It's just a list of stuff you'd like to try to get back into blocks before resuming the regularly scheduled programming.
08:58 < _aj_> had a discussion with luke along similar lines once, but the idea was just to mark previously-confirmed txs as un-replaceable but still in the regular mempool
08:59 < _aj_> it seems like a good idea to me, especially if it simplifies things/makes them more efficient, but i don't have any confidence we'd be willing to make a "peternalistic" policy like that and stand up against the criticism of it
08:59 < gmaxwell> Right but now there is a bunch of hairball about putting that stuff in the mempool and having it frequently break cluster limits and how do you handle that particularly because all of those limits are motivated by computational complexity concerns.
09:00 < gmaxwell> It's justifyable on an entirely or almost enirely non-parternalistic basis, because otherwise you have this cluster limits problem.
09:00 < gmaxwell> Also it's not like the reinstated transactions are going to be *bad* in terms of income. Particularly in the ordinary case of a 1 block reorg.
09:00 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
09:01 < _aj_> last time i looked, the 1-block reorgs had 99.9% the same transactions already anyway
09:01 < _aj_> sadly, i no longer remember how to look that up
09:02 < gmaxwell> _aj_: it was previously (years ago) when I looked.
09:03 < _aj_> yeah, it was at least a year ago when i looked
09:03 < gmaxwell> Like there is this annoying computational problem, it just so happens that doing the "good for the network health" thing can avoid it. Probably the socially good thing is in the miners selfish self interest, but even if it's against it, probably the loss is very small.  But all that aside it solves the limits problem... and does so in a way that doesn't make the network health _worse_ where the 
09:03 < gmaxwell> node evicts perfectly valid already-confirmed txn just because the broke a cluster limit.
09:05 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 248 seconds]
09:05 < _aj_> the idea is the ordering is just exactly how it appeared when it was confirmed?
09:06 < gmaxwell> And it isn't as if the current (or post cluster) mining logic is actually the true income maximizing logic, -- e.g. node won't keep around multiple conflicting pools and decide at the moment of template construction which makes the most money.  It's not even particularly hard to do that (like just calling out to MIP solver with a pretty trivial problem gets you the answer), but it doesn't 
09:06 < gmaxwell> result in a sensible "implied relay logic" that makes sense.
09:07 < gmaxwell> _aj_: yeah or at least the starting point of my suggestion is that, you could apply some sorting (restricted to O(n log n) optimizations) but I think the idea works with just preserving the original order.
09:09 < gmaxwell> You just can't apply any O(N^2) or worse algorithim to an arbitarily long reorg... without having to potentialy cut transactions out that were confirmed to manage the complexity blowup.
09:09 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-dev
09:09 -!- Guest70 [~Guest1@biblio159.dgbiblio.unam.mx] has joined #bitcoin-core-dev
09:09 -!- Guest70 [~Guest1@biblio159.dgbiblio.unam.mx] has quit [Client Quit]
09:10 < gmaxwell> and for system health, I think it's very good and important to restore the 'most confirmed' (greatest depth) transactions first.
09:13 < gmaxwell> but like even if you don't give a fuck about system health, you got some contract that sells your coins the instant they're mined yadda yadda... *something* has to be done here because just dumping the reorg into the mempool doesn't work because of potential complexity blowup.  May well be that what I suggests earns more income directly, anyways, because otherwise you'd drop more profitable txn 
09:13 < gmaxwell> because they violated cluster limits.
09:17 < _aj_> well, i liked the non-replacable idea, and this is better than that, so +1 fwiw
09:17 < gmaxwell> And as far as the health argument goes, you can make a lot of very subjective arguments for the merits of things like RBF or filtering or whatever about non-confirmed txn.  But all this is pretty subjective and the system can't make any promises about unconfirmed stuff... But "this was already N confirmed" is an extremely unambigious metric and confirmation is the point where 
09:17 < _aj_> maybe worth it do a write up of the approach/implications, getting chinese/etc translations, and consulting miners/pools before implementing it
09:17 < gmaxwell> we-the-tech-community has always said that expectations ought to start forming there.  It's would also be completely technically pratical for the network to relay near-tip orphans and for miners to priortize their distinct txn, though that isn't done today... and probably no one will bother implementing because orphans are rare enough.   
09:17 < _aj_> near-tip stale blocks you mean?
09:18 < gmaxwell> but unlike "miners should always prioritize FIRST SEEN" ... priortizing stuff that has actually been mined (and particularly was YOUR best tip) is actually reasonable.
09:19 < gmaxwell> _aj_: Exactly, near-tip stale blocks.  To be clear, I'm not suggesting doing that now, but I think it would be reasonable to do (as it's kind of the logical conclusion of the policy I suggest, so if you hated near-tip inclusion as a priority thing then maybe you should hate my suggestion)
09:19 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
09:21 < gmaxwell> (and given that stale blocks are relatively rare, it's arguable not worth implementing even if you fully buy my argument that those txn should be prioritized where they are non-conflicted)
09:21 < _aj_> you lose the "i've already validated this block, so i know the txs are fine" for that code path
09:22 < gmaxwell> _aj_: yeah but the node is usually pretty idle, validate in background. It's got tip-POW so it's not a DOS vector.
09:23 < _aj_> validating in the background could make reorging to that block and a new child of it faster (and would certainly make rejecting a child of it faster if the stale block turned out to be invalid)
09:23 < _aj_> not sure if any of that would also affect the selfish-mining stuff
09:23 < gmaxwell> _aj_: best counterargument (beyond it not being worth impl complexity) I'm aware of is that there is a harm to consensus to help anyone get *access* to a fork from your tip, but I think it's a pretty thin issue.
09:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
09:24 < _aj_> is it a harm to consensus to know that there's an equal-work valid tip out there that may have more hashrate mining on it though?
09:25 < gmaxwell> _aj_: yes it would, which is at least a theoretical problem, if there is a deep fork bitcoin can stop converging when the cost to switch starts approaching the interblock time.  This actually was seen in practice in some shitty altcoin called 'liquid bitcoin' or something like that where it has a fixed difficulty-- the network shattered into a thousand forks once the reorg time exceeded the 
09:25 < gmaxwell> interblock time.
09:26 < _aj_> (fixed difficulty... why??? :yelling-at-clouds-emoji:)
09:26 < gmaxwell> _aj_: I think everyone has a self interest in trying to avoid there being any additional hashrate confilicting the tip they're on.
09:26 -!- pyth [~pyth@user/pyth] has quit [Quit: Leaving]
09:27 < _aj_> not dealing with an alternative fork that's more than 1 block deep seems fine -- ie, don't disconnect more than 1 block for bg validation of a fork
09:28 < gmaxwell> _aj_: https://runt-of-the-web.com/wordpress/wp-content/uploads/2012/08/funniest-demotivationals-mistakes.jpg
09:28 < _aj_> gmaxwell: i've had that thought: logical conclusion is that you should make the most impressive mistakes you can, and document them thoroughly
09:29 < gmaxwell> _aj_: I mean in terms of theoretical weakness/attacks,  lets say that a 50 block reorg takes more than 10 minutes for most nodes to proces. And forever reason (attack, internet cut, etc) such a fork forms in Bitcoin-- the result may be that the system never reconverges to a single new chain without human intervention, or takes a very very long time. 
09:32 < gmaxwell> but I think I'm off in the weeds about pretty theoretical risks.
09:34 < gmaxwell> To 'solve' that risk it would be sufficient to track multiple near-best chains which have recieved a new block with in n*average_block_time, as in maintain a cloned chainstate for each of them so new blocks in them could be validated without any switching costs.
09:35 < gmaxwell> But oy, lots of software complexity for a theoretical rather than pratical risk, that in practice would just get resolved by intervention if it ever happened.
09:35 < glozow> question: If you have the "previously confirmed txns pool" and see a child of one of those, do you put the child in that pool or the mempool?
09:36 < _aj_> the mempool, unless it was a child in a confirmed block
09:36 < gmaxwell> glozow: in my thinking, the mempool.  The previously confirmed pool is just treated as confirmed from the perspective of the mempool.
09:36 < gmaxwell> as _aj_ says, unless it was itself previously confirmed.
09:36 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
09:36 < _aj_> the mempool, unless it was a child in a pow-valid block (confirmed or perhaps stale)
09:36 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
09:38 < glozow> how long would a tx persist in previously confirmed pool?
09:38 < _aj_> gmaxwell: depends how many new txs were on the other side of the reorg i guess, a simple invalidate/reconsider of 50 blocks seems to take a couple of minutes on not very quick hw
09:38 < _aj_> until it's mined or conflicted by a confirmed tx
09:38 < gmaxwell> Essentially I suggest the node behavior is "once confirmed, always confirmed, unless it gets conflicted"
09:39 < _aj_> i guess if it's mined, technically that's also conflicted by a confirmed tx
09:39 < glozow> how would we decide on evictions for child-of-previously-confirmed in the mempool? it also gets evicted if it's lower feerate right?
09:39 < glozow> as in, it's compared with all the other stuff in mempool
09:39 < gmaxwell> glozow: It might be prudent to time it out, e.g. there is an unknown to you softfork that makes it no longer consensus valid to other participants. But I think my general concept is forever.
09:39 < _aj_> same as we do for child-of-confirmed-tx in the mempool
09:40 < gmaxwell> _aj_: right, in my view it's just treated like its confirmed.
09:40 < _aj_> gmaxwell: wow, that would be horrible -- if you had hashpower, you'd stick it in a block, and everyone would reject your block
09:41 < gmaxwell> _aj_: I mean thats generally the problem with softforks, if someone does mine something invalid then you end up with multiple rejected blocks-- that already happens.
09:42 < _aj_> gmaxwell: you'd normaly reject it from your mempool for being non-standard, but maybe you wouldn't reject it here for that reason
09:42 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
09:42 < gmaxwell> _aj_: yes but people build on the invalid block. We've seen it in practice in prior softforks, where every time a miner that allowed the consensus invalid blocks there would be several additional blocks that built on it.
09:43 < gmaxwell> during one softfork 50btc one of the larger pools at the time spent an entire month producing invalid blocks. many of which triggered other miners to produce invalid-because-child.  The pool was PPS too so they didn't lose much hashpower...
09:44 < glozow> would you not still run validation on the disconnected transactions?
09:44 < gmaxwell> glozow: sure absolutely you're only trying to mine transactions YOU think are valid.
09:44 < gmaxwell> glozow: aj's point is that the network may have other ideas about their validity.
09:45 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 244 seconds]
09:45 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-dev
09:47 < gmaxwell> _aj_: of course you could also further restrict any "restoration" transactions to ones that don't violate forward compatiblity standardness rules to reduce that risk.  I don't really have a strong opinion one way or another, and could argue it either way. 
09:47 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has quit [Quit: Christoph_]
09:50 < gmaxwell> _aj_: the principle of FAFO applies to both sides, non-upgraded-miner producing invalid blocks due to not enforcing a newly active consensus rule, or a user relying on confirmation of a transaction that is non-standard due to well understood forward compat rules.  I *generally* prefer to screw the miner when those two conflict, because they're the more sophicated party.
09:50 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
09:51 < gmaxwell> _aj_: but otoh the new consensus rule might be some rogue bullshit performed by just a couple mining pools, the smaller miner doesn't even know about the new rule, etc.
09:51 < gmaxwell> _aj_: but if the majority hashpower is out to get them they can invalidate stuff that isn't blocked by forward compat rules anyways so ::shrugs::
09:53 < gmaxwell> like right now today two or three miners constuting >>50% hashpower could decide to blacklist some address, maybe belonging to a known bad actor.. and then everyone else is producing blocks that they'll exclude from their chain, and will keep doing so 'forever' (until human intervention).
09:53 < gmaxwell> so I don't think restoration creates a vulnerablity to attack that doesn't just already exist.
09:54 < gmaxwell> (restoration being the word I'm using to describe trying hard to confirm deconfirmed transactions, if it wasn't clear)
09:57 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
09:58 < gmaxwell> _aj_: as to why I favor restoring transactions you wouldn't mine generally, the biggest reason is because restoring them is necessary to restore their children, which you would have mined.  like right now today if I'm not an idiot I don't author transactions that spend unconfirmed non-standard coins.  But once they're confirmed I don't care if they're standard at all, and I expect that right 
09:58 < gmaxwell> now a large percentage of the tip-circulating coins have non-standardness somewhere in their recent causual history.
09:59 < gmaxwell> like someone does some bullshit monkey jpeg crap and the change from that eventually ends up in an exchange wallet, and so on.
09:59 < _aj_> maybe after some timeout you just start moving restoration-txs back into the mempool (relaying to other peers as you do so, and evicting things that violate cluster limits)
09:59 -!- enochazariah [~enochazar@162.245.239.130] has joined #bitcoin-core-dev
10:00 < _aj_> like 72 blocks (12h)
10:01 < gmaxwell> _aj_: yeah I think that is a reasonable backstop. The timeout could also just be some function of their order.  like you can assume the network is generally trying to restore and if a txn isn't immediately restored there may be a reason why not.  So like if there is a 2 deep reorg, the oldest txn are 2 blocks old and maybe you want to kick them out by the time they're N blocks old.  If you 
10:01 < gmaxwell> assume *everyone* is retoring you'd kick them out after litterally the next block, but some slack makes sense.
10:02 -!- saikasyap [~saikasyap@131-193-212-63.east.wireless.uic.edu] has quit [Quit: Client closed]
10:03 < gmaxwell> _aj_: more than I was thinking.  why not just assume miners are restoring, except for some jokers who aren't, and kick stuff out after a couple blocks more than than it would take if everyone was restoring?
10:03 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 272 seconds]
10:04 < gmaxwell> Again I'm not strongly opinioned on this one. I think if you don't try to restore forward-compat-vioating txn then it's pretty reasonable to have a long expiration.  If you restore litterally everyone you may want to evict fast to minimize risk that you're trying to restore something that is invalid but you don't know its invalid. Of course, the two could be hybridized... 
10:06 < gmaxwell> (and to be clear I mean evict from the restore-pool to the mempool, which may or may not mean dropping entirely due to policy/cluster/etc limits)
10:09 < _aj_> gmaxwell: i think you'd drop to the mempool in the reverse order to how you'd mine; i think if the main thing we're protecting against is miners who aren't following current consensus rules, then risking up to half a day of lost hashpower isn't going to cause massive angst, and gives plenty of time to catch up any txs for even a long reorg
10:10 < _aj_> gmaxwell: revalidating previously confirmed txs to see if they follow standardness rules seems annoying, so i dismissed the hybridized approach :(
10:14 < _aj_> (it seemed especially annoying to try to do it straight away when you want to do a getblocktemplate asap after the reorg, so i think that means "restoring txs you wouldn't mine generally" also makes sense)
10:15 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has joined #bitcoin-core-dev
10:18 < instagibbs> _aj_ I suppose when "evicting" from "restore pool" back into the mempool , one could do essentially the reverse of what I was doing for another purpose. Use known cfr of non-oversized clusters, and remove things backwards until not oversized, then commit 
10:18 < gmaxwell> _aj_: hm I was thinking the forward compat rules were decidable as a pure function of the txn, you don't need the inputs. But I'm not particularly sure about that.
10:19 < gmaxwell> I don't have a strong opinion but I'm not the greatest fan of handling the eviction that way, just because its an exceptional case that shouldn't happen, so easier to just pretend its newly recieved. 
10:19 < _aj_> gmaxwell: not for OP_SUCCESS and so forth
10:19 < gmaxwell> _aj_: darn. okay thats a big strike against checking.
10:19 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has joined #bitcoin-core-dev
10:20 < _aj_> gmaxwell: yeah :( DISCOURAGE_UPGRADEABLE_PUBKEYTYPE can be conditional on arbitrary script logic too
10:21 < gmaxwell> But I think restorepool's mission can be achieved even if you evict very quickly, which mitigates harm.
10:21 < _aj_> so depth of reorg + fudge factor blocks?
10:22 < gmaxwell> yeah. Basicaly assume that the network is going to try to restore ASAP, and if it fails to do so, too bad so sad, you get back in line.
10:23 < gmaxwell> also if you didn't get double spent in fudge_factor blocks, good odds you never will be.
10:23 < _aj_> gmaxwell: "I'm not the greatest fan of handling the eviction that way" -- sorry, which way?
10:25 < gmaxwell> _aj_: I understood you were suggesting that a restore-evict should be added to a cluster in a priority way, so eg. cluster limits evict something else.  I'm not a huge fan simply because it requires processing the whole cluster, means there is a bunch of reorg special case mempool logic.  Which this restorepool idea was trying to eliminate.
10:25 < _aj_> instagibbs: oh, i guess when you evict from the restorepool, you have to take all the descendants in the mempool, and validate them as a package, in case there's cpfp stuff? but you also want to remember you've already done the consensus/standardness validation for the descendants
10:26 < _aj_> gmaxwell: oh, no, treating it as new sounds fine to me; i just meant cluster limits would apply now and something would get evicted
10:26 < gmaxwell> ah okay.
10:26 < gmaxwell> there is some unavoidable complexity I think, like say the evicted txn is the parent of all txn in the cluster. 
10:26 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 248 seconds]
10:26 < instagibbs> _aj_ well, if it's undersized, you'll end up being able to evaluate the new chunks, and we're reyling on PoW for anti DoS. How that's advertised on relay, i havent considered it
10:27 < gmaxwell> and cluster is overlimits with it in there.
10:27 < _aj_> gmaxwell: i think package logic might already deal with that (with the only problem be we can't relay it currently, but that's not an issue here). **handwave** **look, a dinosaur!!**
10:27 -!- pablomartin_ [~pablomart@217.130.254.81] has joined #bitcoin-core-dev
10:28 < gmaxwell> yeah I'm not too concerned with relay in the sense that assuming the reorged block was well propoagated there doesn't need to be anyone as ~all nodes will just be doing the same operation.
10:28 < gmaxwell> I mean it's fine to try relaying it.
10:28 < _aj_> instagibbs: relay is just belts and suspenders / best effort; everyone running this new logic should already have the txs...
10:28 < gmaxwell> _aj_: jinx
10:29 < instagibbs> im not worrying too much when big reorgs...
10:29 < instagibbs> s/big//
10:29 < _aj_> what are you worrying about then?
10:29 < instagibbs> you're the one who brought up package relay not me! :)
10:30 < _aj_> okay, worry about it when there's a spec then!
10:35 < bitcoin-git> [bitcoin] BrandonOdiwuor opened pull request #32501: RPC: removeprunedfunds should take an array of txids (master...removeprunedfunds-array) https://github.com/bitcoin/bitcoin/pull/32501
10:36 < _aj_> instagibbs: i just mean if you take X from the restorepool with descendants A B C in the mempool, then remove A,B,C from the mempool and call ProcessNewPackage([X,A,B,C]) maybe that already does 95% of the right thing
10:38 < instagibbs> ah sure, the CFR would be well-known as long as XABC isn't oversized
10:38 < instagibbs> (and I think you can use ABC CFR knowledge to trim a bit smarter)
10:39 < _aj_> well A,B,C might have been in different clusters initially, and bring in whatever else was in those clusters as a result, but yeah
10:39 < instagibbs> yes
10:40 < gmaxwell> That would actually be the most common case too, as mempool cluster size is 1+e on average, and many txn are spending outputs in the last block or two. Bringing back in a parent will tend to merge clusters.
10:40 < _aj_> maybe annoying if your next tx to move from restorepool to mempool is Y which is X's parent
10:41 < instagibbs> you have to keep backing it out, but I don't see a fundamental issue there
10:41 < _aj_> yeah, probably so rare in practice that annoying doesn't matter
10:41 < gmaxwell> well the eviction should be the order of original confirmation I think?  
10:41 < _aj_> annoying-for-the-computer doesn't matter anyway
10:41 < _aj_> got to evict children before parents
10:42 < gmaxwell> ah 
10:42 < gmaxwell> right
10:42 < _aj_> keeping trying to confirm what were the deepest confirmed txs for the longest time also seems okay?
10:42 < gmaxwell> I mean you can evict parents 'first' but you have to evict all the children with htem if you do.
10:43 < gmaxwell> _aj_: yeah I guess my thinking was mostly "this one really should be back in already, if it's not, there is an issue with it" 
10:43 < instagibbs> yes, and you'll have to handle that due to conflicts via other blocks
10:43 < instagibbs> anyways
10:43 < _aj_> i don't think you want to evict everything at once because you still have to validate standardness for all of them; didn't see any obvious midpoint between 1-by-1 and everything
10:44 < _aj_> gmaxwell: fair
10:44 < _aj_> gmaxwell: so maybe 1-by-1 from the front, but grab all its children
10:45 < gmaxwell> That's what I was thinking (well hadn't thought through the children part, but you're right that its necessary)
10:45 < _aj_> gmaxwell: then let the package logic discard stuff that's too big and validate everything in the package, because validating a package all at once is fine anyway
10:45 < instagibbs> in that case, oversized results degenerates to Trim from PR?
10:45 < instagibbs> (in batch)
10:45 < _aj_> PR=Package Relay? yeah, i think so
10:46 < instagibbs> sorry this one #31553 (I still have to review it hence this discussion)
10:46 < corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
10:46 < instagibbs> shove everything in, make best-effort undersized txgraph
10:46 -!- Christoph_ [~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e] has quit [Quit: Christoph_]
10:47 < _aj_> instagibbs: ah, not sure at that detail, but it sounds good
10:51 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-dev
10:58 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
10:59 -!- enochazariah [~enochazar@162.245.239.130] has quit [Quit: Client closed]
11:09 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 276 seconds]
11:10 -!- BlueMoon [~BlueMoon@biblio159.dgbiblio.unam.mx] has joined #bitcoin-core-dev
11:15 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
11:16 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
11:17 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
11:21 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
11:23 -!- BlueMoon [~BlueMoon@biblio159.dgbiblio.unam.mx] has quit [Quit: Client closed]
11:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
11:26 < bitcoin-git> [bitcoin] davidgumberg opened pull request #32502: wallet: Drop unused fFromMe from CWalletTx (master...5-14-25-dead-code-removal) https://github.com/bitcoin/bitcoin/pull/32502
11:29 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 260 seconds]
11:30 -!- pablomartin_ [~pablomart@217.130.254.81] has quit [Ping timeout: 244 seconds]
11:42 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
12:07 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has quit [Quit: Client closed]
12:14 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has joined #bitcoin-core-dev
12:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
12:18 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 245 seconds]
12:18 -!- PaperSword1 is now known as PaperSword
12:21 -!- PaperSword1 [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
12:22 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 248 seconds]
12:22 -!- PaperSword1 is now known as PaperSword
12:26 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
12:27 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Ping timeout: 248 seconds]
12:27 -!- PaperSword1 is now known as PaperSword
12:29 -!- Guest3748 [~ubuntu@197.237.108.217] has quit [Ping timeout: 276 seconds]
12:29 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
12:40 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:57 < bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/f1d78a3087fb...e7a937237686
12:57 < bitcoin-git> bitcoin/master 02d4bc7 ismaelsadeeq: interfaces: remove redundant coinbase fee check in `waitNext`
12:57 < bitcoin-git> bitcoin/master e6c2f4c ismaelsadeeq: interfaces: refactor: move `submitSolution` implementation to miner
12:57 < bitcoin-git> bitcoin/master 720f201 ismaelsadeeq: interfaces: refactor: move `waitNext` implementation to miner
12:57 < bitcoin-git> [bitcoin] achow101 merged pull request #32378: interfaces: refactor: move `Mining` and `BlockTemplate`  implementation to miner (master...04-2025-refactor-mining-interface) https://github.com/bitcoin/bitcoin/pull/32378
13:08 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
13:12 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
13:19 < bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e7a937237686...53eb5593f0a1
13:19 < bitcoin-git> bitcoin/master 8ba245c Sebastian Falbesoner: test: add constants for MuSig2 PSBT key types (BIP 373)
13:19 < bitcoin-git> bitcoin/master 4b24186 Sebastian Falbesoner: test: add test for decoding PSBT with MuSig2 PSBT key types (BIP 373)
13:19 < bitcoin-git> bitcoin/master 53eb559 Ava Chow: Merge bitcoin/bitcoin#32305: test: add test for decoding PSBT with MuSig2 ...
13:19 < bitcoin-git> [bitcoin] achow101 merged pull request #32305: test: add test for decoding PSBT with MuSig2 PSBT key types (BIP 373) (master...202504-test-add_musig2_decodepsbt_tests) https://github.com/bitcoin/bitcoin/pull/32305
13:27 < bitcoin-git> [bitcoin] brunoerg opened pull request #32504: test: descriptor: cover invalid multi/multi_a cases (master...2025-05-descriptor-test-multi) https://github.com/bitcoin/bitcoin/pull/32504
13:56 -!- redstorm [~redstorm@2406:e001:2:6400::1] has joined #bitcoin-core-dev
13:57 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
13:59 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
14:00 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has quit [Quit: Client closed]
14:00 -!- upekkha [~Advanced@2a01:4f8:1c0c:49df::1] has quit [Remote host closed the connection]
14:00 -!- SpellChecker_ [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
14:01 -!- SpellChecker [~SpellChec@user/SpellChecker] has quit [Remote host closed the connection]
14:01 -!- upekkha [~Advanced@2a01:4f8:1c0c:49df::1] has joined #bitcoin-core-dev
14:04 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 245 seconds]
14:05 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has joined #bitcoin-core-dev
14:22 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
14:22 -!- saikasyap [~saikasyap@131-193-237-189.east.wireless.uic.edu] has quit [Ping timeout: 240 seconds]
14:30 -!- santiii [~santiii@209.214.155.50] has joined #bitcoin-core-dev
14:34 < bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/53eb5593f0a1...d5786bc19a9f
14:34 < bitcoin-git> bitcoin/master fa7f04c MarcoFalke: refactor: Remove UB in prevector reverse iterators
14:34 < bitcoin-git> bitcoin/master faf9082 MarcoFalke: test: Fix whitespace in prevector_tests.cpp
14:34 < bitcoin-git> bitcoin/master d5786bc Ava Chow: Merge bitcoin/bitcoin#32490: refactor: Remove UB in prevector reverse iter...
14:34 < bitcoin-git> [bitcoin] achow101 merged pull request #32490: refactor: Remove UB in prevector reverse iterators (master...2505-less-UB) https://github.com/bitcoin/bitcoin/pull/32490
14:52 -!- redstorm [~redstorm@2406:e001:2:6400::1] has quit [Quit: Client closed]
14:53 -!- santiii [~santiii@209.214.155.50] has quit [Quit: Client closed]
15:02 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
15:03 -!- SpellChecker_ [~SpellChec@user/SpellChecker] has quit [Quit: bye]
15:03 -!- SpellChecker [~SpellChec@user/SpellChecker] has joined #bitcoin-core-dev
15:05 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d5786bc19a9f...4b26ca0e2f1e
15:05 < bitcoin-git> bitcoin/master 5bf91ba David Gumberg: wallet: Drop unused fFromMe from CWalletTx
15:05 < bitcoin-git> bitcoin/master 4b26ca0 Ava Chow: Merge bitcoin/bitcoin#32502: wallet: Drop unused fFromMe from CWalletTx
15:05 < bitcoin-git> [bitcoin] achow101 merged pull request #32502: wallet: Drop unused fFromMe from CWalletTx (master...5-14-25-dead-code-removal) https://github.com/bitcoin/bitcoin/pull/32502
15:42 < bitcoin-git> [bitcoin] theStack opened pull request #32505: depends: bump to latest config.guess and config.sub (master...202505-depends-latest_config_guess_sub) https://github.com/bitcoin/bitcoin/pull/32505
15:43 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
15:43 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
15:47 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 245 seconds]
15:50 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
16:01 -!- robszarka [~szarka@2603:3003:4eac:100:3855:996a:9be1:e359] has joined #bitcoin-core-dev
16:01 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
16:04 -!- szarka [~szarka@2603:3003:4eac:100:682b:a9d9:9b1d:907b] has quit [Ping timeout: 260 seconds]
16:06 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Ping timeout: 252 seconds]
16:14 < bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/4b26ca0e2f1e...31d3eebfb92a
16:14 < bitcoin-git> bitcoin/master 4f5e04d Luke Dashjr: Revert "remove unneeded close_fds option from cpp-subprocess"
16:14 < bitcoin-git> bitcoin/master c7c356a Luke Dashjr: cpp-subprocess: Iterate through /proc/self/fd for close_fds option on Linux
16:14 < bitcoin-git> bitcoin/master a0eed55 Luke Dashjr: run_command: Enable close_fds option to avoid lingering fds
16:14 < bitcoin-git> [bitcoin] achow101 merged pull request #32343: common: Close non-std fds before exec in RunCommandJSON (master...2025-04-closefds) https://github.com/bitcoin/bitcoin/pull/32343
16:24 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 252 seconds]
16:26 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has joined #bitcoin-core-dev
16:46 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
16:46 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
16:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
17:03 -!- jespada [~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy] has quit [Ping timeout: 252 seconds]
17:05 -!- mcey_ [~emcy@85.255.235.129] has joined #bitcoin-core-dev
17:08 -!- mcey [~emcy@85.255.232.180] has quit [Ping timeout: 260 seconds]
17:18 -!- luke-jr_ [~luke-jr@user/luke-jr] has joined #bitcoin-core-dev
17:18 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-dev
17:19 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 276 seconds]
17:24 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Remote host closed the connection]
17:35 -!- emcy__ [~emcy@148.252.129.104] has joined #bitcoin-core-dev
17:39 -!- mcey_ [~emcy@85.255.235.129] has quit [Ping timeout: 272 seconds]
17:46 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
17:46 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
18:17 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has joined #bitcoin-core-dev
18:19 -!- PaperSword [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
18:20 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-dev
18:21 -!- PaperSword1 [~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
18:28 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Remote host closed the connection]
18:48 -!- robszarka [~szarka@2603:3003:4eac:100:3855:996a:9be1:e359] has quit [Quit: Leaving]
18:48 -!- szarka [~szarka@2603:3003:4eac:100:3855:996a:9be1:e359] has joined #bitcoin-core-dev
18:51 -!- Cory38 [~Cory38@user/pasha] has quit [Quit: Client closed]
18:51 -!- Cory38 [~Cory38@user/pasha] has joined #bitcoin-core-dev
19:24 -!- jarthur [~jarthur@user/jarthur] has joined #bitcoin-core-dev
19:53 -!- Zak11 [~Zak@2607:fb91:50b:c5::8335] has joined #bitcoin-core-dev
19:54 -!- Zak11 [~Zak@2607:fb91:50b:c5::8335] has quit [Client Quit]
20:02 -!- zak77 [~zak@172.58.150.56] has joined #bitcoin-core-dev
20:43 -!- Guest59 [~Guest59@12.116.17.30] has joined #bitcoin-core-dev
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:24 -!- greypw1495085720 [~greypw@user/greypw] has quit [Quit: Ping timeout (120 seconds)]
21:26 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has quit [Quit: leaving]
21:47 -!- _flood [~flooded@149.102.226.200] has joined #bitcoin-core-dev
21:48 -!- flooded [~flooded@149.102.226.199] has quit [Ping timeout: 252 seconds]
21:51 -!- Guest59 [~Guest59@12.116.17.30] has quit [Quit: Client closed]
22:06 -!- TallTim_ [~talltim@24.124.35.28] has joined #bitcoin-core-dev
22:08 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
22:08 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
22:10 -!- TallTim [~talltim@24-124-35-28-dynamic.midco.net] has quit [Ping timeout: 244 seconds]
22:13 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
22:40 -!- Christoph_ [~Christoph@host-88-217-174-126.customer.m-online.net] has joined #bitcoin-core-dev
23:26 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
23:56 -!- tarotfied [~tarotfied@user/tarotfied] has quit [Quit: WeeChat 4.1.1]
--- Log closed Thu May 15 00:00:43 2025