< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ed49203daabb...8f94c70625eb
< bitcoin-git> bitcoin/master ec76bad Hennadii Stepanov: build, qt: Fix static builds on macOS Big Sur
< bitcoin-git> bitcoin/master 8f94c70 fanquake: Merge #21495: build, qt: Fix static builds on macOS Big Sur
< bitcoin-git> [bitcoin] fanquake merged pull request #21495: build, qt: Fix static builds on macOS Big Sur (master...210321-layer) https://github.com/bitcoin/bitcoin/pull/21495
< SuViVoR> i want to get started with development
< SuViVoR> anyway i can help out?
< phantomcircuit> SuViVoR, there's issues tagged 'good first issue'
< bitcoin-git> [bitcoin] ajtowns opened pull request #21527: NOMERGE: net_processing: orphan handling changes (master...202102-orphanworkset) https://github.com/bitcoin/bitcoin/pull/21527
< SuViVoR1> i am looking for it in the github repo but could'nt find it, can you please help phantomcircuit
< bitcoin-git> [bitcoin] amitiuttarwar opened pull request #21528: [net_processing] Reduce addr blackholes (master...2021-03-addr-defer2) https://github.com/bitcoin/bitcoin/pull/21528
< SuViVoR> sorry i keep getting disconnected
< SuViVoR> i am looking for it in the github repo but could'nt find it, can you please help phantomcircuit
< SuViVoR> is this the one?
< SuViVoR> thanks a lot sipa
< SuViVoR> thanks again :)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8f94c70625eb...9217f9fe7351
< bitcoin-git> bitcoin/master fa818ca MarcoFalke: fuzz: [refactor] Use PickValue where possible
< bitcoin-git> bitcoin/master 9217f9f MarcoFalke: Merge #21522: fuzz: [refactor] Use PickValue where possible
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21522: fuzz: [refactor] Use PickValue where possible (master...2103-fuzzPickValue) https://github.com/bitcoin/bitcoin/pull/21522
< wumpus> hebasto: are you sure you need that and not the libxkbcommon-x11-dev package?
< wumpus> (after all, the non dev packages provide runtime functionality only, i would guess the builder wants to link against it, but unsure)
< michaelfolkson> #proposedmeetingtopic Taproot activation update
< hebasto> wumpus: yes, I think, as an error is "error while loading shared libraries: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory" during runtime
< shesek> why does importmulti with timestamp=now sometimes result in a (short) rescan and sometimes does not?
< darosior> shesek: iirc it always scan 2W of blocks?
< bitcoin-git> [bitcoin] sethupavan12 opened pull request #21529: Updated copyright year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21529
< bitcoin-git> [bitcoin] sethupavan12 closed pull request #21529: Updated copyright year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21529
< bitcoin-git> [bitcoin] sethupavan12 reopened pull request #21529: Updated copyright year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21529
< bitcoin-git> [bitcoin] sethupavan12 closed pull request #21529: Updated copyright year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21529
< bitcoin-git> [bitcoin] sethupavan12 opened pull request #21530: Updated copyright headers to 2021 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21530
< bitcoin-git> [bitcoin] sethupavan12 closed pull request #21530: Updated copyright headers to 2021 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21530
< wumpus> hebasto: yes that sounds like you need the runtime package; it is strange tho, that linking works apparantly but execution does not, is it different platforms maybe ? (e.g. arm versus aarch64)
< hebasto> wumpus: it's linux 32bit, probably `libxkbcommon-x11-0:i386` is required
< amiti> #proposedmeetingtopic addr relay improvements
< jeremyrubin> I don't think the proposedmeetingtopic link works?
< jeremyrubin> #proposedmeetingtopic release timeline for Taproot activation and parameters
< michaelfolkson> jeremyrubin: Yeah doesn't seem to be
< jeremyrubin> #proposedmeetingtopic SpeedyTrial pull requests #21392 and #21377
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< michaelfolkson> I did propose a Taproot activation topic earlier today but hasn't got picked up. Nor has amiti's
< achow101> michaelfolkson: your topic is there
< achow101> I don't think it updates in real time
< michaelfolkson> Oh yeah you're right. I was looking at the wallet one
< * michaelfolkson> slaps head
< jeremyrubin> oh me too; the urls look very similar
< michaelfolkson> I'm happy for you to take the Taproot topics jeremyrubin. Everyone is sick of me
< phantomcircuit> jeremyrubin, freenode is also currently exploding from restarting servers
< jeremyrubin> chin up michaelfolkson
< wumpus> yes it can take a while for the gnusha site to update
< michaelfolkson> I did try to summarize the block height versus mix of block height and MTP discussion on SE https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio
< michaelfolkson> Suggested edits welcome
< michaelfolkson> Ha thanks jeremyrubin
< jeremyrubin> michaelfolkson: either way; I do think that more specific topics are beneficial for the core dev meeting given we're looking at a release in 1 month
< michaelfolkson> jeremyrubin: Yup specific topics better
< achow101> meeting?
< wumpus> #startmeeting
< jnewbery> hi
< luke-jr> o hai
< achow101> hi
< jeremyrubin> hi
< amiti> hi
< 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
< hebasto> hi
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< fjahr> hi
< sipa> hi
< lightlike> hi
< meshcollider> hi
< michaelfolkson> hi
< aj_> hi
< wumpus> FYI: you can propose meeting topics with #proposedmeetingtopic during the week, they will appear in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
< wumpus> These have been proposed for this week: Taproot activation update (michaelfolkson), Addr relay improvements (amiti)
< ariard> hi
< jeremyrubin> wumpus: I proposed 2
< wumpus> any last minute topics anyone wants to discuss?
< michaelfolkson> wumpus: jeremyrubin is going to take the Taproot activation topic(s)
< michaelfolkson> wumpus: So please withdraw mine
< jeremyrubin> 2021-03-25.log:11:44 < jeremyrubin> #proposedmeetingtopic release timeline for Taproot activation and parameters
< jeremyrubin> 2021-03-25.log:11:44 < jeremyrubin> #proposedmeetingtopic SpeedyTrial pull requests #21392 and #21377
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< wumpus> ok, yes, I was confused there because I didn't see much difference with michaelfolkson's topic, didn't notice the other one
< wumpus> #topic High priority for review
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 has 8 blockers, 2 chasing concept ACK
< wumpus> anything to add/remove or that is ready for merge?
< sipa> oh short topic: how far do we want to backport BIP350/bech32m support?
< wumpus> sipa: noted
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/19160 | multiprocess: Add basic spawn and IPC support by ryanofsky · Pull Request #19160 · bitcoin/bitcoin · GitHub
< sipa> dank
< wumpus> ariard: good to know, thanks
< achow101> topic: windows code signing key issues
< achow101> *topic suggestion
< wumpus> achow101: noted
< wumpus> lots of topics today so let's move on
< wumpus> #topic Addr relay improvements (amiti)
< amiti> Hey all, I opened #21528 yesterday and wanted to share some thoughts around how I see it fitting in to the bigger picture.
< gribble> https://github.com/bitcoin/bitcoin/issues/21528 | [net_processing] Reduce addr blackholes by amitiuttarwar · Pull Request #21528 · bitcoin/bitcoin · GitHub
< 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.
< 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`).
< 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.
< 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.
< 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
< 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.
< gribble> https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
< amiti> That’s all! Let me know if you have any questions or feedback :)
< * michaelfolkson> needs time to read
< sipa> amiti: is there are risk of having both sides "wait" until they see an addr?
< luke-jr> amiti types fast :P
< amiti> def a risk, but shouldn't be a problem in the implementation
< amiti> also there's asymmetry, we setup addr relay for outbound connections
< jnewbery> in the current implementation, we'll always send our initial self-advertisement to outbounds
< amiti> (other than block-relay-only)
< 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
< jnewbery> if they want them, they can send a getaddr
< 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?
< sipa> jnewbery: ah, that's a good point
< aj> sipa: we send GETADDR to our outbounds always, and consider inbounds non-blackholes if we receive GETADDR
< jnewbery> i think it'd be strange if a node wanted addrs but didn't send a getaddr
< sipa> that's fair
< ariard> i need to think about how it might affect lightclients, not sure if they do addr-relay with any consistency
< wumpus> light clients never do addr relay afaik
< amiti> lightlike: yeah, I don't think we can prevent all situations of blackholing, but the patch should mitigate some normal usage patterns
< sipa> if we're going to give addresses to a peer, we must assume they can relay them further
< luke-jr> wumpus: but ideally they would
< jeremyrubin> so to summarize; it's basically don't send addrs till they've been requested once?
< luke-jr> or at least keep an addr db
< ariard> wumpus: that's my memory too but ideally they should
< amiti> jeremyrubin: yes but with the added clause of to inbound peers
< 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
< jnewbery> jeremyrubin: or if that peer has relayed an addr to us
< 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
< jeremyrubin> sipa: +1
< jeremyrubin> How much bandwidth does this save amiti?
< jamesob> hi, sorry am late
< sipa> jeremyrubin: i think it's mostly an attempt at avoiding black holing?
< amiti> jeremyrubin: hm, I don't know. the motivation was more about addr relay than bandwidth.
< jeremyrubin> I'm just trying to grok why we care
< jeremyrubin> if it can't stop a malicious peer from becoming a black hole
< amiti> its for reducing the total black holes
< jeremyrubin> why do we care if a honest peer is a black hole?
< jeremyrubin> so we don't advertise them or something?
< jnewbery> jeremyrubin: not much bandwidth. At most we only send one addr message per peer every 30 seconds
< sipa> jeremyrubin: because in general you assume the network has some minimal number of honest peers
< 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
< 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
< sipa> this doesn't have any effect if all your peers are intentionally-blackholing attackers
< amiti> the idea is an ongoing trickle of announcing addrs
< jeremyrubin> Ok I'm just trying to understand why we care about blackholes, which the PR could better motivate
< jeremyrubin> I can take it out of band from the meeting though
< amiti> jeremyrubin: has your question been answered here?
< sipa> seems like a reasonable idea; maybe we can also discuss it further in a P2P meeting
< 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.
< sipa> jnewbery: indeed
< jeremyrubin> amiti: no; it's OK though. I just don't see which resource this is saving us
< jnewbery> jeremyrubin: it's not saving a resource
< amiti> its less about resource saving and more about addr propagation
< aj> jeremyrubin: see net_processing::RelayAddress
< sipa> jnewbery: it more a "you *definitely* don't care about addresses? ok, then i'll send them to someone else instead"
< jnewbery> sipa: exactly
< amiti> sipa: exactly
< amiti> :)
< wumpus> time for next topic?
< wumpus> #topic Release timeline for Taproot activation and parameters (jeremyrubin)
< amiti> yeah sounds good
< amiti> thanks for the input!
< jeremyrubin> ok, so we had a meeting on tuesday in ##taproot-activation
< jeremyrubin> I posted notes to bitcoin-dev mailing list
< sipa> amiti: i feel a comic coming up? :)
< 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
< amiti> sipa: suggestions always welcome :)
< achow101> didn't we have this discussion last week?
< jeremyrubin> With respect to ST, we agreed that we should fix for a Novemeber 15th height regardless of release date/starttime
< michaelfolkson> achow101: Updates, progress since last week
< jeremyrubin> achow101: it didn't have sufficient heads up that a meeting was happening for it to be a respectful process
< sipa> i'm planning to through all the activation related PRs for code review; new comments on what activation is actually appropriate
< sipa> s/new/no/
< michaelfolkson> +1 for a black hole amiti comic
< michaelfolkson> Full nodes in outer space
< jeremyrubin> can we keep it on topic?
< jeremyrubin> Does anyone have any reservations with a release during April?
< 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
< wumpus> michaelfolkson: yessss
< achow101> I think we can keep the timeline that we discussed last week
< aj> are we aiming for taproot activation params in rc2 not rc1 then?
< wumpus> aj: w-why
< achow101> aj: rc1, but have space for an rc2 for other issues that may crop up
< luke-jr> aj: no? rc1 should be a cnadidate..
< wumpus> the aim should always be to get things into the first possible rc
< aj> okay
< aj> april 3 sounds very quick!
< wumpus> planning for something to do in rc2 sounds really strange to me but dunno
< jeremyrubin> Ok, wumpus does it seem that we can get rc1 by then?
< wumpus> aj: yes it might be too soon
< wumpus> jeremyrubin: to be honest? no
< 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?
< luke-jr> jeremyrubin: aim for it, so the inevitable slip is a slip :P
< 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?
< aj> wumpus: "by then" == "may 1st" ?
< achow101> michaelfolkson: only followup is the activation parameters. other followups don't need backport
< michaelfolkson> achow101: Ok cool
< jeremyrubin> There's some question of which of the PRs. hence sep topic
< achow101> actually april 10th for rc1 still keeps the timeline.
< wumpus> aj: people are talking about *april 3*
< jeremyrubin> w.r.t. the mid-MTP thing, the starttime is less sensitive than the stoptime
< 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
< aj> wumpus: i think jeremyrubin's/##t-a's last timeline was rc1 out the door by may 1st?
< jeremyrubin> so I don't think we need to worry that much about releasing with whatever start we want
< wumpus> achow101: bumping it to april 10 does sound a bit more realistic
< luke-jr> MTP was never a viable option to begin with
< 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"
< jeremyrubin> My suggestion was rc1 may 1st, starttime may 7th, 1st period signalling mid may
< wumpus> aj: I was pasting from the conclusion of last week's IRC meeting, I do not know what was discussed elsewhere
< michaelfolkson> Currently achow101 PR is entirely block height and aj PR is a mix of block height and MTP
< aj> wumpus: aha, thanks
< BlueMatt> so the timeline can and shoulld de dependent on when the release finishes, its not a "we have to get release by X"
< BlueMatt> at least in the taproot-activation discussion
< jeremyrubin> BlueMatt: sure, but we should set a schedule we're trying to keep
< achow101> BlueMatt: yes, but also, deadlines are a motivator, even if they are fuzzy
< wumpus> BlueMatt: that's the only thing that makes sense anyway
< jeremyrubin> april 3 seems unrealistic
< sipa> doesn't the start date needs wider coordination? like talking to miners and businesses to see if they're ready to deploy?
< BlueMatt> if we dont know when the code gets merged, then we cant pick a day, until then, the schedule is merge + whatever.
< luke-jr> sipa: if they aren't, they just don't signal
< wumpus> 'do a release at all costs' is a big nope to me
< jeremyrubin> sipa: No; start date is not super sensitive IMO compared to stop date
< luke-jr> sipa: but yes, wider coordination on startheight is important anyway
< sipa> okay, not going to wade into that
< BlueMatt> s/stop/activation/
< jeremyrubin> activation is sensitive OTOH
< jeremyrubin> the outcome of that was we'll project out a height for November 15th
< michaelfolkson> It would be nice to announce a start height as early as we can
< michaelfolkson> But not at expense of rushing
< jeremyrubin> michaelfolkson: doesn't matter till it's in a release
< 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
< wumpus> was one PR chosen? is it clsoe to merge?
< jeremyrubin> next topic?
< BlueMatt> review the code, decide on the pr, and then talk again
< BlueMatt> wumpus: nope, thats up to code review, mostly.
< jeremyrubin> wumpus: (as in, next topic is about that)
< BlueMatt> because, ultimately, no one could decide.
< wumpus> we didn't even decide a PR yet? yes, I think this is pointless like this, let's move on
< sipa> BlueMatt: nack
< luke-jr> wumpus: yes, achow101's
< achow101> both PRs are at one ack
< wumpus> #topic How far do we want to backport BIP350/bech32m support? (sipa)
< BlueMatt> sipa: to...?
< sipa> i *really* dislike using "this things seems to get reviewed faster" as a criterion to decide how consensus changes will be activated
< luke-jr> sipa: not sure why BIP350 would be eligible for backporting at all
< sipa> there should be a clear proposal, with buy-in, and then we implement that
< BlueMatt> sipa: nooooo, thats not what I was suggesting, I was suggesting a part of the criteria is what code reviewers think of it
< sipa> BlueMatt: hmm ok
< 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
< michaelfolkson> If you'd prefer entirely block height then you'd prefer achow101 PR. Please read my SE link on that
< 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"
< sipa> i'm happy to do code review for all of them
< achow101> luke-jr: presumably to allow sending to taproot without upgrading major release?
< luke-jr> ST (with heights) has wide support; this MTP variant does not.
< wumpus> it really doesn't make sense to discuss a timeline every week if there is no progress in that regard
< sipa> but i'm not going to ack merging until it's clear which one is chosen
< ariard> i've reviewed both, i've a preference for bip9-amendment, would review both anyway
< michaelfolkson> I personally have a preference for a consistent use of block height across the activation mechanims
< ariard> but better to focus on one
< michaelfolkson> Mixing block height and MTP doesn't make sense to me
< michaelfolkson> But as I said please read my SE post and suggest edits and improvements
< 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 :/
< sipa> sigh
< 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
< jeremyrubin> so it seems deleterious to not just decide on one or the other
< michaelfolkson> I think reviewers can come to a view on block height versus a mix of block height and MTP perrsonally
< jeremyrubin> Either can be compatible with a subsequent BIP8 release
< michaelfolkson> jeremyrubin: Any UASF is entirely irrelevant to this discussion
< sipa> i don't care about one or the other; i think all of this is a storm in a cup of water
< sipa> just pick one ffs
< BlueMatt> michaelfolkson: jeremyrubin please take it to taproot-activation.
< ariard> sipa: thanks!
< wumpus> if we want to get to to all the topics today, we should move on
< 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.
< ariard> we should do a fair coins toss fwiw
< BlueMatt> anyway, lets move on, this isnt the right venue to debate it.
< wumpus> we can also discuss taproot for the rest of the meeting, of course
< luke-jr> thought we were trying to give sipa the floor for BIP350
< wumpus> ~20 mins to go
< achow101> re the actual topic: I think it makes sense to backport to 0.21 and 0.20
< wumpus> sipa: your topic pls
< sipa> hji!
< sipa> so we merged #20861
< 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
< wumpus> yes
< sipa> which adds send-to-bech32m support and related tests
< sipa> amending what address checksum is expected for v1+ native segwit addresses
< sipa> i think this is something that should be backported... it may not matter, depending on activation of course
< jeremyrubin> sipa: maybe backport anywhere taproot is getting backported + 1 version?
< wumpus> let's do that then
< 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
< 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
< jeremyrubin> I agree you should be able to pay addresses you see, even if you don't know how to create such an address
< 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
< sipa> i'm ok with 0.21 and 0.20
< luke-jr> 0.20 will be end-maint in Aug too
< wumpus> well if he already made a PR for it, then I don't see why not to backport
< sipa> also ok with just 0.21, if that's what we decide
< wumpus> *if* we are going to do another 0.19 release is another question of course
< jnewbery> I've reviewed 0.20 and 0.21. Both look good to me.
< sipa> i just opened backports as far back as they were nontrivial
< luke-jr> seems better to just limit to 0.21
< luke-jr> I don't think anyone plans to backport Taproot itself to 0.20?
< luke-jr> consensus code I mean
< achow101> luke-jr: you don't need taproot in order to make taproot outputs
< wumpus> luke-jr: that doesn't matter here, it's for sending to it
< wumpus> might backport one release further for that
< jeremyrubin> sipa: one question; if taproot doesn't activate can you still send to these addresses?
< luke-jr> achow101: but if you're doing economic stuff, you should be using a full node
< jeremyrubin> Might be kinda weird if you can pay to them before they activate
< jeremyrubin> (that's true for next-release as well as backport)
< sipa> jeremyrubin: being able to send to future addresses is pretty essential for smooth upgrading
< jeremyrubin> sipa: you could only enable sending to them from wallet iff it activates and height > minactiveheight
< wumpus> that would be weird but also, why would anyone do that
< jeremyrubin> not sure, many ways to lose money I spose
< aj> jeremyrubin: been able to send to them since 0.19 due to #15846
< 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
< achow101> jeremyrubin: that removes the upgrade advantage
< 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
< jeremyrubin> aj: ack
< achow101> it's up to the receiver to decide whether he wants to lose money
< wumpus> so ok: 0.20 and 0.21?
< sipa> jeremyrubin: also #20165
< 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
< achow101> wumpus: ack
< sipa> jeremyrubin: but that's about *spending*, not sending to
< jeremyrubin> hmm
< wumpus> I think we need to move to next topic
< wumpus> #topic SpeedyTrial pull requests (jeremyrubin)
< luke-jr> O.o
< jeremyrubin> There are two open PRs
< wumpus> yes
< wumpus> didn't we go through this already
< jeremyrubin> there is not community consensus on either one
< jeremyrubin> IDK it's the topic again so I thought I'd summarize
< wumpus> well you proposed two topics I don't know why
< wumpus> if it's unnecessary let's move on
< BlueMatt> i think we covered this pretty fully
< 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
< sipa> michaelfolkson: and we're not going to do that here
< wumpus> #topic Windows code signing issues (achow101)
< 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
< wumpus> uh oh
< aj> yikes
< wumpus> do you know why they revoked the key?
< 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
< 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
< achow101> so it is possible that for the next release, we may not have a windows code signing key
< achow101> and also we probably need to re-sign 0.20 and 0.21
< wumpus> yes
< achow101> I have no idea why the key was revoked
< achow101> I emailed support and they haven't responded :/
< wumpus> is it possible to install on windows without a signing key?
< achow101> yes
< achow101> there is a non-codesigned installer
< luke-jr> but the codesigned one is a no-go?
< wumpus> can we get a key from a different provider if comodo becomes difficult?
< achow101> luke-jr: pretty much. this is what people see: https://github.com/bitcoin-core/gui/issues/252
< wumpus> should I delete the codesigned one from the website? (or move it out of the way at least)
< achow101> wumpus: yes, but they are way more expensive ($3-400 vs $80 per yr) and probably have similar organization verification requirements
< wumpus> if it is no longer usable it makes no sense to host it, after all
< achow101> sure
< sipa> right
< jeremyrubin> achow101: does the non codesigned one make it harder to install
< sipa> perhaps move it to an archive section or so
< achow101> we have bitcoin-0.21.0-win64-setup-unsigned.exe from the gitian builds which is non-codesigned that we can upload
< luke-jr> good question - why are we even signing it on Windows? XD
< wumpus> sipa: yeah
< achow101> jeremyrubin: it gives a warning iirc
< achow101> but the warning can be ignored
< luke-jr> achow101: doesn't _any_ download?
< wumpus> the only annoyance is that I need to regenrate the SHA256SUMS.asc, and ideally the torrent too
< wumpus> oh can it be ignored?
< luke-jr> only difference IIRC was that signed just shows an author name
< emzy> does it make sense to have 2 signing certs just in case for problems like this?
< achow101> luke-jr: it says something about "untrusted" if it isn't code signed. I think that's just about it
< luke-jr> wumpus: maybe wait on the torrent until we have a full resolution?
< luke-jr> emzy: doubt you can sign it twice
< jeremyrubin> FWIW; I don't think it makes sense to hold out on any releases that are ready to go based on this issue
< 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
< sipa> jeremyrubin: agree, but we should also try to fix it going forward
< 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/)
< wumpus> jeremyrubin: no one is speaking of holding up anything, and I agree
< jeremyrubin> last week it was :p
< luke-jr> jamesob: lol
< wumpus> jamesob: that's a completely different discusion (though a potentially interesting one but there is no time for that now :)
< achow101> I'll get a screenshot of the three different warnings and put them in the earlier issue
< jamesob> wumpus: yeah sorry for lobbing that grenade
< emzy> luke-jr: have a second backup cert for a second binary. That was my thinking, but it will double the work :(
< wumpus> in any case we need a windows installer that works that people can download
< luke-jr> jamesob: looks like it's Wayland - do we even support that?
< achow101> wumpus: the unsigned one is fine for that
< wumpus> luke-jr: no, the binary does not support wayland
< wumpus> luke-jr: self-built ones do
< wumpus> see #19950 wrt wayland
< gribble> https://github.com/bitcoin/bitcoin/issues/19950 | [Linux] Add wayland support · Issue #19950 · bitcoin/bitcoin · GitHub
< luke-jr> "it connects the graphical Linux applications via a Remote Desktop Protocol (RDP) connection to the main Windows display"
< luke-jr> sounds ugly for end users
< wumpus> luke-jr: anyhow this is off topic now
< wumpus> achow101: ok
< luke-jr> sorry
< aj> was this the last topic?
< 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
< aj> wumpus: great success!
< wumpus> #endmeeting
< jnewbery> speedymeeting
< jnewbery> thanks wumpus!
< jeremyrubin> it wasn't intended to be duplicate -- it does really help to break topics into smaller chunks so that you can build consensus on one part of the puzzle without needing the other
< sipa> jeremyrubin: fwiw, the reason why sending to future addresses needs to be supported (at least as a relay policy) is that otherwise you force wallets to keep up with it (e.g. say some service supports withdrawals, and does batching, ... one customer gives a future address and another gives a current address... batching them together both payments get stuck)
< dongcarl> achow101: Is https://github.com/bitcoin-core/gui/issues/252 where I should follow the codesigning discussions?
< jeremyrubin> sipa: yeah, noted. I think it's good as long as no one puts tools out to *generate* taproot addresses ahead of activation
< sipa> jeremyrubin: this i think was a snafu with bech32 that resulted in it actually failing (basically nobody supported sending to future addresses, because they *had* to: relay policy didn't allow it either)
< jeremyrubin> I could see there being confusion with "Taproot is locked in" and "Taproot is active"
< achow101> dongcarl: yes
< jeremyrubin> sipa: yeah I think in general you send to a bad address you pay the price is the best we can do
< sipa> but i think the combination of support relay of sending to: always; support relay of spending: only when rules are active
< sipa> is ideal
< jeremyrubin> yeah I agree because you can be tricked into relaying bad txs after activation
< jeremyrubin> so it makes sense to only relay spends you suspect you can fully validate
< wumpus> jnewbery: yw!
< jeremyrubin> yw?
< wumpus> jeremyrubin: yes i understand your motivation for splitting it up, it just came as a bit of a shock just after the monster topic was concluded to see it come up again :)
< wumpus> in any case, let's not make it a meeting topiuc again until at least the PR has been decided
< jeremyrubin> wumpus: probably could have gone in reverse order
< jeremyrubin> I was hoping that in the meeting, w.r.t. PRs, we could have discussed the practicality of reviewing/merging/backporting either
< jeremyrubin> And if it fits in with the timeline being desired
< wumpus> I think we need to do that after a PR has been decided
< wumpus> with such a tight schedule it is a really bad idea to spread the time and resources over two PRs here
< jeremyrubin> wumpus: I think the issue is that "people" have decided on a tight schedule
< jeremyrubin> that's my only preference for AJ's PR
< jeremyrubin> is if we are trying to meet that timeline or not
< aj> jeremyrubin: fwiw, 21377 cleanly backports currently
< jeremyrubin> aj: yep
< aj> jeremyrubin: (modulo 21489, which also cleanly backports)
< achow101> screenshots of the different prompts that appear for the windows installers: https://github.com/bitcoin-core/gui/issues/252#issuecomment-807400048 The non-codesigned warning has gotten scarier.
< aj> should i manually add 21489 (which i labelled as needs-backport-0.21 already) to the 0.21 milestone? or just open a pr backporting it? or?
< aj> (it's needed whichever pr gets merged)
< sipa> #21489
< gribble> https://github.com/bitcoin/bitcoin/issues/21489 | fuzz: cleanups for versionbits fuzzer by ajtowns · Pull Request #21489 · bitcoin/bitcoin · GitHub
< sipa> aj: is the backport trivial/clean?
< wumpus> achow101: agree, and yes it seems ok for now
< aj> sipa: yes
< wumpus> at least its only a yellow warning
< luke-jr> achow101: bleh :/
< wumpus> PSA: because of the windows signing key being revoked, i have for https://bitcoincore.org/bin/bitcoin-core-0.21.0/ and https://bitcoincore.org/bin/bitcoin-core-0.20.1/ moved the -setup.exe to an "archived" directory, uploaded the setup-unsigned.exe instead, also created and signed a new SHA256SUMS.asc with the alternative exe in it
< wumpus> this should make it at least possible to still install while we resolve the signign key issues
< hebasto> jonasschnelli_: maybe `libxkbcommon-x11-0:i386` package for Linux32 build?
< jonasschnelli> hebasto just saw that. Will add
< hebasto> jonasschnelli: thanks
< harding> wumpus: that breaks the links on https://bitcoincore.org/en/download/ ; is it possible to use the same file name, or is that just too problematic?
< harding> (I can also change the link on the download page if you'd prefer that.)
< wumpus> harding: that is a good idea but I don't feel like doing the entire process (like regenerate SHA256SUMS.asc) again
< wumpus> let's just change the link
< harding> wumpus: will do, thanks.
< wumpus> also the -unsigned in the file name will likely alert people what to expect