19:00:21 <wumpus> #startmeeting
19:00:21 <lightningbot> Meeting started Thu Oct  1 19:00:21 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:21 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:22 <promag> meeting?
19:00:23 <jnewbery> hi
19:00:27 <promag> oh, hi
19:00:28 <hebasto> hi
19:00:38 <amiti> hi
19:00:41 <aj> hi
19:00:44 <achow101> hi
19:00:47 <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
19:00:49 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
19:00:54 <ariard> hi
19:00:58 <provoostenator> hi
19:01:05 <meshcollider> hi
19:01:07 <dongcarl> hi
19:01:30 <sipa> hi
19:01:38 <luke-jr> hi
19:01:45 <jonatack> kon'nichiwa
19:01:53 <wumpus> one proposed topic for today:  merging PR 19953 (taproot) (jnewbery)
19:02:45 <wumpus> any last minute suggestions?
19:03:23 <kanzure> hi
19:03:47 <wumpus> jonatack: こんにちは
19:03:59 <wumpus> #topic High priority for review
19:04:39 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  12 blockers, 1 bugfix, 2 chasing concept ACK
19:04:48 <promag> please remove mine from hp, it doesn't help getting more reviews
19:05:05 <wumpus> ok
19:05:49 <wumpus> yes, anything concerning libevent initialization/shutdown is notoriously hard to review
19:06:31 <promag> basically it will wait for you ^^
19:07:02 <wumpus> well the PR seemed really tricky to me... I think what we need is a clear test, and then to test with different versions of libevent
19:07:33 <wumpus> I can't judge just from the code change wether it's better or not
19:07:39 <promag> ok, then I guess I need to make it clear and improve testing!
19:09:18 <wumpus> it's kind of awkward we've had a history of PRs like that, and it never really fixed the problem, we'll really want to make sure we get it right this time or it doesn't make sense to make another change there
19:09:20 <wumpus> thanks!
19:10:10 <wumpus> anything else for high prio?
19:10:28 <sipa> #19953 ? :)
19:10:31 <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:10:47 <sipa> oh, it is
19:10:57 <wumpus> hehe
19:11:30 <wumpus> that's also the other topic
19:12:07 <wumpus> #topic Merging PR 19953 (taproot) (jnewbery)
19:12:21 <jnewbery> Hi!
19:12:27 <jnewbery> Apologies if eveyone else is already on the same page on this and I'm just not keeping up.
19:12:32 <jnewbery> What are people's hopes for when the Taproot PR gets merged?
19:12:35 <jnewbery> Feature freeze is in a couple of weeks, and it seems optimistic to get it merged before then.
19:12:43 <jnewbery> But if we want it included in v0.21.1, I think it makes sense to be merged very soon after the v0.21 branch, to make back-porting easier.
19:12:51 <jnewbery> So in my mind, it's the priority as soon as v0.21 gets branched, and before any big refactors (eg switching things to C++17) go in.
19:12:57 <jnewbery> Is that what other people are thinking too?
19:13:04 <jnewbery> (I'm personally prioritizing #19988 ahead of it for my reviews, because I think it'd be good to get that in 0.21)
19:13:07 <gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
19:13:11 <luke-jr> jnewbery: before the branch?
19:13:22 <luke-jr> after the branch is too late, isn't it?
19:13:27 <sipa> i was hoping before the branch, but it's obviously not up to me
19:13:34 <sipa> i do think the PR is essentially done
19:13:48 <wumpus> yep, FWIW today was the translations freeze, feature freeze is in 14 days: https://github.com/bitcoin/bitcoin/issues/18947
19:14:02 <aj> i thought before the branch was still plausible; also prioritising 19988, but i think it's just about there
19:14:13 <promag> no backport after branch off right?
19:14:32 <luke-jr> promag: softforks should always be backported to anything supported
19:14:45 <luke-jr> not necessarily until activation is set tho
19:14:47 <wumpus> yes, softforks are always backported
19:15:15 <wumpus> but it would be good to get that in before the branch-off if it's ready anyway
19:15:36 <jnewbery> it currently has two ACKs (instagibbs and benthecarmen). Feels like now would be the time to review if anyone was waiting for the right moment!
19:15:41 <ariard> sounds good to prioritize 19988, I had the same PR order
19:15:52 <jonatack> agree. i was thinking the same as aj and sipa WRT these two PRs, 19953 and 19988
19:16:19 <jonatack> (along with the tor v3 support)
19:16:29 <sipa> it seems silly to say "merge right after branch", if it's ready to merge at that point, it's also ready to merge before
19:16:44 <achow101> i'll move it to the top of my review queue
19:17:13 <wumpus> sipa: right, 'merge after branch' is for features that shouldn't be backported
19:17:30 <sipa> or for very invasive refactors perhaps
19:17:35 <wumpus> yes
19:17:49 <sipa> of course, if it isn't ready before, it isn't, and that should be that
19:18:01 <jnewbery> sipa: I meant "if it's not ready to merge at branch, then it should be a priority to get it reviewed/merged as soon as possible", not "don't merge it before the branch even if it's ready"
19:18:10 <sipa> jnewbery: right, that makes sense
19:19:10 <sipa> in any case, the outstanding things i have for 19953 at this point are a few review comments (which will just result in added code comments for clarification), and documenting the process of creating the JSON unit test data
19:19:28 <sipa> https://github.com/bitcoin-core/qa-assets/pull/27 FWIW
19:19:32 <wumpus> so just documentation work
19:19:49 <ariard> I still want to review in-depth the test coverage, but that said 14 days is largely enough
19:19:51 <wumpus> which is important but doesn't hold up the code merge
19:19:53 <sipa> and obviously addressing any review comments that may still arise
19:20:38 <jnewbery> I guess maybe the message should be: feature freeze is in two weeks, think about what your priorities are. Mine are 19988 and 19953.
19:21:05 <sipa> i'm committed to quickly addressing comments in both of those
19:21:09 <sipa> my other priority is torv3
19:21:29 <luke-jr> IMO #11082 is important to get into 0.21, but clearly I can't do it alone :/
19:21:33 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
19:21:40 <aj> wumpus: oh, i guess #19937 for high-pri might be nice
19:21:42 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
19:21:55 <wumpus> mine are, beside taproot, #19991 and #19954
19:21:58 <gribble> https://github.com/bitcoin/bitcoin/issues/19991 | net: Use alternative port for incoming Tor connections by hebasto · Pull Request #19991 · bitcoin/bitcoin · GitHub
19:22:02 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
19:22:31 <sipa> luke-jr: i haven't seen any argument as for what it adds over settings.json, so barring a wide agreement to revert that (and there doesn't seem to be), it seems hard to get people to find it important
19:23:02 <luke-jr> sipa: it potentially reduces us to 1 config format, whereas settings.json bumped us to 3 or 4
19:23:12 <wumpus> aj: added
19:23:25 <wumpus> sipa: I agree, that's why I haven't really looked at it either
19:23:54 <wumpus> I don'twant yet another config file, initialization and setting priority is complex enough as it is
19:24:06 <sipa> luke-jr: but settings.json is merged; you'll need a much stronger case if your goal is reverting that and merging bitcoin_rw instead
19:24:15 <luke-jr> wumpus: that's the point behind rwconf - it reduces
19:24:15 <sipa> as having both seems the worst of both worlds
19:24:23 <luke-jr> sipa: that's why it's important to do before 0.21
19:24:29 <luke-jr> once 0.21 is released, we're stuck with settings.json
19:24:49 <sipa> luke-jr: but your goal isn't just merging bitcoin_rw; it's replacing a feature that was already merged
19:24:59 <sipa> i have no opinion either way, but one is merged, and the other isn't
19:25:08 <wumpus> it's an internal settings file, people are not supposed to edit it manually, might be better if it's in json format instead
19:25:33 <wumpus> could have been some obscure binary format as well but as least this is readible if you want to...
19:25:40 <jnewbery> luke-jr: you failed to convince people that bitcoin_rw was the right approach in the PRs. I don't see what simply repeating your position here will achieve
19:26:56 <wumpus> any other topics?
19:27:02 <achow101> at what point do we switch to the milestone for hi prio?
19:27:50 <wumpus> achow101: well not yet as I've not really looked at what is at the milestone yet
19:28:06 <wumpus> but yes good point
19:30:04 <wumpus> we could do that starting from next week, after sorting things out, I think we need to postpone things like "sqlite wallet storage" to 0.22  https://github.com/bitcoin/bitcoin/milestone/45
19:30:14 <achow101> :(
19:30:17 <wumpus> as well as the guix build
19:30:22 <wumpus> yes, :(
19:30:55 <sipa> i'm sorry i haven't had the time to dive into that... i'd really like to see sqlite happen
19:30:58 <luke-jr> "the guix build"?
19:31:04 <wumpus> but that sounds scary to do last minute at least to me, seems like something that needs to brew in the master branch for a while
19:31:39 * dongcarl awakens
19:31:41 <wumpus> luke-jr: yes, 0.21 will be another release built with gitian it seems?
19:31:52 <luke-jr> wumpus: hopefully gitian won't be abandoned any time soon
19:32:01 <luke-jr> guix is an improvement over Ubuntu, but not over gitian
19:32:14 <achow101> the main thing was that I had wanted to couple sqlite with descriptor wallets just to avoid multiple upgrade scenarios
19:33:08 <sipa> achow101: i get that, but does that add that much? you'll still need to support legacy+bdb, legacy+sqlite, desc+sqlite anyway
19:33:11 <wumpus> achow101: yes, I understand … but it seems too recent to have as default yet
19:33:16 <luke-jr> Guix requires running third-party blobs to use (or at least, I couldn't get it running - and if I can't, how could we expect others to?)
19:33:41 <achow101> sipa: the idea was there wasn't a legacy+sqlite
19:33:53 <wumpus> luke-jr: my point was, that's a concern for 0.22 not 0.21
19:33:55 <luke-jr> k
19:34:40 <sipa> achow101: in the short term perhaps, but longer term i'd hope you can convert a legacy bdb wallet to sqlite so we could (in due time) have a reasonable build without bdb dependency
19:34:49 <wumpus> ^^
19:34:52 <sipa> while converting legacy to descriptor seems much harder/impossible
19:35:13 <achow101> converting legacy to descriptor seems possible
19:35:26 <wumpus> there needs to be a way to upgrade old wallets
19:35:32 <wumpus> if not, we'll be stuck with them forever
19:35:33 <achow101> #19602 does it
19:35:35 <gribble> https://github.com/bitcoin/bitcoin/issues/19602 | wallet: Migrate legacy wallets to descriptor wallets by achow101 · Pull Request #19602 · bitcoin/bitcoin · GitHub
19:36:07 <achow101> my plan was for the legacy -> desc upgrade is the bdb -> sqlite upgrade too
19:36:26 <luke-jr> we *could* disable descriptor wallets in 0.21, but I don't think anyone wants to go there..
19:36:33 <sipa> luke-jr: yeah, no
19:37:04 <wumpus> you can't really require people to transfer their funds to a new wallet to upgrade, ever
19:37:06 <sipa> achow101: i see, right, if you require a new backup at the same time, it does seem reasonaBLE
19:37:56 <wumpus> requiring a new backup is fine
19:38:06 <wumpus> just be clear about it
19:38:21 <achow101> wumpus: no funds transfer is required for the upgrade
19:39:11 <wumpus> achow101: good, that's the only hope we can get rid of berkeleydb at some point :)
19:39:20 <dongcarl> luke-jr: We can talk more about guix on #bitcoin-builds, would very much like to know the problems you ran into
19:40:40 <luke-jr> dongcarl: k, after the meeting
19:40:43 <wumpus> (which I fully support, FWIW, though we'll want to be careful to somehow have some tools somewhere that people can use to convert old bdb wallets they find)
19:41:49 <wumpus> it highlights how important backwards compatibility is for our wallet formats anway
19:42:07 <wumpus> any other topics?
19:42:20 <sipa> 42 is a good minute to end at
19:42:43 <wumpus> #endmeeting