12016-04-26T00:03:12  *** Madars_ has joined #bitcoin-core-dev
  22016-04-26T00:05:51  *** sipa_ is now known as sipa
  32016-04-26T00:13:04  *** jtimon has quit IRC
  42016-04-26T00:31:08  *** Ylbam has quit IRC
  52016-04-26T01:01:19  *** afk11 has quit IRC
  62016-04-26T01:04:08  *** afk11 has joined #bitcoin-core-dev
  72016-04-26T01:19:37  <GitHub160> [bitcoin] kazcw opened pull request #7942: lock cs_main for State/Misbehaving/chainActive (master...locking) https://github.com/bitcoin/bitcoin/pull/7942
  82016-04-26T01:42:16  *** Giszmo has quit IRC
  92016-04-26T01:57:59  <achow101> zmq notifications don't seem to be working in windows
 102016-04-26T01:58:59  *** Greybits has quit IRC
 112016-04-26T02:28:02  *** Alopex has quit IRC
 122016-04-26T02:29:07  *** Alopex has joined #bitcoin-core-dev
 132016-04-26T02:36:55  *** Chris_Stewart_5 has quit IRC
 142016-04-26T02:36:58  *** hsmiths has quit IRC
 152016-04-26T02:37:51  *** hsmiths has joined #bitcoin-core-dev
 162016-04-26T02:44:37  *** achow101 has quit IRC
 172016-04-26T02:53:59  *** TomMc has quit IRC
 182016-04-26T02:57:42  *** laurentmt has joined #bitcoin-core-dev
 192016-04-26T03:00:56  *** laurentmt has quit IRC
 202016-04-26T03:05:01  *** Alopex has quit IRC
 212016-04-26T03:06:06  *** Alopex has joined #bitcoin-core-dev
 222016-04-26T03:21:02  *** Alopex has quit IRC
 232016-04-26T03:21:28  *** Squidicuz has joined #bitcoin-core-dev
 242016-04-26T03:22:07  *** Alopex has joined #bitcoin-core-dev
 252016-04-26T03:53:43  *** NotAnNSAgent has quit IRC
 262016-04-26T03:57:08  <btcdrak> sipa: looks like a typo
 272016-04-26T04:01:32  <gmaxwell> kanzure: it's intentional incompetence in bitcoinj... it used to be worse, google up the bitcoin-dev logs for this lovely conversation
 282016-04-26T04:01:35  <gmaxwell> 09:04 < gmaxwell> BlueMatt: someone was saying in here that bitcoinj used a ping interval of 200ms the other day? is that so?
 292016-04-26T04:01:38  <gmaxwell> 09:05 < gmaxwell> (200ms * 124 peers = 620 pps = about 400kbit/sec before adding in whatever the ping itself takes)
 302016-04-26T04:01:52  <gmaxwell> 09:12 < TD> a ping every 200msec is not even going to stress a pocket calculator, but yeah, i'll see what's going on there
 312016-04-26T04:02:29  <gmaxwell> ...
 322016-04-26T04:02:29  <gmaxwell> 09:19 < TD> how about making the default 1 second. 44 bytes once a second is trivial compared to the cost of running a full node, even if you have a large number of peers.
 332016-04-26T04:02:42  <gmaxwell> 09:21 < gmaxwell> TD: Any reason it needs to be that fast? The network radius is many seconds now. I was thinking of conferring DOS when pings come faster than once per second, so actually sending at once per second would be right on the wire.
 342016-04-26T04:02:55  <gmaxwell> 09:24 < TD> because responsiveness matters, a ton. it's trying to figure out which of the peers it was able to find can shovel it the chain fastest, ie, is not overloaded
 352016-04-26T04:03:01  <gmaxwell> 09:25 < TD> pings are super cheap. if we go up to even a pathetic level of traffic like 5-6 transactions per second, invs will be far more expensive bandwidth and cpu wise
 362016-04-26T04:03:30  <gmaxwell> 09:30 < gmaxwell> TD: nothing on the network happens within a one second time frame. The time it takes to get a message across the network is multiple seconds. Any sane peer has multiple connections. 1 second is still on the order of (20+28+12+32)*8*125 = 92kbit/sec for a node with 125 peers.
 372016-04-26T04:03:35  <gmaxwell> 09:31 < gmaxwell> I do not think this is reasonable in the general case.
 382016-04-26T04:03:38  <gmaxwell> 09:32 < gmaxwell> esp unlike blocks and such, pings are not reduced by recieving one first from another peer.
 392016-04-26T04:04:08  <gmaxwell> 09:36 < gmaxwell> TD: it's also as much as we'll spend transmitting the blockchain on average when all our peers are full nodes.
 402016-04-26T04:04:11  <gmaxwell> 09:36 < gmaxwell> (or at least within a small factor of it)
 412016-04-26T04:04:46  <gmaxwell> yadda yadda.
 422016-04-26T04:17:55  <btcdrak> maybe andreas would be willing to dial that down a bit.
 432016-04-26T04:19:35  <luke-jr> wouldn't have a choice if we release code that bans misbehaving peers <.<
 442016-04-26T04:19:59  <luke-jr> but yeah, probably better to try the polite approach first
 452016-04-26T04:31:31  *** cryptocoder has quit IRC
 462016-04-26T04:33:13  <gmaxwell> I wrote code a while back that banned when it got a new ping less than a second after the last pong response, and it immediately banned all bitcoinj peers, which is what started that discussion.
 472016-04-26T04:34:00  <gmaxwell> even with bitcoinj backed off, and the banning backed off, it still had false positives due to nodes continuing to send pings when they hadn't had a response, resulting in a backlog... and so whenever the network burped a bunch of pings would come in a burst.
 482016-04-26T04:34:27  <gmaxwell> so I think banning can't be done unless we also specify that a peer shall not have multiple pings in flight.
 492016-04-26T04:41:49  *** cryptocoder has joined #bitcoin-core-dev
 502016-04-26T04:42:16  *** luke-jr has quit IRC
 512016-04-26T04:42:54  <cfields> sipa: still around, by chance?
 522016-04-26T04:43:12  <gmaxwell> I hope not.
 532016-04-26T04:43:26  <cfields> heh, I never know what continent he's on
 542016-04-26T04:45:15  <cfields> the switch is flipped travis-side. I'm working on getting everything to turn green so that we can merge the Trusty change. Until then, things will be wonky. I might have to disable qt on a few builds, seems to take longer to build on Trusty. We can re-enable after some experimentation
 552016-04-26T04:45:35  *** luke-jr has joined #bitcoin-core-dev
 562016-04-26T04:46:13  <gmaxwell> \O/
 572016-04-26T04:51:30  *** luke-jr has quit IRC
 582016-04-26T04:55:31  *** luke-jr has joined #bitcoin-core-dev
 592016-04-26T04:58:54  *** cjcj has quit IRC
 602016-04-26T05:17:46  *** arowser has quit IRC
 612016-04-26T05:18:13  *** arowser has joined #bitcoin-core-dev
 622016-04-26T05:21:10  <sipa> cfields: \o/
 632016-04-26T05:21:37  *** xiangfu has joined #bitcoin-core-dev
 642016-04-26T05:21:49  * gmaxwell looks at the clock
 652016-04-26T05:23:38  * luke-jr replaces gmaxwell's clock with a tonal one
 662016-04-26T05:24:32  <cfields> sipa: almost ready, maybe 1 more hour
 672016-04-26T05:26:04  <gmaxwell> luke-jr: your tonal time is useless to me since there is no such thing as tonal atomic time.
 682016-04-26T05:26:25  <luke-jr> :<
 692016-04-26T05:31:13  <cfields> luke-jr: btw, you might want to keep an eye on https://github.com/travis-ci/travis-build/pull/706, since you use a similar hack iirc
 702016-04-26T05:31:44  <cfields> (and ignore my stupid first comment, I didn't realize at first that the change is being made specifically for us :p)
 712016-04-26T05:33:51  <luke-jr> cfields: I don't suppose you know a way to get GCC to link to a library from a specific directory btw?
 722016-04-26T05:34:05  <luke-jr> without knowing the library filenames which vary by platform :/
 732016-04-26T05:35:08  <sipa> specify the .a directly as a source file?
 742016-04-26T05:36:23  <luke-jr> sipa: .so, except sometimes it's .dll, and sometimes it has a lib prefix and sometimes it has a -NNN suffix etc
 752016-04-26T05:37:10  <luke-jr> oh, and don't forget Cygwin where it's a "cyg" prefix :x
 762016-04-26T05:37:46  <cfields> luke-jr: ac_search_libs :(
 772016-04-26T05:38:00  <luke-jr> :x
 782016-04-26T05:38:10  <luke-jr> hmm
 792016-04-26T05:47:27  *** ThomasV has joined #bitcoin-core-dev
 802016-04-26T05:48:42  *** Ylbam has joined #bitcoin-core-dev
 812016-04-26T05:52:14  *** ThomasV has quit IRC
 822016-04-26T06:00:13  *** dermoth has quit IRC
 832016-04-26T06:00:55  *** dermoth has joined #bitcoin-core-dev
 842016-04-26T06:04:41  <luke-jr> cfields: AC_SEARCH_LIBS doesn't seem to have a way to get the filename?
 852016-04-26T06:06:52  <cfields> luke-jr: no, not really. But using it with [foo foo-NNN etc] would get you part of the way there, since that will also take care of .so/.dll
 862016-04-26T06:09:03  <luke-jr> cfields: it won't tell me the .so/.dll, so not really
 872016-04-26T06:09:21  * luke-jr ponders
 882016-04-26T06:09:24  <cfields> luke-jr: you actually need the filename? Or you just need it to link against one of the possibilities?
 892016-04-26T06:09:35  *** murch has joined #bitcoin-core-dev
 902016-04-26T06:09:43  <luke-jr> cfields: well, I don't know how to get GCC to do it without the absolute filename
 912016-04-26T06:10:14  <luke-jr> problem is it's using -L/usr/local/lib for -lbase58, and the latter -L for libblkmaker is ignored because and older libblkmaker is in /usr/local/lib also
 922016-04-26T06:10:34  <luke-jr> I could reverse the order of the lib stuff, but then it'd have the problem in the opposite situation
 932016-04-26T06:11:35  <cfields> luke-jr: pkg-config ?
 942016-04-26T06:11:41  <luke-jr> cfields: this is with pkg-config
 952016-04-26T06:12:09  <luke-jr> -L/usr/local/lib -lbase58 from libbase58.pc, and -L/path/to/other/lib -lblkmaker from libblkmaker.pc
 962016-04-26T06:14:35  <cfields> luke-jr: doesn't libblkmaker depend on libbase58?
 972016-04-26T06:14:47  <luke-jr> cfields: yep
 982016-04-26T06:15:10  <luke-jr> both /usr/local/lib/libblkmaker and /path/to/other/lib/libblkmaker use /usr/local/lib/libbase58
 992016-04-26T06:16:33  <cfields> luke-jr: i'm missing something then. It seems like libbase58 should be private in the .pc's, and not added to the linker path since it's an indirect dep
1002016-04-26T06:16:50  <cfields> luke-jr: can you point me to what's linking them both in?
1012016-04-26T06:17:15  <luke-jr> cfields: BFGMiner also directly depends on both
1022016-04-26T06:18:17  *** BashCo has quit IRC
1032016-04-26T06:19:40  <cfields> luke-jr: ah. Not sure what to tell you, then :\
1042016-04-26T06:20:44  * luke-jr would have thought libtool and pkg-config solved this by now :\
1052016-04-26T06:21:38  <cfields> luke-jr: well i'm pretty sure you don't actually need to link against libblkmaker, since the syms will be resolved recursively at runtime
1062016-04-26T06:21:48  <cfields> er sorry, link against libbase58
1072016-04-26T06:22:35  <luke-jr> 3hmm
1082016-04-26T06:22:55  <cfields> but i'm not sure if ld will whine about unresolved symbols, assuming you're handling visibility
1092016-04-26T06:26:41  <cfields> sipa: is it possible to reduce the secp256k1 test runs for 32bit? They take several minutes for travis
1102016-04-26T06:29:59  *** cjcj has joined #bitcoin-core-dev
1112016-04-26T06:30:11  <sipa> cfields: i think so
1122016-04-26T06:37:29  <cfields> sipa: ah, it takes a count arg :)
1132016-04-26T06:39:30  <gmaxwell> cfields: yes, though the count might not really get it low enough, due to imbalances.
1142016-04-26T06:42:48  <cfields> imbalances?
1152016-04-26T06:44:56  <sipa> gmaxwell: but there is also a really huge count of tests run
1162016-04-26T06:45:19  <sipa> cfields: is this for the secp repo, or the tests ran inside the bitcoind repo?
1172016-04-26T06:45:50  <cfields> sipa: in the bitcoin repo. They're pretty redundant, I should think
1182016-04-26T06:47:09  <sipa> at least there no huge number of different test combinations is tried
1192016-04-26T06:47:20  <gmaxwell> cfields: we should not disable tests, since differences in build configuration are meaningful, but their count could be cut down.
1202016-04-26T06:48:12  *** BashCo has joined #bitcoin-core-dev
1212016-04-26T06:48:51  <cfields> gmaxwell: we could make sure the bitcoin configs are covered in the downstream matrix, but yea, I suppose it's best to keep them running in case we get out of sync
1222016-04-26T06:49:25  <gmaxwell> cfields: it's not even the same code, so----
1232016-04-26T06:50:18  <cfields> gmaxwell: well i sure hope the code that's coming in via merge points has been tested at least once :)
1242016-04-26T06:50:36  <cfields> but sure, point taken
1252016-04-26T06:50:59  <sipa> gmaxwell: how do you mean it is not the same code?
1262016-04-26T06:51:39  <gmaxwell> sipa: I mean upstream moves ahead.
1272016-04-26T06:58:39  *** abritoid has joined #bitcoin-core-dev
1282016-04-26T07:00:27  <sipa> cfields: how does this change make travis unusually slow?
1292016-04-26T07:00:37  <sipa> cfields: before it is merged
1302016-04-26T07:00:39  <sipa> ?
1312016-04-26T07:00:52  <sipa> some cache interaction between old and new PRs?
1322016-04-26T07:02:36  <cfields> sipa: our special cache flag has been removed, so I'm afraid of that interaction, yes
1332016-04-26T07:02:53  <cfields> sipa: in theory it's supposed to work, but i get the impression this path hasn't been tested on their end
1342016-04-26T07:03:11  <sipa> ah, i see
1352016-04-26T07:03:16  <cfields> sipa: I'll bump a PR real quick to test
1362016-04-26T07:16:39  *** ThomasV has joined #bitcoin-core-dev
1372016-04-26T07:20:06  *** jtimon has joined #bitcoin-core-dev
1382016-04-26T07:20:35  *** xiangfu has quit IRC
1392016-04-26T07:46:41  <GitHub178> [bitcoin] randy-waterhouse opened pull request #7944: Re-instate TARGET_OS=linux in configure.ac. Removed by 351abf9e035. (master...master) https://github.com/bitcoin/bitcoin/pull/7944
1402016-04-26T07:46:53  *** randy-waterhouse has joined #bitcoin-core-dev
1412016-04-26T07:47:48  <randy-waterhouse> wumpus: cfields : https://github.com/bitcoin/bitcoin/pull/7944
1422016-04-26T07:48:52  <randy-waterhouse> without this gives a weird runttime qt error (core dump) not linking to xcb plugin correctly (depends build)
1432016-04-26T08:03:10  *** Guyver2 has joined #bitcoin-core-dev
1442016-04-26T08:03:27  *** MarcoFalke has joined #bitcoin-core-dev
1452016-04-26T08:08:57  *** AaronvanW has joined #bitcoin-core-dev
1462016-04-26T08:26:42  *** paveljanik has quit IRC
1472016-04-26T08:34:29  *** jannes has joined #bitcoin-core-dev
1482016-04-26T08:43:58  *** supasonic has quit IRC
1492016-04-26T08:51:26  *** paveljanik has joined #bitcoin-core-dev
1502016-04-26T08:51:26  *** paveljanik has joined #bitcoin-core-dev
1512016-04-26T08:52:14  *** paveljanik has quit IRC
1522016-04-26T08:56:29  *** pedrobranco has joined #bitcoin-core-dev
1532016-04-26T08:56:42  *** pedrobranco has joined #bitcoin-core-dev
1542016-04-26T09:06:47  *** ThomasV has quit IRC
1552016-04-26T09:18:38  *** arowser has quit IRC
1562016-04-26T09:19:03  *** arowser has joined #bitcoin-core-dev
1572016-04-26T09:39:13  *** teward has quit IRC
1582016-04-26T09:58:07  *** fanquake has joined #bitcoin-core-dev
1592016-04-26T10:02:48  <jonasschnelli> the signal UpdatedBlockTip() is called without holding cs_main, SyncWithWallets() is called while holding cs_main
1602016-04-26T10:02:52  <jonasschnelli> I guess the signal listeners do also hold cs_main during the signal callback function?
1612016-04-26T10:03:55  <sipa> i think no callbacks should happen while holding a lock
1622016-04-26T10:04:20  <jonasschnelli> Yes. Agree. But ConnectTip is under cs_main, right?
1632016-04-26T10:04:47  <jonasschnelli> sipa: and connectTip calls SyncWithWallets()
1642016-04-26T10:04:52  <sipa> yes, should; not saying they are :)
1652016-04-26T10:05:56  <jonasschnelli> I guess a dirty RAII breaking LEAVE_CRITICAL_SECTION() is not the way to go...
1662016-04-26T10:18:17  *** teward has joined #bitcoin-core-dev
1672016-04-26T10:25:10  *** cjcj has quit IRC
1682016-04-26T10:28:35  *** cjcj has joined #bitcoin-core-dev
1692016-04-26T10:28:59  *** teward has quit IRC
1702016-04-26T10:34:57  <luke-jr> guess we better use Q_EMIT
1712016-04-26T10:34:59  * luke-jr hides
1722016-04-26T10:35:52  <sipa> how about using dbus?
1732016-04-26T10:37:02  <luke-jr> that actually would make sense to add, even if not for internal use :x
1742016-04-26T10:38:03  *** teward has joined #bitcoin-core-dev
1752016-04-26T10:46:37  *** pmienk has quit IRC
1762016-04-26T10:54:04  *** teward has quit IRC
1772016-04-26T10:54:56  <wumpus> what about kdbus, obviously we should aim to bring it all into the kernel
1782016-04-26T10:59:04  <wumpus> btw, Q_EMIT works the same as boost signals if it's used within one thread, the event handler is called synchronously. It becomes more interesting if you use it between thread, or somehow with Qt::QueuedConnection, then it will be called later in that event loop
1792016-04-26T10:59:13  <sipa> wumpus: i tried uses the ShowProgress signal for better reindex information, but it seems that using that while the main window is up makes it irresponsive (and a non-colored small window shows up)
1802016-04-26T10:59:46  <wumpus> sipa: the problem is that something in the GUI may try to get a cs_main lock in response to the signal
1812016-04-26T10:59:52  <sipa> so i guess the reindex progress should be reported by extendid UodateTi
1822016-04-26T10:59:53  <wumpus> e.g. inthe GUI thrad
1832016-04-26T11:00:08  <wumpus> if your code is hogging that signal, it will only proceed after releasing the lock
1842016-04-26T11:00:14  <wumpus> hogging that lock, I mean
1852016-04-26T11:00:25  <sipa> why does ShowProgress need a lock?
1862016-04-26T11:00:31  <wumpus> I don't know
1872016-04-26T11:00:38  <wumpus> it may not actually need it, maybe it's a mistake
1882016-04-26T11:00:59  <wumpus> ideally the GUI thread would never aquire cs_main at all, unfortunately we're not there yet
1892016-04-26T11:01:03  <sipa> it's only used for the startup check now, i think
1902016-04-26T11:01:20  <sipa> maybe it's just not or badly implemented for the main window
1912016-04-26T11:01:36  <wumpus> but sometimes the GUI wants to fetch some additional statistics from the core, which are not passed in the signal parameters, which require the lock
1922016-04-26T11:02:04  <sipa> right
1932016-04-26T11:02:05  <wumpus> I don't know for sure but it is usually the explanation for 'GUI stuck' issues
1942016-04-26T11:02:24  <wumpus> some of the additional statistics fetches are actually under try_locks to avoid this
1952016-04-26T11:02:38  <wumpus> but sometimes there's something sneaky that aquires a cs_main lock deep in the code
1962016-04-26T11:02:47  <jonasschnelli> I'm now removing the cs_main lock from the SyncWithWallets signal
1972016-04-26T11:02:58  <wumpus> in any case I could take a look at it later
1982016-04-26T11:03:12  <wumpus> just push the code somewhere and tell me how to reproduce it
1992016-04-26T11:03:12  <jonasschnelli> And I agree with wumpus: we should not allows cs_main locks from the GUI logic itself.
2002016-04-26T11:03:18  *** pedrobranco has quit IRC
2012016-04-26T11:03:31  <jonasschnelli> Though, the GUI can call something from the core classes that acquires cs_main
2022016-04-26T11:03:40  <wumpus> jonasschnelli: that should be the eventual goal; it's pretty hard to do at the moment though, e.g. sending coins and such should happen in an auxiliary thread
2032016-04-26T11:03:46  *** pedrobranco has joined #bitcoin-core-dev
2042016-04-26T11:03:56  <wumpus> getting data from the core should also happen in an auxiliary thread, and be passed using signals
2052016-04-26T11:04:12  <jonasschnelli> Right. We already have something that could work: RPC. :)
2062016-04-26T11:04:27  <wumpus> it's not rocket science but not trivial to get entirely right
2072016-04-26T11:04:37  <wumpus> yes, you need exactly the same changes if the core were to be remotely
2082016-04-26T11:04:40  <wumpus> that's a bonus.
2092016-04-26T11:04:55  <jonasschnelli> I think the only change that is worth is to fully process separete the GUI.
2102016-04-26T11:05:07  <jonasschnelli> First It could be only the node-GUI (non wallet)
2112016-04-26T11:05:08  <wumpus> well it would be a step there
2122016-04-26T11:05:27  <wumpus> if all communication to the core hapepns through signals, detaching it is almost trivial
2132016-04-26T11:05:28  <jonasschnelli> Right. You need similar/same changes.
2142016-04-26T11:05:51  <wumpus> in any case it's been on my todo list for years
2152016-04-26T11:06:37  <wumpus> I could focus on it again, but playing around with databases is so much more fun :p
2162016-04-26T11:07:41  <wumpus> and for years I believed the GUI would eventually be removed anyway, so didn't feel like spending effort on it
2172016-04-26T11:08:05  <wumpus> but you changed things around jonasschnelli :)
2182016-04-26T11:08:20  <sipa> i'm sure bitcoin 0.13 will ship with the ability to maintain the utxo set in RAM, in LevelDB, in LMDB, in BDB and in CSV files.
2192016-04-26T11:08:50  <wumpus> hahahahah you're on the right track sipa
2202016-04-26T11:08:59  <jonasschnelli> hehe...
2212016-04-26T11:09:10  <sipa> wumpus: interesting... the Qt GUI was what brought you into bitcoin development in the first place, no?
2222016-04-26T11:09:31  <wumpus> sipa: yes, it was
2232016-04-26T11:09:54  <sipa> pedrobranco: hi there
2242016-04-26T11:10:24  <pedrobranco> hi sipa :)
2252016-04-26T11:10:32  <wumpus> I was really optimistic about it in the beginning, but it turned out to be more than I bargained for, I chose qt (with a standard approach) because it is a well-known toolkit in the hope it would attract more developers to it
2262016-04-26T11:10:37  <jonasschnelli> I think the Qt GUI is great! Sure, we could use some UX designers. But one step after the other..
2272016-04-26T11:11:02  <wumpus> ... but that didn't really happen, and myself I was countinously distracted by other changes that had to be done
2282016-04-26T11:11:53  <wumpus> so at some point with all the complaints about the GUI, and with most developers not interested in it anyway, I didn't give it much time before someone would decide to remove it completely
2292016-04-26T11:12:35  <pedrobranco> sipa: whats up?
2302016-04-26T11:12:37  <sipa> pedrobranco: sorry for all the noise on your importmulti call... i really think we should have such a call
2312016-04-26T11:13:00  <MarcoFalke> Interesting, we didn't yet switch to trusty or py3, yet https://github.com/bitcoin/bitcoin/pull/7944 fails due to https://github.com/bitcoin/bitcoin/issues/7893 ...
2322016-04-26T11:13:57  <pedrobranco> sipa: no need to sorry, i thank you for the feedback. yes, i think we should too.
2332016-04-26T11:14:37  <wumpus> but anyhow, things changed, also with many of the other desktop wallets effectively dead in the water
2342016-04-26T11:14:56  <wumpus> MarcoFalke: maybe someone at Travis pushed The Button
2352016-04-26T11:15:10  <sipa> wumpus: yes, the new cache flag was enabled for our repo
2362016-04-26T11:15:20  <sipa> we can merge #7920
2372016-04-26T11:16:11  <MarcoFalke> Agree, right now things seem to be broken without it.
2382016-04-26T11:16:32  <pedrobranco> sipa: your proposal is more accurate on the expected result. looks good to me.
2392016-04-26T11:18:15  *** teward has joined #bitcoin-core-dev
2402016-04-26T11:18:41  <jonasschnelli> +1 for 7920
2412016-04-26T11:19:52  <GitHub154> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/46880ed2fd96...a4078071e0b4
2422016-04-26T11:19:53  <GitHub154> bitcoin/master 89c844d randy-waterhouse: Re-instate TARGET_OS=linux in configure.ac. Removed by 351abf9e035.
2432016-04-26T11:19:53  <GitHub154> bitcoin/master a407807 Wladimir J. van der Laan: Merge #7944: Re-instate TARGET_OS=linux in configure.ac. Removed by 351abf9e035....
2442016-04-26T11:20:02  <GitHub26> [bitcoin] laanwj closed pull request #7944: Re-instate TARGET_OS=linux in configure.ac. Removed by 351abf9e035. (master...master) https://github.com/bitcoin/bitcoin/pull/7944
2452016-04-26T11:20:35  <GitHub111> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/a4078071e0b4...c3e3cfb5d1ea
2462016-04-26T11:20:36  <GitHub111> bitcoin/master a6666b2 Wladimir J. van der Laan: depends: mac deploy Py3 compatibility...
2472016-04-26T11:20:36  <GitHub111> bitcoin/master 06fdffd Cory Fields: travis: switch to Trusty
2482016-04-26T11:20:37  <GitHub111> bitcoin/master 9267a47 Cory Fields: depends: enable pre-compiled headers for qt...
2492016-04-26T11:20:42  <GitHub8> [bitcoin] laanwj closed pull request #7920: Switch Travis to Trusty (master...travis-trusty) https://github.com/bitcoin/bitcoin/pull/7920
2502016-04-26T11:21:52  <GitHub0> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c3e3cfb5d1ea...0ea394188611
2512016-04-26T11:21:53  <GitHub0> bitcoin/master 62a9abd Chris Stewart: Fixing comment in script_test.json test case
2522016-04-26T11:21:53  <GitHub0> bitcoin/master 0ea3941 Wladimir J. van der Laan: Merge #7941: Fixing comment in script_test.json test case...
2532016-04-26T11:22:03  <GitHub188> [bitcoin] laanwj closed pull request #7941: Fixing comment in script_test.json test case (master...fix_script_test_comment) https://github.com/bitcoin/bitcoin/pull/7941
2542016-04-26T11:23:26  <sipa> do we backport it to 0.12? PRs against 0.12 may be very slow otherwise
2552016-04-26T11:23:28  <GitHub135> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/0ea394188611...e26b62093ae2
2562016-04-26T11:23:29  <GitHub135> bitcoin/master f8e6fb1 Pieter Wuille: Introduce constant for maximum CScript length
2572016-04-26T11:23:30  <GitHub135> bitcoin/master 4f87af6 Pieter Wuille: Treat overly long scriptPubKeys as unspendable
2582016-04-26T11:23:30  <GitHub135> bitcoin/master 4bf631e Patrick Strateman: CDataStream::ignore Throw exception instead of assert on negative nSize....
2592016-04-26T11:23:38  <GitHub86> [bitcoin] laanwj closed pull request #7933: Fix OOM when deserializing UTXO entries with invalid length (master...fixcompressoroom) https://github.com/bitcoin/bitcoin/pull/7933
2602016-04-26T11:23:57  *** teward has quit IRC
2612016-04-26T11:23:58  <MarcoFalke> sipa, looks like we have to
2622016-04-26T11:26:01  <GitHub38> [bitcoin] laanwj closed pull request #7936: CDataStream::ignore Throw exception instead of assert on negative nSize. (master...2016-04-24-cdatastream-ignore) https://github.com/bitcoin/bitcoin/pull/7936
2632016-04-26T11:26:28  <btcdrak> so does this mean we can merge #7165?
2642016-04-26T11:26:54  <GitHub157> [bitcoin] MarcoFalke opened pull request #7945: Revert "travis: temporarily disable qt to avoid timeouts" (master...Mf1604-travisQtCache) https://github.com/bitcoin/bitcoin/pull/7945
2652016-04-26T11:27:09  <wumpus> let's first see if the travis passes btcdrak
2662016-04-26T11:31:46  <wumpus> sipa: yes, I think the test changes should be backported to 0.12
2672016-04-26T11:32:13  <wumpus> but let's make sure it's stable on master first
2682016-04-26T11:32:18  <wumpus> then do that in one go
2692016-04-26T11:33:07  <sipa> agree
2702016-04-26T11:33:12  <sipa> no hurry for the backports
2712016-04-26T11:36:00  *** cryptapus_ has joined #bitcoin-core-dev
2722016-04-26T11:36:00  *** cryptapus_ has joined #bitcoin-core-dev
2732016-04-26T11:49:26  *** cryptapus_ is now known as cryptapus
2742016-04-26T11:57:34  *** BCBot has quit IRC
2752016-04-26T12:03:21  <GitHub138> [bitcoin] jonasschnelli opened pull request #7946: Reduce cs_main locks during ConnectTip/SyncWithWallets (master...2016/04/cs_main_wallet) https://github.com/bitcoin/bitcoin/pull/7946
2762016-04-26T12:13:47  <jonasschnelli> Okay. Am besten nimmst Du dann auch noch Taxi/Zug/Essen kosten obendrauf.
2772016-04-26T12:13:56  <jonasschnelli> arg.. wrong window. Sry.
2782016-04-26T12:14:35  <GitHub95> [bitcoin] hmel opened pull request #7947: Global params cleanup (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/7947
2792016-04-26T12:19:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2802016-04-26T12:20:42  *** randy-waterhouse has quit IRC
2812016-04-26T12:26:48  *** NotAnNSAgent has joined #bitcoin-core-dev
2822016-04-26T12:28:05  <jonasschnelli> sipa: during ActivateBestChainStep, connectTip can only be get  the pblock pointer (CBlock* pblock from ActivateBestChainStep()) or NULL? Right?
2832016-04-26T12:28:41  <jonasschnelli> So we can only sync the transactions from the block passed into ActivateBestChainStep()?
2842016-04-26T12:29:28  <sipa> heh, no
2852016-04-26T12:29:30  *** teward has joined #bitcoin-core-dev
2862016-04-26T12:29:49  <sipa> activatebestchainstep can activate or deactivate multiple blocks
2872016-04-26T12:30:05  <sipa> that pblock is just an optimization
2882016-04-26T12:30:09  <jonasschnelli> Right!
2892016-04-26T12:30:16  <jonasschnelli> There is a ReadBlockFromDisk...
2902016-04-26T12:30:18  <jonasschnelli> okay... will fix it.
2912016-04-26T12:30:23  <sipa> so it doesn't need to load that specific block again from disk if we already habe it
2922016-04-26T12:32:25  <jonasschnelli> Right. I think I form a std::list with all relevant transactions... should not exhaust the memory I guess.
2932016-04-26T12:36:17  <sipa> a vector will be more efficient
2942016-04-26T12:38:49  <jonasschnelli> sipa: because it doesn't need to check for duplicates?
2952016-04-26T12:40:15  <jonasschnelli> s/for duplicates/if item already exists
2962016-04-26T12:40:23  <sipa> because it doesn't need to allocate a new memory block for each item
2972016-04-26T12:41:57  *** teward has quit IRC
2982016-04-26T12:47:22  <jonasschnelli> Arg.. why does the SyncWithWallet signal requires a "const CBlock* pblock"!
2992016-04-26T12:47:51  <sipa> to know which block it came from :)
3002016-04-26T12:49:21  <jonasschnelli> sipa: But the hash should enough?!
3012016-04-26T12:49:34  <sipa> since we removed the merkle branches, i think that's correct
3022016-04-26T12:50:30  <jonasschnelli> the only problematic part would be: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3288
3032016-04-26T12:50:34  *** laurentmt has joined #bitcoin-core-dev
3042016-04-26T12:50:48  <sipa> that's just a sanity check, i think
3052016-04-26T12:51:06  <sipa> oh, no, it is not
3062016-04-26T12:51:34  <sipa> we could change the signal to pass a CBlockIndex* and the position in the vtx vector
3072016-04-26T12:51:38  <jonasschnelli> Right!
3082016-04-26T12:51:53  <jonasschnelli> I try that.
3092016-04-26T12:54:40  *** laurentmt has quit IRC
3102016-04-26T12:57:58  *** sdaftuar has quit IRC
3112016-04-26T12:58:29  *** morcos has quit IRC
3122016-04-26T12:59:00  *** zxzzt has quit IRC
3132016-04-26T12:59:11  *** sdaftuar has joined #bitcoin-core-dev
3142016-04-26T12:59:18  <jonasschnelli> sipa: I think the wallet does not need to know at which position the transaction is in the block. Only if it in a block or not.
3152016-04-26T12:59:24  <jonasschnelli> I don't see a usage of nIndex
3162016-04-26T12:59:26  *** morcos has joined #bitcoin-core-dev
3172016-04-26T12:59:42  *** zxzzt has joined #bitcoin-core-dev
3182016-04-26T12:59:55  <jonasschnelli> well,... there is one.
3192016-04-26T13:00:53  * jonasschnelli hates when touching a single thing results in touching the whole codebase.
3202016-04-26T13:07:21  <sipa> jonasschnelli: we use nIndex==-1 to indicate "conflicted"
3212016-04-26T13:07:28  <sipa> also, it may be useful in the future
3222016-04-26T13:10:40  <jonasschnelli> sipa: Yes. And we use the position for "merges" https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L715
3232016-04-26T13:42:15  *** TomMc has joined #bitcoin-core-dev
3242016-04-26T13:43:07  <jonasschnelli> I think this should work now as intended: https://github.com/bitcoin/bitcoin/pull/7946/files
3252016-04-26T13:43:13  <jonasschnelli> Lets see what travis thinks about it.
3262016-04-26T13:44:07  *** teward has joined #bitcoin-core-dev
3272016-04-26T13:44:17  *** zooko has joined #bitcoin-core-dev
3282016-04-26T13:54:22  *** Samdney has joined #bitcoin-core-dev
3292016-04-26T14:05:33  *** fanquake1 has joined #bitcoin-core-dev
3302016-04-26T14:05:59  *** fanquake1 has joined #bitcoin-core-dev
3312016-04-26T14:06:47  *** fanquake has quit IRC
3322016-04-26T14:09:54  *** supasonic has joined #bitcoin-core-dev
3332016-04-26T14:15:16  *** bsm117532 has quit IRC
3342016-04-26T14:28:42  *** cjcj has quit IRC
3352016-04-26T14:41:33  <GitHub176> [bitcoin] mruddy opened pull request #7948: RPC: add locked_in block hash to getblockchaininfo bip9_softforks data (master...version_bits_locked_in_block) https://github.com/bitcoin/bitcoin/pull/7948
3362016-04-26T14:57:58  <sipa> 
3372016-04-26T14:57:58  <sipa> 
3382016-04-26T14:58:08  <helo> :D
3392016-04-26T15:09:25  *** BashCo has quit IRC
3402016-04-26T15:19:24  *** earlest has joined #bitcoin-core-dev
3412016-04-26T15:19:59  *** laurentmt has joined #bitcoin-core-dev
3422016-04-26T15:22:34  *** bysherper has quit IRC
3432016-04-26T15:26:00  *** laurentmt has quit IRC
3442016-04-26T15:28:55  *** BashCo has joined #bitcoin-core-dev
3452016-04-26T15:33:17  <GitHub26> [bitcoin] jonasschnelli opened pull request #7949: [RPC] Add RPC long poll notifications (master...2016/04/rpc_signals) https://github.com/bitcoin/bitcoin/pull/7949
3462016-04-26T15:41:39  *** baldur has quit IRC
3472016-04-26T15:44:20  *** zooko has quit IRC
3482016-04-26T15:47:26  *** cryptocoder has quit IRC
3492016-04-26T15:55:41  <btcdrak> looks like that Travis merge went ok
3502016-04-26T15:59:57  <cfields> btcdrak: yea, but there's a big backlog atm :(
3512016-04-26T16:01:23  <btcdrak> cfields: 15 PRs, heh. Do they all need to rebase to take advantage as well?
3522016-04-26T16:01:32  *** fanquake1 has quit IRC
3532016-04-26T16:01:43  *** zooko has joined #bitcoin-core-dev
3542016-04-26T16:02:35  <cfields> btcdrak: no, cache is built now. But anything going into 0.12 will take forever until the travis change is backported.
3552016-04-26T16:03:06  <cfields> I didn't think that would be an immediate issue.. should've PR'd them in parallel
3562016-04-26T16:03:10  *** Guest4820 has joined #bitcoin-core-dev
3572016-04-26T16:04:31  <btcdrak> cfields: exciting :) nicely done!
3582016-04-26T16:04:34  *** Guest4820 is now known as roidster
3592016-04-26T16:05:29  <cfields> btcdrak: thanks. Now to work on speeding things up
3602016-04-26T16:06:24  <cfields> MarcoFalke: wasn't there some discussion a while back about running the rpc tests in parallel?
3612016-04-26T16:09:05  <cfields> jonasschnelli: I was wishing for a polling interface recently as well. I'd be curious to know how much it could speed up rpc tests
3622016-04-26T16:09:49  <jonasschnelli> cfields: hm... haven't though about that. But right, this might be capable of speeding up the tests
3632016-04-26T16:10:02  <jonasschnelli> adding now multiple listeners support
3642016-04-26T16:10:43  <cfields> jonasschnelli: all of the tests that constantly ping for blockcount, received tx, etc. There are lots of while(1){wait(0.1)}'s around, iirc
3652016-04-26T16:11:23  <jonasschnelli> cfields: Yes. Would be interesting to see if these could be avoided with the RPC signals pull.
3662016-04-26T16:11:59  <GitHub57> [bitcoin] MarcoFalke opened pull request #7950: [0.12] travis: switch to Trusty (0.12...Mf1604-012travisTrusty) https://github.com/bitcoin/bitcoin/pull/7950
3672016-04-26T16:13:52  *** frankenmint has joined #bitcoin-core-dev
3682016-04-26T16:15:39  <GitHub25> [bitcoin] MarcoFalke opened pull request #7951: [qa] test_framework: Properly print exception (master...Mf1604-qaMinorFixes) https://github.com/bitcoin/bitcoin/pull/7951
3692016-04-26T16:16:33  *** cryptocoder has joined #bitcoin-core-dev
3702016-04-26T16:17:10  *** PRab has quit IRC
3712016-04-26T16:20:56  *** abritoid has quit IRC
3722016-04-26T16:21:31  *** shesek has joined #bitcoin-core-dev
3732016-04-26T16:31:21  *** Don_John has joined #bitcoin-core-dev
3742016-04-26T16:31:42  *** cryptocoder has quit IRC
3752016-04-26T16:33:44  *** pmienk has joined #bitcoin-core-dev
3762016-04-26T16:50:08  *** arowser has quit IRC
3772016-04-26T16:50:24  *** arowser has joined #bitcoin-core-dev
3782016-04-26T16:50:45  *** pedrobranco has quit IRC
3792016-04-26T16:55:06  *** bysherper has joined #bitcoin-core-dev
3802016-04-26T16:58:04  *** earlest has quit IRC
3812016-04-26T17:00:08  *** achow101 has joined #bitcoin-core-dev
3822016-04-26T17:01:44  *** pedrobranco has joined #bitcoin-core-dev
3832016-04-26T17:16:49  *** Eliel_ has quit IRC
3842016-04-26T17:28:55  *** Eliel has joined #bitcoin-core-dev
3852016-04-26T17:42:03  *** murch has quit IRC
3862016-04-26T17:50:29  *** wangchun has quit IRC
3872016-04-26T17:51:00  *** wangchun has joined #bitcoin-core-dev
3882016-04-26T18:17:02  *** JackH has joined #bitcoin-core-dev
3892016-04-26T18:21:38  *** cryptocoder has joined #bitcoin-core-dev
3902016-04-26T18:26:09  *** earlest has joined #bitcoin-core-dev
3912016-04-26T18:29:04  *** bysherper has quit IRC
3922016-04-26T18:29:43  *** [\\\] has quit IRC
3932016-04-26T18:36:23  *** belcher has joined #bitcoin-core-dev
3942016-04-26T18:41:02  *** pedrobranco has quit IRC
3952016-04-26T18:41:12  *** pedrobranco has joined #bitcoin-core-dev
3962016-04-26T18:43:00  *** frankenmint has quit IRC
3972016-04-26T18:44:31  *** pedrobranco has joined #bitcoin-core-dev
3982016-04-26T18:47:04  *** Giszmo has joined #bitcoin-core-dev
3992016-04-26T18:48:50  *** tripleslash has joined #bitcoin-core-dev
4002016-04-26T18:49:03  *** pedrobranco has quit IRC
4012016-04-26T18:55:37  *** belcher has quit IRC
4022016-04-26T19:04:14  *** belcher has joined #bitcoin-core-dev
4032016-04-26T19:10:33  *** paveljanik has joined #bitcoin-core-dev
4042016-04-26T19:17:58  *** pedrobranco has joined #bitcoin-core-dev
4052016-04-26T19:18:11  *** bysherper has joined #bitcoin-core-dev
4062016-04-26T19:20:43  *** cryptocoder has quit IRC
4072016-04-26T19:21:04  *** earlest has quit IRC
4082016-04-26T19:22:31  *** pedrobranco has quit IRC
4092016-04-26T19:24:43  *** cryptocoder has joined #bitcoin-core-dev
4102016-04-26T19:38:56  *** pedrobranco has joined #bitcoin-core-dev
4112016-04-26T19:43:12  *** earlest has joined #bitcoin-core-dev
4122016-04-26T19:43:17  *** pedrobranco has quit IRC
4132016-04-26T19:46:04  *** bysherper has quit IRC
4142016-04-26T19:49:25  *** NotAnNSAgent has left #bitcoin-core-dev
4152016-04-26T19:53:11  <paveljanik> anyone having problem on testnet with "block is marked invalid" right now?
4162016-04-26T19:54:17  <paveljanik> my node is not able to finish IBD
4172016-04-26T19:54:34  <paveljanik> 2016-04-26 19:53:40 received: headers (32808 bytes) peer=1
4182016-04-26T19:54:34  <paveljanik> 2016-04-26 19:53:40 ERROR: AcceptBlockHeader: block is marked invalid
4192016-04-26T19:54:34  <paveljanik> 2016-04-26 19:53:40 ERROR: invalid header received
4202016-04-26T19:54:34  <paveljanik> 2016-04-26 19:53:40 ProcessMessages(headers, 32808 bytes) FAILED peer=1
4212016-04-26T19:54:48  *** cryptapus has quit IRC
4222016-04-26T19:57:52  <sdaftuar> paveljanik: IBD takes a while if your initial headers sync is from a bad peer (in this case, a peer that is on a chain you think is invalid)
4232016-04-26T19:58:35  <sdaftuar> paveljanik: it should clear up on its own after one of your other peers announces a new block.
4242016-04-26T19:58:43  <sdaftuar> (at least, that's my guess)
4252016-04-26T19:58:54  <paveljanik> ok, I'll wait a bit.
4262016-04-26T19:58:56  <paveljanik> Thanks
4272016-04-26T20:01:55  <sdaftuar> paveljanik: hm.  after slightly more investigation, i don't have a good explanation of what you're seeing after all -- looks like the bad peer should have been disconnected, and then you should have requested headers from one of your other peers...
4282016-04-26T20:02:12  *** bysherper has joined #bitcoin-core-dev
4292016-04-26T20:04:31  *** muuqwaul has joined #bitcoin-core-dev
4302016-04-26T20:05:04  *** earlest has quit IRC
4312016-04-26T20:06:51  <paveljanik> I did disconnect peers one by one
4322016-04-26T20:06:57  <paveljanik> and now the same for other peer
4332016-04-26T20:07:04  *** bysherper has quit IRC
4342016-04-26T20:08:19  <sdaftuar> interesting
4352016-04-26T20:08:30  <sdaftuar> looks to me like if you have 2 peers on the same bad chain
4362016-04-26T20:08:43  <sdaftuar> and the first one feeds you an invalid header, you'll disconnect from it
4372016-04-26T20:08:57  <sdaftuar> but then if the second one feeds the same bad header to you, you'll get exactly the error message you pasted, but no disconnect
4382016-04-26T20:09:42  <sdaftuar> that seems unfortunate
4392016-04-26T20:10:19  <sdaftuar> what height are you at?
4402016-04-26T20:11:15  <paveljanik> 787628
4412016-04-26T20:11:35  <paveljanik> I'll print the block hash of the invalid block to the log to see more...
4422016-04-26T20:11:50  *** arowser has quit IRC
4432016-04-26T20:12:13  *** arowser has joined #bitcoin-core-dev
4442016-04-26T20:12:16  <paveljanik> I'm at 787628
4452016-04-26T20:12:33  <sdaftuar> checking my logs for invalid block headers...
4462016-04-26T20:12:34  <paveljanik> and the logged message is: ERROR: AcceptBlockHeader: block 00000000000005354772cb50ea2decd1e9176724c41eb3427197943aea33194e is marked invalid
4472016-04-26T20:13:11  <paveljanik> this is 787391
4482016-04-26T20:13:13  <paveljanik> 8)
4492016-04-26T20:13:23  <sdaftuar> yeah i see a big invalidchainfound message about that
4502016-04-26T20:16:54  <sdaftuar> looks like maybe the chain forked after CSV deployed on testnet
4512016-04-26T20:17:06  <sdaftuar> ERROR: ConnectBlock: contains a non-BIP68-final transaction
4522016-04-26T20:17:48  <sdaftuar> sounds like you need some 0.12.1 peers...
4532016-04-26T20:19:01  <paveljanik> 8) OK, I'll disconnect all nodes but 0.12.99
4542016-04-26T20:20:42  <paveljanik> looks like everyone moved from testnet to segnets ;-)
4552016-04-26T20:21:00  <sdaftuar> heh maybe!
4562016-04-26T20:26:06  <GitHub9> [bitcoin] paveljanik opened pull request #7952: Log invalid block hash to make debugging easier. (master...20160426_Log_invalid_block) https://github.com/bitcoin/bitcoin/pull/7952
4572016-04-26T20:37:59  *** frankenmint has joined #bitcoin-core-dev
4582016-04-26T20:38:19  *** pmienk has quit IRC
4592016-04-26T20:41:42  *** cryptapus_afk is now known as cryptapus
4602016-04-26T20:54:13  *** pmienk has joined #bitcoin-core-dev
4612016-04-26T21:15:39  *** JackH has quit IRC
4622016-04-26T21:22:23  *** droark has joined #bitcoin-core-dev
4632016-04-26T21:23:29  <Chris_Stewart_5> Shouldn't this be a INVALID_STACK_OPERATION instead of a BAD_OPCODE?
4642016-04-26T21:23:31  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L719
4652016-04-26T21:24:16  *** JackH has joined #bitcoin-core-dev
4662016-04-26T21:26:30  *** paveljanik has quit IRC
4672016-04-26T21:27:12  *** paveljanik has joined #bitcoin-core-dev
4682016-04-26T21:29:28  *** tripleslash is now known as imsaguy
4692016-04-26T21:32:16  *** imsaguy is now known as tripleslash
4702016-04-26T21:38:52  *** neha has quit IRC
4712016-04-26T21:39:00  *** neha has joined #bitcoin-core-dev
4722016-04-26T21:45:51  *** JackH has quit IRC
4732016-04-26T21:51:28  *** jannes has quit IRC
4742016-04-26T21:52:47  *** JackH has joined #bitcoin-core-dev
4752016-04-26T22:19:29  *** cryptapus is now known as cryptapus_afk
4762016-04-26T22:19:54  <Chris_Stewart_5> also, are there not any CHECKSEQUENCEVERIFY tests inside of script_tests?
4772016-04-26T22:24:25  *** Guyver2 has quit IRC
4782016-04-26T22:35:13  *** frankenmint has quit IRC
4792016-04-26T22:47:07  *** Chris_Stewart_5 has quit IRC
4802016-04-26T22:47:58  *** tripleslash is now known as imsaguy
4812016-04-26T22:50:04  *** gevs has quit IRC
4822016-04-26T22:50:22  *** heath is now known as ybit
4832016-04-26T23:02:24  *** gevs has joined #bitcoin-core-dev
4842016-04-26T23:02:24  *** gevs has joined #bitcoin-core-dev
4852016-04-26T23:04:10  *** AaronvanW has quit IRC
4862016-04-26T23:09:55  *** TomMc has quit IRC
4872016-04-26T23:19:01  *** Guest48555 is now known as petertodd
4882016-04-26T23:36:19  *** frankenmint has joined #bitcoin-core-dev
4892016-04-26T23:37:56  *** cryptocoder has quit IRC
4902016-04-26T23:40:45  *** frankenmint has quit IRC
4912016-04-26T23:41:24  *** assder has quit IRC
4922016-04-26T23:45:32  *** frankenmint has joined #bitcoin-core-dev
4932016-04-26T23:50:09  *** supasonic has quit IRC
4942016-04-26T23:51:41  *** supasonic has joined #bitcoin-core-dev
4952016-04-26T23:52:27  *** jonasschnelli has quit IRC
4962016-04-26T23:59:50  *** jonasschnelli has joined #bitcoin-core-dev