19:00:30 <wumpus> #startmeeting
19:00:30 <lightningbot> Meeting started Thu Dec 14 19:00:30 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:30 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:31 <maaku> opposite. the sigops are picked up by static analysis of the outer script, which if it only contains a NOP4 (MBV) and stack oeprations is 0
19:00:37 <jtimon> hi
19:00:54 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
19:00:54 <jonasschnelli> hi
19:00:56 <achow101> hi
19:01:02 <kanzure> hi.
19:01:06 <cfields> hi
19:01:19 <wumpus> #topic high priority for review
19:01:23 <wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
19:01:25 <Provoostenator> hi
19:01:37 <sipa> hi
19:01:41 <luke-jr> multiwallet gui can be added back in
19:01:56 <BlueMatt> #11639
19:01:58 <gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
19:02:04 <wumpus> I think we managed to merge two high-priority PRs this week, woohoo
19:02:15 <sipa> woohoo
19:02:32 <wumpus> now all we really want is #11403 :)
19:02:39 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
19:02:40 <jnewbery> hi
19:02:48 <jonasschnelli> Added #11383 to the high prio project
19:02:50 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
19:03:04 <cfields> should've named it "trivial SegWit wallet support". Those get merged quicker :)
19:03:13 <jonasschnelli> hah
19:03:14 <wumpus> segwit wallet before multiwallet please :)
19:03:20 <promag> hi
19:03:40 <jonasschnelli> Yes. 11383 needs more reviews first
19:03:59 <achow101> I'll actually start working on #10367 again after finals this week
19:04:01 <gribble> https://github.com/bitcoin/bitcoin/issues/10367 | [test] Test abortrescan command. by kallewoof · Pull Request #10367 · bitcoin/bitcoin · GitHub
19:04:09 <achow101> *#10637
19:04:13 <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
19:04:33 <BlueMatt> we're getting really close on #11281 which is also high-prio and I think also #10387
19:04:36 <BlueMatt> so thats nice
19:04:36 <wumpus> added BlueMatt #11639
19:04:36 <gribble> https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
19:04:38 <gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Eventually connect to NODE_NETWORK_LIMITED peers by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
19:04:40 <gribble> https://github.com/bitcoin/bitcoin/issues/11639 | Rewrite the interface between validation and net_processing wrt DoS by TheBlueMatt · Pull Request #11639 · bitcoin/bitcoin · GitHub
19:05:21 <wumpus> yep, getting there
19:05:24 <BlueMatt> ryanofsky: asked for #11687
19:05:26 <gribble> https://github.com/bitcoin/bitcoin/issues/11687 | External wallet files by ryanofsky · Pull Request #11687 · bitcoin/bitcoin · GitHub
19:06:13 <wumpus> added
19:06:21 <wumpus> but let's focus on segwit wallet please
19:06:41 <BlueMatt> yea, I mean there's also like 3 or 4 bugs on master that need fixing for 0.16...
19:06:53 <wumpus> all the other things are nice but what people really want at this point is segwit wallet
19:07:28 <wumpus> I get bothered a lot about it so I'm happy to pass it on :p
19:07:45 <wumpus> other topics?
19:08:23 * BlueMatt notes that things needed for 0.16 are at least #11888 (does not yet have pr), #11822 (pr 11824) and #11512
19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/11888 | Prevent Opening Wallets Simultaneously in Two Instances · Issue #11888 · bitcoin/bitcoin · GitHub
19:08:24 <gribble> https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
19:08:26 <promag> will sipa include Qt changes in #11403?
19:08:26 <gribble> https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
19:08:31 <wumpus> #action merge segwit wallet
19:08:32 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
19:08:54 <jnewbery> Quick topic: can I shill for the Coredev tech days in New York, March 5th-7th?
19:09:07 <wumpus> #topic coredev tech announcement
19:09:09 <BlueMatt> jnewbery: I think you just did
19:09:15 <cfields> woohoo!
19:09:50 <jnewbery> I've sent invites to everyone I think contributes regularly to Bitcoin Core or lightning implementations. If you think you should have got an invite and haven't, plese message me
19:09:52 <BlueMatt> put it on your calendar! week after fc so book your flights back via ny!
19:09:59 <jonasschnelli> I think I should merge https://github.com/coredev-tech/coredev-dot-tech/pull/1
19:10:05 <achow101> is it up on coredev.tech yet?
19:10:13 <jnewbery> jonasschnelli: yes please!
19:10:13 <jonasschnelli> jnewbery: have you invited promag?
19:10:32 <jnewbery> jonasschnelli: yes
19:11:19 <promag> yes he did
19:11:20 <jnewbery> that's all my shilling :)
19:11:35 <luke-jr> proposed topic: status of meeting summaries on the website
19:11:45 <jonasschnelli> Thanks for organising jnewbery! To bad I can't attend....
19:12:20 <maaku> jnewbery: New York is a big place. Where is it?
19:12:20 <wumpus> BlueMatt: seems they were already tagged for 0.16 except #11824
19:12:22 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
19:12:32 <sipa> that needs tagging
19:12:32 <jnewbery> sorry jonas :(
19:12:34 <jonasschnelli> jnewbery: keep the location discolued
19:12:38 <luke-jr> maaku: "We're still working on final confirmation for the location, but it's almost certain to be in Lower Manhattan, close to The Battery."
19:12:39 <jonasschnelli> *disclosed
19:12:42 <luke-jr> oops
19:12:43 <wumpus> better to send the address in private
19:12:53 <BlueMatt> wumpus: yes, I'm aware, I was pointing out that those three are issues which fix current master bugs ie are blocking 0.16, unlike much of the 0.16 tagged things
19:12:58 <maaku> "Lower Manhatten, close to The Battery" was all I was looking for
19:12:58 <luke-jr> hopefully that wasn't too much detail
19:13:16 <wumpus> BlueMatt: yeah if there's things tagged 0.16 that shouldn't be, let me know
19:13:22 <wumpus> BlueMatt: I'll bump them to 0.17
19:13:34 <BlueMatt> "whatever makes it in", right? :p
19:14:03 <instagibbs> oh meeting, hi
19:14:09 <wumpus> yes, but if it shouldn't hold up the release it shouldn't really be tagged w/  specific release
19:14:21 <jtimon> so after #11403 gets merged, what's the timeline for "whatever makes it in" ?
19:14:27 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
19:14:30 <luke-jr> wumpus: then why tag anything? :p
19:14:59 <BlueMatt> wumpus: heh, ok, so lets see, untag 7664, 7729, 7949, 7955, 8501, 9502, 9728....yea, pretty much everything there
19:15:00 <wumpus> after 11403 makes it in we should go to bugfixing only
19:15:14 <luke-jr> even Segwit wallet is a "early release trigger", not a blocker ;)
19:15:19 <jtimon> wumpus: I see
19:15:31 <BlueMatt> most 0.16-tagged things really dont need a tag
19:15:35 <sipa> wumpus: i guess that means we shouldn't have tags for future releases
19:15:42 <sipa> only for backport branches
19:15:54 <BlueMatt> we should just have a "fixes current master bug" tag which has to be cleared for each release
19:15:54 <wumpus> sipa: unless they're bugfixes that really need to get in
19:16:05 <BlueMatt> or i guess stop tagging things that dont fit into that category
19:16:08 <jonasschnelli> Mabe a tag for "aims for next release"?
19:16:13 <wumpus> well, github has milestones, not 'current master'
19:16:23 <BlueMatt> jonasschnelli: doesnt everything aim for next release?
19:16:25 <wumpus> at least now they will stick which is useful for historical reference
19:16:29 <BlueMatt> i mean occasionally not, but its rare
19:16:38 <jonasschnelli> BlueMatt: that is a good questions... or "candidate for next release"?
19:17:02 <wumpus> the 'future' milestone is for unlikely things that need a lot more work
19:17:18 <wumpus> so probably not next release
19:18:03 <gmaxwell> release candidate on tuesday then?
19:18:05 <sipa> wumpus: perhaps a tag "release blocker" rather than a spdcific version milestone is better for those?
19:18:05 <jonasschnelli> Usually agile development works with "priorities"..
19:18:05 <luke-jr> jonasschnelli: everything is a candidate if it gets enough review ;p
19:18:17 <wumpus> sipa: I prefer a milestone, we have too many tags already
19:18:20 <sipa> ok
19:18:23 <wumpus> sipa: at least this is displayed in a different place
19:18:39 <luke-jr> jonasschnelli: that assumes someone gets to decide priorities for other people
19:18:40 <sipa> right
19:18:42 <wumpus> ok, any real topics?
19:18:56 <jonasschnelli> luke-jr: Yes. Agree. It's kinda impossible
19:19:04 <wumpus> luke-jr: we have 'high priority' which we already discuss every week
19:19:11 <wumpus> there's no point in other priorities really
19:19:12 <luke-jr> [19:11:35] <luke-jr> proposed topic: status of meeting summaries on the website
19:19:25 <luke-jr> wumpus: sure, just pointing out it has its limits
19:19:28 <wumpus> #topic meeting summaries
19:19:32 <gmaxwell> I've been seeing highish connection counts, appears to be organic.  Non-listening nodes appear to have grown a lot in the last three months.
19:19:51 <achow101> luke-jr: what about the meeting summaries
19:19:58 <gmaxwell> Who called this meeting?
19:20:40 <sipa> ?
19:20:45 <luke-jr> I don't actually know what's up with meeting summaries, but the last one was 2 months ago (with a huge gap before that), and people are wondering
19:20:55 <achow101> TheSadFace is the person I got to write them
19:21:03 <achow101> he's been doing them slowly
19:21:06 <BlueMatt> https://github.com/bitcoin-core/bitcoincore.org/pulls
19:21:14 <BlueMatt> I mean there are ones sitting there ready to merge
19:21:18 <BlueMatt> so...that sounds like a first step
19:21:37 <TheSadFace> Hello everyone, yeah sorry about how slow it's going... After finals I plan to catch up to the present time
19:21:44 <achow101> the last few weeks have been slightly busy because of exams, so meeting notes haven't really gotten written. but hopefully a bunch will be written in the next few weeks
19:21:45 <wumpus> oh right I'm allowed to merge things on the bitcoincore.org site now
19:21:48 <wumpus> :D
19:22:01 <BlueMatt> lol after you broke the site!
19:22:10 <luke-jr> ok, so basically it's taken care of, just a matter of time
19:22:14 <achow101> luke-jr: yes
19:22:30 <TheSadFace> luke-jr: Yeah just had a crazy last bit of the semester
19:22:31 <wumpus> well the site was still working :)
19:22:36 <Provoostenator> I think just posting the chat log quickly after the meeting is better than nothing.
19:22:47 <sipa> TheSadFace: very happy that someone's doing that
19:22:49 <wumpus> Provoostenator: the bot uploads the chat log
19:22:53 <sipa> even if it takes a while
19:23:14 <wumpus> e.g. http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html for last meeting
19:23:16 <Provoostenator> But those don't show up here: https://bitcoincore.org/en/meetings/
19:23:25 <TheSadFace> sipa: Thanks!
19:23:34 <Provoostenator> For the RSS folks out there...
19:23:42 <wumpus> TheSadFace: yes, thanks a lot
19:23:55 <luke-jr> Provoostenator: wouldn't that make RSS more complex? if it shows up with the log, but then the summary added later.,.
19:23:56 <achow101> Provoostenator: "To view more recent logs, all meeting logs and raw minutes can be found here."
19:24:00 <bitcoin-git> [13bitcoin] 15instagibbs opened pull request #11900: [policy] simplify CheckMinimalPush checks, add safety assert (06master...06checkminimal) 02https://github.com/bitcoin/bitcoin/pull/11900
19:24:02 <achow101> here links to http://www.erisian.com.au/meetbot/bitcoin-core-dev/
19:24:05 <Provoostenator> It might be better to just always generate a post on /meetings, edit the post later.
19:24:26 <luke-jr> I don't personally use RSS, but I would imagine it would be better if the post only showed when the summary is done
19:24:40 <luke-jr> otherwise people will try to read, see no summary, and forget to go back later
19:25:00 <Provoostenator> True, maybe have a second RSS feed with just the logs?
19:25:07 <Provoostenator> For people who want them fast.
19:25:20 <achow101> also, who owns the meetbot and the site where all of the meeting logs and stuff go?
19:25:26 <wumpus> aj does
19:25:29 <luke-jr> why not they just connect to the webchat? :P
19:25:33 * aj waves
19:25:40 <MarcoFalke> Provoostenator: Scroll back on botbot?
19:26:38 <cfields> very quick topic suggestion: toolchain builder progress
19:26:50 <wumpus> #topic toolchain builder progress
19:26:50 <luke-jr> actually, maybe we should link the webchat on the page?
19:27:04 <wumpus> is a read-only link to the webchat possible?
19:27:06 <cfields> i'm knee-deep in compiler builds. slowly taking shape. that is all :)
19:27:09 <BlueMatt> pr in time for 0.16 to replace gitian for 0.16, right?
19:27:09 <wumpus> if not, please don't do it
19:27:22 <cfields> heh
19:27:25 <achow101> wumpus: could link to botbot which is read only
19:27:29 <wumpus> achow101: +1
19:27:43 <luke-jr> wait, replacing gitian? :/
19:28:17 <cfields> first step will just be a toolchain that we use in gitian rather than whatever ubuntu ships
19:28:40 <cfields> that will mean that we can very easily use whatever compilers/versions we want for gitian/travis
19:28:45 <wumpus> that would help in cases like we have with ubuntu 16.04, where the mingw64 compiler is completely broken
19:28:57 <cfields> right
19:29:09 <sipa> wow, even in travis?
19:29:19 <Chris_Stewart_5> cfields: nice!
19:29:42 <cfields> after that, I'd like to discuss something more long-term. But replacing Gitian would still be a long way away
19:29:53 <luke-jr> within gitian sgtm, although hopefully only as-needed for Travis since it's already slow
19:29:55 <BlueMatt> #link http://vxer.org/lib/pdf/Reflections%20on%20Trusting%20Trust.pdf
19:30:16 <gmaxwell> luke-jr: the would it be slow in travis? it would get cached.
19:30:34 <cfields> luke-jr: the idea would be to host our toolchains somewhere, so that travis just pulls them like anything else
19:30:40 <cfields> right
19:30:57 <BlueMatt> will this make bitcoin core the first open source project to do releases using the 1984-suggested toolchain system? =D
19:31:18 <sipa> BlueMatt: we don't ship with our own CPU microcode yet :(
19:31:22 <cfields> gmaxwell: also, the clang/gcc thing is kinda moot. We'll want to build them with each-other anyway, so going clang-only wouldn't make things any easier
19:31:28 <wumpus> 1984 toolchain system doesn't have a good ring to it
19:31:29 <luke-jr> sipa: yet.
19:31:29 <BlueMatt> sipa: lol, ok, fair
19:31:45 <BlueMatt> wumpus: all the better to spy on you with
19:31:52 <wumpus> BlueMatt: :D
19:32:39 <achow101> is the goal to eventually get rid of gitian?
19:32:44 <gmaxwell> BlueMatt: IIRC diverse double compilation was not suggested by KT.
19:32:53 <cfields> BlueMatt: heh yes. The initial toolchain will likely take ages and ages to build. But after it's done once, updates are quick and easy
19:33:02 <luke-jr> achow101: I would hope not. Gitian is handy.
19:33:03 <wumpus> good to hear you're making progress cfields
19:33:07 <BlueMatt> gmaxwell: oh? how did I get that confused...who suggested it?
19:33:24 <luke-jr> achow101: at least not unless there's an alternative that isn't Bitcoin/Core-specific
19:33:28 <achow101> luke-jr: same, although it does need a bit of fixing I think
19:33:35 <gmaxwell> KT made the problem statement, I don't think DDC was suggested until david wheeler's thesis in the mid-oughts.
19:33:43 <BlueMatt> ah, ok
19:34:07 <wumpus> I think abstractly gitian as a launcher for deterministic containers that build is a good concept
19:34:24 <luke-jr> (and also not distro-specific ;)
19:35:14 <jtimon> what would be the advantageof getting rid of gitian?
19:35:16 <wumpus> it does have too much overhead (runnig a full ubuntu VM inside, which upgrades everyt ime), and is pretty hard to initially set up
19:35:52 <cfields> wumpus: agreed that the concept is good. It's just got lots of rough edges
19:36:00 <wumpus> the advantage is not in getting rid in it, but building something better
19:36:08 <luke-jr> wumpus: even making the updates persistent might be an improvement there
19:36:10 <achow101> I think that setting up a new gitian environment has been slowly getting harder
19:36:29 <cfields> luke-jr: with the toolchain stuff done, we won't need to do the updates anymore
19:36:40 <cfields> it'll be distro-agnostic
19:36:47 <wumpus> cfields: what about the windows installer stuff
19:37:04 <luke-jr> building NSIS should be trivial I'd think
19:37:06 <wumpus> cfields: I mean NSIS - we should probably build that too, then
19:37:12 <wumpus> oh no building NSIS is not trivial :(
19:37:13 <luke-jr> Gentoo has an ebuild, so just port that
19:37:29 <cfields> wumpus: right, i haven't gotten that far yet. But I suspect we'll just need to suck it up and build it
19:37:33 <wumpus> the problem is that it's a mix of cross compield windows code and native code, and has a sucky build system
19:38:13 <wumpus> yes
19:38:18 <luke-jr> correction: Gentoo *used* to have an ebuild :x
19:38:19 <cfields> have no alternatives cropped up in the last ~10 years?
19:38:27 <wumpus> using the one in 12.04 isn't acceptable anymore at least
19:38:33 <wumpus> eh, 14.04
19:38:52 <luke-jr> I have a copy of the last ebuild in my overlay, it's only 111 lines
19:39:17 <cfields> luke-jr: that assumes you already have scons built and working
19:39:22 <wumpus> windows has a native installer db system that would be preferable to use
19:39:33 <wumpus> but porting the installer over to that would be... work
19:39:40 <luke-jr> yes :p
19:40:43 <cfields> well we can always take the toolchain stuff but still rely on a few bits and pieces from ubuntu until we get it all worked out
19:40:49 <wumpus> sure
19:41:05 <luke-jr> doesn't the toolchain stuff depend on a native autotools/make anyway?
19:41:10 <luke-jr> what harm in using native scons?
19:41:20 <wumpus> ah yes window's own system is msi
19:41:31 <cfields> luke-jr: depends how deep we want to go
19:41:51 <wumpus> thinking of it, might not be that easy to make those in cross-build
19:41:55 <maaku> wumpus: building a gitian vm can be easily scriptable. I had vagrant scripts for doing this since 2013, but weren't upstreamed out of lack of interest
19:42:20 <wumpus> maaku: there is a script for that now
19:42:21 <maaku> maintaining a script to construct a gitian vm solves the accessibilty problem (and gets more people using gitian)
19:42:40 <cfields> wumpus: msi's? IIRC gnu ld can target them, at least
19:43:02 <sipa> i also have brief libsecp256k1 update
19:43:07 <wumpus> contrib/gitian-build.sh
19:43:22 <wumpus> cfields: ok, so if we can get someone to make a msi installer for us, we could use that instead
19:43:22 <achow101> maaku: unfortunately sometimes gitian doesn't get setup even with a script
19:43:33 <achow101> it might fail at some random point in the process for some unknown reason
19:43:39 <cfields> wumpus: sure, something to look into
19:43:42 <wumpus> the problem is that it has a lot to accomodate, because setting up the kvm/lxc is slightly different on differnt systems
19:44:04 <wumpus> anyhow we'll figure it out, time for next topic
19:44:04 <wumpus> #topic libsecp256k1 update (sipa)
19:44:11 <luke-jr> doesn't KVM just work on all modern systems?
19:44:24 <wumpus> luke-jr: not inside VMs
19:44:27 <cfields> luke-jr: nested is a pain
19:44:29 <sipa> in the past week we've finally merged multi-multiplication support in libsecp256k1: https://github.com/bitcoin-core/secp256k1/pull/486
19:44:38 <maaku> wumpus: which is why you outsource the vm maintenance to an existing cross-platform vm management tool, like vagrant, and then do lxc-gitian within that vm
19:44:56 <jonasschnelli> sipa; what are the benefits?
19:45:04 <achow101> sipa: that's the pippenger thing?
19:45:05 <sipa> this is the low-level functionality for efficiently computing a*A + b*B + c*C + ..., with a,b,c scalars and A,B,C points
19:45:20 <sipa> it is not exposed currently (except for tests and benchmarks)
19:45:22 <cfields> ah, nice :)
19:45:34 <sipa> but it's the basis for efficiently building signature aggregation, batch validation, bulletproofs, ...
19:45:47 <jonasschnelli> nice
19:46:14 <wumpus> maaku: ok, maybe discuss with cfields
19:46:37 <wumpus> sipa: congrats!
19:46:50 <sipa> it doesn't currently affect anything in bitcoin, but i thought about mentioning it here as it's under the bitcoin-core repo and all that
19:47:20 <cfields> sipa: how do you picture that working with threading?
19:47:36 <cfields> batches of batches?
19:47:50 <sipa> cfields: split up the problem in N parts, run each part on one thread, and add the results together
19:47:59 <cfields> (I realize that's still a ways out)
19:48:03 <cfields> roger
19:48:19 <sipa> there are algorithms to actually be more efficient than that, but they need high communication across threads
19:48:24 <sipa> which may or may not be worth it
19:48:35 <sipa> (and be much harder to do API-wise)
19:48:56 <wumpus> one step at a time
19:49:04 <sipa> anyway, thanks to andytoshi and nickler, and peterdettman who all contributed optimizations
19:49:46 <michagogo> Sorry I'm late. IIRC a while back I made a gitian-building appliance with video instructions for recreating it from scratch
19:49:47 <cfields> nice work
19:50:00 <sipa> and of course gmaxwell for all imput and discussions :)
19:50:05 <sipa> *input
19:50:27 <achow101> sipa: so what do we need to be able to use this in Bitcoin?
19:50:49 <sipa> achow101: ECDSA can't really take advantage of it in its current form
19:50:51 <michagogo> (Wow, apparently that was over a year ago: https://1drv.ms/f/s!AvCguGMVwWzLgxJPeXdvaQVJ2WJq )
19:50:52 <cfields> a use-case
19:51:17 <BlueMatt> ok, any last-minute topics/
19:51:18 <BlueMatt> ?
19:51:33 <gmaxwell> well I tried to talk about connection slot saturation earlier.
19:51:34 <sipa> achow101: slightly modified ECDSA would permit batch validation, but there's no reason to choose that over some form of Schnorr-based signatures
19:51:37 <maaku> achow101: bitcoin doesn't do multi-generator arithmetic
19:51:57 <maaku> but it's useful for CT/CA
19:52:16 <achow101> oh, ok. cool.
19:52:19 <BlueMatt> gmaxwell: was there much to discuss? thanks for the notice, encourage people to run nodes/increase -maxconnections if possible?
19:52:36 <sipa> </endtopic>
19:52:37 <gmaxwell> We need to start looking into reenabling some kind of port forwarding I think.
19:52:42 <wumpus> so does anyone really get a lot of connections?
19:52:51 <gmaxwell> the number of non-listning nodes as increased by 50% in the last six months.
19:53:03 <wumpus> I have maxconnections at 500 on one node and have never got more than 100
19:53:15 <achow101> wumpus: I have 120 right now
19:53:16 <sipa> i'm at 124 connections
19:53:18 <gmaxwell> wumpus: when I was commenting a day ago I had confirmations of >110 on 6 nodes.
19:53:19 <Provoostenator> Are we sure UDNP works?
19:53:20 <wumpus> on the other node I'm happy to get more than 10
19:53:32 <achow101> Provoostenator: it's currently disabled by default
19:53:45 <sipa> Provoostenator: UPNP?
19:53:47 <gmaxwell> you'll see less if you're in a /16 with many other nodes in it.
19:53:51 <jonasschnelli> does NODE_NETWORK_LIMITED helps in this case?
19:53:58 <sipa> jonasschnelli: perhaps!
19:54:05 <wumpus> well the netherlands has lots of nodes so I've heard :-)
19:54:08 <gmaxwell> probably not much.
19:54:14 <Provoostenator> sipa: that one
19:54:19 <wumpus> they're not *all* mine :p
19:54:55 <gmaxwell> Running short on inbounds is the reasonable and expected outcome from not having automatic port forwarding... it's obviously not critical currently, but I think it's becoming more important.
19:55:12 <achow101> gmaxwell: do you think it would be safe to re-enable UPnP?
19:55:14 <Provoostenator> Maybe BitcoinQT can encourage users to use UPnP with a little nag?
19:55:21 <achow101> IIRC it was disabled because of vulnerabilities
19:55:27 <luke-jr> Provoostenator: better to just make it default then..
19:55:27 <wumpus> any plans for bitcoin over udp? much easier to port fw there
19:55:31 <gmaxwell> achow101: bleh. I dunno. that codebase sucks.
19:55:49 <wumpus> yes, UPNP is not going to be enabled by default again as long as I have a say, I have no confidence in that codebase
19:55:53 <gmaxwell> achow101: but there are other portforwarding protocols that we could support that are simple.
19:56:05 <BlueMatt> I believe wumpus has investigated it the most, sadly :(
19:56:06 <luke-jr> wumpus: what if someone ports it to another UPnP lib? (are there any good ones?)
19:56:42 <Provoostenator> Without UPnP, we could at least show some instructions that they need to perform the port forwarding ritual.
19:56:50 <wumpus> wasn't there a better replacement for upnp gmaxwell?
19:57:07 <luke-jr> other protocols won't help with routers being UPnP..
19:57:11 <gmaxwell> Yes, there are several.
19:57:12 <wumpus> something that didn't rely on variable buffers and xml parsing
19:57:28 <jonasschnelli> Provoostenator: a "connectable" green/read flag and some instruction is probably simple
19:57:32 <gmaxwell> not as widely supported as UPNP but e.g. all apple networking appliances support the one whos name I can't remember.
19:57:43 <cfields> Bonjour?
19:57:45 <gmaxwell> where the protocol is just a trivial struct sent over usp.
19:57:54 <jonasschnelli> Bonjour is mDNS (that is different)
19:57:56 <sipa> DLNA?
19:58:22 <gmaxwell> I'm thinking of NAT-PMP
19:58:23 <Provoostenator> As well as a P2P message like "please try to connect to me", so it's easier to see if the port is open?
19:58:26 <luke-jr> does anyone actually use Apple networking appliances? :/
19:58:28 <sipa> ah yes, that
19:58:53 <wumpus> NAT-PMP is quite common these days, not only in apple
19:58:56 <gmaxwell> luke-jr: yes, though I'm sure they're not the most popular... NAT-PMP has support beyond apple of course.
19:59:05 <Provoostenator> The current instruction says "go to 21 and enter your IP there"
19:59:12 <gmaxwell> I just mentioned apple as a concrete example that it is widely supported.
19:59:13 <luke-jr> would be nice to find a quality library that can do both
19:59:18 <sipa> Provoostenator: ?
19:59:23 <gmaxwell> Provoostenator: wtf? what "the current instructions" say that?
19:59:49 <gmaxwell> luke-jr: there is not really a reason for a library for nat-pmp. You send a dozen byte packet over UDP.
19:59:50 <wumpus> I'd be ok with NAT-PMP on by default
20:00:01 <gmaxwell> And if you want to know your IP you listen for a similarly structured dozen by UDP reply.
20:00:09 <achow101> gmaxwell: I think Provoostenator is talking about https://bitcoin.org/en/full-node#port-forwarding
20:00:23 <wumpus> but no C/C++ xml parser crap again please
20:00:33 <wumpus> we've pretty much dodged a bullet last time
20:00:37 <BlueMatt> achow101: oh ffs, can we get that fixed?
20:00:41 <Provoostenator> (trying to find where I saw that)
20:00:44 <BlueMatt> <dong>
20:00:49 <wumpus> #endmeeting