< 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.
< 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.
< 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
< 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
< 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)
< 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.
< 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.