19:00:51 <wumpus> #startmeeting
19:00:51 <lightningbot> Meeting started Thu Dec  7 19:00:51 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:51 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:52 <instagibbs> yes
19:01:04 <meshcollider> hi
19:01:21 <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:01:26 <jonasschnelli> hi
19:01:38 <cfields> hi
19:01:38 <Provoostenator> hi
19:01:46 <wumpus> #topic high priority for review
19:01:49 <achow101> hi
19:01:55 <wumpus> https://github.com/bitcoin/bitcoin/projects/8
19:02:52 <wumpus> there was lots of review on #11403 this week
19:02:57 <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
19:02:59 <wumpus> but nothing ready for merge yet AFAIK
19:03:13 <kanzure> hi.
19:03:22 <jnewbery> hello
19:03:28 * BlueMatt is working on reviewing it now...lots of "ehh, you should clean this up instead of hacking around it" type things which may get pushed to a new pr, but nothing broken yet
19:03:35 <sipa> hi, only half here
19:03:46 <BlueMatt> re: high prio #11383 should probably be taken off
19:03:49 <gribble> https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
19:03:52 <BlueMatt> cause luke-jr hasnt kept up with it
19:04:08 <wumpus> sipa: which half?
19:04:10 <BlueMatt> jnewbery: promised me he'd rebase #10740
19:04:13 <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
19:04:19 <wumpus> BlueMatt: ok
19:04:47 <instagibbs> will retest segwit wallet/qt pr on top of #11839
19:04:49 <jonasschnelli> I'll try to take over 11383 (we should have this in 0.16)
19:04:49 <gribble> https://github.com/bitcoin/bitcoin/issues/11839 | dont attempt mempool entry for wallet transactions on startup if alr… by instagibbs · Pull Request #11839 · bitcoin/bitcoin · GitHub
19:04:49 <promag> hi
19:05:07 <BlueMatt> oh, yea, 11839 should be tagged 0.16
19:05:10 <BlueMatt> its a trivial fix, I think
19:05:44 <BlueMatt> jonasschnelli: no need to take it over if instagibbs is active on it?
19:05:51 <wumpus> if it's a trival fix it should probably be merged instead of tagged?
19:06:00 <instagibbs> BlueMatt, wrong PR, just looks like he mentioned it i think?
19:06:11 <jonasschnelli> I'm doing the Multiwalltet GUI PR
19:06:13 <instagibbs> that's multiwallet
19:06:20 <BlueMatt> ohoh, yea, wrong #
19:06:27 * BlueMatt suggested an alternative fix for 11839, so thats just pending disucssion of "the right fix"
19:06:32 <BlueMatt> all options are relatively trivial
19:07:13 <BlueMatt> #11824 may be mergeable with another review to fix reindex on master, jamesob indicated his issue was the result of "running wrong build"
19:07:15 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
19:08:10 <achow101> I think #11824 can be merged.
19:08:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
19:08:37 <wumpus> #action merge #11824
19:08:39 <gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
19:08:46 <achow101> I did notice another OOM issue I think, but it looked like to be hard to reproduce and required significant uptime
19:09:23 <BlueMatt> achow101: I failed to find any hidden memory in massif, but I'm still doing runs in it so will look further
19:10:22 <wumpus> do we have a memory leak?
19:11:00 <BlueMatt> I dont (currently) believe so...master will OOM during reindex cause validation runs ahead of validationinterface and memory grows huge, but its not technically a leak cause it will catch up eventually if you have enough memory to do it
19:11:03 <wumpus> I haven't had any OOM crashes FWIW
19:11:04 <BlueMatt> 11824 fixes that
19:11:09 <jonasschnelli> Did also a quick run with my leak tool and some stuff popped up. leveldb, bdb ansd some other things
19:11:31 <jonasschnelli> Will have a closer look soon
19:11:41 <wumpus> oh, only during reindex, I haven't done that recently
19:11:43 <BlueMatt> topics?
19:12:01 <BlueMatt> wumpus: could also happen directly after restart if you've been offline for a month or whatever
19:12:18 <achow101> or during IBD
19:12:25 <wumpus> I think an OOM issue is a pretty serious topic? but other suggestions are welcome of course
19:12:44 <morcos> if anyone objects to my "won't fix" of #11800, speak up now.  will update code comments per ryanofsky suggestion
19:12:46 <gribble> https://github.com/bitcoin/bitcoin/issues/11800 | Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet) · Issue #11800 · bitcoin/bitcoin · GitHub
19:12:50 <BlueMatt> well I think we've at least gotten 97% of it down, several folks looking into the last 3 and it may be a false positive
19:12:51 <Provoostenator> OOM?
19:12:59 <michagogo> Out Of Memory
19:13:13 <achow101> wumpus: the only known OOM right now is fixed by 11824
19:13:18 <BlueMatt> achow101: ibd seems less likely cause time spent downloading blocks is time for wallet to catch up...
19:13:19 <wumpus> achow101: ok
19:13:42 <wumpus> on to morcos' topic
19:13:45 * BlueMatt makes a quick note that, of the high-priority-to-review items, #11363 is very easy to review and has been sitting for a while
19:13:46 <wumpus> #topic Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet)
19:13:47 <gribble> https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
19:14:11 <wumpus> #action review #11363
19:14:14 <gribble> https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
19:14:26 <wumpus> anyone opposing 'wontfix' there?
19:14:43 <jonasschnelli> we should at least know why
19:14:53 <BlueMatt> jonasschnelli: morcos had a writeup on the issue
19:15:00 <jonasschnelli> #?
19:15:00 <cfields> BlueMatt: thanks :)
19:15:06 <BlueMatt> #11800
19:15:06 <morcos> 11800
19:15:07 <gribble> https://github.com/bitcoin/bitcoin/issues/11800 | Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet) · Issue #11800 · bitcoin/bitcoin · GitHub
19:15:07 <wumpus> morcos posted that
19:15:09 <wumpus> right
19:16:09 <wumpus> so the situation is pretty much unique to testnet and extremely unlikley on mainnet
19:16:13 <jonasschnelli> IMO low prio or even "won't fix"
19:16:52 <BlueMatt> yea, I mean I think I'd prefer to not call it "wont fix", but certainly not anything worth spending time on compared to other priorities
19:16:53 <wumpus> I tend to agree, very low priority if it only affects testnet's wildness
19:17:24 <jonasschnelli> what BlueMatt said
19:17:35 <wumpus> we kind of know that the current testnet isn't realistic
19:17:44 <wumpus> a frequent request is a more realistic testnet FWIW
19:18:46 <BlueMatt> suggested topic: testnet4
19:19:01 <midnightmagic> the data in tn3 is fairly valuable on its own. if any tn reset is being considered for a pullreq it would be really nice to effect a high-quality preservation of tn3. like an option or something to put it into archive-mode.
19:19:20 <BlueMatt> you mean as test-cases?
19:19:27 <promag> next topic? btw I would like to have more NACK/ACK on #11826
19:19:28 <gribble> https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
19:19:29 <midnightmagic> as test-cases and historical reference.
19:19:33 <Provoostenator> What about cherry-picking interesting testnet3 transactions?
19:19:56 <wumpus> no tn reset is being considered
19:20:07 <jonasschnelli> That's more regression testing?
19:20:18 <BlueMatt> wumpus: please add comma, or do you mean we're not considering it?
19:20:19 <wumpus> keeping tn3 support is fine
19:20:22 <midnightmagic> okay. sorry, carry on. :)
19:20:51 <wumpus> BlueMatt: huh? yes I mean we're not considering it. Any new testnet would be an addition, I think.
19:21:20 <BlueMatt> I meannn...I guess thats fine? I think I was considering just moving to testnet4
19:21:28 <wumpus> (still not sure where to add the comma)
19:21:48 <BlueMatt> if nothing else testnet3 with a mindiff higher than 1, and to not have a million blocks
19:22:09 <BlueMatt> lots of complaints about even spv sync time in testnet3 cause of so many blocks
19:22:12 <morcos> i vote we do segwit wallet support first
19:22:17 <wumpus> there was some talk of doing a testnet with signed blocks which simulates behavior of the mainnet
19:22:26 <wumpus> morcos: yes, absolutely
19:22:27 <BlueMatt> i mean thats also of interest, yea
19:22:36 <phantomcircuit> huh what im here
19:22:45 <meshcollider> topic suggestion: the various config file PRs
19:22:55 <adiabat> testnet having lots of headers needed for SPV may motivate more efficient header transmission
19:22:59 <meshcollider> e.g. #10996 and #10267
19:23:01 <gribble> https://github.com/bitcoin/bitcoin/issues/10996 | Add per-network config file network.conf by ajtowns · Pull Request #10996 · bitcoin/bitcoin · GitHub
19:23:03 <gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
19:23:08 <wumpus> #topic config file handling
19:24:11 <meshcollider> We have to work out what configurations we should support, e.g. whether -conf should be repeatable, whether we have -includeconf, -netconf and -conf, etc.
19:24:18 <wumpus> so the question is pretty much whether to do per-network config file
19:24:22 <jonasschnelli> IMO the config layers are already complex... not sure if we want to add more
19:24:23 <meshcollider> its getting a bit messy
19:24:25 <wumpus> or -testnet-X and -regtest-X
19:24:38 <jonasschnelli> There are serval levels and multiple files
19:24:49 <wumpus> where X are options like port, walletdir, logfile, which are only useful per network
19:25:37 <wumpus> currently if you define e.g. port or bind in bitcoin.conf you will get collisions when you run both testnet and mainnet on the same machine
19:25:53 <meshcollider> one idea I had was suggested in https://github.com/bitcoin/bitcoin/pull/10996#issuecomment-346189099, basically we default to using root-level bitcoin.conf and network specific network.conf if they exist, but if -conf is specified then we just use that and not the network specific one too
19:26:02 <wumpus> so one potential solution for that was to do per-network config files, but as said that makes things reallly complex
19:26:08 <meshcollider> and then allow -conf to be repeatable?
19:26:11 <wumpus> so an alternative proposal was just to do -regtest-port -testnet-port etc
19:26:26 <jonasschnelli> wumpus: +1
19:26:31 <aj> from 10267, having conf repeatable or includeconf recursive seems hard to implement well; currently it only handles a single additional config file aiui
19:26:32 <wumpus> and I think I like that
19:26:39 <meshcollider> wumpus what about unique addnode's for each network
19:26:47 <wumpus> so bare -port will be only for mainnet
19:26:57 <wumpus> meshcollider: -regtest-addnode -testnet-addnode
19:27:19 <meshcollider> so just allow -regtest or -testnet to be prefixed to any existing arg?
19:27:23 <promag> yes, I think that is pretty simple and clear
19:27:33 <promag> if not set, defaults to?
19:27:43 <wumpus> these can be specified in any config file or on the command line, no difference, no *context sensitivity* like per-network config files
19:27:43 <jonasschnelli> promag: the default :)
19:27:48 <wumpus> yes,the default
19:28:06 <meshcollider> and then still support  #10267 ?
19:28:07 <wumpus> meshcollider: yes
19:28:09 <gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
19:28:18 <wumpus> includeconf is orthogonal
19:28:33 <wumpus> I see no reason why not
19:28:37 <meshcollider> yeah but it would allow -regtest-includeconf=whatever
19:28:39 <promag> jonasschnelli: default of the network right?
19:28:43 <meshcollider> so it could be good :)
19:28:46 <jonasschnelli> promag: yes
19:28:47 <wumpus> it's pretty standard these days to allow including config files from config files for daemons
19:28:55 <morcos> wait, just so i understand, if you run ./bitcoind -regtest , then do you also have to add -regtest- to each of your command line options
19:28:59 <morcos> that would be super annoying
19:29:02 <cfields> an alternative to that would be sections in a config file. and on the cmdline they'd look like namespaces. so, [testnet] port=5. or -testnet::port=5.
19:29:08 <wumpus> almost any program supporting config files supports that in any way
19:29:12 <promag> wumpus: yes, like inherit other config
19:29:14 <morcos> cfields: that soudns way better
19:29:32 <wumpus> cfields: fine with me too
19:29:57 <wumpus> it's just that per-network config files make things too complex, so I'd like to avoid that
19:30:11 <meshcollider> morcos: I guess anything without a prefix would be used no matter what network was chosen
19:30:12 <wumpus> which kind of namespacing whether it's [net]option or -net-option I don't mind much
19:30:16 <cfields> and in time the sections could potentially be broken out an included/inerited. but the simple change seems like a simple enough first step to me.
19:30:45 <wumpus> meshcollider: yeah...
19:30:46 <jonasschnelli> but morcos point is valid. What if you just start use CLI params and switch between networks...
19:30:46 <cfields> simple == simple. nice.
19:30:48 <morcos> seems like it would make a lot of sense to have a single conf file, that has sections : [default] [mainnet] [testnet] [regtest] and you always end up reading default and one of the others
19:30:58 <jonasschnelli> do you need to add/switch the namespace all the times?
19:31:10 <wumpus> morcos: yes
19:31:23 <aj> morcos: +1
19:31:51 <sipa> ok, back
19:32:01 <meshcollider> cool, next topic then :)
19:32:07 <wumpus> yes seems we agree
19:32:12 <promag> #11826
19:32:13 <gribble> https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
19:32:24 <meshcollider> jonasschnelli: what do you mean
19:32:40 <jonasschnelli> meshcollider: solves with the namespaces described by morcos.
19:32:42 <jonasschnelli> *solved
19:33:01 <meshcollider> promag: I like 11826
19:33:01 <wumpus> #topic activity feature
19:33:08 <meshcollider> concept ACK from me
19:33:08 <jnewbery> seems like the namespace model gives you separate conf files for free: just add a -includeconf in your relevant network namespace
19:33:09 <jonasschnelli> Yes. We should have that
19:33:13 <wumpus> I think everyone likes 11826
19:33:28 <jonasschnelli> Bitcoin Core does a lot of things under the hood... and there is no way to see/control that
19:33:29 <promag> I have one problem there
19:33:38 * BlueMatt isnt sure about the use-cases for 11826
19:33:39 <jonasschnelli> An activity window is something should have IMO
19:33:43 <promag> should the activity have a boost::variant<> source?
19:33:45 <BlueMatt> seems like putting the cart before the horse, as it were
19:34:00 <BlueMatt> like, the only things that can go *into* the activity window are things you do from rpc debug window
19:34:00 <promag> or should we have class WalletActivity : Activity ?
19:34:09 <jonasschnelli> BlueMatt: most stuff in there should be read-only...
19:34:15 <promag> BlueMatt: why?
19:34:20 <sipa> promag: seems like an implementation details
19:34:23 <BlueMatt> in that case, building an activity window should probably come after making rescan, etc things that users have access to
19:34:34 <sipa> BlueMatt: reindex-chainstate too
19:34:58 <BlueMatt> isnt reindex-chainstate handled like ibd?
19:35:01 <BlueMatt> (as it should be)/
19:35:05 <sipa> yes, it is
19:35:12 <BlueMatt> (cause we cant get a progress indicator for reindex-chainstate)
19:35:22 <sipa> ?
19:35:50 <BlueMatt> I mean the only progress indicator you can do is the same as ibd
19:36:05 <promag> BlueMatt: in those cases it's an indeterminate progress bar
19:36:16 <jonasschnelli> Maybe we should first fix the rescan GUI "abortness", then continue with the activity window (will take a while)
19:36:40 <jonasschnelli> A single progress bar does certainly limit use cases.
19:36:48 <wumpus> yes
19:36:51 * BlueMatt is just saying, if someone wants to build an activity window, ok, have fun, but I'm not sure where it actually makes all that much sense, cause we dont have many activities that users almost ever do)
19:37:14 <jonasschnelli> BlueMatt: not only the user triggered ones...
19:37:42 <promag> BlueMatt: also, activities could stays on the window even after finished, like a log, or your download history
19:37:53 <BlueMatt> download history?
19:37:59 <sipa> i do agree there are relatively few use cases now, but the concept is useful... and i think eventually we want to be able to do things more concurrently anyway
19:37:59 <BlueMatt> you mean rescan history
19:38:08 <promag> no, I mean browser download history
19:38:08 <jonasschnelli> Yeah.. a mix between Activity and short term log would be possible
19:38:09 <jonasschnelli> but hard to make it right
19:38:16 <promag> it's more friendly than a raw log
19:38:28 <phantomcircuit> BlueMatt, lots of users complain about ibd apparently stalling, something that indicated what was happening would be good
19:38:41 <jonasschnelli> [disappearing message] new block validated \n [disappearing message] new peer 1.1.1.1 connected
19:38:51 <BlueMatt> I mean if I'm a user, I dont really want to see a progress history thing, tbh....either I have all the transactions in my wallet or I dont...
19:39:17 <wumpus> for that, a debug log view would be more useful
19:39:22 <wumpus> let's not conflate ongoing activities with a log
19:39:25 <cfields> :q
19:39:32 <cfields> er, heh
19:39:42 <jonasschnelli> heh... Yes.
19:40:12 <jonasschnelli> previous attempts that are more or less a log where kinda accepted #5896
19:40:14 <gribble> https://github.com/bitcoin/bitcoin/issues/5896 | [Qt][PoC] introduce "core-pulse" by jonasschnelli · Pull Request #5896 · bitcoin/bitcoin · GitHub
19:40:18 <promag> ok, I'll try to keep it simple
19:40:24 <BlueMatt> but, ongoing activities are like....rescan, just rescan, and thats not something you should do all that often...ibd/reindex/sync is a rather separate thing
19:40:46 <BlueMatt> but, anyway, it sounds like I'm the only one who disagrees, so I'm happy to shut up :p
19:40:57 <wumpus> sending a transaction is also an ongoing activity
19:41:13 <wumpus> ideally the GUI would move to do all those things asynchronously instead of in the GUI thread
19:41:17 <BlueMatt> I mean it sounds like y'all want to restructure our entire gui around an activity log...
19:41:18 <achow101> I also don't really see the utility of an activity window. but I don't really care either way
19:41:25 <promag> un/loading wallets too
19:41:34 <wumpus> no, I want to structure the GUI asynchronously
19:41:46 <wumpus> an activity thing would be a nice thing that comes with it
19:41:51 <BlueMatt> sending txn is rather async already, no? I mean you send and then you wait on confirms, maybe with a feebump
19:42:27 <BlueMatt> (at a user level, that is)
19:43:07 <jonasschnelli> Lets promag work on that concept and see where it leads to. It's certenly good to have it around in case we can do more stuff in parallel and have other cases where we want to show progress
19:43:11 <wumpus> the point is that comments are executed in the GUI thread, with the various locks held
19:43:14 <wumpus> commands*
19:43:37 <jonasschnelli> Also it would be useful for IPC (GUI / node detatch)
19:43:40 <instagibbs> probably makes more sense if the wallet is more goal-driven, for now I don't mind the feature
19:43:48 <instagibbs> (re: wallet comments)
19:44:08 <wumpus> which is not a nice user experience
19:44:11 <promag> ok guys, I'll file the PR soon
19:44:54 <wumpus> e.g. what I've noticed is that when it's catching up to the chain, getting the information for coin control hangs the entire GUI for half a minute sometimes
19:45:12 <wumpus> which would be fine if it showed a progress indicator but not if everything just blocks
19:45:28 <Randolf> That would likely cause many users to think it crashed.
19:45:40 <wumpus> well the window manager starts to think that too
19:45:43 <wumpus> and wants to kill it
19:46:10 <jonasschnelli> The GUI synchronousness does sometimes lead to terrible UX.
19:46:12 <Randolf> Yes.  And under the Windows OS, the user sees a message along the lines of "Task not responding" with an option to kill the task.
19:46:52 <wumpus> jonasschnelli: it was always my intent to change that but I just don't get around to it
19:47:05 <jonasschnelli> wumpus: it's also pretty complex
19:47:12 <wumpus> nah, not really complex, just work
19:47:17 <Randolf> So, if the GUI is on a separate thread, then it can always respond to the OS and the user's operations (e.g., open the Help menu, load/save wallets, print reports, etc.) while waiting for updates from the other threads.
19:47:17 <BlueMatt> yea, cs_main-y-ness of gui sucks atm :(
19:47:41 <jonasschnelli> Randolf: we are trying that (ask ryanofsky) :)
19:47:42 <wumpus> Randolf: right
19:47:51 <Randolf> jonasschnelli:  Cool!
19:48:30 <BlueMatt> anyway, more topics in 10 minutes?
19:48:43 <sipa> i have one
19:48:54 <sipa> would a libgmp dependency by acceptable?
19:49:19 <BlueMatt> for....secp? or your muhash stuff?
19:49:32 <Randolf> jonasschnelli:  I've done a lot of Java development, and this is how JFC/Swing and the newer JavaFX handle things.  The use of atomic variables and thread-safe queues becomes pretty important.  Maybe the original GUI for Bitcoin was designed with more development convenience in mind just so that the
19:49:32 <Randolf> project could get completed faster?  I don't consider this to be a bad thing, necessarily, but I'm glad to know that there's an interest in improving this.
19:49:32 <BlueMatt> I mean doesnt secp optionally use it already?
19:49:46 <wumpus> #topic libgmp dependency
19:49:53 <wumpus> libgmp is GPL right?
19:50:03 <sipa> BlueMatt: it does, and there is a small performanc benefit from using it for validation itself
19:50:08 <wumpus> if it's MIT/BSD licensed it's ok with me
19:50:10 <meshcollider> wumpus: yep I think so
19:50:17 <wumpus> but if it's GPL, we have to say no
19:50:18 <sipa> but for UTXO hashes it would be a huge difference
19:50:22 <sipa> i see
19:50:22 <cfields> sipa: i assume you mean a non-optional dep?
19:50:34 <sipa> it's LGPLv3
19:50:44 <sipa> cfields: right
19:50:50 <ryanofsky> Randolf maybe see https://github.com/bitcoin/bitcoin/pull/10244 which separates bitcoin gui code from wallet/node code
19:51:23 <meshcollider> sipa: also uses GPLv2 I think
19:51:27 <wumpus> there's really no other library implementing that?
19:51:30 <Randolf> Thanks ryanofsky.
19:51:40 <wumpus> (which could have a more suitable license)
19:51:49 <sipa> wumpus: specifically, it's for jacobi symbol computation
19:51:50 * BlueMatt personally thinks its fine to ship lgpl stuff, but others likely disagree
19:51:55 <aj> meshcollider: it's user's discretion as to GPLv2+ or LGPLv3+
19:52:05 <cfields> sipa: license aside, it would feel a little backwards to introduce a new dep which may at some point be consensus critical :(
19:52:09 <sipa> which is not impossible to implement ourselves, and probably faster if we do, but it's very nontrivial
19:52:12 <sipa> cfields: it wouldn't be
19:52:39 <sipa> cfields: everything we'd use would be verified
19:52:47 <wumpus> cfields: also agree with that
19:53:01 <wumpus> so apart from using libgmp and implementing it ourselves there are no options?
19:53:14 <sipa> or take the performance hit
19:53:21 <aj> sipa: context is #10434 ?
19:53:23 <gribble> https://github.com/bitcoin/bitcoin/issues/10434 | [WIP] 3072-bit MuHash based hash_serialized by sipa · Pull Request #10434 · bitcoin/bitcoin · GitHub
19:53:45 <sipa> 10434 uses the modular multiplication group approach, which doesn't need this - it's faster but much harder to cache
19:54:37 <sipa> the alternative approach is using EC based rolling hashes, for which using jacobi symbols would be a 2x speedup or so
19:54:49 <sipa> wumpus: so a 3rd option is not implementing EC-based rolling hashes
19:54:50 <promag> out-of-battery o/
19:55:44 <wumpus> also after all the work that was done to lose dependency on openssl for bignums, to introduce dependency on a new arbitrary precision library seems also a reversal to me
19:55:47 <sipa> so i just wanted to bring it up to see what the option were
19:55:48 <BlueMatt> so if we use lgpl gmp as a dep, and then someone wants to ship a bitcoincore-modified binary with all deps static-linked, they'd be screwed?
19:56:11 <sipa> wumpus: to be clear, nothing would be consensus critical (even if rolling hashes were somehow made a consensus rule)
19:56:21 <aj> BlueMatt: lgpl means they'd have to release sources or their .o/.a files
19:57:01 <BlueMatt> yea, ok, i meannnn, probably fine, but that is a real change in effective license of bitcoin core
19:57:10 <morcos> sipa: 2x speedup in what exactly
19:57:29 <morcos> when would those computations happen and what is the base latency
19:57:40 <cfields> sipa: at the risk of going too far off-topic, aren't there curves with potentially quicker and guaranteed O(1) map operations?
19:58:13 <morcos> piont being, perhaps we can punt on the question of libgmp until it becomes clear that optimizing the speed is an important tradeoff to make
19:58:17 <wumpus> good point morcos
19:58:19 <instagibbs> morcos, +1
19:58:27 <sipa> cfields: let's discuss outside of the meeting
19:58:28 <sipa> morcos: updating a rolling hash given a set of UTXOs created and spent
19:58:40 <cfields> ok
19:58:50 <BlueMatt> well meeting over anyway
19:58:57 <gmaxwell> ugh was missing meeting.
19:59:04 <instagibbs> gmaxwell, 2 minutes
19:59:06 <instagibbs> 1 minute
19:59:06 <morcos> right, so how often are we envisioning doing that, does it happen async to everything else, and how long does it take without libgmp
19:59:10 <gmaxwell> why did we start talking about libgmp? :(
19:59:12 <sipa> in an absolutely first implementation, i would expect that that would just affect gettxoutsetinfo or its equivalent that just computes the hash from the UTXO set from scratch
19:59:18 <BlueMatt> gmaxwell: blame sipa
19:59:41 <gmaxwell> sipa: we do not want gmp as part of bitcoin's consensus critical paths,  totally independently of using it as a dependency.
19:59:46 <sipa> $ git blame sipa
19:59:46 <sipa> fatal: cannot stat path 'sipa': No such file or directory
19:59:50 <BlueMatt> yes, that point was made
19:59:56 <sipa> gmaxwell: absolutely
20:00:01 <sipa> no intention of changing that
20:00:26 <wumpus> #endmeeting