--- Day changed Wed Mar 08 2017 00:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:24 < sipa> on what hardware 00:25 < sipa> ? 00:31 < sipa> in particular: do you have hardware acceleration? 00:31 < sipa> if running inside a VM, it may be resorting to software emulation 00:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:45 < warren> model name : Intel(R) Core(TM) i5-4690S CPU @ 3.20GHz 00:45 < warren> used KVM on this hardware before, I'll figure it out 00:49 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 00:49 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 00:53 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 01:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xtyfyvnhytwvgoso] has joined #bitcoin-core-dev 01:28 < jonasschnelli> prioritisetransaction 0 100000000 should lead to (always) include the transaction in the next getblocktemplate call, right? 01:29 < gmaxwell> no, due to caching. 01:30 < gmaxwell> if the block doesn't change IIRC we'll cache the CNB result for up to 30 seconds. 01:30 < jonasschnelli> Is there a way to drain the cache? 01:30 < gmaxwell> mine a new block. 01:31 < gmaxwell> don't call getblocktemplate for (IIRC) 30 seconds before. 01:31 < jonasschnelli> okay... thanks gmaxwell! 01:32 < gmaxwell> Sorry I don't have a more useful suggestion! 01:33 < jonasschnelli> Well... that's already useful. I know now why. 01:36 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 01:39 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:43 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds] 01:45 < Lauda> ping wumpus 01:48 < gmaxwell> what is the gpg undocumented option to restrict recv-key to only fetch a key it already knows? 01:48 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 01:54 -!- Victor_sueca is now known as Victorsueca 01:55 < gmaxwell> --refresh-keys ah ha 01:55 < gmaxwell> Lauda: thanks 01:59 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 02:02 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9947: Add true/false return value to prioritisetransaction (master...2017/03/ptx) https://github.com/bitcoin/bitcoin/pull/9947 02:26 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 02:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 02:32 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 02:33 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has quit [Remote host closed the connection] 02:34 < Lauda> You're welcome. 02:46 -!- slsdhl [~srd@park511.koll.au.dk] has joined #bitcoin-core-dev 02:49 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 02:53 -!- dcousens_ [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 02:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:54 -!- paulyb [892b8baa@gateway/web/freenode/ip.137.43.139.170] has joined #bitcoin-core-dev 02:54 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 02:56 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds] 02:58 < jonasschnelli> Should we allow to add a fee delta on txn's that are not in the mempool, ... right now we do. I hink we can't change that behavior.. 02:59 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 02:59 < dcousens_> Yeah, I personally use the current behaviour of "CAmount &delta = mapDeltas[hash]; delta += nFeeDelta;" to prioritize transactions before they are in the mempool 03:00 < gmaxwell> jonasschnelli: it is an intentional feature that took extra effort to support. Without it, priority is much less effective. 03:01 < gmaxwell> since txn you want to prioritize might not otherwise make it into your mempool at all. 03:01 < jonasschnelli> Yes. I see... maybe the return value then should be wether the transaction was already in the mempool or now. 03:01 < jonasschnelli> *not 03:07 < dcousens_> ooi, in the above statement, "Amount &delta = mapDeltas[hash]; delta += nFeeDelta;", mapDeltas[hash] if unitialized, does it get default constructed to 0 somehow? 03:08 < jonasschnelli> Can anyone help me understand why CreateTransaction (CDummySigner VerifyScript seems to be the problem) if I want to use watch-only addresses (no pubkeys available). 03:09 < jonasschnelli> If the address is P2PKH, it should be capable to calculate the fee, right... 03:09 < jonasschnelli> Guess not possible for P2SH 03:09 < jonasschnelli> *[...] understand why CreateTransaction *fails* 03:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/47510ad3dd51...ac23a7c1f19b 03:18 < bitcoin-git> bitcoin/master 6c1fb73 John Newbery: Improve logging in bctest.py if there is a formatting mismatch 03:18 < bitcoin-git> bitcoin/master ac23a7c MarcoFalke: Merge #9945: Improve logging in bctest.py if there is a formatting mismatch... 03:18 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9945: Improve logging in bctest.py if there is a formatting mismatch (master...improve_bctest_logging) https://github.com/bitcoin/bitcoin/pull/9945 03:19 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 03:28 < bitcoin-git> [bitcoin] practicalswift opened pull request #9949: [bench] Avoid function call arguments which are pointers to uninitialized values (master...avoid-pointers-to-unitialized-values-in-function-calls) https://github.com/bitcoin/bitcoin/pull/9949 03:29 -!- paulyb [892b8baa@gateway/web/freenode/ip.137.43.139.170] has quit [Quit: Page closed] 03:58 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has quit [Quit: Whatever] 03:59 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9790: doc/release-notes: Various cleanups (0.14...0.14-relnotes) https://github.com/bitcoin/bitcoin/pull/9790 04:01 -!- harrymm1 [~wayne@104.222.140.77] has quit [Ping timeout: 268 seconds] 04:13 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 268 seconds] 04:14 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 04:17 -!- harrymm [~wayne@104.222.140.115] has joined #bitcoin-core-dev 04:42 < NicolasDorier> jonasschnelli: you may encounter the same problem I stumbled upon while doing my watchonlyhd stuff 04:42 < NicolasDorier> take a look at https://github.com/bitcoin/bitcoin/pull/9728/files#diff-b2bb174788c7409b671c46ccc86034bdL1859 04:43 < NicolasDorier> basically, watchonly addresses are untrusted if not confirmed 04:43 < NicolasDorier> might be your problem 04:46 < jonasschnelli> NicolasDorier. Thanks... ill have a look 04:46 < NicolasDorier> jonasschnelli: this PR https://github.com/bitcoin/bitcoin/pull/9830 expose the istrusted flag, it might help you to debug 04:50 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 04:50 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:53 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 04:55 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] 05:03 -!- paulyb [c101a6d5@gateway/web/freenode/ip.193.1.166.213] has joined #bitcoin-core-dev 05:10 -!- paulyb [c101a6d5@gateway/web/freenode/ip.193.1.166.213] has quit [Ping timeout: 260 seconds] 05:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ac23a7c1f19b...8bfa13b15b84 05:18 < bitcoin-git> bitcoin/master fdab309 practicalswift: [trivial] Fix typos introduced in 7184e25c80aa8b1629a700bb7a7e290ad0bb2792 05:18 < bitcoin-git> bitcoin/master 8bfa13b MarcoFalke: Merge #9936: [trivial] Fix three typos introduced into walletdb.h in commit 7184e25... 05:18 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #9936: [trivial] Fix three typos introduced into walletdb.h in commit 7184e25 (master...fix-typos-introduced-in-commit-7184e25c) https://github.com/bitcoin/bitcoin/pull/9936 05:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:09 -!- nemgun [~nemgun@105.101.142.246] has joined #bitcoin-core-dev 06:19 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 06:20 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 06:23 -!- MarcoFalke [~none@198.12.116.246] has left #bitcoin-core-dev [] 06:32 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 06:33 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 06:34 -!- nemgun [~nemgun@105.101.142.246] has quit [Read error: Connection reset by peer] 06:34 -!- nemgun [~nemgun@105.101.142.246] has joined #bitcoin-core-dev 06:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds] 06:39 -!- warpo [cce145fe@gateway/web/freenode/ip.204.225.69.254] has joined #bitcoin-core-dev 06:48 < bitcoin-git> [bitcoin] laanwj opened pull request #9951: Wallet database handling abstractions/simplifications (master...2017_03_wallet_dbwrapper) https://github.com/bitcoin/bitcoin/pull/9951 06:51 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 06:52 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev 06:53 < bitcoin-git> [bitcoin] laanwj closed pull request #9900: Ban "invalid messagestart" nodes (master...patch-2) https://github.com/bitcoin/bitcoin/pull/9900 06:56 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 256 seconds] 07:01 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:02 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:04 < BlueMatt> wumpus: (or someone) should set v0.14.0 as a release on github (https://github.com/bitcoin/bitcoin/releases) 07:05 < wumpus> yes 07:23 < bitcoin-git> [bitcoin] laanwj opened pull request #9952: Add historical release notes for 0.14.0 (master...2017_03_014_release_notes) https://github.com/bitcoin/bitcoin/pull/9952 07:26 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bfa13b15b84...6996e066b538 07:26 < bitcoin-git> bitcoin/master 2de6930 Wladimir J. van der Laan: Add historical release notes for 0.14.0 07:26 < bitcoin-git> bitcoin/master 6996e06 Wladimir J. van der Laan: Merge #9952: Add historical release notes for 0.14.0... 07:26 < arubi> release notes link on github releases is wrong, points to master (which also 404s) 07:27 < bitcoin-git> [bitcoin] laanwj closed pull request #9952: Add historical release notes for 0.14.0 (master...2017_03_014_release_notes) https://github.com/bitcoin/bitcoin/pull/9952 07:27 < wumpus> arubi: should be fixed now 07:27 < wumpus> arubi: you checked too early 07:27 < arubi> ah yes 07:27 < arubi> well it still says master :) 07:27 < arubi> oh, that's where it's pointing, thought it should point to the tag? 07:28 -!- warpo [cce145fe@gateway/web/freenode/ip.204.225.69.254] has quit [] 07:28 < wumpus> that's on purpose. It points at the historical release notes in master, that's the most recent version of the release notes for a version 07:28 < arubi> understood 07:29 < wumpus> the one in the tag may be older, e.g. sometimes there are post-mortem fixes, and it can no longer be changed 07:29 < arubi> yea, now I figure the one it points to is kept up to date with the release 07:40 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 07:43 -!- Vinnie_win [vinnie.fal@pdpc/supporter/gold/thevinn] has joined #bitcoin-core-dev 07:44 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 246 seconds] 07:48 < wumpus> normally release notes aren't edited after the release, but it sometimes happens if there's something very wrong 08:00 < arubi> I see where I got confused then, I thought for some reason the link would point to the 0.14 branch, and not the 0.14.0 tag, so at some point when 0.14.1 is released then the link points to the same place, but really no reason for it to work like that :) 08:04 -!- nemgun1 [~nemgun@105.101.93.164] has joined #bitcoin-core-dev 08:07 -!- nemgun [~nemgun@105.101.142.246] has quit [Ping timeout: 240 seconds] 08:26 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9953: Fix shutdown hang with >= 8 -addnodes set (master...2017-03-exit-with-addnode) https://github.com/bitcoin/bitcoin/pull/9953 08:36 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 08:40 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 08:41 -!- slsdhl [~srd@park511.koll.au.dk] has quit [Ping timeout: 260 seconds] 08:52 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection] 08:52 -!- pedrobranco [~pedrobran@bl23-97-35.dsl.telepac.pt] has joined #bitcoin-core-dev 08:53 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:00 -!- slsdhl [~srd@park511.koll.au.dk] has joined #bitcoin-core-dev 09:13 -!- laurentmt [~Thunderbi@85.233.202.4] has joined #bitcoin-core-dev 09:14 -!- laurentmt [~Thunderbi@85.233.202.4] has quit [Client Quit] 09:16 -!- pedrobranco [~pedrobran@bl23-97-35.dsl.telepac.pt] has quit [Remote host closed the connection] 09:17 -!- pedrobranco [~pedrobran@bl23-97-35.dsl.telepac.pt] has joined #bitcoin-core-dev 09:17 -!- slsdhl [~srd@park511.koll.au.dk] has quit [Quit: Leaving.] 09:18 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 240 seconds] 09:19 -!- pedrobranco [~pedrobran@bl23-97-35.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 09:23 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 09:28 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Read error: Connection reset by peer] 09:28 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 10:24 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 10:25 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:40 -!- CubicEarth [~cubiceart@201.227.226.150] has joined #bitcoin-core-dev 10:43 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 10:44 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 10:45 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Max SendQ exceeded] 10:45 < CubicEarth> What would be the computational bottle neck if validation was parallelized to the point of being able to run on a GPU? During chain-sync for example. 10:47 < arubi> I think if you could get signature validation on a GPU that would be cool CubicEarth :) 10:48 -!- Alina-malina [~Alina-mal@37.157.223.66] has joined #bitcoin-core-dev 10:48 -!- Alina-malina [~Alina-mal@37.157.223.66] has quit [Max SendQ exceeded] 10:48 < gmaxwell> CubicEarth: I would be mildly surprised if it were possible to make it faster that way. 10:48 -!- CubicEarth [~cubiceart@201.227.226.150] has quit [Read error: Connection reset by peer] 10:48 < arubi> :( 10:49 < arubi> oh this is -core-dev, sorry 10:49 -!- Alina-malina [~Alina-mal@37.157.223.66] has joined #bitcoin-core-dev 10:49 -!- Alina-malina [~Alina-mal@37.157.223.66] has quit [Changing host] 10:49 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 10:49 -!- CubicEarth [~cubiceart@201.227.226.149] has joined #bitcoin-core-dev 10:49 -!- nemgun1 [~nemgun@105.101.93.164] has quit [Quit: Leaving] 10:52 < wumpus> GPUs are fking unstable on most user's computers 10:53 < gmaxwell> big lesson from mining there, remarkable how bad it was ... I hope things have improved? 10:53 < wumpus> utilizing the CPU and GPU during verification by default would be a good way to cause fires and such :) 10:53 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 10:54 < wumpus> doesn't seem so, especially on laptops it's bad, even if it doesn't overheat immediately there's usually crash issues with ancient drivers, strange edge cases, and so on. Unless you have to deal with GPUs (e.g. game develpoment) I"d suggest staying far from using them for anything to be used by end-users. For research in well-controlled settings/hardware they're ok. 10:56 < wumpus> at least you can troubleshoot on-site then... 11:02 < BlueMatt> gmaxwell: i had to replace the gpu in my workstation because a reasonably-high-end consumer gpu was unstable randomly on a machine that literally only ever displays terminals 11:02 < BlueMatt> they're fucking terrible 11:03 < BlueMatt> the workstation-class ones seem to be stable, but its clear literally no one ever bothered to test the drivers against them 11:03 < CubicEarth> that makes sense for laptops... I was imaging using a typical 4-card mining rig 11:09 < gmaxwell> What was thefeeling around eliminating the requirement for gbtresults on segwit activation? IMO we shouldn't have behavior changes like that triggered by network events, if it is at all possible to avoid. And also changing the version returned to include segwit, even if the flag isn't set-- we're enforce the rules, which is what matters. 11:10 < gmaxwell> and there are plenty of miners who will already process transactions. 11:21 -!- e4xit_ [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Quit: e4xit_] 11:28 -!- CubicEarth [~cubiceart@201.227.226.149] has quit [Remote host closed the connection] 11:38 < sdaftuar> gmaxwell: i'm on board, i was just thinking today abotu coding that up and suggesting it as a backport to the 0.14 branch 11:39 < gmaxwell> yes, well the addnode bug matt is fixing will call for a 0.14.1 at some point. so I was just thinking it would be good to get that done and in it too. 11:39 < sdaftuar> agreed 11:39 < gmaxwell> I'm sorry guys. Didn't make it 24 hours after release before finding something that calls for a 0.14.1. :( 11:45 < BlueMatt> gmaxwell: yea sucks, but oh well 11:56 < warren> wumpus: Recently a friend asked what I thought about some startup that aims to accelerate SATA controllers with "low cost desktop GPU's" ... 11:58 < gmaxwell> I'm sure you must have misheard something. 11:59 < gmaxwell> for example, maybe they intend to accelerate 200 disk raid with 10 disks of parity. 12:01 < TD-Linux> warren, just wait until people ask you to solve all their problems with FPGAs 12:07 -!- wudayoda_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 12:07 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 12:10 < warren> gmaxwell: hand wavy "everything is possible" presentation including that and somehow blockchains. My first question was "Is this reliable?" 12:11 < BlueMatt> ok, whos' blocked getting review/merge? 12:11 * BlueMatt very much is on #9725, and am willing to trade review of that for other things 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt · Pull Request #9725 · bitcoin/bitcoin · GitHub 12:16 < sdaftuar> gmaxwell: how important do you think it is that CreateNewBlock be fast, when invoked post-segwit activation by a miner that doesn't support it? in order to be fast, we'd have to cache extra information in the mempool, which i'm not eager to do unless really necessary 12:17 < sdaftuar> (making it work at all, on the other hand, is not very hard) 12:23 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 12:24 < gmaxwell> sdaftuar: I think it would be okay if it became slower in that case. 12:25 < gmaxwell> my expectation is that we'd eventually go back to the current behavior in a later release. (basically: I think it's fine for a new release to change the interface, it's not so fine for network events to change the interface, if it can be avoided.) 12:26 -!- aalex__ [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds] 12:35 -!- aalex__ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 12:39 -!- aalex_ [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 12:46 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 12:52 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 12:53 -!- moli_ [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 12:54 < luke-jr> BlueMatt: why remove virtual? 12:55 < BlueMatt> luke-jr: because I was told you normally remove virtual if you're using override to indicate that you are the implementor of an interface and not something which will be subclassed and overriden 12:56 < BlueMatt> I dont care either way, talk to ryanofsky 12:58 < ryanofsky> i don't care much either. i suggested it mainly to be consistent with our other code which uses override. and fwiw, google style guide says "For clarity, use exactly one of override, final, or virtual when declaring an override." 13:00 < luke-jr> I was under the impression *only* virtuals could have an override, and unless a method is virtual, overrides would de facto get ignored 13:02 < BlueMatt> no, you have to be implementing a virtual to get override 13:02 < ryanofsky> it's a compile error to write override on a method that's not virtual, so writing both virtual and override is redundant 13:02 < BlueMatt> but dont, yourself, have to be virtual 13:02 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 13:04 < luke-jr> oh, I see, these are on subclasses 13:10 < paveljanik> BlueMatt, should I make torControlThread static as well (one line below gBase in src/torcontrol.cpp)? 13:11 < BlueMatt> paveljanik: anything that can be, probably should be 13:11 < BlueMatt> i mean especially for such a generic name like "base", but I suppose why not 13:11 < paveljanik> ok 13:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 13:30 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 13:36 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 260 seconds] 13:41 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 13:44 -!- Pasha is now known as Cory 14:01 < bitcoin-git> [bitcoin] sdaftuar opened pull request #9955: Don't require segwit in getblocktemplate for segwit signalling or mining (master...2017-03-mining-segwit-changes) https://github.com/bitcoin/bitcoin/pull/9955 14:02 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 14:08 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 14:11 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 14:11 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 14:13 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 14:14 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 14:19 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 14:19 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 14:26 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 14:35 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:35 -!- r0x [xen@2001:41d0:2:599c::685b:47d1] has joined #bitcoin-core-dev 14:38 -!- veleiro [~sleeper@fsf/member/veleiro] has joined #bitcoin-core-dev 14:38 -!- r0x [xen@2001:41d0:2:599c::685b:47d1] has left #bitcoin-core-dev [] 14:56 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] 14:57 -!- CubicEarth [~cubiceart@181.197.4.66] has joined #bitcoin-core-dev 15:00 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has joined #bitcoin-core-dev 15:01 -!- CubicEarth [~cubiceart@181.197.4.66] has quit [Remote host closed the connection] 15:01 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 15:04 < bitcoin-git> [bitcoin] jnewbery opened pull request #9956: Reorganise qa directory (master...reorganise_qa) https://github.com/bitcoin/bitcoin/pull/9956 15:05 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: jnewbery] 15:21 < warren> Is anyone using gitian with qemu-system-x86_64 (not LXC)? It seems that the base-trusty-amd64.qcow2 images generated by make-base-vm are currently unbootable. qemu-system-x86_64 gets stuck with 100% CPU usage on one core, very little memory use, nothing in logs but a localhost:16 VNC port shows it is stuck at trying to boot the disk image. 15:44 -!- CubicEarth [~cubiceart@181.197.4.66] has joined #bitcoin-core-dev 15:48 < luke-jr> warren: I do, but my base VM is somewhat old 15:50 < achow101> warren: I use qemu with gitian and haven't had any issues with make-base-vm 15:51 < warren> I did as recently as last month, but using the latest gitian-builder's make-base-vm the new base-trusty-amd64.qcow2 I get no longer works with gbuild. 15:51 < warren> achow101: how long ago did you make your base image? 15:51 < achow101> whenever 0.14.0rc3 was tagged 15:52 < achow101> (last week I think) 15:54 < bitcoin-git> [bitcoin] deannolan opened pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (master...RPC_refactor) https://github.com/bitcoin/bitcoin/pull/9958 16:05 -!- CubicEar_ [~cubiceart@181.197.4.66] has joined #bitcoin-core-dev 16:06 -!- CubicEarth [~cubiceart@181.197.4.66] has quit [Ping timeout: 246 seconds] 16:10 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev 16:17 -!- bityogi [~textual@208-104-132-26.brvd.dsl.dyn.comporium.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 16:25 -!- CubicEar_ [~cubiceart@181.197.4.66] has quit [] 16:26 < MarcoFalke> funny how the release announcement on twitter comes with a screenshot of java script code 16:26 < gmaxwell> I laughed at that too. 16:26 < MarcoFalke> it should come with a screenshot of the four redundant indentation levels 16:27 < sipa> where does that picture come from? 16:27 < sipa> it's not in the URL linked to 16:27 < achow101> who controls the account? 16:27 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 16:28 < MarcoFalke> maybe ask btcdrak 16:28 < btcdrak> LOL, google image search 16:28 < gmaxwell> there was some popular press article with that picture. 16:28 < gmaxwell> oh no, actually a similar one. 16:29 < gmaxwell> btcdrak: don't do that, for one-- copyright problems. :P 16:29 -!- JackH [~laptop@79-73-184-8.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds] 16:30 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 16:31 < MarcoFalke> jonasschnelli: has a nice one: https://bitcoin.jonasschnelli.ch/img/header.jpg 16:31 < MarcoFalke> Needs more colors, though. 16:31 < btcdrak> yeah 16:45 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev 16:48 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 240 seconds] 16:59 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:05 < gmaxwell> jonasschnelli: sipa: both of you are rehashing old arguments that have already been made to voskuil on the list. He is either flagrantly incompetent or actively working against the public interest. He is not worth your time or attention, and he gets _no say_ in this. Supporting authenticated links is something each indivigual node can decide to do for itself. 17:06 < gmaxwell> sipa: your addnode argument was directly made my me previously in a private email, which he has dishonestly described as a threat (because I said that I thought I would write him to him privately before mentally writing him off, and he responded that this was 'a threat'-- absurd.) 17:08 < gmaxwell> https://0bin.net/paste/zGcQVRFoTt7rsaZH#ZI5dYJ4GVIWYRFmeKzPQ6C3lorBGQ7LV6IrePetem2z the 'threat' 17:08 < gmaxwell> Abusive asshole like that are a big part of the reason I unsubscribed. You just enable them when you argue with them where you don't have to. 17:26 -!- MarcoFalke [~none@198.12.116.246] has left #bitcoin-core-dev [] 17:30 < bitcoin-git> [bitcoin] sdaftuar opened pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (master...2017-03-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/9959 17:37 < gmaxwell> jeremyrubin: I can't make sense of your comment on #9955 17:37 < gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 17:40 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:44 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:40e2:317c:b75:218b] has quit [Quit: .] 17:44 < isle2983> plug for a bitcoin-maintainer-tools PR I just submitted: 17:44 < isle2983> https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/10 17:45 < isle2983> it is a set of functionality previously submitted to contrib/devtool, but closed because it was decided that was the wrong spot 17:46 < isle2983> the pointer was to bitcoin-maintainer-tools, so I ran with that 17:46 < isle2983> the scripts use a common shared framework 17:46 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:bdab:df8e:3885:5518] has joined #bitcoin-core-dev 17:46 < isle2983> hopefully it will help accelerate further automation in the future 17:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xtyfyvnhytwvgoso] has quit [Quit: Connection closed for inactivity] 18:16 -!- wudayoda_ [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Remote host closed the connection] 18:33 < bitcoin-git> [bitcoin] NicolasDorier opened pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960 18:49 -!- harrymm [~wayne@104.222.140.115] has quit [Ping timeout: 240 seconds] 18:51 -!- harrymm [~wayne@104.222.140.115] has joined #bitcoin-core-dev 18:55 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:02 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 19:04 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:08 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 19:13 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 19:14 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 19:18 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 19:23 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 19:44 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 246 seconds] 19:50 < jeremyrubin> gmaxwell: if a miner doesn't want to support segwit, and won't mine them, maybe they should not keep such transactions in their memory pool 19:50 < jeremyrubin> gmaxwell: e.g., to keep room for the most-fee nonsegwit txns 20:12 < luke-jr> jeremyrubin: what if a miner does want to support segwit, but is locked-into mining software that doesn't support it, on some machines? 20:15 < jeremyrubin> this still applies 20:15 < jeremyrubin> they will make more money evicting segwit txs 20:19 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 20:23 -!- jtimon [~quassel@70.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds] 20:25 < luke-jr> jeremyrubin: they won't be supporting segwit with that logic, and they might not make more money either so long as their mempool is a decent size 20:26 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 20:32 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 20:45 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 20:48 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Remote host closed the connection] 20:49 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has joined #bitcoin-core-dev 20:53 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has quit [Ping timeout: 246 seconds] 21:12 < jeremyrubin> luke-jr: false. they can still validate segwit blocks. 21:12 < jeremyrubin> luke-jr: and check the witnesses (full validation) 21:13 < luke-jr> jeremyrubin: all miners need to validate segwit blocks once it activates; that's not support, it's just mining 21:18 < jeremyrubin> that's not completely true. 21:18 < jeremyrubin> A miner can mine a non segwit block, it will just get orphaned by the segwit-mining majority 21:19 < jeremyrubin> (if any of the txs have a witness) 21:20 < jeremyrubin> and even in that case, such a miner might not want segwit transactions in their mempool if they can't mine them? 21:24 < warren> I suspect your discussion there may be confused by absolutism on one hand, and a common misconception that I also made on the other. 21:31 < jeremyrubin> warren: that sentence doesn't say anything 21:32 < jeremyrubin> In general, if I am a miner, and I have a 10 MB mempool (let's say), and there is a backlog of 100MB of transactions, and the top 10MB are all segwit transactions I absolutely want to exclude them from my mempool if I can't mine them 21:34 < warren> jeremyrubin: pre-segwit nodes see segwit transactions as non-standard and it won't enter the mempool to begin with 21:36 < warren> nevermind, I don't care enough about this to continue 21:37 < jeremyrubin> warren: context is a miner wanting to be a fully validating segwit node running on the latest, but with segwit incompatible mining hardware #9955 21:37 < gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information. 21:39 < jeremyrubin> The question is, if you're never going to mine a transaction why would you want it in your mempool? (other than, perhaps, compact blocks) 21:40 < luke-jr> jeremyrubin: it would be fairly irresponsible for a miner to have a mere 10 MB mempool in the first place.. 21:41 < luke-jr> the default of 300 MB is for non-mining nodes 21:42 < jeremyrubin> luke-jr: was only for convenience picking a number. 21:42 < luke-jr> point is they should have more than enough 21:43 < jeremyrubin> no 21:43 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has joined #bitcoin-core-dev 21:43 < jeremyrubin> there is actually an attack that you can do with a more well resourced miner (larger mempool) against a less well resourced node that can't mine segwit txns 21:44 < jeremyrubin> e.g., let's say I have a consistent segwit fee around 10 sat/byte, filling up at all times the top 10MB of the mempool 21:44 < jeremyrubin> all txns will be selected from that range always 21:45 < jeremyrubin> so then, I issue 290 MB of txns that are at 9 sat/byte, with segwit, such that they won't be mined 21:46 < jeremyrubin> let's say I also have a bunch on non-segwit txns at 9 sat/byte 21:46 < jeremyrubin> I can push them out with my segwit txns 21:47 < jeremyrubin> so that your less well resourced miner now has a mempool full of txns you can't mine 21:47 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has quit [Ping timeout: 246 seconds] 22:19 < gmaxwell> jeremyrubin: we don't know in advance of someone calling GBT what they're going to call it with, and they may call it with a mix of arguments. 22:20 < gmaxwell> jeremyrubin: their normal operation as a node shouldn't be impared ... e.g. logical conclusion of what you suggest is that someone who doesn't mine shouldn't have a mempool at all-- which is clearly not true, as its integral to other functions of a node (fast block propagation, fee estimation, txn relay) 22:21 < gmaxwell> luke-jr: you say a lot of confusing things, there is nothing wrong with having a 300 mb mempool as a miner and CNB is effectively the same speed for all mempool sizes. Having a small mempool may also adversely impact your block reception speed. 22:22 < gmaxwell> tiny mempools also prevent users from being able to create low priority transactions that get mined in off hours... which is bad because without a supply of lower priority transactions the spare capacity will instead by used for less useful/efficient uses that continually rebroadcast. 22:22 < luke-jr> gmaxwell: I'm saying a small mempool is bad.. 22:22 < gmaxwell> oh okay! 22:23 < gmaxwell> I had read your comment backwards. 22:23 < gmaxwell> jeremyrubin: okay thanks for at least clarifying what you meant. (I don't think it's a good idea at all-- but at least it makes logical sense to me now) 22:25 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Remote host closed the connection] 22:25 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev 22:27 < jeremyrubin> gmaxwell: that's fair; what I'm suggesting might be better off as a startup time argument 22:28 < jeremyrubin> gmaxwell: I also think that you can relay a txn w/o having it in your mempool (e.g., to your immediate peers) 22:29 < jeremyrubin> gmaxwell: w.r.t. fee estimation, you could collect the fee estimate information for such transactions without storing them 22:29 < sipa> jeremyrubin: BIP152 relay speed depends on having transactions in your mempool 22:29 < sipa> (or at least, stored somewhere) 22:29 < gmaxwell> jeremyrubin: not as soon as there is a dependency, and we also use the mempool as a dynamic rate control. 22:29 < jeremyrubin> yes, as I said, compact blocks is the place where it does make sense to keep them 22:30 < gmaxwell> jeremyrubin: you have to remember information about them, it could be just their IDs and feerates, rather than the whole things. but you would get less accurate results since you'd overestimate the time it took for things that were evicted. 22:30 < gmaxwell> In any case what you are suggesting is 99% orthorgonal, since you do not know at the rest of operation what your future GBT calls will be. 22:32 < jeremyrubin> yeah; this would only make sense where you know that none of your calls would need it 22:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 22:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 22:37 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has joined #bitcoin-core-dev 22:41 -!- juscamarena [~justin@47.148.176.74] has quit [Remote host closed the connection] 22:41 -!- dodomojo [~goksinen@2604:2000:c591:8400:1ce2:f666:7a3f:60fc] has quit [Ping timeout: 246 seconds] 22:42 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev 22:42 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 22:43 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:43 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 22:43 -!- chris2000 [~chris2000@p5DCB4EF0.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 22:47 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Ping timeout: 240 seconds] 23:13 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6996e066b538...c047b1663d47 23:13 < bitcoin-git> bitcoin/master 8a52281 Karl-Johan Alm: Refactor: Remove using namespace from wallet/ 23:13 < bitcoin-git> bitcoin/master a57845c Karl-Johan Alm: Refactor: Remove using namespace from util* 23:13 < bitcoin-git> bitcoin/master c047b16 Wladimir J. van der Laan: Merge #9643: [refactor] Remove using namespace from wallet/ & util*... 23:13 < bitcoin-git> [bitcoin] laanwj closed pull request #9643: [refactor] Remove using namespace from wallet/ & util* (master...no-using-namespace-wallet-util) https://github.com/bitcoin/bitcoin/pull/9643 23:16 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c047b1663d47...8152d3fe57a9 23:16 < bitcoin-git> bitcoin/master f3c264e Karl-Johan Alm: Refactor: Remove using namespace from rpc/ 23:16 < bitcoin-git> bitcoin/master 8cbfc4e Karl-Johan Alm: Refactor: Remove using namespace from script/ 23:16 < bitcoin-git> bitcoin/master 8152d3f Wladimir J. van der Laan: Merge #9476: [refactor] Remove using namespace from rpc/ & script/ sources... 23:16 < bitcoin-git> [bitcoin] laanwj closed pull request #9476: [refactor] Remove using namespace from rpc/ & script/ sources (master...no-using-namespace-rpc-script) https://github.com/bitcoin/bitcoin/pull/9476 23:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 23:28 < bitcoin-git> [bitcoin] laanwj closed pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (master...RPC_refactor) https://github.com/bitcoin/bitcoin/pull/9958 23:31 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 23:36 -!- dodomojo [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 264 seconds] 23:41 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:49 < wumpus> okay, that removes the last uses of "using namespace" in the code (apart from one in the tests) 23:50 < sipa> nice 23:51 < wumpus> I can imagine it's a bit painful for some patches (I have some rebasing to do now, too) but at least this is only a one-time thing 23:53 < paveljanik> small pain for big gain! 23:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gmfiwlfbwmbcccro] has joined #bitcoin-core-dev