19:00:20 <wumpus> #startmeeting
19:00:20 <lightningbot> Meeting started Thu Jul 23 19:00:20 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:20 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:22 <sipa> hi
19:01:28 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
19:01:29 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:01:37 <meshcollider> hi
19:01:40 <jeremyrubin> hi
19:01:52 <jonasschnelli> Hi
19:01:54 <luke-jr> hi
19:01:58 <fjahr> hi
19:02:04 <jeremyrubin> hi
19:02:10 <amiti> hi
19:02:12 <jkczyz> hi
19:02:20 <phantomcircuit> hi
19:02:36 <ariard> hi
19:02:42 <instagibbs> hi
19:02:46 <pinheadmz> hi
19:02:53 <wumpus> one proposed meeting topic for this week: taproot in 0.20 (somethingsomethi)
19:02:54 <aj> hi
19:03:15 <somethingsomethi> hi
19:03:25 <wumpus> any last-minute topics?
19:03:30 <sipa> given that 0.20 is already released, this seems hard
19:03:42 <kanzure> hi
19:03:42 <luke-jr> sipa: 0.20.2
19:03:48 <meshcollider> 8:34 PM <fanquake> #proposedmeetingtopic:  tag rc1
19:03:50 <wumpus> 0.20.0 (and 0.20.1) have been almost released
19:04:16 <somethingsomethi> yes
19:04:23 <somethingsomethi> let me explain
19:04:34 <somethingsomethi> This is something that came up in the taproot-activation channel: When could we actually start an activation cycle?
19:04:40 <wumpus> meshcollider: that's already done, nothing to discuss about that in the meeting I think?
19:04:44 <jeremyrubin> somethingsomethi: usually we wait till the actual topic is switched to
19:04:49 <somethingsomethi> ok
19:04:58 <jnewbery> hi
19:05:02 <meshcollider> wumpus: Yeah I'm confused too haha dw
19:05:02 <aj> wumpus: he meant release not tag
19:05:10 <meshcollider> Isn't it already released?
19:05:11 <wumpus> aj: that's also been done
19:05:20 <wumpus> not at the time he posted that
19:05:31 <meshcollider> 3:58 AM <wumpus> rc1 binaries up https://bitcoincore.org/bin/bitcoin-core-0.20.1/test.rc1/
19:05:37 <meshcollider> \o/
19:05:39 <wumpus> ya
19:05:50 <wumpus> #topic High priority for review
19:05:53 <meshcollider> Easy topic then ;)
19:06:06 <promag> hi
19:06:09 <meshcollider> achow101 wanted #19335 on HP
19:06:11 <gribble> https://github.com/bitcoin/bitcoin/issues/19335 | wallet: Cleanup and separate BerkeleyDatabase and BerkeleyBatch by achow101 · Pull Request #19335 · bitcoin/bitcoin · GitHub
19:06:19 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 11 blockers,  1 bugfix, 3 chasing concept ACK
19:06:26 <troygiorshev> hi
19:07:18 <jeremyrubin> I'll add #19478 as a blocker for me (I don't have any currently slotted)
19:07:21 <gribble> https://github.com/bitcoin/bitcoin/issues/19478 | Remove CTxMempool::mapLinks data structure member by JeremyRubin · Pull Request #19478 · bitcoin/bitcoin · GitHub
19:07:40 <wumpus> meshcollider:added
19:08:25 <wumpus> jeremyrubin: well if it is a blocker for you it should be added as blocker, if not not, it's not like everyone needs to have a blocker slotted every week :)
19:09:10 <jnewbery> I'd like to make some progress on #19398. The first PR in that sequence is #19472 so perhaps that could be added to high priority?
19:09:11 <gribble> https://github.com/bitcoin/bitcoin/issues/19398 | Move remaining application layer data to net processing · Issue #19398 · bitcoin/bitcoin · GitHub
19:09:16 <gribble> https://github.com/bitcoin/bitcoin/issues/19472 | [net processing] Reduce cs_main scope in MaybeDiscourageAndDisconnect() by jnewbery · Pull Request #19472 · bitcoin/bitcoin · GitHub
19:09:22 <jeremyrubin> There's like 70 commits worth of other work that is queued up pending on progress on similar stuff for like the last 6-9 months
19:09:53 <sipa> jeremyrubin: ok, so it's a blocker; no other justification needed :)
19:10:25 <jeremyrubin> Those could be all parallelized I guess, but I don't want to overwhelm review
19:11:19 <wumpus> jeremyrubin: jnewbery  added
19:11:46 <jnewbery> wumpus: dank
19:11:50 <jeremyrubin> tx
19:12:57 <wumpus> #topic taproot in 0.20 (somethingsomethi)
19:13:28 <somethingsomethi> Like I said, this came up in the taproot-activation channel: When could we really start an activation cycle?
19:13:43 <somethingsomethi> Going by the segwit playbook, the activation params would be released in 0.21.1, which is probably about 8 months from now, so some people were wondering if this could be shortened
19:13:56 <wumpus> welcome btw somethingsomethi I don't remember seeing you in a meeting before
19:14:11 <somethingsomethi> yeah, made this account just two hours ago :-)
19:14:28 <somethingsomethi> I'm really more trying to pass messages between irc channels
19:14:41 <luke-jr> I was expecting a 0.20.2 with it, but apparently there's a dependency on wtxid relay?
19:15:36 <wumpus> I think the question of whether to backport it to 0.20.x is completely independent of shortening anything
19:15:51 <jeremyrubin> I think there's sort of a tradeoff; how incompatible is master with 0.20 right now v.s. how incompatible will 0.21 be with 0.20?
19:15:51 <somethingsomethi> for the purposes of the taproot-activation channel, it would be interesting to know how much time there is before anything starts
19:16:02 <luke-jr> wumpus: well, if it didn't have the wtxid dependency, we could release 0.20.2 in a few weeks with it…
19:16:05 <wumpus> I think the expectation is to backport it to that branch when it's ready
19:16:22 <luke-jr> (assuming the usual requirements get met quickly)
19:16:33 <instagibbs> wumpus, that meaning 0.20(handwaving away deps)
19:16:35 <instagibbs> ?
19:16:43 <jeremyrubin> wumpus: or maybe backport it to the current major release/last major release when it's ready
19:16:45 <instagibbs> or whatever branch is ready by then
19:16:54 <wumpus> jeremyrubin: yes
19:17:01 <jeremyrubin> +1, here's to hoping that does mean 0.20 tho
19:17:18 <wumpus> in any case it shouldn't end up in a .0 first
19:17:38 <sipa> i think it's very reasonable that the consensus logic for it goes into a .0
19:17:48 <instagibbs> activation I presume he meant
19:17:48 <sipa> and then activation goes into a .1
19:17:50 <luke-jr> I suppose another option would be to just start the 0.21.0 release process after 0.20.1 gets finalised, so that 0.21.1 could be sooner
19:18:01 <wumpus> I mean the actual activation
19:18:01 <sipa> the real question here is when the consensus logic can be in a release, as that's a lower bound
19:18:15 <wumpus> of course ,preparations can go in sooner
19:18:38 <jeremyrubin> I'm somewhat of the opinion that if a release cycle schedule is holding up when we think a consensus thing gets put out then it makes sense to shift around the release windows, so i agree with luke-jr
19:18:55 <wumpus> but is this really a problem right now?
19:19:08 <jeremyrubin> mac recently released an OS with two version numbers btw so that, e.g., 20.2 is identical to 21.1
19:19:28 <sipa> if there is an expectation to backport the consensus logic to a 0.20 branch, we could take some care to avoid having too many preparation changes in master first
19:19:31 <jeremyrubin> wumpus: in the ##taproot-activation discussion, yes
19:19:38 <wumpus> I'd prefer not to shift along major version schedules too much
19:19:40 <luke-jr> wumpus: I think generally there's a sense that we should have at least a 1 year timeout, and waiting a year before even starting that annoys people :p
19:20:28 <sipa> i wasn't expecting taproot in a 0.20 branch- but i also sympethize with the argument that consensus changes, when reviewed and agreed upon, shouldn't be too strongly affected by bitcoin core's release schedule
19:20:56 <wumpus> in any case, the release schedule for 0.21 is in #18947, is this a problem? do you think it should be moved backward or forward?
19:20:57 <gribble> https://github.com/bitcoin/bitcoin/issues/18947 | Release schedule for 0.21.0 · Issue #18947 · bitcoin/bitcoin · GitHub
19:21:19 <jeremyrubin> I think also that if 0.21 has a bunch of other changes, then people may not upgrade out of major upgrade conservatism
19:21:31 <luke-jr> wumpus: if we're not backporting to 0.20, the sooner 0.21.0 is released the better IMO
19:21:39 <jeremyrubin> So we might be further lengthening adoption until, e.g., 0.22 major
19:22:26 <wumpus> what is the major difference between 0.20 and the curent master branch that you think warrants an early 0.21 release?
19:22:43 <luke-jr> wumpus: my thought is, as soon as 0.20.1 is released and Taproot logic merged, move the 2020-10-01 date to the next day
19:22:59 <jeremyrubin> wumpus: generally I think most end users are woefully confused about what our version number system means.
19:23:02 <luke-jr> wumpus: this would be if wtxid relay + Taproot is seen as too big to backport
19:23:13 <wumpus> we've never based releases on features
19:23:33 <somethingsomethi> except segwit wallet release :-)
19:23:34 <instagibbs> didn't we do it for segwit(and wumpus got upset :) )
19:23:37 <sipa> luke-jr: the goal is having wtxid _deployed on the network_ before a new segwit softfork
19:23:40 <wumpus> every 6 months a new major version is released, minor versions are released for bugfixes and softforks
19:23:41 <wumpus> that's it
19:23:53 <luke-jr> sipa: yes, that'd be why releasing 0.21.0 ASAP?
19:24:02 <sipa> that seems reckles
19:24:22 <luke-jr> sipa: how?
19:24:22 <aj> sipa: i was thinking we should consider not relaying txs with taproot inputs except to wtxid peers
19:24:30 <wumpus> I don't see the need for hurry here to be honest
19:24:36 <luke-jr> sipa: I don't mean bypassing the release process, just starting it sooner.
19:24:48 <sipa> luke-jr: sure, but why?
19:25:00 <cfields_> wumpus: +1
19:25:04 <wumpus> I don't think 'users want this sooner' is a good reason, quality before everything
19:25:19 <jeremyrubin> doesn't prove anything but I did two twitter polls https://twitter.com/JeremyRubin/status/1283873417301639169 and https://twitter.com/JeremyRubin/status/1283879638435950594 which shows people don't really understand versioning fwiw
19:25:26 <luke-jr> wumpus: the release schedule isn't a matter of quality, though, is it?
19:25:46 <sipa> luke-jr: agree, but it's a matter of development cadence
19:25:55 <wumpus> I'm fairly sure a predictable schedule helps there
19:26:12 <wumpus> if people on twitter don't understand the release schedule, explain it to them
19:26:45 <jeremyrubin> i tried and they told me that I'm trying to attack bitcoin :p
19:26:50 <luke-jr> I suppose I could put it in Knots..
19:26:58 <wumpus> sigh
19:26:59 <somethingsomethi> so 0.21.1 around feb it is then?
19:27:02 <luke-jr> was planning to wait in case the protocol has any further changes though
19:27:07 <wumpus> that sounds like just riling up things
19:27:17 <luke-jr> wumpus: ?
19:27:22 <sipa> if there is a strong desire to have taproot earlier in a bitcoin core release, i think we should prefer backporting to 0.20 over accelerating 0.21
19:27:30 <wumpus> "that I"m trying to attack bitcoin" I mean
19:27:32 <luke-jr> ah
19:27:35 <instagibbs> sipa, ok that's fair enough
19:27:37 <sipa> (whether that desire exists, i have no opinion about)
19:27:44 <wumpus> there's lots of trolls on twitter we know that
19:27:44 <luke-jr> sipa: so two backports?
19:27:56 <luke-jr> sipa: one with wtxid relay, then the next with Taproot?
19:28:22 <sipa> luke-jr: i don't have a good answer here -i feel that wtxid deployment will take way longer than people here seem to tolerate for taproot
19:28:31 <sipa> regardless of what releases it goes into
19:28:42 <sipa> as it takes sometimes ~years to get new releases deployed...
19:28:45 <jeremyrubin> it also matches roconnor's complaints
19:28:57 <luke-jr> well, at least then we can tell people "not enough wtxid relay users yet" if they whine about the delay? :p
19:28:59 <jeremyrubin> people should care much more about wtxid relay than taproot in some respects
19:29:16 <sipa> wtxid doesn't really hurt until there are major relay policy changes
19:29:21 <sipa> s/hurt/help/
19:29:33 <wumpus> this is the first time I hear about wtxid relay being a problem for taproot
19:29:43 <wumpus> if I knew this sooner I would not have merged it
19:29:48 <ariard> we talked about it like 2 or 3 meeting away
19:29:50 <luke-jr> wumpus: the lack of it is the problem..
19:29:55 <ariard> when moneyball brought taproot topic
19:30:12 <wumpus> we can still revert that PR I suppose though it sounds like a mess
19:30:19 <sipa> wumpus: the opposite; wtxid is arguably required to be deployed on the network, before we can make major relay policy changes
19:30:25 <sipa> (such as taproot would imply)
19:30:32 <wumpus> ok
19:30:38 <luke-jr> sdaftuar: is wtxid relay protocol stable? should we update the BIP to Proposed status?
19:30:42 <sipa> or any script extension on top of segwit
19:30:59 <ariard> luke-jr: it has been merged yesterday, sipa has some follow-ups needed
19:31:18 <sipa> the follow-ups don't change the (specified part of) protocol
19:31:25 <wumpus> so at least merging it is progress right?
19:31:31 <sipa> yes, definitely
19:31:43 <jeremyrubin> I think the problem is that people are proposing a 4 year rollout timeline for the soft fork, to be conservative. If we're not releasing any clients for that until february it's like 5 years. I think we're inviting controversy if we do that.
19:32:11 <somethingsomethi> any guesstimate on how long the gap between wtxid and taproot would have to be?
19:32:12 <luke-jr> jeremyrubin: ?
19:32:19 <wumpus> february?
19:32:32 <luke-jr> jeremyrubin: I don't see the community tolerating 4 years
19:32:33 <somethingsomethi> *wtxid and taproot rollout
19:32:36 <jeremyrubin> "proposed 0.21.1 release"
19:32:44 <luke-jr> somethingsomethi: depends on how long it takes nodes to upgrade
19:33:07 <somethingsomethi> luke-jr that's why I wrote guesstimate :-)
19:33:09 <jeremyrubin> I don't see it being tolerated either, but I think that's what a decent number of people are expecting and proposing.
19:33:43 <jeremyrubin> By being slow we end up inviting a big kerfuffle UASF thing again.
19:33:50 <wumpus> I really dislike this discussion about tolerating, things are ready when they're ready
19:34:03 <wumpus> it sounds like you're trying to pressure us and I really dislike this
19:34:29 <ariard> You can build most of applications improved by schorr/taproot today (in hacky way though)
19:34:35 <jeremyrubin> you can draw a line between what I'm expressing and what I'm relaying
19:34:36 <somethingsomethi> It's not so much about pressure, if everyone agrees it's at least a year out, then at least we can plan accordingly
19:34:37 <ariard> like ecdsa scriptless scripts
19:34:46 <instagibbs> ariard, i.e., probably not at all :)
19:35:00 <jeremyrubin> sorry if it's coming across as *me* pressuring
19:35:11 <jeremyrubin> I agree with the "release when it's ready" mentality
19:35:22 <wumpus> if you want to push this I'm going to quit as maintainer
19:36:13 <wumpus> I feel enough responsibility for this to not like if things like this get rushed
19:36:38 <sipa> fwiw, i don't think there is much in master today that interacts with taproot, that would be hard to backport
19:37:08 <sipa> i think the bigger question may be wtxid relay
19:37:35 <ariard> instagibbs: I disagree a bit, some people instead of complaining are building on ecdsa while envisioning to upgrade to schnorr
19:37:40 <luke-jr> I guess I can look into backporting that
19:37:41 <ariard> for their use-case, when ready
19:37:48 <aj> sipa: updating secp in a backport would be large, but self-contained, so preumably fine?
19:37:49 <jeremyrubin> sipa: I think we can reasonably release taproot without wtxid relay, no? Taproot blocksonly validation, don't accept things to mempool?
19:37:50 <instagibbs> fantastic ariard
19:37:55 <wumpus> FWIW I like taproot but this is not some shitcoin where we rush features  in to boost the price or something like that
19:38:29 <sipa> jeremyrubin: ugh...
19:38:33 <ariard> jeremryrubin: hmmm wouldn't this break compactblock?
19:38:48 <sipa> aj: yes
19:38:56 <luke-jr> ariard: no?
19:39:05 <instagibbs> sipa, ok so you said it takes time for wtxid relay to propagate, how much time? Is this a hard blocker from even setting a signaling window?
19:39:22 <jeremyrubin> sipa: I mean, whatever is less software work to get it so that clients can take a backport...
19:39:44 <luke-jr> instagibbs: IMO we shouldn't set a signaling window until at the very least Taproot is merged into master..
19:39:45 <ariard> luke-jr: I mean loosing the propagation benefits of validating transaction before seeing them in a block?
19:39:54 <instagibbs> luke-jr, right I assumed that
19:40:06 <instagibbs> I'm asking *bare* minimum
19:40:17 <instagibbs> obviously things take time on top
19:40:25 <luke-jr> ariard: sure, but that's true even without Taproot logic
19:40:29 <jeremyrubin> ariard: the idea would be that wtxid can't be backported, so it's in 0.21. 0.20 gets degraded compactblock performance
19:41:00 <jeremyrubin> luke-jr: good point, all old clients get degraded compactblock
19:41:44 <sipa> instagibbs: i need to think about that
19:41:56 <luke-jr> it would be interesting to split policy acceptance of Taproot, from Taproot consensus deployment
19:42:07 <instagibbs> sipa, roger
19:42:08 <cfields_> jeremyrubin: that sounds interesting to me. sipa: why "Ugh" to that?
19:42:09 <ariard> that sounds a bit awful for network robustness, you will favor connections to upgraded nodes
19:42:36 <luke-jr> ariard: there is no uniform network policy anyway, nor is the network dependent on that
19:42:56 <sipa> well, the network won't actually have any taproot-spending transactions until activation, so i think anything before activation doesn't matter
19:43:34 <jeremyrubin> instagibbs:  an interesting corollary of your point is it may be good to try to backport wtxid relay even earlier (e.g., 0.19 if possible) to boost those #'s
19:43:47 <instagibbs> that might be too difficult/dangerous
19:43:52 <instagibbs> (I dont know)
19:44:32 <luke-jr> well, if we split Taproot consensus vs policy… we only need wtxid relay for policy, right?
19:44:39 <ariard> luke-jr: I was thinking consequences on peer eviction/selection, if you degrade performances of a whole subset of them
19:44:40 <aj> there's been a punch of p2p changes since 0.20 that will probably make backporting wtxid relay a bit hard at this point (not very hard if you just rewrite it; pretty annoying if you try cherry-picking/rebasing)
19:44:42 <luke-jr> so that can proceed in parallel to the consensus/activation
19:46:21 <sipa> luke-jr: i don't see how that is related to splitting anything
19:46:27 <luke-jr> if activation happens ~a year from now, having only consensus logic in 0.20, and wtxid relay + Taproot policy only with 0.21+ seems fine?
19:46:31 <sipa> relay of those relevant transactions won't happen until activation
19:47:20 <luke-jr> sipa: right, which is why we don't need to sort relay issues until closer to activation
19:47:28 <sipa> yes, i agree with that
19:48:08 <luke-jr> we could start the Taproot activation process, and even in the worst case scenario (too few updated to 0.21) have it activate without changing the node policy
19:48:18 <instagibbs> mmmm
19:48:31 <sipa> wumpus: do we have any other topics?
19:48:54 <sipa> i feel the part of the discussion relevant to bitcoin core's release process is over
19:49:35 <wumpus> no, that was all
19:49:37 <wumpus> #endmeeting