19:00:22 #startmeeting 19:00:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:25 hi 19:00:39 #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 hello 19:00:47 hi 19:00:48 hi 19:01:05 hi 19:01:09 hi 19:01:12 hi 19:01:21 hi 19:01:29 hi 19:01:44 has anyone been testing 0.19.0rc1? any issues found? 19:02:01 Limited testing so far. Nothing obvious has cropped up. 19:02:05 hoy 19:02:08 Will do more over the weekend. 19:02:28 hi 19:02:30 same, no problems here 19:02:34 hi 19:02:52 Would be surprised if this was the first major release without bugs xD 19:02:52 * jonasschnelli running 0.19.0rc1 19:03:08 we should definitely give it some more time :) 19:04:03 hi 19:04:07 spinning as usual 19:04:20 we have one proposed topic: #16834 (BlueMatt) 19:04:21 https://github.com/bitcoin/bitcoin/issues/16834 | Fetch Headers over DNS by TheBlueMatt · Pull Request #16834 · bitcoin/bitcoin · GitHub 19:04:27 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 yea, I need to find some time to switch my seed nodes to 190rc1 19:04:41 will do this coming week 19:04:50 but we'll start with high priority for review again 19:04:57 #topic High priority for review 19:05:20 https://github.com/bitcoin/bitcoin/projects/8 only three blockers on the list right now 19:05:39 #16202 Had quite a few ACKs, however needs a rebase jonasschnelli 19:05:41 #16202 is close to merge? 19:05:41 https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub 19:05:44 https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub 19:05:58 Oh. Let me rebase then 19:06:05 I'd like to put up #16490 19:06:07 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 I think most of the comments in #16202 expand on the scope, and should be followups. They're all ACKs otherwise 19:06:34 https://github.com/bitcoin/bitcoin/issues/16202 | Refactor network message deserialization by jonasschnelli · Pull Request #16202 · bitcoin/bitcoin · GitHub 19:07:03 hi 19:07:07 I removed the "Bugs in 0.19 are blockers" card in high prio 19:07:18 MarcoFalke: added 19:07:22 thx 19:07:59 I'd like to nominate #16944, pretty close anyway... 19:08:01 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 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 provoostenator: ok added 19:09:43 my only worry is, that with 16944 the GUI gets even more complicated 19:09:52 ^ 19:09:57 But maybe okay for watch-only expertish setups 19:10:08 #topic gui: create PSBT with watch-only wallet 19:10:19 but I need to take a closer look at 16944 before I further complain 19:11:20 jonasschnelli: it's going to get more complicated if we ever add full hardware support 19:11:31 See also: #16966 19:11:33 https://github.com/bitcoin/bitcoin/issues/16966 | ui: make send a wizard by Sjors · Pull Request #16966 · bitcoin/bitcoin · GitHub 19:12:08 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 yes 19:13:17 yup 19:13:37 provoostenator: how does what your doing aling/conflict with what the HWI project is doing GUI wise? 19:13:42 *align 19:13:56 I've seen discussions on their repo about adding some sort of GUI. 19:14:14 It's the reverse approach, it can co-exist 19:14:47 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 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 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 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 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 I plan to build a hardware wallet GUI on top of the wizard above. 19:17:50 As well as some options to the create wallet dialog. 19:18:15 I think that would be great. Thanks provoostenator 19:18:47 yeah, the two gui things is just a stop-gap measure, just like how the importmulti thing was a stop-gap 19:19:22 Should we move on? bluematt & DNS & Rust ? 19:19:40 right, got to have it working first, then think about streamlining it 19:19:40 :) 19:20:11 Has also been some good Rust related discussion in #17090 so far. 19:20:13 https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub 19:20:17 #topic Fetch Headers over DNS (BlueMatt) 19:20:19 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 https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub 19:20:22 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 https://github.com/bitcoin/bitcoin/issues/16834 | Fetch Headers over DNS by TheBlueMatt · Pull Request #16834 · bitcoin/bitcoin · GitHub 19:20:30 (sorry, I had those pre-written :p) 19:21:23 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 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 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 https://github.com/bitcoin/bitcoin/issues/17090 | RFC: Rust code integration · Issue #17090 · bitcoin/bitcoin · GitHub 19:21:43 but it has generated a nice little framework for building ways to download the chain 19:21:54 time to learn rust I guess 19:22:04 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 I think if we're going to discuss here, we should split this topic in two. 19:22:45 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 (Or maybe the higher level discussions belong on 17090) 19:23:05 so it's good for the last-to-end bocks, but not for getting the entire chain, I guess 19:23:13 I think there's a few open questions here that we may want to discuss 19:23:20 biggest is just what rustc version do we target 19:23:45 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 whatever is in bionic would be most convenient I guess 19:24:02 I agree with BlueMatt on the rustc version. 19:24:04 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 wumpus: that means 1.36 19:24:29 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 looks like bionic has a newer rustc than debian stable 19:24:46 (1.36 instead of 1.34) 19:24:55 we need bionic for gitian building 19:25:15 I dont think we're gonna ship rust code in release until dongcarl figures out guix stuff 19:25:30 but I *do* think we don't want to break debian stable (which is gonna be stable for like years) 19:26:04 that's weird 19:26:11 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 hm it seems pretty easy to integrate it into the existing gitian 19:26:31 I'm not sure why make it conditional on guix, but anyhow 19:26:42 MarcoFalke: that's the goal in the long term at least 19:26:47 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 BlueMatt Is there anything not in 1.34 from later versions that would be "nice to have" ? 19:26:51 The new feature can be tested by folks who build manually, that's been done before 19:26:52 That changes as soon as we lock-in. 19:26:53 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 (was hoping 0.21) 19:27:05 I don't think it makes sense to make so many different concerns conditional on each other 19:27:06 but if we're comfortable with it, that's cool too 19:27:30 fanquake: i'm going over releases now to see if there's anything really interesting after 1.34 19:27:33 historically that was always a bad idea because we don't really know how long things are going to take 19:27:46 for gitian you need to trust Ubuntu either way, so there is no downgrade in trusting the Bionic rustc 19:28:06 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 I suppose this is true....ubuntu did bootstrap rust themselves..... 19:28:44 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 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 so that would hopefully limit that somewhat 19:29:01 aside from bluematt that is. 19:29:39 jnewbery: I mean, you can never control wat people will review and contribute to 19:29:55 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 i don't think any of them matter but 1.34.2 fixed a CVE 19:30:14 wumpus: right, I agree with that. I certainly wouldn't want to tell anyone what they should work on 19:30:17 right, debian does have 1.34.2, not 1.34 19:30:17 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 that's the debian supported version 19:30:29 elichai2: is 2. needed for overriding malloc? 19:30:50 cfields: no. it's just a way to link against liballoc and not libstd 19:30:50 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 also, it might also get new people interested, you never know 19:30:51 cfields: no, only 1.28 is required for GlobalAlloc 19:31:05 Ok, thanks. 19:31:06 (making binaries smaller and further support for embedded) 19:31:28 wumpus: hopefully 19:31:35 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 ysangkok: That is the long-term goal, but won't happen before Bitcoin Core 0.21.0 19:32:12 I would probably feel more embolded reviewing c++ p2p code if there was a fresh Rust version to compare with 19:32:18 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 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 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 right, I dont think core is gonna support wasm so that may be ok :p 19:34:48 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 IMHO 1.34.2 it is 19:35:28 musl appears to be a popular target for supporting e.g. BE on POWER9 19:35:33 kool, unless there are other obections seems like at least that issue is fine 19:36:13 people that want to use musl can just use a newer rust, right? 19:36:28 midnightmagic: right, just means those users will need a newer rustc, even though we "support" older ones 19:36:29 yes 19:36:29 that it supports 1.35 doesn't mean you need to build with that... 19:36:30 yep 19:36:47 the target support should only conserned released binaries I think 19:37:17 sure, just making observation that it appears some (highly competent) people are liking the musl 19:37:26 right 19:37:30 \o 19:37:43 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 *armv7-bsd 19:38:05 released binaries are glibc only 19:38:25 I'm sure that could change inthe future, but that's a wholly different concern 19:38:26 right, and you'll at least be able to turn it off at compile time for the forseeable future 19:38:53 elichai2 and I have a longer-term plan for rust/libc world domination anyway. 19:39:05 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 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 so the windows,mac,and arm releases couldn't come with any rust code compiled in? 19:40:36 only the x86 ones? 19:41:03 no they totally could 19:41:13 all of those platforms are "well supported" 19:41:36 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 rust works very well on ARM 32 and 64, windows/mac is also well supported 19:42:20 we don't have power yet: #14066 19:42:22 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 risc-v linux is still a problem right now 19:42:43 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 then again, that will be resolved soon, I'm sure it won't be in a year or so 19:42:48 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 wumpus: which target triple is "normal arm"? 19:43:05 arm-linux-gnueabi 19:43:10 hf 19:43:38 yeah. that's Tier 2 with cargo+rustc+libstd. good support :) 19:43:39 do we support hard forking? 19:43:54 arm64 is aarch64-linux-gnu 19:44:23 both can run the compiler as well as cross compile for 19:44:38 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 yep same. the `gnueabi` and `musleabi` are the ones who changed 19:45:01 I don't think there's any other topics 19:45:41 #endmeeting