--- Day changed Tue Jul 11 2017 00:03 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 00:06 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 00:11 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 00:13 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 00:16 -!- Meghan [~Meghan@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection] 00:23 < wumpus> right, some of the options support host lookup as of master, but rpcallowip certainly doesn't 00:24 < wumpus> (e.g. #9774) 00:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9774 | Enable host lookups for -proxy and -onion parameters by jmcorgan · Pull Request #9774 · bitcoin/bitcoin · GitHub 00:24 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 00:26 < wumpus> oh yes, inv rate looks a lot more calm recently 00:28 < gmaxwell> the changes for inv batching and timing make it basically constant. 00:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 00:38 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 00:39 < bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/9edda0c5f5f2...21ed30a314cf 00:39 < bitcoin-git> bitcoin/master ff6a834 Matt Corallo: Use TestingSetup to DRY qt rpcnestedtests 00:39 < bitcoin-git> bitcoin/master 3a19fed Matt Corallo: Make ValidationInterface signals-type-agnostic... 00:39 < bitcoin-git> bitcoin/master cda1429 Matt Corallo: Give CMainSignals a reference to the global scheduler... 00:39 < bitcoin-git> [bitcoin] laanwj closed pull request #10179: Give CValidationInterface Support for calling notifications on the CScheduler Thread (master...2017-01-wallet-cache-inmempool-3) https://github.com/bitcoin/bitcoin/pull/10179 00:46 < bitcoin-git> [bitcoin] maaku opened pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792 00:50 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 260 seconds] 00:54 < gmaxwell> you mean it doesn't compute the max of the last two stack variables!?!? 00:54 < gmaxwell> :P 00:55 -!- promag [~joao@2001:8a0:fe30:de01:3048:f78e:3013:fc27] has joined #bitcoin-core-dev 00:56 < gmaxwell> [OT-ish] https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf < the ictp described here is neat. I wish pax stuff was open. 00:57 < sipa> gmaxwell: ??? 00:57 < sipa> (re: last two stack variables) 00:58 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection] 01:00 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 01:00 < gmaxwell> sipa: joke on mark's MAX_OPCODE 01:01 < gmaxwell> that it doesn't compute max() 01:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 01:01 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 01:02 < sipa> ah 01:04 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Client Quit] 01:04 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev 01:07 -!- promag [~joao@2001:8a0:fe30:de01:3048:f78e:3013:fc27] has quit [Quit: Leaving.] 01:16 < bitcoin-git> [bitcoin] MeshCollider closed pull request #10790: Use vector::data() instead of &vch[0] in base58.cpp (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10790 01:39 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 01:44 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev 01:45 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:50 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:52 -!- pyface [~pyface@about/security/contributor/pyface] has joined #bitcoin-core-dev 02:11 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 02:26 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 02:33 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 02:37 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 02:44 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21ed30a314cf...379aed0e53a6 02:44 < bitcoin-git> bitcoin/master f2f1d0a Gregory Sanders: document script-based return fields for validateaddress 02:44 < bitcoin-git> bitcoin/master 379aed0 Wladimir J. van der Laan: Merge #10676: document script-based return fields for validateaddress... 02:44 < bitcoin-git> [bitcoin] laanwj closed pull request #10676: document script-based return fields for validateaddress (master...validatata) https://github.com/bitcoin/bitcoin/pull/10676 02:45 < bitcoin-git> [bitcoin] MeshCollider opened pull request #10793: Changing &var[0] to var.data() (master...prefer-vector-data) https://github.com/bitcoin/bitcoin/pull/10793 02:48 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has joined #bitcoin-core-dev 02:58 < bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/379aed0e53a6...104f5f21dc24 02:58 < bitcoin-git> bitcoin/master cfaef69 Alex Morcos: remove default argument from GetMinimumFee 02:58 < bitcoin-git> bitcoin/master d507c30 Alex Morcos: Introduce a fee estimate mode.... 02:58 < bitcoin-git> bitcoin/master e0738e3 Alex Morcos: remove default argument from estimateSmartFee 02:58 < bitcoin-git> [bitcoin] laanwj closed pull request #10589: More economical fee estimates for RBF and RPC options to control (master...rpcestimatechoice) https://github.com/bitcoin/bitcoin/pull/10589 03:20 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev 03:36 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 240 seconds] 03:36 -!- pyface [~pyface@about/security/contributor/pyface] has quit [Quit: Leaving] 03:42 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev 03:46 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 03:50 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.] 03:54 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:58 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 04:00 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 04:02 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 04:13 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 268 seconds] 04:36 -!- coredump_ [~quassel@101.165.147.38] has joined #bitcoin-core-dev 04:40 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev 04:41 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit] 04:51 -!- coredump_ [~quassel@101.165.147.38] has quit [Ping timeout: 260 seconds] 05:14 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has joined #bitcoin-core-dev 05:31 -!- PlaneteNamek [50d774a1@gateway/web/freenode/ip.80.215.116.161] has joined #bitcoin-core-dev 05:31 < PlaneteNamek> Hello world 😊 05:34 < jonasschnelli> Beg for review on: https://github.com/bitcoin/bitcoin/pull/9502 05:48 -!- PlaneteNamek [50d774a1@gateway/web/freenode/ip.80.215.116.161] has quit [Ping timeout: 260 seconds] 05:53 -!- robotpoop [~gares@CPE00fc8d947f53-CM00fc8d947f50.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev 05:57 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has joined #bitcoin-core-dev 06:01 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 06:05 -!- ProfMac [43c671dc@gateway/web/freenode/ip.67.198.113.220] has quit [Ping timeout: 260 seconds] 06:08 -!- robotpoop [~gares@CPE00fc8d947f53-CM00fc8d947f50.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] 06:10 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has quit [Ping timeout: 240 seconds] 06:11 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has joined #bitcoin-core-dev 06:11 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:12 < wumpus> #9502 06:12 < gribble> https://github.com/bitcoin/bitcoin/issues/9502 | [Qt] Add option to pause/resume block downloads by jonasschnelli · Pull Request #9502 · bitcoin/bitcoin · GitHub 06:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:21 < bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/104f5f21dc24...e4f226a133d0 06:21 < bitcoin-git> bitcoin/master 32cffe6 John Newbery: [tests] Fix import order in getblocktemplate test 06:21 < bitcoin-git> bitcoin/master 0a3a5ff John Newbery: [tests] Fix flake8 warnings in getblocktemplate tests 06:21 < bitcoin-git> bitcoin/master 38b38cd John Newbery: [tests] getblocktemplate_proposals.py: add logging 06:21 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:22 < bitcoin-git> [bitcoin] laanwj closed pull request #10190: [tests] mining functional tests (including regression test for submitblock) (master...mining_functional_test) https://github.com/bitcoin/bitcoin/pull/10190 06:24 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e4f226a133d0...badd81bd3185 06:24 < bitcoin-git> bitcoin/master c8e29d7 Mark Friedenbach: Replace MAX_OPCODE for OP_NOP10.... 06:24 < bitcoin-git> bitcoin/master badd81b Wladimir J. van der Laan: Merge #10792: Replace MAX_OPCODE for OP_NOP10.... 06:25 < bitcoin-git> [bitcoin] laanwj closed pull request #10792: Replace MAX_OPCODE for OP_NOP10. (master...max-opcode-over-nop10) https://github.com/bitcoin/bitcoin/pull/10792 06:25 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/badd81bd3185...cef4b5ccaa37 06:25 < bitcoin-git> bitcoin/master 6270d62 Matt Corallo: Verify binaries from bitcoincore.org and bitcoin.org 06:25 < bitcoin-git> bitcoin/master cef4b5c Wladimir J. van der Laan: Merge #10651: Verify binaries from bitcoincore.org and bitcoin.org... 06:25 < bitcoin-git> [bitcoin] laanwj closed pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651 06:26 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 06:30 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has quit [] 06:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:37 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/cef4b5ccaa37...b27b004532db 06:37 < bitcoin-git> bitcoin/master 9c85b91 Alex Morcos: Change API to estimaterawfee... 06:37 < bitcoin-git> bitcoin/master 1fafd70 Alex Morcos: Add function to report highest estimate target tracked per horizon 06:37 < bitcoin-git> bitcoin/master 5e3b7b5 Alex Morcos: Improve error reporting for estimaterawfee 06:37 < bitcoin-git> [bitcoin] laanwj closed pull request #10543: Change API to estimaterawfee (master...estimaterawapi) https://github.com/bitcoin/bitcoin/pull/10543 06:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds] 06:40 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b27b004532db...ca4c545cc7e8 06:40 < bitcoin-git> bitcoin/master 475c08c Pieter Wuille: Add PR description to merge commit in github-merge.py 06:40 < bitcoin-git> bitcoin/master ca4c545 Wladimir J. van der Laan: Merge #10786: Add PR description to merge commit in github-merge.py... 06:41 < bitcoin-git> [bitcoin] laanwj closed pull request #10786: Add PR description to merge commit in github-merge.py (master...20170710_prbody) https://github.com/bitcoin/bitcoin/pull/10786 07:06 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 07:12 < ryanofsky> can #10235 be merged? 07:12 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 07:31 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 07:34 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds] 07:53 < morcos> I think #10712 can also be merged. sipa: you left just a nit, were you still reviewing? I'll skip the nit since the current commit has 3 ack's 07:53 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub 07:59 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving] 08:01 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10794: Add simple light-client mode (RPC only) (master...2017/07/spv) https://github.com/bitcoin/bitcoin/pull/10794 08:02 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #9171: Introduce auxiliary block requests (master...2016/11/spv_step_1) https://github.com/bitcoin/bitcoin/pull/9171 08:02 -!- Herta [~Herta@static.22.144.99.88.clients.your-server.de] has joined #bitcoin-core-dev 08:05 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has quit [Ping timeout: 240 seconds] 08:09 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has joined #bitcoin-core-dev 08:12 < BlueMatt> wumpus: would be nice to get a quick glance and merge on #10235 08:12 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 08:14 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 08:34 -!- Herta [~Herta@static.22.144.99.88.clients.your-server.de] has quit [Remote host closed the connection] 08:35 < morcos> BlueMatt: How does it know what index to create key at if the keypool is empty? (same question before your PR) 08:36 < BlueMatt> hmm? 08:36 < BlueMatt> it doesnt matter if the pool is empty, use index 0? 08:37 < BlueMatt> the indexes dont really have a purpose, its more of a set 08:37 < wumpus> looking at 10235 08:37 < morcos> yeah i just figured that out, that the indices are only for keypool management 08:37 < BlueMatt> yea 08:37 < morcos> but are you sure there is not a bug now that you have two keypools 08:38 < BlueMatt> well afterwards you should still make sure they keyids are unique, ie creating at the max of both sets 08:38 < morcos> if external runs out, couldn't you create a new key in the external pool with the same index as one in the internal pool 08:38 < BlueMatt> i hope that pr doesnt do that 08:39 < morcos> i'm not sure if there is a bug, i'm making my way through all this logic for the first time, but i think it would be a lot clearer if you figured out nInternalEnd and nExternalEnd and maxed them for nEnd 08:40 < morcos> actually it seems even worse than that 08:40 < morcos> i just don't think this logic works with two pools 08:41 < BlueMatt> hmm? 08:41 < morcos> imagine internal = {1,3} and external = {2,4} 08:41 < morcos> then external runs out 08:41 < BlueMatt> you can reuse indexes 08:41 < morcos> you'll now generate 4 as the next internal key or external key 08:41 < BlueMatt> thats no problem 08:41 < morcos> oh yeah, i guess thats ok 08:42 < morcos> ok, so ignore me 08:42 < morcos> maybe it's pretty clear. 08:43 < morcos> what about the pool on disk though? it seems like you shouldn't start reusining indices until you're sure they aren't in there? 08:44 < BlueMatt> hmmmmmm, yea, there is a bug there, but I didnt introduce it 08:44 < morcos> yeah, but made it much more likely to get hit i think 08:44 < BlueMatt> dont think so? 08:45 < BlueMatt> ReserveKeyFromKeyPool, (keypool now empty), TopUpKeyPool, fucked 08:45 < BlueMatt> I dont think i made a real difference to the likelyhood there 08:45 < morcos> well before you start over again at 1, so it's unlikely the initial indices are still in disk pool 08:45 < morcos> but with yours you could easily reuse a recent one as per my {1,3} {2,4} example above 08:45 < BlueMatt> depends on your keypool size 08:45 < BlueMatt> true 08:45 < morcos> sure, seems like a bug either way 08:46 < BlueMatt> anyway, its only really likely if you have a small pool, but still not good 08:46 < BlueMatt> unless you object I'll fix it in a separate pr? 08:47 < wumpus> what is the worst that can happen if an index is inadvertently reused? 08:47 < morcos> so what happens, do you overwrite the old keypool entry with the new one on disk? and seems like you could either return the reserved key or use it, and either case might cause problems 08:47 < BlueMatt> jonasschnelli: where are you on #10650? We 08:47 < gribble> https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub 08:47 < morcos> wumpus: not clear to me 08:47 < BlueMatt> re dangerously close to having multiwallet slip to 16 08:48 < BlueMatt> wumpus: yea, not clear to me either, intuitively it should be rather minimal, not like we're clearing private keys or anything, but I could see it hitting an assert somewhere 08:48 < morcos> BlueMatt: I suppose I have a slight preference for you adding another commit to that PR to fix it. 08:48 < wumpus> is everything necessary for multiwallet tagged as 0.15? 08:48 < BlueMatt> i think its just 10650 at this point, no? 08:49 -!- kvp [8700fb85@gateway/web/freenode/ip.135.0.251.133] has quit [Quit: Page closed] 08:49 < wumpus> yes, I think so, and that one is tagged, good 08:50 < BlueMatt> morcos: heh, ok, I was trying to avoid polluting the bugfix-vs-not distinction, but I suppose the performance regression is somewhat bugfix-y anyway 08:50 < morcos> 64-bits is a big number.. seems pretty safe to just have an in-memory nextIndex that is initialized by taking max of the on-disk last entry in the set? 08:50 < morcos> sets 08:51 < wumpus> if you do that, please do make it per-wallet, not global 08:51 < BlueMatt> yes, that was my preferred fix 08:51 < wumpus> but if it's 64-bit I don't think we have to be worried about reusing 08:52 < wumpus> unless small numbers are preferable because they are more efficient for some reason 08:52 < wumpus> but I don't think so in this case 08:52 < BlueMatt> ugh, no, bigger numbers better 08:53 < wumpus> ok, so hold off on merging #10235? 08:53 < gribble> https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub 08:53 < BlueMatt> i guess 08:53 < wumpus> I'm not sure that's the right thing to do if that bug was not introduced here 08:53 * BlueMatt does care 08:54 < morcos> wumpus: don't hold off for my sake 08:54 < morcos> i trust we'll merge the fix before 0.15 08:54 < BlueMatt> heh, ok, how bout i just open a pr right now to fix it 08:54 < BlueMatt> and take 10235 08:54 < morcos> BlueMatt: stop talking and start coding 08:55 < wumpus> std::max(nEnd, *(--setExternalKeyPool.end()) + 1); 08:56 < wumpus> whaaaa 08:56 < BlueMatt> lol, i didnt introduce that 08:56 < wumpus> what is *that* 08:56 < BlueMatt> there's no back() in set :( 08:57 < wumpus> I'm not blaming you, but that's not acceptable, certainly not without a comment 08:57 < wumpus> then add a back(set) helper function maybe 08:57 < BlueMatt> lol, ok, sec 08:57 < wumpus> factor this out to a sensible something 08:58 < BlueMatt> fwiw, I find that pretty readable, but ok 08:58 < wumpus> no, that's not readable 08:58 < wumpus> not at all 08:58 < wumpus> why would you want to infix-decrease end()? 08:58 < wumpus> what does that even do? 08:58 < wumpus> does it move the end of the set? 08:59 < BlueMatt> but, then, i write iterator garbage that looks like https://github.com/bitcoinfibre/bitcoinfibre/blob/master/src/blockencodings.cpp#L281 09:00 < wumpus> people have to be able to maintain that code, also people that are not you 09:00 < BlueMatt> i didnt write it 09:00 < BlueMatt> I'm fixing... 09:01 < wumpus> that function in fibre looks more understandable 09:02 < wumpus> it doesn't do anything really crazy and it does it step by step 09:03 < BlueMatt> ok, fixed on 10235 09:03 < BlueMatt> lol, clearly I need to try harder to write garbage iterator code in fibre then 09:04 < wumpus> well as long as you don't inadvertently add UB 09:04 < wumpus> but if you really want to, make sure it's all in one expression and the order of operations, as well as what applies to what isn't clear 09:05 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:05 < wumpus> yes, this is much better, thanks 09:05 < BlueMatt> heh, I was joking, that stuff is hard enough to maintain when I go back once every three months and rewrite big chunks to get another 2 milliseconds out of it :p 09:05 < BlueMatt> without remembering the threading model that will cause a segfault-in-a-million if you break it 09:07 < wumpus> I can imagine 09:07 < cfields> BlueMatt: fwiw, you can use *.rend() if !empty() 09:07 < cfields> er, rbegin 09:07 < BlueMatt> yea, that too 09:13 < BlueMatt> wumpus: err, nvm, easier to just fix the first bug than bother with simplifying that code 09:13 < wumpus> I'm afraid #10712 doesn't build on top of current master 09:13 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub 09:13 < wumpus> BlueMatt: well you had simplified that code just fine imo 09:13 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:13 < BlueMatt> yes, but the next pr is to remove it :p 09:13 * morcos loves it when someone elses code gets made fun of (ha ha, wow poor timeing to say that) 09:13 < morcos> ok will look 09:14 < BlueMatt> lol 09:14 < wumpus> BlueMatt: lol, oops, that happens to me all the time 09:14 < wumpus> spend optimizing or improving some part of the code, then it's no longer necessary :p 09:15 < wumpus> re: #10712: src/wallet/wallet.cpp:2763:151: error: too few arguments to function call, expected 7, have 5 09:15 < wumpus> CAmount fee_needed_for_change = GetMinimumFee(change_prototype_size, currentConfirmationTarget, ::mempool, ::feeEstimator, nullptr); 09:15 < gribble> https://github.com/bitcoin/bitcoin/issues/10712 | Add change output if necessary to reduce excess fee by morcos · Pull Request #10712 · bitcoin/bitcoin · GitHub 09:15 < BlueMatt> well, I'll lave 10235 with the fix for now, since it should be an easy merge 09:16 < BlueMatt> and then it'll get removed in the next pr, which will need a whole review cycle 09:17 < morcos> yeah conflict with my other PR you just merged but in a newly added line, will fix 10712 09:18 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10795: No longer ever reuse keypool indexes (master...2017-07-wallet-keypool-overwrite) https://github.com/bitcoin/bitcoin/pull/10795 09:41 -!- vicenteH [~user@195.235.96.150] has quit [Read error: Connection reset by peer] 09:47 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has quit [Ping timeout: 255 seconds] 09:50 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev 09:51 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has joined #bitcoin-core-dev 09:57 -!- JackH [~laptop@host86-187-162-169.range86-187.btcentralplus.com] has quit [Ping timeout: 240 seconds] 10:02 < sipa> these are some preliminary benchmarks for a reindex-chainstate up to height 450000 (before assumevalid, so no signature checking), with infinity dbcache, for various sha256 implementations: 10:03 < sipa> bitcoind-rorx: 4835 10:03 < sipa> bitcoind-shani: 4297 10:03 < sipa> bitcoind-basic: 5134 10:03 < sipa> bitcoind-sse: 4875 10:04 < sipa> basic is master 10:04 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca4c545cc7e8...e8b95239eeb0 10:04 < bitcoin-git> bitcoin/master 253cd7e Alex Morcos: Only reserve key for scriptChange once in CreateTransaction... 10:04 < bitcoin-git> bitcoin/master 0f402b9 Alex Morcos: Fix rare edge case of paying too many fees when transaction has no change.... 10:04 < bitcoin-git> bitcoin/master e8b9523 Wladimir J. van der Laan: Merge #10712: Add change output if necessary to reduce excess fee... 10:04 < sipa> rorx and sse are from wumpus' work to include some asm optimized versions 10:04 < bitcoin-git> [bitcoin] laanwj closed pull request #10712: Add change output if necessary to reduce excess fee (master...addchangehwenoverpaying) https://github.com/bitcoin/bitcoin/pull/10712 10:04 < sipa> the shani version is using code from cryptopp 10:06 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 10:07 < BlueMatt> lol, Make Bitcoin CryptoPP Again 10:08 < BlueMatt> thats a pretty impressive gain 10:08 < sipa> unfortunately, very few systems right now have sha-ni instructions 10:09 < BlueMatt> yes, but that should change over time 10:09 < BlueMatt> the sha-ni in intel and amd are identical, no? 10:09 < sipa> afaik, there is exists no "sha-ni in intel" yet :) 10:10 < wumpus> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :) 10:10 -!- JackH [~laptop@79-73-186-49.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 10:11 < sipa> sse is present in nearly every x86_64 cpu, i think 10:12 < wumpus> yes, sse is present in all of them 10:12 < wumpus> even sse2 should be in all of them 10:13 < BlueMatt> sipa: hmm? I was under the impression they had announced something like the next arch will get it 10:13 < gmaxwell> sse2 is required by x86_64. 10:13 < BlueMatt> no shipping ones, obviously 10:14 < wumpus> those are not exactly new instructions though :) anyhow supporting shani as well is nice, just takes time and it will be in near everything... 10:14 < gmaxwell> here is something funny: compilng bitcoin with -march=native makes the sha2 in C most of the speed of the sse one. (compiler manages to use rorx) 10:15 < gmaxwell> Also the x86 simd support will make it easier to plug in arm versions; which will be more important for speed. 10:15 < BlueMatt> wow, yay compiler smarts 10:16 < gmaxwell> sipa: there is an intel chip with sha-ni, but it's some crappy atom processor. 10:16 < BlueMatt> that's always the dilemma with new instructions, the systems that have that instruction probably least need the optimization :) 10:16 < BlueMatt> heh, guess not, then 10:17 < sipa> gmaxwell: compiling all of bitcoind with -march=native actually makes it overall another 100s faster to sync 10:17 < gmaxwell> well aformentioned atom is some server atom that isn't very widely deployed from what I can tell. 10:17 < BlueMatt> do you have lto benchmarks? 10:17 < sipa> not yet, but i can create 10:18 < wumpus> yes, march=native is nice, everyone compiling bitcoind locally should use it 10:18 < gmaxwell> #9804 looks like a good change that is getting forgotten. (I say that as someone whos only concept acked so far...) 10:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9804 | Fixes subscript 0 ([0]) where should use (var.data()) instead. by JeremyRubin · Pull Request #9804 · bitcoin/bitcoin · GitHub 10:18 < wumpus> with so many open PRs it's unavoidable that some things get forgotten, unfortunately 10:19 < wumpus> but no, that one isn't 10:19 < wumpus> I just referred people to review it today (because they opened a PR that was a strict subset of it) 10:20 < sipa> wumpus: thanks for that, i had almost forgotten about jeremy's version 10:30 < BlueMatt> lolwut 10:30 < BlueMatt> ehh, wrong window 10:31 < sipa> seems totally appropriate here 10:32 < BlueMatt> ok, then I'll pretend I meant to 10:33 -!- vicenteH` [~user@195.235.96.150] has joined #bitcoin-core-dev 10:34 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 240 seconds] 10:36 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 10:37 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 10:46 -!- vicenteH` [~user@195.235.96.150] has quit [Ping timeout: 240 seconds] 10:47 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds] 10:58 < sipa> running benchmarks for lto and shani+lto as well now 10:58 < sipa> will have numbers in a day... 10:59 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev 10:59 < sipa> interestingly, the shani+lto does not even contain any non-shani sha code, even though it's dispatched to a modifiable pointer 10:59 < BlueMatt> heh 10:59 < BlueMatt> oh nice 10:59 < sipa> the compiler must notice there are no assignments to that pointer, and treats it as a constant 11:00 < BlueMatt> yea, lto can be clever sometimes 11:01 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 11:08 < gmaxwell> if compiler versions are still keeping up from ltoing by default perhaps we could add a --gofast configure flag to do -march=native -O3 -lto 11:09 < BlueMatt> is O3 a win in bitcoin? 11:09 < sipa> i guess i'll benchmark that too :) 11:09 < BlueMatt> heh 11:13 < wumpus> I don't see why something as basic as that would need a configure fla 11:14 < wumpus> people that want to supply their own CXXFLAGS can do so already 11:14 < wumpus> could just mention it in the build document 11:14 < wumpus> a dedicated configure flag only makes sense if we use something for the gitian build, so people can do their own build with the same settings 11:15 < gmaxwell> wumpus: fair enough 11:15 < wumpus> but using -march=native would be a bad idea there, -flto might be a good one 11:15 < BlueMatt> yea, flto could use its own configure flat...doing it manually is like 6 variables long 11:17 < gmaxwell> well I think we should lto by default, but there was still some question of compiler support. (which I think was mooted by C++11, but perhaps I'm wrong, since we still haven't done it.) 11:18 < wumpus> I'm not convinced anything but -O2 optimization should be default 11:19 < gmaxwell> wumpus: why shouldn't it be lto-ing by default? 11:19 < wumpus> cfields might have more of an opinion, but in my experience buildling open source software for lots of platforms, I've had lots of annoyances with software that tried to forcibly injects certain sets of optimizations flags 11:19 < wumpus> it should be left up to the distribution ideally to set optimization flags 11:19 < BlueMatt> gmaxwell: lto does not work on moderately-recent compilers 11:19 < wumpus> well even if it did 11:19 < BlueMatt> eg debian jessie 11:19 < sipa> works fine here, and for release builds we control the environment entirely anyway 11:20 < BlueMatt> well, i guess 4.9 isnt moderately-recent 11:20 < wumpus> yes, for release builds flto would be good 11:20 < BlueMatt> anyway, we support it, and lto doesnt work on it 11:20 < cfields> wumpus: agreed. "-02 -g" is expected to be the default, I get really irritated when that's not the case 11:20 < wumpus> cfields: exactly 11:20 < sipa> benchmarking reindex with "-O2", "-O3", "-flto -O2", and "-flto -O3" 11:20 < BlueMatt> nice 11:21 < wumpus> don't get me wrong, flto would be great for gitian builds, and we could have a configure option for that, but adding non-standard optimization flags by default on configure tends to be really annoying in edge cases 11:21 < sipa> cfields was concerned about having release builds deviate too much from developers-tested builds 11:21 < cfields> I get the impression i should go ahead and wire up --enable-lto before someone sneaks in something unexpected :) 11:22 < gmaxwell> BlueMatt: I do not believe that LTO fails to work on anything that can compile Bitcoin Core. It's been supported since GCC 4.7 11:22 < wumpus> if you want to encourage people to build with optimization flags then just document it in e.g. build-unix.md 11:22 < wumpus> don't do anything sneaky 11:22 < gmaxwell> Our cflags are far from -O2 -g, though, we add about two dozen warning flags. 11:22 < wumpus> warning flags don't do aything funny to the code 11:22 < cfields> sipa: i think an --enable-lto alleviates that somewhat, since it makes it easy for devs to get the same results 11:23 < BlueMatt> gmaxwell: I dunno, I've been building on lto for a long time and every debian jessie server I've ever installed has always failed to build lto 11:23 < sipa> BlueMatt: due to some boost interaction, right? 11:23 < BlueMatt> its an easy fix - just recompile util.cpp without lto and then it works, but its broken 11:23 < BlueMatt> sipa: its not boost-specific, but thats where it fails 11:23 < BlueMatt> it appears to be some general issue with destructors defined in headers 11:23 < cfields> sipa: iirc i hit a boost::filesystem problem last i tried 11:23 < gmaxwell> BlueMatt: good datapoint then. 11:23 < BlueMatt> I've seen it fail on other things, but normally the thing you see is ~boost::filesystem() 11:23 < cfields> but i assumed it was local 11:24 < BlueMatt> ehh, sorry, not filesystem 11:24 < BlueMatt> some boost::filesystem path ~ thing 11:25 < cfields> sipa: ooh i know, we can wire it up with depends builds 11:25 < BlueMatt> cfields: didnt you tell me you were gonna wire up a "trusting-trust" gcc build in depends for 15? :P 11:25 < BlueMatt> I still dont see a PR 11:26 < cfields> that way anyone using depends gets lto by default, and we also know what dep versions we're dealing with 11:26 < wumpus> our good friend ubuntu trusty has gcc 4.8.4, hopefully that can do flto without probems (especially worried about windows! but we'll see) 11:26 < cfields> BlueMatt: i don't think it's going to make it :( 11:26 < BlueMatt> wumpus: I'd be kinda surprised if it did 11:26 < BlueMatt> cfields: what? by this coming sunday? yea, somehow i doubt it 11:27 < wumpus> can someone please just try instead of guess :-) 11:27 < BlueMatt> +1 11:27 < BlueMatt> go cfields, go 11:27 < wumpus> I can do it, np, but thought cfields was going to 11:28 < cfields> add lto to configure (and see if it works) ? 11:28 < wumpus> cfields: yes, doing a gitian build with lto (for all platforms) 11:29 < BlueMatt> oh, i thought we were talking about a "trusting trust" copy of gcc 11:29 < wumpus> then seeing where/if the result crashes 11:29 < cfields> sure, i can do that 11:29 < BlueMatt> yea, ok, adding lto is much easier, that could make it 11:29 < wumpus> BlueMatt: I thoughtwe were talking about optimizations 11:29 * wumpus confused 11:30 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds] 11:30 < cfields> adding lto to configure now, then seeing where it works. 11:32 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 11:32 < wumpus> cool 11:34 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev 11:34 < cluelessperson> Hey guys, I'm looking at buying some new server hardware. 11:34 < cluelessperson> https://www.asus.com/us/Commercial-Servers-Workstations/RS100-E9-PI2/specifications/ 11:35 < cluelessperson> is currently on my plate, but I was wondering if you might suggest something else that might be more beneficial towards bitcoin development, testing/QA? 11:38 < wumpus> this really isn't the channel for server hw suggestions 11:38 < midnightmagic> I sent him here. 11:39 < BlueMatt> cluelessperson: anything with fast disk and lots of memory 11:39 < BlueMatt> otherwise, O/T 11:40 < cluelessperson> BlueMatt: I could do PCI-SSD, but what type of ram requirements are we talking? 11:40 < midnightmagic> -- since he was hoping to help in some capacity with the development itself, and I know occasionally guidance in terms of e.g. differing hardware or stuff that would be more helpful than generic hardware is sometimes in demand. 11:40 < BlueMatt> ok, no big deal, lets move to #bitcoin 11:43 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #8369: [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" (master...2016/07/wallet_features) https://github.com/bitcoin/bitcoin/pull/8369 11:48 -!- Guest23212 [~socrates1@li175-104.members.linode.com] has quit [Ping timeout: 246 seconds] 11:51 -!- Guest89066 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev 11:55 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:00 < morcos> ryanofsky: #10244 is marked high-priority, but seems to me from reading the conversation that although it is now concept acked it's targeted for post-0.15? 12:00 < gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub 12:00 < morcos> just want to direct my review appropriately with 0.15 coming up 12:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 12:01 < jonasschnelli> morcos: Yes. Agree. 10244 should probably removed until there is conceptual consensus (not cleat to me if we have that or not, which probably means we have not :) ) 12:02 < ryanofsky> i thought i had two concept acks 12:02 < jonasschnelli> Oh. Yes. Right.. 12:02 < ryanofsky> but it's not intended for 15. maybe search for milestone:0.15.0 12:02 < jonasschnelli> I take back my last comment then... 12:04 < jonasschnelli> I think for 10244, it makes sense to rebase it after 0.15 has been split off and concentrate review (and hope for a merge) 12:04 < jonasschnelli> It's a large PR though 12:04 < jonasschnelli> +2,262 −1,152 12:04 < ryanofsky> it's pretty much a mechanical change 12:06 < wumpus> agreed 12:06 < wumpus> it's not an end-user visible change, we should prioritize those for 0.15 12:07 < wumpus> all the code cleanups pure refactorings can wait for 0.16 12:11 < morcos> ok, i was viewing high priority as a subset of milestone:0.15, but perhaps that isn't correct 12:12 < jonasschnelli> wumpus, ryanofsky: Argee about it beeing mechanical, though it still require line by line review by at least 2-3 guys. 12:12 < wumpus> well maybe it is now, but in general it's just something that people can request review if it blocks future PRs from themselves 12:12 < wumpus> but I agree ahving something high-prio that won't make 0.15 anyway is a bad idea 12:13 < wumpus> right now 12:13 < jonasschnelli> Yes. I had the same feeling. High-Prio in context of holding back the individual developer / focus of the individual developer. 12:14 < jonasschnelli> About sipa's ser. changes (#10785), is it worth to benchmark the differences or do we expect non to little impact on performance? 12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Serialization improvements by sipa · Pull Request #10785 · bitcoin/bitcoin · GitHub 12:15 < jonasschnelli> (otherwise I can add a bench-package for the serialization code 12:15 < jonasschnelli> ) 12:17 < jonasschnelli> ryanofsky about the CAuxiliaryRequest, where do you think we have duplicated code? Also, what do you think about the points I wrote (https://github.com/bitcoin/bitcoin/pull/10794#issuecomment-314534086)? 12:18 < jonasschnelli> (maybe its better to discuss some thing here instead of have to much discussion on the PR before we actually get reviews) 12:18 < jonasschnelli> things* 12:19 < sipa> jonasschnelli: i expect 0 impact on performance 12:19 < jonasschnelli> sipa: Okay. Then it's probably not worth... 12:19 < ryanofsky> it's been months since i've looked at it but, i remember duplicated logic in the aux request class & normal network download code 12:20 < jonasschnelli> ryanofsky: I can't see any real duplication, maybe some lines that take care of passing to the instance and for the callback approach... 12:20 < ryanofsky> i'm looking up my old comments 12:21 < jonasschnelli> Great. Thanks.. 12:22 < sipa> jonasschnelli: it could be considered a bugfix though (but almost certainly not one that matters) 12:22 < ryanofsky> here is the comment where i point out the duplication: https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677 12:22 < jonasschnelli> sipa: you mean the "cast ways the const"? 12:23 < jonasschnelli> "cast away" 12:24 < ryanofsky> jonasschnelli, my broader point is that i would like you to get some concept ack on your networking design from some other developers who know more about the networking code than me, before i spend more time reviewing it 12:24 < jonasschnelli> ryanofsky: Yes. Sure. That makes sense. 12:25 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds] 12:25 < jonasschnelli> About your comment, I saw that and I think its then not about duplication, it's a slightly different approach (which seems also to make sense). 12:26 < jonasschnelli> I just like the have-its-own file approach for the reasons I wrote.. but lets get other opinions 12:26 < ryanofsky> fillInNextBlocks is duplicative of FindNextBlocksToDownload, processWithPossibleBlock is duplicative of ProcessNewBlock was my point 12:27 < ryanofsky> i don't think you are going to convince me that having two different control flows for regular downloads vs priority downloads is the way to go, but you don't have to convince me. i'm happy to accept that if others think it is a good idea 12:27 < jonasschnelli> ryanofsky: I don't think its duplicative, if we would eliminate the class, that logic has just to move into net_processing.cpp/validation.cpp 12:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:28 < gmaxwell> ryanofsky: I think others do not think it's a good idea, and already raised the concern. 12:28 < ryanofsky> iirc, more logic could be shared if they were in the same place 12:28 < gmaxwell> When that code was first implemented; ... made sense to do for a demo or whatnot. 12:28 -!- ivan_ [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev 12:28 < sipa> just have a means to tell the network layer "i need block X, and here is callback for when you have it" 12:29 < jonasschnelli> Okay. But the network layer hasn't to be stuffed into a single file/class? 12:29 < ryanofsky> sipa, yes that is what i requested. i think the auxilliary class is too low level 12:30 < jonasschnelli> But if the general opinion goes direction of having the logic in net_processing.cpp directly, then I'm fine with moving it there... 12:30 < sipa> jonasschnelli: net_processing is already a single file 12:30 < ryanofsky> jonasschnelli, i think agree networking code is monolithic. but that you have to find the right way to break it up and this does not seem like the right way 12:31 < jonasschnelli> sipa: Yes. And I think having specialized functions (like the light client block rquests) in dedicated files makes sense.. rebasing, patches, code-overview 12:32 < sipa> jonasschnelli: i really don't think block fetching code should be in more than 1 place 12:32 < gmaxwell> we have a hard enough time keeping the two existing block requesting state machine functioning and maintained... really pretty ugly to add another seperate one for the wallet in another place. 12:32 < sipa> it's arguably already too spread out in net_processing (dealing with invs, direct fetching, headers fetching, async fetching ...) 12:32 < jonasschnelli> sipa: it's not fetching,.. is an object that hold information about what it should fetch and if it's done or not and eventuall the process flow 12:33 < sipa> jonasschnelli: yes, that's probably how all the fetching code should work 12:33 < sipa> keep information on what blocks are to be downloaded 12:34 < jonasschnelli> ryanofsky gmaxwell: I think the out-of-band (auxiliary) requests need state, and therefore a class makes sense (when was the request initiated, how much is done, etc.) would you add that class into net_processing rathern then creating a new file? 12:34 < ryanofsky> i think if you wanted to move code *out* of net_processing into your new download implementation, that would be nice. but just adding the new download implementation alongside does not seem seem so nice 12:34 < gmaxwell> jonasschnelli: all block requests need state. 12:34 < gmaxwell> jonasschnelli: we have to track what we've asked for, what we need, whats been recieved... and so on. 12:34 < jonasschnelli> gmaxwell: yes. But here it is a user-requested range 12:35 < sipa> jonasschnelli: in the current case, the user is the block validation logic 12:35 < sipa> you just want to add another user 12:35 < gmaxwell> ^ 12:35 < jonasschnelli> sipa: can't follow the "user is the block validation logic" :/ 12:35 < ryanofsky> to make discussion more concrete, what do you think of my blocksToDownloadFirst suggestion? 12:36 < jonasschnelli> ryanofsky: Yes. Make sense. But still, the requester (assume wallet) will need to blocks in a clear sequence (assume A, B, C, D and not C, D, A, B). 12:37 < jonasschnelli> Therefore there must be something that takes care of the state of a wallet/user initiated out-of-band block request and make sure, it will be passed in in sequence 12:38 < jonasschnelli> IMO its about "requesting n amount of "range of blocks" rather then just requesting blocks 12:40 < gmaxwell> jonasschnelli: right now the consensus logic requests the block download machinery to download blocks, keep track of the requests and what not. 12:40 < ryanofsky> i'm not sure i see the problem. that state could be tracked inside the wallet. wallet just needs to request blocks, get notifications when they come in, then request more blocks 12:40 < gmaxwell> jonasschnelli: sipa is pointing out that what you're doing is just adding an addition set of callers. 12:40 < gmaxwell> jonasschnelli: why does the wallet need blocks in order? 12:42 < jonasschnelli> gmaxwell: if we assume the wallet does show to the user what it had processed it would probably look strange if the wallet would update the balance, tx-list of block that come in out of order 12:42 < jonasschnelli> Also, detecting re-orgs would be difficult? 12:42 < ryanofsky> can't wallet keep track of it's own requests and ignore anything it wants to ignore? 12:43 < gmaxwell> if the wallet is just saying how far it had processed, couldn't it just show the minimum height processed so far? showing things out of order would certantly allow things faster. 12:43 < jonasschnelli> ryanofsky: Yes. If we assume only wallets want that. What about the other user cases, ZMQ, light-client "middleware" (Oh I had this term) 12:44 < ryanofsky> jonasschnelli, that's why i was asking for some kind of design doc, going into the what specifically you envision there 12:45 < jonasschnelli> gmaxwell: hmm.. I guess the user would look at the transaction list and see a possible incoming transaction while a older expected incoming transaction is missing, regardless of how the wallet communicates "minimum process height" 12:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 12:45 < sipa> jonasschnelli: right now, the only thing that "needs" blocks is the block validation 12:45 < sipa> you're adding something else that needs blocks 12:46 < jonasschnelli> ryanofsky: Not only, #10794 is purely RPC/ZMQ 12:46 < gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub 12:46 < sipa> both of them should be seen as users of the block fetching logic 12:46 < jonasschnelli> sipa: Ah. I understand now 12:48 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:48 < jonasschnelli> sipa, ryanofsky: The idea in 10794 is to have the validation triggered download logic in tact (minimal impact) while preferring out-of-band requests. And I tried to keep the logic, state-machine outside of net_processing.cpp to allow later code splits 12:49 < sipa> i think that's the wrong approach (though admittedly i haven't reviewed the code) 12:49 < jonasschnelli> (It's good you haven't so I can change it before you do. :) ) 12:49 < jonasschnelli> sipa: what would you prefer then? 12:49 < sipa> jonasschnelli: as i explained 12:50 < sipa> refactor the current block downloading logic to support multiple users 12:50 < sipa> make it keep track of what blocks to download 12:50 < sipa> and what to do when they arrive 12:50 < jonasschnelli> sipa: I thought you are going to say that... I just think this is way larger but probably cleaner 12:50 < sipa> it's much more refactoring, yes 12:51 < sipa> but it'll be tiny to add light client fetching on top :) 12:51 < jonasschnelli> heh.. Yes. After that one or two year for the block download refactoring.. :) 12:52 < ryanofsky> am i missing something? https://github.com/bitcoin/bitcoin/pull/9483#discussion_r100077677 seems pretty straightforward and not a large amount of refactoring 12:53 < jonasschnelli> I guess I focus to much on the minimal.impact solution rather then on the clean solution because I'm too much feature driven 12:53 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:54 < jonasschnelli> ryanofsky: Not sure if the idea in that comment fulfils sipa idea of having "multiple users for the download logic" 12:55 < morcos> sipa: i also like that idea, but i wonder if there is a priority difference there... like how quickly you time out, or find someone else to deliver or penalize for bad behavior or etc... 12:55 < ryanofsky> because blocksToDownloadFirst is not sufficient for multiple users? 12:55 < morcos> who me? 12:56 < morcos> oh him 12:58 < jonasschnelli> ryanofsky: No I think because we would only partially (out of band request) allow multiple users for the block download. But not exactly sure to what extend sipas solution should go to 12:58 < ryanofsky> oh i think i see the difference. sipa's idea is to keep track of blocks to download and "what to do when they arrive". my idea would just do the first and let client figure out what to do when blocks come 12:58 < sipa> what do you mean with 'out of band' ? 12:59 < jonasschnelli> sipa: out-of-band is a poor multi-user approach for block download (the in-band is validation, the rest is out-of-band) 12:59 < sipa> i don't understand what you mean with 'out of band' in this context 12:59 < jonasschnelli> sipa: i guess what you meant is that the validation part uses the same block download interface then the light-client wallet? right? 13:00 < sipa> yes 13:01 < jonasschnelli> sipa: the validation requests block after it's own logic (not to far away, etc.), out-of-band requests can request a range of blocks that make no sense for the validation (in terms of time prioritation) 13:01 < jonasschnelli> sipa: I guess ryanofsky terms `blocksToDownloadFirst` is much better 13:01 < sipa> i still don't understand what you mean with out of band 13:02 < sipa> there are blocks to download, there is logic to determine which ones to download in what order, they're processed when they arrive 13:02 < jonasschnelli> I think i should call it "priorizedBlockRequests" 13:03 < jonasschnelli> sipa: Yes. But the light client (wallet) wants to break that oder by a) preferring other blocks first, b) pass them through BlockConnected() before they are connected to the tip 13:04 < jonasschnelli> (connected to the tip == validated, not connected == spv) 13:05 < sipa> sure 13:05 < jonasschnelli> ryanofsky: I think sipa's idea makes sense in the long run (don't distinct between wallet spv block requests and the validation triggered block request), ideally the validation would then use the same interface then the (light-client) wallet would use 13:06 < jonasschnelli> but this would be a lot of work 13:06 < sipa> sure, not everything has to happen in one go 13:06 < ryanofsky> yeah, i get that now. i think that refactoring is basically orthogonal though 13:07 < jonasschnelli> I agree... 13:07 < ryanofsky> you could do that refactoring with or without prioritized downloads, or vice versa 13:07 < sipa> ryanofsky: agree 13:07 < jonasschnelli> I even think implementing the prioritized downloads gives a better feeling on how-to-refactor 13:07 < jonasschnelli> because you refactor with a clear interface use-case 13:08 < sipa> yes, fair enough 13:08 < jonasschnelli> But I'm still not sure if it makes then sense to implement it within net_processing or leave it in a designated file (not very different IMO) 13:09 < jonasschnelli> Probably most devs things within net_processing.cpp makes more sense... 13:09 < jonasschnelli> *think 13:09 < jonasschnelli> Then let me do that and let me rename it from auxiliary (out-of-band) to prioritizedBlockRequests 13:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 13:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:19 -!- jamesob_ [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 13:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 13:21 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds] 13:25 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:25 -!- ybit2 is now known as ybit 13:31 < cfields> ok, i managed to patch boost and fix the lto linking error... 13:32 < cfields> anyone feel like looking at a head-scratcher? 13:32 < BlueMatt> really? I failed to do so previously 13:32 * BlueMatt is curious 13:33 < cfields> BlueMatt: was this your problem as well? https://pastebin.com/raw/kmqJVmfq 13:33 < BlueMatt> oh, no 13:34 < cfields> oh. what's yours? 13:34 < BlueMatt> i always got a link-time "~boost::filesystem::path() undefined" error 13:34 < BlueMatt> and occasionally for other destructors that were implicitly-defined in headers or explicitly defined in headers 13:34 < cfields> oh, same thing 13:34 < cfields> ZN5boost10filesystem4pathD1Ev is mangled destructor 13:35 < cfields> right, so the fix was to give it an explicit destructor in the .cpp 13:35 < BlueMatt> heh, your linker has garbage error messages 13:35 < BlueMatt> yes, but boost::filesystem::path has no .cpp 13:35 < cfields> but i'm not understanding why 13:35 < BlueMatt> or, i dont recall one 13:35 < BlueMatt> oh, i have no idea why 13:35 < cfields> it does 13:35 < BlueMatt> oh, ok 13:35 < sipa> BlueMatt: go test cfields's fix :p 13:36 < cfields> heh, I'll PR as soon as I can understand why it's a fix :) 13:36 < BlueMatt> and it mostly only happens to that one place, not on other destructors-defined-in-headers 13:36 < BlueMatt> but i have seen it on others before 13:36 < cfields> BlueMatt: right, there's a particular reason for these, sec 13:36 < sipa> there are fairly complicated rules in C++ about which object the implementation of some implicit methods goes into 13:37 < cfields> https://github.com/boostorg/filesystem/blob/develop/src/path.cpp#L703 13:37 < cfields> they're static vars there 13:38 < cfields> (and statics for each of the failures in the link) 13:38 < BlueMatt> ah, is that why? static objects with implicitly-defined destructors? 13:39 < cfields> so my best guess is... the static vars are created there when the lib is built, so an entry for the dtor is added. But we never use those functions... 13:39 < cfields> so i think it's either: a gcc/lto bug, or some crazy ODR-like issue 13:40 < cfields> oh, also, we build with fvisibility=hidden. when that's off for boost _and_ our build, it links fine 13:41 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds] 13:41 < BlueMatt> lol 13:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 13:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:56 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection] 13:58 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 14:01 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 14:03 -!- jamesob_ [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds] 14:04 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 14:16 < gmaxwell> Did Paul Sztorc talk to anyone here before publishing his thing? (except luke-jr) I want to remark on his " 14:16 < gmaxwell> I wrote the roadmap to try to be representative of a Core / developer position." -- that if so he might have wanted to talk to some of the more frequent ones, it doesn't appear that he did. 14:17 < gmaxwell> But I want a fact-check before saying htat. 14:17 < gmaxwell> s/htat/that/ 14:17 < BlueMatt> i havent heard from him 14:17 < BlueMatt> (nor speak to him specifically about that issue at any point i can recall) 14:21 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 14:26 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 14:32 -!- JackH [~laptop@79-73-186-49.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 14:33 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds] 14:34 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 14:43 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 14:44 -!- timothy [~tredaelli@redhat/timothy] has quit [Client Quit] 14:48 -!- PRab [~chatzilla@c-68-56-234-28.hsd1.mi.comcast.net] has quit [Remote host closed the connection] 14:49 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds] 14:50 < jtimon> images... https://github.com/bitcoin/bitcoin/pull/10757#issuecomment-314581913 14:51 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 14:53 < luke-jr> wumpus: https://github.com/UASF/bitcoin/releases/tag/v0.14.2-uasfsegwit1.0 15:11 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer] 15:15 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 15:16 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 15:20 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 266 seconds] 15:20 -!- jouke [~worst@unaffiliated/komkommer] has quit [Ping timeout: 276 seconds] 15:22 -!- jouke [~worst@2001:1c02:1600:9200:2dfb:4464:a7c7:4c89] has joined #bitcoin-core-dev 15:22 -!- jouke [~worst@2001:1c02:1600:9200:2dfb:4464:a7c7:4c89] has quit [Changing host] 15:22 -!- jouke [~worst@unaffiliated/komkommer] has joined #bitcoin-core-dev 15:25 < cfields> sipa: aha, you were right 15:27 < cfields> i traced the symbol references in linker dumps. as-is, with lto, the destructor gets stuffed into util.o (because it's one of the files where there's a static reference) 15:27 < cfields> but when i comment out the static references in util.cpp, it links fine, and the destructor goes into a boost object (operations.o) 15:28 < cfields> IIRC when it's ambiguous, the linker is free to choose where to put the symbol, as long as it's just added to one object 15:29 < cfields> but with lto, it gets put into util.o. then, the link-order causes boost_filesystem to be unable to find it 15:29 < sipa> cfields: so, you fixed it? 15:30 < cfields> i believe so 15:30 -!- promag [~joao@2001:8a0:fe30:de01:e48d:4241:d22e:770a] has joined #bitcoin-core-dev 15:30 < cfields> 2 fixes: 1 quick hack to use a static string rather than a fs::path, to avoid the issue entirely. 2. the upstream boost fix 15:31 < promag> jtimon: please rename #10757 15:31 < gribble> https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getperblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub 15:35 < jtimon> oh, right, I did s/getperblockstats/getblockstats/ as you suggested...thanks! 15:36 < bitcoin-git> [bitcoin] jnewbery opened pull request #10798: test bitcoin-cli (master...cli_tests) https://github.com/bitcoin/bitcoin/pull/10798 15:43 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...] 15:47 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 15:47 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Ping timeout: 240 seconds] 15:49 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 15:55 < cluelessperson> BlueMatt: So I'm looking at a 3.8ghz Xeon Quad Core, 256 GB PCI SSD 3200MBps Read, 1500MBps Write, 64 GB RAM DDR4, thoughts? 15:55 < cluelessperson> $1400 15:55 < cluelessperson> (rounded up) 15:55 < BlueMatt> -> #bitcoin 15:59 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:00 -!- spinza [~spin@196.212.164.26] has quit [Quit: Coyote finally caught up with me...] 16:00 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 16:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 16:03 -!- ivan_ is now known as ivan 16:06 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-core-dev 16:34 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #bitcoin-core-dev 16:35 -!- Aaronvan_ is now known as AaronvanW 16:37 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 260 seconds] 16:50 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Quit: Page closed] 16:55 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has quit [Quit: lp0 on fire] 17:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:05 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 240 seconds] 17:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:19 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 17:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 17:23 -!- Giszmo [~leo@ip-47-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 17:37 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 17:42 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds] 17:49 -!- btcdrak [uid237747@gateway/web/irccloud.com/x-gkbefysszjhmejxj] has quit [Quit: Connection closed for inactivity] 17:55 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 18:30 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10799: Prevent user from specifying conflicting parameters to fundrawtx (master...2017-07-no-fundraw-conflicts) https://github.com/bitcoin/bitcoin/pull/10799 18:39 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:44 -!- gielbier [~michiel@unaffiliated/gielbier] has quit [Ping timeout: 248 seconds] 18:44 -!- gielbier [~michiel@92-111-70-106.static.chello.nl] has joined #bitcoin-core-dev 18:48 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds] 18:49 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jzxrriaolhvtugcu] has quit [Quit: Connection closed for inactivity] 18:50 -!- Giszmo [~leo@ip-47-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds] 18:51 -!- cryptechonomics [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-dev 18:52 -!- cryptechonomics [~user@cpe-76-175-74-114.socal.res.rr.com] has left #bitcoin-core-dev [] 19:00 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 19:05 -!- Giszmo [~leo@ip-188-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev 19:47 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 19:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:56 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 19:57 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 20:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 20:03 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 276 seconds] 20:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 20:28 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 20:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:40 -!- Giszmo [~leo@ip-188-233.219.201.nextelmovil.cl] has quit [Ping timeout: 268 seconds] 20:44 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 20:46 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 20:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 20:52 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds] 20:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 20:59 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 21:03 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Client Quit] 21:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 21:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 21:25 -!- ivan [~ivan@unaffiliated/ivan/x-000001] has joined #bitcoin-core-dev 21:26 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 21:46 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 21:52 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 22:03 < bitcoin-git> [bitcoin] theuni opened pull request #10800: build: add lto configure option (master...enable-lto) https://github.com/bitcoin/bitcoin/pull/10800 22:14 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 22:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 22:39 < achow101> someone please ban this guy: https://github.com/MIGUELWAXX he keeps spamming the repo 22:54 -!- joelsbeard [~joel@c-24-5-163-171.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 23:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:48 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 23:50 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds] 23:52 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev