< bitcoin-git> [bitcoin] luke-jr opened pull request #18133: Fix various edge case bugs in QValidatedLineEdit (master...bugfix_qvalidlineedit) https://github.com/bitcoin/bitcoin/pull/18133
< bitcoin-git> [bitcoin] Empact opened pull request #18134: Replace std::to_string with locale-independent alternative (master...2020-02-to-string) https://github.com/bitcoin/bitcoin/pull/18134
< bitcoin-git> [bitcoin] fanquake opened pull request #18135: build: add --no-insert-timestamp to Windows linker flags (master...no_insert_timestamp_ld) https://github.com/bitcoin/bitcoin/pull/18135
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2bdc476d4d23...b6a16fa44ef2
< bitcoin-git> bitcoin/master bf36a3c Russell Yanofsky: gui: Fix race in WalletModel::pollBalanceChanged
< bitcoin-git> bitcoin/master b6a16fa Jonas Schnelli: Merge #18123: gui: Fix race in WalletModel::pollBalanceChanged
< bitcoin-git> [bitcoin] jonasschnelli merged pull request #18123: gui: Fix race in WalletModel::pollBalanceChanged (master...pr/pollbug) https://github.com/bitcoin/bitcoin/pull/18123
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b6a16fa44ef2...0c20809da85a
< bitcoin-git> bitcoin/master c9fe612 Hennadii Stepanov: gui: Throttle GUI update pace when -reindex
< bitcoin-git> bitcoin/master 0c20809 Jonas Schnelli: Merge #18121: gui: Throttle GUI update pace when -reindex
< bitcoin-git> [bitcoin] jonasschnelli merged pull request #18121: gui: Throttle GUI update pace when -reindex (master...20200211-reindex-gui) https://github.com/bitcoin/bitcoin/pull/18121
< fanquake> wumpus sipa can you block https://github.com/1b3634f6-9166-46d7-a43a-51d575159cf0 from the wiki / repo
< bitcoin-git> [bitcoin] Bushstar opened pull request #18138: build: remove redundant compiler error supression (master...redundant-no-error) https://github.com/bitcoin/bitcoin/pull/18138
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18139: doc: Add missing author to 0.19.1 release notes (0.19...2002-docRelAuth) https://github.com/bitcoin/bitcoin/pull/18139
< bitcoin-git> [bitcoin] Bushstar closed pull request #18138: build: remove redundant compiler warning suppression (master...redundant-no-error) https://github.com/bitcoin/bitcoin/pull/18138
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/628103d67302...a28ea316ed47
< bitcoin-git> bitcoin/0.19 facbdc0 MarcoFalke: doc: Add missing author to 0.19.1 release notes
< bitcoin-git> bitcoin/0.19 a28ea31 Wladimir J. van der Laan: Merge #18139: doc: Add missing author to 0.19.1 release notes
< bitcoin-git> [bitcoin] laanwj merged pull request #18139: doc: Add missing author to 0.19.1 release notes (0.19...2002-docRelAuth) https://github.com/bitcoin/bitcoin/pull/18139
< promag> wumpus: sorry, bad week with flu.. will try to catch especially those that I think should go before feature freeze
< wumpus> promag: thanks, no problem (I'm not sure anything needs to be done for #17746)
< gribble> https://github.com/bitcoin/bitcoin/issues/17746 | rpc: Remove vector copy from listtransactions by promag . Pull Request #17746 . bitcoin/bitcoin . GitHub
< promag> I'll add Russell suggestions
< jonatack> Should #17812 be tagged for v0.20? (also, is a release note needed for the asmap config?)
< gribble> https://github.com/bitcoin/bitcoin/issues/17812 | config, net, test: asmap functional tests and feature refinements by jonatack . Pull Request #17812 . bitcoin/bitcoin . GitHub
< wumpus> it would definitely be nice to have a release note for asmap, noting that it's an experimental feature, what it does, a link to how to use it
< jonatack> yes. will propose this weekend (separately from 17812 since it already has review and acks) if gleb doesn't do one before
< jonatack> heh, only now realised that it's friday already
< jonatack> err, thursday
< luke-jr> would asmap be worth including in Knots 0.19.1 for some earlier testing? mostly I'd just need to get rid of the dummy binary file (patch doesn't like those)
< sipa> i don't think we're planning on distributing the map file yet
< luke-jr> sipa: last time I looked, the PR had a like ~30 byte binary file included?
< luke-jr> I assume an empty asmap
< jonatack> sipa: ETA? is review needed in sipa/asmap? fwiw i've been running an experimental node since weeks with sipa/asmap/demo.map (932999 bytes)
< sipa> luke-jr: oh, that's for the testz
< sipa> we have plenty of binary files for testing, no?
< luke-jr> ah, I can probably just drop the test then
< luke-jr> sipa: probably, but I distribute Knots in patch form, so I can't add binary files
< luke-jr> keyword: add
< sipa> ah
< sipa> jonatack: ETA for what?
< jonatack> sipa: distributing the map file. still, users may want to generate their own, i suppose?
< jonatack> (this is unclear to me and i should look at that)
< * luke-jr> wonders how much damage a malicious asmap could do
< sipa> jonatack: i think the plan was to not have a distributed one in the first release
< wumpus> sipa: agree, not for 0.20
< wumpus> luke-jr: with regard to malicious asmaps, I wouldn't assume the curent code is completely hardened against that, there might be more bugs like the one in https://github.com/bitcoin/bitcoin/pull/18023/commits/c86bc144081f960347232546f7d22deb65d27deb
< vasild> #17563 fixes a compilation error on FreeBSD (assuming -Werror). Right now I have to apply that fix on top of whatever other changes I have made in order to compile (I refuse to depart from -Werror). Would be nice to get some more reviews. It already has one ACK.
< gribble> https://github.com/bitcoin/bitcoin/issues/17563 | lib: fix a compiler warning: unused GetDevURandom() by vasild . Pull Request #17563 . bitcoin/bitcoin . GitHub
< jonatack> luke-jr: i began writing tests for unparseable asmap files but the scope goes beyond the changes in the open PR, see https://github.com/bitcoin/bitcoin/pull/17812/#discussion_r377734856
< jonatack> also there is work that can be done on the unit tests
< luke-jr> wumpus: I was thinking more like getting nodes to connect to malicious peers
< sipa> luke-jr: in that case, yes, trivially
< sipa> mark the entire internet except the attacker's range as one AS
< luke-jr> sipa: you wouldn't end up with at least half the peers from the internet?
< sipa> no; the attacker would mark each of his IPs as separate ASes
< wumpus> heh
< sipa> and then the rest of the internet as one
< luke-jr> o
< jonatack> perhaps some sanity checks could be added
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0c20809da85a...470664f2b788
< bitcoin-git> bitcoin/master 25bc17f Joao Barbosa: refactor: rpc: Remove vector copy from listtransactions
< bitcoin-git> bitcoin/master 470664f Wladimir J. van der Laan: Merge #17746: refactor: rpc: Remove vector copy from listtransactions
< bitcoin-git> [bitcoin] laanwj merged pull request #17746: refactor: rpc: Remove vector copy from listtransactions (master...2019-12-listtransactions) https://github.com/bitcoin/bitcoin/pull/17746
< dongcarl> If I understand correctly... we only have one codesigner for windows?
< cfields_> dongcarl: yup
< dongcarl> who's the assigned codesigner?
< cfields_> and the cert expires in March, should probably discuss.
< cfields_> dongcarl: me
< cfields_> dongcarl: why do you ask?
< dongcarl> Ah okay, question: in both release-process.md and gitian-win-signer.yml, there's reference to a bitcoin-osx-unsigned.tar.gz
< dongcarl> However, I only ever see a bitcoin-0.19.99-win-unsigned.tar.gz in the output... is it manually renamed?
< dongcarl> sorry I mean... bitcoin-win-unsigned.tar.gz
< cfields_> "tar xf ../bitcoin-0.19.1rc2-win-unsigned.tar.gz"
< cfields_> Is what I unpacked to sign rc2
< cfields_> Oh, sorry. This is in my building script:
< cfields_> cp build/out/*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz
< dongcarl> cfields_: Okay so is the codesigning done outside of gitian? And the gitian-win-signer.yml is just the signature attachment that's doable by everyone?
< cfields_> dongcarl: IIRC it's to avoid having to change the gitian recipe for each release.
< cfields_> Right
< wumpus> yes, gitian-win-signer attached the signature and validates the result IIRC
< dongcarl> I see, this is roughly the same for gitian-osx-signer as well?
< cfields_> I take bitcoin-0.19.99-win-unsigned.tar.gz, untar it, run the script inside, and commit the results to bitcoin-detached-sigs
< cfields_> Yup
< dongcarl> (I'm implementing the functionality in guix right now that's why I'm asking)
< dongcarl> cool, thanks!
< cfields_> Ok. No need to emulate the name weirdness. Renaming to bitcoin-win-unsigned.tar.gz is just a hack.
< cfields_> and same for osx.
< dongcarl> roger that!
< cfields_> #proposedmeetingtopic expiring Windows codesigning key
< kanzure> #proposedmeetingtopic topic collection for physical meeting (follow-up)
< achow101> dongcarl: #14325 changed the gitian-build.py script to use the versioned tarball instead of the generic one so that you could do concurrent release builds
< gribble> https://github.com/bitcoin/bitcoin/issues/14325 | [gitian] use versioned unsigned tarballs instead of generically named ones by achow101 . Pull Request #14325 . bitcoin/bitcoin . GitHub
< dongcarl> achow101: Ah. There are too many places to look for what gitian is actually doing... Thanks for the pointer
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 13 19:00:50 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jnewbery> hi
< cfields_> hi
< fjahr> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
< wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
< provoostenator> hi
< hebasto> hi
< amiti> hi
< emilengler> hi
< jonasschnelli> hi
< kanzure> hi
< jb55> hi
< jonatack> hi
< jkczyz> hi
< achow101> hi
< wumpus> no proposed topics for today in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a, but some have been proposed above by cfields_ and kanzure
< wumpus> kanzure | #proposedmeetingtopic topic collection for physical meeting (follow-up)
< kanzure> oh it's not an automated tool
< kanzure> yeah so i'm still collecting topic suggestions for coredev.tech meeting
< wumpus> cfields_ | #proposedmeetingtopic expiring Windows codesigning key
< wumpus> no it's not automated afaik
< wumpus> any other last minute topics?
< cfields_> Oh whoops, I thought something scraped them too.
< achow101> should make an automated tool to collect those
< wumpus> I'm sure moneyball will be thankful if you make one :)
< wumpus> #topic High priority for review
< provoostenator> I'd like to nominate #17509 for hi-prio review (gwillen has a PR on top)
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 -- 8 blockers, 1 bugfix, 6 chasing concept
< gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors . Pull Request #17509 . bitcoin/bitcoin . GitHub
< achow101> Replace #16528 with #18034. we keep deciding it's a good idea to stack more PRs before descriptor wallets :/
< gribble> https://github.com/bitcoin/bitcoin/issues/16528 | Native Descriptor Wallets using DescriptorScriptPubKeyMan by achow101 . Pull Request #16528 . bitcoin/bitcoin . GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/18034 | Get the OutputType for a descriptor by achow101 . Pull Request #18034 . bitcoin/bitcoin . GitHub
< wumpus> 17509 added
< meshcollider> hi
< wumpus> achow101: why is that? (deciding to stack more PRs)
< moneyball> i would very much welcome a tool that automates my process of downloading the log archive and grep'ing for proposed meeting topics!
< wumpus> replaced 16528 with 18034
< achow101> mostly just cleaning things up so descriptor wallets is slightly less painful to review
< achow101> missed a few things during all of the wallet boxes stuff, including a glaring hole in the design itself that doesn't work with hardware wallets
< wumpus> okay if it helps review that's good
< wumpus> whoops
< wumpus> #topic Expiring windows codesigning key (cfields_)
< cfields_> For once we're not scrambling to deal with an expired codesigning cert. The current Windows cert expires on Mar 26, 23:59:59 2020 GMT. We'll need to renew before then.
< cfields_> Last year gwillen was kind enough to renew the cert for us.
< cfields_> Also, it probably makes sense for the signer to be someone more active.
< wumpus> any volunteers? what's involved?
< achow101> does it require a windows machine?
< jonasschnelli> We could purchase it via the Bitcoin Core Code Signing Association
< wumpus> jonasschnelli: was about to suggest that
< jonasschnelli> (make sure the certificate belong to that name)
< cfields_> No, Windows isn't required. You hold a key and run a bash script for each release.
< jonasschnelli> there are no funds though,.. :)
< jonatack> how often does the cert expire?
< cfields_> Since it's not a rush this time, I can open a github issue to discuss.
< wumpus> how expensive is a cert?
< cfields_> jonatack: This one was a 1year, I think you can also buy a 2.
< jonasschnelli> Last time I checked most cert where around 200usd
< cfields_> wumpus: good question, sec.
< jonasschnelli> (per year)
< jonasschnelli> always depends on the issuer...
< wumpus> I guess we can't use the travel fund for this?
< jonasschnelli> we could... or we find a generous sponsor. :)
< achow101> I could do the signing. I've done every gitian build for quite a while, usually on time
< jonasschnelli> I sponsor the apple one already,...
< jonasschnelli> ack on achow101
< jonasschnelli> (thanks for volunteering)
< wumpus> sounds good to me!
< cfields_> Yeah, I can't find the price off-hand, but it was somewhere under $200. IIRC closer to $100 for the 1yr.
< jonasschnelli> I guess its best if you achow101 purchase the cert.. we can pay it via the coredev.tech fund if no-one opposes that
< wumpus> +1
< wumpus> but sure, if we can find another sponsor that'd be great
< achow101> sure
< kanzure> moneyball: http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt should have topics collected ~5 minutes before each meeting. let me know if it breaks.
< jonasschnelli> thanks to a falling USD, the coredev.tech bitcoin holding have quite some purchase power
< achow101> I wonder if I can expense it to blockstream...
< jonasschnelli> heh. try it!
< cfields_> I can buy if we can't find a sponsor. Buying my way out :)
< jonasschnelli> cfields_: you did great! No need to buy yourself out
< achow101> cfields_: is the script(s) in contrib/windeploy?
< wumpus> yes, thanks for all your work
< cfields_> Ok, will discuss with achow outside of the meeting.
< achow101> +1
< wumpus> #topic Topic collection for physical meeting (kanzure)
< kanzure> yeah still collecting topics, let me know what you do or don't want to hear about
< cfields_> achow101: yes, but gitian spits them out. It's as simple as running a script from the gitian payload.
< kanzure> things on the list include stuff like guix, more build stuff, erlay, miniscript integration, descriptor wallets
< kanzure> HWI updates will probably get in there...
< kanzure> oh and forgot about taproot. anyway, that's all.
< achow101> kanzure: oh yeah, HWI. add that to mine
< kanzure> added.
< kanzure> i think hearing about the fuzzing work would be interesting
< jnewbery> people have given me some topic requests in the survey responses. I'll pass those on to you, kanzure
< kanzure> thank you
< kanzure> another note here's my two second hack for proposedmeetingtopic scraping (set to run 5 minutes before the meeting time each day) http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
< jnewbery> incidentally, thank you to everyone who replied to the survey (30 responses so far). Very much appreciate your time. I'll present aggregate results at coredev
< cfields_> kanzure: heh, nice.
< wumpus> that was quick :)
< wumpus> any other topics?
< wumpus> nothing else to discuss?
< kanzure> i am now daily timestamping the logs?
< emilengler> cool
< kanzure> not much of a topic :)
< emilengler> well but good to know
< jeremyrubin> hi
< cfields_> oh, quick last-second thing...
< jonasschnelli> macOS notarization is also done now. We start with the next release
< wumpus> nice!
< cfields_> would there still be interest in a multi-signer protocol for codesigning? That might be a good project for a student around here.
< cfields_> Not for this time around, ofc. But maybe for next time.
< jonasschnelli> I question if it is worth the effort... but if someone is up for... yeah. Why not
< jonasschnelli> Just expect that Apple changes the key types (and enforces them) probably with 1 week notice.. :)
< cfields_> Heh, fair point.
< jonasschnelli> I guess its still RSA right now... but I'm sure they have plans to migrate away from that
< achow101> cfields_: hasn't that been on the todo list for the past 6 or so years?
< jonasschnelli> heh.. maybe past 4
< cfields_> achow101: heh, yep, every time codesigning comes up. But this time I might actually be able to sucker someone into doing it :)
< wumpus> it's a pretty old idea by now, yes, the problem is backfitting something like that into proprietary codesigning systems
< jonasschnelli> And at the end, it's little security/trust compared to our gitian signatures
< wumpus> right, it's not as if it's going to replace gitian signature verification
< cfields_> Ok, not much interest.
< jonasschnelli> I would rather invest resources in having a release-checker within bitcoin-cores binary (+Qt)
< cfields_> Thanks, that's a helpful answer too.
< jonasschnelli> Gitian is such a nice process.... but I doubt many people verify (which makes it kinda pointless).
< jonasschnelli> If they could just verify from directly withing older bitcoin core versions.
< wumpus> well at least the people that build verify that's something...
< jonasschnelli> yes. that alone is a big plus.
< cfields_> Yeah, I see it more as a proof that it can be done.
< cfields_> Anyway, </topic>. Thanks.
< wumpus> but yes it might be nice to have a tool that automates verification integrated, so that if people have one version of bitcoin core they can verify a newer one they downloaded
< jonasschnelli> not that its not a cool project.
< jonasschnelli> wumpus: Yes. Agree. We could have secp256k1 signatures from the gitian assert files... then verify those within core
< wumpus> yup
< wumpus> any other topics?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 13 19:39:42 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa> oops
< cfields_> @sipa Well you were 18min early, at least :)
< sipa> more like 10062 minutes early
< wumpus> that's a lot of minutes
< provoostenator> Just did a brain dump about how to (mabey) coordinate a multisig wallet setup: https://github.com/bitcoin/bitcoin/issues/18142
< jeremyrubin> sdaftuar: here?
< bitcoin-git> [bitcoin] bitzec opened pull request #18143: Update chainparams.cpp (master...patch-1) https://github.com/bitcoin/bitcoin/pull/18143
< bitcoin-git> [bitcoin] fanquake closed pull request #18143: Update chainparams.cpp (master...patch-1) https://github.com/bitcoin/bitcoin/pull/18143
< gwillen> provoostenator: thanks for putting 17509 up for hi-pri, I am on a train and had no cell signal during the meeting