< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e5d47ed8fd37...4502ed7cd1b3
< bitcoin-git> bitcoin/master fab2527 MarcoFalke: test: Disable mockforward scheduler unit test for now
< bitcoin-git> bitcoin/master 4502ed7 fanquake: Merge #18211: test: Disable mockforward scheduler unit test for now
< bitcoin-git> [bitcoin] fanquake closed pull request #18174: WIP test: make mockscheduler test more reliable (master...2020-02-fix-scheduler-test) https://github.com/bitcoin/bitcoin/pull/18174
< bitcoin-git> [bitcoin] fanquake merged pull request #18211: test: Disable mockforward scheduler unit test for now (master...2002-testSchedulerWorkaround) https://github.com/bitcoin/bitcoin/pull/18211
< bitcoin-git> [bitcoin] fanquake closed pull request #18174: WIP test: make mockscheduler test more reliable (master...2020-02-fix-scheduler-test) https://github.com/bitcoin/bitcoin/pull/18174
< fanquake> Kiminuo: Not sure if your still working on it, but rather than continuously pushing to the branch in #18210, can you setup Travis to run on your own repository while your testing/debugging.
< gribble> https://github.com/bitcoin/bitcoin/issues/18210 | test: type hints in Python tests by kiminuo · Pull Request #18210 · bitcoin/bitcoin · GitHub
< fanquake> That saves our Travis resources, and saves me (and anyone subscribed to the repo) from continual notifications.
< Kiminuo> fanquake, Ah, sorry. Thanks for information
< provoostenator> achow101 I don't have strong feelings if we should cache all the things or not. A typical wallet would still be smaller than a single block.
< provoostenator> If the performance difference is very small than I'm biased to keeping it lean.
< provoostenator> (disk cache I mean)
< bitcoin-git> [bitcoin] dangershony opened pull request #18212: Add missing step in win deployment instructions. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/18212
< instagibbs> anyone else having trouble getting comments through in github
< instagibbs> yeah submitting review giving me an octopus
< pinheadmz> instagibbs: https://www.githubstatus.com/ ... guess I'll... go ... outside??
< instagibbs> Going to start e-mailing reviews now
< jonatack> Apologies to those whose PRs I planned to finish reviewing this week... been fighting off something flu-like this week (despite getting a flu shot last fall)
< jonatack> sounds like GitHub hasn't been cooperating with review, either
< elichai2> jonatack: hope you'll feel better soon!
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 27 19:00:42 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.
< jonatack> elichai2: thanks! your siphash pr and suhas' wtxid one are top of my list
< provoostenator> hi
< kanzure> hi
< elichai2> Hi
< achow101> hi
< sipa> hi
< jonatack> 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
< hebasto> hi
< lightlike> hi
< promag> hi
< fjahr> hi
< meshcollider> hi
< jonasschnelli> hi
< wumpus> two proposed topics in proposedmeetingtopics: macOS notarization (jonasschnelli), more topic collection for upcoming physical meeting (kanzure)
< wumpus> any last minute topics?
< wumpus> FWIW 0.20.0 feature freeze is in about half a month
< instagibbs> hi
< wumpus> #topic High priority for review
< wumpus> 7 blockers, 1 bugfix, 6 chasing concept ACK in https://github.com/bitcoin/bitcoin/projects/8
< achow101> Add #18115
< gribble> https://github.com/bitcoin/bitcoin/issues/18115 | wallet: Pass in transactions and messages for signing instead of exporting the private keys by achow101 · Pull Request #18115 · bitcoin/bitcoin · GitHub
< provoostenator> +1
< wumpus> added
< wumpus> anything else to add/remove, or that is ready for merge?
< provoostenator> I was hoping #17509 is ready, though maybe meshcollider can review first (it's not strictly wallet)
< gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
< wumpus> that one does seem the closest
< gleb> hi
< jnewbery> hi
< ariard> hi
< meshcollider> provoostenator: sure, I can review it :) Missed it actually sorry because it's only tagged GUI
< sdaftuar> hi
< provoostenator> If it makes it in, I pre-nominate gwillen's #18027 after that, nice to get that in for the feature freeze
< gribble> https://github.com/bitcoin/bitcoin/issues/18027 | "PSBT Operations" dialog by gwillen · Pull Request #18027 · bitcoin/bitcoin · GitHub
< instagibbs> yeah that would be awesome ^
< wumpus> that would be very nice
< MarcoFalke> Can I add #17809 to high prio? It is a lot of changes, but shouldn't be too hard to review.
< gribble> https://github.com/bitcoin/bitcoin/issues/17809 | rpc: Auto-format RPCResult by MarcoFalke · Pull Request #17809 · bitcoin/bitcoin · GitHub
< instagibbs> no need to open up -cli/console for anything PSBT related
< provoostenator> +1
< wumpus> MarcoFalke: sure
< wumpus> added
< wumpus> #topic macOS notarization (jonasschnelli)
< provoostenator> We could try #18187 on v0.19.1rc3; if that's the only change it can be tested very quickly.
< gribble> https://github.com/bitcoin/bitcoin/issues/18187 | Add macOS notarization (including stapling) by jonasschnelli · Pull Request #18187 · bitcoin/bitcoin · GitHub
< jonasschnelli> 18187 is pretty much it
< wumpus> do we need a 0.19.1rc3?
< jonasschnelli> It changes the process how we create the final macOS app
< jonasschnelli> for the notarization, we don't need a rc3 I think... but it could help
< provoostenator> It adds a staple to the signed binary, which is better for privacy
< wumpus> thanks for working on this btw
< provoostenator> And something we should test ideally
< jonasschnelli> yes.
< jonasschnelli> if there are any questions or possible problems (privacy / security), ask now! :)
< wumpus> yes, we could do a rc3 just to test this, though I think many would like 0.19.1 out of the door, and we could test this for 0.20.0rc1 as well it takes somewhat longer but dunno
< wumpus> it's more in line with the usual flow of doing things on master first
< wumpus> but no strong opinion
< provoostenator> True, but it's nice to test this on a smaller demographic than the 0.20 release
< jonasschnelli> We can notarize 0.19.1 anyways (even without 18187)
< jonasschnelli> I think targeting the pull for 0.20 makes sense
< wumpus> do you think 0.20.0rc1 will have a larger demograhic?
< sipa> 0.20.0 likely will have bigger adoption than 0.19.1
< sipa> don't know about the rc's
< jonasschnelli> Maybe we skip 0.19.1 and focus on a rc
< provoostenator> That's what I mean. The rc I can test myself
< wumpus> a lot of people wait for .1 fwiw
< wumpus> don't know about rcs
< jonasschnelli> There is the risk that we corrupt the final dmg otherwise
< sipa> no strong opinion either way here
< wumpus> ok, lets just merge it for 0.20 then
< jonasschnelli> if I publish the notarization ticket together with the code signature, it would automatically end up in the final dmg
< wumpus> then backport if it works
< jonasschnelli> but we had no test if we go for 0.19.1
< provoostenator> I don't like the privacy implications of not stapling, so then I suggest we don't notarize it, and just leave it right-click to install
< jonasschnelli> yes. Lets merge and do the process only for 0.20rcX
< jonasschnelli> provoostenator: thats a good point.
< jonasschnelli> But no-one AFAIK has done a privacy related test.
< jonasschnelli> We don't know if the GateKeeper server will not be contacted if the ticket is stapled
< jonasschnelli> I haven't tested it (yet)
< jonasschnelli> But very likely its completely offline
< provoostenator> Well, if not, then they might as well ping gatekeeper for non-notarized binaries too and that's the end of macOS privacy :-)
< jonasschnelli> Yes. There are little more we can do...
< wumpus> that's what happens with platforms closing up
< wumpus> Cory Doctorow was right with his war on general purpose computing
< jonasschnelli> Yeah. I guess the staping concept is probably acceptable.
< jonasschnelli> But yeah. It's the digital war agains terrorism
< jonasschnelli> (== - privacy)
< wumpus> yep
< jonasschnelli> What if we notarize 0.19.1 without stapeling?
< wumpus> okay, one topic left
< jonasschnelli> It would run without changing the security settings
< wumpus> #topic more topic collection for upcoming physical meeting (kanzure)
< provoostenator> But it would potentially doxx users to Apple
< kanzure> hey yeah just a reminder that we have a meeting in a month and i'm collecting topics
< kanzure> need to poke jnewbery for survey entries iirc
< jonasschnelli> provoostenator: lets talk on 18187
< kanzure> i have a short document with a list of things that people have asked about.
< kanzure> that's all
< kanzure> in other news, HWI irc logs are now available http://gnusha.org/hwi/
< wumpus> great!
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 27 19:26:46 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< instagibbs> coredev during feature freeze, guess that means more discussion vs merging :)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4502ed7cd1b3...324a6dfeafcb
< bitcoin-git> bitcoin/master 2f63ffd practicalswift: tests: Add fuzzing harness for V1TransportDeserializer (P2P transport)
< bitcoin-git> bitcoin/master 324a6df MarcoFalke: Merge #17771: tests: Add fuzzing harness for V1TransportDeserializer (P2P ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17771: tests: Add fuzzing harness for V1TransportDeserializer (P2P transport) (master...fuzzers-p2p_transport_deserializer) https://github.com/bitcoin/bitcoin/pull/17771
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/324a6dfeafcb...1615043935ef
< bitcoin-git> bitcoin/master b902bd6 Sebastian Falbesoner: test: check custom descendant limit in mempool_packages.py
< bitcoin-git> bitcoin/master 1615043 MarcoFalke: Merge #17461: test: check custom descendant limit in mempool_packages.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #17461: test: check custom descendant limit in mempool_packages.py (master...20191112-test-check_custom_descendant_limit_in_mempool-packages) https://github.com/bitcoin/bitcoin/pull/17461
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18213: test: Fix race in p2p_segwit (master...2002-qaFixRaceSegwit) https://github.com/bitcoin/bitcoin/pull/18213
< Kiminuo> Hello, anyone willing to take a look at https://github.com/kiminuo/bitcoin/commit/150e950461fdb929e45aee50126766c8a159a2c2 for (pre)review?
< instagibbs> Kiminuo, you should just open a "draft" PR for more visibility
< instagibbs> (there's some setting somewhere to make it a draft)
< Kiminuo> I have already did that. I have pushed many force-commits and fanquake was unhappy about that. That's why I have turned on Travis for my account and keep shooting commits there :)
< Kiminuo> this is draft-of-draft :)
< Kiminuo> I'll push it to bitcoin repo when I'm sufficiently happy about it
< luke-jr> don't un-notarised DMGs still ping Apple to see if they are notarized?
< luke-jr> jonasschnelli:
< jonasschnelli> luke-jr: yeah. I have that feeling as well. Otherwise how could the os know its notarized
< jonasschnelli> Maybe it doesn't check if one disables the security feature or if he right-click-opens (don't think so though)
< luke-jr> jonasschnelli: does anything stop <random Joe> from notarising it "for" us? :x
< jonasschnelli> luke-jr: you can only notarize apps with your registered bundle id
< jonasschnelli> (AFAIK)
< jonasschnelli> so you need to provide username/passphrase during notarization which binds to your registered bundle ids
< luke-jr> which is tied to the signing we already do?
< jonasschnelli> as for privacy,... you'r probably already married with Apple somehow.
< jonasschnelli> luke-jr: yes
< luke-jr> + Users running macOS Catalina may need to "right-click" and then choose "Open"
< luke-jr> + to open the Bitcoin Knots .dmg. This is due to new signing requirements
< luke-jr> + imposed by Apple, which the Bitcoin Knots project does not implement.
< luke-jr> wumpus: ^ should be re-added to release notes if we're not doing the notary thing yet
< luke-jr> err, s/Knots/Core/ ofc ;)
< jonasschnelli> luke-jr: do you codesign Knots?
< sipa> i had to read that 3 times before realizing you we're asking luke-jr about co-designers of Knots
< luke-jr> jonasschnelli: no, but I would welcome signatures
< sipa> *weren't
< luke-jr> sipa: haha
< jonasschnelli> sipa: heh
< jonasschnelli> luke-jr: you could register at apple (99$/year) or we could see if we want to sign it with the Bitcoin Core Code Sign Association key.
< luke-jr> jonasschnelli: lately, Knots hasn't even come close to the goal of 3+ gitian sigs even tho :/
< jonasschnelli> I would be okay with that,... as long as we have a clear policy
< luke-jr> jonasschnelli: the latter seems more logical - but IMO we should retain the required gitian signatures first
< jonasschnelli> luke-jr: indeed. I'll try to run my builder next time. Just ping me.
< luke-jr> without 3+ gitian sigs, BCCSA clearly shouldn't sign it
< luke-jr> jonasschnelli: thanks
< bitcoin-git> [bitcoin] instagibbs opened pull request #18214: Give slightly more understandable advice when needing -fallbackfee (master...fallback_msg) https://github.com/bitcoin/bitcoin/pull/18214
< stevenroose> Just a heads up, the estimatesmartfee documentation is not optimal:
< stevenroose> "confirmation within conf_target blocks if possible and return the number of blocks\n"
< stevenroose> "for which the estimate is valid. Uses virtual transaction size as defined\n"
< stevenroose> and then " \"blocks\" : n (numeric) block number where estimate was found\n"
< stevenroose> It's not really clear what the "blocks" return value is supposed to be.
< stevenroose> Is it supposed to be a block height or a block height delta?
< stevenroose> Is it the block height at which a tx with the given fee is supposed to go in? Or does it indicate for how long I can reliably keep using the same estimation?
< stevenroose> If anyone thinks this is confusing enough for me to open an issue, I'd be happy to. Let me know.
< fanquake> stevenroose: opening an issue sounds worthwhile
< stevenroose> Opening one, if you can tell me with certainty what it actually is, I can also make a PR to improve the documentation, if you prefer.
< bitcoin-git> [bitcoin] Empact opened pull request #18216: test, build: Enable -Werror=sign-compare (master...2020-02-sign-compare) https://github.com/bitcoin/bitcoin/pull/18216