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