19:00:45 <wumpus> #startmeeting 
19:00:53 <jnewbery> hi
19:00:53 <luke-jr> o hai
19:00:56 <achow101> hi
19:00:58 <jeremyrubin> hi
19:00:59 <amiti> hi
19:00:59 <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:02 <hebasto> hi
19:01:02 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:13 <fjahr> hi
19:01:17 <sipa> hi
19:01:22 <lightlike> hi
19:01:23 <meshcollider> hi
19:01:23 <michaelfolkson> hi
19:01:30 <aj_> hi
19:01:39 <wumpus> FYI: you can propose meeting topics with #proposedmeetingtopic during the week, they will appear in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:01:49 <wumpus> These have been proposed for this week: Taproot activation update (michaelfolkson), Addr relay improvements (amiti)
19:01:59 <ariard> hi
19:02:15 <jeremyrubin> wumpus: I proposed 2
19:02:20 <wumpus> any last minute topics anyone wants to discuss?
19:02:23 <michaelfolkson> wumpus: jeremyrubin is going to take the Taproot activation topic(s)
19:02:31 <michaelfolkson> wumpus: So please withdraw mine
19:02:38 <jeremyrubin> 2021-03-25.log:11:44 < jeremyrubin> #proposedmeetingtopic release timeline for Taproot activation and parameters
19:02:39 <jeremyrubin> 2021-03-25.log:11:44 < jeremyrubin> #proposedmeetingtopic SpeedyTrial pull requests #21392 and #21377
19:02:42 <gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
19:02:45 <gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
19:03:36 <wumpus> ok, yes, I was confused there because I didn't see much difference with michaelfolkson's topic, didn't notice the other one
19:03:56 <wumpus> #topic High priority for review
19:04:15 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  has 8 blockers, 2 chasing concept ACK
19:04:33 <wumpus> anything to add/remove or that is ready for merge?
19:04:40 <sipa> oh short topic: how far do we want to backport BIP350/bech32m support?
19:05:16 <wumpus> sipa: noted
19:05:24 <ariard> #19160 is pretty mature and have been ack by jamesob, dongcarl and I, I guess it would benefit from one or two more pairs of eyes
19:05:27 <gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
19:05:27 <sipa> dank
19:06:20 <wumpus> ariard: good to know, thanks
19:06:32 <achow101> topic: windows code signing key issues
19:06:38 <achow101> *topic suggestion
19:06:57 <wumpus> achow101: noted
19:07:18 <wumpus> lots of topics today so let's move on
19:07:21 <wumpus> #topic Addr relay improvements (amiti)
19:07:28 <amiti> Hey all, I opened #21528 yesterday and wanted to share some thoughts around how I see it fitting in to the bigger picture.
19:07:29 <gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [net_processing] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
19:07:33 <amiti> The PR is currently a draft & needs some cleaning up, but serves as a proof of concept. The goal is to reduce addr blackholes- aka relaying self advertisements to peers who are unlikely to continue relaying it to the network.
19:07:37 <amiti> The approach defers initializing the `m_addr_known` for inbound peers until they send us an addr related message. Then, it uses the presence of the filter to decide if a peer is eligible for addr relay before forwarding addresses (in `RelayAddress`).
19:07:41 <amiti> If something like this were to land into master, it would resolve my concern with the `disabletx` proposal, and #20726 / bip 338 could focus solely on transaction handling, while not having the addr blackhole concern block the end goal of increasing block-relay-only connections.
19:07:45 <amiti> That said, avoiding addr blackholes is a standalone win for improving addr relay, and currently would apply to block-relay-only connections as well as light clients.
19:07:50 <gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
19:07:50 <amiti> Also want to mention, I do think this patch would be simpler / safer on top of the net/net_processing addr refactoring that jnewbery is doing. So if anyone is interested in helping, you can review this PR or #21236.
19:07:53 <gribble> https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
19:07:57 <amiti> That’s all! Let me know if you have any questions or feedback :)
19:07:59 <michaelfolkson> needs time to read
19:08:27 <sipa> amiti: is there are risk of having both sides "wait" until they see an addr?
19:08:37 <luke-jr> amiti types fast :P
19:08:55 <amiti> def a risk, but shouldn't be a problem in the implementation
19:09:09 <amiti> also there's asymmetry, we setup addr relay for outbound connections
19:10:05 <jnewbery> in the current implementation, we'll always send our initial self-advertisement to outbounds
19:10:21 <amiti> (other than block-relay-only)
19:10:43 <sipa> not sure how i feel about making the assumption that a peer who doesn't relay addresses to us would be necessarily uninterested in getting them
19:11:05 <jnewbery> if they want them, they can send a getaddr
19:11:05 <lightlike> some peers might be blackholes by not actively sending addrs further, but they will still require addrs. should they use getaddr for that only?
19:11:17 <sipa> jnewbery: ah, that's a good point
19:11:22 <aj> sipa: we send GETADDR to our outbounds always, and consider inbounds non-blackholes if we receive GETADDR
19:11:36 <jnewbery> i think it'd be strange if a node wanted addrs but didn't send a getaddr
19:11:41 <sipa> that's fair
19:11:53 <ariard> i need to think about how it might affect lightclients, not sure if they do addr-relay with any consistency
19:12:24 <wumpus> light clients never do addr relay afaik
19:12:26 <amiti> lightlike: yeah, I don't think we can prevent  all situations of blackholing, but the patch should mitigate some normal usage patterns
19:12:46 <sipa> if we're going to give addresses to a peer, we must assume they can relay them further
19:12:47 <luke-jr> wumpus: but ideally they would
19:12:51 <jeremyrubin> so to summarize; it's basically don't send addrs till they've been requested once?
19:12:54 <luke-jr> or at least keep an addr db
19:13:00 <ariard> wumpus: that's my memory too but ideally they should
19:13:23 <amiti> jeremyrubin: yes but with the added clause of to inbound peers
19:13:47 <sipa> you can't have a mode where you consider a peer both a blackhole, but still give them addresses... because such a state could be abused to bias addr relay
19:14:25 <jnewbery> jeremyrubin: or if that peer has relayed an addr to us
19:14:29 <sipa> so i think it's correct to only use as criterion does this peer _want_ addresses or not; not whether they're going to relay it further
19:14:40 <jeremyrubin> sipa: +1
19:15:21 <jeremyrubin> How much bandwidth does this save amiti?
19:15:35 <jamesob> hi, sorry am late
19:16:07 <sipa> jeremyrubin: i think it's mostly an attempt at avoiding black holing?
19:16:08 <amiti> jeremyrubin: hm, I don't know. the motivation was more about addr relay than bandwidth.
19:16:36 <jeremyrubin> I'm just trying to grok why we care
19:16:44 <jeremyrubin> if it can't stop a malicious peer from becoming a black hole
19:16:54 <amiti> its for reducing the total black holes
19:16:57 <jeremyrubin> why do we care if a honest peer is a black hole?
19:17:13 <jeremyrubin> so we don't advertise them or something?
19:17:23 <jnewbery> jeremyrubin: not much bandwidth. At most we only send one addr message per peer every 30 seconds
19:17:27 <sipa> jeremyrubin: because in general you assume the network has some minimal number of honest peers
19:17:42 <amiti> so, a key component of addr relay is self advertisement. approximately once a day we announce our addr to each peer, and when we receive those messages from others, we relay to 1-2 peers
19:17:47 <aj> jeremyrubin: we only choose a few peers to relay to every day via RelayAddress() don't want to pick ones that don't care about addresses
19:17:49 <sipa> this doesn't have any effect if all your peers are intentionally-blackholing attackers
19:17:54 <amiti> the idea is an ongoing trickle of announcing addrs
19:18:12 <jeremyrubin> Ok I'm just trying to understand why we care about blackholes, which the PR could better motivate
19:18:21 <jeremyrubin> I can take it out of band from the meeting though
19:19:09 <amiti> jeremyrubin: has your question been answered here?
19:19:20 <sipa> seems like a reasonable idea; maybe we can also discuss it further in a P2P meeting
19:19:27 <jnewbery> sipa: right, this isn't effective against peers 'maliciously' not relaying your addrs, but I don't think anything can be, except a diversity of peers.
19:19:36 <sipa> jnewbery: indeed
19:19:46 <jeremyrubin> amiti: no; it's OK though. I just don't see which resource this is saving us
19:20:01 <jnewbery> jeremyrubin: it's not saving a resource
19:20:06 <amiti> its less about resource saving and more about addr propagation
19:20:08 <aj> jeremyrubin: see net_processing::RelayAddress
19:20:10 <sipa> jnewbery: it more a "you *definitely* don't care about addresses? ok, then i'll send them to someone else instead"
19:20:18 <jnewbery> sipa: exactly
19:20:20 <amiti> sipa: exactly
19:20:21 <amiti> :)
19:20:47 <wumpus> time for next topic?
19:20:53 <wumpus> #topic Release timeline for Taproot activation and parameters (jeremyrubin)
19:20:54 <amiti> yeah sounds good
19:20:58 <amiti> thanks for the input!
19:21:25 <jeremyrubin> ok, so we had a meeting on tuesday in ##taproot-activation
19:21:33 <jeremyrubin> I posted notes to bitcoin-dev mailing list
19:21:39 <sipa> amiti: i feel a comic coming up? :)
19:22:14 <jeremyrubin> The outcome of that is that we're looking at a release with parameters in the next month, assuming there's not strong opposition for whatever reason
19:22:18 <amiti> sipa: suggestions always welcome :)
19:22:43 <achow101> didn't we have this discussion last week?
19:22:49 <jeremyrubin> With respect to ST, we agreed that we should fix for a Novemeber 15th height regardless of release date/starttime
19:23:12 <michaelfolkson> achow101: Updates, progress since last week
19:23:13 <jeremyrubin> achow101: it didn't have sufficient heads up that a meeting was happening for it to be a respectful process
19:23:51 <sipa> i'm planning to through all the activation related PRs for code review; new comments on what activation is actually appropriate
19:23:51 <sipa> s/new/no/
19:24:08 <michaelfolkson> +1 for a black hole amiti comic
19:24:23 <michaelfolkson> Full nodes in outer space
19:24:49 <jeremyrubin> can we keep it on topic?
19:25:07 <jeremyrubin> Does anyone have any reservations with a release during April?
19:25:19 <wumpus> summary from last week was: 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:25:28 <wumpus> michaelfolkson: yessss
19:25:37 <achow101> I think we can keep the timeline that we discussed last week
19:25:43 <aj> are we aiming for taproot activation params in rc2 not rc1 then?
19:25:59 <wumpus> aj: w-why
19:26:03 <achow101> aj: rc1, but have space for an rc2 for other issues that may crop up
19:26:05 <luke-jr> aj: no? rc1 should be a cnadidate..
19:26:13 <wumpus> the aim should always be to get things into the first possible rc
19:26:21 <aj> okay
19:26:34 <aj> april 3 sounds very quick!
19:26:37 <wumpus> planning for something to do in rc2 sounds really strange to me but dunno
19:26:42 <jeremyrubin> Ok, wumpus does it seem that we can get rc1 by then?
19:26:48 <wumpus> aj: yes it might be too soon
19:26:52 <wumpus> jeremyrubin: to be honest? no
19:27:22 <michaelfolkson> Are there any follow up PRs planned for either achow101 PR or aj PR? I think achow101 has said he plans at least one follow up. I think all of aj fuzzing PRs are merged?
19:27:27 <luke-jr> jeremyrubin: aim for it, so the inevitable slip is a slip :P
19:27:29 <wumpus> if you mean "can you go through the release process by then" sure, but it seems somewhat rushed, did we decide which of the two PRs to choose yet?
19:27:46 <aj> wumpus: "by then" == "may 1st" ?
19:27:52 <achow101> michaelfolkson: only followup is the activation parameters. other followups don't need backport
19:28:03 <michaelfolkson> achow101: Ok cool
19:28:15 <jeremyrubin> There's some question of which of the PRs. hence sep topic
19:28:19 <achow101> actually april 10th for rc1 still keeps the timeline.
19:28:27 <wumpus> aj: people are talking about *april 3*
19:28:58 <jeremyrubin> w.r.t. the mid-MTP thing, the starttime is less sensitive than the stoptime
19:29:02 <michaelfolkson> I tried writing up the block height versus mix of block height and MTP discussion on a SE question. Suggested edits welcome https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio
19:29:18 <aj> wumpus: i think jeremyrubin's/##t-a's last timeline was rc1 out the door by may 1st?
19:29:20 <jeremyrubin> so I don't think we need to worry that much about releasing with whatever start we want
19:29:21 <wumpus> achow101: bumping it to april 10 does sound a bit more realistic
19:29:33 <luke-jr> MTP was never a viable option to begin with
19:29:46 <BlueMatt> wumpus: in the meeting there was also discussion of "it takes the time it takes, if it slips, ok, if it slips past mid-may, then we bump the eventual lock-in time, if it doesnt, then we always set activation to estimated-release + 1 week or so"
19:29:51 <jeremyrubin> My suggestion was rc1 may 1st, starttime may 7th, 1st period signalling mid may
19:29:54 <wumpus> aj: I was pasting from the conclusion of last week's IRC meeting, I do not know what was discussed elsewhere
19:29:59 <michaelfolkson> Currently achow101 PR is entirely block height and aj PR is a mix of block height and MTP
19:30:01 <aj> wumpus: aha, thanks
19:30:10 <BlueMatt> so the timeline can and shoulld de dependent on when the release finishes, its not a "we have to get release by X"
19:30:24 <BlueMatt> at least in the taproot-activation discussion
19:30:34 <jeremyrubin> BlueMatt: sure, but we should set a schedule we're trying to keep
19:30:40 <achow101> BlueMatt: yes, but also, deadlines are a motivator, even if they are fuzzy
19:30:41 <wumpus> BlueMatt: that's the only thing that makes sense anyway
19:30:42 <jeremyrubin> april 3 seems unrealistic
19:30:51 <sipa> doesn't the start date needs wider coordination? like talking to miners and businesses to see if they're ready to deploy?
19:30:59 <BlueMatt> if we dont know when the code gets merged, then we cant pick a day, until then, the schedule is merge + whatever.
19:31:03 <luke-jr> sipa: if they aren't, they just don't signal
19:31:07 <wumpus> 'do a release at all costs' is a big nope to me
19:31:12 <jeremyrubin> sipa: No; start date is not super sensitive IMO compared to stop date
19:31:23 <luke-jr> sipa: but yes, wider coordination on startheight is important anyway
19:31:25 <sipa> okay, not going to wade into that
19:31:25 <BlueMatt> s/stop/activation/
19:31:41 <jeremyrubin> activation is sensitive OTOH
19:31:53 <jeremyrubin> the outcome of that was we'll project out a height for November 15th
19:31:57 <michaelfolkson> It would be nice to announce a start height as early as we can
19:32:08 <michaelfolkson> But not at expense of rushing
19:32:14 <jeremyrubin> michaelfolkson: doesn't matter till it's in a release
19:32:36 <BlueMatt> anyway, not sure there's more discussion to be had here - the code can be merged when its ready, until then, its just speculation
19:32:38 <wumpus> was one PR chosen? is it clsoe to merge?
19:32:43 <jeremyrubin> next topic?
19:32:45 <BlueMatt> review the code, decide on the pr, and then talk again
19:32:53 <BlueMatt> wumpus: nope, thats up to code review, mostly.
19:32:58 <jeremyrubin> wumpus: (as in, next topic is about that)
19:33:02 <BlueMatt> because, ultimately, no one could decide.
19:33:05 <wumpus> we didn't even decide a PR yet? yes, I think this is pointless like this, let's move on
19:33:08 <sipa> BlueMatt: nack
19:33:14 <luke-jr> wumpus: yes, achow101's
19:33:20 <achow101> both PRs are at one ack
19:33:20 <wumpus> #topic How far do we want to backport BIP350/bech32m support? (sipa)
19:33:23 <BlueMatt> sipa: to...?
19:33:36 <sipa> i *really* dislike using "this things seems to get reviewed faster" as a criterion to decide how consensus changes will be activated
19:33:45 <luke-jr> sipa: not sure why BIP350 would be eligible for backporting at all
19:33:56 <sipa> there should be a clear proposal, with buy-in, and then we implement that
19:34:13 <BlueMatt> sipa: nooooo, thats not what I was suggesting, I was suggesting a part of the criteria is what code reviewers think of it
19:34:29 <sipa> BlueMatt: hmm ok
19:34:30 <wumpus> sipa: right, I don't think it's great to have two competing PRs for this at all, I think it would make sense to choose one and close the other kind of asap
19:34:35 <michaelfolkson> If you'd prefer entirely block height then you'd prefer achow101 PR. Please read my SE link on that
19:34:38 <BlueMatt> as in, which one happens is basically "people are kinda fine with whatever, but if code reviewers feel strongly about one vs the other's safety in code, then we go with that"
19:34:50 <sipa> i'm happy to do code review for all of them
19:34:59 <achow101> luke-jr: presumably to allow sending to taproot without upgrading major release?
19:34:59 <luke-jr> ST (with heights) has wide support; this MTP variant does not.
19:35:00 <wumpus> it really doesn't make sense to discuss a timeline every week if there is no progress in that regard
19:35:03 <sipa> but i'm not going to ack merging until it's clear which one is chosen
19:35:04 <ariard> i've reviewed both,  i've a preference for bip9-amendment, would review both anyway
19:35:07 <michaelfolkson> I personally have a preference for a consistent use of block height across the activation mechanims
19:35:17 <ariard> but better to focus on one
19:35:30 <michaelfolkson> Mixing block height and MTP doesn't make sense to me
19:35:52 <michaelfolkson> But as I said please read my SE post and suggest edits and improvements
19:36:03 <BlueMatt> sipa: ultimately, there's....rather strong personalities who are stuck in the sand on picking one, but a small enough set of people and an equal amount on both sides, so deciding is gonna require code review deciding on code safety :/
19:36:40 <sipa> sigh
19:36:41 <jeremyrubin> wumpus: I agree, but then the most likely outcome is a UASF BIP lOT=true released before we agree on anything, which is precisely what certain people have NACKd
19:36:53 <jeremyrubin> so it seems deleterious to not just decide on one or the other
19:37:03 <michaelfolkson> I think reviewers can come to a view on block height versus a mix of block height and MTP perrsonally
19:37:21 <jeremyrubin> Either can be compatible with a subsequent BIP8 release
19:37:25 <michaelfolkson> jeremyrubin: Any UASF is entirely irrelevant to this discussion
19:37:27 <sipa> i don't care about one or the other; i think all of this is a storm in a cup of water
19:37:32 <sipa> just pick one ffs
19:37:36 <BlueMatt> michaelfolkson: jeremyrubin please take it to taproot-activation.
19:37:39 <ariard> sipa: thanks!
19:37:55 <wumpus> if we want to get to to all the topics today, we should move on
19:38:10 <BlueMatt> sipa: well, the people who show up in taproot-activation are....the people who feel the strongest and the most stubborn about it. without more voices there, there will be no agreement, sadly.
19:38:11 <ariard> we should do a fair coins toss fwiw
19:38:21 <BlueMatt> anyway, lets move on, this isnt the right venue to debate it.
19:38:32 <wumpus> we can also discuss taproot for the rest of the meeting, of course
19:38:55 <luke-jr> thought we were trying to give sipa the floor for BIP350
19:38:57 <wumpus> ~20 mins to go
19:38:57 <achow101> re the actual topic: I think it makes sense to backport to 0.21 and 0.20
19:39:03 <wumpus> sipa: your topic pls
19:39:08 <sipa> hji!
19:39:19 <sipa> so we merged #20861
19:39:22 <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:39:26 <wumpus> yes
19:39:30 <sipa> which adds send-to-bech32m support and related tests
19:39:51 <sipa> amending what address checksum is expected for v1+ native segwit addresses
19:40:06 <sipa> i think this is something that should be backported... it may not matter, depending on activation of course
19:40:13 <jeremyrubin> sipa: maybe backport anywhere taproot is getting backported + 1 version?
19:40:23 <wumpus> let's do that then
19:40:24 <jnewbery> I don't think #21472 is required. 0.19 is out of maintenance, and this isn't a critical fix. It'll be EOL in August: https://bitcoincore.org/en/lifecycle/#schedule
19:40:25 <gribble> https://github.com/bitcoin/bitcoin/issues/21472 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses (0.19 backport) by sipa · Pull Request #21472 · bitcoin/bitcoin · GitHub
19:40:35 <jeremyrubin> I agree you should be able to pay addresses you see, even if you don't know how to create such an address
19:40:56 <sipa> but it would be unfortunate if adoption (once activated etc) is hampered by the fact that you can't send to it from stable bitcoin core releases
19:41:02 <sipa> i'm ok with 0.21 and 0.20
19:41:02 <luke-jr> 0.20 will be end-maint in Aug too
19:41:10 <wumpus> well if he already made a PR for it, then I don't see why not to backport
19:41:25 <sipa> also ok with just 0.21, if that's what we decide
19:41:27 <wumpus> *if* we are going to do another 0.19 release is another question of course
19:41:43 <jnewbery> I've reviewed 0.20 and 0.21. Both look good to me.
19:41:45 <sipa> i just opened backports as far back as they were nontrivial
19:42:01 <luke-jr> seems better to just limit to 0.21
19:42:14 <luke-jr> I don't think anyone plans to backport Taproot itself to 0.20?
19:42:34 <luke-jr> consensus code I mean
19:42:38 <achow101> luke-jr: you don't need taproot in order to make taproot outputs
19:42:40 <wumpus> luke-jr: that doesn't matter here, it's for sending to it
19:42:49 <wumpus> might backport one release further for that
19:43:00 <jeremyrubin> sipa: one question; if taproot doesn't activate can you still send to these addresses?
19:43:15 <luke-jr> achow101: but if you're doing economic stuff, you should be using a full node
19:43:17 <jeremyrubin> Might be kinda weird if you can pay to them before they activate
19:43:44 <jeremyrubin> (that's true for next-release as well as backport)
19:43:46 <sipa> jeremyrubin: being able to send to future addresses is pretty essential for smooth upgrading
19:44:13 <jeremyrubin> sipa: you could only enable sending to them from wallet iff it activates and height > minactiveheight
19:44:18 <wumpus> that would be weird but also, why would anyone do that
19:44:38 <jeremyrubin> not sure, many ways to lose money I spose
19:44:39 <aj> jeremyrubin: been able to send to them since 0.19 due to #15846
19:44:41 <gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
19:44:46 <achow101> jeremyrubin: that removes the upgrade advantage
19:44:46 <wumpus> it doesn't seem like something you can do by accident and there are tons of ways to lose coins if you really want
19:44:51 <jeremyrubin> aj: ack
19:44:54 <achow101> it's up to the receiver to decide whether he wants to lose money
19:45:28 <wumpus> so ok: 0.20 and 0.21?
19:45:31 <sipa> jeremyrubin: also #20165
19:45:33 <gribble> https://github.com/bitcoin/bitcoin/issues/20165 | Only relay Taproot spends if next block has it active by sipa · Pull Request #20165 · bitcoin/bitcoin · GitHub
19:45:37 <achow101> wumpus: ack
19:45:45 <sipa> jeremyrubin: but that's about *spending*, not sending to
19:45:56 <jeremyrubin> hmm
19:46:07 <wumpus> I think we need to move to next topic
19:46:19 <wumpus> #topic SpeedyTrial pull requests (jeremyrubin)
19:46:25 <luke-jr> O.o
19:46:45 <jeremyrubin> There are two open PRs
19:46:49 <wumpus> yes
19:46:57 <wumpus> didn't we go through this already
19:46:58 <jeremyrubin> there is not community consensus on either one
19:47:08 <jeremyrubin> IDK it's the topic again so I thought I'd summarize
19:47:20 <wumpus> well you proposed two topics I don't know why
19:47:27 <wumpus> if it's unnecessary let's move on
19:47:32 <BlueMatt> i think we covered this pretty fully
19:47:35 <michaelfolkson> I agree we need to break the deadlock on the two PRs asap. Spreading review effort over two PRs at this stage is not optimal
19:47:51 <sipa> michaelfolkson: and we're not going to do that here
19:47:53 <wumpus> #topic Windows code signing issues (achow101)
19:48:30 <achow101> The windows code signing key expired yesterday. I've been trying to renew it, but somehow in that process, comodo revoked the key. This is causing users who install 0.20 or 0.21 on windows to be unable to run the installer
19:48:53 <wumpus> uh oh
19:49:04 <aj> yikes
19:49:07 <wumpus> do you know why they revoked the key?
19:49:08 <bitcoin-git> [bitcoin] sipa closed pull request #21472: BIP 350: Implement Bech32m and use it for v1+ segwit addresses (0.19 backport) (0.19...202103_bech32m_0.19) https://github.com/bitcoin/bitcoin/pull/21472
19:49:11 <achow101> comodo has also changed how they are verifying the Bitcoin Core Code Signing Association which is making it harder to get the renewed key. jonasschnelli_ is working on that, but it could be a while
19:49:22 <achow101> so it is possible that for the next release, we may not have a windows code signing key
19:49:33 <achow101> and also we probably need to re-sign 0.20 and 0.21
19:49:43 <wumpus> yes
19:49:45 <achow101> I have no idea why the key was revoked
19:50:01 <achow101> I emailed support and they haven't responded :/
19:50:10 <wumpus> is it possible to install on windows without a signing key?
19:50:16 <achow101> yes
19:50:21 <achow101> there is a non-codesigned installer
19:50:37 <luke-jr> but the codesigned one is a no-go?
19:50:42 <wumpus> can we get a key from a different provider if comodo becomes difficult?
19:51:09 <achow101> luke-jr: pretty much. this is what people see: https://github.com/bitcoin-core/gui/issues/252
19:51:45 <wumpus> should I delete the codesigned one from the website? (or move it out of the way at least)
19:51:46 <achow101> wumpus: yes, but they are way more expensive ($3-400 vs $80 per yr) and probably have similar organization verification requirements
19:52:21 <wumpus> if it is no longer usable it makes no sense to host it, after all
19:52:32 <achow101> sure
19:52:43 <sipa> right
19:52:46 <jeremyrubin> achow101: does the non codesigned one make it harder to install
19:52:49 <sipa> perhaps move it to an archive section or so
19:52:58 <achow101> we have bitcoin-0.21.0-win64-setup-unsigned.exe from the gitian builds which is non-codesigned that we can upload
19:53:06 <luke-jr> good question - why are we even signing it on Windows? XD
19:53:11 <wumpus> sipa: yeah
19:53:16 <achow101> jeremyrubin: it gives a warning iirc
19:53:24 <achow101> but the warning can be ignored
19:53:36 <luke-jr> achow101: doesn't _any_ download?
19:53:39 <wumpus> the only annoyance is that I need to regenrate the SHA256SUMS.asc, and ideally the torrent too
19:53:46 <wumpus> oh can it be ignored?
19:53:48 <luke-jr> only difference IIRC was that signed just shows an author name
19:53:57 <emzy> does it make sense to have 2 signing certs just in case for problems like this?
19:54:07 <achow101> luke-jr: it says something about "untrusted" if it isn't code signed. I think that's just about it
19:54:10 <luke-jr> wumpus: maybe wait on the torrent until we have a full resolution?
19:54:33 <luke-jr> emzy: doubt you can sign it twice
19:54:50 <jeremyrubin> FWIW; I don't think it makes sense to hold out on any releases that are ready to go based on this issue
19:54:56 <wumpus> the process is kind of a hassle so I'm not going to do this for all releases, but for the last 0.20.x and 0.21.x release sure
19:55:09 <sipa> jeremyrubin: agree, but we should also try to fix it going forward
19:55:24 <jamesob> (aside) maybe at some point we can stop doing Windows releases altogether and just recommend people run them through the graphical WSL subsystem (https://www.zdnet.com/article/linux-graphical-apps-coming-to-windows-subsystem-for-linux/)
19:55:26 <wumpus> jeremyrubin: no one is speaking of holding up anything, and I agree
19:55:36 <jeremyrubin> last week it was :p
19:55:37 <luke-jr> jamesob: lol
19:56:04 <wumpus> jamesob: that's a completely different discusion (though a potentially interesting one but there is no time for that now :)
19:56:18 <achow101> I'll get a screenshot of the three different warnings and put them in the earlier issue
19:56:24 <jamesob> wumpus: yeah sorry for lobbing that grenade
19:56:35 <emzy> luke-jr: have a second backup cert for a second binary. That was my thinking, but it will double the work :(
19:56:36 <wumpus> in any case we need a windows installer that works that people can download
19:56:44 <luke-jr> jamesob: looks like it's Wayland - do we even support that?
19:56:52 <achow101> wumpus: the unsigned one is fine for that
19:56:56 <wumpus> luke-jr: no, the binary does not support wayland
19:57:05 <wumpus> luke-jr: self-built ones do
19:57:30 <wumpus> see #19950 wrt wayland
19:57:31 <gribble> https://github.com/bitcoin/bitcoin/issues/19950 | [Linux] Add wayland support · Issue #19950 · bitcoin/bitcoin · GitHub
19:57:38 <luke-jr> "it connects the graphical Linux applications via a Remote Desktop Protocol (RDP) connection to the main Windows display"
19:57:42 <luke-jr> sounds ugly for end users
19:57:50 <wumpus> luke-jr: anyhow this is off topic now
19:57:54 <wumpus> achow101: ok
19:57:54 <luke-jr> sorry
19:58:01 <aj> was this the last topic?
19:58:30 <wumpus> aj: I think so! I didn't expect to get this far but hadn't noticed the speedytrial one was more or less duplicate
19:58:46 <aj> wumpus: great success!
19:58:48 <wumpus> #endmeeting