19:00:21 #startmeeting 19:00:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:22 meeting? 19:00:23 hi 19:00:27 oh, hi 19:00:28 hi 19:00:38 hi 19:00:41 hi 19:00:44 hi 19:00:47 #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 amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2 19:00:54 hi 19:00:58 hi 19:01:05 hi 19:01:07 hi 19:01:30 hi 19:01:38 hi 19:01:45 kon'nichiwa 19:01:53 one proposed topic for today: merging PR 19953 (taproot) (jnewbery) 19:02:45 any last minute suggestions? 19:03:23 hi 19:03:47 jonatack: こんにちは 19:03:59 #topic High priority for review 19:04:39 https://github.com/bitcoin/bitcoin/projects/8 12 blockers, 1 bugfix, 2 chasing concept ACK 19:04:48 please remove mine from hp, it doesn't help getting more reviews 19:05:05 ok 19:05:49 yes, anything concerning libevent initialization/shutdown is notoriously hard to review 19:06:31 basically it will wait for you ^^ 19:07:02 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 I can't judge just from the code change wether it's better or not 19:07:39 ok, then I guess I need to make it clear and improve testing! 19:09:18 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 thanks! 19:10:10 anything else for high prio? 19:10:28 #19953 ? :) 19:10:31 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 oh, it is 19:10:57 hehe 19:11:30 that's also the other topic 19:12:07 #topic Merging PR 19953 (taproot) (jnewbery) 19:12:21 Hi! 19:12:27 Apologies if eveyone else is already on the same page on this and I'm just not keeping up. 19:12:32 What are people's hopes for when the Taproot PR gets merged? 19:12:35 Feature freeze is in a couple of weeks, and it seems optimistic to get it merged before then. 19:12:43 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 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 Is that what other people are thinking too? 19:13:04 (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 https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub 19:13:11 jnewbery: before the branch? 19:13:22 after the branch is too late, isn't it? 19:13:27 i was hoping before the branch, but it's obviously not up to me 19:13:34 i do think the PR is essentially done 19:13:48 yep, FWIW today was the translations freeze, feature freeze is in 14 days: https://github.com/bitcoin/bitcoin/issues/18947 19:14:02 i thought before the branch was still plausible; also prioritising 19988, but i think it's just about there 19:14:13 no backport after branch off right? 19:14:32 promag: softforks should always be backported to anything supported 19:14:45 not necessarily until activation is set tho 19:14:47 yes, softforks are always backported 19:15:15 but it would be good to get that in before the branch-off if it's ready anyway 19:15:36 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 sounds good to prioritize 19988, I had the same PR order 19:15:52 agree. i was thinking the same as aj and sipa WRT these two PRs, 19953 and 19988 19:16:19 (along with the tor v3 support) 19:16:29 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 i'll move it to the top of my review queue 19:17:13 sipa: right, 'merge after branch' is for features that shouldn't be backported 19:17:30 or for very invasive refactors perhaps 19:17:35 yes 19:17:49 of course, if it isn't ready before, it isn't, and that should be that 19:18:01 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 jnewbery: right, that makes sense 19:19:10 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 https://github.com/bitcoin-core/qa-assets/pull/27 FWIW 19:19:32 so just documentation work 19:19:49 I still want to review in-depth the test coverage, but that said 14 days is largely enough 19:19:51 which is important but doesn't hold up the code merge 19:19:53 and obviously addressing any review comments that may still arise 19:20:38 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 i'm committed to quickly addressing comments in both of those 19:21:09 my other priority is torv3 19:21:29 IMO #11082 is important to get into 0.21, but clearly I can't do it alone :/ 19:21:33 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 wumpus: oh, i guess #19937 for high-pri might be nice 19:21:42 https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub 19:21:55 mine are, beside taproot, #19991 and #19954 19:21:58 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 https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub 19:22:31 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 sipa: it potentially reduces us to 1 config format, whereas settings.json bumped us to 3 or 4 19:23:12 aj: added 19:23:25 sipa: I agree, that's why I haven't really looked at it either 19:23:54 I don'twant yet another config file, initialization and setting priority is complex enough as it is 19:24:06 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 wumpus: that's the point behind rwconf - it reduces 19:24:15 as having both seems the worst of both worlds 19:24:23 sipa: that's why it's important to do before 0.21 19:24:29 once 0.21 is released, we're stuck with settings.json 19:24:49 luke-jr: but your goal isn't just merging bitcoin_rw; it's replacing a feature that was already merged 19:24:59 i have no opinion either way, but one is merged, and the other isn't 19:25:08 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 could have been some obscure binary format as well but as least this is readible if you want to... 19:25:40 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 any other topics? 19:27:02 at what point do we switch to the milestone for hi prio? 19:27:50 achow101: well not yet as I've not really looked at what is at the milestone yet 19:28:06 but yes good point 19:30:04 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 :( 19:30:17 as well as the guix build 19:30:22 yes, :( 19:30:55 i'm sorry i haven't had the time to dive into that... i'd really like to see sqlite happen 19:30:58 "the guix build"? 19:31:04 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 luke-jr: yes, 0.21 will be another release built with gitian it seems? 19:31:52 wumpus: hopefully gitian won't be abandoned any time soon 19:32:01 guix is an improvement over Ubuntu, but not over gitian 19:32:14 the main thing was that I had wanted to couple sqlite with descriptor wallets just to avoid multiple upgrade scenarios 19:33:08 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 achow101: yes, I understand … but it seems too recent to have as default yet 19:33:16 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 sipa: the idea was there wasn't a legacy+sqlite 19:33:53 luke-jr: my point was, that's a concern for 0.22 not 0.21 19:33:55 k 19:34:40 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 ^^ 19:34:52 while converting legacy to descriptor seems much harder/impossible 19:35:13 converting legacy to descriptor seems possible 19:35:26 there needs to be a way to upgrade old wallets 19:35:32 if not, we'll be stuck with them forever 19:35:33 #19602 does it 19:35:35 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 my plan was for the legacy -> desc upgrade is the bdb -> sqlite upgrade too 19:36:26 we *could* disable descriptor wallets in 0.21, but I don't think anyone wants to go there.. 19:36:33 luke-jr: yeah, no 19:37:04 you can't really require people to transfer their funds to a new wallet to upgrade, ever 19:37:06 achow101: i see, right, if you require a new backup at the same time, it does seem reasonaBLE 19:37:56 requiring a new backup is fine 19:38:06 just be clear about it 19:38:21 wumpus: no funds transfer is required for the upgrade 19:39:11 achow101: good, that's the only hope we can get rid of berkeleydb at some point :) 19:39:20 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 dongcarl: k, after the meeting 19:40:43 (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 it highlights how important backwards compatibility is for our wallet formats anway 19:42:07 any other topics? 19:42:20 42 is a good minute to end at 19:42:43 #endmeeting