19:00:25 <wumpus> #startmeeting
19:00:25 <lightningbot> Meeting started Thu Apr 11 19:00:25 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:25 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:07 <wumpus> #topic 0.18.0
19:01:16 <wumpus> so it turns out we need another rc
19:01:29 <kanzure> hi
19:02:07 <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
19:02:21 <wumpus> (for #15776)
19:02:23 <gribble> https://github.com/bitcoin/bitcoin/issues/15776 | Expire inflight GETDATA requests by ajtowns · Pull Request #15776 · bitcoin/bitcoin · GitHub
19:02:31 <meshcollider> hi
19:02:35 <jonasschnelli> hi
19:02:39 <achow101> hi
19:02:42 <jamesob> hi
19:02:48 <cfields_> hi
19:02:49 <wumpus> the schedule was to tag final today, but we're not going to make that then I guess
19:02:51 <luke-jr> hi
19:02:54 <wumpus> let's at least tag a new rc?
19:02:57 <meshcollider> In that case, I think we should also backport #15749 ?
19:02:59 <gribble> https://github.com/bitcoin/bitcoin/issues/15749 | Fix: importmulti only imports origin info for PKH outputs by sipa · Pull Request #15749 · bitcoin/bitcoin · GitHub
19:03:10 <MarcoFalke> wumpus: nothging changed since rc3?
19:03:21 <sipa> 15776 is not yet merged
19:03:25 <wumpus> MarcoFalke: after 15776 ofc
19:03:33 <MarcoFalke> oh
19:03:57 <MarcoFalke> Doesn't look like it was reviewed
19:04:00 <wumpus> meshcollider: yea if all kinds of other bugs were found since, makes sense to include them
19:04:09 <wumpus> ok
19:04:40 <wumpus> well, 0.18.0 will be delayed a bit that's clear at least
19:04:46 <luke-jr> no big deal imo
19:05:14 <jonasschnelli> yes. acceptable
19:06:09 <wumpus> no, it doesn't really matter, though I think review should focus on those PRs then
19:06:14 <sipa> agree
19:07:41 <wumpus> added #15749 to needs backport to 0.18.0
19:07:43 <gribble> https://github.com/bitcoin/bitcoin/issues/15749 | Fix: importmulti only imports origin info for PKH outputs by sipa · Pull Request #15749 · bitcoin/bitcoin · GitHub
19:08:17 <meshcollider> thanks
19:08:34 <wumpus> #topic Bitcoin CRust (cfields_)
19:09:10 <jnewbery> I'd request that #15750 gets considered for inclusion in the next rc. It completes a fix that is already in 0.18
19:09:11 <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
19:09:31 <jeremyrubin> Hi! Also present
19:10:12 <instagibbs> hi
19:10:21 <luke-jr> jnewbery: that looks like removal of an API, not a fix; I don't really care though
19:10:35 <luke-jr> better to remove in 0.18.0 than 0.18.1
19:10:43 <cfields_> ah, sorry, irc went weird for me.
19:10:55 <cfields_> See #15798, lots of useful info there. tl;dr: This is a cool project from Jeremy Rubin that allows us to use rust code from inside of Bitcoin Core. No plan yet, I mostly just wanted to spread the word that people should try it out and report back. It pretty much just works. It is surprisingly complete, but has only been tested in a few environments so far.
19:10:57 <gribble> https://github.com/bitcoin/bitcoin/issues/15798 | RFC: Rust code integration by theuni · Pull Request #15798 · bitcoin/bitcoin · GitHub
19:11:13 <wumpus> jnewbery: looks like it's somewhat controversial, any reason to not do this for 0.19 instead?
19:11:15 <luke-jr> anyway, CRust.. I don't think including Rust inside Bitcoin Core is a good idea, even optionally, so long as Rust requires trusting third party binaries
19:11:18 <MarcoFalke> jnewbery: There shouldn't be any cost to only remove it in 0.19.0
19:11:19 <jonasschnelli> Nice work jnewbery and cfields_!
19:11:36 <jonasschnelli> luke-jr: it's an experiment AFAIK
19:11:37 <kanzure> which third party library is that
19:11:38 <wumpus> I really like the rust work
19:11:43 <jnewbery> Because the deprecation warning in the RPC help text is removed in 0.18
19:11:51 <luke-jr> jonasschnelli: experiments can be done outside Core
19:11:58 <cfields_> luke-jr: there are people working on that. This is experimental. This discussion is not helpful at this time.
19:11:59 <kanzure> you mean the rust binary?
19:12:01 <wumpus> jnewbery: wha-why ?
19:12:05 <luke-jr> kanzure: yes, rustc
19:12:05 <jonasschnelli> luke-jr: read the PR desc
19:12:09 <MarcoFalke> luke-jr: Bitcoin is experimental
19:12:10 <cfields_> luke-jr: it says right there. NOT FOR MERGE.
19:12:16 <cfields_> caps and everything :)
19:12:20 <jeremyrubin> luke-jr: did you see Marco's bootstrapping link as well?
19:12:33 <wumpus> it's an experiment, but it's good to have people aware of it
19:12:46 <cfields_> anyway, I'd like to get some feedback from people who have actually used rust.
19:12:56 <instagibbs> you'd want to ping #rust-bitcoin folks
19:13:01 <dongcarl> Hi
19:13:03 <luke-jr> jeremyrubin: as I understand it, mrustc only works on x86
19:13:05 <wumpus> dongcarl: ^^
19:13:07 <jamesob> rust is a pleasure to write - beyond that I don't have much input
19:13:16 <jonasschnelli> I don't disagree with luke-jr concerns,.. but an experiments needs to start somewhere and Rust will evolve over time
19:13:42 <kanzure> don't we also use other compilers in deterministic builds..?
19:13:45 <jeremyrubin> luke-jr: can you not cross compile after bootstrap? Do you want to bootstrap on every platform?
19:13:50 <MarcoFalke> Yeah, it is good to see that the build system changes are smaller than anyone expected
19:13:59 <jeremyrubin> Anyways, as noted, this is just for enabling more experimentation
19:14:06 <cfields_> luke-jr's complaint has been heard. Let's move on please.
19:14:23 <gmaxwell> yeah, its not a for merge thing. Useful announcement.
19:14:29 <luke-jr> kanzure: hopefully we are moving away from that
19:14:45 <dongcarl> perhaps a good question is what parts of the code is memory safety the most critical
19:15:18 <wumpus> anything that interfaces to the hostile outside world (e.g. P2P code)
19:15:19 <gmaxwell> It would only be interesting to merge if there were some functionality written in rust that we wanted to include. It was surprising to me that it took as much as CRust in order to do that. (it isn't like we need anything special in the build system to link code written in C, for example)
19:15:21 <MarcoFalke> The parts that are not going to be rewritten in rust any time soon ;)
19:15:24 <cfields_> dongcarl: yes. also, what things are in-spec in rust that can only be undefined in c/c++.
19:15:25 <MarcoFalke> dongcarl: ^
19:15:28 <instagibbs> MarcoFalke, hah!
19:16:22 <jamesob> a while back BlueMatt had talked about doing a secondary fallback network stack in rust which would activate if the existing p2p code started acting weird
19:16:29 <jamesob> but that's obviously pretty speculative...
19:16:49 <wumpus> that's a pretty neat idea
19:16:58 <sipa> i don't understand the appeal of that idea
19:17:09 <sipa> the complexity is all in the interaction between network code and the rest
19:17:11 <meshcollider> I remember him bringing that up in tokyo
19:17:13 <jamesob> two is one and one is none, I guess
19:17:15 <luke-jr> gmaxwell: well, part of the concern is that people are more likely to write stuff others want in Rust than C++, with this; but maybe not a big deal if Rust is making good progress
19:17:15 <sipa> not in the network code itself
19:17:44 <luke-jr> jamesob: sounds more complex to detect "weird" than to just replace it
19:18:01 <jamesob> luke-jr: could be
19:18:09 <cfields_> sipa: I would think something like a rust-libevent would be pretty appealing. But yeah, that's a layer below us.
19:18:09 <wumpus> it's not so much about the complexity I think, but potential safety issues, rust would be safer for the network code
19:18:14 <luke-jr> if someone is compromising the original network stack, they can probably corrupt the alternate one too
19:18:44 <sipa> wumpus: in a way that we've actually ever had problems?
19:18:54 <cfields_> It's also worth considering that new tools could be written in rust. Doesn't have to be direct bitcoind integration.
19:19:09 <luke-jr> rewrite the node around libconsensus? ;)
19:19:10 <gmaxwell> IIRC. We have never had a bug in the network code that use of rust would have structurally prevented, we have however had many bugs of the same kind that occure in rust. see e.g. the somewhat recent parity (ethereum node software) network wide crasher vuln from memory exhaustion (I think ultimately stemming from livelocks)
19:19:22 <wumpus> sipa: that we haven't noticed any problems doesn't mean that they don't exist, but sure...
19:19:31 <sipa> iirc all scares we've had in the past were about unbounded data structures, processing interactions, buggy logic, ... not out of bounds issues or the sort
19:19:40 <wumpus> a lot of this is to rule out entire bug classes, not just to fix bugs that we've found
19:19:58 <sipa> wumpus: while introducing a complexity in making the two layers communicate
19:20:04 <wumpus> so in a sense it's speculative
19:20:06 <MarcoFalke> Doesn't rust fix uninitizlized reads? #14728
19:20:08 <gribble> https://github.com/bitcoin/bitcoin/issues/14728 | fix uninitialized read when stringifying an addrLocal by kazcw · Pull Request #14728 · bitcoin/bitcoin · GitHub
19:20:16 <dongcarl> Perhaps another useful property: Safe Rust guarantees an absence of data races.
19:20:17 <MarcoFalke> #6636
19:20:18 <gribble> https://github.com/bitcoin/bitcoin/issues/6636 | net: correctly initialize nMinPingUsecTime by laanwj · Pull Request #6636 · bitcoin/bitcoin · GitHub
19:20:24 <gmaxwell> at a cost of radically reducing the set of people who can review things, and more complexity from interfaces looking different on each side, however.
19:20:25 <wumpus> rust fixes undefined behavior at least,we've had plenty of that reported
19:20:25 <jeremyrubin> I think fixing some of the internal concurrent workers would be a good task
19:20:33 <jeremyrubin> E.g., the CheckQueue or Task QUeue
19:20:37 <sipa> my view is that if and when there is an actual project with useful code we'd like to introduce as a dependency, that happens to be written in rust, of course
19:20:41 <cfields_> gmaxwell: for now.
19:20:43 <jeremyrubin> As that can just be treated as a scheduler
19:20:44 <gmaxwell> Put it this way, however: I would much rather be linking a upnp library written in rust.
19:21:02 <sipa> but i have no interest in seeing bitcoin core becoming developed in a mix of languages
19:21:06 <jamesob> sipa: +1
19:21:12 <meshcollider> Agreed
19:21:26 * cfields_ banishes sipa from the testing framework :p
19:21:38 <wumpus> it'd be somewhat confusing, though I'd personally be happy to move away from c++, I've really grown to dislike it
19:21:46 <gmaxwell> testing framework being written in another language has a non-trivial cost. (not that I'd suggest otherwise!)
19:21:51 <cfields_> (That was a joke, I realize it's not the same thing)
19:22:05 <jamesob> cfields_: I'm working on a c++ rewrite as we speak
19:22:08 <sipa> wumpus: i realize that; but bitcoin core is a c++ project with c++ reviewers
19:22:20 <wumpus> sipa: yes, maybe it means I need to move to rust-bitcoin :-)
19:22:49 <cfields_> sipa: i think that's a fair point. But nearly every one of those reviewers that I've poked has mentioned that they'd like to learn rust.
19:22:51 <wumpus> anyhow, this is an experiment, I don't think merging it is even a question right now
19:22:58 <MarcoFalke> A lot of the reviewers know rust or wouldn't have a problem learning it
19:23:17 <gmaxwell> It appears to me that language proliferation is doing a lot of harm to open source communties.... lots of duplication of effort and half abandoned projects just because someone wanted to do the same thing over in another language. :(
19:23:21 <sipa> cfields_: sure, i'd like to learn rust; but i'm not going to be an expert in it even when i do to the extent that i'd feel like reviewing production ready code
19:23:29 <cfields_> wumpus: right. So the question for now is how to get eyes on it and keep it up to date. I guess we can just maintain it in a branch somewhere?
19:23:37 <wumpus> cfields_: yes
19:23:38 <meshcollider> Review quality would definitely go down if people are new to the language
19:23:42 <luke-jr> gmaxwell: if only everything used the same ABI
19:23:43 <cfields_> sipa: very fair point.
19:23:43 <jeremyrubin> Expertise in rust is easier to attain than c++
19:23:55 <jeremyrubin> The compiler catches most of the stuff you spend time revieiwing in c++ anyways
19:24:01 <wumpus> cfields_: as said I'm happy to maintain that branch
19:24:39 <gmaxwell> I am skeptical also about this motivation about structurally elimiating bugs, when development in bitcoin core continues to _introduce_ bug in the form of things like memory-unbounded asynchronous layers.
19:24:40 <cfields_> wumpus: ok, great, you're welcome to take it over.
19:25:08 <wumpus> gmaxwell: concurrent programming should be more straightforward in rust at least
19:25:39 <gmaxwell> wumpus: somewhat, but the problems we have like invisible queues that grow unboundedly exist exactly the same in rust.
19:25:41 <wumpus> a lot of the boilerplate we're introducing in bitcoin for queues, asyn handling,et c is simply part of rust already
19:26:05 <wumpus> gmaxwell: yes, no one is claiming it would eliminate all problems automatically, that would have been great
19:26:16 <gmaxwell> It's a lot easier to avoid writing data races, however, indeed
19:26:52 <gmaxwell> wumpus: not all problems, of course... but the problems we actually end up shipping.
19:26:54 <wumpus> right
19:27:29 <wumpus> I really don't know, like if you and sipa are 100% against including rust in bitcoin core, it's a done deal I guess
19:27:50 <sipa> i'm not; but it's a discussion to be had when there is code to include
19:27:54 <wumpus> yes
19:28:01 <gmaxwell> As I said before, I'd be much happier with a rust miniupnp than miniupnp.
19:28:04 <jonasschnelli> Let it be an experiment
19:28:09 <wumpus> so let's start with miniupnp
19:28:14 <gmaxwell> So certantly not 100% against it.
19:28:22 <jeremyrubin> I think the point of this PR is that if someone wanted to start exploring, they would have to spend a week just setting up building and linking
19:28:26 <wumpus> happy to write that in rust :)
19:28:37 <dongcarl> I can get boostrap working
19:28:40 <sipa> i'd be even happier with a minimal c++ reimplementation of miniupnp :p
19:28:51 <sipa> (but i have no problem with a rust one if it would exist)
19:29:07 <wumpus> you really want to make another c++ upnp implementation?
19:29:10 <sipa> and it's great that the build system issues are already out of the way
19:29:14 <jeremyrubin> So now that we have the demo build, someone can more easily show us motivation
19:29:33 <jeremyrubin> It's also good to know that rust work won't be shot down purely on the "another language" basis
19:29:36 <gmaxwell> I dunno, I think I'd rather a rust one,  ignoring the build related issues (like rust notes, the blind binary trust in rust toolchains, etc)
19:29:54 <wumpus> I'd not be inclined to trust that tbh, even if we wrote it ourselves, we're not perfect either it's not like we'd avoid all the problems in the original one automatically
19:30:10 <gmaxwell> jeremyrubin: has the proble of the rust ecosystem where cargo effectively forces you into getting nearly blind updates been resolved?
19:30:19 <sipa> i think we have a pretty good track record wrt the kind of bugs that miniupnp has
19:30:29 <wumpus> you mean, xml parsing?
19:30:35 <sipa> memory safety
19:30:48 <wumpus> nah
19:31:00 <gmaxwell> jeremyrubin: my expirence at blockstream was that it was very costly to not blindly take new software via cargo... because, yes you can ping versions, but then compiler updates would break deep dependencies, and you'd have to move forward your pins... and often move all of them at once because of interactions.
19:31:24 <gmaxwell> s/ping/pin/
19:31:28 <jeremyrubin> gmaxwell: I'm not sure? Crates.io is supposed to be append only
19:31:31 <sipa> wumpus: how so?
19:31:49 <jeremyrubin> gmaxwell: cargo also just added the ability to have your own crate registry, which would help
19:31:57 <wumpus> sipa: just having a good track record doesn't guarantee anything
19:32:01 <sipa> wumpus: of course
19:32:09 <jeremyrubin> gmaxwell: in the PR, I manually pinned the one dep (a build tool to auto-gen headers)
19:32:12 <wumpus> it doesn't mean you can do arbitrarily complex things and avoid bugs
19:32:13 <gmaxwell> jeremyrubin: append only doesn't help if it doesn't build anymore with new compilers.  (to be fair C++ also has this issue but on a 10x slower timescale)
19:32:39 <jeremyrubin> gmaxwell: I think what grin does is not update the compiler -- just fix the version to a known stable or nightly
19:33:12 <luke-jr> is it even possible to have multiple versions of Rustc installed on most distros?
19:33:14 <gmaxwell> jeremyrubin: yes, thats what we ended up doing at blockstream...  but then that runs into issues when you want to add something else and it depends on a new compiler.
19:33:15 <jeremyrubin> gmaxwell: updating to a new compiler can be annoying for anything
19:33:25 <jeremyrubin> luke-jr: yes look at the rustup toolchain manager
19:33:26 <gmaxwell> luke-jr: the tooling makes it possible to do that, yes.
19:33:39 <sipa> wumpus: to be clear, i say i'd prefer a c++ miniupnp because i'd be able to look at it; not because of innate qualities of the language
19:33:42 <wumpus> I'm just very skeptical of things like 'if we implemented it it'd be better', I'm sure the author of miniupnp thought the same, he also wanted to make a minimal upnp implementation
19:33:52 <jeremyrubin> gmaxwell: yeah -- it's a pity rust is adding so many exciting new features ;)
19:34:02 <wumpus> it's pretty much outside all our expertise
19:34:17 <sipa> but the whole question is pointless without an actual package to discuss
19:34:22 <wumpus> yes
19:35:02 <wumpus> (this is besides the rust issue btw)
19:35:10 <cfields> Sorry, was laggy, had to switch servers.
19:35:11 <gmaxwell> So there are essentially two infrastructure issues for using rust stuff for non-optional functionality: (1) bootstraping needing blobs, and (2)  ecosystem very strongly pressuring everyone to take blind software updates (ala JS train wreak).
19:35:53 <wumpus> I think using it for non-optional functionality is a bad idea right now
19:37:04 <wumpus> agree on gmaxwell's comments re: cargo
19:37:05 <cfields> gmaxwell: #1 is unfair and not worth discussing imo unless people are going to scream about us using ubuntu's toolchain as well.
19:37:07 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
19:37:12 <gmaxwell> for something like a miniupnp, the main argument against using rust is that we might get fewer reviewers (but might get more rust fad-followers to review? so maybe thats a tie),  the main argument I see for it, is that would be nice that there is a class of bugs that miniupnp had many of structurally prevented by the langauge.
19:37:43 <luke-jr> cfields: people who build their own bitcoind *don't* need to use Ubuntu's toolchain
19:37:44 <gmaxwell> cfields: we do use a toolchain that can be bit identically produced by many hetrogenious toolchains.
19:38:15 <jeremyrubin> gmaxwell: for 2, there are a lot of things that could be done w/o external deps
19:38:19 <luke-jr> gmaxwell: UPnP might be generic enough that non-Bitcoin devs are interested too
19:38:28 <gmaxwell> cfields: in particular we use a gcc binary that I can produce starting from clang.  (and I've independanty produced the compiler on my laptop from a disjoint toolchain)
19:38:36 <gmaxwell> luke-jr: exactly.
19:39:02 * dongcarl agrees, but needs help
19:39:03 <gmaxwell> It's exactly the sort of thing likely to get somewhat broad interest, thats part of why I used it as a positive example.
19:39:11 <cfields> Grr, I swore I wasn't going to take the bait on this :p
19:39:28 <wumpus> apparently there are already some projects to implement upnp in rust
19:39:30 <gmaxwell> cfields: I yield, I don't really need to argue this with you right now.
19:39:39 <wumpus> in any case -- let's move to other topics, this isn't so urgent now
19:39:46 <jnewbery> Can I quickly get back to #15750?
19:39:46 <gmaxwell> cfields: we can agree that there are at least concerns there, even if we disagree how much its really any different.
19:39:48 <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
19:39:59 <wumpus> #topic Remove addresses field in getaddressinfo
19:40:03 <jnewbery> The addresses field was marked deprecated in v0.17 along with other changes to validateaddress and getaddressinfo (#10583)
19:40:07 <gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
19:40:09 <jnewbery> #12490 (V0.18) should have removed the all deprecated functionality (and depracation notes). This part was missed out.
19:40:11 <gribble> https://github.com/bitcoin/bitcoin/issues/12490 | [Wallet] [RPC] Remove deprecated wallet rpc features from bitcoin_server by jnewbery · Pull Request #12490 · bitcoin/bitcoin · GitHub
19:40:13 <cfields> gmaxwell: oh for sure, this really is just "here, this is possible, see if it's useful". It seems it was taken as more than that.
19:40:15 <jnewbery> So #15750 should fully remove it in v0.18.
19:40:17 <gribble> https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
19:40:19 <gmaxwell> cfields: +1000
19:40:25 <gmaxwell> cfields: thanks for bringing it up
19:40:30 <jnewbery> I don't think it counts as controversial if some random drops in and says "NEVER CHANGE RPCS". If we let that stop useful changes to Bitcoin Core we'd never do anything.
19:40:45 <wumpus> jnewbery: I agree
19:41:02 <gmaxwell> cfields: also I hope it was useful to the people most interested in using rust to understand the kind of headwinds that are out there.  I don't think we can really have much useful discussion without talking about something specific.
19:41:09 <sipa> jnewbery: his comments also seem to be about the move from validateaddress to getaddressinfo in the first place
19:41:16 <sipa> which if anything are far too late
19:41:32 <luke-jr> jnewbery: "bugfixes only during RCs" is not "NEVER CHANGE RPCS"
19:41:32 <gmaxwell> It's unclear to me if he just needs help phrasing his argument.
19:41:40 <gmaxwell> But I agree the argument as stated should be ignored.
19:41:51 <wumpus> jnewbery: I was just reasoning 'what would it hurt to move this to 0.19', not trying to argue against the change!
19:41:52 <jnewbery> Right, I don't think he's concerned about this particular field
19:42:05 <wumpus> luke-jr: right
19:42:05 <instagibbs> 0.17 breakages were heavier than in the past fwiw
19:42:11 <gmaxwell> Sometimes people have a real complaint (like "I use that field, can't easily generate it myself, and you're taking it away") but just don't know how to state it, so we should be sensitive to that.
19:42:26 <instagibbs> not complaining, we just have delayed upgrading on some stuff due to it, which is fine
19:42:27 <jnewbery> The problem is that the deprecation notice goes away in v0.18
19:42:32 <wumpus> gmaxwell: yes, would make sense to add documentation for that
19:42:33 <gmaxwell> (life would be better if bug reporters were assigned a lawyer)
19:42:45 <sipa> gmaxwell: i'm... not sure
19:42:52 <wumpus> (which is also what I noted in the PR)
19:42:59 <instagibbs> are we suing people when they file issues :)
19:43:11 <MarcoFalke> no, they sue us
19:43:12 <gmaxwell> I just mean an advocate who would tell them how to state their issue in a way that makes sense to the process they're addressing.
19:43:20 <sipa> ah yes
19:43:21 <jnewbery> my point is that we should remove all of the deprecated parts of `deprecatedrpc=validateaddress` in one release or none at all
19:43:22 <luke-jr> we can always say "use 0.17 until you're ready" too
19:43:42 <achow101> jnewbery: ack
19:43:51 <jeremyrubin> instagibbs: is the issue csw not being satoshi
19:43:56 <sipa> jnewbery: i agree; but i also think it's a minor enough thing
19:44:14 <jnewbery> Yeah, I wouldn't bring it up if we weren't already doing another rc
19:44:28 <wumpus> yes, I don't care deeply either way, it just seems to cause a lot of discussion
19:45:00 <gmaxwell> when in doubt, add docs.
19:45:32 <wumpus> yes
19:46:17 <sipa> oh quick topic: there has been a bunch of improvements to https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.18.0-Release-Notes-Draft lately (thanks, harding); people may want to look over it before it becomes a last-minute thing before release
19:46:24 <gmaxwell> in any case, we should also consider it a good sign that we're getting compat complaints now.  None is the wrong number.
19:46:25 <wumpus> anyhow added "needs backport" for now
19:46:36 <jnewbery> wumpus: thanks!
19:46:38 <gmaxwell> sipa: thanks, will do
19:47:29 <sipa> achow101: in particular, i think the new psbt descriptions could use slightly more text
19:47:29 <wumpus> sipa: good idea
19:47:33 <sipa> *new psbt rpcs
19:47:55 <achow101> sipa: I can take a look at those
19:48:03 <wumpus> yes, as a general concept, documentation belongs in the doc/ folder, not in the release notes, could always add a link :)
19:48:25 <sipa> so also have a look at the updates in doc/psbt.md :p
19:48:58 <wumpus> it's good to meantion things in the release notes but indeed not to be too wordy
19:49:05 <wumpus> ok, cfields had another topic
19:49:15 <wumpus> #topic Platform deprecation (cfields)
19:49:18 <wumpus> sipa: will do
19:49:29 <cfields> We don't (afaik?) have any means of deprecating old platforms. Many of the TODOs left for rust integration revolve around pretty old/unused platforms. I'm not suggesting that we drop platforms just because rust may be integrated at some point in the future, only that now seems like a reasonable time to re-evaluate. I originally planned to do the work to hack together fixes either here or upstream, but it's worth asking first: are these
19:49:29 <cfields> platforms worth the effort?
19:49:38 <cfields> The actual issues are documented in the PR. In particular, the troubled platforms are 32bit Windows and glibc < 2.15. glibc distro versions (unverified google hit) can be seen here: https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa45b1
19:49:41 <wumpus> which platform?
19:50:17 <sipa> are all newly sold x86 CPUs these days 64-bit?
19:50:29 <wumpus> yess since 2005 or so?
19:50:37 <sipa> and do people run 64-bit OSes on them?
19:50:43 <cfields> sipa: I would think anything running windows especially.
19:50:45 <wumpus> for windows: yes
19:50:46 <sipa> (i have no clue about the windows ecosystem in this regard)
19:50:47 <gmaxwell> yes, though all still also capable of running in 32bit mode.
19:50:50 <luke-jr> cfields: AFAIK current policy is to freely drop support for all but the most recent stable release of major distros; I assume none of them use glibc <2.15 ?
19:51:14 <gmaxwell> for a long time people were still installing new systems as 32-bit but I think thats finally stopped as of about two years ago.
19:51:26 <cfields> luke-jr: see link above, I don't recall off the top of my head.
19:51:43 <gmaxwell> (e.g. two-ish years ago the default fedora download was 32-bit, in part because of compatiblity with #$@# binary only browser extensions)
19:51:50 <wumpus> 100% behind deprecating windows 32-bit
19:52:17 <jonasschnelli> me 2
19:52:41 <gmaxwell> unfortunately we don't run that well on 32-bit in any case,  I'm not currently aware of a reason we shouldn't depricate windows 32-bit but I am not a windows expert. :)
19:52:42 <wumpus> I've tried to raise the issue two years ago (or so?) and maybe one person complained on twitter, who was in the process of migrating things to a 64-bit OS later that year so…
19:52:46 <jonasschnelli> just don't deprecate the ARM 32bits
19:52:51 <wumpus> oh no not ARM
19:52:53 <wumpus> I mean x86
19:52:55 <cfields> jonasschnelli: right.
19:52:59 <wumpus> windows
19:53:07 <bitcoin-git> [13bitcoin] 15MarcoFalke opened pull request #15799: doc: Clarify RPC versioning (06master...061904-docRPC) 02https://github.com/bitcoin/bitcoin/pull/15799
19:53:15 <meshcollider> Does that clean up any existing windows-only code or just for later
19:53:31 <wumpus> and for 0.19
19:53:49 <achow101> Windows does have 32 bit version still
19:53:51 <wumpus> meshcollider: I don't think it cleans up any code tbh
19:54:03 <cfields> Great, that was easy :)
19:54:04 <wumpus> it just leaves oneless configuration to maintain and test
19:54:06 <wumpus> which is good
19:54:15 <jeremyrubin> Is anyone even testing 32-bit windows?
19:54:18 <wumpus> no.
19:54:22 <jonasschnelli> I do
19:54:26 <cfields> wumpus: it's also the one that takes _forever_ to run.
19:54:26 <wumpus> oh!
19:54:31 <jonasschnelli> (VM though)
19:54:37 <luke-jr> maybe we should solicit feedback somehow?
19:54:42 <gmaxwell> 12:52:42 < wumpus> I've tried to raise the issue two years ago (or so?) and maybe one person complained on twitter, who was in the process of
19:54:47 <gmaxwell> ^ fantastic!
19:54:47 <luke-jr> open an issue to deprecate Win32, and put it in release notes?
19:55:05 <gmaxwell> luke-jr: I don't disagree but it also sounds like wumpus already did previously.
19:55:16 <wumpus> I mean we already dropped xp and vista support, which are the most likely to be 32 bit
19:55:21 <luke-jr> gmaxwell: a tweet isn't as loud as release notes
19:55:32 <sipa> luke-jr: i suspect more people read tweets :p
19:55:38 <luke-jr> sipa: could be :/
19:55:41 <sipa> (but maybe less relevant ones)
19:55:49 <cfields> sipa: haha
19:55:51 <sipa> windows 10 still has a 32-bit version it seems
19:56:01 <wumpus> windows 7/8 was already mostly 64-bit, windows 10 certainly
19:56:06 <wumpus> yes it exists but no one uses it
19:56:11 <luke-jr> sipa: how many people use it?
19:56:11 <sipa> okay.
19:56:25 <sipa> luke-jr: i have no clue!
19:56:27 <bitcoin-git> [13bitcoin] 15jnewbery opened pull request #15800: [rpc] Remove the addresses field from the getaddressinfo return object (060.18...062019_04_remove_address_from_getaddressinfo_0.18) 02https://github.com/bitcoin/bitcoin/pull/15800
19:56:42 <luke-jr> I'm sure Microsoft does :P
19:57:31 <luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
19:57:50 <wumpus> the kind of CPUs that only run 32-bit don't really run bitcoin, you'd be better off with a rpi at that point
19:57:57 <wumpus> +x86
19:57:58 <luke-jr> that way we can always upload them later if it's a problem
19:58:13 <meshcollider> Seems sensible
19:58:26 <wumpus> luke-jr: good idea
19:58:29 <wumpus> :D
19:58:39 <gmaxwell> 12:57:31 < luke-jr> maybe we could just neglect to post the Win32 binaries for 0.18 and see who complains?\
19:58:42 <gmaxwell> ^ I'd +1 that too
19:58:48 <instagibbs> wumpus, fwiw they croak when trying to run secp-zkp benchmarks too
19:58:51 <gmaxwell> that would be a nice way of measuring usage.
19:59:04 <wumpus> yes, let's do that
19:59:13 <wumpus> instagibbs: whoops
19:59:21 <harding> I'm not sure if people are serious, but if you are, please let me know in advance.  The BitcoinCore.org site tests check for missing binaries.
19:59:24 * luke-jr glares at the clock
19:59:27 <gmaxwell> if people complain about the binaries, then we can just go ahead and post them.
19:59:34 <instagibbs> harding, is that a complaint ;)
19:59:36 <wumpus> #endmeeting