19:00:46 <wumpus> #startmeeting 
19:00:46 <core-meetingbot> Meeting started Thu Mar 18 19:00:46 2021 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:46 <core-meetingbot> Available commands: action commands idea info link nick
19:00:51 <achow101> hi
19:00:54 <jnewbery> hi
19:00:55 <amiti> hi
19:00:55 <sipa> hi
19:00:57 <fjahr> hi
19:00:57 <michaelfolkson> hi
19:00:57 <hebasto> hi
19:01:11 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
19:01:13 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:22 <glozow> hi
19:01:26 <meshcollider> hi
19:01:38 <wumpus> no proposed meeting topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:01:55 <michaelfolkson> I proposed one. Did I do it wrong? :)
19:01:58 <wumpus> (fwiw: you can propose meeting topics with #proposedmeetingtopic during the week)
19:02:07 <wumpus> michaelfolkson: oh? maybe overlooked it
19:02:12 <jeremyrubin> hi
19:02:28 <luke-jr> hi
19:02:30 <wumpus> ah yes
19:02:38 <dongcarl> hi
19:02:46 <luke-jr> [14:35:46] <michaelfolkson> #proposedmeetingtopic Taproot activation PRs and attempting to finalize startheight
19:02:48 <wumpus> Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
19:02:50 <jonatack> hi
19:03:04 <wumpus> luke-jr: yes it was the last line, after a lot of spam, which is why i missed it sorry
19:03:18 <wumpus> any last minute topic proposals?
19:03:54 <wumpus> #topic High priority for review
19:03:55 <core-meetingbot> topic: High priority for review
19:04:11 <achow101> #21392 for me
19:04:14 <gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
19:04:28 <wumpus> https://github.com/bitcoin/bitcoin/projects/8   8 blockers, 2 chasing concept ACKs right now
19:04:32 <sipa> i think #20861 is ready for merge
19:04:35 <gribble> https://github.com/bitcoin/bitcoin/issues/20861 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses by sipa · Pull Request #20861 · bitcoin/bitcoin · GitHub
19:05:09 <dongcarl> Not enough to be a meeting topic but would like to give a quick Guix update once the meeting's over
19:05:37 <jnewbery> sipa: I agree
19:05:45 <wumpus> achow101: 21392 addded
19:05:53 <wumpus> sipa: good to know! will take a look
19:05:56 <jonatack> review beg for #20197
19:05:59 <gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: protect onions in AttemptToEvictConnection(), add eviction protection test coverage by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
19:06:28 <jonatack> repeated ACK by vasild and numerous concept acks
19:06:42 <sipa> jnewbery: will have a look
19:06:45 <sipa> eh
19:06:49 <sipa> jonatack: ^
19:06:57 <jonatack> sipa: ty!
19:07:03 <wumpus> jonatack: will have a look too
19:07:59 <wumpus> any more suggestions for additions/removals?
19:09:07 <wumpus> #topic Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
19:09:07 <core-meetingbot> topic: Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
19:09:47 <michaelfolkson> Ok cool. So after a torturous process of many weeks (which none of us have enjoyed) I think (!) we are close on Taproot activation
19:10:25 <michaelfolkson> achow101 has already linked to his PR implementing Speedy Trial
19:10:49 <michaelfolkson> aj has an alternative PR https://github.com/bitcoin/bitcoin/pull/21377
19:11:31 <michaelfolkson> Now there is obviously the added complication of needing to finalize a startheight
19:11:41 <wumpus> any specific reason to have competing PRs?
19:12:01 <achow101> 21377 uses the MTP start and timeouts, 21392 uses height
19:12:16 <michaelfolkson> aj PR changes less code, uses existing BIP 9 code
19:12:47 <wumpus> right, thanks
19:13:09 <michaelfolkson> There is an added complication that some people seem not like to BIP 8 and so trying to get around using it (I think but I could be wrong)
19:13:27 <michaelfolkson> That is a sense I get (which some people have told me is wrong)
19:14:07 <michaelfolkson> Speedy Trial doesn't have a relaxed proposed timetable
19:14:13 <achow101> people seem to not like some aspects of BIP 8, but the change to heights is generally seen to be a good change
19:14:25 <michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
19:14:30 <luke-jr> ST would be very controversial with MTP, or without a clear documentation/disclaimer
19:14:34 <michaelfolkson> Those are proposed dates
19:15:03 <achow101> no one is trying to "get around using BIP 8" because they don't like it. 21377 exists because it is a minimal change, not because MTP is better or that heights are bad.
19:15:13 <michaelfolkson> So we don't have much time to work with if we are going to keep to that proposed timetable
19:15:37 <michaelfolkson> achow101: I've got the sense that it is more than that (but as I said I've been corrected)
19:16:09 <jeremyrubin> I think that ST with MTP is only really controversial with activate MTP, not activate height
19:16:18 <achow101> michaelfolkson: the objections I've seen have been to the lockinontimeout parameter. please don't generalize that to disliking the entirety of bip 8
19:16:35 <jeremyrubin> It's really easy to get around the signaling periods issue by targetting a mid-signal period activate height and time
19:16:41 <michaelfolkson> achow101: Right but lockinontimeout is in BIP 8
19:16:50 <jeremyrubin> given the short timetable, mining drift will likely be minimal
19:17:12 <michaelfolkson> achow101: So that seems to be the only reason for disliking BIP 8 (at least in my view)
19:17:19 <luke-jr> achow101's proposal seems the least controversial at the moment
19:17:20 <jeremyrubin> s/activate height and time/start,end height and time/
19:17:45 <michaelfolkson> A startheight of May 1st was proposed which doesn't leave much time
19:17:58 <luke-jr> michaelfolkson: it's for signalling, not activation
19:18:06 <achow101> michaelfolkson: it really does not matter and trying to focus on that bip number distinction is bikeshedding, a waste of time, and no one (except you) cares
19:18:08 <luke-jr> a release May 1 is okay with that startheight
19:18:39 <michaelfolkson> achow101: I don't care about it personally :) I just don't want it delaying reviewing of PR(s)
19:19:22 <jeremyrubin> To restate more clearly: The main reason to prefer Achow's w/ start height and time is to fix the issue of a known number of singalling periods by using heights and not times. The main reason to prefer AJ's is smaller diff. Either will work. Because of the 3 month period proposed, we can likely set times so that we have a known number of periods with high confidence.
19:19:42 <jeremyrubin> I don't have a preference either way
19:19:56 <achow101> jeremyrubin: note that 21377 has changed to using an activation height. It only uses MTP for start and timeout time
19:20:10 <jeremyrubin> Yep!
19:20:18 <michaelfolkson> luke-jr: Assuming. a release of May 1 when does the PR need to be merged by?
19:20:39 <michaelfolkson> I'm kind of in the dark on whether the proposed startheight of May 1st is doable
19:20:45 <luke-jr> michaelfolkson: typically there's at least 1 week of a RC
19:21:11 <luke-jr> add a few days to backport I guess
19:21:15 <achow101> Note that the windows signing certificate expires next week. I'm in the process of renewing it currently, but it's a process that takes some time
19:21:23 <jeremyrubin> achow101: my point about known periods is just that if you pick start/end heights that are mid-signaling period there's unlikely to be enough drift to cause an off-by-one in intended # of singaling. I agree that height is superior in general.
19:21:25 <michaelfolkson> And what needs to be done in advance of May 1st. Lots of communication to mining pools, users etc?
19:21:32 <achow101> so any future release will need to wait for that cert to be renewed
19:21:37 <jeremyrubin> and activationheight is agreed on across both proposals
19:21:39 <luke-jr> michaelfolkson: ST is okay because it's okay if ST fails
19:21:55 <wumpus> achow101: good to know
19:22:04 <michaelfolkson> luke-jr: Right but we want to give it as good chance as we can to succeed
19:22:16 <michaelfolkson> Releasing quietly and waiting until it fails shouldn't be the plan
19:22:29 <wumpus> achow101: i guess we have no releases planned immediately so given it cawn be resolved in a month or so it's no big deal
19:22:43 <jeremyrubin> I don't think we should wait for a windows signing cert personally -- I don't like the notion of Microsoft being in the way of bitcoin development
19:23:07 <achow101> jeremyrubin: I expect I'll have it resolved by the time we're ready to make a release anyways
19:23:22 <wumpus> jeremyrubin: that doesn't seem to be the case at all
19:23:22 <meshcollider> Is this going to be 21.1 release, not 22?
19:23:33 <luke-jr> jeremyrubin: we could always publish the unsigned binaries, but it'd be better to not have an odd release
19:24:20 <wumpus> not codesigning it will probably hinder adoption i think that would be even worse and besides there is no real hurry
19:24:26 <michaelfolkson> Normally competing PRs is good, gives a chance for people to pursue different approaches. Given the short timetable I'm not sure if this is as important for this. But obviously not going to ask people to only review one PR
19:25:05 <jeremyrubin> sure, i just don't think we should ever be in a position that we delay anything due to a third party vendor -- if signing binaries with MSFT approval opens us up to coercion, we should probably plan to deprecate that sort of signing. Let's not discuss further in this meeting though
19:25:46 <wumpus> please
19:26:17 <wumpus> there is no talk of coercion at all here, if there was i'd agree with you ,for now we have enough real issues let's not make up any
19:26:41 <achow101> in order to make the May 1st start time, I think we should get 0.21.1 by April 24th at the latest
19:26:52 <wumpus> right
19:26:53 <michaelfolkson> If we are going to change the proposed timetable I personally think that is ok but I can't speak for certain with all the ACKers on this if it changes *substantially* https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
19:27:25 <michaelfolkson> But it sounds like May 1st is doable which is great
19:27:31 <achow101> For 2 RCs, we need to get everything in by April 10th
19:27:57 <jeremyrubin> michaelfolkson: I don't see any concrete dates there?
19:28:06 <jeremyrubin> so I don't know what people are ACKing w.r.t. a timeline
19:28:13 <michaelfolkson> If anyone has concerns though about this timetable please raise them. Personally I think a delay of a few weeks would be ok
19:28:16 <achow101> Since this requires backport, I think having the PRs merged to master by April 3rd is the latest
19:28:27 <achow101> then a week for backport
19:28:35 <achow101> then RC1 and so on
19:28:43 <michaelfolkson> jeremyrubin: They are ACKing the proposal
19:28:52 <wumpus> so the real bottleneck  is trusting the code enough to merge it (including the backport), it is better to not split reviewers over multiple PRs if possible
19:29:20 <achow101> indeed
19:29:26 <wumpus> maybe two competing approaches is fine but let's not open more :-)
19:29:34 <michaelfolkson> wumpus: Personally I would agree. I also don't want it to be rushed. If the timetable needs to be pushed back I think that is ok
19:29:47 <michaelfolkson> But if we can avoid that it would be great
19:30:01 <jeremyrubin> michaelfolkson: I just don't see a specific startheight/startime in the proposal
19:30:04 <wumpus> aiming for april 3 sgtm
19:30:17 <luke-jr> I opened a PR with just the height/user-facing stuff, but it already conflicts between 0.21 and master, so I'm not sure it gains anything over just reviewing+merging achow's as-is
19:30:20 <sipa> 2 weeks (tm)
19:30:22 <wumpus> it is short time though
19:30:34 <luke-jr> let's aim for March 25th then
19:30:36 <luke-jr> :P
19:30:37 <michaelfolkson> jeremyrubin: Good point. The dates were in a follow up email https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
19:30:42 <jeremyrubin> michaelfolkson: so I'm not sure what timetable you think is being ackd
19:30:56 <sipa> let's just focus on code review
19:30:57 <jeremyrubin> Gotcha, but it's unclear that was ACKd. My read is people ACKd the general shape of it
19:31:03 <sipa> let me know what to look at
19:31:07 <wumpus> we should probably delay merging anything that conflicts
19:31:12 <michaelfolkson> jeremyrubin: That's fair challenge
19:31:14 <jeremyrubin> so I think it's fine for core to pick reasonable times
19:31:15 <meshcollider> #21392 
19:31:17 <gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
19:31:31 <meshcollider> FWIW I don't think the size of the diff of achow101's version is really an issue ^
19:31:43 <amiti> my two cents: I don't think either PR is close to being RFM, both need significantly more review. looks like 21392 is currently failing CI. If the goal is to quickly merge with safety, I think 21377 makes more sense (as I stated on the PR)
19:31:46 <wumpus> having to rebase the PR all the time will not make it getting through review easier, after all
19:31:53 <amiti> the diff is much smaller and mostly tests
19:32:04 <wumpus> amiti: +1
19:32:20 <luke-jr> amiti: consensus comes first
19:32:29 <achow101> the ci failure on 21392 should be fixed now
19:33:26 <amiti> achow101: cool, and I'm not opposed to 21392, I'm just saying its a bigger patch requires more review.
19:34:14 <michaelfolkson> I know I sound like a broken record but BIP 8 has been updated and BIP 9 is "dead" according to one of the authors. So from a BIP perspective BIP 8 would be easier. I get amiti's argument that code diff wise AJ's smaller
19:34:37 <jeremyrubin> I don't think "BIP9 is dead" is useful here
19:34:41 <jeremyrubin> the code works fine
19:34:50 <michaelfolkson> Code is most important
19:34:52 <amiti> michaelfolkson: I don't think it makes sense to fixate on the associated bip number. the main difference between these two PRs are using block height vs MTP
19:35:00 <jeremyrubin> the property that achow101's PR improves is a fixed # of signals
19:35:11 <achow101> it comes down to mtp vs block height
19:35:11 <michaelfolkson> amiti: I think there is consensus on block height from what I've seen
19:35:19 <jeremyrubin> The question is if it is worth addtl review on new code.
19:35:30 <jeremyrubin> I agree that height is superior long term
19:35:36 <michaelfolkson> (but there are still a lot of reviewers who haven't looked at it yet)
19:35:39 <amiti> micahelfolkson: I don't think you can claim that there is consensus on either, neither patch has been thoroughly reviewed
19:35:45 <achow101> with mtp, we run the risk of losing 2 signaling periods. with already few signaling periods, this has the possibility of failng to activate due to bad luck
19:35:52 <luke-jr> jeremyrubin: without height, ST doesn't have community support
19:36:01 <achow101> amiti: consensus on the concept
19:36:05 <jeremyrubin> But it's important to mind that for ST, it's a very short window of time (3 months) so by targetting a mid-period we have a known # of signals with high confidence
19:36:13 <luke-jr> amiti: consensus has nothing to do with review
19:36:15 <michaelfolkson> amiti: I'm only basing it on what I've seen in discussions and meetings. I personally don't have a (strong) view
19:36:48 <michaelfolkson> We've had meetings with a number of Core contributors showing up and discussing it
19:36:58 <jeremyrubin> achow101: the risk is tiny with MTP if you target mid signal periods, and only the last one matters
19:37:10 <michaelfolkson> Deliberately off this channel so as not to block this channel for weeks/months
19:37:14 <jeremyrubin> (is my point about mid period times falling on deaf ears?)
19:37:38 <jeremyrubin> you would need a super large hashrate shift to happen, and then we'd have bigger problems
19:37:54 <jonatack> will review both soon
19:38:02 <bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/a65e772fec62...8ec881d3b694
19:38:02 <bitcoin-git> bitcoin/master da2bb69 Pieter Wuille: Implement Bech32m encoding/decoding
19:38:03 <bitcoin-git> bitcoin/master 25b1c6e Pieter Wuille: Add Bech32m test vectors
19:38:03 <bitcoin-git> bitcoin/master fe5e495 Pieter Wuille: Use Bech32m encoding for v1+ segwit addresses
19:38:11 <sipa> \o/
19:38:19 <jnewbery> yay!
19:38:21 <bitcoin-git> [bitcoin] laanwj merged pull request #20861: BIP 350: Implement Bech32m and use it for v1+ segwit addresses (master...202101_bech32m) https://github.com/bitcoin/bitcoin/pull/20861
19:38:24 <jnewbery> thanks wumpus
19:38:30 <wumpus> \o/
19:38:43 <achow101> jeremyrubin: I get that, but both start and end matter.
19:38:43 <jonatack> b-b-b-bech32mmmmmm
19:38:45 <michaelfolkson> jeremyrubin: I think that would be a material change to the proposal
19:38:59 <glozow> :M:
19:39:17 <achow101> jeremyrubin: that would move the start time to april 24th, which also affects our timelin for merging things
19:39:35 <jnewbery> is the conclusion to this conversation going to be that people should review PRs?
19:39:41 <achow101> I guess we could just ignore that first half-period
19:39:41 <wumpus> so summary re: taproot activation: aim for april 3 for 0.21.1rc1, review both PRs asap, please hold up merging conflicting PRs for now
19:39:51 <jeremyrubin> achow101: exactly... it can't hit threshold anyways
19:40:05 <jnewbery> wumpus: sounds good!
19:40:08 <michaelfolkson> Right, agreed jnewbery wumpus
19:40:19 <amiti> wumpus: sounds good :)
19:40:53 <wumpus> if we can make a decision between the two PRs quickly that would be even better
19:41:08 <wumpus> and allow focusing attention, but obviously that shouldn't be done in the meeting
19:42:04 <michaelfolkson> Yup
19:42:18 <luke-jr> only one of them is socially viable anyway..
19:42:19 <wumpus> any other topics?
19:42:19 <amiti> also want to quickly mention #21380, adds fuzz tests to version bits, useful coverage whichever PR/technique we go with
19:42:22 <gribble> https://github.com/bitcoin/bitcoin/issues/21380 | tests: Add fuzzing harness for versionbits by ajtowns · Pull Request #21380 · bitcoin/bitcoin · GitHub
19:42:51 <achow101> dongcarl had one?
19:42:51 <michaelfolkson> amiti: Cool
19:43:08 <luke-jr> achow101: I think he wanted to do it after the meeting tho
19:43:17 <wumpus> achow101: but for after the meeting he said
19:43:23 <wumpus> yea
19:43:28 <dongcarl> Just a quick Guix update once everyone's done discussing :-)
19:43:43 <wumpus> amiti: good point
19:44:12 <midnight> \o/ also!
19:44:39 <wumpus> #endmeeting