<theStack_> _aj_: true, though that wouldn't prevent users from burning funds (though one could argue that reducing the supply is just a donation to everyone else)
brunoerg has quit [Ping timeout: 268 seconds]
<_aj_> theStack_: "also"
sipsorcery has quit [Ping timeout: 268 seconds]
<theStack_> _aj_: ah, right
<theStack_> but UTXO set exclusion is consensus-relevant, no? thinking about utreexo and assumeutxo, it wouldn't be healthy if UTXO sets differ between nodes
<sipa> So far nothing relies on having a normalized UTXO set, I think.
Guest67 has joined #bitcoin-core-dev
<sipa> Apart from the fact that `gettxoutsetinfo`'s hash will differ - but we can rename the hash field's name to indicate that.
<_aj_> sipa: if you track the utxos you've excluded via muhash, i think you could just add that to the muhash of the utxos you haven't excluded and get the same result
<sipa> Interesting!
<theStack_> nice indeed
<_aj_> sipa: oh, and since they're unspendable, when you initially go to exclude them, if you go through the utxo set in height order, you should be able to recreate the excluded hashes at every block height fairly efficiently...
<_aj_> sipa: (ie, without having to look up any blocks from disk)
<theStack_> currently, if i run let's say a 0.8 node and 22.0 one syncing to the tip, the UTXO sets are equal? or were there already UTXOs exclusions introduced in previous versions?
AaronvanW has quit [Quit: Leaving...]
<_aj_> theStack_: https://github.com/bitcoin/bitcoin/pull/2791 was included in 0.9 not 0.8 i think?
vysn has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
<theStack_> _aj_: thanks, interesting
Guest67 has quit [Quit: Client closed]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
<achow101> theStack_: I think that is reasonable
bomb-on has quit [Quit: aллилѹіа!]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> bitcoin/master ce6dd2f fanquake: zeromq 4.3.4
<bitcoin-git> bitcoin/master 6897c4b fanquake: build: patch depends zeromq to fix building on NetBSD Current
<bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/06b636976613...7102f7d6f3c4
<bitcoin-git> bitcoin/master 7102f7d fanquake: Merge bitcoin/bitcoin#23956: build: use zeromq 4.3.4 in depends & fix NetB...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake merged pull request #23956: build: use zeromq 4.3.4 in depends & fix NetBSD 10 build (master...zeromq_4_3_4) https://github.com/bitcoin/bitcoin/pull/23956
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
yanmaani has quit [Ping timeout: 276 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
z0d has joined #bitcoin-core-dev
<fanquake> Blocked 13rAXwNNnaAuCJA3z1REfJbJNMwgK4LBTC from the bitcoin/ org, as they were spamming the wiki in the bips repo
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
yanmaani has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brunoerg has quit [Ping timeout: 240 seconds]
jarthur_ has joined #bitcoin-core-dev
jarthur has quit [Ping timeout: 240 seconds]
z0d has quit [Quit: Textual IRC Client: www.textualapp.com]
jarthur_ is now known as jarthur
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] theStack opened pull request #24106: policy: treat P2TR outputs with invalid x-only pubkey as non-standard (master...202201-policy-treat_p2tr_with_invalid_xpubkey_as_nonstandard) https://github.com/bitcoin/bitcoin/pull/24106
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Ryazur has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
arythmet_ has joined #bitcoin-core-dev
arythmetic has quit [Ping timeout: 250 seconds]
Ryazur has quit [Quit: Client closed]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7102f7d6f3c4...a541e5d51988
<bitcoin-git> bitcoin/master dc5d6b0 Andrew Chow: fs: Make compatible with boost 1.78
<bitcoin-git> bitcoin/master a541e5d fanquake: Merge bitcoin/bitcoin#24104: fs: Make compatible with boost 1.78
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake merged pull request #24104: fs: Make compatible with boost 1.78 (master...fix-fs-path-plus) https://github.com/bitcoin/bitcoin/pull/24104
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jb55 has quit [Ping timeout: 250 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a541e5d51988...63fc2f5cce6a
<bitcoin-git> bitcoin/master e2ab9f8 fanquake: build: disable external signer on Windows
<bitcoin-git> bitcoin/master 63fc2f5 fanquake: Merge bitcoin/bitcoin#24065: build: explicitly disable support for externa...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake merged pull request #24065: build: explicitly disable support for external signing on Windows (master...no_external_signer_win_openbsd) https://github.com/bitcoin/bitcoin/pull/24065
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
sudoforge has quit [Ping timeout: 240 seconds]
sdfgsdfg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
gleb7454 has quit [Ping timeout: 240 seconds]
sipsorcery has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
sipsorcery has quit [Ping timeout: 268 seconds]
vysn has quit [Ping timeout: 250 seconds]
salvatoshi has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 250 seconds]
jespada has joined #bitcoin-core-dev
rex4539_ has quit [Quit: No Ping reply in 180 seconds.]
rex4539 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
jesseposner has quit [Ping timeout: 250 seconds]
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
_flood has quit [Ping timeout: 240 seconds]
gleb7454 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bitcoin_alien[m] has quit [Quit: You have been kicked for being idle]
brunoerg has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
rex4539 has quit [Remote host closed the connection]
rex4539 has joined #bitcoin-core-dev
rex4539 has quit [Client Quit]
rex4539 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] w0xlt opened pull request #24108: Replace RecursiveMutex `cs_addrLocal` with Mutex, and rename it (master...change_cs_addrLocal) https://github.com/bitcoin/bitcoin/pull/24108
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
___nick___ has joined #bitcoin-core-dev
___nick___ has quit [Client Quit]
Guyver2 has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 240 seconds]
kexkey has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
jesseposner has joined #bitcoin-core-dev
arowser has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
morcos_ has joined #bitcoin-core-dev
Aaronvan_ has joined #bitcoin-core-dev
morcos has quit [Ping timeout: 276 seconds]
morcos_ is now known as morcos
brunoerg has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 256 seconds]
vysn has joined #bitcoin-core-dev
paulo has quit [Ping timeout: 256 seconds]
meshcollider has quit [Ping timeout: 256 seconds]
<michaelfolkson> fanquake: Thanks for the blocking notifications
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
yanmaani has quit [Ping timeout: 276 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
yanmaani has joined #bitcoin-core-dev
arowser has quit [Remote host closed the connection]
bitdex has quit [Quit: = ""]
Dezzy has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
pergaminho has joined #bitcoin-core-dev
_flood has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake opened pull request #24111: build: force CRCCheck in Windows installer (master...force_win_installer_crccheck) https://github.com/bitcoin/bitcoin/pull/24111
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest57 has joined #bitcoin-core-dev
Guest57 has quit [Client Quit]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/63fc2f5cce6a...1824644a363b
<bitcoin-git> bitcoin/master 5e7e4c9 w0xlt: refactor: replace RecursiveMutex g_maplocalhost_mutex with Mutex
<bitcoin-git> bitcoin/master a7da140 w0xlt: scripted-diff: rename cs_mapLocalHost -> g_maplocalhost_mutex
<bitcoin-git> bitcoin/master 1824644 MarcoFalke: Merge bitcoin/bitcoin#24099: Replace `RecursiveMutex cs_mapLocalHost` with...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke merged pull request #24099: Replace `RecursiveMutex cs_mapLocalHost` with Mutex, and rename it (master...mutex-mapLocalHost) https://github.com/bitcoin/bitcoin/pull/24099
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Dezzy has quit [Quit: Ping timeout (120 seconds)]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Nikhil has joined #bitcoin-core-dev
Nikhil23 has joined #bitcoin-core-dev
Nikhil23 has quit [Client Quit]
Nikhil09 has joined #bitcoin-core-dev
Nikhil09 has quit [Client Quit]
Nikhil has quit [Client Quit]
Guest15 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake opened pull request #24112: build: pass win32-dll to LT_INIT() (master...libtool_init_win32_dll) https://github.com/bitcoin/bitcoin/pull/24112
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
kabaum has joined #bitcoin-core-dev
<hebasto> nice to see how #19303 is being fulfilled
<gribble> https://github.com/bitcoin/bitcoin/issues/19303 | Replace all of the RecursiveMutex instances with the Mutex ones · Issue #19303 · bitcoin/bitcoin · GitHub
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
grettke has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
kabaum has quit [Ping timeout: 250 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<theStack_> hebasto: indeed \o/ will be tough when it comes to cs_main, the final boss
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] jonatack opened pull request #24113: test, refactor: add GetTransaction() coverage, part 2 (master...rpc_rawtransaction-test-followups) https://github.com/bitcoin/bitcoin/pull/24113
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
jb55 has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Guest15 has quit [Ping timeout: 256 seconds]
Guyver2_ has joined #bitcoin-core-dev
Guyver2 has quit [Ping timeout: 256 seconds]
Guyver2_ is now known as Guyver2
Guest has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 250 seconds]
gleb7454 has quit [Ping timeout: 256 seconds]
Guest has quit [Client Quit]
jb55 has quit [Ping timeout: 256 seconds]
michagogo has joined #bitcoin-core-dev
salvatoshi has joined #bitcoin-core-dev
gleb7454 has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Guest15 has joined #bitcoin-core-dev
Guest15 has quit [Client Quit]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1824644a363b...b60c477d54bb
<bitcoin-git> bitcoin/master faedb11 MarcoFalke: refactor tests to fix ubsan suppressions
<bitcoin-git> bitcoin/master b60c477 MarcoFalke: Merge bitcoin/bitcoin#23629: refactor tests to fix ubsan suppressions
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] MarcoFalke merged pull request #23629: refactor tests to fix ubsan suppressions (master...2111-testInt) https://github.com/bitcoin/bitcoin/pull/23629
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
gleb74543 has joined #bitcoin-core-dev
gleb7454 has quit [Ping timeout: 256 seconds]
gleb74543 is now known as gleb7454
sipsorcery has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
luke-jr has quit [Quit: ZNC - http://znc.sourceforge.net]
luke-jr has joined #bitcoin-core-dev
gleb7454 has quit [Ping timeout: 240 seconds]
salvatoshi has quit [Ping timeout: 240 seconds]
jb55 has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b60c477d54bb...e3ce019667fb
<bitcoin-git> bitcoin/master 36012ef Antoine Poinsot: qa: test descriptors with mixed xpubs and const pubkeys
<bitcoin-git> bitcoin/master e3ce019 Andrew Chow: Merge bitcoin/bitcoin#23171: qa: test descriptors with mixed xpubs and con...
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] achow101 merged pull request #23171: qa: test descriptors with mixed xpubs and const pubkeys (master...desc_test_mix) https://github.com/bitcoin/bitcoin/pull/23171
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
drnet has joined #bitcoin-core-dev
kabaum has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
kabaum has quit [Ping timeout: 256 seconds]
sipsorcery has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
kabaum has joined #bitcoin-core-dev
Kaizen_K_ has quit [Remote host closed the connection]
kabaum has quit [Ping timeout: 256 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] prusnak opened pull request #24115: ARMv8 SHA2 Intrinsics (master...armv8-shani) https://github.com/bitcoin/bitcoin/pull/24115
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
rex4539 has quit [Remote host closed the connection]
rex4539 has joined #bitcoin-core-dev
gleb74543 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Lightsword has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
sipsorcery has joined #bitcoin-core-dev
Lightsword has joined #bitcoin-core-dev
b10c_ is now known as b10c
<laanwj> #startmeeting
<core-meetingbot`> Meeting started Thu Jan 20 19:01:22 2022 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
<core-meetingbot`> Available commands: action commands idea info link nick
<sipsorcery> hi
<b10c> hi
<laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball
<laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
<hebasto> hi
<jonatack> hi
<MarcoFalke> hi
<achow101> hi
<_aj_> hi
<lightlike> hi
<kvaciral[m]> hi
<laanwj> hi
<laanwj> it looks like there have been no proposed meeting topics this week (this can be done using #proposedmeetingtopic <topic>), any last-minute ones?
<jarolrod> Hi
<jeremyrubin> hi
<sipa> hi
<laanwj> #topic High priority for review
<core-meetingbot`> topic: High priority for review
<MarcoFalke> Can I have #23438 pls
<laanwj> https://github.com/bitcoin/bitcoin/projects/8 : 9 blockers, 1 chasing concept ACK
<gribble> https://github.com/bitcoin/bitcoin/issues/23438 | refactor: Use spans of std::byte in serialize by MarcoFalke · Pull Request #23438 · bitcoin/bitcoin · GitHub
<laanwj> MarcoFalke: added
<MarcoFalke> thx
<cfields> hi
<laanwj> anything else to add/remove, or is anything ready for merge?
<_aj_> i think #23508 is rfm but it needs a few more acks :)
<gribble> https://github.com/bitcoin/bitcoin/issues/23508 | Add getdeploymentinfo RPC by ajtowns · Pull Request #23508 · bitcoin/bitcoin · GitHub
<jonatack> #23604 had 4 ACKs before the last rebase, should be close
<gribble> https://github.com/bitcoin/bitcoin/issues/23604 | Use Sock in CNode by vasild · Pull Request #23604 · bitcoin/bitcoin · GitHub
<laanwj> ah yes #23604 should definitely be close, and #23508 too
<gribble> https://github.com/bitcoin/bitcoin/issues/23604 | Use Sock in CNode by vasild · Pull Request #23604 · bitcoin/bitcoin · GitHub
<gribble> https://github.com/bitcoin/bitcoin/issues/23508 | Add getdeploymentinfo RPC by ajtowns · Pull Request #23508 · bitcoin/bitcoin · GitHub
bomb-on has joined #bitcoin-core-dev
<jonatack> #22932 had acks by hebasto, achow101 and vasild. I updated it to take review feedback, re-acks welcome
<gribble> https://github.com/bitcoin/bitcoin/issues/22932 | Add CBlockIndex lock annotations, guard nStatus/nFile/nDataPos/nUndoPos by cs_main by jonatack · Pull Request #22932 · bitcoin/bitcoin · GitHub
<fjahr> hi
<jonatack> it now contains a few commits by hebasto and vasild
rottenstonks_ has joined #bitcoin-core-dev
<jonatack> will look at #23508
<gribble> https://github.com/bitcoin/bitcoin/issues/23508 | Add getdeploymentinfo RPC by ajtowns · Pull Request #23508 · bitcoin/bitcoin · GitHub
<laanwj> great!
brunoerg has joined #bitcoin-core-dev
<fjahr> already started reviewing #23508, should be done soon as well
<gribble> https://github.com/bitcoin/bitcoin/issues/23508 | Add getdeploymentinfo RPC by ajtowns · Pull Request #23508 · bitcoin/bitcoin · GitHub
rottenstonks_ is now known as rottenstonks
<laanwj> any other topics?
<_aj_> is the 23.0 milestone up to date?
<jeremyrubin> if there's nothing else i think it's interesting to talk about making a style-change epoch after split-off
<laanwj> _aj_: i don't know, do you see anything off?
<laanwj> style change epoch? oh no...
brunoerg has quit [Ping timeout: 250 seconds]
<_aj_> laanwj: just wonering if i should go through that a few times before feature freeze
<MarcoFalke> Yeah, let us know if anything is missing from it or should be removed
Guest21 has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<laanwj> #topic Style change after split-off (jeremyrubin)
<core-meetingbot`> topic: Style change after split-off (jeremyrubin)
<jeremyrubin> see #22969
<gribble> https://github.com/bitcoin/bitcoin/issues/22969 | Release schedule for 23.0 · Issue #22969 · bitcoin/bitcoin · GitHub
<jeremyrubin> the concept would be that after split off for T days bigger cleanups can be prioritized
<jeremyrubin> and then after T days, cleanups would not really be considered
<laanwj> not a fan of all-over-the-place changes that break every other PR just for style's sake tbh
<sipa> concept nack in general on invasive style changes
<laanwj> yeah
<jeremyrubin> this is to allow for cleanups while minimizing rebase work
<sipa> refactors that are useful for other reasons... sure, on a case-by-case basis
<laanwj> not sure anyone cares anymore but we used to not do this and i think for good reason
<jeremyrubin> i am nack on the invasive changes as well, but it seems people do continually want things like changing all C style casts
<laanwj> nack on the casts change, not only is it invasive it's risky
<_aj_> https://github.com/bitcoin/bitcoin/issues/15465 maybe relevant history/context
<jeremyrubin> or things like moving class A from file X to file Y to clean a linker supression
<_aj_> personally i like/prefer the "do useful work, and clean up as you go" approach that we're already doing
<laanwj> you mean breaking circular dependencies? yeah, that can be valid
<MarcoFalke> [20:20] <sipa> refactors that are useful for other reasons... sure, on a case-by-case basis
<jeremyrubin> e.g. #17786
<MarcoFalke> Agree with sipa that this is a case-by-case decision
<gribble> https://github.com/bitcoin/bitcoin/issues/17786 | refactor: Nuke policy/fees->mempool circular dependencies by hebasto · Pull Request #17786 · bitcoin/bitcoin · GitHub
Kaizen_Kintsugi_ has quit [Read error: Connection reset by peer]
<sipa> aj: agreew
<laanwj> i don't see that as much of a style thing
<jeremyrubin> well the point would more be to still do these things when they make sense, but contain it to a minimally disruptive part of the release cycle
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<laanwj> circular dependencies are just bad design
<jeremyrubin> laanwj: but you can see how that's very disruptive for rebasing
<laanwj> sure
<jeremyrubin> so the point of a cleanup epoch would be to do cleanups like that only in e.g. the first month after split off
<_aj_> it's maximally disruptive for anything we want to backport to the latest release though?
<MarcoFalke> jeremyrubin: Why would a specific epoch be minimally disruptive? I'd say it depends on the case
<sipa> I conceptually agree that there are better/worse times to make invasive changes (assuming they're justified)... but they also have to be ready at that point.
<jeremyrubin> yeah i'm not tied to a specific time
<sipa> And indeed, when that is depends on the case.
<MarcoFalke> If you are touching a part of the code that no one else is touching, then the time doesn't matter
<jeremyrubin> just thinking that it might be something that leads to less contributor frustration
<jeremyrubin> if people who work on these things know when it is appropriate and people who don't don't have to argue for not merging a conflict
<MarcoFalke> If you are touding a part of the code that is touched by others, then you'll have to order the changes anyway
<sipa> Right, but the risk is that we designate a specific timeframe for refactors... and then we get a torrent of refactors in that time that all conflict with each other.
<jeremyrubin> possibly. although it's not clear it's a bigger problem than as is v.s. just more apparent
<jeremyrubin> if we queue up the refactors and people discuss them before investing time maybe that can help mitigate it
<MarcoFalke> I'd also expect it will be harder to find reviewers if there is a time pressure/specific time slot
<jonatack> seems best to remain ad hoc about it (as it is currently)
<MarcoFalke> If you are worries about invensting time, you can also ask during the meeting if the concept makes sense (or in an issue)
<jeremyrubin> i guess so, it seems sad though because i think it does contribute to burn out and frustration.
<jeremyrubin> i dont spend time on refactors like this anymore afaik so not really concerned for me
<MarcoFalke> Generally writing code is trivial compared to reading and reviewing not so
<MarcoFalke> s/not so//g
<jeremyrubin> i think the main benefit is for people not working on these
<jeremyrubin> If i have a feature/improvement X and there is also a refactor Y in the pipe that would confilict does it makes sense for me to refactor/rebase X?
<jeremyrubin> If I knew that the cleanup work would not pre-empt, i might spend time more actively on X rather than speculating on Y
<jonatack> one can make the argument that adding process can contribute to dev frustration as well
<jeremyrubin> jonatack: good point, process ==bureaucracy, however, it also leads to getting a clear answer on when or how something can proceed
<sipa> I think most frustration is simply due to lack of review feedback. I don't think that designating times for certain kinds of changes will improve that (and it may even work the other way around... "I was told this was the time for this kind of change, and I *still* don't get feedback!?")
<jeremyrubin> i personally favor clear answers v.s. unclear ones
<MarcoFalke> If you think that X should go before Y (or the other way round), you should say so in a review comment
<_aj_> drahtbot already says that when it reports conflicting prs
<jeremyrubin> _aj_ afaict drahbot doesn't analyze for merge order, just for conflicts
<jeremyrubin> and it's buggy w.r.t. silent conflicts
<_aj_> jeremyrubin: no it tells you to figure out which one should go first
<jeremyrubin> (err unsolvable)
<MarcoFalke> Jup, it was the intention behind the comment to focus reviewers on one of the conflicts
<MarcoFalke> DrahtBot re-runs all CI every 9 days, so (some) silent conflicts are now detected
<laanwj> that's good!
<jeremyrubin> anyhow it sounds like most people are happy with the status quo on this stuff so it's not a hill i'd die on
<MarcoFalke> DrahtBot can't tell you which order to merge. This is up to the reviewers
<sipa> I wouldn't say I'm happy - the frustration you speak of, and the impact on contributors is certainly real. I however don't think your suggestion will improve it.
<MarcoFalke> I mean frustration is certainly real, but I think a "refactor window" is not a clear and trivial to solve that.
<lightlike> seems in practice it's more up to the maintainers - I rarely see discussions about merge order amongst reviewers
<laanwj> it would be an indication to the maintainers
<MarcoFalke> lightlike: It is implicit in where people put their ACKs
<jeremyrubin> sipa: fair, i'm not tied to any specific suggestion. is there something else you think might be an improvement?
<sipa> I'm afraid I don't have concrete suggestions.
<laanwj> it definitely happens that someone asks for something to be merged before/after another PR
<jeremyrubin> is this a harmful thing to try over e.g. 2 releases?
<laanwj> not often, but it's also not often necessary
<jeremyrubin> or do we feel confident the problems would exceed the benefit?
<jeremyrubin> i'm all for trying something if the status quo isn't happy and if it doesnt help trying something else
<laanwj> that kind of coordination tends to be pretty hard to do in this project tbh
<sipa> I think it's such a case-by-case thing that trying to institute a process for it isn't helpful.
<MarcoFalke> Jup, would be hard to announce that the next 12 days from today are the "refactor window" and explain what that even means in practice
<_aj_> are there any refactoring tools that make it easy to see "oh you're just changing from Foo* x and x->bar to Foo& x and x.bar" these days?
<jeremyrubin> scripted-diff?
<MarcoFalke> "--word-diff-regex=." ?
<_aj_> i mean syntax aware, rather than textual
<jeremyrubin> there's no tooling for AFAIU testing a scripted diff against all current reported conflicting branches
<_aj_> syntax aware can see I'm changing Foo::bar to Foo::m_bar and see that Baz::bar is unrelated while scripted-diff generally can't eg
<laanwj> syntax/structure aware refactoring tools for c++ are really difficult to do, people have been trying for decades at least
<laanwj> i think clang has some tooling nowadays but it's eally fiddly
* MarcoFalke Let's use clang-refactor in a scripted-diff *hides
<laanwj> for easier to parse languages like java it's quite common
<laanwj> lol
<laanwj> any other topics?
<_aj_> MarcoFalke: yes, exactly! thanks!
<laanwj> #endmeeting
<core-meetingbot`> topic: 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/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
<core-meetingbot`> Meeting ended Thu Jan 20 19:46:54 2022 UTC.
drnet has quit [Quit: Leaving]
<jonatack> i've found a good cure for wanting more process is to go into consulting or industry and work on a process/buzzword/ritual-heavy agile/scrum software project :)
sdfgsdfg has joined #bitcoin-core-dev
<jeremyrubin> noted
<jeremyrubin> hey random question, how does https://en.cppreference.com/w/cpp/thread/call_once work?
<sipa> What do you mean by "how"?
<jeremyrubin> oh nvm
<jeremyrubin> i get it now
<jeremyrubin> i missed you have to pass in your own atomic flag
michagogo has quit [Quit: Connection closed for inactivity]
<jeremyrubin> but still, kinda curious how the flag works practically with exception handling mostly
<sipa> An `std::once_flag` could theoretically be simpler than an `std::atomic<bool>`, as it needs no means of going back from true to false.
<jeremyrubin> well in this case the call_once permits functions that throw
<jeremyrubin> and the others get 'queued up'
<jeremyrubin> and then released once the call finishes sucessfully
<jeremyrubin> and then all side effects can be seen
<jeremyrubin> byt the other callers
Guest21 has left #bitcoin-core-dev [#bitcoin-core-dev]
<sipa> It doesn't sound hard to implement that using a mutex and a condition variable.
<jeremyrubin> yeah but this is just using an atomic flag
<sipa> Though I suspect most platforms offer far more efficient ways of accomplishing that (pthreads has a primitive for it, I think).
<jeremyrubin> ah ok
<jeremyrubin> would it be totally wild to use this in rewriting some of the caching logic for CTV to be cache-on-first-use?
<sipa> I have no opinion on that.
<jeremyrubin> no concerns about using call_once at all from consensus/script interpreter code?
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
kabaum has joined #bitcoin-core-dev
vysn has quit [Ping timeout: 240 seconds]
rex4539 has quit []
MarcoFalke has quit [Ping timeout: 245 seconds]
rottenstonks_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
rottenstonks has quit [Ping timeout: 256 seconds]
brunoerg has quit [Ping timeout: 240 seconds]
ZeroMaster has quit [Read error: Connection reset by peer]
jarthur has quit [Read error: Connection reset by peer]
Guest49 has joined #bitcoin-core-dev
Guest49 has quit [Client Quit]
jarthur has joined #bitcoin-core-dev
MarcoFalke has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 256 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
<jeremyrubin> is there a convenient way to attach GDB from a functional test?
<jeremyrubin> i want to test the node, not the test
<achow101> jeremyrubin: you can pause the test with pdb, then attach gdb to the pid of the bitcoind you want to debug
<achow101> there's a doc somewhere describing how to do this
pergaminho has quit []
<achow101> jeremyrubin: https://gist.github.com/fjahr/2cd23ad743a2ddfd4eed957274beca0f#debugging-from-functional-tests (substitute lldb with gdb, it should work)
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<jeremyrubin> yeah makes sense... maybe i will add a flag for it
<jeremyrubin> key word "convenient" :)
<jeremyrubin> maybe some shell aliases or smth
<achow101> you could probably shell alias it
<achow101> although that might be more difficult if the test has multiple nodes and you are trying to debug a specific one
Kaizen_Kintsugi_ has quit [Ping timeout: 240 seconds]
<cfields> jeremyrubin: there's also --wait_for_debugger
<cfields> Oh, whoops, functional. nm.
<jeremyrubin> problem chased down anyways... another victim to a =default constructor lol
<jeremyrubin> still may patch a way to have the node run in debugger of choice and drop to a console on fault
<jeremyrubin> is that something anyone else would like? test.py --with-debugger=lldb|gdb?
<sipa> That sounds useful. But how do you control which node gets debugged?
sudoforge has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] thonkle opened pull request #24116: Document listening on port 0 assigns a random unused port (master...doc-port-0) https://github.com/bitcoin/bitcoin/pull/24116
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jamesob has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<jeremyrubin> sipa: whichever one crashes i guess...
<jeremyrubin> but good point
<sipa> Ah, it only attaches a debugger when a node crashes? That's also useful. And perhaps enough... just add an assert(false) in the codebase where you want to debug.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] mzumsande opened pull request #24117: index: make indices robust against init aborts (master...202201_index_startup) https://github.com/bitcoin/bitcoin/pull/24117
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<jeremyrubin> sipa: well you need to attach before it crashes I guess? but i spose it's not too bad to run test once, report which node *did* crash fail, and run again?
<jeremyrubin> (run again specifying to attach that one
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] Xekyo opened pull request #24118: Add 'sweep' RPC (master...sweep-wallet-rpc) https://github.com/bitcoin/bitcoin/pull/24118
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has quit [Ping timeout: 250 seconds]
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 250 seconds]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git> [gui] jonatack opened pull request #526: Add address relay/processed/rate-limited fields to peer details (master...add-addr-fields-to-peer-details) https://github.com/bitcoin-core/gui/pull/526
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<sugarpuff_> hi guys, I realize this question might not be considered "development" per se, but it is development related: right now the developers (y'all) are under legal attack by Craig Wright. Afaict, Wright is being used a new means of attack against Bitcoin. The last time I witnessed such a serious attack was BitcoinXT, except this time I think the threat is even greater.
<sugarpuff_> My question is: what are the bitcoin developers doing (other than trying to switch to pseudonymous development) to defend against this? I have seen gmaxwell repeatedly call Wright a fraud. If Maxwell actually believes this, then why is he avoiding the legal challenge? I think Bitcoin could lose if this sort of approach (of running away from Wright) continues.
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
tla2k21 has quit [Remote host closed the connection]
jonatack has quit [Ping timeout: 250 seconds]
sdfgsdfg has joined #bitcoin-core-dev
sdfgsdfg has quit [Client Quit]
sdfgsdfg has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 268 seconds]
mekster669 has quit [Quit: mekster669]
<prayank> sugarpuff_: 1. Legal issues are handled by people involved in different ways. Recently few organizations and individuals have tried to support the devs. 2. Greg Maxwell does not directly contribute to Bitcoin anymore as shared by him multiple times. He can respond to your questions on reddit as they are not related to Bitcoin Core. 3. Bitcoin is fine and CSW or any such scammers will not be able to do much. There was a tweet thread which clearl
prayank has quit [Quit: irc thread exit]
brunoerg has quit [Ping timeout: 268 seconds]
mekster6694 has joined #bitcoin-core-dev
<michaelfolkson> sugarpuff_: For more details on a Bitcoin Legal Defense fund feel free to email the address contained in this https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019741.html
<michaelfolkson> "If you have questions or concerns, you can email info at bitcoindefensefund.org. Will share more information in the near future."
<michaelfolkson> Other than that don't think there's anything to discuss here
yanmaani has quit [Remote host closed the connection]
yanmaani has joined #bitcoin-core-dev