19:01:20 <wumpus> #startmeeting
19:01:20 <lightningbot> Meeting started Thu Dec 12 19:01:20 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:20 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:25 <emilengler> hi
19:01:27 <moneyball> hi
19:01:28 <amiti> hi
19:01:28 <sipa> hi
19:01:31 <sipsorcery> hi
19:01:38 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo
19:01:39 <wumpus> 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 jeremyrubin lightlike emilengler jonatack
19:01:49 <fanquake> hi
19:01:49 <jeremyrubin> hi
19:01:51 <jonatack> hi
19:02:24 <fjahr> hi
19:02:33 <wumpus> one proposed topic for this week in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : appveyor CI future
19:02:51 <fanquake> cc sipsorcery
19:02:59 <achow101> hi
19:03:14 <sipsorcery> my suggestion is to switch from appveyor to github actions (which is Azure CI under the hood) purely for speed
19:03:42 <emilengler> I personally think we should use Cirrus CI only as it supports Windows, Linux, macOS and also FreeBSD
19:03:44 <wumpus> sorry, that was not the start of the topic
19:04:07 <wumpus> this is still the "propose your topics" phase of the meeting, then we'll start with high priority for review
19:04:13 <gwillen> I am hoping to get some feedback this week on #17717
19:04:14 <gribble> https://github.com/bitcoin/bitcoin/issues/17717 | Proposed PSBT sign/broadcast flow · Issue #17717 · bitcoin/bitcoin · GitHub
19:04:16 <kanzure> HI
19:04:20 <emilengler> oh sorry
19:04:21 <sipsorcery> oops sorry
19:04:45 <wumpus> gwillen: ok, let's addd that as topic then
19:04:53 <wumpus> #topic High priority for review
19:05:02 <jeremyrubin> #proposedmeetingtopic finish up #12763
19:05:05 <gribble> https://github.com/bitcoin/bitcoin/issues/12763 | Add RPC Whitelist Feature from #12248 by JeremyRubin · Pull Request #12763 · bitcoin/bitcoin · GitHub
19:05:07 <wumpus> https://github.com/bitcoin/bitcoin/projects/8   8 blockers, 7 chasing concept ACK
19:05:13 <jeremyrubin> oh sorry *not* high priority
19:06:05 <wumpus> anything to add/remove or that is ready for merge?
19:06:13 <achow101> #17537 for hi prio
19:06:15 <gribble> https://github.com/bitcoin/bitcoin/issues/17537 | wallet: Cleanup and move opportunistic and superfluous TopUp()s by achow101 · Pull Request #17537 · bitcoin/bitcoin · GitHub
19:06:46 <nehan> hi
19:07:06 <wumpus> achow101: for blockers I guess?
19:07:10 <achow101> yes
19:07:22 <wumpus> ok, added
19:08:17 <wumpus> #topic appveyor CI future (sipsorcery)
19:08:29 <emilengler> Like I said, I personally think we should use Cirrus CI only as it supports Windows, Linux, macOS and also FreeBSD
19:08:30 <wumpus> sipsorcery | my suggestion is to switch from appveyor to github actions (which is Azure CI under the hood) purely for speed
19:08:53 <sipsorcery> second suggestion is to cache the vcpkg dependencies in a .zip file to avoid failures unrelated to PR's.
19:09:09 <luke-jr> emilengler: ppc64?
19:10:00 <emilengler> luke-jr: I'm not sure about that but we keep using travis for this purpose only
19:10:06 <wumpus> I don't think MarcoFalke is here
19:10:06 <emilengler> could keep*
19:10:43 <wumpus> is anyone against moving to github actions for just the MSVC build?
19:10:50 <luke-jr> emilengler: what about distros?
19:10:58 <wumpus> (there is no question of moving *all*CI to github actions, to be clear)
19:11:13 <jeremyrubin> wumpus: given that github is a microsoft product seems reasonable :p
19:11:27 <wumpus> jeremyrubin: heh!
19:11:36 <fanquake> As long as that involves removing all Appveyor usage.
19:11:58 <emilengler> luke-jr: I'm not sure about distros
19:12:17 <wumpus> fanquake: yes, it would
19:12:22 <emilengler> But anyway, I believe that we should use Cirrus CI in the long term. Maybe only for FreeBSD?
19:12:31 <emilengler> But that's anotehr topic
19:12:38 <wumpus> fanquake: this would be about replacing appveyor
19:13:32 <fanquake> wumpus great. If it's faster, and isn't going to be broken seemingly every thrid day for reasons outside our control.
19:13:45 <wumpus> I can't comment on that
19:13:53 <fanquake> Maybe the vcpkg maintainers will stop randomly slicing up their packages.
19:14:15 <MarcoFalke> I got the appveyor timeout back to 90 minutes
19:14:22 <MarcoFalke> Anything else needs to be fixed?
19:14:36 <sipa> but is the issue with appveyor itself, or the fact that vcpkg changes out from under us all the time?
19:14:57 <jeremyrubin> My understanding was that it's vcpkg
19:15:03 <wumpus> both, appveyor is slow and has a low timeout, and the packages switch under us all the time
19:15:08 <jeremyrubin> But that actions will make it less annoying for non windows maintainers
19:15:08 <fanquake> There's a good summary of some of the issues in #17736
19:15:09 <gribble> https://github.com/bitcoin/bitcoin/issues/17736 | Update msvc build for Visual Studio 2019 v16.4 by sipsorcery · Pull Request #17736 · bitcoin/bitcoin · GitHub
19:15:14 <sipa> okay, so there are two independent issues to be fixed
19:15:37 <fanquake> 3 if you include the compiler issues.
19:15:42 <wumpus> yes, I'm not sure in how far they're correlated
19:16:16 <ryanofsky> well my earlier suggestion for dealing with vcpkg issues will not work if appveyor is too slow
19:16:28 <sipsorcery> at a guesstimate on appveyor failures: 5% genuinely relate to PR's, 30% vcpkg, 25% python functional tests, 5% appveyor image, 30% appveyor timeout, 5% other.
19:16:56 <fanquake> a literal roulette wheel
19:17:23 <sipsorcery> suspect GitHub, Cirrus or Circle could all be the same excepting the timeouts.
19:18:17 <sipsorcery> assuming similar reliability, my vote would go to whichever one is fastest
19:18:46 <wumpus> yes
19:19:06 <sipsorcery> GitHub is substantially faster than appveyor. I haven't tested any other but would be happy to do so if it would help?
19:19:33 <luke-jr> speed seems likely to be dependent on how many projects are using them
19:19:39 <luke-jr> ie, if we switch, it will get slow :P
19:20:07 <wumpus> fair enough, our test suite is pretty heavy!
19:20:21 <wumpus> sipsorcery: let's just try github next imo
19:20:32 <wumpus> sipsorcery: no one was strongly against trying them
19:20:33 <MarcoFalke> What about #17736 ?
19:20:35 <gribble> https://github.com/bitcoin/bitcoin/issues/17736 | Update msvc build for Visual Studio 2019 v16.4 by sipsorcery · Pull Request #17736 · bitcoin/bitcoin · GitHub
19:21:12 <wumpus> #17736 would be necessary no matter the CI I think
19:21:13 <gribble> https://github.com/bitcoin/bitcoin/issues/17736 | Update msvc build for Visual Studio 2019 v16.4 by sipsorcery · Pull Request #17736 · bitcoin/bitcoin · GitHub
19:21:19 <sipsorcery> if appveyor is being canned 17736 is not required (at least until GitHub upgrade).
19:21:25 <wumpus> oh
19:21:56 <MarcoFalke> Has anyone tested the GitHub CI and found any issues?
19:22:00 <MarcoFalke> I merged it a few days ago
19:22:46 <fanquake> I didn't realise that Github seems to automatically turn the CI on for any repos that have the config file? Had to turn it off for my own fork.
19:22:58 <fanquake> Didn't realise until a build had failed and it emailed me.
19:23:03 <MarcoFalke> Huh
19:23:11 <MarcoFalke> It was turned off for bitcoin/bitcoin
19:23:12 <sipa> fanquake: maybe you're part of a weird opt in program?
19:23:17 <MarcoFalke> ^
19:23:57 <fanquake> Yea I'm not talking about bitcoin/bitcoin. Which we had tried to turn "Actions" off for. This was one my fanquake/bitcoin fork.
19:24:03 <fanquake> sipa could be
19:24:33 <wumpus> someone, not me at least turned 'actions' back on for bitcoin/bitcoin (which is okay if we're going to use it)
19:24:49 <bitcoin-git> [13bitcoin] 15jamesob opened pull request #17737: Add ChainstateManager, remove BlockManager global (06master...062019-12-au.chainman) 02https://github.com/bitcoin/bitcoin/pull/17737
19:24:49 <fanquake> wumpus Yea I was wondering how that happened
19:25:14 <wumpus> in any case, let'stest it and talk about it next meeting or so
19:25:26 <MarcoFalke> Ok, so unless there are objections: Merge #17736 as short term fix, and then (next week maybe) switch to GitHub Actions CI?
19:25:28 <gribble> https://github.com/bitcoin/bitcoin/issues/17736 | Update msvc build for Visual Studio 2019 v16.4 by sipsorcery · Pull Request #17736 · bitcoin/bitcoin · GitHub
19:25:41 <sipsorcery> +1
19:25:49 <fanquake> +1
19:25:49 <wumpus> ack
19:25:52 <emilengler> +1
19:25:54 <wumpus> #topic Proposed PSBT sign/broadcast flow (gwillen)
19:26:11 <wumpus> #17717
19:26:12 <gribble> https://github.com/bitcoin/bitcoin/issues/17717 | Proposed PSBT sign/broadcast flow · Issue #17717 · bitcoin/bitcoin · GitHub
19:26:32 <sipa> yay, PSBT guis
19:27:11 <gwillen> this is building on top of Sjors' #17509 which is not merged yet
19:27:13 <gribble> https://github.com/bitcoin/bitcoin/issues/17509 | gui: save and load PSBT by Sjors · Pull Request #17509 · bitcoin/bitcoin · GitHub
19:27:33 <gwillen> my general sense is, once we can load PSBTs, the next step is "what are the operations we support on them"
19:27:48 <gwillen> so I think introducing a simple dialog to analyze them, sign them, broadcast them, and save them is a good next step
19:28:04 <gwillen> (this is simpler than the dialog from my old branch, for those of you who saw that, but it will reuse a lot of the parts)
19:28:14 <emilengler> ack
19:28:24 <sipa> i agree with the observation that an explicit update step is probably unnecessary
19:28:49 <gwillen> yeah my approach has always been to automatically update the PSBT eagerly when loading it, and that seems to produce good results
19:29:12 <achow101> seems reasonable
19:29:27 <gwillen> anyway I'm trying to make this a small and uncontroversial step, so feedback welcomed on the issue, there will be a PR soon, thanks!
19:29:29 <sipa> the only reason why you'd want that to be explicit is because of privacy concerns (you may not want to reveal bip32 paths you know about keys used), but the sentiment in #17264 seems to be that that needs to be solved differently anyway
19:29:33 <gribble> https://github.com/bitcoin/bitcoin/issues/17264 | rpc: set default bip32derivs to true for psbt methods by Sjors · Pull Request #17264 · bitcoin/bitcoin · GitHub
19:29:46 <gwillen> sipa: hmm *nod*, will go read the notes on that
19:29:53 <instagibbs> yeah making PSBT private is not super well defined to begin with, you need additional roles
19:31:31 <instagibbs> especially as more special-case fields are entered into it
19:31:31 <luke-jr> "update"?
19:31:45 <instagibbs> luke-jr, filling fields like hd derivation path, etc
19:31:53 <luke-jr> not signing, though, right?
19:31:55 <gwillen> luke-jr: it's possible to have a PSBT that doesn't have things like P2SH redeemscripts, witnessscripts, etc. that are required for signing
19:32:05 <gwillen> I would never have the UI sign automatically, no
19:32:10 <achow101> luke-jr: correct. update is done before signing
19:32:12 <sipa> luke-jr: BIP 174 updating is filling in UTXOs/prevtxs, bip32 paths, scripts used
19:32:12 <gwillen> thanks for noting that clarification
19:32:28 <gwillen> signing is always a big red button that's explicit
19:32:31 <luke-jr> hmm
19:32:37 <instagibbs> updating is done to "guide" signing, especially for dumb signers
19:32:49 <luke-jr> exposing redeemscripts is arguably partially a signature?
19:33:10 <gwillen> well the design of PSBT in Core is such that the wallet creating the tx will already include them if it knows them
19:33:12 <sipa> luke-jr: it doesn't involve private keys
19:33:21 <gwillen> the "update" step only ever occurs separately in unusual cases I think
19:33:28 <luke-jr> sipa: I'm thinking the script itself is part of the private key
19:33:29 <jb55> oh that's probably why I could never get rawtx to psbt conversion to work, I probably needed to call utxoupdatepsbt?
19:33:43 <instagibbs> that conversion is sketchy :)
19:33:44 <sipa> luke-jr: it should not be considered that way
19:33:57 <sipa> luke-jr: as security should not ever depend on keeping scripts private
19:34:26 <luke-jr> hmm
19:34:29 <sipa> (it may matter for privacy to keep them secret, but that's a much more complicated issue to solve if desired)
19:34:45 <gwillen> given that PSBT is pretty dependent on the current workflow, I think the workflow is maybe outside the scope of my specific change
19:34:46 <achow101> if you want privacy of scripts and derivations paths, psbt ain't it
19:34:54 <gwillen> but might be worth having a discussion about it at some point
19:34:55 <luke-jr> I guess the scripts are strictly less a concern than derivation paths
19:35:41 <jeremyrubin> sipa: it's sometimes possible to compress a HTLC in a taproot branch I think
19:36:28 <achow101> jeremyrubin: taproot will have it's own set of fields that hopefully better preserve privacy
19:36:38 <jb55> should the ui give a privacy warning when copying psbts to clipboard/saving when there's derivation paths included?
19:36:41 <instagibbs> you'll still need additional roles/flows imo
19:36:56 <sipa> jb55: imho, no - it's generally not actionable
19:36:58 <instagibbs> better to me to actually define common flows, and design for those, rather than just guessing
19:37:12 <sipa> jb55: you have the choice between private and broken, and non-private and functional
19:37:28 <gwillen> I think in general PSBTs are also never intended to be published, they are intended to be shared only with required signers
19:37:32 <instagibbs> hww<->host<->curious co-signer, things like that
19:37:38 <gwillen> I suspect this really mutes a lot of the privacy issues that could otherwise exist
19:37:43 <instagibbs> but there's no RPC flow for this
19:37:44 <gwillen> for most people the required signers will only ever be themselves
19:37:51 <achow101> gwillen: the main privacy concern is for coinjoins
19:37:52 <gwillen> or people they already trust with their privacy
19:37:55 <gwillen> *nod*
19:38:09 <gwillen> I have not thought a lot about the coinjoin case
19:38:27 <bitcoin-git> [13bitcoin] 15fanquake opened pull request #17738: build: remove linking librt for backwards compatibility (06master...06remove_librt_back_compat) 02https://github.com/bitcoin/bitcoin/pull/17738
19:38:33 <instagibbs> depends on what co-signers require to sign, there can be additional proof data etc
19:38:44 <achow101> in coinjoins you don't know or trust the other participants. deriv path and scripts could provide an easy way for a coinjoin participant to deanonymize other coinjoin participatns
19:38:48 <sipa> yeah, the (interesting) privacy issues appear when you're combinging multi-party signing for some inputs, and distinct signers for other inputs
19:39:18 <sipa> there could be some best effort where we remove bip32 derivation info from finalized inputs
19:39:36 <gwillen> we may already do that
19:39:45 <achow101> pretty sure we do
19:39:46 <gwillen> I know that we strip partial signatures from finalized inputs once we combine them
19:40:01 <achow101> I think the spec for finalizer says drop everything but final sig/witness and utxo
19:40:02 <sipa> oh, ok
19:40:12 <sipa> achow101: i vaguely remember that indeed
19:40:37 <instagibbs> oh that's not too bad then for most uses already
19:41:03 <achow101> I think the workflow we should be going for is really the hardware wallet/cold storage one
19:41:17 <jb55> I still wish there was some hrp that I could glance at the various states a psbt is in, but I guess that ship has sailed
19:41:20 <instagibbs> well that one can be very naive
19:42:41 <gwillen> jb55: can you expand "hrp"
19:42:55 <achow101> human readable aprt
19:42:57 <achow101> *part
19:43:01 <gwillen> there is the analyzepsbt rpc which produces what you want, I think
19:43:04 <sipa> the stage depends on the input...
19:43:16 <gwillen> and my goal is for my UI to also expose as much of that as makes sense
19:43:37 <jb55> yeah perhaps thats just difficulties arising from copying and pasting psbts and the cli, but ui could help a lot here
19:43:42 <gwillen> I don't think it would make sense to put an hrp in the PSBT itself, you could attack people by having it be secretly out of sync with the rest
19:43:48 <instagibbs> jb55, different signers may expect different input, so it's kind of hard to say. e.g., one may expect xpub for multisig detection, other may not
19:46:31 <jeremyrubin> Anything else on this topic?
19:46:40 <gwillen> I think further comments on my proposal can go on the issue
19:46:48 <wumpus> #topic RPC Whitelist Feature (jeremyrubin)
19:47:02 <jeremyrubin> I think this is more or less ready to merge
19:47:22 <emilengler> The test (#17536) is also rebased on the squashed commit
19:47:23 <jeremyrubin> It adds the ability to whitelist certain RPCs for credentials for those unfamiliar
19:47:24 <gribble> https://github.com/bitcoin/bitcoin/issues/17536 | test: Add test for rpc_whitelist by emilengler · Pull Request #17536 · bitcoin/bitcoin · GitHub
19:48:26 <instagibbs> could you snipe the test? :) if that's ok emilengler
19:48:53 <emilengler> instagibbs: What do you mean?
19:48:57 <jeremyrubin> snipe meaning put onto the same branch? I could, I just didn't want to unfairly steal emilengler's merge stats ;)
19:49:13 <emilengler> jeremyrubin: It's fine
19:49:14 <instagibbs> emilengler, can jeremy cherry-pick into his branch? I don't like features without tests :)
19:49:21 <jeremyrubin> big credit to emilengler for putting in the effort to get the tests over the line
19:49:22 <emilengler> sure
19:49:34 <wumpus> just make sure to keep the author data the same
19:49:46 <instagibbs> +1
19:49:46 <emilengler> Would be nice if you colud put me into the longer commit description
19:50:20 <jeremyrubin> will do
19:50:28 <instagibbs> will review
19:50:30 <emilengler> thanks :)
19:50:34 <luke-jr> do it without an @ or he'll get spammed by altcoins
19:50:39 <emilengler> Will close the PR then
19:50:49 <luke-jr> (usually just maintaining the Author field is enough?)
19:51:24 <jonatack> will review
19:52:39 <instagibbs> 8 minutes, any other topics?
19:52:41 <wumpus> thanks everyone, I don't think we have any more topics so that concludes the meeting
19:52:44 <instagibbs> kk
19:52:49 <wumpus> #endmeeting