12015-11-09T00:21:34  *** Yoghur114 has joined #bitcoin-core-dev
  22015-11-09T00:34:09  *** Thireus has quit IRC
  32015-11-09T00:50:53  *** CodeShark has joined #bitcoin-core-dev
  42015-11-09T00:51:08  *** CodeShark has quit IRC
  52015-11-09T00:51:29  *** CodeShark has joined #bitcoin-core-dev
  62015-11-09T01:12:03  *** CodeShark has quit IRC
  72015-11-09T01:12:23  *** CodeShark has joined #bitcoin-core-dev
  82015-11-09T01:13:30  *** CodeShark_ has joined #bitcoin-core-dev
  92015-11-09T01:14:28  *** CodeShark is now known as Guest88917
 102015-11-09T01:14:36  *** CodeShark_ has quit IRC
 112015-11-09T01:14:40  *** Guest88917 has quit IRC
 122015-11-09T01:30:35  *** Yoghur114 has quit IRC
 132015-11-09T01:44:24  *** Ylbam has quit IRC
 142015-11-09T02:12:00  *** Guest23423 has joined #bitcoin-core-dev
 152015-11-09T02:14:44  *** Guest23423 has quit IRC
 162015-11-09T02:14:44  *** Arnavion has quit IRC
 172015-11-09T02:15:01  *** Arnavion has joined #bitcoin-core-dev
 182015-11-09T02:38:14  *** Arnavion has quit IRC
 192015-11-09T02:38:31  *** Arnavion has joined #bitcoin-core-dev
 202015-11-09T03:34:41  *** dcousens has joined #bitcoin-core-dev
 212015-11-09T03:36:47  <dcousens> Is there any difference to minReasonableRelayFee and minRelayTxFee ?
 222015-11-09T03:39:20  <dcousens> I'm not sure why there is two, but it seems the minReasonableRelayFee is not kept in sync with minRelayTxFee, any one know why?
 232015-11-09T04:02:21  *** JackH has quit IRC
 242015-11-09T04:09:47  *** jgarzik has quit IRC
 252015-11-09T04:12:48  <dcousens> aye, the `-minrelaytxfee` seems to have no effect at all on `estimatefee` or the mempool in general
 262015-11-09T04:12:52  <dcousens> Is that intended?
 272015-11-09T04:13:43  <dcousens> (Or am I missing something)
 282015-11-09T04:31:16  <dcousens> Also, is there a reason estimatefee returns `-1` if `nblocks` is > 25?
 292015-11-09T05:00:46  *** gribble has quit IRC
 302015-11-09T05:12:48  *** Thireus has joined #bitcoin-core-dev
 312015-11-09T05:16:42  *** gribble has joined #bitcoin-core-dev
 322015-11-09T05:30:05  <GitHub157> [bitcoin] laanwj opened pull request #6969: doc: there is no libboost-base-dev, add missing sudo in release notes (master...2015_11_docfix) https://github.com/bitcoin/bitcoin/pull/6969
 332015-11-09T05:46:48  *** CodeShark has joined #bitcoin-core-dev
 342015-11-09T06:09:16  <wumpus> fingers itch to merge #6954
 352015-11-09T06:10:01  <Luke-Jr> wumpus: Is it possible to generate/use a cookie file in addition to the rpcuser/pass?
 362015-11-09T06:10:22  <wumpus> no, only one authentication method at a time is supported
 372015-11-09T06:10:29  <Luke-Jr> k
 382015-11-09T06:10:42  <Luke-Jr> I guess -rpcpassword= does it for debugging purposes
 392015-11-09T06:15:14  <Luke-Jr> hrm, any way to access strDataDir QSettings without Qt? :/
 402015-11-09T06:16:29  <Luke-Jr> thoughts on a bitcoin-cli -printdatadir option or something?
 412015-11-09T06:16:45  <Luke-Jr> although it's unlikely to be in PATH on Windows.. so maybe that won't work
 422015-11-09T06:17:04  <Luke-Jr> wait, is that a bug for Core? that bitcoin-cli won't find -qt's cookie file?
 432015-11-09T06:17:10  <dcousens> Luke-Jr: the datadir will be in the same line you're executing?
 442015-11-09T06:17:31  <Luke-Jr> dcousens: bitcoin-qt supports overriding the data dir from a QSettings value
 452015-11-09T06:17:32  <wumpus> qt has its own settings, bitcoind/bitcoin-cli are not able to access those
 462015-11-09T06:17:39  <dcousens> ah
 472015-11-09T06:17:42  <wumpus> that's not a bug
 482015-11-09T06:17:50  <Luke-Jr> wumpus: what's the point of the cookie then?
 492015-11-09T06:18:20  <wumpus> to let bitcoind and bitcoin-cli communicate given just the datadir
 502015-11-09T06:18:38  <Luke-Jr> …
 512015-11-09T06:19:00  <Luke-Jr> awful lot considering bitcoin-cli is just a testing tool, and bitcoind users should be capable of configuring bitcoin.conf anyway :x
 522015-11-09T06:19:02  <wumpus> pass the right datadir to bitcoin-cli and it should work
 532015-11-09T06:19:54  <wumpus> well other software could use it too, but sure it needs to find out what the datadir is, or let the user point them at it
 542015-11-09T06:20:15  <Luke-Jr> I thought the whole point of the cookie file was so Bitcoin-Qt users didn't need to configure RPC explicitly
 552015-11-09T06:20:52  <wumpus> yes, it is
 562015-11-09T06:21:18  <Luke-Jr> but there's no reasonable way to get to it
 572015-11-09T06:21:26  <wumpus> any software that knows the bitcoin data dir can communicate with bitcoin{d,qt} if server=1
 582015-11-09T06:21:41  <wumpus> if it doesn't it needs to be pointed at it
 592015-11-09T06:23:14  <Luke-Jr> would it be terrible to have Bitcoin-Qt get strDataDir from a special QSettings that explicitly uses <default datadir>/datadir.ini or something?
 602015-11-09T06:23:29  <Luke-Jr> or better yet, ignore strDataDir for cookie purposes?
 612015-11-09T06:24:03  <wumpus> sure, another option would be to ignore the datadir completely
 622015-11-09T06:24:24  <wumpus> e.g. tor drops the cookie file in /var/... by default
 632015-11-09T06:24:32  <wumpus> then again, how to handle multiple instances in that case
 642015-11-09T06:24:39  <wumpus> I think putting it in the datadir makes sense
 652015-11-09T06:24:47  <wumpus> you can override the cookie path to be something else
 662015-11-09T06:24:52  <Luke-Jr> multiple Qt instances can't use the QSettings for datadir anyway
 672015-11-09T06:25:21  <Luke-Jr> if the user has to override anything, it defeats the purpose of being zero-configuration <.<
 682015-11-09T06:25:25  <wumpus> -rpccookiefile=/var/run/bitcoindcookie
 692015-11-09T06:25:41  <wumpus> just look in the registry, find the data dir, and use that
 702015-11-09T06:26:15  <Luke-Jr> that's a lot of code, considering Mac and Linux do it differently
 712015-11-09T06:26:20  <wumpus> normally you can assume that the cookie is in the data directory along with the other files, that's a feature not a  bug
 722015-11-09T06:26:33  <dcousens> Any ideas on the question I had before RE minReasonableRelayFee being out of sync with minRelayTxFee, is that intentional? In terms of the estimator policy.  All good if it is, but, it'd be nice to maybe just add a comment there to reassure its not just a missing reference
 732015-11-09T06:26:34  <wumpus> you can also use QSettings if your application is qt-based
 742015-11-09T06:26:40  <Luke-Jr> it's not even C++
 752015-11-09T06:27:27  <wumpus> yes it's some code, maybe we can make a libfindbitcoindatadir ...
 762015-11-09T06:27:41  <Luke-Jr> ugh
 772015-11-09T06:28:00  <gmaxwell> wait why isn't bitcoin-qt and bitcoin-cli finding the same datadir?!
 782015-11-09T06:28:04  <wumpus> although I think it's a  bad idea, as it wouldn't handle multiple instances, you need a way to choose a data directory anyway
 792015-11-09T06:28:39  <wumpus> bitcoin-qt allows choosing a data directory on first start in the GUI, this is stored inthe qt settings
 802015-11-09T06:28:45  <wumpus> bitcoin-cli and bitcoind don't care about that
 812015-11-09T06:28:47  <Luke-Jr> gmaxwell: bitcoin-qt gets datadir from Windows registry, Mac registry-equivalent, or an INI file on Linux; based on user input at first run
 822015-11-09T06:29:28  <Luke-Jr> wumpus: multiple instances can't mix with QSettings datadir period, unless I am missing something?
 832015-11-09T06:29:55  <wumpus> Luke-Jr: that's true. The datadir from QSettings is seen as a default, it's still possible to override it from the command line
 842015-11-09T06:30:16  <Luke-Jr> wumpus: so what if cookie file uses the same logic as bitcoin-cli for datadir? this seems to work in all cases..?
 852015-11-09T06:30:36  <Luke-Jr> if it's overridden via bitcoin.conf or cmdline, it uses that; otherwise the platform default
 862015-11-09T06:30:37  *** ParadoxSpiral has joined #bitcoin-core-dev
 872015-11-09T06:32:24  <wumpus> dcousens: -1 for estimatefee means 'unknown'
 882015-11-09T06:32:47  <dcousens> wumpus: why not just give back an error
 892015-11-09T06:32:54  <wumpus> dcousens: don't know about minReasonableRelayFee/minRelayTxFee
 902015-11-09T06:33:00  <wumpus> dcousens: because
 912015-11-09T06:33:18  <Luke-Jr> …
 922015-11-09T06:33:59  <dcousens> (because ...?)
 932015-11-09T06:34:20  <wumpus> dcousens: yes I don't know, the interface was written in this way not that way
 942015-11-09T06:34:36  <wumpus> it's just a choice that was made at some point that made sense
 952015-11-09T06:34:38  <wumpus> or something
 962015-11-09T06:34:56  <dcousens> ok
 972015-11-09T06:35:02  <wumpus> if you go change it around now then people will complain about that
 982015-11-09T06:35:21  <wumpus> the values it can return are documented in the RPC help
 992015-11-09T06:35:51  <dcousens> that wasn't my main question, just something I noticed that was odd why playing with -minrelaytxfee and noticing it had no effect on the estimation algorithm
