19:00:04 <wumpus> #startmeeting
19:00:04 <lightningbot> Meeting started Thu Aug  1 19:00:04 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:04 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:07 <moneyball> https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
19:00:07 <jnewbery> hi
19:00:21 <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:27 <provoostenator> hi\
19:00:30 <sdaftuar> hello
19:00:33 <kanzure> hi
19:00:48 <meshcollider> Hi
19:01:08 <achow101> hi
19:01:11 * jonasschnelli not really here
19:01:19 <wumpus> four proposed topics today in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a, though jonasschnelli is not here
19:01:22 <wumpus> right
19:01:36 <jamesob> hi
19:01:42 <sipa> hi
19:01:43 <wumpus> #topic High priority for review
19:02:11 <wumpus> 7 PRs (!) left in blockers, also 7 things chasing concept ACK
19:02:17 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:02:33 <gleb> hi
19:02:53 <wumpus> anything to add/remove?
19:03:08 <wumpus> or more or less ready for merge?
19:03:12 <sdaftuar> i'll beg again for review on #15759
19:03:15 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
19:03:41 <wumpus> we should probably refuse to add anything more to high prio until 15759 is merged :-)
19:03:51 <sdaftuar> no argument from me :)
19:03:59 <MarcoFalke> ok, then just merge it, no?
19:04:21 <jamesob> I said I'd review it again and I did. still A++++++ 10/10
19:04:24 <sdaftuar> it only has one ack, i believe, so probably premature
19:04:26 <wumpus> well it needs review first
19:04:48 <sdaftuar> jamesob: thank you!
19:04:57 <wumpus> maybe something for the review club, though, possibly too difficult
19:06:11 <ariard> will give it a try, at least on code changes, not on p2p implications
19:06:21 <wumpus> thanks!
19:06:24 <jonatack> same
19:07:07 <wumpus> anything to discuss about the issues needing concept ACK?
19:08:11 <aj> i think i'll close #16229 in favour of #16060
19:08:13 <gribble> https://github.com/bitcoin/bitcoin/issues/16229 | Standardise deployment handling by ajtowns · Pull Request #16229 · bitcoin/bitcoin · GitHub
19:08:17 <gribble> https://github.com/bitcoin/bitcoin/issues/16060 | Bury bip9 deployments by jnewbery · Pull Request #16060 · bitcoin/bitcoin · GitHub
19:08:52 <aj> doesn't #14895 already have conceptacks?
19:08:53 <gribble> https://github.com/bitcoin/bitcoin/issues/14895 | Package relay design questions · Issue #14895 · bitcoin/bitcoin · GitHub
19:09:03 <jnewbery> I've just pushed to 16060. It's ready for rereview
19:09:10 <jnewbery> (thanks for the review, aj!)
19:09:34 <wumpus> aj: yes, maybe for the best, having two competing PRs open is usually not very productive
19:09:41 <achow101> It seems like #16341 has Concept ACKs, so maybe move it to blockers? At least isn't labeled with "needs conceptual review" anymore
19:09:44 <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
19:10:03 <wumpus> I think 7 blockers is enough :)
19:10:33 <wumpus> otoh doesn't seem you have one yet there
19:10:45 <achow101> it got merged :)
19:11:27 <wumpus> ok moving it then
19:11:29 <provoostenator> I'd love to build on top of The Box, so not opposed to making it high prio.
19:12:06 <wumpus> at least #16363 is almost, or entirely ready for merge, I think
19:12:09 <gribble> https://github.com/bitcoin/bitcoin/issues/16363 | test: Add test for BIP30 duplicate tx by MarcoFalke · Pull Request #16363 · bitcoin/bitcoin · GitHub
19:13:20 <wumpus> #topic 0.18.1?
19:13:43 <wumpus> rc1 was uploaded almost a week ago, do we have any reports of issues?
19:13:45 <MarcoFalke> I haven't heard of any issues with 18.1rc1
19:13:49 <wumpus> me neither
19:14:05 <MarcoFalke> #action ship it
19:14:38 <wumpus> there's also no bugfixes that need to make it in hard enough to warrant another rc, AFAIK
19:14:45 <wumpus> yess
19:14:46 <achow101> haven't heard anything, but that may be a symptom of no one using it
19:14:56 <wumpus> you never know that...
19:15:55 <wumpus> waiting longer will not likely get more people to test it
19:16:09 <achow101> ship it!
19:16:46 <wumpus> clear!
19:17:03 <wumpus> #topic is transaction.nVersion signed or unsigned? (BlueMatt)
19:17:13 <BlueMatt> #16513
19:17:15 <gribble> https://github.com/bitcoin/bitcoin/issues/16513 | [RFC] Switch CTransaction::nVersion to an unsigned integer by TheBlueMatt · Pull Request #16513 · bitcoin/bitcoin · GitHub
19:17:19 <BlueMatt> this came up in rust-bitcoin discussion
19:17:27 <BlueMatt> consens-wise its unsigned, in our code its signed, people are confused
19:17:34 <BlueMatt> concept ack or nack, happy either way
19:17:36 <BlueMatt> just a discussion to have
19:17:39 <achow101> I thought consensus wise it isn't signed
19:17:48 <BlueMatt> indeed, it is unsigned in cnosensus
19:17:51 <BlueMatt> in the code its signed
19:18:08 <sdaftuar> how about we add a comment to think about it if it ever matters?
19:18:18 <wumpus> FWIW, I think it's fairly risky to change the consensus code for no functional change
19:18:19 <MarcoFalke> How can the change even be reviewed? Look at each call site?
19:18:37 <BlueMatt> MarcoFalke: the way I wrote it is to remove nVersion, see every place its accessed, and go read it
19:18:41 <BlueMatt> its....actually not that many
19:18:49 <sipa> one easy way to make sure you have all the call sites is to rename it
19:18:50 <achow101> if our code says it's signed, then doesn't that mean consensus-wise it is signed?
19:18:57 <BlueMatt> but, indeed, I'm happy to take a no, just also kinda wondering if people think libraries should make it signed or unsigned
19:19:11 <BlueMatt> achow101: its casted to unsigned in consensus checks
19:19:13 <sipa> achow101: as in: all call sites either don't care about signedness, or explicitly cast to unsigned before usage
19:19:25 <MarcoFalke> huh, nVersion is still here: https://github.com/bitcoin/bitcoin/pull/16513/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR289
19:19:29 <BlueMatt> do people think this should be signed or unsigned in rust-bitcoin
19:19:29 <achow101> wth
19:19:36 <wumpus> well, other implementations could make it unsigned, if that makes the code easier
19:19:42 <BlueMatt> like, if its unsigned, people get confused reading crap from rpc
19:19:51 <BlueMatt> if its signed, people may misimplement CSV
19:20:32 <sipa> no strong opinion either way; if people want to change it, i think this is fairly easy to review for correctness
19:20:35 <wumpus> rust-bitcoin is not consensus critical, so the amount at stake for an implementation error is somewhat less their
19:20:53 <MarcoFalke> [15:18] <sipa> one easy way to make sure you have all the call sites is to rename it
19:20:54 <BlueMatt> right
19:20:54 <provoostenator> I can confirm nVersion is a source of confusion :-)
19:21:25 <BlueMatt> the background is someone got confused parsing rpc output or something similar, and wants to change the unsigned nVersion to signed
19:22:06 <provoostenator> 1 is the same signed and unsigned?
19:22:14 <wumpus> that only gets the direct usage sites though, it's somewhat harder to analyse where the value ends up indirectly
19:22:15 <BlueMatt> anyway, enough discussion, its somewhat minor...in 5 seconds everyone say their prefernce and we'll flip a weighted coin based on the response and close or not :p
19:22:32 <MarcoFalke> +0.001
19:23:01 <aj> MarcoFalke: you're voting for signed floating point? :)
19:23:17 <BlueMatt> aj: no, signed Decimal
19:23:42 <elichai2> BlueMatt: make it signed and cast when pass to libconsensus? lol
19:24:30 <sdaftuar> how about we cast to unsigned in the rpc handler
19:24:37 <wumpus> ^^
19:24:37 <sdaftuar> and then stop thinking about it for a long time
19:24:47 <BlueMatt> sounds fine to me too
19:24:54 <sipa> sgtm
19:24:56 <wumpus> exactly, if it confuses people in RPC, then report it differently in RPC :)
19:24:58 <BlueMatt> cool, next topi
19:25:00 <MarcoFalke> sdaftuar: Doeparsers decode 32bits to signed?
19:25:00 <BlueMatt> c
19:25:17 <MarcoFalke> Oh, json doesn't use bits
19:25:20 <wumpus> #topic any contributors affected by GH blocking access/functionality in certain countries? (fanquake)
19:25:52 <BlueMatt> well whats the eta until auzzies cant work on core cause their govt forces them ato add backdoors and gh kicks them out?
19:26:19 <BlueMatt> do we need to get fanquake a freedom visa?
19:26:27 <achow101> and aj
19:26:33 <BlueMatt> right
19:26:34 <moneyball> Nat tweeted saying it only affects private repos. I'm not sure if that matches reality or not.
19:26:35 <wumpus> from what I've heard, currently it shouldn't be a problem because Iran/Crimea/etc is only locked out of their private repos
19:26:38 <provoostenator> BlueMatt: Microsoft gladly added a backdoor to Skype for China, so I don't think they'll kick anyone out.
19:26:51 <wumpus> but in the longer run it's not clear what will happen
19:27:02 <provoostenator> Does Github allow Tor?
19:27:03 <achow101> https://help.github.com/en/articles/github-and-trade-controls
19:27:09 <sipa> yeah, it doesn't seem open projects are affected right now
19:27:11 <elichai2> I heard they're locked out of *their accounts* and becuase of that they can't see their private repos
19:27:12 <sipa> but it's a scary precedent
19:27:18 <sipa> elichai2: that was fixed, afaik
19:27:25 <moneyball> sipa: agree
19:27:40 <wumpus> it's definitely scary and it'd be absurd to have an international open source project be affected by one country's strange psychosis
19:27:46 <achow101> wumpus: I heard some reports that people were locked out of their accounts entirely
19:27:51 <BlueMatt> wumpus: BUT FREEDOMZ
19:28:08 <emilengler> I have a VPN, I can look if I can connect to a Crimea server if there are one
19:28:19 <emilengler> Or any other servers/locations which are blocked by the US
19:28:24 <sipa> achow101: read this thread: https://twitter.com/Hamed/status/1154268514074660864
19:28:25 <emilengler> Is there a list or something
19:28:28 <wumpus> emilengler: DO NOT log into your account from there
19:28:44 <achow101> emilengler: I think it only effects accounts where they believe you a resident of a sanctioned country, not if you are connecting from one
19:28:53 <emzy> There is a git mirror for Bitcoin in the tor network.
19:29:03 <emilengler> wumpus: Sure, I wanted to create a trash account for it
19:29:09 <wumpus> emilengler: okay :)
19:29:14 <sipa> achow101: in particular, private repos can still be made public if their account is restricted
19:29:25 <jonatack> IIUC people can be blocked based on presumed citizenship e.g. the wrong passport living in London can be frozen out of their account
19:30:06 <sipa> everyone, please read this first to the end: https://twitter.com/Hamed/status/1154268514074660864
19:30:26 <emilengler> Has someone a list of the countries who are blocked?
19:30:30 <emilengler> Or regions
19:30:37 <wumpus> emzy: right, getting the source code isn't hard, but losing access to PRs/issues etc to be able to contribute back would be bad
19:30:42 <achow101> emilengler: it's in the help.github article I linked earlier
19:30:52 <achow101> emilengler: Crimea, Cuba, Iran, North Korea, and Syria.
19:30:56 <sipa> afaict, the only thing we should be discussing here now is whether we should prioritize figuring out in what ways our processes are dependent on github
19:31:15 <wumpus> yes
19:31:42 <emzy> right
19:32:16 <dongcarl> I know that a few of the depends packages depend on other GitHub repos
19:32:29 <wumpus> I think our process is already kind of detached from github in a way: we dont use it for merging, a lot of us prefer reviewing locally, the ACK system could work everywhere, etc
19:32:47 <sipa> yeah, i think if worst comes to worst, we can spin up something else
19:32:56 <sipa> it'd be annoying, but not devastating
19:33:12 <achow101> the annoying part is losing the issues and PRs
19:33:23 <wumpus> the good part you mean
19:33:25 <wumpus> *ducks*
19:33:27 <sdaftuar> lol
19:33:30 <moneyball> ha
19:33:30 <meshcollider> Lol
19:33:34 <wumpus> just file the ones that matter again :p
19:33:55 <elichai2> unless we think of this ahead of time and start slowly duplicating all of github into a private gitlab (we could "fake" the PRs and issues to be the same as in github if it's an open source platform)
19:33:59 <moneyball> can't we just export issues/PR data on a regular basis as backup?
19:34:03 <wumpus> seriously though, maybe there's some way to import gh metadata
19:34:06 <BlueMatt> I presume as long as we (a) have very good backups of the entire pr/issue/everything context and (b) are willing to switch upon seeing any actual real-world issues for people, then I think we dont need to do anything today, no?
19:34:08 <wumpus> moneyball: we do!
19:34:17 <moneyball> oh nice!
19:34:35 <MarcoFalke> So people from those countries can create pull requests and issues, right?
19:34:43 <wumpus> moneyball: it's backed up to a github repo though, so be sure to pull it regularly :) https://github.com/zw/bitcoin-gh-meta
19:34:51 <dongcarl> Is there a GitHub<->GitLab mirroring tool that keeps them in sync?
19:34:54 <sipa> MarcoFalke: afaict, the only thing is access to their private repos
19:35:27 <achow101> MarcoFalke: seems like it
19:35:33 <phantomcircuit> BlueMatt, visa doesn't change an australian citizens obligation to backdoor stuff for their government
19:35:36 <emilengler> GitLab can import github issues/pr as well
19:35:42 <phantomcircuit> just cant trust those convicts anymore
19:36:14 <wumpus> hehe
19:36:23 <wumpus> phantomcircuit: discrimination!
19:36:57 <wumpus> anyhow, not much to say on this topic I think, no one from those countries spoke up at least
19:37:12 <BlueMatt> ehh, if openbsd can discriminate against us citizens for the same reason, I think we're allowed to discriminate based on a convict colony
19:37:13 <wumpus> (if you are from those countries feel free to PM me)
19:37:49 <sipa> BlueMatt: you know the difference between a cup of yoghurt and australia?
19:37:57 <achow101> oh no
19:38:10 <dongcarl> something something culture?
19:38:48 <wumpus> that leaves one topic "bitcoin-dev mailing list moderation", which I'm kind of scared of and jonasschnelli isn't here anyway
19:39:02 <sipa> is warren or kanzure here?
19:39:02 <phantomcircuit> wumpus, in all seriousness the first part is actually true, the obligation is of citizens and residents, not merely of people in australia
19:39:12 <achow101> I think it was just a question about whether we had enough mailing list moderators
19:39:16 <emilengler> How does the list moderation works? It is slow that's the only thing I know..
19:39:30 <wumpus> "I propose that we add more moderators to shorten the moderation lag which has been between >24h, thus makes debates cumbersome"
19:39:44 <sipa> arguably the ML isn't really on topic here, as it's not a bitcoin core thing
19:39:47 <wumpus> "Eventually there are some volunteers for moderation, ideally neutral people"
19:39:57 <wumpus> yea exactly...
19:40:04 <sipa> plus it doesn't seem that any of the list operators are here now
19:40:13 <MarcoFalke> Could the mailing list be used for this discussion?
19:40:20 <sipa> yes
19:40:32 <MarcoFalke> ok, endmeeting :)
19:40:36 <wumpus> #endmeeting