19:03:12 #startmeeting 19:03:12 Meeting started Thu Aug 27 19:03:12 2020 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:14 hi 19:03:14 lekker 19:03:19 hi 19:03:26 hallo 19:03:28 hi 19:03:31 hi 19:03:32 hi 19:03:33 hi 19:03:34 hi 19:03:38 hi 19:03:44 hai 19:04:02 * MarcoFalke waiting for the mass-ping 19:04:08 Am I right that the only proposed topics are form MarcoFalke? (0.19 minor release / signet)? 19:04:17 jonasschnelli: correct 19:04:41 #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:04:43 amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2 19:05:13 #topic High priority for review 19:05:24 is there anything you want to add or remove or replace? 19:05:37 https://github.com/bitcoin/bitcoin/projects/8 19:05:42 add #19717 :) 19:05:44 https://github.com/bitcoin/bitcoin/issues/19717 | rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump) by MarcoFalke · Pull Request #19717 · bitcoin/bitcoin · GitHub 19:06:15 MarcoFalke: replace #19629? 19:06:20 https://github.com/bitcoin/bitcoin/issues/19629 | refactor: Keep mempool interface in validation by MarcoFalke · Pull Request #19629 · bitcoin/bitcoin · GitHub 19:06:23 jup, removed the other 19:07:12 done 19:07:30 thx 19:07:52 currently 10 blockers, 3 chasing concept ACK (same as last week) 19:08:42 #topic Status of 0.19 minor release (MarcoFalke) 19:09:23 Well, we should probably wrap that up and ship? 19:09:27 https://github.com/bitcoin/bitcoin/milestone/46 19:09:51 sounds good to me, I had no idea that was ready? 19:09:58 though, there is still some tagged for backport: https://github.com/bitcoin/bitcoin/issues?q=label%3A%22Needs+backport+%280.19%29%22 19:10:36 #19681 looks ready for merge 19:10:38 https://github.com/bitcoin/bitcoin/issues/19681 | 0.19: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19681 · bitcoin/bitcoin · GitHub 19:11:24 agree 19:12:03 so does #18284? 19:12:04 https://github.com/bitcoin/bitcoin/issues/18284 | [0.19] scheduler: Workaround negative nsecs bug in boosts wait_until by luke-jr · Pull Request #18284 · bitcoin/bitcoin · GitHub 19:12:42 18284 isn't a backport, though 19:13:02 if we want to have the http race also fixed in 0.19.2, we should mark #19033 0.19.2,... otherwise move 18856 19:13:05 https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub 19:13:07 it's labeled 0.19.2 and targetted for 0.19 thugh 19:13:44 The bug is not a regression in 0.19, so I am not sure if we *need* to fix it 19:14:11 and it doesn't happen on servers 19:14:30 why didn't you never comment that on the PR? 19:14:43 it has only ACKs now 19:14:56 so it looks ready to go at least 19:14:57 ok, will leave a comment now 19:15:40 it's fine with me to not do it at all, but if no one comments that in months that's not very clear to the author 19:15:42 it should only happen if you're mocking the time right? 19:16:22 #19033 is ready for merge IMO.. a backport to 0.19.2 should be easy to fix 18856 19:16:24 https://github.com/bitcoin/bitcoin/issues/19033 | http: Release work queue after event base finish by promag · Pull Request #19033 · bitcoin/bitcoin · GitHub 19:17:05 jeremyrubin: No only if you hibernate/suspend 19:17:35 Can I have #19806 added? 19:17:36 probably fine to fix then 19:17:38 https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub 19:17:47 jamesob: added to 0.19 backport? 19:17:55 high prio 19:17:57 the code change itself looked ok to me 19:17:58 jeremyrubin: sure. Adding... 19:18:14 Oops, we're still on highprio right? 19:18:21 it's always possible to argue it's not *worth* fixing, but I think it's kind of strange if there is already a patch 19:18:45 if it can happen with hiberbate/suspend that seems like a legit issue? 19:18:47 jamesob: no. 0.19.2 (but it's fine) 19:19:00 wumpus: Jup, the code change looks fine obviously. Though, it is also boost. A previous version of the patch forgot to catch and re-throw boost::thread_interrupted 19:19:55 I'd rather have a known bug that is well understood than an newly introduced intermittent unknown bug 19:19:57 is there any urgency to do another 0.19 release at all? 19:20:12 reject filtering? 19:20:24 wumpus: Not really. Not sure how urgent the reject filtering needs to go out 19:20:25 that was the main motivator iirc? 19:20:42 i don't think that's urgent 19:22:29 not urgent enough to rush and skip other fixes at least 19:22:30 Anything to add to 0.19.2? (MarcoFalke) 19:23:05 Not really. Everything should be tagged already. 19:23:37 #topic Status of signet implementation in Bitcoin Core (MarcoFalke) 19:24:18 Pretty much a short topic. I only wanted to ask if anyone plans to ACK/NACK/review it. 19:24:28 i played around with the impl yesterday. It's pretty good but currently lacking the contrib tools 19:24:31 From my view it seems close to ready 19:24:40 It was hard for me to fully test it without the contrib tooling 19:25:10 jeremyrubin: I'd say Bitcoin Core is the wrong place to add contrib tools for the signet maintainers. 19:25:21 They can have their own repo 19:25:28 MarcoFalke: disagree -- we should be able to produce blocks for signet 19:25:32 we have a maintainer tools repo just add it there 19:25:42 I don't care where the tools are 19:25:51 https://github.com/bitcoin-core/bitcoin-maintainer-tools 19:25:53 But I care that I can't test a signet that I created 19:26:01 i'm not sure it's really a maintainer tool 19:26:03 I agree they should be public 19:26:24 I'm saying that it's a bit of a merge precondition. I would ACK if I could finish testing it 19:26:33 it's pretty much free for all for anything maintainers need, no need to put signet tools anywhere else 19:26:42 the expectations may be unclear, but i hope that over time various private signets get spun up - it could even replace regtest over time 19:26:52 Can't test jeremyrubin? What can't you test exactly? 19:27:10 Well I made my own signet script and network 19:27:10 michaelfolkson: Mining blocks 19:27:15 And i cannot produce blocks 19:27:25 So I can't test peering it and seeing that it works 19:27:32 doesn't mean it needs to be in the repo right now, but i don't think it'd be unreasonable to have the scripts for working/spining up a signet in the main repo 19:28:13 https://en.bitcoin.it/wiki/Signet 19:28:18 at some point 19:28:40 no big objection either, but I would say that there need to be tests for them if you'd put them in the main repo, there's already too many quasi-unmaintained tools 19:28:54 agree 19:28:55 Yeah I'm hazy about what should be in Core, what is covered by Core but I'm sure it will become clearer to me over time 19:29:18 Yeah the tools could be somewhere, I'm just commenting that I can't finish testing and ACK without having block producing scripts. 19:29:18 wumpus: yes, let's not merge things that are untested and then go broken without anyone noticing 19:29:23 in any case that doesn't seem necessary for the PR that is open now 19:29:38 If they get added to the repo, I hope they are not written in bash at least *hides 19:29:41 wumpus: one cannot tested ACK the current code 19:29:49 jeremyrubin: i don't think that's a blocker for signet itself - the tools are available, right? 19:29:53 just not in the PR 19:29:58 I don't think so AFAIK 19:30:04 wait, the tools are not available *at all*? 19:30:12 okay, that seems like a blocker 19:30:21 I think they are quasi available 19:30:30 why not just ask kallewoof for them 19:30:31 In that they exist against a prior version of Signet 19:30:32 I guess kallewoof is asleep 19:30:36 signet is certainly the PR i've spent the most time doing re-reviews of these past 6 months. it would be nice to begin reviewing follow-ups instead of the whole thing every time. 19:30:42 I think they're still finishing them 19:31:04 And it's fine if we want follow up work to add the full tools 19:31:12 Is it a blocker? There will be future Signet related PRs 19:31:14 but if people are wondering why I haven't ACKd it 19:31:18 in any case, in including the tools in bitcoin core's repo (+tests) should imo not be a requirement for this PR 19:31:27 (which is more or less the current topic) 19:31:29 but they need to be available somewhere 19:31:29 that's why 19:31:36 jeremyrubin: seems very reasonable 19:31:42 wumpus: +1, I'm happy with them being anywhere 19:32:29 aren't the tools here: https://github.com/kallewoof/bitcoin/commit/50c839e1d91348408b40b3f8a53e0ef1a7f6da72 19:32:58 jonasschnelli: There was a previous version that signed the block, not transactions 19:33:10 I'd bet the current one would be easier to write from scratch 19:33:14 i think it would be good if the signet consensus PR included a trivial python based functional test... even if it's a super simple one with just OP_TRUE as script or so 19:33:32 yes 19:33:59 i don't see any actual testing apart from a fuzz test? 19:34:20 sipa: I was planning to write some tests as a follow-up 19:34:38 There is this too for setting up your own Signet https://github.com/kallewoof/signet-platform 19:34:47 sipa, could have all tests run with --signet, and it handles it in background using generate* aliased? :) 19:35:09 s/all/some/ 19:35:11 re-running every test seems like overkill 19:35:14 right 19:35:15 instagibbs: They'd run for years with that POW 19:35:24 yeah, i just want to make sure the signet code is exercised in tests 19:35:30 that does not seem to be the case in the current PR 19:35:31 MarcoFalke, sigregtest ... right 19:35:59 heh, regtest should already mimic mainnet in most params 19:36:05 michaelfolkson: those tools don't seem to be current 19:36:32 Jup, anything that was written before august is outdated 19:36:37 aj and kallewoof have the current block keys, for final might be worth having keys in EU/US for timezone arbitrage 19:36:57 Volunteering? :) 19:37:15 I'm moving their timezone, probably, so no 19:37:15 lol 19:37:32 voluntelling achow to run a node 19:37:37 ack 19:37:59 instagibbs: nack 19:38:14 I think we shouldn't try to offer signet as any sort of "use the main one thing" 19:38:22 let a thousand ships sail ;) 19:38:45 Disagree. But I will post on the mailing list and you can disagree with me there 19:38:51 ok 19:39:52 instagibbs: what am I being voluntold to do? 19:40:11 also note that for signet there's not ~that much value in the current multisig setup 19:40:15 it's 1 of N 19:40:18 Third signer on Signet blocks being mined. Congrats achow101 19:40:24 there's no M of N cordination 19:40:37 so you can literally do a 1 of 1 and send anyone the key 19:40:44 jeremyrubin, right it's less crucial but "hey bump your server" 19:41:03 well, then it becomes 1 of 1 over time, anyways, not a huge deal 19:41:39 chaincode should run a signet node then 19:41:45 I'd presume it is 1 of 2 to protect against power outages 19:41:48 it's current 1 of 2, which has no security improvement over 1 of 1 where two people know the 1 19:41:59 it's not security 19:42:00 it's outages 19:42:03 hence timezone comment 19:42:06 not nation :) 19:42:07 it has no outages improvement 19:42:49 i think you guys are talking past each other 19:42:50 unless I'm missing something where you want to know which node created the block 19:42:58 It does. If one signer is down blocks can still be mined using sigs from the other signer 19:43:05 yeah, i think the only difference is accountability 19:43:07 "why not" but also "I've stopped caring" :) 19:43:08 not sure that matters 19:43:20 so I'll concede i appear to care less and relent 19:43:33 Yeah I'm not sure how to make my point more clear but I'll cede the balance of my time (too much CSPAN) 19:43:59 you could softfork out on of the keys(haha) 19:44:22 (100% not serious) 19:44:27 * jeremyrubin groans 19:45:17 1 of 2 also gives debugability. (You'll see which miner didn't produce blocks) 19:45:34 you already get that with coinbase message if you want 19:45:38 MarcoFalke: yeah, that's commonly called accountability 19:46:32 there's maybe an edge on debuggable v.s. provably accountable if the miner-id is a unverified message 19:47:27 i think this is getting off topic 19:47:32 any other last minute topics? 19:47:41 so, signet is near-mergeable, just needs a sanity check functional test? 19:47:45 jonasschnelli: About 0.19.2 backports -- not a bugfix per se but perhaps #19455. It accompanies the cli -generate addition, which was in 0.19. 19:47:48 https://github.com/bitcoin/bitcoin/issues/19455 | rpc generate: print useful help and error message by jonatack · Pull Request #19455 · bitcoin/bitcoin · GitHub 19:48:10 re 18284 I don't get why we would intentionally *not* merge a bugfix 19:48:30 luke-jr: Because of the risk that it introduces new bugs 19:48:32 jonatack: 19455 is not really a bugfix? 19:48:32 it's one thing if people don't give it reviews needed, but once it has review, it doesn't make sense to leave it out 19:48:46 jonatack: I think one should be able to stand up a net and generate blocks, which might be a subset of that functional test. That's my watermark for tested ACK 19:48:51 I don't think it's particularly risky 19:49:08 jonasschnelli: it explains to people that run the former RPC generate that it is now CLI -generate instead 19:49:16 then again I ACKed it 19:50:02 jonatack: I'd say no need to backport this... but no strong opinion. 19:50:21 because several tutorials online still mention rpc generate and it might be confusing for them. Yep, no worry, just mentioning. 19:50:41 Yeah, I see it has two ACKs 19:51:12 jonatack: Yes. That is a good point. 19:51:36 jonatack: I doubt meany people following tutorials will use a new 0.19.x 19:51:56 yeah,.. that 19:51:58 not opposed to backporting it, but, these kind of backport releases tend to be used for old software on servers 19:52:14 if used at all 19:52:33 well, some end users intentionally hold back on major updates too; but still unlikely they'd be using the old version for something like this 19:52:42 right 19:52:58 they're definitely downloaded looking at torrent seed server stats etc 19:53:06 wumpus: good to know 19:55:02 #endmeeting