19:00:27 <wumpus> #startmeeting
19:00:27 <lightningbot> Meeting started Thu Oct 15 19:00:27 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:27 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:28 <provoostenator> hi
19:00:32 <emzy> hi
19:00:37 <hebasto> hi
19:00:39 <jnewbery> hi
19:00:49 <luke-jr> hi
19:00:54 <kanzure> hi
19:01:05 <promag> hi
19:01:10 <wumpus> two proposed topics taproot relay policy / activation on testnet/signet (sipa),  Getting BIP 8 logic in before freeze (luke-jr)
19:01:26 <luke-jr> wumpus: there was a third by jeremyrubin O.o
19:01:33 <luke-jr> [18:42:09] <jeremyrubin> #proposedmeetingtopic small announcement on behalf of BGIN
19:01:33 <jonatack> hi
19:02:03 <elichai2> hi
19:02:06 <wumpus> PSA today is the feature freeze for 0.21, it seems we managed to merge all the features on the milestone
19:02:12 <wumpus> luke-jr: strange, didn't see it in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:02:18 <luke-jr> wumpus: thought it was tomorrow? :x
19:02:20 <provoostenator> Note that the GUI repo doesn't have a milestone
19:02:43 <MarcoFalke> provoostenator: Right. Is there any feature we missed from the GUI?
19:02:52 <MarcoFalke> bugfixes can go in any time
19:02:57 <luke-jr> [16:22:11] <hebasto> provoostenator: https://github.com/bitcoin-core/gui/pull/96
19:02:59 <wumpus> there are some PRs left of course, but nothing that can be labeled feature imo https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
19:03:19 <wumpus> provoostenator: good point, didn't look at the gui repo at all
19:03:24 <luke-jr> wumpus: would be nice to get some of BIP 8 in, so there's less backported with activation
19:03:24 <MarcoFalke> We still have 14 days to find and fix all bugs
19:04:01 <luke-jr> but I'll save that for the dedicated topic
19:04:08 <wumpus> luke-jr: well 10-15 is today here https://github.com/bitcoin/bitcoin/issues/18947 , but does it matter, everything tagged as feature was merged
19:04:26 <wumpus> (except for the GUI one apparently, if it's ready for merge it should go in)
19:04:38 <luke-jr> wumpus: doesn't mean much when only a few people can edit tags :/
19:05:00 <wumpus> luke-jr: the idea is that things get proposed for the milestone in meetings, or in the channel at least
19:05:08 <dongcarl> hi
19:05:30 <luke-jr> oh well, BIP 8 isn't strictly feature anyway
19:05:33 <fjahr_> hi
19:06:01 <wumpus> #topic Pending bugfixes for 0.21
19:06:47 <wumpus> any bugfixes that we should get in for the release missing on the milestone?
19:07:14 <jonatack> i'd propose 20120, 20115, 19961, and maybe 19874
19:07:15 <luke-jr> I found #20157,  not sure how important it is
19:07:16 <gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
19:07:37 <sipa> luke-jr: should definitely be fixed before release
19:07:42 <sipa> #20120
19:07:44 <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
19:07:45 <luke-jr> > #20120, #20115, #19961, and maybe #19874
19:07:45 <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
19:07:46 <jonatack> plus the upcoming fix for #19543
19:07:47 <gribble> https://github.com/bitcoin/bitcoin/issues/20115 | cli: -netinfo quick updates/fixups and release note by jonatack · Pull Request #20115 · bitcoin/bitcoin · GitHub
19:07:49 <gribble> https://github.com/bitcoin/bitcoin/issues/19961 | doc: tor.md updates by jonatack · Pull Request #19961 · bitcoin/bitcoin · GitHub
19:07:50 <gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
19:07:51 <gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
19:08:09 <hebasto> #20080 or #19933
19:08:11 <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
19:08:14 <gribble> https://github.com/bitcoin/bitcoin/issues/19933 | wallet: bugfix; if datadir has a trailing / listwalletdir would strip lead char of walletname by Saibato · Pull Request #19933 · bitcoin/bitcoin · GitHub
19:08:41 <luke-jr> oh yes, one of those are important to get in ☺
19:08:51 <wumpus> jonatack: i'm not convinced  #19874 is really a bugfix
19:08:53 <gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
19:09:17 <luke-jr> afaik -getinfo has never worked with old servers gracefully
19:09:21 <ariard> hi
19:09:23 <jonatack> agree that it's optional. the doc/tor.md is still in draft but will open v soon
19:09:47 <sipa> i think documentation improvements can be done after feature freeze
19:09:58 <MarcoFalke> tests and docs can go in any time
19:10:07 <jonatack> sipa: agree, i held off on those to get the features in
19:11:31 <provoostenator> #18788 would be good tests to add
19:11:34 <gribble> https://github.com/bitcoin/bitcoin/issues/18788 | tests: Update more tests to work with descriptor wallets by achow101 · Pull Request #18788 · bitcoin/bitcoin · GitHub
19:11:56 <wumpus> 19543 was already tagged
19:12:18 <luke-jr> oh, did achow101 want to make descriptor wallets tied to sqlite? where does that stand?
19:12:28 <luke-jr> #20156 is IMO a bugfix
19:12:30 <gribble> https://github.com/bitcoin/bitcoin/issues/20156 | Make sqlite support optional (compile-time) by luke-jr · Pull Request #20156 · bitcoin/bitcoin · GitHub
19:12:37 <provoostenator> luke-jr: that's already merged
19:12:40 <wumpus> yes, that was his plan, to make it clearer that those are two different wallet formats
19:12:57 <meshcollider> Please can we decide which of 19933 and 20080 we want to keep and which one to close?
19:13:03 <luke-jr> provoostenator: tying the two together is?
19:13:07 <wumpus> luke-jr: i think 'return a null in a field' is graceful enough, it just shouldn't crash
19:13:09 <MarcoFalke> I like #20080
19:13:11 <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
19:13:20 <provoostenator> luke-jr: descriptor == sqlite for new wallet yes
19:13:25 <provoostenator> see my comment as well
19:13:33 <promag> +1 #20080
19:13:35 <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
19:13:42 <provoostenator> Unless achow101 changed his mind about that, but I think that was the point of getting it in before release
19:13:44 <wumpus> 20080 was already tagged right
19:13:46 <MarcoFalke> I promise to test 20080 soon
19:13:51 <wumpus> please don't repeat things
19:13:56 <luke-jr> wumpus: 'return a null in a field' ?
19:14:16 <wumpus> I'm having a lot of trouble keeping track of PRs mentioned here to add them to the milestone
19:14:21 <luke-jr> oh, for -getinfo; sure; or just an error even
19:14:25 <wumpus> luke-jr: yes
19:14:37 <meshcollider> Alright 20080 it is, I'll close 19933
19:15:09 <wumpus> meshcollider: yes makes sense
19:16:14 <wumpus> I think I've tagged everything mentioned, if not, please let me know
19:16:57 <promag> wumpus: maybe #20125
19:16:59 <gribble> https://github.com/bitcoin/bitcoin/issues/20125 | rpc, wallet: Expose database format in getwalletinfo by promag · Pull Request #20125 · bitcoin/bitcoin · GitHub
19:17:26 <luke-jr> 20080 should get 0.19.x and 0.20.x tags too I think
19:17:30 <wumpus> promag: sounds like a feature to me
19:17:49 <MarcoFalke> luke-jr: It already has
19:17:55 <wumpus> (though maybe a necessary one, I don't' know)
19:17:57 <luke-jr> o
19:17:58 <bitcoin-git> [13bitcoin] 15meshcollider closed pull request #19933: wallet: bugfix; if datadir has a trailing '/'  listwalletdir would strip lead char of walletname (06master...06wallet-fix-missing-chars-boost-1.47) 02https://github.com/bitcoin/bitcoin/pull/19933
19:18:14 <jonatack> agree with promag about 20125
19:18:18 <wumpus> luke-jr: let's discuss the 0.21 milestone now not other ones
19:19:09 <wumpus> ok adding 20125...
19:19:14 <promag> wumpus: not really... just adds "format" key to the rpc response
19:19:28 <wumpus> well it's not a bugfix at least
19:19:36 <wumpus> but I don't care it seems minimal enough
19:19:52 <promag> wumpus: right
19:20:43 <wumpus> that concludes the topic I guess
19:20:53 <luke-jr> I'm not sure it makes sense to expose that detail, but meh
19:21:06 <wumpus> #topic taproot relay policy / activation on testnet/signet (sipa)
19:21:18 <sipa> hi
19:21:31 <wumpus> luke-jr: especially if it's linked to descriptor wallets it seems a bit redundant, but yeah...
19:21:32 <promag> luke-jr: could still be rejected ;)
19:21:41 <sipa> there are a few aspects here
19:21:50 <wumpus> if it's useful for troubleshooting/diagnosis it should be in
19:22:12 <sipa> one is relay of v1 transaction outputs; bitcoin core will do that since #15846
19:22:15 <gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
19:22:54 <sipa> but since the merge of #19953, we'll also relay spends of (valid) taproot outputs
19:22:57 <gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
19:23:09 <sipa> i think that's undesirable, at least until activation is defined, or even until actually activated
19:23:44 * luke-jr did suggest splitting that out of the PR a few months ago :P
19:24:07 <sipa> luke-jr: well, we do want it on regtest
19:24:24 <luke-jr> regtest supports acceptnonstdtxn, but ok
19:26:03 <sipa> talking to sdaftuar a bit, i think we should just reject creation and spending of v1 outputs until taproot is _active_
19:26:17 <sipa> as a policy rule (not through script validation, which is more invasive)
19:27:16 <sipa> or at least creation as soon as an activation is defined
19:27:36 <sipa> (so that the behavior on mainnet before an activation is defined is essentially as if it didn't exist at all)
19:28:06 <sipa> i can open a PR/issue and discuss further there
19:28:30 <sipa> but i wanted to bring this up, as it may be unexpected that master is now doing taproot validation on the mempool
19:28:43 <wumpus> I think that makes sense, to do that as a policy rule
19:28:59 <MarcoFalke> so the spends would be valid taproot spends (with witness) only?
19:29:28 <sipa> so right now: all v1 creation is relayed, v1 spends are relayed only if valid according to taproot rules
19:29:52 <ariard> is there any disadvantage of doing this?
19:30:20 <sipa> my proposal: v1 creation is not relayed while taproot activation is defined but not yet active; v1 spending is only relayed after being actually active
19:30:40 <provoostenator> Why not always relay?
19:31:02 <MarcoFalke> provoostenator: Someone will give away their coins, surely
19:31:03 <provoostenator> Doesn't seem ideal to have a bunch of nodes out there not relaying v1 transactions.
19:31:23 <sipa> provoostenator: they'd all start relaying as soon as activation happens
19:31:31 <sipa> before that point, we don't care
19:32:03 <ariard> sipa: so you want to hardcode the loosening policy change based on the consensus activation IIRC ?
19:32:07 <luke-jr> well, activation isn't in 0.21.0, so not these
19:32:38 <sipa> luke-jr: indeed, the only effect on 0.21.0 would be making spending of v1 non relayed
19:32:50 <jnewbery> sipa: what's the difference between 'not relayed while taproot activation is defined but not yet active' and 'only relayed after being actually active'
19:33:31 <provoostenator> Did we relay v1 to/from transactions before taproot was merged?
19:33:37 <sipa> jnewbery: creation would be relayed as long as no activation parameters are set (the idea being that without activation parameters, it should be treated as an unknown future upgrade that can still change)
19:33:41 <aj> jnewbery: 0.21.0 will be not-defined and not-active, so will always relay creation of taproot outputs, but not spends of them
19:34:16 <sipa> maybe this is a simpler principle: before activation is _defined_, behavior should be identical to before taproot was merged
19:34:21 <aj> sipa: i'm not sure it makes much sense to make it harder to spend a taproot output than to create one? creating one before activation is how you lose money?
19:34:43 <jeremyrubin> aj: i thought we checked outputs standardness?
19:35:02 <jnewbery> sipa aj: thanks
19:35:10 <aj> jeremyrubin: 15846
19:35:12 <luke-jr> aj: the spend we make harder, may be a theft
19:35:20 <luke-jr> you can't steal if you can't spend
19:35:22 <jeremyrubin> #15846
19:35:24 <gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
19:35:41 <aj> luke-jr: prior to activation miners can spend trivially
19:35:58 <luke-jr> aj: miners don't rely on others' policy
19:36:11 <sipa> aj: my suggestion is that relay of creation and spending only differs before activation is defined... to match pre-taproot-implemented behavior
19:36:27 <sipa> after activation is defined, both are disallowed until it is actually active
19:37:45 <luke-jr> (OT: wumpus: #19502 should probably get milestoned)
19:37:47 <gribble> https://github.com/bitcoin/bitcoin/issues/19502 | Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks by luke-jr · Pull Request #19502 · bitcoin/bitcoin · GitHub
19:37:51 <sipa> aj: which is ultimately due to softfork safeness... if we treat taproot as subject to change still (which i think we should until activation is defined), we shouldn't permit spending it to be relayed
19:38:09 <wumpus> luke-jr: ok
19:38:24 <jeremyrubin> has that been reverted though somehow?
19:38:33 <sipa> jeremyrubin: what?
19:38:42 <jeremyrubin> looking at the current code and I'm not seeing that logic still
19:38:46 <aj> sipa: right, immediately after activation (supported by 0.21.1 say), you have all nodes relaying creation, but only 0.21.1 nodes relaying spends. vs having 0.21.0 and 0.21.1 nodes validating and relaying spends if we leave things as they are now
19:39:36 <jeremyrubin> Ah
19:39:39 <jeremyrubin> it went into Solver
19:40:35 <sipa> aj: i think permitting spends right now is bad... it's just gratuitous policy difference between 0.21 and pre-0.21 nodes
19:40:54 <sipa> the extra rule for suspending relay of outputs is user protection before activation
19:41:07 <sipa> anyway, will open an issue
19:41:08 <aj> sipa: the principle (no behaviour change prior to activation) makes sense, just doesn't seem like it has much benefit (people still lose money if they create outputs earlier, because miners will claim them via a non-std tx) and slight costs (will make relay slightly harder due to implementation-but-no-activation nodes not relaying)
19:41:21 <wumpus> 20 minutes left, we might want to move to the next topic
19:41:30 <sipa> aj: if their own node rejects relay, miners will never see the tx :)
19:41:46 <luke-jr> sipa: no reason their own node would :P
19:41:53 <wumpus> #topic  Getting BIP 8 logic in before freeze (luke-jr)
19:42:03 <luke-jr> I've implemented the current BIP 8 as logic only (no activations) in #19573. This is probably not the final BIP 8 (aj's been working on some revisions), but having it merged in 0.21 means we can have a smaller diff to add Taproot activation later.
19:42:04 <gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
19:42:06 <luke-jr> Would be nice to get this merged before 0.21.0rc1 if possible. Anyone who wants to help review (or other) can join ##taproot-activation to help get this done quickly.
19:42:09 <luke-jr> Note the PR depends on #19401 and #20157. These are fairly trivial, and the former already has 2 ACKs.
19:42:11 <gribble> https://github.com/bitcoin/bitcoin/issues/19401 | QA: Use GBT to get block versions correct by luke-jr · Pull Request #19401 · bitcoin/bitcoin · GitHub
19:42:12 <gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
19:45:03 <wumpus> i don't know, it does feel a bit rushed to me, to merge something (that should be a no-op otherwise) last minute just to minimize the diff later, especially when we don't even know yet if it's the final state of the BIP
19:45:13 <wumpus> not a small project either
19:45:48 <luke-jr> hmm, true
19:46:01 <sipa> no strong opinion... it doesn't seem very invasive, but on the other hand, this can also easily be backported along with actual activation parameters
19:46:18 <sipa> it also may turn out to be wasted effort
19:47:13 <luke-jr> not sure how it could be wasted effort
19:47:29 <luke-jr> sipa: your topic, you had mentioned signet/testnet activation - that might or might not be a reason to do this sooner
19:47:38 <jeremyrubin> i think it makes sense to wait for cleaner git history
19:48:03 <luke-jr> jeremyrubin: I'm assuming the two trivial PRs would be merged first as part of this process
19:48:20 <sipa> oh right, i didn't bring that up... do we want to define an activation on testnet?
19:48:36 <sipa> that's something that was done historically, but with signet i think there may be less need now
19:48:40 <luke-jr> I think it makes sense to test BIP 8 with testnet
19:49:30 <wumpus> it should activate there at some time i guess
19:50:18 <sipa> always possible in .1 or whatever point release too, of course
19:50:19 <aj> probably shouldn't activate on testnet with a different activation method than we plan on using for mainnet?
19:50:32 <luke-jr> sipa: true
19:51:04 <luke-jr> maybe that's a good solution: testnet in .1, and mainnet not until .2
19:51:05 <sipa> it'd be nice to see things active on signet first before suggesting testnet changes
19:51:05 <wumpus> sipa: right
19:51:20 <aj> kallewoof's not awake, but i was thinking maybe lock taproot as it stands in immediately on the default signet, and if worst comes to worst just restart the signet chain if needed
19:51:20 <sipa> (as in signet it can be rolled out without code changes...)
19:52:00 <wumpus> that's great
19:52:12 <luke-jr> signet doesn't even need an activation, does it?
19:52:15 <luke-jr> just always-active?
19:52:16 <MarcoFalke> wait, if spends are made non-standard, it needs conde changes for signet
19:52:21 <aj> sipa: (not-relaying taproot-txs if activation hasn't happened will affect the "without code changes" part a bit
19:52:43 <aj> luke-jr: yeah, that's what i'm thinking
19:52:55 <aj> luke-jr: (i mean, "always-active" is an activation)
19:53:02 <luke-jr> the policy changes sipa suggested are conditional on the deployment state AFAIK?
19:53:21 <MarcoFalke> so I guess s/without/minimal/
19:53:25 <aj> luke-jr: right, but *nodes* have to know the deployment state in that case, not just miners
19:53:31 <luke-jr> so always-active would trigger the spending policy
19:53:50 <sipa> i think we can flesh these things out the next few days
19:53:55 <aj> yep
19:54:04 <luke-jr> yeah, let's give jeremyrubin some minutes ☺
19:54:18 <jeremyrubin> i need like 1 min
19:54:27 <jeremyrubin> so no rush
19:54:47 <wumpus> #topic Small announcement on behalf of BGIN (jeremyrubin)
19:55:00 <jeremyrubin> Matsuo has asked me to share the following
19:55:02 <jeremyrubin> FYI bgin-global.org is hosting an event for core devs the first week of Nov, please fill out this form https://forms.gle/99yUnQdtAkAwt5SW7 to assist scheduling or email schwentker@bsafe.network with any questions. Goal of the event is to help core dev sustainability, so should be of interest for all here.
19:55:12 <jeremyrubin> https://bgin-global.org
19:55:20 <luke-jr> during a pandemic? O.o
19:55:29 <achow101> Who's bgin?
19:55:33 <jeremyrubin> it's a virtual event
19:55:36 <luke-jr> i c
19:55:56 <luke-jr> "Blockchain Governance Initiative Network "
19:55:58 <jeremyrubin> BGIN is "Blockchain Governance Initiative Network (BGIN)"
19:56:05 <jeremyrubin> I'd ignore the acronym tho
19:56:11 <luke-jr> so this is like NY agreement in organization form? :x
19:56:20 <jeremyrubin> no
19:56:40 <aj> there's also coinbase looking to support bitcoin dev projects as of an hour or so ago https://twitter.com/coinbase/status/1316801517983334401
19:56:42 <jeremyrubin> it's the sort of name that you have to have to get intl participation from people in intl financial regulation
19:56:53 <luke-jr> jeremyrubin: lol
19:56:56 <jeremyrubin> so it's started by Matsuo and others
19:57:31 <jeremyrubin> the point being that a lot of various regulators want to chat about how Bitcoin works and how they engage, but also understanding how standards emerge
19:57:57 <jeremyrubin> But a part of that is they want to understand and potentiall support development through research grants
19:58:32 <wumpus> that sounds pretty scary tbh
19:58:36 <jeremyrubin> so it's maybe folk you'd rather not talk to at all depending on your preferences, but it is a good faith effort afaict
19:58:57 <jeremyrubin> :shrug:
19:59:15 <jeremyrubin> I'd encourage you to email concerns to schwentker@bsafe.network
20:00:05 <luke-jr> jeremyrubin: it sounds like they're just giving webinars and we'd simply watch it? O.o
20:00:14 <jeremyrubin> no i don't think so
20:00:26 <jeremyrubin> I think they want to hear from you directly
20:00:41 <MarcoFalke> end meeting?
20:00:44 <wumpus> ok, I think everything is said, thanks for the announcement
20:00:46 <wumpus> #endmeeting