<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?
<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]
<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
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
<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 :)
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 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