<bitcoin-git>
bitcoin/master c4139f0 Hennadii Stepanov: doc: Replace a link to Qt precompiled binaries with compile instructions
<bitcoin-git>
bitcoin/master 5e42f2a Hennadii Stepanov: build: Make <QtBaseDir> default name Qt and VS versions agnostic
<bitcoin-git>
bitcoin/master 6bc4398 Hennadii Stepanov: doc: Suggest using jom instead of nmake
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake merged pull request #22890: doc: Replace a link to Qt precompiled binaries with compile instructions (master...210904-msvc) https://github.com/bitcoin/bitcoin/pull/22890
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<fanquake>
Another step towards removing bdb, is no-longer failing to configure when we don't have it, so that people stop installing it: #23168
<bitcoin-git>
[bitcoin] hebasto opened pull request #23217: [DO NOT MERGE] ci: Test required resources for native Windows tasks (master...211007-mem) https://github.com/bitcoin/bitcoin/pull/23217
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<bitcoin-git>
[bitcoin] jonatack opened pull request #23219: p2p: remove unneeded CNetAddr vector in LookupSubNet() and update/tidy up (master...LookupSubNet-todo-fix) https://github.com/bitcoin/bitcoin/pull/23219
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
AaronvanW has quit [Remote host closed the connection]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jonatack opened pull request #23223: Add NoLockLoggingTestingSetup to test utilities, use in checkqueue_tests (master...alleviate-checkqueue-tests-contention-logging) https://github.com/bitcoin/bitcoin/pull/23223
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
AaronvanW has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
gene has quit [Quit: gene]
AaronvanW has quit [Remote host closed the connection]
<laanwj>
doesn't look like any topics have been proposed for this week (use #proposedmeetingtopic to propose topics you want to discuss in the meeting)
<laanwj>
any last minute ones?
<laanwj>
i think we should cancel the IRC meeting next week due to the IRL coredev meeting
<jeremyrubin>
disagree
<jeremyrubin>
i'd like to move some things onto blockers
<jeremyrubin>
err priority
<laanwj>
well, i'm not going to chair it, feel free to meet anyway
<jeremyrubin>
kk
<jeremyrubin>
also won't be at IRL i think :(
<jeremyrubin>
#topic high priority for review
<laanwj>
eh,
<laanwj>
please leave that to me
<jeremyrubin>
laanwj: "well, i'm not going to chair it, feel free to meet anyway"
<laanwj>
jeremyrubin: next week
<cfields>
hi
* jeremyrubin
slaps forehead
<laanwj>
i'm here now why wouldn't i
<michaelfolkson>
You can always request things are moved to blockers outside an actual meeting right laanwj?
<jonatack>
hi
<cfields>
hehe
<laanwj>
michaelfolkson: yes, sure
<michaelfolkson>
Wouldn't need a meeting next week if that is all jeremyrubin wants to do
<laanwj>
anyhow, yes, high priority for review
<jeremyrubin>
sorry for the read-o, i thought you were saying cancel right now
<michaelfolkson>
A new soft fork is high priority?
Talkless has quit [Quit: Konversation terminated!]
<laanwj>
jeremyrubin: added
<cfields>
"for review"
<jeremyrubin>
michaelfolkson: well, high priority is for communicating personal priority + review precedence. afaiu contributors get to pick what they want there
<jonatack>
the first for performance and lower memory use, the second appears to reduce some of the most frequent lock contentions
<laanwj>
jonatack: intend to look into them
<laanwj>
anything else?
<jonatack>
laanwj: great!
<laanwj>
nothing else to add to high prio? no other topics?
<meshcollider>
We could re-visit the discussion about fanquake now we have a lot of ACKs :)
jamesob has joined #bitcoin-core-dev
<jeremyrubin>
Is this about increased GH permissions?
<michaelfolkson>
What's your best case for the timing of a #21702 merge jeremyrubin? It is an interesting time to put it as your highest priority for review
<michaelfolkson>
Perhaps not the best place for this discussion, probably mailing list is better
<michaelfolkson>
For the PR
<michaelfolkson>
fanquake discussion sounds good
<michaelfolkson>
I think there were a lot of ACKs with two NACKs (from what I saw)
<laanwj>
didn't keep a tally but a lot of people voted +1 for fanquake being able to block people from the github, outside the meeting
<laanwj>
yes
<meshcollider>
FWIW, we had 15 ACKs (darosior, michaelfolkson, jarolrod, fjahr, MarcoFalke, laanwj, dhruv, jnewbery, amiti, ariard, larryruane, sipa, achow101, hebasto, and myself) on IRC in support, while only 2 against (prayank, luke-jr)
<laanwj>
meshcollider: ok!
<jeremyrubin>
i'll ack --> perhaps we can just keep a log wiki somewhere of who is blocked and why
<luke-jr>
laanwj: I don't think the problem is him being able to block spammers, just having full access
<meshcollider>
jeremyrubin: I think the only thing anyone is ever blocked for is unintelligible spam
<laanwj>
to be clear, we only block, ever, for obvious spamming and scamming attempts
AaronvanW has joined #bitcoin-core-dev
<luke-jr>
meshcollider: I've seen a lot of issues locked to stop non-spam discussion lately
<jeremyrubin>
that's fine then, email notification are sufficient IMO
<luke-jr>
(but not sure that's fanquake)
<luke-jr>
laanwj: that isn't accurate
<meshcollider>
luke-jr: I haven't seen that, you'll need to provide specific examples
<luke-jr>
unless the distinction is lock vs block
<laanwj>
luke-jr: i mean block as in making specific users unable to post or PR to the repository
<luke-jr>
meshcollider: I'll bring them up next time; IIRC the last one I noticed was rebroad commenting
<luke-jr>
rebroad may be dense sometimes, but he isn't spam
<laanwj>
rebroad isn't blocked from the repo !!!
<laanwj>
you're bringing other things into this
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dougEfresh opened pull request #23224: [RFC] util: Add suffix byte unit parser for ArgsManager (master...add-args-byte-units) https://github.com/bitcoin/bitcoin/pull/23224
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<michaelfolkson>
I would like more transparency and explanations on why certain issues are locked (if people ask)
<luke-jr>
ok, sorry for the confusion
<michaelfolkson>
But I don't think that is fanquake specific
<lightlike>
luke-jr: the locking of old PRs was done by MacroFalke, see 2021-10-05 09:57 in logs
<jamesob>
(ACK fanquake, fwiw)
<laanwj>
i think the idea is that people open new issues instead of post on ancient ones
<michaelfolkson>
Recently MarcoFalke closed 3 year old issues and told this channel (which was fine I think)
<michaelfolkson>
As long as this channel is told and people can enquire why if there is confusion
<laanwj>
e.g. some old issues and PRs that have been merged years ago keep accumulating replies that don't really apply to the original topic anymore
<meshcollider>
michaelfolkson: He didn't close them, he locked inactive issues which were already closed I think
<michaelfolkson>
meshcollider: Ok sure, thanks for correction
<laanwj>
right
<laanwj>
in any case i think it makes sense to post why before closing/locking an issue, i tend to to that unless it's obvious
<meshcollider>
(locking issues is also a lower permission than maintainer, a number of other users have that permission)
<meshcollider>
The "issue management" team
<laanwj>
right
yanmaani has quit [Ping timeout: 276 seconds]
<laanwj>
in any case, if your pR or issue is closed and you disagree, bring it up here
<jeremyrubin>
maybe we should just declare issue/pr bankruptcy and close everything w/o activity in the last week and allow folks to reopen if they want, that way there's less 'moral judgement' of should be closed or not and we can just clean shop
<laanwj>
doing issue management is simply needed in a busy project like this, and i'm sure there are mistakes sometimes
<meshcollider>
jeremyrubin: if an issue is closed by a maintainer I don't think the user can re-open it themselves
<jeremyrubin>
we could do a 'reopen bot' that checks for a request to reopen as a comment... but i know that's extra work for someone
<laanwj>
why would that need a bot
<laanwj>
simply ask a maintainer when it happens
<laanwj>
or better, simply post here
<jeremyrubin>
didn't want to make more work for maintainer as noted by meshcollider, but I agree that works
<jonatack>
meshcollider: seems so, i've had pulls unilaterally closed several times this year and had to open a new pull
<luke-jr>
jeremyrubin: not all of us have funding to touch every PR once a week; sometimes it takes me months to address things
<laanwj>
jonatack: why didn't you ask to reopen them?
<meshcollider>
^
<jonatack>
laanwj: wu wei, going with the flow i guess :D
<jeremyrubin>
luke-jr: i'm saying do it as a 1x pr-bankruptcy, not every week. (maybe 1x a year?)
<michaelfolkson>
It seems communication could be improved in both directions between PR authors and maintainers :)
<michaelfolkson>
Definitely ask next time jonatack :)
<meshcollider>
I think this is a very separate conversation anyway
<laanwj>
jonatack: heh
<jonatack>
i mean, it's not important, just confirming meshcollider's statement
<laanwj>
i think that concludes the meeting
<laanwj>
luke-jr: in your case we know that, it's sometimes different with new contributors that open a PR then never respond again :)
<laanwj>
#endmeeting
<laanwj>
oh, yeah, no bot
<cfields>
## meep morp, meeting adjourned.
<laanwj>
:D
<jeremyrubin>
michaelfolkson i moved it to my high priority since i'm not going to be able to attend IRL it seems, that was the appropriate other choice for communicating my intent.
<jeremyrubin>
there is no specific timeline i have, i'm noting that it would be good to get more eyes on it
<jonatack>
yes iirc the guideline has been that anyone can request more or less any pull, the only limit being just normally not more than one at a time of their own
<jeremyrubin>
the PR itself contains no deployment params, so is fully revertible. nor does it change any standardness rules. so it'd be fine to merge it (assuming correct) and then discuss potential deployment (as was done with e.g. taproot). i'm not advocating that before technical consensus is reached, just explaining how the software works.
<michaelfolkson>
I think at some point there will need to be a discussion on where people are standing on "the next soft fork", possible timing, makeup of it. Ideally that discussion would be put off as long as possible though imo
<michaelfolkson>
I suspect there will be some strong disagreements
<laanwj>
normally only one per person, we do have two PRs in the list by jeremyrubin now, but i guess the mempool optimization is dissimilar enough it's not really an issue
<jeremyrubin>
yep, as noted welcome to remove that if you like. but i don't really have the motivation to push on that one really much further at present, i'm hoping some other contributors will prioritize seeing it through beyond basic maitnenance.
<jeremyrubin>
michaelfolkson: can you say more about what you view as this timeline for when things can or cannot be discussed?
<jamesob>
laanwj: sorry, missed the beginning of the meeting. can I add #23174 to high prio list?
<michaelfolkson>
jeremyrubin: I can only speak for myself. But putting something as high priority today if the plan is for a soft fork in e.g. 2 years (name a longish period from now) seems bizarre to me. That's why I asked on best case timing
<jamesob>
jeremyrubin: I'm definitely in the process of doing a conceptual evaluation of OP_CTV for myself atm - specifically in the context of covenants for vaulting
<michaelfolkson>
Anything can be discussed whenever people want to discuss them. But prioritizing is the act of weighing up what is most urgent, important versus other possible priorities
gene has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
<_aj_>
laanwj: (maybe it would make sense to rename high-pri to "top-pri" as in "this is contributor x's top priority pr")
<jeremyrubin>
well, I put it on priority for review since i've been talking with more and more potential users of CTV there seems to be more desire to evaluate it to solve problems (e.g. vaults) as well as to know what kind of timeline there could be. a timeline can't evolve until there's been enough core review.
<jonatack>
laanwj: oh heh, i didn't see there were two now, wasn't commenting on that :D there have been other times as well if i'm not misremembering
<jeremyrubin>
in the conversations i've been having with orgs they seem to want to solve problems on a 6 months to 1 year horizon, beyond that is too far out for them to dedicate resources
<michaelfolkson>
I'm definitely following OP_CTV and have recently discussed it at multiple Socratics, it is really interesting. I just think we potentially strongly disagree on timing and how much time should be given to weighing up what should be in a covenant/vault soft fork before it happens
<michaelfolkson>
But that's only my personal view, I have no idea what other people think
<michaelfolkson>
Anyway, gtg
<jeremyrubin>
i think the orgs i've mostly been speaking to would strongly like *something* in place that's studied to be safe sooner than later so that they can work on getting tech out to end users based on it.
<jeremyrubin>
a better thing can always be added later, but there's a preference to have more options on the table now than there is to design the 'one covnenant system to rule them all'.
<jeremyrubin>
i've not been hyping it as an argument for deployement since i think it could still use more support and review, but there's a list i'm tracking on utxos.org/signals for orgs/ppl that would like ctv
<jamesob>
e.g. vaulting is really compelling for custody operations, and CTV-style covenants could add a ton of security in short order by enabling better forms of them. alternative is doing presigned txns, but proving key deletion is difficult.
<jeremyrubin>
the other one i've seen a lot of excitement for is batch channel creation.
<jeremyrubin>
especially with the El Salvador stuff people are trying to figure out better ways to create a large number of channels w/o resorting to more custodial setups
<_aj_>
jeremyrubin: hmm, bip 119 has (expired) activation parameters currently?
<jaybny2>
think op_ctv doesnt go far enough - but its a good first step, and hope more can eventually more can part of the next soft fork including op_apo
<jeremyrubin>
_aj_: ah yeah i think when i put that in the BIP there may not have been the disabled specific flags. that's that the PR currently uses
<jeremyrubin>
I can update to copy what's in the PR
<_aj_>
jeremyrubin, jamesob: fwiw, when last i looked at the bip, and skimmed the code, it seemed like the simplest possible implmentation of the idea, which resolved the concerns i'd had with earlier versions. i think i'd nitpick how the hash is constructed, but otherwise if the code isn't buggy, it seems plausible
<jeremyrubin>
we also didn't have speedy trial then, which we do now :)
<_aj_>
jeremyrubin, jamesob: i think sighash_group would be a big bang-for-buck feature so it's highest on my list atm (very subject to change), and i'm curious as to whether ctv and sighash_group could be made compatible, so that the same technique to combine sighash_group payments into a single tx could allow combining multiple ctv paymnts into a single tx
<jamesob>
I'm interested in TLUV and any other idea for covenant implementations, but they seem much more general/in-direct/hard to assess for code janitors like me. I think I'm Concept ACK unless I hear reasonable concerns about safety from some of the devs here with grayer beards than mine
<jamesob>
_aj_ where can I read about sighash_group? Must've missed the ML post
<_aj_>
(i think eltoo channels might need ANYPREVOUT and SIGHASH_GROUP, and eltoo factories (3+ participants who can establish off-chain internal channels amongst subgroups) might also need TLUV)
<jeremyrubin>
it's a good question. my preferred technique for that would be to do it as follow on whenever bundles are sufficiently reviewed, and then enable it as a 33 byte hash for CTV only under taproot where the annex contains the bitmask?
<laanwj>
jamesob: added
<jamesob>
laanwj: thanks
<jeremyrubin>
i think the thing that concerns me re bundles and CTV is that it limits the benefits of caching hashes so i'd be worried if the bundle spec were not per input (e.g., bundle spec tag on hash could lead to quad hashing)
<_aj_>
jeremyrubin: yeah, that makes sense to me too. i think CTV is philosophically "SIGHASH_ANYPREVOUT" but without bothering to do the signature, so this would be "SIGHASH_ANYPREVOUT | SIGHASH_GROUP" again without doing the signature, so you'd just be adding a sighash-byte at the start/end to differentiate just like for sigs
<jeremyrubin>
and i also am curious about thinking through allowing overlapping bundles and if there is any merit or use of that
<_aj_>
sighash_group specifies no overlapping bundles
<jeremyrubin>
_aj_ is there a link for most recent thinking on sighash group for jamesob?
<jamesob>
yeah neither duckduckgo nor google turn up results
<jeremyrubin>
_aj_ btw i don't care much about the specific hash construction if you have thoughts on that.
<jeremyrubin>
i think there are tradeoffs any way you define it, but there absolutely could be some benefit to different orders interactions with CAT or SHASTREAM or caching or something
<_aj_>
jeremyrubin: i think my thoughts were just "should use tagged hashes, and maybe otherwise be more similar to taproot than to segwitv0/whatever" but i haven't actually compared or thought about any pitfalls
<jeremyrubin>
Ah
<jeremyrubin>
the main reason not to do a tagged hash is to make it easier to work with on the stack if there is a future CAT fork
<_aj_>
jeremyrubin: pretty easy to construct tagged hashes with CAT though
<jeremyrubin>
at cost of bigger txns
<laanwj>
_aj_: we couldrename it, but i'm not sure top-prio versus high-prio is that much clearer
<jeremyrubin>
is there a benefit to the safety of using tagged hashes?
<_aj_>
laanwj: yeah, i put brackets around things that probably aren't good ideas :)
<_aj_>
laanwj: at least that's a helpful way of thinking about it for me though -- "high pri" sounds like something the "project" thinks is high priority to me, especially if you're a newb; realising it's only indiviual people's things requires a moment of insight...
<_aj_>
jeremyrubin: when you're not trying to sign it, perhaps not?
<jeremyrubin>
i was actually thinking w.r.t. hash construction that doing merkle trees of the outputs would be interesting, but would be very bikesheddy given it would presuppose how some mtree manipulation code would work (and could just be done as a tagged version).
<laanwj>
it might help that the sub-category is called 'blockers', it would be slightly strange if they were blocking the entire project and not one person's work, but yes i understand the confusion
<jamesob>
laanwj _aj_: whatever the list is called, it's really just "where do I look for the next thing to review"
<laanwj>
jamesob: right, that's the idea, just to give people ideas what to review
<jeremyrubin>
_aj_ yeah i did consider it a while back and couldn't think of any benefit and only a mild annoyance in the future so i did a plain hash
<_aj_>
jeremyrubin: maybe if we also had checkdatasig or whatever? though then it'd presumably be people signing components that get CATed to make the hash anyway (if you were signing the full ctv hash, might as well just use checksig/anyprevout, presumably)
<_aj_>
jeremyrubin: you're not on wizards?
bomb-on has joined #bitcoin-core-dev
<jeremyrubin>
oops
yanmaani has joined #bitcoin-core-dev
<jeremyrubin>
_aj_ the checkdatasig thing is interesting, you can actually do eltoo like thing with just CTV and CDS
<jeremyrubin>
so it is possible you'd want to sign hashes?
<jeremyrubin>
That said, it depends if CDS gets a 'raw' API (sign arbitrary message) or if the message to CDS gets hashed (and therefore, can have it's own tag)
<_aj_>
jeremyrubin: that's just emulating ANYPREVOUT because CTV has it (more or less) but CHECKSIG doesn't, no?
<jeremyrubin>
can you reword that? what's it?
bomb-on has quit [Quit: aллилѹіа!]
<_aj_>
jeremyrubin: that's just emulating CHECKSIG-ANYPREVOUT because CTV has ANYPREVOUT (more or less) but CHECKSIG doesn't, no?
<jeremyrubin>
ah, yes
<jeremyrubin>
if you do <H> CTV <PK> CHECKSIGFROMSTACKVERIFY you basically get something that's like anyprevout
<jeremyrubin>
the main difference is no sighash flags
<jeremyrubin>
but you can always e.g. sign a couple copies of the txn with extra *inputs* if you want (no adding outputs)
<jeremyrubin>
then you can do eltoo like stuff with
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
gene has quit [Quit: gene]
AaronvanW has joined #bitcoin-core-dev
gene has joined #bitcoin-core-dev
<gene>
sipa: after messing around with mull for mutation tests, not sure if it's suitable for CI
<gene>
even running mull-cxx (mutation compiler) with only one worker takes 12-16G ram
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
larryruane has quit [Ping timeout: 250 seconds]
ziggie has quit [Ping timeout: 245 seconds]
glozow has quit [Ping timeout: 252 seconds]
fanquake has quit [Ping timeout: 268 seconds]
elichai2 has quit [Ping timeout: 260 seconds]
jarolrod has quit [Ping timeout: 260 seconds]
hugohn has quit [Ping timeout: 250 seconds]
dergoegge has quit [Ping timeout: 250 seconds]
bw has quit [Ping timeout: 250 seconds]
blkncd has quit [Ping timeout: 250 seconds]
hsmiths has quit [Ping timeout: 260 seconds]
jamesob has quit [Ping timeout: 245 seconds]
ziggie has joined #bitcoin-core-dev
hendi has quit [Ping timeout: 252 seconds]
stick has quit [Ping timeout: 252 seconds]
rodarmor has quit [Ping timeout: 250 seconds]
dergoegge has joined #bitcoin-core-dev
glozow has joined #bitcoin-core-dev
sebx2a_ has joined #bitcoin-core-dev
hebasto has quit [Ping timeout: 268 seconds]
hebasto_ has joined #bitcoin-core-dev
stick has joined #bitcoin-core-dev
jkczyz has quit [Ping timeout: 246 seconds]
ajonas has quit [Ping timeout: 246 seconds]
sebx2a has quit [Ping timeout: 268 seconds]
sebx2a_ is now known as sebx2a
RubenSomsen_ has joined #bitcoin-core-dev
ajonas has joined #bitcoin-core-dev
jkczyz has joined #bitcoin-core-dev
RubenSomsen has quit [Ping timeout: 260 seconds]
Evolver has quit [Ping timeout: 260 seconds]
FelixWeis_ has joined #bitcoin-core-dev
moneyball_ has quit [Ping timeout: 252 seconds]
RubenSomsen_ is now known as RubenSomsen
schmidty has quit [Ping timeout: 240 seconds]
schmidty has joined #bitcoin-core-dev
sugarpuff__ has joined #bitcoin-core-dev
FelixWeis has quit [Ping timeout: 268 seconds]
fjahr has quit [Ping timeout: 268 seconds]
FelixWeis_ is now known as FelixWeis
josibake has quit [Ping timeout: 260 seconds]
amiti has quit [Ping timeout: 264 seconds]
sugarpuff_ has quit [Ping timeout: 264 seconds]
Jackielove4u has quit [Ping timeout: 264 seconds]
sugarpuff__ is now known as sugarpuff_
lightlike has quit [Ping timeout: 268 seconds]
fjahr has joined #bitcoin-core-dev
rodarmor has joined #bitcoin-core-dev
Evolver has joined #bitcoin-core-dev
josibake has joined #bitcoin-core-dev
hsmiths has joined #bitcoin-core-dev
elichai2 has joined #bitcoin-core-dev
bw has joined #bitcoin-core-dev
hendi has joined #bitcoin-core-dev
lightlike has joined #bitcoin-core-dev
amiti has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
Jackielove4u has joined #bitcoin-core-dev
jarolrod has joined #bitcoin-core-dev
fanquake has joined #bitcoin-core-dev
larryruane has joined #bitcoin-core-dev
jamesob has joined #bitcoin-core-dev
hugohn has joined #bitcoin-core-dev
blkncd has joined #bitcoin-core-dev
<michaelfolkson>
laanwj: Perhaps the description for High-priority for review could be added to
moneyball_ has joined #bitcoin-core-dev
<michaelfolkson>
Currently it is "These either block other important work in progress, or are necessary for backport to a minor release. Also includes a list of PRs that are in a mergeable state."
<michaelfolkson>
Something like "from the PR author's perspective" after "block other important work in progress"
<michaelfolkson>
The description sounds like it is high priority for the project
<michaelfolkson>
Some may think it is (e.g. the PR author) but to have a new soft fork as a high priority for the project is at least disputable imo
c_arc has joined #bitcoin-core-dev
<jeremyrubin>
what is high priority for the project that's indisputible?
<michaelfolkson>
I guess nothing hence my suggested wording change
<michaelfolkson>
Putting a consensus change as high priority could certainly give the wrong impression to an outside observer (as others have pointed out)
<michaelfolkson>
I don't even know if it can be considered for merging until there is community consensus on it being in the next soft fork can it? If it can't be considered for merging it can't be high priority for the project
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<lightlike>
how could a community consensus form if not through peer review? It's called "high priority for review" after all, not "high priority for merge"
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
lightlike: I'm not sure whether the only way you get peer review is by marking it as "high priority for review" and a "blocker" on Bitcoin Core
AaronvanW has quit [Remote host closed the connection]
mikehu44 has joined #bitcoin-core-dev
<michaelfolkson>
I just think there is (potentially) a fundamental disagreement on how we consider consensus changes in future. Merging a consensus change PR once it has ~5 ACKs on a Core PR doesn't seem to be the right process for a consensus change to me
<TallTim>
Perhaps changes should be factored as to their economic impact, given that this is a financial system after all. UI/UX? Probably minor. Protcol level? Bigger impact.
c_arc has joined #bitcoin-core-dev
<michaelfolkson>
I would factor it by risk personally. And there is nothing more risky than a soft fork other than perhaps a hard fork. Doing one every time a consensus change PR gets ~5 ACKs on the Core repo sounds crazy to me
<michaelfolkson>
But maybe we have to learn that lesson in real life
<jeremyrubin>
tbh soft forks aren't particularly more or less dangerous than other changes we make to bitcoin
<jeremyrubin>
all changes have risks and rewards
<jeremyrubin>
think of it like skydiving vs driving
<michaelfolkson>
I couldn't disagree any more strongly. Even with a soft fork that had overwhelming community consensus (Taproot) activation was concerning
<jeremyrubin>
skydiving isn't more dangerous than driving -- did you know that? it's actually safer
<michaelfolkson>
And that was the safest it gets. Couldn't have had any more community consensus
<jeremyrubin>
but obviously jumping out of a plane is more dangerous than driving a car
<michaelfolkson>
Maybe we just have to have that disputed soft fork so we can learn that lesson
<jeremyrubin>
but when you jump out of a plane you take more precautions than driving, which makes it safer
<jeremyrubin>
so i think you're having the reaction that "it's jumping out of a plane it's so unsafe" and ignoring the fact that we're driving day by day by day
<jeremyrubin>
courting review is a part of "packing the chute", so is the fact that we do signalled activation for soft forks
<jeremyrubin>
i think that leads to the way that we do soft forks for bitcoin being no more unsafe than other changes we make
<michaelfolkson>
I just think the above is nonsense. But I'm not going to be able to convince you
<michaelfolkson>
Either a consensus change has overwhelming community buy in or you take shortcuts and try to get it in with a few reviews on the Core repo
<jeremyrubin>
i think what you're arguing for is tantamount to just shouting that we shouldn't even think about going for another jump because sky diving is so scary when you think about it, and telling people to not bother checking the chute is proprely packed because we shouldn't go because it's so dangerous.
<jeremyrubin>
there's nothing wrong with checking that the chute is properly packed
<jeremyrubin>
there's nothing wrong with reviewing the code for ctv
<jeremyrubin>
i'm really not sure what shortcuts you're accusing me of. i am requesting more reviewers and you are saying that i shouldn't request more reviewers because i'm trying to get it merged with few reviewers
<jeremyrubin>
i think it's utter nonsense and i don't get why you're pursuing these convoluted arguments
<michaelfolkson>
I don't know how we avoid the disputed soft fork then
<jeremyrubin>
i think you're manufacturing factionalized controversy for controversy's sake
<michaelfolkson>
I think there should be overwhelming community consensus on what is in the soft fork. You think you do a soft fork whenever a consensus change gets merged into Core
<michaelfolkson>
(I think)
<jeremyrubin>
i don't see where you are getting that from
<jeremyrubin>
the PR has no activation parameters in it
<michaelfolkson>
Right but once merged into Core the next phase is activation
<jeremyrubin>
presumably core doesn't merge activation parameters until there's community consensus.
<jeremyrubin>
even then, soft forks have signals which can be used as a second safety check for community consensus
<michaelfolkson>
I don't think it should merge consensus code changes until there's community consensus
<jeremyrubin>
we do that pretty often
<jeremyrubin>
many changes to bitcoin core affect the consensus code
<jeremyrubin>
we hope in ways that are not observable, of course
<jeremyrubin>
similar to an un activated soft fork, which should not be observable
<jeremyrubin>
michaelfolkson was there overwhelming community consensus for taproot? for segwit? for CSV? etc?
<jeremyrubin>
can you quantify or qualify what that means?
<michaelfolkson>
For Taproot, yes. I think only contributor I'm aware who NACKed it was on quantum concerns
<michaelfolkson>
That is a very high bar
AaronvanW has joined #bitcoin-core-dev
<jeremyrubin>
so the bar for "overhwhelming community consensus" is just what contributors think?
<jeremyrubin>
it's my recollection there were actually a lot of NACKs for the activation mechanism (you know, the actual fork part)
TheRec has quit [Ping timeout: 246 seconds]
<jeremyrubin>
to the point where a potentially incompatible client was released
<michaelfolkson>
That was activation. And that will happen for the next soft fork too
<jeremyrubin>
so isn't that actually a low bar then?
<jeremyrubin>
well activation code is definitionally consensus code
<michaelfolkson>
So add a disputed soft fork into the mix of activation concerns and you've got quite the bonfire
<jeremyrubin>
are there plans to not reuse speedy trial again? it seemed to go very smoothly
<michaelfolkson>
It hasn't been discussed. I would guess it will be used next time but I'm sure we'll have similar dynamics around the alternative client
<michaelfolkson>
(or at least I'm not aware it has been discussed)
<jeremyrubin>
so you think taproot had community consensus, but what about segwit?
<michaelfolkson>
Speedy Trial seemed to go smoothly for a soft fork with one contributor NACK and although harder to measure what seemed like overwhelming community consensus. I didn't see (m)any people saying Taproot shouldn't be activated
<michaelfolkson>
SegWit was part of a block size, ASICBoost, hard fork war. I'm not sure that is what we should be comfortable with for the next soft fork
<jeremyrubin>
counterpoint, not getting segwit would have been pretty bad for bitcoin overall, no? should we let 'bullies' who don't want bitcoin to progress to roadblock the rest of the network? if we can't get an important upgrade in the face of bad actors, that sounds bad for bitcoin...
<luke-jr>
jeremyrubin: yet you wanted to empower such bullies ;)
<BlueMatt>
can y'all take this to a more appropriate forum? this is not the right place.