1002015-11-09T06:35:53  <wumpus> that's everything of an interface definition that we have, asking why it doesn't behave otherwise is quite pointless
1012015-11-09T06:37:23  <Luke-Jr> wumpus: if I made cookies ignore QSettings, will you accept it?
1022015-11-09T06:37:46  <wumpus> Luke-Jr: I think it's strange to make something ignore qsettings
1032015-11-09T06:38:28  <wumpus> Luke-Jr: it's a valid concern and maybe reason to re-think where the cookie file gets placed, but 'let's ignore qsettings' sounds like a terrible hack
1042015-11-09T06:38:40  <wumpus> then it will make *two* data directories
1052015-11-09T06:39:41  <gmaxwell> using something QT specific for handling finding the datadir on windows was probably what should have been avoided, since bitcoind and bitcoin-cli also need to find the data directory.
1062015-11-09T06:39:57  <Luke-Jr> it's tempting to change this to write to bitcoin.conf instead of QSettings then
1072015-11-09T06:40:06  <wumpus> NO NO NO NO
1082015-11-09T06:40:08  <Luke-Jr> wouldn't an append-only be safe?
1092015-11-09T06:40:09  <wumpus> don't write to bitcoin.conf
1102015-11-09T06:40:12  <wumpus> goddamnit
1112015-11-09T06:40:17  <Luke-Jr> sigh
1122015-11-09T06:40:37  <gmaxwell> then you have the "how do you find bitcoin.conf" problem.
1132015-11-09T06:40:46  <wumpus> no it's not safe, software should not write to its configuration file,  it can't even be asssumed to be writable
1142015-11-09T06:40:50  <dgenr8> writing to bitcoin.conf should be controlled by a setting in bitcoin.conf
1152015-11-09T06:40:52  <Luke-Jr> gmaxwell: that's at least possible to solve
1162015-11-09T06:40:55  <wumpus> that's why I went with the cookie solution in the first place
1172015-11-09T06:41:13  <gmaxwell> Luke-Jr: it reduces to the same problem, finding the data directory.
1182015-11-09T06:41:13  <wumpus> otherwise I'd just have made it write a rpcuser and rpcpassword to bitcoin.conf
1192015-11-09T06:41:38  <Luke-Jr> gmaxwell: minus QSettings
1202015-11-09T06:42:03  <wumpus> bitcoin.conf is usually in the same directory as the cookie so it won't avoid *any* problems
1212015-11-09T06:42:21  <Luke-Jr> if the data directory cannot be overridden by QSettings, the problem is solved.
1222015-11-09T06:42:30  <wumpus> yes, let's rip that feature out again
1232015-11-09T06:42:43  <wumpus> why would people want a user friendly dialog to choose the datadir
1242015-11-09T06:42:46  <wumpus> what a stupid thing
1252015-11-09T06:42:46  <Luke-Jr> …
1262015-11-09T06:43:18  <gmaxwell> Luke-Jr: yes if you make the datadir not actually configurable then the issue of finding it goes away...
1272015-11-09T06:43:27  <wumpus> maybe 1% of users actually use bitcoin-qt with bitcoin-cli, 0.1% uses it with a changed datadir through qt
1282015-11-09T06:43:55  <wumpus> most people that want to use RPC with bitcoin-qt will use the debug console
1292015-11-09T06:44:10  <gmaxwell> wumpus: it is a bit broken that changing your datadir breaks bitcoind / bitcoin-cli from finding it.
1302015-11-09T06:44:16  <Luke-Jr> wumpus: my main concern is BFGMiner, not bitcoin-cli
1312015-11-09T06:44:30  <gmaxwell> wumpus: e.g. joinmarket and bfgminer and such need to find the rpc stuff too.
1322015-11-09T06:44:53  <wumpus> gmaxwell: qsettings is the qt equivalent of adding command line arguments, you can pass a datadir to bitcoin-cli and it will work
1332015-11-09T06:45:41  <gmaxwell> wumpus: datadir isn't a qt specific thing. Finding the default datadir via the registery is the reasonable thing to do on windows, sure. requiring QT for that is less so.
1342015-11-09T06:46:17  <wumpus> yes because we really want to write our own registry/everyOSsettingsmechanism wrappers...
1352015-11-09T06:46:17  <Luke-Jr> I'm sure there's some way to avoid Qt for it, but that means implementing each platform's stuff
1362015-11-09T06:46:43  <wumpus> Qt is not strictly required though, other applications can read bitcon's datadir from the registry without qt
1372015-11-09T06:46:47  *** ParadoxSpiral has quit IRC
1382015-11-09T06:46:59  <gmaxwell> wumpus: sometimes we have to... there are dozens of windows ifdefs in the code.  Unless you think linking bitcoind/bitcoin-cli to QT is a better plan. :)
1392015-11-09T06:47:00  <wumpus> but we use qt because that's available anyway
1402015-11-09T06:47:10  <wumpus> and we don't want piles of extra codes to maintain
1412015-11-09T06:47:14  <wumpus> sigh
1422015-11-09T06:47:50  <wumpus> there's tons of windows ifdefs in the code so let's add even more
1432015-11-09T06:48:03  <gmaxwell> wumpus: take a step back, ignore how its implemented. The behavior of our own compoents looking in different places due to internal architecture reasons and to no benefit to the user is surprising and suboptimal.
1442015-11-09T06:48:10  <wumpus> I'd prefer to reduce the amount of platform dependent code
1452015-11-09T06:48:42  <wumpus> well at least it's working for most people now, it's one of the things that is hardly ever complained about
1462015-11-09T06:48:48  <gmaxwell> I prefer to reduce the amount of platform dependant code too. But that doesn't mean that we should be disfunctional in some cases where a bit is needed to prevent disfunction.
1472015-11-09T06:48:56  <wumpus> there are tons of things *really* broken, this is not one of them!
1482015-11-09T06:50:17  <wumpus> no, it's not disfunctional... never mind
1492015-11-09T06:51:27  <wumpus> go ahead, implement it some way else, just make really sure it's backward compatible
1502015-11-09T06:54:12  <gmaxwell> Luke-Jr: I think we could probably just add code that reads the registry in the same way RandAddSeedPerfmon and looks to the same place QT looks, and call that from bitcoind/bitcoin-cli on windows, and document the location so other programs can look. No?
1512015-11-09T06:55:10  <Luke-Jr> gmaxwell: wouldn't make implementing it externally any easier than how it currently is.
1522015-11-09T06:56:16  <Luke-Jr> I'm sure QSettings has some well-defined location/format so things are backward compatible.
1532015-11-09T06:56:17  *** Ylbam has joined #bitcoin-core-dev
1542015-11-09T06:56:58  <gmaxwell> Luke-Jr: well externally is going to have to deal with the OS specific way of finding things, regardless. But that can be made arbritarily easier through better documentation.
1552015-11-09T06:57:16  * wumpus really likes 'better documentation' instead of 'adding piles of code'
1562015-11-09T06:58:08  <Luke-Jr> supporting cookies was already going to be a major chore, so I'm inclined to just not do so at this point
1572015-11-09T06:58:39  <gmaxwell> Luke-Jr: this has nothing to do with cookies though.
1582015-11-09T06:58:46  <gmaxwell> You'd fail to find the config location.
1592015-11-09T06:58:58  <gmaxwell> wumpus: I'd still suggest adding (hopefully) 1/2 LOC: code to use RegQuery to find the same location in bitcoind/bitcoin-cli.
1602015-11-09T06:58:59  <wumpus> indeed it's the same for finding bitcoin.conf
1612015-11-09T06:59:05  <Luke-Jr> does bitcoin-qt use strDataDir for the config location too? :/
1622015-11-09T06:59:15  <wumpus> yes
1632015-11-09T06:59:20  <Luke-Jr> gmaxwell: you're forgetting Mac and Linux..
1642015-11-09T06:59:22  <wumpus> it uses it to set -datadir
1652015-11-09T06:59:36  <wumpus> (which generally, unless you override it with -conf, specifies the configuration file location as well)
1662015-11-09T06:59:48  <Luke-Jr> bleh
1672015-11-09T07:00:08  <wumpus> bitcoin, by design, only has one datadir. If you move it, everything moves with it
1682015-11-09T07:00:20  <gmaxwell> Luke-Jr: nothing is special on linux. There is no magical registry path location there.  I'm not well enough informed about the mac parallel.
1692015-11-09T07:00:31  <Luke-Jr> gmaxwell: hehehe.. yes it is
1702015-11-09T07:00:56  <Luke-Jr> ~/.config/Bitcoin/Bitcoin-Qt.conf
1712015-11-09T07:00:56  <wumpus> in linux it's just a file
1722015-11-09T07:01:09  <gmaxwell> what do we have an installer just setting a gconf thing for it on linux too?
1732015-11-09T07:01:21  <Luke-Jr> gmaxwell: it's not part of the installer
1742015-11-09T07:01:59  <wumpus> however you turn it, finding the datadir was always going to be an OS-specific affair
1752015-11-09T07:02:20  <Luke-Jr> wumpus: hm, that's a point.. I guess I must already have some ifdefs going on
1762015-11-09T07:03:02  <gmaxwell> even if it wasn't configurable, the defaults are different.
1772015-11-09T07:12:33  *** NLNico has joined #bitcoin-core-dev
1782015-11-09T07:40:47  *** Thireus has quit IRC
1792015-11-09T07:45:25  <GitHub126> [bitcoin] laanwj opened pull request #6970: Fix crash in validateaddress with -disablewallet (master...2015_11_rpc_validateaddress_crash) https://github.com/bitcoin/bitcoin/pull/6970
1802015-11-09T08:14:24  *** guest234234 has joined #bitcoin-core-dev
1812015-11-09T08:15:17  *** guest234234 has quit IRC
1822015-11-09T08:16:19  *** guest234234 has joined #bitcoin-core-dev
1832015-11-09T08:16:58  *** guest234234 has quit IRC
1842015-11-09T08:23:36  <Luke-Jr> FWIW, a KDE developer in #qt told me if it needs to be accessed from other software, don't use QSettings and write our own :/
1852015-11-09T08:23:46  <Luke-Jr> (I asked a while ago when it was ongoing discussion)
1862015-11-09T08:28:51  *** Thireus has joined #bitcoin-core-dev
1872015-11-09T08:34:03  *** JackH has joined #bitcoin-core-dev
1882015-11-09T08:34:06  <wumpus> won't 'write your own' effectively end up reimplementing qsettings? you need to do something for every OS
1892015-11-09T08:37:05  <wumpus> not saying that is not the way forward to 'find' the same datadir in bitcoin-cli and bitcoind, as well as other software, but it doesn't quite make it easier
1902015-11-09T08:38:56  <wumpus> oops accidentally had 'debian desktop environment' on while installing a VM, was wondering why it was pulling 2300+ packages in debian 8 :-)
1912015-11-09T08:44:51  *** Thireus has quit IRC
1922015-11-09T08:57:20  *** BashCo has quit IRC
1932015-11-09T09:15:39  *** BashCo has joined #bitcoin-core-dev
1942015-11-09T09:17:40  *** NLNico has quit IRC
1952015-11-09T09:29:32  *** Thireus has joined #bitcoin-core-dev
1962015-11-09T10:13:02  *** rubensayshi has joined #bitcoin-core-dev
1972015-11-09T10:22:07  <wumpus> executables for 0.11.2rc1 are live: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/   sorry for the delay
1982015-11-09T10:25:25  *** jtimon has quit IRC
1992015-11-09T10:27:44  <GitHub133> [bitcoin] laanwj closed pull request #6968: [Docs] First-draft release notes for 0.11.2RC1 (0.11...release-notes-0.11.2) https://github.com/bitcoin/bitcoin/pull/6968
2002015-11-09T10:27:45  <GitHub138> [bitcoin] laanwj pushed 4 new commits to 0.11: https://github.com/bitcoin/bitcoin/compare/984587ac5d3e...3dcb390fe9e2
2012015-11-09T10:27:46  <GitHub138> bitcoin/0.11 40941d9 David A. Harding: [Docs] First-draft release notes for 0.11.2RC1
2022015-11-09T10:27:46  <GitHub138> bitcoin/0.11 929b2c7 David A. Harding: [docs] Minor revisions to 0.11.2RC1 release notes...
2032015-11-09T10:27:47  <GitHub138> bitcoin/0.11 9149589 David A. Harding: [docs] 0.11.2 release notes: add sipa graphs & leveldb note...
2042015-11-09T10:29:55  <harding> wumpus: note those release notes still have a FIXME in them for a version of libblkmaker that supports v4 blocks.
2052015-11-09T10:30:15  <wumpus> I know, but good enough for an rc :)
2062015-11-09T10:30:28  <wumpus> thanks again for writing them
2072015-11-09T10:31:48  <harding> My pleasure; thanks for writing them for every other release!
2082015-11-09T10:32:18  *** kanzure has quit IRC
2092015-11-09T10:57:57  <GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ee149a6db25...92701b3b8918
2102015-11-09T10:57:57  <GitHub67> bitcoin/master 2980a18 Wladimir J. van der Laan: Fix crash in validateaddress with -disablewallet...
2112015-11-09T10:57:57  <GitHub67> bitcoin/master 92701b3 Wladimir J. van der Laan: Merge pull request #6970...
2122015-11-09T10:58:07  <GitHub130> [bitcoin] laanwj closed pull request #6970: Fix crash in validateaddress with -disablewallet (master...2015_11_rpc_validateaddress_crash) https://github.com/bitcoin/bitcoin/pull/6970
2132015-11-09T10:59:31  *** AtashiCon has quit IRC
2142015-11-09T11:03:09  *** AtashiCon has joined #bitcoin-core-dev
2152015-11-09T11:09:51  <GitHub161> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/92701b3b8918...6176e9bf3d55
2162015-11-09T11:09:52  <GitHub161> bitcoin/master 6dd3a44 MarcoFalke: translations: Don't translate markdown or force English grammar
2172015-11-09T11:09:52  <GitHub161> bitcoin/master 6176e9b Wladimir J. van der Laan: Merge pull request #6962...
2182015-11-09T11:09:56  <GitHub43> [bitcoin] laanwj closed pull request #6962: translations: Don't translate markup or force English grammar (master...MarcoFalke-2015-translations) https://github.com/bitcoin/bitcoin/pull/6962
2192015-11-09T11:38:13  <wumpus> it's so annoying how in C functions like strtol, isspace, etc are affected by the locale. It's as if they had a discussion while designing the C library on how to break programs as subtly as possible, and make behavior of functions almost like you expect but not quite
2202015-11-09T11:41:11  <wumpus> (a common pattern also with functions like strncat, which writes one byte more than you'd expect, a trap that resulted in tons of suffering for decennia)
2212015-11-09T11:41:19  *** kanzure has joined #bitcoin-core-dev
2222015-11-09T11:41:29  <wumpus> it should be forbidden to use C and its cursed offspring for anything such as string processing
2232015-11-09T11:41:30  <gmaxwell> wumpus: yea, there are a bunch of multimedia file formats where there are subtle incompatiblities in every implementation because of number in "ascii" headers.
2242015-11-09T11:41:50  <gmaxwell> You can change your locale in the program, but doing so will change it in other threads.. not exactly nice to do in libraries.
2252015-11-09T11:42:50  <wumpus> yes that solves one problem but causes many others. We tried forcing the locale to C in bitcoin for a while but this messed with file name encodings on windows.
2262015-11-09T11:43:07  <wumpus> solve one subtle problem, create another
2272015-11-09T11:44:09  <phantomcircuit> just pause world, change locale to c, call strtol, change back to whatever, and unpause world
2282015-11-09T11:44:12  <phantomcircuit> no problem
2292015-11-09T11:44:14  * phantomcircuit runs
2302015-11-09T11:45:00  <gmaxwell> Well for example, you could change it just around the single point(s) you need C locale-- at least for the specific problem of file format compatiblity; but ... threads break that. so to fix this elsewhere I've had to just rewrite those C parser functions.
2312015-11-09T11:45:28  <wumpus> phantomcircuit: travel back in time and ... try to convince Dennis Ritchie to not make this awful mistake
2322015-11-09T11:45:52  <gmaxwell> wumpus: thats really a subcase of my maxium about strings being doom. :)  Other languages have their own string awfulness. :(
2332015-11-09T11:46:17  <wumpus> yes, typical C, inthe end you have to roll everything yourself, because the library support sucks
2342015-11-09T11:46:17  <gmaxwell> (often around unicode)
2352015-11-09T11:46:44  <wumpus> and if it happens to not suck on your platform, be prepared to do that when making your application portable
2362015-11-09T11:47:33  <wumpus> well other languages also have issues, but usually not as dangerous
2372015-11-09T11:47:49  <gmaxwell> yea, then you end up somewhere where someone thought 'UCS-2' was a good idea... and then you want to carry some chinese characters that aren't part of the BMP. :)
2382015-11-09T11:48:28  <gmaxwell> and fun like: https://en.wikipedia.org/wiki/Bush_hid_the_facts
2392015-11-09T11:48:29  <wumpus> yes, typical C, inthe end you have to roll everything yourself, because the library support sucks <- and of course while doing that you write it half assed, so it walks out of a buffer somewhere... happiness, more fun
2402015-11-09T11:48:55  * midnightmagic likes C
2412015-11-09T11:48:55  <wumpus> gmaxwell: LOl yeah
2422015-11-09T11:49:17  <wumpus> I like C to, but not for anything involving string processing or dynamic structures
2432015-11-09T11:49:33  <gmaxwell> I am pretty sure that every cases where I've used a string where something else would have been a reasonable choice, I regretted the string. :)
2442015-11-09T11:50:11  <gmaxwell> But this may reflect too much time spent in C. OTOH, I think in terms of sheer hours lost, I've lost more to string hell in python. (probably because I avoid strings like the plague in C).
2452015-11-09T11:50:26  <wumpus> or anything that can result in buffers that overflow, for that matter
2462015-11-09T11:50:41  <midnightmagic> +1 python string hell, plus incompatibility with unicode handling across versions
2472015-11-09T11:51:13  <wumpus> almost the entire infosec industry can thank C for their jobs
2482015-11-09T11:51:37  <wumpus> I've never had any problems with strings in python
2492015-11-09T11:52:02  <gmaxwell> wumpus: python string hell mostly needs the help of unicode.
2502015-11-09T11:52:18  <wumpus> what's so bad about unicode? just use UTF-8 everywhere
2512015-11-09T11:52:21  <gmaxwell> esp less common unicode. Like chinese.
2522015-11-09T11:52:27  <midnightmagic> former employer wrote unicode handling in python 2.x, and as a result, had a *dual* python installation requirement for about a year for a flagship product while transitioning to python 3
2532015-11-09T11:52:45  * midnightmagic claws own eyes out
2542015-11-09T11:52:55  <gmaxwell> wumpus: because random python library code catches fire inconsistently with invalid, or worse --valid but unusual-- unicode.
2552015-11-09T11:53:14  <gmaxwell> I believe its improved a lot in the last couple years at least.
2562015-11-09T11:55:18  <wumpus> anyhow, I don't have any reason to defend python. I just think C for anything involving strings should die. And this reflects spending too much time in C (and related languages) solving stupid string handling, truncation, buffer overflow issues and crashes and security holes
2572015-11-09T11:56:01  <gmaxwell> wumpus: not just C's fault, we can also blame microarchitecutrs for not making tagged/bounds checked pointers cheap in hardware. (Intel tried once but their product was premature and a commercial failure...)
2582015-11-09T11:57:53  <wumpus> gmaxwell: well, sure, that would be perfect. But I think C could have been less devious and not suffer anything in performance.
2592015-11-09T11:59:10  <wumpus> sometimes it seems to have been designed to make software as insecure and buggy as possible
2602015-11-09T11:59:49  <wumpus> (and mind you,that's mostly the library, not the langauge at fault!)
2612015-11-09T12:00:36  <gmaxwell> I think part of the problem is also that "parsing" code ends up having much higher branch-complexity than almost any other code, so it is very hard to test completely... so thats where the bugs endup being, and often its strings being parsed. In libsecp256k1 the der parsers are ~25% of the conditional statements, but only about 9% of the lines of code... and they required very clever tests to ev
2622015-11-09T12:00:42  <gmaxwell> en execute all their branches.
2632015-11-09T12:02:03  <wumpus> sure, but if straightforward functions like strtol, which they teach new people to use, simply did parse according to a clear specification instead of 'leave it to the locale', that doesn't make parsing code any easier to write
2642015-11-09T12:02:28  <wumpus> s/doesn't/would/
2652015-11-09T12:02:56  <gmaxwell> things like strtol did originally not to locale stuff... that was a later enhancement that fit poorly with the architecutre of the functions.
2662015-11-09T12:02:59  <wumpus> bleh sometimes I think programming is no longer for me
2672015-11-09T12:03:19  <wumpus> get too angered about stuff lately
2682015-11-09T12:04:06  <gmaxwell> One must come to terms with everything being broken as the natural state of the world.  On the plus side, you will never run out of things to fix. :)
2692015-11-09T12:04:36  <dcousens> gmaxwell: I have a weekly break-down about that on Fridays
2702015-11-09T12:04:46  <wumpus> ah yes 'enhancement' :-) just like there was strcpy, which was plain stupid, then they tried to fix it using strncpy, which had other warts, and then there came platform-specific ones like strlcpy ...
2712015-11-09T12:05:48  <gmaxwell> in software we makes things 10,000x (or more) more complex than other more mature domains of engineering would even dare; and with much smaller budgets and compressed timelines.
2722015-11-09T12:06:11  <wumpus> which of course are still not supported on all platforms, so even if there is a better function you still end up implementing it yourself, or wrapping something, of course introducing more bugs
2732015-11-09T12:07:04  * midnightmagic is not surprised at all that deRaadt seems deflated and fatalistic these days
2742015-11-09T12:07:05  <wumpus> well given how much time we spend working around warts in our tools that's amazing
2752015-11-09T12:07:10  <dcousens> wumpus: interestingly, in 6 years of doing C++
2762015-11-09T12:07:32  <dcousens> I think I can count strcpy uses on my hand
2772015-11-09T12:08:04  <wumpus> dcousens: oh yes, but you'll encounter it in other people's code that you are using / relying on! that's half the fun
2782015-11-09T12:08:16  <gmaxwell> C++ allows you to swap out your choice of the warts in C with different and more exciting warts. :)
2792015-11-09T12:08:40  <wumpus> midnightmagic: it's hard to not be fatalistic about these things, this is quite a hole we've digged ourself in
2802015-11-09T12:08:40  <dcousens> wumpus: simple, don't just don't rely on other peoples code
2812015-11-09T12:08:44  <dcousens> (/s)
2822015-11-09T12:09:28  <wumpus> dcousens: hehe
2832015-11-09T12:11:24  <gmaxwell> The space shuttle had about 2 million moving parts. Firefox has something like 10 million 'moving parts'. If the space shuttle has a problem a half dozen people have a very bad day, if firefox has an issue a few hundred million people may have a (less, I hope) bad day.
2842015-11-09T12:11:27  <wumpus> dcousens: that's surprisingly hard, even if you'd write your own OS and compiler, there is a whole castle of shit (depending on the platform, bootrom, UEFI, ACPI, etc) that runs before you can and can subtly mess things up!
2852015-11-09T12:12:09  <wumpus> no surprise we're not going to the moon anymore :-)
2862015-11-09T12:12:23  <midnightmagic> wumpus: people yelling at you all the time probably doesn't help much. I dunno how deRaadt's made it this far without melting down and just disappearing off into the bush with a crossbow..
2872015-11-09T12:12:23  <gmaxwell> In any case, there is something worse than (all) things being broken. And thats being stuck working on software where things are broken and _no one cares_. Here we do really care, even if we're sometimes helpless because there is so much debt and the problems are so hard.
2882015-11-09T12:12:41  <midnightmagic> (I mention deRaadt only because you said something about strlcpy)
2892015-11-09T12:13:02  <dcousens> haha, gmaxwell here here
2902015-11-09T12:13:43  <dcousens> wumpus: I know, you can only chase the rabbit whole so far until you realise hardware is completely retarded as well
2912015-11-09T12:13:47  <midnightmagic> gmaxwell: Or, worse than no-one caring, but everyone getting *angry* at you for pointing out all these problems that indicate the software will fail in production!
2922015-11-09T12:14:00  <gmaxwell> but yea, the specifics around C/posix where common mistakes reliably result in exploitable vulnerabilities is why @blockstream we're trying rust for some things.
2932015-11-09T12:14:03  <wumpus> gmaxwell: very true
2942015-11-09T12:14:29  <wumpus> gmaxwell: yes, I've also started using rust for some private tools, can say it's pretty nice
2952015-11-09T12:14:35  <gmaxwell> midnightmagic: yea no kidding. It's really bad in much of the software writing world. You're the bad guy for pointing out things are dangerously broken.
2962015-11-09T12:14:50  <midnightmagic> As in..  they *want* to not care about broken things, but by pointing broken things out to them, they are forced to care, and then they get angry at you and make you present at conferences things that kill you a little inside.
2972015-11-09T12:15:05  <dcousens> midnightmagic: haha
2982015-11-09T12:15:09  <gmaxwell> wumpus: I heard from andytoshi that you've been keeping him honest on rust-bitcoin. :)
2992015-11-09T12:15:14  <wumpus> midnightmagic: well the messenger of bad news and al
3002015-11-09T12:16:02  <wumpus> midnightmagic: or rather, people *know* how broken things are, but feel helpless, and get homicidal when they are reminded :)
3012015-11-09T12:17:25  <wumpus> like we're all on the same boat, and it's sinking, but there's no use in telling people that because they already know, but there's no way to stop it
3022015-11-09T12:18:27  * midnightmagic mutters about Mongol messengers getting a bit more respect after the first few times they were decapitated..
3032015-11-09T12:18:43  <gmaxwell> some of this is about variance, the tools we have for software are so amazingly powerful-- but they mostly reduce the average case complexity of software engineering.  The worst case complexity of software engineering is still little better than if were wirewraping out programs, except in wirewrap form they would be the size of the planet.
3042015-11-09T12:18:47  <midnightmagic> loll
3052015-11-09T12:19:00  <gmaxwell> s/out programs/our programs/
3062015-11-09T12:22:02  <dcousens> wumpus: its like the boat is perpetually sinking though
3072015-11-09T12:22:13  <dcousens> but you keep inflating life boats to hold up the hull
3082015-11-09T12:22:52  <gmaxwell> (I really didn't appriciate how awesome the tools we have for software were, until I had a dream once that I was working on a car, and had GDB like tools. "set a watch on that air molecule and single step; ah it escapes the intake at the throttle body, but only under boost" :)  Slim consolation, we use these tools to make software much more complex than we'd dare attempt otherwise.
3092015-11-09T12:22:58  <gmaxwell> )
3102015-11-09T12:23:08  <dcousens> haha
3112015-11-09T12:23:12  <wumpus> gmaxwell: one problem is that it's become so easy to make something that *seems* to do what you want :)
3122015-11-09T12:25:19  <gmaxwell> In 15 seconds you can write a program with 20 moving parts (e.g. branches or what not); if you built a simple machine with that complexity you'd probably expect to spend days twiddling with it to get it working right.
3132015-11-09T12:25:59  <dcousens> gmaxwell: thats why I try to just avoid moving parts as much as possible :P
3142015-11-09T12:26:11  <dcousens> functionality purity is great
3152015-11-09T12:26:22  <dcousens> (a different problem, but, similar prospect)
3162015-11-09T12:26:33  <wumpus> gmaxwell: hehe, yes, some of the tools are pretty awesome. When they work.
3172015-11-09T12:27:21  <gmaxwell> Still, even the most pure functional code has its own 'moving part complexity' (even though avoiding mutable state really does simplify analysis of many kinds)
3182015-11-09T12:27:28  <wumpus> (and once you've learned how to use them, which, by the time you fully grasp them, they're deprecated and you need to learn something new :p)
3192015-11-09T12:27:43  <jonasschnelli> hah
3202015-11-09T12:28:28  <gmaxwell> gdb is still gdb. :) Part of why I'm so happy that RR works with GDB so well now.
3212015-11-09T12:31:17  <wumpus> and gdb, while great with C, works so bad with C++ :-( the many times I've seen (optimized out) just for the variable I was trying to inspect... even when compiling without optimizations. Or inspecting e.g. stl containers, which have a maze of templated objects inside...
3222015-11-09T12:31:53  <wumpus> anyhow, enough ranting for today, sorry
3232015-11-09T12:32:11  <gmaxwell> A rant here or there is good for everyone.
3242015-11-09T12:32:33  <gmaxwell> :) Always good to confirm that you're not alone.
3252015-11-09T12:33:29  <wumpus> yes, thanks :)
3262015-11-09T12:38:41  * jonasschnelli likes lldb
3272015-11-09T12:51:54  <wumpus> haven't tried lldb yet
3282015-11-09T13:17:01  *** ParadoxSpiral has joined #bitcoin-core-dev
3292015-11-09T13:19:14  <GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6176e9bf3d55...f24880b13213
3302015-11-09T13:19:15  <GitHub67> bitcoin/master c53d48a Jorge Timón: BIP70: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings...
3312015-11-09T13:19:15  <GitHub67> bitcoin/master f24880b Wladimir J. van der Laan: Merge pull request #6908...
3322015-11-09T13:19:24  <GitHub130> [bitcoin] laanwj closed pull request #6908: Chainparams: DRY: Make qt/guiutil.cpp fit BIP70 chain name strings (master...chainparams-bip70-0.12.99) https://github.com/bitcoin/bitcoin/pull/6908
3332015-11-09T13:19:49  <GitHub173> [bitcoin] laanwj closed pull request #6953: Backport bugfixes to 0.10 (2015-10-22 / f2c869a) (0.10...backport-bugfixes-to-0.10-20151014) https://github.com/bitcoin/bitcoin/pull/6953
3342015-11-09T13:19:49  <GitHub98> [bitcoin] laanwj pushed 15 new commits to 0.10: https://github.com/bitcoin/bitcoin/compare/cbc4e3bd37da...3b89bf643896
3352015-11-09T13:19:50  <GitHub98> bitcoin/0.10 9c81005 Diego Viola: Fix spelling of Qt
3362015-11-09T13:19:50  <GitHub98> bitcoin/0.10 3ad96bd Alex Morcos: Fix locking in GetTransaction....
3372015-11-09T13:19:51  <GitHub98> bitcoin/0.10 612efe8 MarcoFalke: [Qt] Raise debug window when requested...
3382015-11-09T13:33:23  <GitHub120> [bitcoin] ptschip opened pull request #6973: Zlib Block Compression for block relay (master...compress) https://github.com/bitcoin/bitcoin/pull/6973
3392015-11-09T13:33:45  <GitHub72> [bitcoin] laanwj opened pull request #6974: Always allow getheaders from whitelisted peers (master...2015_11_whitelisted_allow_headers) https://github.com/bitcoin/bitcoin/pull/6974
3402015-11-09T13:44:06  *** dcousens has quit IRC
3412015-11-09T14:07:27  *** Guest91590 has quit IRC
3422015-11-09T14:09:23  <GitHub127> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/c2e7baf2bdb2e2c163bcadaebe68ee00c9a27e7c
3432015-11-09T14:09:24  <GitHub127> bitcoin/0.10 c2e7baf Wladimir J. van der Laan: Bump version to 0.10.4, add release notes
3442015-11-09T14:12:37  <wumpus>  * [new tag]         v0.10.4rc1 -> v0.10.4rc1
3452015-11-09T14:13:26  *** pigeons has joined #bitcoin-core-dev
3462015-11-09T14:13:49  *** pigeons is now known as Guest51134
3472015-11-09T14:20:12  <helo> another couple days, another abort on assert(onlyMaybeDeadlock)... am i the only one seeing these?
3482015-11-09T14:29:33  <wumpus> haven't seen it yet
3492015-11-09T14:35:27  *** ParadoxSpiral_ has joined #bitcoin-core-dev
3502015-11-09T14:38:52  *** ParadoxSpiral has quit IRC
3512015-11-09T14:39:33  <helo> i think it's only started since i upgraded to ubuntu 15.10
3522015-11-09T14:40:41  <wumpus> so you're building with -DDEBUG_LOCKORDER?
3532015-11-09T14:41:55  <wumpus> that became the default for --enable-debug some time ago, that's probably when it started
3542015-11-09T14:42:35  <helo> i've been using --enable-debug for quite a while now
3552015-11-09T14:43:06  <helo> i've seen plenty of the potential deadlock warnings, but never aborting until recently
3562015-11-09T14:43:56  <wumpus> the commit that enables it is Mon Jul 13 14:28:03 2015
3572015-11-09T14:45:12  *** lclc has quit IRC
3582015-11-09T14:48:05  <GitHub135> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f24880b13213...503ff6e1ae69
3592015-11-09T14:48:05  <GitHub135> bitcoin/master 9ea7762 Matt Corallo: Use Pieter's signing subkey instead of his primary key...
3602015-11-09T14:48:06  <GitHub135> bitcoin/master 503ff6e Wladimir J. van der Laan: Merge pull request #6967...
3612015-11-09T14:48:12  <GitHub148> [bitcoin] laanwj closed pull request #6967: Use Pieter's signing subkey instead of his primary key (master...verify-commits-fixes) https://github.com/bitcoin/bitcoin/pull/6967
3622015-11-09T14:53:24  *** lclc has joined #bitcoin-core-dev
3632015-11-09T14:56:16  <jonasschnelli> on my libsecp256k verification node, my active tip is at 382748 (~-10 blocks), headers are up to 382758...
3642015-11-09T14:56:25  <GitHub75> [bitcoin] harding opened pull request #6975: [doc] 0.11.2 release notes: use original pull numbers (0.11...note-0.11.2-orig-prs) https://github.com/bitcoin/bitcoin/pull/6975
3652015-11-09T14:56:26  <jonasschnelli> 20049 transaction stuck in the mempool
3662015-11-09T14:56:41  <jonasschnelli> 286MB dynamic usage
3672015-11-09T14:59:50  <jonasschnelli> On of my local nodes (non libsecp256k1 verification) tells me i'm on 382758 with ~5000tx in mempool.
3682015-11-09T15:14:06  *** lclc has quit IRC
3692015-11-09T15:14:10  *** bsm1175321 has quit IRC
3702015-11-09T15:19:10  *** bsm1175321 has joined #bitcoin-core-dev
3712015-11-09T15:21:04  *** lclc has joined #bitcoin-core-dev
3722015-11-09T15:21:44  *** GAit has joined #bitcoin-core-dev
3732015-11-09T15:22:52  <wumpus> jonasschnelli: why is the node stuck? did it reject a block?
3742015-11-09T15:23:24  <jonasschnelli> wumpus: can't see anything in the debug.log (have no -debug flag activated)
3752015-11-09T15:23:45  <wumpus> you don't need a debug flag to log block rejection, just for tx rejection
3762015-11-09T15:23:55  <jonasschnelli> let me check again...
3772015-11-09T15:25:16  <jonasschnelli> i can see the update tip to: 382748
3782015-11-09T15:25:29  <jonasschnelli> after that, only "boring" stuff like "receive version message:"
3792015-11-09T15:25:37  <jonasschnelli> no reject
3802015-11-09T15:26:46  <jonasschnelli> last 1000 lines of my debug log: https://bitcoin.jonasschnelli.ch/secp/stuck_debug.log
3812015-11-09T15:28:18  *** lclc has quit IRC
3822015-11-09T15:29:03  *** lclc has joined #bitcoin-core-dev
3832015-11-09T15:29:08  <bsm1175321> jonasschnelli: that seems like an awful lot of version messages to me.  Why so many disconnects/reconnects?
3842015-11-09T15:30:18  <bsm1175321> My node has been running since ~Thursday and is on peer=14, yours is at peer=2715.
3852015-11-09T15:30:51  <helo> i get insane disconnects/reconnects from bitnodes
3862015-11-09T15:31:08  <bsm1175321> Mine is firewalled though, no incoming connections.
3872015-11-09T15:31:12  <jonasschnelli> hmm... no idea. getpeerinfo reports a huge list.
3882015-11-09T15:31:55  <jonasschnelli> node is up since: 2015-11-08 19:17:23
3892015-11-09T15:31:56  <bsm1175321> Maybe your node has fallen behind and is getting banned?
3902015-11-09T15:32:21  <bsm1175321> jonasschnelli: my node is up since 2015-11-05.
3912015-11-09T15:33:14  <jonasschnelli> bsm1175321: hmm.. don't think so.. getpeerinfo reports many peers with reasonable connect time
3922015-11-09T15:33:35  * jonasschnelli needs to attach the debugger for more info...
3932015-11-09T15:34:41  <jonasschnelli> i assume -dbcache=6000 should not be related to this issue?
3942015-11-09T15:35:24  <bsm1175321> jonasschnelli: In between blocks 382748 and a peer notifying blocks=382749 is: 2015-11-09 13:39:07 socket recv error Connection reset by peer (104)
3952015-11-09T15:35:36  <bsm1175321> Could that have been the 382749 block download?
3962015-11-09T15:35:59  <jonasschnelli> theres a second headers-only chain which i accidentally cut of in the comment: now re-added: https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-155093019
3972015-11-09T15:36:02  <wumpus> ouch, I shut down a VM where a bitcoind w/ -dbcache=8000 was running, without waiting for bitcoind shutdown to complete and flush. A learning moment. Lost a lot of state :-) But no leveldb corruption at least...
3982015-11-09T15:36:33  <jonasschnelli> wumpus: hah. yeah. 8GB are some amount of blocks... :) happy catch up...
3992015-11-09T15:37:50  <jonasschnelli> as said, im stuck on 382748, and i have two headers-only chains, one at the most recent height of 382761, the other at 382649 (=stuck block +1)
4002015-11-09T15:39:14  <bsm1175321> jonasschnelli: Might be worth checking out the code path if a connection gets closed during block download.
4012015-11-09T15:39:49  <jonasschnelli> i could restart with -debug=net, but i guess i ruin the error-picture we have here...
4022015-11-09T15:43:37  *** Thireus has quit IRC
4032015-11-09T16:03:37  <sipa> jonasschnelli: strange
4042015-11-09T16:03:51  <sipa> jonasschnelli: does getpeerinfo list any of those blocks as in flight?
4052015-11-09T16:04:02  <jonasschnelli> sipa: let me check...
4062015-11-09T16:04:53  <sipa> or anything about failed validation in debug.log
4072015-11-09T16:05:23  <jonasschnelli> sipa: nope. All inflight array empty.
4082015-11-09T16:05:41  <sipa> very strange
4092015-11-09T16:05:42  <jonasschnelli> sipa: nothing in the debug log: check here if you wan't: https://bitcoin.jonasschnelli.ch/secp/stuck_debug.log
4102015-11-09T16:05:56  <sipa> how long have you been stuck?
4112015-11-09T16:06:56  <jonasschnelli> i just checked 1-2h ago and encountered the issue... so height 382748 (where i'm stuck is from today ~13:30)
4122015-11-09T16:07:38  *** gribble has quit IRC
4132015-11-09T16:08:06  <jonasschnelli> git log says: 4ee149a6db25cde31432f83369b40c92be13021c + Merge branch 'secp256k1' of https://github.com/sipa/bitcoin
4142015-11-09T16:08:14  <sipa> have you restarted the note yet?
4152015-11-09T16:08:35  <jonasschnelli> no. i guess this will cure the issue...
4162015-11-09T16:08:55  <sipa> (not that that should be needed, but if it's a bug related due to switchover from IBD to normal sync, that would solve it)
4172015-11-09T16:08:57  <jonasschnelli> but i'd like to not ruin the possibility to debug that issue
4182015-11-09T16:09:42  <jonasschnelli> as you can see in the debug log, IBD was already done
4192015-11-09T16:10:08  <jonasschnelli> but i try to restart now...
4202015-11-09T16:10:25  <jonasschnelli> what -debug flags would be helpful? =net?
4212015-11-09T16:10:36  <jonasschnelli> (in case the issue shows up again)
4222015-11-09T16:12:43  <michagogo> Wtf? https://usercontent.irccloud-cdn.com/file/i4xhIkLw/IMG_3113.PNG
4232015-11-09T16:17:39  <jonasschnelli> michagogo : ppa?
4242015-11-09T16:17:53  <michagogo> Hm?
4252015-11-09T16:17:58  <michagogo> This is in a gitian build
4262015-11-09T16:18:03  <jonasschnelli> hu!
4272015-11-09T16:18:15  <michagogo> (That's build.log)
4282015-11-09T16:18:19  * jonasschnelli thinks michagogo should use a desktop shell to avoid the use of a magnify
4292015-11-09T16:18:24  *** gribble has joined #bitcoin-core-dev
4302015-11-09T16:18:37  <michagogo> jonasschnelli: what?
4312015-11-09T16:18:54  <jonasschnelli> Where do we use Qt4.6.4? Aren't the current linux builds not done with qt5?
4322015-11-09T16:18:59  <michagogo> (That's a screenshot from me remoting into my laptop from my phone)
4332015-11-09T16:19:05  <jonasschnelli> ^^
4342015-11-09T16:19:05  <michagogo> jonasschnelli: 0.10.4rc1
4352015-11-09T16:22:29  <sipa> jonasschnelli: this may be related to the IsInitialBlovkdownload logic wumpus and suhas have been talking about
4362015-11-09T16:22:59  <sipa> see #6971 and #6974
4372015-11-09T16:23:37  <jonasschnelli> right.. could be. Restarting the node now...
4382015-11-09T16:23:50  <jonasschnelli> (dbcache=6000, takes a while)
4392015-11-09T16:25:05  <sipa> yes, leveldb always does a full compaction at startup
4402015-11-09T16:25:11  <sipa> rather than at shutdown
4412015-11-09T16:25:22  <jonasschnelli> jup... sync up to the "most recent block"
4422015-11-09T16:26:23  <jonasschnelli> getchaintips still reports a "headers-only" chain on height (382649 , height I have ben stuck +1).
4432015-11-09T16:27:53  <sipa> where are you syncing from?
4442015-11-09T16:29:45  <jonasschnelli> sipa: before i restarted i started from genesis (fresh node sync, full IBD)
4452015-11-09T16:30:17  <jonasschnelli> It was the 3h22min IBD (https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958)
4462015-11-09T16:30:25  <jonasschnelli> with dbcache 6GB
4472015-11-09T16:31:00  <jonasschnelli> i keep an eye on that node and will report if it happens again...
4482015-11-09T16:31:36  <morcos> jonasschnelli: so that node is still up and running and stuck?
4492015-11-09T16:31:43  <sipa> but where is it pulling blocks from?
4502015-11-09T16:31:48  <jonasschnelli> morcos: a restart cured the issue
4512015-11-09T16:31:49  <morcos> whoops, was behind in my history
4522015-11-09T16:33:58  <jonasschnelli> sipa: you mean from which node? I think without the -debug=net tag i can't see the node,.. i just get the UpdateTip log entry
4532015-11-09T16:34:21  <sipa> jonasschnelli: so i assume the answer is "random nodes on the internet" :)
4542015-11-09T16:34:23  <jonasschnelli> sipa: i have set up the node with standard parameters in a non-firewalled zone.
4552015-11-09T16:34:26  <jonasschnelli> right
4562015-11-09T16:37:02  <sdaftuar> jonasschnelli: am i right in thinking your node that got stuck had inbound connections?
4572015-11-09T16:37:38  <jonasschnelli> sdaftuar: right..
4582015-11-09T16:37:57  <jonasschnelli> it was connected to 38 nodes
4592015-11-09T16:38:31  <michagogo> Hrm. http://paste.ubuntu.com/13209510/
4602015-11-09T16:39:12  <michagogo> cfields: depends doesn't seem to be fetching qt 4.6.4 for the 0.10.4rc1 build
4612015-11-09T16:41:12  *** GAit has quit IRC
4622015-11-09T16:43:32  *** GAit has joined #bitcoin-core-dev
4632015-11-09T16:43:33  <michagogo> Nevermind
4642015-11-09T16:44:07  <michagogo> But do we REALLY need to be using dotfiles for download stamps, in a directory that's dedicated to those?
4652015-11-09T16:54:44  *** GAit has quit IRC
4662015-11-09T16:58:42  *** Guyver2 has joined #bitcoin-core-dev
4672015-11-09T17:10:33  *** Thireus has joined #bitcoin-core-dev
4682015-11-09T17:32:05  *** BashCo has quit IRC
4692015-11-09T17:48:28  *** zooko has joined #bitcoin-core-dev
4702015-11-09T17:48:29  *** jgarzik has joined #bitcoin-core-dev
4712015-11-09T17:48:35  *** jgarzik has joined #bitcoin-core-dev
4722015-11-09T18:01:17  *** Arabe has joined #bitcoin-core-dev
4732015-11-09T18:03:47  *** Arabe has quit IRC
4742015-11-09T18:04:23  *** GAit has joined #bitcoin-core-dev
4752015-11-09T18:07:06  *** BashCo has joined #bitcoin-core-dev
4762015-11-09T18:11:02  *** rubensayshi has quit IRC
4772015-11-09T18:20:34  *** GAit has quit IRC
4782015-11-09T18:20:58  *** GAit has joined #bitcoin-core-dev
4792015-11-09T18:21:53  *** zooko has quit IRC
4802015-11-09T18:23:17  *** zooko has joined #bitcoin-core-dev
4812015-11-09T18:31:46  <morcos> I posted issued #6976 with some performance estimates.  If we can merge all of these for 0.12, we'll have sped up ConnectBlock by over 400% and CreateNewBlock by 2000%.
4822015-11-09T18:37:55  *** BashCo has quit IRC
4832015-11-09T18:38:20  *** BashCo has joined #bitcoin-core-dev
4842015-11-09T18:59:10  *** zooko has quit IRC
4852015-11-09T19:11:37  *** gribble has quit IRC
4862015-11-09T19:26:54  *** gribble has joined #bitcoin-core-dev
4872015-11-09T19:37:11  *** skyraider has joined #bitcoin-core-dev
4882015-11-09T20:12:49  *** zooko has joined #bitcoin-core-dev
4892015-11-09T20:18:54  *** tulip has joined #bitcoin-core-dev
4902015-11-09T20:19:34  <jcorgan> #6973 could use some additional review.  i don't think it is the right approach but would like to see more input from others.
4912015-11-09T20:32:53  *** zooko has quit IRC
4922015-11-09T20:49:05  *** Eliel_ is now known as Eliel
4932015-11-09T21:03:15  *** evoskuil has quit IRC
4942015-11-09T21:09:42  *** evoskuil has joined #bitcoin-core-dev
4952015-11-09T21:11:21  *** paveljanik has quit IRC
4962015-11-09T21:21:29  *** zooko has joined #bitcoin-core-dev
4972015-11-09T21:32:06  *** zooko has quit IRC
4982015-11-09T21:35:08  *** ParadoxSpiral_ has quit IRC
4992015-11-09T21:58:27  *** jgarzik has quit IRC
5002015-11-09T22:00:11  <cfields> gitian signers: osx detached sig for 0.10.4rc1: https://bitcoincore.org/cfields/bitcoin-0.10.4rc1/signature.tar.gz
5012015-11-09T22:03:33  *** dcousens has joined #bitcoin-core-dev
5022015-11-09T22:27:40  *** zooko has joined #bitcoin-core-dev
5032015-11-09T22:36:08  *** zooko` has joined #bitcoin-core-dev
5042015-11-09T22:37:10  *** zooko has quit IRC
5052015-11-09T22:42:24  *** davec has quit IRC
5062015-11-09T22:43:12  *** zooko` is now known as zooko
5072015-11-09T22:48:00  *** davec has joined #bitcoin-core-dev
5082015-11-09T22:58:25  *** dixson3 has quit IRC
5092015-11-09T23:08:09  *** GAit has quit IRC
5102015-11-09T23:18:26  *** Guyver2 has quit IRC
5112015-11-09T23:39:41  *** GAit has joined #bitcoin-core-dev
5122015-11-09T23:41:06  *** GAit has quit IRC
5132015-11-09T23:41:58  *** GAit has joined #bitcoin-core-dev
5142015-11-09T23:50:29  *** GAit has quit IRC