< bitcoin-git> [bitcoin] hebasto closed pull request #21459: build: Add convenient BITCOIN_TRY_ADD_COMPILE_FLAG macro (master...210317-flag) https://github.com/bitcoin/bitcoin/pull/21459
< bitcoin-git> [bitcoin] fanquake closed pull request #20454: build: Bump clang version to fix non-determinism (master...201122-clang) https://github.com/bitcoin/bitcoin/pull/20454
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a9d1b40d53ec...d6e3ac89d4e6
< bitcoin-git> bitcoin/master c180c91 Jarol Rodriguez: doc: revamp macOS build doc
< bitcoin-git> bitcoin/master d6e3ac8 fanquake: Merge #21343: doc: revamp macOS build doc
< bitcoin-git> [bitcoin] fanquake merged pull request #21343: doc: revamp macOS build doc (master...macos-build-docs) https://github.com/bitcoin/bitcoin/pull/21343
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d6e3ac89d4e6...bf7c22f7ff83
< bitcoin-git> bitcoin/master 1a01a5d Hennadii Stepanov: doc: Update zlib info in dependencies.md
< bitcoin-git> bitcoin/master bb3f79f Hennadii Stepanov: doc: Update libnatpmp info in dependencies.md
< bitcoin-git> bitcoin/master bf7c22f fanquake: Merge #21435: doc: Update dependencies.md
< bitcoin-git> [bitcoin] fanquake merged pull request #21435: doc: Update dependencies.md (master...210314-deps) https://github.com/bitcoin/bitcoin/pull/21435
< mj_node> hi all, wanted to get the pulse of dev community on blockstack, is this something worth looking into?
< fanquake> mj_node: no idea what that is, no doubt off-topic here
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/bf7c22f7ff83...e057e01b7b7b
< bitcoin-git> bitcoin/master a38a4e8 John Newbery: [net processing] Move RelayTransaction into PeerManager
< bitcoin-git> bitcoin/master 680eb56 John Newbery: [net processing] Don't pass CConnman to RelayTransactions
< bitcoin-git> bitcoin/master e057e01 fanquake: Merge #21162: Net Processing: Move RelayTransaction() into PeerManager
< bitcoin-git> [bitcoin] fanquake merged pull request #21162: Net Processing: Move RelayTransaction() into PeerManager (master...2021-02-relay-transactions-peer-manager) https://github.com/bitcoin/bitcoin/pull/21162
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e057e01b7b7b...6834e02c896b
< bitcoin-git> bitcoin/master fa2a80b MarcoFalke: refactor: Pass PeerManagerImpl members only once
< bitcoin-git> bitcoin/master 6834e02 MarcoFalke: Merge #21425: refactor: Pass PeerManagerImpl members only once
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21425: refactor: Pass PeerManagerImpl members only once (master...2103-refactorMember) https://github.com/bitcoin/bitcoin/pull/21425
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/6834e02c896b...a65e772fec62
< bitcoin-git> bitcoin/master 61a0f8f Hennadii Stepanov: test: Cleanup test files in test-{security,symbol}-check.py
< bitcoin-git> bitcoin/master 0fc0c00 Hennadii Stepanov: test: Drop unused get_machine function
< bitcoin-git> bitcoin/master a65e772 fanquake: Merge #21428: test: Cleanup in test-{security,symbol}-check.py
< bitcoin-git> [bitcoin] fanquake merged pull request #21428: test: Cleanup in test-{security,symbol}-check.py (master...210313-check) https://github.com/bitcoin/bitcoin/pull/21428
< bitcoin-git> [bitcoin] Sjors opened pull request #21467: Move external signer out of wallet module (master...2021/03/signer_no_wallet) https://github.com/bitcoin/bitcoin/pull/21467
< michaelfolkson> #proposedmeetingtopic Taproot activation PRs and attempting to finalize startheight
< Arvidt> Any preference for having base-10 (kB/MB/GB) or base-2 (KiB/MiB/GiB) prefix for GUI network peer tab data transferred/throughput value? See https://github.com/bitcoin-core/gui/pull/248 Would be thankful to get some feedback.
< luke-jr> Arvidt: base 10 sucks ;)
< hebasto> luke-jr: what reasons for?
< luke-jr> hebasto: 10 is a multiple of 5 and 2
< luke-jr> but more importantly, networks tend to use base-1024 measurements
< sipa> my gigabit ethernet does 1000000000 bits/s
< luke-jr> sipa: it does? :o
< sipa> yes
< luke-jr> hmm
< sipa> all network stuff is 1000-based, as far as i know'
< sipa> only disk sizes use 1024-based units conventionally
< sipa> or on-disk sizes
< luke-jr> RAM typically does even now
< sipa> that's true, RAM is also typically 1024-based
< luke-jr> well, decimal still sucks, but we should match what other stuff does
< luke-jr> eg, torrent clients, browsers, etc
< jeremyrubin> can we use nats?
< jeremyrubin> I think the thing with the MiB MB is it's always "close enough" if you mix em up
< sipa> it's 7.3% off!
< jeremyrubin> I think that's why people get away with confusing labeling
< sipa> once you get to peta/pebi it's a 12.6% difference
< jeremyrubin> you should file a CFPB complaint :)
< sipa> child for parent bays?
< jeremyrubin> I guess CFPB only does financial fraud
< jeremyrubin> anyways off topic
< Arvidt> OK I just left the 1000-based prefixes then and just corrected the divisor from 1024 to 1000. Thanks for Your feedback
< * luke-jr> proposes using 1024-based units when it is a good thing, and 1000-based units when it is bad or a cost :P
< Arvidt> The good thing with binary prefix is that one can be pretty sure the programmers are aware of the complex and (hopefully) knew what they have programmed
< jnewbery> meet?
< wumpus> #startmeeting
< 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.
< core-meetingbot> Available commands: action commands idea info link nick
< achow101> hi
< jnewbery> hi
< amiti> hi
< sipa> hi
< fjahr> hi
< michaelfolkson> hi
< hebasto> 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
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< glozow> hi
< meshcollider> hi
< michaelfolkson> I proposed one. Did I do it wrong? :)
< wumpus> (fwiw: you can propose meeting topics with #proposedmeetingtopic during the week)
< wumpus> michaelfolkson: oh? maybe overlooked it
< jeremyrubin> hi
< luke-jr> hi
< wumpus> ah yes
< dongcarl> hi
< luke-jr> [14:35:46] <michaelfolkson> #proposedmeetingtopic Taproot activation PRs and attempting to finalize startheight
< wumpus> Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
< jonatack> hi
< wumpus> luke-jr: yes it was the last line, after a lot of spam, which is why i missed it sorry
< wumpus> any last minute topic proposals?
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< achow101> #21392 for me
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 8 blockers, 2 chasing concept ACKs right now
< sipa> i think #20861 is ready for merge
< 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
< dongcarl> Not enough to be a meeting topic but would like to give a quick Guix update once the meeting's over
< jnewbery> sipa: I agree
< wumpus> achow101: 21392 addded
< wumpus> sipa: good to know! will take a look
< jonatack> review beg for #20197
< 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
< jonatack> repeated ACK by vasild and numerous concept acks
< sipa> jnewbery: will have a look
< sipa> eh
< sipa> jonatack: ^
< jonatack> sipa: ty!
< wumpus> jonatack: will have a look too
< wumpus> any more suggestions for additions/removals?
< wumpus> #topic Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
< core-meetingbot> topic: Taproot activation PRs and attempting to finalize startheight (michaelfolkson)
< 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
< michaelfolkson> achow101 has already linked to his PR implementing Speedy Trial
< michaelfolkson> aj has an alternative PR https://github.com/bitcoin/bitcoin/pull/21377
< michaelfolkson> Now there is obviously the added complication of needing to finalize a startheight
< wumpus> any specific reason to have competing PRs?
< achow101> 21377 uses the MTP start and timeouts, 21392 uses height
< michaelfolkson> aj PR changes less code, uses existing BIP 9 code
< wumpus> right, thanks
< 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)
< michaelfolkson> That is a sense I get (which some people have told me is wrong)
< michaelfolkson> Speedy Trial doesn't have a relaxed proposed timetable
< achow101> people seem to not like some aspects of BIP 8, but the change to heights is generally seen to be a good change
< luke-jr> ST would be very controversial with MTP, or without a clear documentation/disclaimer
< michaelfolkson> Those are proposed dates
< 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.
< michaelfolkson> So we don't have much time to work with if we are going to keep to that proposed timetable
< michaelfolkson> achow101: I've got the sense that it is more than that (but as I said I've been corrected)
< jeremyrubin> I think that ST with MTP is only really controversial with activate MTP, not activate height
< 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
< jeremyrubin> It's really easy to get around the signaling periods issue by targetting a mid-signal period activate height and time
< michaelfolkson> achow101: Right but lockinontimeout is in BIP 8
< jeremyrubin> given the short timetable, mining drift will likely be minimal
< michaelfolkson> achow101: So that seems to be the only reason for disliking BIP 8 (at least in my view)
< luke-jr> achow101's proposal seems the least controversial at the moment
< jeremyrubin> s/activate height and time/start,end height and time/
< michaelfolkson> A startheight of May 1st was proposed which doesn't leave much time
< luke-jr> michaelfolkson: it's for signalling, not activation
< 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
< luke-jr> a release May 1 is okay with that startheight
< michaelfolkson> achow101: I don't care about it personally :) I just don't want it delaying reviewing of PR(s)
< 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.
< jeremyrubin> I don't have a preference either way
< achow101> jeremyrubin: note that 21377 has changed to using an activation height. It only uses MTP for start and timeout time
< jeremyrubin> Yep!
< michaelfolkson> luke-jr: Assuming. a release of May 1 when does the PR need to be merged by?
< michaelfolkson> I'm kind of in the dark on whether the proposed startheight of May 1st is doable
< luke-jr> michaelfolkson: typically there's at least 1 week of a RC
< luke-jr> add a few days to backport I guess
< 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
< 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.
< michaelfolkson> And what needs to be done in advance of May 1st. Lots of communication to mining pools, users etc?
< achow101> so any future release will need to wait for that cert to be renewed
< jeremyrubin> and activationheight is agreed on across both proposals
< luke-jr> michaelfolkson: ST is okay because it's okay if ST fails
< wumpus> achow101: good to know
< michaelfolkson> luke-jr: Right but we want to give it as good chance as we can to succeed
< michaelfolkson> Releasing quietly and waiting until it fails shouldn't be the plan
< 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
< 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
< achow101> jeremyrubin: I expect I'll have it resolved by the time we're ready to make a release anyways
< wumpus> jeremyrubin: that doesn't seem to be the case at all
< meshcollider> Is this going to be 21.1 release, not 22?
< luke-jr> jeremyrubin: we could always publish the unsigned binaries, but it'd be better to not have an odd release
< wumpus> not codesigning it will probably hinder adoption i think that would be even worse and besides there is no real hurry
< 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
< 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
< wumpus> please
< 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
< achow101> in order to make the May 1st start time, I think we should get 0.21.1 by April 24th at the latest
< wumpus> right
< 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
< michaelfolkson> But it sounds like May 1st is doable which is great
< achow101> For 2 RCs, we need to get everything in by April 10th
< jeremyrubin> michaelfolkson: I don't see any concrete dates there?
< jeremyrubin> so I don't know what people are ACKing w.r.t. a timeline
< michaelfolkson> If anyone has concerns though about this timetable please raise them. Personally I think a delay of a few weeks would be ok
< achow101> Since this requires backport, I think having the PRs merged to master by April 3rd is the latest
< achow101> then a week for backport
< achow101> then RC1 and so on
< michaelfolkson> jeremyrubin: They are ACKing the proposal
< 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
< achow101> indeed
< wumpus> maybe two competing approaches is fine but let's not open more :-)
< 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
< michaelfolkson> But if we can avoid that it would be great
< jeremyrubin> michaelfolkson: I just don't see a specific startheight/startime in the proposal
< wumpus> aiming for april 3 sgtm
< 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
< sipa> 2 weeks (tm)
< wumpus> it is short time though
< luke-jr> let's aim for March 25th then
< luke-jr> :P
< michaelfolkson> jeremyrubin: Good point. The dates were in a follow up email https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html
< jeremyrubin> michaelfolkson: so I'm not sure what timetable you think is being ackd
< sipa> let's just focus on code review
< jeremyrubin> Gotcha, but it's unclear that was ACKd. My read is people ACKd the general shape of it
< sipa> let me know what to look at
< wumpus> we should probably delay merging anything that conflicts
< michaelfolkson> jeremyrubin: That's fair challenge
< jeremyrubin> so I think it's fine for core to pick reasonable times
< meshcollider> #21392
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< meshcollider> FWIW I don't think the size of the diff of achow101's version is really an issue ^
< 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)
< wumpus> having to rebase the PR all the time will not make it getting through review easier, after all
< amiti> the diff is much smaller and mostly tests
< wumpus> amiti: +1
< luke-jr> amiti: consensus comes first
< achow101> the ci failure on 21392 should be fixed now
< amiti> achow101: cool, and I'm not opposed to 21392, I'm just saying its a bigger patch requires more review.
< 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
< jeremyrubin> I don't think "BIP9 is dead" is useful here
< jeremyrubin> the code works fine
< michaelfolkson> Code is most important
< 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
< jeremyrubin> the property that achow101's PR improves is a fixed # of signals
< achow101> it comes down to mtp vs block height
< michaelfolkson> amiti: I think there is consensus on block height from what I've seen
< jeremyrubin> The question is if it is worth addtl review on new code.
< jeremyrubin> I agree that height is superior long term
< michaelfolkson> (but there are still a lot of reviewers who haven't looked at it yet)
< amiti> micahelfolkson: I don't think you can claim that there is consensus on either, neither patch has been thoroughly reviewed
< 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
< luke-jr> jeremyrubin: without height, ST doesn't have community support
< achow101> amiti: consensus on the concept
< 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
< luke-jr> amiti: consensus has nothing to do with review
< michaelfolkson> amiti: I'm only basing it on what I've seen in discussions and meetings. I personally don't have a (strong) view
< michaelfolkson> We've had meetings with a number of Core contributors showing up and discussing it
< jeremyrubin> achow101: the risk is tiny with MTP if you target mid signal periods, and only the last one matters
< michaelfolkson> Deliberately off this channel so as not to block this channel for weeks/months
< jeremyrubin> (is my point about mid period times falling on deaf ears?)
< jeremyrubin> you would need a super large hashrate shift to happen, and then we'd have bigger problems
< jonatack> will review both soon
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/a65e772fec62...8ec881d3b694
< bitcoin-git> bitcoin/master da2bb69 Pieter Wuille: Implement Bech32m encoding/decoding
< bitcoin-git> bitcoin/master 25b1c6e Pieter Wuille: Add Bech32m test vectors
< bitcoin-git> bitcoin/master fe5e495 Pieter Wuille: Use Bech32m encoding for v1+ segwit addresses
< sipa> \o/
< jnewbery> yay!
< 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
< jnewbery> thanks wumpus
< wumpus> \o/
< achow101> jeremyrubin: I get that, but both start and end matter.
< jonatack> b-b-b-bech32mmmmmm
< michaelfolkson> jeremyrubin: I think that would be a material change to the proposal
< glozow> :M:
< achow101> jeremyrubin: that would move the start time to april 24th, which also affects our timelin for merging things
< jnewbery> is the conclusion to this conversation going to be that people should review PRs?
< achow101> I guess we could just ignore that first half-period
< 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
< jeremyrubin> achow101: exactly... it can't hit threshold anyways
< jnewbery> wumpus: sounds good!
< michaelfolkson> Right, agreed jnewbery wumpus
< amiti> wumpus: sounds good :)
< wumpus> if we can make a decision between the two PRs quickly that would be even better
< wumpus> and allow focusing attention, but obviously that shouldn't be done in the meeting
< michaelfolkson> Yup
< luke-jr> only one of them is socially viable anyway..
< wumpus> any other topics?
< amiti> also want to quickly mention #21380, adds fuzz tests to version bits, useful coverage whichever PR/technique we go with
< gribble> https://github.com/bitcoin/bitcoin/issues/21380 | tests: Add fuzzing harness for versionbits by ajtowns · Pull Request #21380 · bitcoin/bitcoin · GitHub
< achow101> dongcarl had one?
< michaelfolkson> amiti: Cool
< luke-jr> achow101: I think he wanted to do it after the meeting tho
< wumpus> achow101: but for after the meeting he said
< wumpus> yea
< dongcarl> Just a quick Guix update once everyone's done discussing :-)
< wumpus> amiti: good point
< midnight> \o/ also!
< wumpus> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu Mar 18 19:44:39 2021 UTC.
< dongcarl> Here's my quick Guix update:
< dongcarl> Originally, I planned to build things heads-down for 5 wks (ending today) then do user-testing + refinement for 5 weeks (ending on April 22nd). /1
< dongcarl> However, many of you were eager enough to test my half-baked scripts, and I’m actually glad we did it this way because many pitfalls were discovered and fixed along the way (see #21375)! Thanks all! /2
< dongcarl> So the new plan (operation “roll-with-it”) is this: we do the building + user testing for 4 more weeks (ending on April 15th), and after that we’ll agree on a commit on which to perform a non-codesigned build and upload signatures to `guix.sigs`. /3
< gribble> https://github.com/bitcoin/bitcoin/issues/21375 | guix: Misc feedback-based fixes + hier restructuring by dongcarl · Pull Request #21375 · bitcoin/bitcoin · GitHub
< dongcarl> I will update the umbrella ticket with this updated timeline today. This does not eat into our 4 week contingency buffer period
< achow101> dongcarl: cool!
< hebasto> nice
< sipa> sgtm, i'm all set up
< dongcarl> :-)
< achow101> I'll start testing after taproot stuff is merged :)
< dongcarl> Thanks again all for testing!
< jnewbery> dongcarl: thanks for the update. Very impressive that you're making such great progress with guix _and_ on #20158
< gribble> https://github.com/bitcoin/bitcoin/issues/20158 | tree-wide: De-globalize ChainstateManager by dongcarl · Pull Request #20158 · bitcoin/bitcoin · GitHub
< jonatack> dongcarl: nice! haven't dove into it yet but looking forward
< dongcarl> jnewbery: :-) Hehe thanks John!
< dongcarl> jonatack: Reach out any time if you run into anything!
< wumpus> dongcarl: sounds great to me!
< jonatack_> dongcarl: (whoops lost the connection) thanks! seems to be the culmination of quite a bit of work leading to this point, so good to see!
< wumpus> i've been doing regular guix builds of master and PRs and it seems to work quite smoothly now
< dongcarl> wumpus: Glad to hear it!
< achow101> dongcarl: has the gnutls problem been fixed in a release yet?
< dongcarl> achow101: Not yet, I think upstream is coordinating one soon. I will post on the mailing list again to ask for an update.
< dongcarl> See it as... Very temporary incentive to bootstrap Guix from source XP
< achow101> ugh
< sipa> or enable substitutes for just gnutls *ducks*
< hebasto> dongcarl: any update on non-determinism issue for macos builds?
< dongcarl> hebasto: see #bitcoin-builds
< dongcarl> or reset your system time *ducks*
< sipa> wumpus: how do you use the backport.py script?
< aj> MarcoFalke: are we at "->soon" for 21380 yet?
< wumpus> sipa: run it from the repository directory, easiest is to pass the PR numbers on the command line
< wumpus> sipa: with the branch checked out you want to backport to
< sipa> that's what i assumed, but it says: Missing: [...]
< wumpus> what is the exact command line you are giving?
< sipa> doesn't matter, #20861 isn't a trivial backport anyway
< 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> mind that you have to specify the PR number without # as that makes it a comment :)
< wumpus> also, make sure the 'master' branch is up to date and has that PR
< sipa> i did: ~/git/bitcoin-maintainer-tools/backport.py 20861
< wumpus> maybe `git fetch origin master:master` to make sure your repository's master branch is up to date (even if you are on the 0.21 branch)
< hebasto> wumpus: luke-jr: I'll appreciate your opinion on #21465 :)
< gribble> https://github.com/bitcoin/bitcoin/issues/21465 | translation: Provide more context to Transifex translators · Issue #21465 · bitcoin/bitcoin · GitHub
< wumpus> i will have a look
< hebasto> wumpus: thanks
< wumpus> hebasto: sorry, i think some of the changes are a bit questionable/unnecessary, fine to let other people weigh in i don't have strong opinions about it but you asked me explicitly :)
< hebasto> wumpus: I was talking about 21465, not #21463...
< gribble> https://github.com/bitcoin/bitcoin/issues/21463 | doc: Address feedback from Transifex translator community by hebasto · Pull Request #21463 · bitcoin/bitcoin · GitHub
< hebasto> anyway, thanks for your feedback on 21463
< bitcoin-git> [bitcoin] sipa opened pull request #21469: Implement Bech32m encoding/decoding (0.21 backport) (0.21...202103_bech32m_0.21) https://github.com/bitcoin/bitcoin/pull/21469
< wumpus> hebasto: oh, yes, will take a look at that one too, I assumed it was the one you just opened
< bitcoin-git> [bitcoin] sipa opened pull request #21470: Implement Bech32m encoding/decoding (0.20 backport) (0.20...202103_bech32m_0.20) https://github.com/bitcoin/bitcoin/pull/21470
< bitcoin-git> [bitcoin] sipa opened pull request #21471: bugfix: fix bech32_encode calls in gen_key_io_test_vectors.py (master...202103_bech32m_fix_genscript) https://github.com/bitcoin/bitcoin/pull/21471
< bitcoin-git> [bitcoin] sipa opened 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
< luke-jr> hebasto: I guess it's a good idea; but might be a good idea to ask Transifex to support it in TS files first?
< hebasto> luke-jr: they have a paid service for fork flow with XLIFF
< hebasto> "Translate using XLIFF files as an intermediate format if you’re working with professional translators" -- https://www.transifex.com/pricing/
< hebasto> *for work
< luke-jr> wait, we'd need to pay to use it?
< hebasto> no
< hebasto> conversion on their side is paid -- "File conversion to XLIFF format is only available on the Premium plan and up."
< hebasto> suggesting conversion on our side
< luke-jr> i c