< yanmaani>
How come Bitcoin doesn't use a custom assert macro? That way, if NDEBUG is set, assert could be ((void)__VA_ARGS__) instead, allowing for compilation without assertions to be made.
< luke-jr>
yanmaani: afaik it's UB to redefine assert?
< yanmaani>
luke-jr: if assert.h is included, yes
< yanmaani>
but a custom assert macro, i.e. #define assert2(...) is OK
< yanmaani>
and so is redefining assert() without including assert.h
< yanmaani>
so `#ifdef NDEBUG #define assert(...) ((void)__VA_ARGS__) #else #include <assert.h> #endif` should be OK
< yanmaani>
Is there any easy way to get a CPubKey from a CScript or CTxDestination? Or do you simply have to re-implement the logic in SignStep/
< yanmaani>
Can you take the CScript, pass it into Solver(), and then case vSolutions[0] to a key ID?
< yanmaani>
(a CKeyID)
< yanmaani>
oh wait, ToKeyID(ExtractDestination(script)) should work right?
< BlueMatt>
yanmaani: bitcoin core generally has historically treated assert() as "if this isn't true, we probably have buggy hardware, or otherwise may lose funds, continuing is unsafe". so running without assertions is definitely *not* a goal
< jeremyrubin>
keep in mind that it's much safer for the network *as a whole* to shut down as a result of an assertion violation than it is for an assumption to be violated
< jeremyrubin>
but that sounds more like a wizards convo
< yanmaani>
BlueMatt: true, but what if I want to...? but maybe then I should just take the 5 seconds to write another macro :P
< jeremyrubin>
There's an Assume macro i think
< BlueMatt>
what?
< yanmaani>
jeremyrubin: Doesn't that do something else? "This is true else UB"
< jeremyrubin>
no i think the RPCs use it to return errors
< BlueMatt>
you asked why bitcoin core doesn't use something other than assert(), I answered why. There is, to my knowledge, nothing in bitcoin core that will abort() in a debug build and not in a release build, which appears to be what you want.
< BlueMatt>
modulo a few subsystem-specific constructs
< jeremyrubin>
yanmaani: if you want to get rid of then, best bet is to e.g. refactor code to not use pointers
< yanmaani>
BlueMatt: right, I understand. And I can sort of see why it wouldn't be worthwhile to add it, either. Since it's a 5 second change and all.
< yanmaani>
jeremyrubin: I was thinking of __builtin_assume, sorry
< jeremyrubin>
There are a few good examples where we use ptrs that could be references or reference_wrappers
< jeremyrubin>
so maybe try to refactor where we're using non nullable ptr asserts
< jnewbery>
yanmaani: I think you're looking for ASSUME(). Take a look in src/util/check.h
< aj>
jnewbery: too many caps
< jnewbery>
oh sorry, you're right. It's just Assume()
< jnewbery>
wumpus: MarcoFalke: I think #21009 is ready for merge. Two ACKs on the current branch, and additional ACKs on recent branches from jonatack and ariard.
< fanquake>
Am I missing something with the opening of description-less PRs, just to fill the description in shortly after?
< fanquake>
Why not just open it with the description, and avoid potential questions. i.e :https://github.com/bitcoin/bitcoin/pull/21749#discussion_r618227797
< hebasto>
fanquake: sorry for that, it was opened as a draft
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21752: scripted-diff: Clarify that feerates are per virtual size (master...2104-docFee) https://github.com/bitcoin/bitcoin/pull/21752
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21754: test: Run feature_cltv with MiniWallet (master...2104-testCltvNoWallet) https://github.com/bitcoin/bitcoin/pull/21754
< bitcoin-git>
[bitcoin] prayank23 opened pull request #21755: Add more info about prefix in error message for invalid address (master...error-address) https://github.com/bitcoin/bitcoin/pull/21755
< jnewbery>
thanks dhruvm
< yanmaani>
In the test framework, is there any way to import a specific private key and use it as change?
< yanmaani>
There's an arg "keypool" in importmulti, but it says "Only allowed when wallet private keys are disabled"
< jeremyrubin>
MarcoFalke: was curious if you have any advice on where I should create/put test vectors for BIP-119
< jeremyrubin>
There seems to be like 5 different places static test vectors go, including a separate repo
< jeremyrubin>
Someone asked for me to make them, which is actually very easy, but deciding where they go is not as simple
< jeremyrubin>
Also it's not clear if they are in the QA repo if i need to make my branch do a submodule update or something?
< yanmaani>
also, I don't even get the error thrown when I try to import privkeys into it
< yanmaani>
Is it even possible, or should I just make a wallet.dat file with the keys hardcoded?
< MarcoFalke>
jeremyrubin: How many vectors are there?
< jeremyrubin>
Well I don't even know which ones would be helpful?
< jeremyrubin>
Using sapio I can churn out ~infinite vectors in 5 minutes of work
< MarcoFalke>
Nice. Then pick the ones that are orthorgonal
< MarcoFalke>
The minimal set that maximizes branch coverage
< jeremyrubin>
Where should they live since they require TX Context?
< jeremyrubin>
just a vector of txs?
< MarcoFalke>
they require the prevout or more of the previous tx?
< jeremyrubin>
nope
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21756: Avoid calling `getnameinfo` when formatting IPv6 addresses in `CNetAddr::ToStringIP` (master...simplify-ipv6-address-formatting) https://github.com/bitcoin/bitcoin/pull/21756
< MarcoFalke>
Looks like there shouldn't be too many branches
< MarcoFalke>
Basically it just checks a hash
< MarcoFalke>
And some size-edge cases
< MarcoFalke>
Just looking at the functional tests. Do you think they are exhaustive?
< MarcoFalke>
Looks like you are using randomness and variable tree size, but that shouldn't increase coverage I guess because verification doesn't concern itself with depth
< MarcoFalke>
So if there are just ~10 vectors you could hardcode them in hex or json and add them to the BIP
< MarcoFalke>
If there are thousands of vectors, it might be better to add them to qa-assets repo
< MarcoFalke>
You could still include the nicest ones in the BIP, I guess
< MarcoFalke>
It is mostly up to you, but for the Bitcoin Core repo we try to avoid commiting large blobs
< jeremyrubin>
yeah maybe i'll just print some small ones
< jeremyrubin>
Should I add a taproot case to the rpc test?
< jeremyrubin>
Do i need a p2sh one which is kinda mathematically impossible?
< jeremyrubin>
I guess I can test that it fails..
< MarcoFalke>
yanmaani: Yes, it is possible to import private keys in tests (just like you would "normally")
< MarcoFalke>
Jup, failing test cases are just as useful as passing ones
< yanmaani>
MarcoFalke: How do I do that, while adding them to the keypool?
< wumpus>
yanmaani: meeting in progress, please delay other discussion until after it
< yanmaani>
I can import public keys with importmulti, but that doesn't support adding private keys as change
< jnewbery>
yanmaani: after meeting, please
< wumpus>
#topic Adding a second BIP editor (jnewbery)
< core-meetingbot>
topic: Adding a second BIP editor (jnewbery)
< jnewbery>
hi
< jnewbery>
luke-jr has been the sole BIP editor for several years, and it seems like he's now overstretched and only able to look at the repo about once a month
< jnewbery>
I suggest that we lighten his load by adding a second BIP editor. BIP2 allows multiple BIP editors and refers to plural BIP editors in several places, eg "The BIP editors are intended to fulfill administrative and editorial responsibilities. The BIP editors monitor BIP changes, and update BIP headers as appropriate."
< wumpus>
would make sense imo
< jnewbery>
kallewoof has recently offered to help with BIP repo maintainence:
< jnewbery>
15:43 < kallewoof> luke-jr: on a serious note, if you want help with the bip maintenance stuff, i'll gladly assist.
< jnewbery>
If he's willing, I propose that add him as a second BIP editor.
< achow101>
Seems like something to discuss on the mailing list really
< luke-jr>
^
< MarcoFalke>
ACK, but seems off topic for this channel
< sipa>
i agree with jnewbery's idea, but ut's something to discuss on the ML
< jnewbery>
Lots of us know kallewoof. I believe he's trustworthy and perfectly capable of fulfilling the required administrative and editorial responsibilities.
< ariard>
i agree on the motivation but same something to discuss on the ml
< wumpus>
it's something to *decide* on the ML, but it's fine to discuss it here once imo
< luke-jr>
FWIW, I did discuss it further with kalle privately; but IMO the timing is very poor for adding another editor right now
< MarcoFalke>
luke-jr: why?
< jnewbery>
luke-jr: why is the timing poor?
< luke-jr>
it seems motivated by an effort to give special treatment to a certain PR, which I hear might be "weaponised" for deceptive propaganda
< jeremyrubin>
I agree with ML, but also maybe we can add a *temporary editor* if current editors have been too busy in the short term
< luke-jr>
would be better to wait until any such concerns are gone
< MarcoFalke>
luke-jr: What do you mean with "special treatment"?
< jnewbery>
I trust that kallewoof would not give special treatment to any PR. The editor's role is not to show preference/dispreference to PRs.
< wumpus>
right the role of BIP editors is to follow the BIP1/2 process, not to pass personal judgement on BIPs besides very basic style criteria
< luke-jr>
MarcoFalke: rushed merging outside the usual triage, without full consideration to the factors in concluding it's RTM
< jeremyrubin>
What sort of breach of duty under the BIP-0002 defined role would an additional editor make?
< michaelfolkson>
It is a tricky situation, the aforementioned PR. I'd like to discuss it and how this type of scenario should be treated in future but better when things have calmed down I think
< jeremyrubin>
As far as you've represented previously, you haven't had time to even look at the BIP341 changes which is why it's not merged.
< luke-jr>
jeremyrubin: right, maybe it's fine, I don't know
< jnewbery>
luke-jr: if you believe that kallewoof is unsuitable and wouldn't fulfil the editor role faithfully, then perhaps you could spell out why you have that concern. It'd save time on the mailing list
< jeremyrubin>
+1 jnewbery
< luke-jr>
jnewbery: I'm not saying he is unsuitable.
< jeremyrubin>
as per BIP-0002, which would need ammending to add kallewoof, BIP authors are responsible for collecting community feedback on both the initial idea and the BIP before submitting it for review. However, wherever possible, long open-ended discussions on public mailing lists should be avoided
< jnewbery>
so what's the concern with timing?
< luke-jr>
jnewbery: I already summarised.
< jeremyrubin>
so if kallewoof is controversial, or an editor, even if better suited to decide on mailing list, we should flesh out what adding an editor means before then
< jeremyrubin>
*an addtl editor
< jeremyrubin>
I'm also very concerned with "weaponised" for deceptive propagand'
< jnewbery>
luke-jr: let me restate your points. Correct me where I go wrong: now is not a good time because a new editor might show preferential treatment to a certain PR. But we don't believe kallewoof would show preferential treatment to PRs. So what's the timing concern
< jeremyrubin>
Is this something we need to be preparing for? Like when the copyright claims were made on the whitepaper?
< luke-jr>
jnewbery: because the motivation appears to be to get preferential treatment; I have been hit with a lot of nagging, apparently for the purposes of passing off ST as "the" activation method period
< jnewbery>
ok, so the concern is not timing, but motivation?
< luke-jr>
jnewbery: it would be better to add an editor when there isn't such things going on
< michaelfolkson>
Shall we continue on the mailing list as previously suggested?
< wumpus>
ok... I don't think this is particularly constructive, let's move it further to the mailing list
< wumpus>
yes
< jeremyrubin>
noting that it's against BIP-0002 to proceed on mailing list
< luke-jr>
jeremyrubin: wut?
< jeremyrubin>
"long open-ended discussions on public mailing lists should be avoided"
< luke-jr>
sigh
< wumpus>
they should be avoided in the weekly core IRC meeting too
< jnewbery>
I'm happy to draft an email to the mailing list, but I'd like to understand the process. What's the process for adding an editor? How does it get decided?
< ariard>
jeremyrubin: on the other point, I don't think bip2 recommend bitcoin-core-dev as a venue, maybe better suitted to #bitcoin or #bitcoin-wizards
< luke-jr>
jnewbery: in the past, it's been the existing editor passes it on, but when I intended to do that in 2018 I found people privately didn't like it, so wider involvement might be better
< jeremyrubin>
well I think it's sort of a weird bind, as luke-jr is the author of 0002 who has the only right to amend it
< luke-jr>
jeremyrubin: BIP 2 doesn't need to be amended for this
< jeremyrubin>
and he's also the editor who judge amendement
< jeremyrubin>
so I think jnewbery is right to ask what the heck the process is
< michaelfolkson>
jeremyrubin: I agree it is a bind but binds aren't solved best overnight
< luke-jr>
IMO what would make sense, is when the timing is reasonable/calm, I can just propose Kalle to the ML and if nobody objects we add him to the README or whatever
< luke-jr>
jeremyrubin: ah, forgot about that
< jnewbery>
it does seem somewhat of a centralization problem. The BIPs repo is a venue for sharing proposed changes to Bitcoin, and one person decides who can update it, and also decides whether or not they should ever be replaced/supplemented?
< wumpus>
yes
< meshcollider>
jeremyrubin: I interpret that "long winded discussion" bit to be about the BIPs themselves, not the process of adding an editor
< luke-jr>
jnewbery: seems like it would be good to have the editor cycle every year or two
< jeremyrubin>
luke-jr: I think that given conflict of interest you should just appoint a disterested editor/owner for BIP-0002
< harding>
luke-jr: I don't agree with the timing issues, but until they're resolved to your satisfaction, is there something we can do to provide you with additional availability so that you can review BIP PRs in a timely manner?
< jonatack>
meshcollider: same
< jeremyrubin>
meshcollider: it's a self-reference bug of how we defined editorship; I agree it should be fixed!
< luke-jr>
harding: hmm, I'm not sure. any suggestions?
< jeremyrubin>
Is it displacing paid consulting work or something? How long do you estimate editing work would take?
< luke-jr>
(I do expect I can get to it before the signalling begins, either way)
< harding>
luke-jr: take over some other work of yours? Help pay for your lawn maintenance person? Something like that?
< michaelfolkson>
I think in summary luke-jr is happy at some point to add an additional editor, appears to be happy with kallewoof if that is the eventual choice but doesn't want it rushed overnight to fix a PR merge issue
< jonatack>
luke-jr: naive suggestion, maybe just take a few minutes to review the PR in question and merge it, issue resolved?
< luke-jr>
as a reminder, though, BIPs *are* just documentation, so there really shouldn't need to be a rush
< michaelfolkson>
I don't this is productive at this point. An email to the mailing list informing the BIP community that an additional editor is sought is probably a good next step
< jeremyrubin>
Well it might be helpful for those implementing ST compatibility for the reference doc for activation to be the latest draft
< jnewbery>
I think that for a project that strives for decentralization, a situation where one person has a role and gets to decide whether they should ever be replaced is completely unsuitable
< jeremyrubin>
AJ's PR does not move 341 to final IIRC (altho perhaps it should be Active)
< michaelfolkson>
jnewbery: luke-jr is saying he is happy to add an additional editor (just not in a rushed manner)
< luke-jr>
harding: right now, I'm churning through dealing with the rebase of BIP8 on top of the ST stuff. I suppose that might go faster if there were people willing to review it. But frankly then it almost sounds like I'm holding the BIPs hostage, and I don't want to do that either.
< yanmaani>
jnewbery: Do the BIP editors have any actual power?
< yanmaani>
I mean, if they'd start to NACK things in bad faith, you could just figure something out if that happens. It doesn't seem like a catastrophic issue.
< jnewbery>
yanmaani: in theory, no. But if a BIP editor were acting unfaithfully they could do something like hold up the merge of a PR that the authors had all ACKed
< ariard>
quis custodiet ipsos custodes?
< jeremyrubin>
What if we just Cordon off the section of the AJ's PR and add a patch that says *activation logic pending further bip editing review, but merged in public information interest*
< michaelfolkson>
There are no other topics right? This doesn't seem to be going anywhere
< wumpus>
there is another topic
< jnewbery>
wumpus: I don't think this one is done
< jnewbery>
I'm still not clear on what the process is for adding a new BIP editor
< jeremyrubin>
This might be an uncomfortable conversation but I think it's important
< jnewbery>
jeremyrubin: +1
< luke-jr>
jnewbery: kallewoof was also AIUI planning to write a new BIP to replace BIP 2. maybe this is another topic to resolve in it.
< jnewbery>
if the answer is "a new BIP editor is added when and only when luke-jr wants to", then I think we need to change that
< luke-jr>
I don't think the current situation is well-defined
< MarcoFalke>
luke-jr: The only factor to consider merging a change is whether the bip author(s) are ok with a change
< jeremyrubin>
I think the main thing is that it seems like procedure stalling over AJ's PR
< MarcoFalke>
(well apart from formatting and technical feasibility, ....)
< jeremyrubin>
I think we *should* fix the process. We should also merge AJ's PR.
< jeremyrubin>
We don't need to depend one on the other
< luke-jr>
jeremyrubin: BIPs PRs merging slowly is not a new thing at all.
< jeremyrubin>
What, if anything, do you need to check in the PR and how long would it take you?
< murch>
I mean, signaling begins this week and it's not documented in a BIP yet.
< wumpus>
yea if the PR is ready for merge it should be merged, in the time of this discussion it could have been merged like 5 times
< jeremyrubin>
Like IMO it seems like less time than this meeting is taken?
< jeremyrubin>
wumpus: +1
< glozow>
I don't understand why the process for adding a new editor would be different based on timing or what PRs are open on the repo
< jnewbery>
I also don't understand that. The two things can be handled separately.
< luke-jr>
murch: signalling does not begin this week
< michaelfolkson>
Someone should propose a process for formalizing the adding a new BIP editor to the mailing list
< murch>
starttime = 2021-04-24 00:00 UTC
< wumpus>
people really want to see it merged, no one disagrees strongly, why not just cooporate luke-jr, i don't really see why we need to escalate this to add a new editor right now
< meshcollider>
BIP PRs merging being merged historically is not a reason to continue being slow forever
< jonatack>
wumpus: same. I don't understand what's to be gained here.
< meshcollider>
Being merged slowly*
< jnewbery>
BIP PRs being merged slowly historically is more evidence that we need to spread the load of BIP repo maintainership
< luke-jr>
wumpus: I have the impression people who really want to see it merged, are for deceptive purposes, and that there is ongoing arguments over it on the PR
< luke-jr>
wumpus: maybe it is RTM, but I don't expect it's 5 minutes to figure out
< jeremyrubin>
also being merged slowly for random things is different than being merged slowly *after being asked for accelerated process*
< michaelfolkson>
glozow: luke-jr is of the view that this is only being requested at this time because of a specific PR merge decision. And it does seem that way
< achow101>
luke-jr: it has ACKs from all 3 BIP authors, is that not sufficient?
< jnewbery>
luke-jr: it doesn't matter whether there are 'ongoing arguments'. The three authors have all ACKed it
< luke-jr>
murch: it's the first diff adjustment after that date
< jeremyrubin>
harding asked you days ago to do it prior to this optech
< wumpus>
separately from that we probably need a new BIP editor, and a process for that, but rushing into that after years of no one showing a single interest in being BIP editor is also a bit strange
< harding>
luke-jr: I can link you directly to each of the authors ACKs.
< jnewbery>
wumpus: kallewoof has shown interest in helping
< luke-jr>
jnewbery: maybe so. I haven't looked.
< jnewbery>
luke-jr: very good. Maybe having an extra editor would help
< jeremyrubin>
wumpus: I've seen others express interest, but lack of clarity around process and not wanting to insult the current editor
< luke-jr>
jnewbery: again, I agree. we should add an editor. I just don't think doing so for this specifically is good timing.
< jnewbery>
I'm not suggesting we do it for this specifically
< michaelfolkson>
jeremyrubin: If there are other possible candidates other than kallewoof it needs a process
< meshcollider>
luke-jr: in the meantime it seems very trivial to go and check the ACKs and then merge it then before proposing the new editor, which would solve the controversial timing issue
< jeremyrubin>
michaelfolkson: are there other candidates?
< wumpus>
meshcollider: right
< jeremyrubin>
ANd I agree it can be discussed on the mailing list
< jnewbery>
I'm still curious what the process is for adding a new BIP editor
< jeremyrubin>
but jnewbery asked a simple question, what's the process
< michaelfolkson>
jeremyrubin: "I've seen others express interest,"
< murch>
So, I see two conflicting statements: you haven't checked whether all three bip authors have acked it, and that would be sufficient, but it would take you more than 5 minutes to figure out. How about you check now. We have a minute.
< jeremyrubin>
and luke answered in essence when I say so
< luke-jr>
meshcollider: but with people trying to politicise it, passing it off as "the activation method" and such, I need to evaluate if the BIP process has any rules/precedent dealing with such things
< jeremyrubin>
which isn't really a process
< jeremyrubin>
I don't think that we need one or two editors, anyone who wants to and is qualified can be added with reasonable support
< michaelfolkson>
jnewbery: The process has not been formalized. If you could draft up a formalized process for the mailing list that would be a productive step
< luke-jr>
meshcollider: (I don't think it does, but I'm not certain.)
< jeremyrubin>
I think 3-5 editors is probably a good amount, odd # preferred
< michaelfolkson>
Next topic....?
< ariard>
i think the best answer we have is we don't have a process to add a new bip editor for now and it's a wider community concern than scope of core dev meeting, so better mailing list
< jeremyrubin>
luke-jr: if you think the optics of adding an editor now are bad, recognize your role in creating the neccessity of it
< wumpus>
clearly there is no process for it at the moment
< luke-jr>
jeremyrubin: that's nonsense.
< wumpus>
like jeremyrubin says we could just add one if there is sufficient support for it
< glozow>
so we are in agreement that jnewbery should draft a proposal for the process and send it to the mailing list?
< wumpus>
then agin I'd prefer if luke-jr agreed
< luke-jr>
glozow: sounds good to me
< jeremyrubin>
I think that -- by your own admission -- you've said there is an appearance that you're holding the BIP hostage
< luke-jr>
if jnewbery is okay with that
< jnewbery>
wumpus: there is certainly sufficient support for it
< luke-jr>
jeremyrubin: stop twisting my words
< jeremyrubin>
That appearance serves to delegitimize the BIP process itself, which is also bad... remove yourself from the situation, just appoint a temporary editor for this BIP
< jeremyrubin>
and then let jnewbery take his time to propose a new process
< jeremyrubin>
this seems to be a natural compromise
< wumpus>
jnewbery: that was fairly clear
< wumpus>
jnewbery: I think you can just propose adding kallewoof as BIP editor on the mailing list and see what the response is
< jeremyrubin>
wumpus: works for me
< jnewbery>
wumpus: who is able to add an editor?
< meshcollider>
Any admin of the Bitcoin org
< wumpus>
if you mean as to github permissions: any admin of the github org
< wumpus>
yes
< jeremyrubin>
so you or sipa?
< jnewbery>
So what would an admin need in order to be satisfied that such support existed?
< jnewbery>
And therefore add a new editor
< michaelfolkson>
Is this PR an emergency? Because I am not aware it is...
< wumpus>
i would prefer if luke-jr agreed to it
< jeremyrubin>
wumpus: by what process would you ignore your preference? it seems unlikely luke-jr would agree
< luke-jr>
jeremyrubin: quit trolling
< wumpus>
but also agree that this is very centralized right now and if he seems to be blocking things, that is not good optics and such either
< luke-jr>
wumpus: I'm not blocking anything. Just doing the same as I have for every other PR for years.
< jeremyrubin>
luke-jr: I don't think it's appropriate for you, the bip editor, to call trying to understand how you've ensconced yourself as editor, trolling.
< jnewbery>
it's not that it's bad optics. It's bad process for the project. And it's a waste of everyone's time
< michaelfolkson>
Is this an emergency PR? If it is I agree it needs emergency measures. If it isn't I think this is a waste of time for all of us
< ariard>
imo it's not a good precedent to have admin of the github org substituting to the lack of bip editor appointment process
< jeremyrubin>
michaelfolkson: it's not a waste of time as this conversation does have to happen now or in the future
< jnewbery>
ariard: there is no process
< jeremyrubin>
michaelfolkson: and that is true absent the current PR in question
< luke-jr>
there are several outstanding issues with BIP 2 that should be revised. I think we identified one more. seems like the action path is best to work on a new BIP to replace BIP 2.
< michaelfolkson>
jeremyrubin: It would be easier to have this conversation without this cloud though
< wumpus>
ariard: agree
< jeremyrubin>
michaelfolkson: I disagree -- then it would be "we have other more pressing things, why have this stupid debate now"
< ariard>
jnewbery: we agree on the lack of process, i'm marking my disagreement on fallbacking to github org admins
< luke-jr>
ariard: there is precedent for BIP editor to add BIP editors; so no problem assuming we wait for reasonable timing
< wumpus>
ariard: then again i'm just trying to do what people in the project want
< jnewbery>
luke-jr: that in itself is a problem
< jeremyrubin>
michaelfolkson: there's no good time, place, etc for this convo because it's fundamental stupid procedure issues
< wumpus>
ariard: if everyone wants kallewoof as BIP editor i'm going to add him
< jnewbery>
wumpus: +1
< jeremyrubin>
michaelfolkson: but it's still necessary
< harding>
+1 kallewoof as BIP editor
< jeremyrubin>
+1 kallewoof
< ariard>
wumpus: yes but i think the discussion belongs wider than a core dev meeting, and we should seek consensus on the mailing list
< wumpus>
i do prefer it to be proposed on the ML as well
< jeremyrubin>
(I'm also +1 to ~anyone else who cares to be editor)
< luke-jr>
jeremyrubin: a good time is when it's not being used as a tool toward some other purpose
< michaelfolkson>
Not knowing the other candidates I wouldn't oppose kallewoof. I don't like it being rushed because of a PR though
< jeremyrubin>
we can seek some rough consensus here tho; to make sure it's not wasting mailing list time
< meshcollider>
+1 kallewoof with a ML proposal too
< wumpus>
jeremyrubin: i think we have consensus here now
< jeremyrubin>
if kallewoof is fundamentally objectionable someone should say so
< wumpus>
jeremyrubin: no one here is disagreeing on it, just about timing
< jeremyrubin>
this reminds me of soft forks and signalling vs not signalling...
< jeremyrubin>
there's value in "people said ok" v.s. "no one disagreed"
< jnewbery>
wumpus: very happy to send a post to the mailing list asking for anyone to step forward with objections. If no-one has a reasonable objection within a week or so, then perhaps we should go ahead and do it
< ariard>
jeremyrubin: right that's a first step but you have a lot of others community dev involved in the bip process than only core
< jnewbery>
I think that's a fair process
< wumpus>
jnewbery:sgtm
< jeremyrubin>
ariard: yep, I'm not nacking going to mailing list
< wumpus>
ok, we have another topic ,so let's move on for now
< meshcollider>
luke-jr: as we said, if it's just that PR merge you're worried about for propoganda sake, please go and review it now before kalle is added, then there is no problem
< luke-jr>
meshcollider: yes, I probably will get a chance within that week timeframe
< wumpus>
#topic 0.20.2 (MarcoFalke)
< core-meetingbot>
topic: 0.20.2 (MarcoFalke)
< MarcoFalke>
Any objections to release 0.20.2 a week or two after 0.21.1?
< luke-jr>
0.20 doesn't have Taproot logic, right?
< MarcoFalke>
luke-jr: no taproot
< MarcoFalke>
luke-jr: But bech32m
< wumpus>
what is the motivation ? ah right, makes sense then
< luke-jr>
at the very least that should be made very clear in the rel notes
< jnewbery>
MarcoFalke: will there be a taproot v0.20 release shortly after?
< MarcoFalke>
jnewbery: No, why?
< luke-jr>
jnewbery: IIRC adding Taproot to 0.20 was a can of worms
< jeremyrubin>
i think if anyones not following the motivation is "I want to send to addresses people give me, but I run 0.20"
< jnewbery>
ah ok then. Never mind
< jeremyrubin>
TBH I'm skeptical of value -- are bech32m addresses expected to be used before 0.20 falls out of service?
< luke-jr>
besides, it won't activate before November
< MarcoFalke>
At this point it might be questionable if anyone upgrades to 0.20.2 even, but we have everything prepared for the release
< jeremyrubin>
(and does a point release extend that deadline?)
< luke-jr>
MarcoFalke: well, could do a rc1 and leave it at that if there's no feedback
< jeremyrubin>
if the question for the topic is just [4/22/21 12:51] <MarcoFalke> Any objections to release 0.20.2 a week or two after 0.21.1?
< jeremyrubin>
then i have no objection :)
< murch>
jeremyrubin: I think the bigger issue would be that 0.20.1 recognizes native segwit v1 addresses encoded as Bech32 as correct?
< MarcoFalke>
murch: It does
< MarcoFalke>
murch: Though, there should be no wallet that produces v1 addresses
< murch>
Well, some wallets implemented experimental Taproot support before BIP350
< luke-jr>
but it can't be used before activation..
< jeremyrubin>
I think the benefits of releasing it as a compiled binary that a used can discover are relatively slim... that it has been backported at all is OK
< jeremyrubin>
MarcoFalke: I think whatever you decide is OK with me
< MarcoFalke>
It would be good to have some kind of process for this
< wumpus>
there's not much overhead to doing a release so if someone wants a release we can do it
< MarcoFalke>
If the process is "just do an rc1", that's fine
< luke-jr>
rc1->final is where things are fuzzy; it makes sense to just not go final in some cases
< luke-jr>
if people want a final, they can test rc1 and report back
< wumpus>
yes
< luke-jr>
if not, it stays at rc1 - that's fine too
< luke-jr>
IMO
< wumpus>
sgtm, at least the backport has a tag then
< MarcoFalke>
ok
< wumpus>
so it doesn't get dropped when the branch goes away