19:00:22 <wumpus> #startmeeting
19:00:22 <lightningbot> Meeting started Thu Oct 10 19:00:22 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:22 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:25 <kanzure> hi
19:00:39 <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
19:00:44 <promag> hello
19:00:47 <gleb> hi
19:00:48 <jonatack> hi
19:01:05 <fanquake> hi
19:01:09 <sipa> hi
19:01:12 <elichai2> hi
19:01:21 <provoostenator> hi
19:01:29 <meshcollider> hi
19:01:44 <wumpus> has anyone been testing 0.19.0rc1? any issues found?
19:02:01 <fanquake> Limited testing so far. Nothing obvious has cropped up.
19:02:05 <MarcoFalke> hoy
19:02:08 <fanquake> Will do more over the weekend.
19:02:28 <jonasschnelli> hi
19:02:30 <wumpus> same, no problems here
19:02:34 <achow101> hi
19:02:52 <MarcoFalke> Would be surprised if this was the first major release without bugs xD
19:02:52 * jonasschnelli running 0.19.0rc1
19:03:08 <wumpus> we should definitely give it some more time :)
19:04:03 <real_or_random> hi
19:04:07 <promag> spinning as usual
19:04:20 <wumpus> we have one proposed topic: #16834 (BlueMatt)
19:04:21 <gribble> https://github.com/bitcoin/bitcoin/issues/16834 | Fetch Headers over DNS by TheBlueMatt · Pull Request #16834 · bitcoin/bitcoin · GitHub
19:04:27 <fanquake> A couple PRs to pull in at some point as well. https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+backport+%280.19%29%22
19:04:30 <BlueMatt> yea, I need to find some time to switch my seed nodes to 190rc1
19:04:41 <BlueMatt> will do this coming week
19:04:50 <wumpus> but we'll start with high priority for review again
19:04:57 <wumpus> #topic High priority for review
19:05:20 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  only three blockers on the list right now
19:05:39 <fanquake> #16202 Had quite a few ACKs, however needs a rebase jonasschnelli
19:05:41 <wumpus> #16202 is close to merge?
19:05:41 <gribble> https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub
19:05:44 <gribble> https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub
19:05:58 <jonasschnelli> Oh. Let me rebase then
19:06:05 <MarcoFalke> I'd like to put up #16490
19:06:07 <gribble> https://github.com/bitcoin/bitcoin/issues/16490 | rpc: Report reason for replaceable txpool transactions by MarcoFalke · Pull Request #16490 · bitcoin/bitcoin · GitHub
19:06:32 <dongcarl> I think most of the comments in #16202 expand on the scope, and should be followups. They're all ACKs otherwise
19:06:34 <gribble> https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub
19:07:03 <jnewbery> hi
19:07:07 <MarcoFalke> I removed the "Bugs in 0.19 are blockers" card in high prio
19:07:18 <wumpus> MarcoFalke: added
19:07:22 <MarcoFalke> thx
19:07:59 <provoostenator> I'd like to nominate #16944, pretty close anyway...
19:08:01 <gribble> https://github.com/bitcoin/bitcoin/issues/16944 | gui: create PSBT with watch-only wallet by Sjors · Pull Request #16944 · bitcoin/bitcoin · GitHub
19:08:20 <wumpus> dongcarl: right, especially so early in the release window it's better to merge, then expanding the scope in follow-ups, it allows for better cooporation
19:09:20 <wumpus> provoostenator: ok added
19:09:43 <jonasschnelli> my only worry is, that with 16944 the GUI gets even more complicated
19:09:52 <fanquake> ^
19:09:57 <jonasschnelli> But maybe okay for watch-only expertish setups
19:10:08 <wumpus> #topic gui: create PSBT with watch-only wallet
19:10:19 <jonasschnelli> but I need to take a closer look at 16944 before I further complain
19:11:20 <provoostenator> jonasschnelli: it's going to get more complicated if we ever add full hardware support
19:11:31 <provoostenator> See also: #16966
19:11:33 <gribble> https://github.com/bitcoin/bitcoin/issues/16966 | ui: make send a wizard by Sjors · Pull Request #16966 · bitcoin/bitcoin · GitHub
19:12:08 <provoostenator> That wizard PR should make it easier to add more stuff, because we're not squeezing a million things in one dialog.
19:13:02 <wumpus> yes
19:13:17 <promag> yup
19:13:37 <fanquake> provoostenator: how does what your doing aling/conflict with what the HWI project is doing GUI wise?
19:13:42 <fanquake> *align
19:13:56 <fanquake> I've seen discussions on their repo about adding some sort of GUI.
19:14:14 <provoostenator> It's the reverse approach, it can co-exist
19:14:47 <jonasschnelli> however, the function itself (PSBT creation in watch-only mode) is certainly a strong concept ack,... just need to watch out for the UX
19:14:50 <achow101> The idea is to have some gui for HWI where users can paste the psbt from 16944 instead of having to go to the command line
19:16:02 <provoostenator> In the longer run I'd rather not force users to have 2 GUIs to deal with, but in the short run an HWI GUI is easier.
19:17:11 <jonasschnelli> I totally get the use case... just copy pasting from one UI to another is not a UX users appreciate in general. However, I'm not saying this is how it could be done initially
19:17:21 <fanquake> At a high level, not necessarily in regards to this PR, I'm hesitant to add more & more flows/functionality to Cores GUI. However I'll present my thoughts another time.
19:17:29 <provoostenator> I plan to build a hardware wallet GUI on top of the wizard above.
19:17:50 <provoostenator> As well as some options to the create wallet dialog.
19:18:15 <jonasschnelli> I think that would be great. Thanks provoostenator
19:18:47 <achow101> yeah, the two gui things is just a stop-gap measure, just like how the importmulti thing was a stop-gap
19:19:22 <fanquake> Should we move on? bluematt & DNS & Rust ?
19:19:40 <wumpus> right, got to have it working first, then think about streamlining it
19:19:40 <elichai2> :)
19:20:11 <fanquake> Has also been some good Rust related discussion in #17090 so far.
19:20:13 <gribble> https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub
19:20:17 <wumpus> #topic Fetch Headers over DNS (BlueMatt)
19:20:19 <BlueMatt> so #17090 is where the high-level discussion has moved, and there's good comments there to read, but, at a high level, I want to move forward with (in 0.20, off by default, with a goal of on by default/in release bins in 0.21) work to enable parallel p2p and block/header download in rust.
19:20:21 <gribble> https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub
19:20:22 <BlueMatt> the first step/merge-candidate is #16834 which just fetches headers over dns with 100 loc in rust or so. I want to change the format of the dns responses but otherwise (mod some review from elichai2 I need to respond to) I think its "ready to go"
19:20:23 <gribble> https://github.com/bitcoin/bitcoin/issues/16834 | Fetch Headers over DNS by TheBlueMatt · Pull Request #16834 · bitcoin/bitcoin · GitHub
19:20:30 <BlueMatt> (sorry, I had those pre-written :p)
19:21:23 <BlueMatt> in the medium-term, I'd like a) blocks-over-http(preferably s, but ssl is Hard), and b) a full parallel p2p network implementation in rust, likely with the same protocol and with an explicit goal of being Simple and Robust
19:21:27 <fanquake> Aside from the review comments, I've discussed with Cory and there is still some build related "cleanup" that can be done there as well.
19:21:40 <wumpus> as for the high level discussion about rust, concept ACK, don't really have anything to say besides already written in #17090
19:21:41 <gribble> https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub
19:21:43 <BlueMatt> but it has generated a nice little framework for building ways to download the chain
19:21:54 <achow101> time to learn rust I guess
19:22:04 <wumpus> as for fetching headers over DNS ... interesting idea, doesn't it put a lot of strain on the DNS resolver to have a request per block?
19:22:07 <cfields> I think if we're going to discuss here, we should split this topic in two.
19:22:45 <BlueMatt> wumpus: probably, but its partially a demo, and partially a thing that you could theoretically use in conjunction with the Dns-over-https-over-cloudflare stuff people are looking at putting in systemd....
19:22:52 <cfields> (Or maybe the higher level discussions belong on 17090)
19:23:05 <wumpus> so it's good for the last-to-end bocks, but not for getting the entire chain, I guess
19:23:13 <BlueMatt> I think there's a few open questions here that we may want to discuss
19:23:20 <BlueMatt> biggest is just what rustc version do we target
19:23:45 <BlueMatt> wumpus: my model for eaders fetching is that it may be a good censorship *detection* thing, so even if it just gets a few more headers than you have blocks, thats ok
19:23:57 <wumpus> whatever is in bionic would be most convenient I guess
19:24:02 <elichai2> I agree with BlueMatt on the rustc version.
19:24:04 <BlueMatt> as long as it can generate a "you may be censored" warning, which p2p could take an turn on more aggressive options, as well as warn the user
19:24:26 <elichai2> wumpus: that means 1.36
19:24:29 <cfields> Right, we've discussed this a bit briefly. Because we don't yet have any rust code, and it won't be a build-time requirement, it makes sense imo to require the version that delivers whatever features we need. If that's bleeding-edge, so be it.
19:24:38 <BlueMatt> looks like bionic has a newer rustc than debian stable
19:24:46 <BlueMatt> (1.36 instead of 1.34)
19:24:55 <MarcoFalke> we need bionic for gitian building
19:25:15 <BlueMatt> I dont think we're gonna ship rust code in release until dongcarl figures out guix stuff
19:25:30 <BlueMatt> but I *do* think we don't want to break debian stable (which is gonna be stable for like years)
19:26:04 <elichai2> that's weird
19:26:11 <MarcoFalke> That means the rust code is not shipped and disabled by default. What is the point then? Might as well not do it if it doesn't give any advantage
19:26:12 <wumpus> hm it seems pretty easy to integrate it into the existing gitian
19:26:31 <wumpus> I'm not sure why make it conditional on guix, but anyhow
19:26:42 <wumpus> MarcoFalke: that's the goal in the long term at least
19:26:47 <cfields> MarcoFalke: I mean that we don't *yet* have any rust code, so we're still free to set whatever requirements we want.
19:26:51 <fanquake> BlueMatt Is there anything not in 1.34 from later versions that would be "nice to have" ?
19:26:51 <provoostenator> The new feature can be tested by folks who build manually, that's been done before
19:26:52 <cfields> That changes as soon as we lock-in.
19:26:53 <BlueMatt> MarcoFalke: well I was kinda expecting we'd want to have a good story around bootstrapping the rust code before we ship in release binaries
19:26:57 <BlueMatt> (was hoping 0.21)
19:27:05 <wumpus> I don't think it makes sense to make so many different concerns conditional on each other
19:27:06 <BlueMatt> but if we're comfortable with it, that's cool too
19:27:30 <elichai2> fanquake: i'm going over releases now to see if there's anything really interesting after 1.34
19:27:33 <wumpus> historically that was always a bad idea because we don't really know how long things are going to take
19:27:46 <MarcoFalke> for gitian you need to trust Ubuntu either way, so there is no downgrade in trusting the Bionic rustc
19:28:06 <jnewbery> I'm worried that in this medium-term world where we have a shiny new rust p2p implementation, we'll have even fewer people making and reviewing changes in the c++ p2p implementation
19:28:17 <BlueMatt> I suppose this is true....ubuntu did bootstrap rust themselves.....
19:28:44 <BlueMatt> jnewbery: my anticipation is that the "shiny new rust p2p implementation" was explicitly "thou may not relay transactions nor add anything 'complicated'"
19:28:46 <fanquake> jnewbery: atleast that should be somewhat offset by the major p2p reviewers not being Rust devs, as far as I'm aware.
19:28:50 <BlueMatt> so that would hopefully limit that somewhat
19:29:01 <fanquake> aside from bluematt that is.
19:29:39 <wumpus> jnewbery: I mean, you can never control wat people will review and contribute to
19:29:55 <elichai2> 1. better hashmap. 2.alloc crate. 3. #[must_use]. 4. `--offline` to cargo. 5. armv7-unknown-freebsd-gnueabihf, armv6-unknown-freebsd-gnueabihf, wasm32-unknown-wasi support.
19:30:05 <elichai2> i don't think any of them matter but  1.34.2 fixed a CVE
19:30:14 <jnewbery> wumpus: right, I agree with that. I certainly wouldn't want to tell anyone what they should work on
19:30:17 <BlueMatt> right, debian does have 1.34.2, not 1.34
19:30:17 <wumpus> jnewbery: it sounds a bit childish to not include rust code because you're afraid developers will look at that code more :)
19:30:19 <elichai2> that's the debian supported version
19:30:29 <cfields> elichai2: is 2. needed for overriding malloc?
19:30:50 <elichai2> cfields: no. it's just a way to link against liballoc and not libstd
19:30:50 <ysangkok> wouldn't it make sense to drop support for debian once guix makes it really easier to build the same thing on all platforms?
19:30:50 <wumpus> also, it might also get new people interested, you never know
19:30:51 <BlueMatt> cfields: no, only 1.28 is required for GlobalAlloc
19:31:05 <cfields> Ok, thanks.
19:31:06 <elichai2> (making binaries smaller and further support for embedded)
19:31:28 <fanquake> wumpus: hopefully
19:31:35 <jnewbery> wumpus: I'm not sure it's childish. I think it's a valid concern thta when there aren't many developers looking at a component, then reimplementing it in a different language may make the situation worse
19:32:02 <MarcoFalke> ysangkok: That is the long-term goal, but won't happen before Bitcoin Core 0.21.0
19:32:12 <provoostenator> I would probably feel more embolded reviewing c++ p2p code if there was a fresh Rust version to compare with
19:32:18 <BlueMatt> elichai2: well luckily all but 3 there dont require changes to our code, so we can build with newer rustc and get those features, even if we "support" older ones
19:32:18 <wumpus> jnewbery: but only if you see the set of dvelopers looking at the code as a closed set, I hope that's not the case in the medium term
19:33:26 <elichai2> BlueMatt: yeah I shoud've dropped 1 because that's transparent to impl. but 2 isn't. altough I don't think we care about it that much (maybe for compiling to some exotic target that doesn't support libstd)
19:33:48 <BlueMatt> right, I dont think core is gonna support wasm so that may be ok :p
19:34:48 <elichai2> oh another thing in 1.35 is musl support. although again that doesn't bother implementors. only the users who compile (a user can compile the same code both to x86_64-gnu and x86_64-musl) https://github.com/rust-lang/rust/pull/58575
19:35:16 <elichai2> IMHO 1.34.2 it is
19:35:28 <midnightmagic> musl appears to be a popular target for supporting e.g. BE on POWER9
19:35:33 <BlueMatt> kool, unless there are other obections seems like at least that issue is fine
19:36:13 <wumpus> people that want to use musl can just use a newer rust, right?
19:36:28 <BlueMatt> midnightmagic: right, just means those users will need a newer rustc, even though we "support" older ones
19:36:29 <elichai2> yes
19:36:29 <wumpus> that it supports 1.35 doesn't mean you need to build with that...
19:36:30 <BlueMatt> yep
19:36:47 <elichai2> the target support should only conserned released binaries I think
19:37:17 <midnightmagic> sure, just making observation that it appears some (highly competent) people are liking the musl
19:37:26 <BlueMatt> right
19:37:30 <midnightmagic> \o
19:37:43 <elichai2> so as long as all released binaries are for x86 windows/gnu(glibc) then I don't think any of that other stuff matter. users can use 1.38 to compile to musl/armv7/riscv32i etc.
19:38:05 <cfields> *armv7-bsd
19:38:05 <wumpus> released binaries are glibc only
19:38:25 <wumpus> I'm sure that could change inthe future, but that's a wholly different concern
19:38:26 <BlueMatt> right, and you'll at least be able to turn it off at compile time for the forseeable future
19:38:53 <cfields> elichai2 and I have a longer-term plan for rust/libc world domination anyway.
19:39:05 <BlueMatt> another thing that may be worth mentioning here is that for the bitcoin core-required bits of stratumv2 (ie a getblocktemplate replacement) there has been some initial speculation/thinking that it would be in rust
19:40:16 <elichai2> cfields: don't know too much about armv7 but something changed even for the linux variants lately https://github.com/rust-lang/rust/pull/63107/
19:40:29 <MarcoFalke> so the windows,mac,and arm releases couldn't come with any rust code compiled in?
19:40:36 <MarcoFalke> only the x86 ones?
19:41:03 <BlueMatt> no they totally could
19:41:13 <BlueMatt> all of those platforms are "well supported"
19:41:36 <BlueMatt> power may be more of a question (as its "second tier" support or some shit like that), but I've never had issues with rust on power9 and thats my main dev machine
19:42:13 <wumpus> rust works very well on ARM 32 and 64, windows/mac is also well supported
19:42:20 <MarcoFalke> we don't have power yet: #14066
19:42:22 <cfields> yeah, I'm a bit confused about that PR. I think it's a bit more subtle than "armv7 wasn't supported but is now".
19:42:23 <wumpus> risc-v linux is still a problem right now
19:42:43 <elichai2> I really don't know a lot about arm and there are too many target triples for armv7 for me to know what's what lol
19:42:47 <wumpus> then again, that will be resolved soon, I'm sure it won't be in a year or so
19:42:48 <gribble> https://github.com/bitcoin/bitcoin/issues/14066 | gitian-linux: Build binaries for 64-bit POWER by luke-jr · Pull Request #14066 · bitcoin/bitcoin · GitHub
19:42:58 <elichai2> wumpus: which target triple is "normal arm"?
19:43:05 <wumpus> arm-linux-gnueabi
19:43:10 <wumpus> hf
19:43:38 <elichai2> yeah. that's Tier 2 with cargo+rustc+libstd. good support :)
19:43:39 <BlueMatt> do we support hard forking? </badjoke>
19:43:54 <wumpus> arm64 is aarch64-linux-gnu
19:44:23 <wumpus> both can run the compiler as well as cross compile for
19:44:38 <fanquake> Getting a bit into the weeds here. Does anyone else have a meeting topic for the last 15 minutes? Otherwise I can we can continue Rust discussion/
19:44:40 <elichai2> yep same. the `gnueabi` and `musleabi` are the ones who changed
19:45:01 <wumpus> I don't think there's any other topics
19:45:41 <wumpus> #endmeeting