--- Day changed Wed Apr 06 2016
00:18 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
00:42 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
00:47 -!- PRab [~chatzilla@c-68-51-175-167.hsd1.mi.comcast.net] has quit [Ping timeout: 276 seconds]
00:55 -!- PRab [~chatzilla@c-68-51-175-167.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
01:08 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:10 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:17 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
01:18 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
01:28 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
01:28 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:31 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection]
01:34 < GitHub9> [bitcoin] laanwj opened pull request #7821: init: allow shutdown during 'Activating best chain...' (master...2016_04_shutdown_during_activate_best_chain) https://github.com/bitcoin/bitcoin/pull/7821
01:42 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has quit [Ping timeout: 244 seconds]
01:43 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev
01:54 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 276 seconds]
01:58 < wumpus> just curious, did anyone (or know of anyone that tried) to replace leveldb with lmdb and do benchmarks with regard to chainstate sync yet?
01:59 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
01:59 < wumpus> I'd really like to know this but I don't get around to it, I know there are lmdb versus leveldb comparison sites but should be under our specific workload
02:00 < wumpus> I'm seeing awful latency on arm64 with leveldb
02:01 < btcdrak> no testing was done with lmdb, only sqlite (which was ghastly).
02:02 < wumpus> yes I know about sqlite, sqlite would be an ok format for the wallet but it's too high level/high overhead for chainstate use
02:04 < wumpus> what this needs a very fast, close-to-hw, key/value store, Ideally for this experient I'd just map the entire thing into memory but the device has only 2GB.
02:05 < sipa> wumpus: lmdb uses mmap for everything afaik, so it's hard to use on 32-bit platforms
02:05 < wumpus> I don't care about 32 bit platforms for this experiment
02:05 < wumpus> just want to compare x86_64 versus arm64
02:06 < wumpus> mmapping everything sounds perfect
02:09 < jonasschnelli> wumpus: what device are you targeting? Odroid? PINE A64?
02:09 < wumpus> odroid C2
02:10 < jonasschnelli> I have ordered a PINE A64. ~same sepcs..
02:10 < wumpus> how much memroy?
02:10 < jonasschnelli> 2GB
02:10 < jonasschnelli> (which is essential)
02:11 < jonasschnelli> I think we might finally have tiny devices that can run a fullnode and cost <40USD.
02:11 < wumpus> yes I'd preferred one with 8GB but at least it's not abysmal :)
02:11 < jonasschnelli> A fullnode next to your router...
02:11 < wumpus> right, it's promising, too bad leveldb is letting me down on this, I'm not sure why, most profiling tools are broken with this experimental kernel
02:12 < jonasschnelli> imdb sounds promissing...
02:12 < jonasschnelli> wumpus: what this needs a very fast, close-to-hw, key/value store    <--- I agree!
02:12 < jonasschnelli> C based
02:13 < jonasschnelli> wumpus: How fast is the "disk" (flash) access on the Odroid C2? You think its enough for UTXO queries?
02:13 < wumpus> exactly!
02:14 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
02:14 < wumpus> well I have a microsd in it of 32gb, but it's not very fast, I only use it for the OS, have attached an external USB harddisk for storing the block chain and utxo set
02:16 < jonasschnelli> wumpus USB2.0 should probably fast enought... though, in theory (IIRC) gbit ethernet should be faster.
02:16 < wumpus> so it could be a problem with slow storage, it looks like a latency problem, block validation fires a lot of queries and some of those end up taking ~1.2ms per input
02:17 < wumpus> well the fastest setup I've been able to use up until now is to put the blocks on the USB harddisk, and the utxo set on a network block device mounted over 1gbit ethernet
02:17 < wumpus> of course, that's kind of cheating :)
02:17 < jonasschnelli> hah. true!
02:17 < wumpus> and it still doesn't manage to max out the CPU on most blocks, so something curious is happening with leveldb
02:17 < jonasschnelli> wumpus: also, have a look at the PINE: https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput/description
02:18 < btcdrak> yeah that thing is going to rock
02:18 < jonasschnelli> 1,2GHZ Cortext A53
02:18 < wumpus> nice! yes specs look very much like the odroid C2
02:18 < jonasschnelli> Wel.. the Odroid runs on 2Ghz
02:19 < jonasschnelli> I mean, 29USD. Holly!
02:19 < sipa> i have a rpi3 now
02:20 < jonasschnelli> 512MB ram?!
02:20 < sipa> which also has an arm64 cpu, though their kernel is still 32-bit :(
02:20 < jonasschnelli> Ordoid C2: * Infrared(IR) Receiver? :|
02:21 < sipa> We need a bitcoin-over-ir protocol...
02:25 < jonasschnelli> haha...
02:48 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
02:51 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
02:51 < wumpus> I've heard about bitcoin over nfc, but no never over IRyet :-)
02:53 < Luke-Jr> turn gameboy colour into a hw wallet?
02:58 < wumpus> almost all those ARM boards have an IR receiver, but never a transmitter
03:07 < wumpus> yes you could use it for communication with a gameboy color probably :-)
03:09 < wumpus> not sure about wavelengths, frequencies etc
03:16 < wumpus> I have an FPGA board (ICEstick) with a IR led that could probably be taught to speak the right protocol, but I'm too lazy :p
03:31 < GitHub118> [bitcoin] jpdffonseca opened pull request #7822: [qa] Add test to RPC listunspent (master...support/add-test-listunspent) https://github.com/bitcoin/bitcoin/pull/7822
03:33 -!- p15x [~p15x@179.91.145.64.unassigned.bringover.net] has quit [Excess Flood]
03:38 -!- broofa [~broofa@ed-3354-10.studat.chalmers.se] has joined #bitcoin-core-dev
03:38 < GitHub154> [bitcoin] jpdffonseca opened pull request #7823: [Wallet] Add index of unspent transaction outputs (UTXOs) (master...enhancement/cache-unspent-outputs) https://github.com/bitcoin/bitcoin/pull/7823
03:40 -!- broofa [~broofa@ed-3354-10.studat.chalmers.se] has quit [Quit: Leaving]
03:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
03:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:58 -!- fengling [~fengling@111.198.29.53] has quit [Quit: WeeChat 1.4]
04:08 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:08 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
04:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has left #bitcoin-core-dev []
04:34 -!- cryptapus [~cyptapus@87.254.202.197] has joined #bitcoin-core-dev
04:34 -!- cryptapus [~cyptapus@87.254.202.197] has quit [Changing host]
04:34 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:51 < GitHub62> [bitcoin] jonasschnelli opened pull request #7824: Add uncontroversial RBF base features (master...2016/04/rbf_uncontroversial) https://github.com/bitcoin/bitcoin/pull/7824
04:59 < GitHub56> [bitcoin] pedrobranco opened pull request #7825: Prevent multiple calls to ExtractDestination (master...enhancement/prevent-multiple-calls-extractdestination) https://github.com/bitcoin/bitcoin/pull/7825
05:08 < jtimon> MarcoFalke: told me that some people told him they kind of like #7779
05:10 < jtimon> wumpus: but nobody commented on the PR...I'm not sure what should I do. Comment the example commit and remove the "Discussion: " label? just close it and keep waiting for someone to hopefuly comment?
05:10 < wumpus> heh we have kind of a PR storm at the moment
05:13 < GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b2460bd5824...70ac71b877f3
05:13 < GitHub168> bitcoin/master ffff866 MarcoFalke: [qa] Remove misleading "errorString syntax"
05:13 < GitHub168> bitcoin/master 70ac71b Wladimir J. van der Laan: Merge #7801: [qa] Remove misleading "errorString syntax"...
05:13 < GitHub158> [bitcoin] laanwj closed pull request #7801: [qa] Remove misleading "errorString syntax" (master...Mf1604-qaTestErrorString) https://github.com/bitcoin/bitcoin/pull/7801
05:14 < GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70ac71b877f3...401c65c6b3e2
05:14 < GitHub191> bitcoin/master fac724c MarcoFalke: [qa] maxblocksinflight: Actually enable test
05:14 < GitHub191> bitcoin/master 401c65c Wladimir J. van der Laan: Merge #7803: [qa] maxblocksinflight: Actually enable test...
05:14 < GitHub183> [bitcoin] laanwj closed pull request #7803: [qa] maxblocksinflight: Actually enable test (master...Mf1604-qaTestMaxBlocks) https://github.com/bitcoin/bitcoin/pull/7803
05:14 < GitHub54> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/401c65c6b3e2...3bc71e1572cb
05:14 < GitHub54> bitcoin/master fa24456 MarcoFalke: [qa] httpbasics: Actually test second connection
05:14 < GitHub54> bitcoin/master 3bc71e1 Wladimir J. van der Laan: Merge #7802: [qa] httpbasics: Actually test second connection...
05:14 < GitHub144> [bitcoin] laanwj closed pull request #7802: [qa] httpbasics: Actually test second connection (master...Mf1604-qaTestHttp) https://github.com/bitcoin/bitcoin/pull/7802
05:14 < wumpus> jtimon: maybe ask people to look at it during the meeting
05:18 < jtimon> quote from MarcoFalke "Actually we were discussing on IRC with wumpus morcos and sduftar. 
05:18 < jtimon> They seemed unanimous about using one flag and not removing it from the method because it might be needed later." when talking about #7779 and #7574
05:19 < jtimon> sdaftuar: 
05:19 < jtimon> I'll just leave it here
05:24 < wumpus> we should also inform about the c++11 transition in the upcoming meeting, I want to use nullptr  @sipa :)
05:26 < paveljanik> jtimon, I guess it is because it slipped to the second page of the PRs.
05:27 < jtimon> paveljanik: not in a hurry, but it seems a bit useless as a discussion PR if the discussion happens elsewhere (and without me, I opened it to know what people think)
05:29 < wumpus> agreed on that
05:30 < btcdrak> wumpus: recent meeting notes on c++11 transition here: https://bitcoincore.org/en/meetings/2015/12/17/#c11-for-013
05:30 < btcdrak> and again here https://bitcoincore.org/en/meetings/2016/01/21/#c11-update
05:30 < wumpus> thanks :)
05:31 < jtimon> wumpus: thanks, so just pinged the people involved and mentioned here, I don't think it's necessary to talk about #7779 in the meeting
05:31 < wumpus> It might be still blocked on travis caching support, not sure though
05:36 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
05:47 -!- cryptapus__ [~cyptapus@66.119.84.15] has joined #bitcoin-core-dev
05:47 -!- cryptapus__ [~cyptapus@66.119.84.15] has quit [Changing host]
05:47 -!- cryptapus__ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:48 -!- cryptapus__ is now known as cryptapus_
05:50 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
05:53 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-znbjwbxsjxslrqew] has joined #bitcoin-core-dev
05:59 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
06:02 < jonasschnelli> hmm... the GUI does not show wallet conflicts. Right? IIRC, there where PRs from dgenr8?
06:03 < jonasschnelli> With RBF this will be required somehow
06:04 < btcdrak> jonasschnelli: https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Adgenr8+
06:05 < jonasschnelli> btcdrak: Thanks...
06:05 < jtimon> mhmm, 1b2460b doesn't pass python ./qa/pull-tester/rpc-tests.py (mempool_limit.py fails), git fetch origin...
06:09 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
06:13 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 248 seconds]
06:17 < jtimon> mhmm, 3bc71e1 *   origin/master seems to fail too...
06:17 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
06:17 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
06:17 < jtimon> do I need to do anything else besides rm -rf cache or the current master wouldn't pass travis?
06:18 < jtimon> wumpus: ?
06:18 < wumpus> is that the extended or the base tests?
06:18 < wumpus> only the base tests are run by travis
06:19 < jtimon> the base ones mempool_limit.py
06:19 < wumpus> those should indeed pass, haven't heard travis complain
06:19 < jtimon> python ./qa/pull-tester/rpc-tests.py mempool_limit
06:19 < wumpus> what error do you get?
06:20 < jtimon> https://0bin.net/paste/qSAK6dUwqKg8rAQL#b8PsedY3uoBOHP3J-bsCQ73XyGXgr6XhSEDcQXctC/J
06:21 < wumpus> hm weird, never saw that one
06:21 < jtimon> you don't reproduce it on current master?
06:22 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
06:22 < wumpus> can't try rght now
06:23 < jtimon> ok, if anybody else can try "python ./qa/pull-tester/rpc-tests.py mempool_limit" on the current master to confirm is not a local/cache thing, I would appreciate it
06:24 < paveljanik> jtimon, mmnt
06:24 < jtimon> paveljanik: awesome thanks
06:24 < sipa> wumpus: ack on nullptr :)
06:25 -!- cryptapus_ is now known as cryptapus
06:26 < jtimon> wumpus: sipa: suggestions for more C++11-ish "extern boost::scoped_ptr<CPolicy> globalPolicy;" ?
06:26 < paveljanik> jtimon, OK, 3s
06:26 < jtimon> paveljanik: no hurry
06:27 < paveljanik> no, it is finished - 
06:27 < paveljanik> Tests successful
06:27 < paveljanik> Duration: 3 s
06:27 < wumpus> a global scoped ptr? no, I don't like that
06:27 < wumpus> if you need them at all, please explicitly create/initialize and teardown global objects
06:27 < paveljanik> jtimon, what does it print for you?
06:27 < paveljanik> ah mempool full
06:27 < wumpus> we've had enough (de)initialization order problems to last a lifetime
06:27 < paveljanik> not here...
06:29 < jtimon> paveljanik: thank you, see the 0bin link above. Now it is something in https://github.com/bitcoin/bitcoin/pull/7820/commits and I'm not cleaning up properly between tests
06:29 < jtimon> it seems "rm -rf cache" is not enough
06:30 < jtimon> wumpus: where's the right place for deleting global pointers ?
06:31 < jtimon> people seemed to like boost::scoped_ptr<CChainParams> for #6907
06:31 < wumpus> jtimon: shutdown()
06:33 < jtimon> ok, then I can use a simple pointer that initializes in AppInit2() and gets deleted in shutdown(), fine with me. maybe we should do that with the chainparams globals too
06:33 < wumpus> sure, if you really need something that lasts the entire program you could use global scoped_ptr, but make sure there areno dependencies on anything
06:34 < wumpus> and ideally the global pointer would be restricted within one module, not shared via external, but passed where necessary
06:35 < sipa> ideally all of the node operation in main is encapsulated in a class, which has a pointer to the utxo cache, the policy, the mempool, ...
06:35 < sipa> and there are no globals at all
06:35  * sipa dreams
06:35 < wumpus> yes, no globals would be best
06:35 < jtimon> what do you think about eventually moving all globals to globals/server (most of them currently in main.o), globals/util, globals/common, etc
06:35 < jtimon> ?
06:35 < wumpus> but if you really need them at least be as careful as possible with them, restrict their scope/accessibility as much as possible, etc
06:36 < wumpus> doesn't sound good to me
06:36 < wumpus> keep the globals with the code that uses them
06:36 < wumpus> keep them as local as possible
06:36 < wumpus> this makes it easier to make it into a class, too
06:36 < jtimon> well, I was thinking that maybe not including all the globals in everything that needs to include main.h for other reason would be a step forward, but thanks for the feedback
06:38 < jtimon> you could just grep #include "globals/ and find functions that could take parameters explicitly (the only true and slow path to removing globals)
06:40 < jtimon> I mean, I've mostly thought about this only for the globals in util.o, chainparams.o and globalPolicy, probably would move globals from main.o to globals/server.o the last thing, since it will be clearly the most disruptive
06:44 < jtimon> I changed the topic, sorry. I guess the answer to my original question is http://stackoverflow.com/a/5294005 
06:52 < jtimon> on "keep the globals with the code that uses them" well, in my opinion I will use a new global in init.cpp, and everywhere else basically shouldn't be using it (it should be passed down explicitly, but you cannot do that at once)
06:53 < jtimon> where should Params() be called from? ideally, nowhere
06:55 < jtimon> but only from init and one other place would be almost as ideal
06:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
06:57 < wumpus> I don't like the globals/ idea. If you need globals from another implementation unit there could be a function that returns (a pointer or reference to) it
06:57 < wumpus> similar to private: or protected: in classes
06:58 < wumpus> where should Params() be called from? <- yes, ideally just once to create the object, after that it just gets passed on
06:59 < wumpus> and stored in appropriate places within classes, so they can pass it on
07:00 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Quit: Something is wrong...]
07:02 < jonasschnelli> sipa: ping
07:02 < sipa> jonasschnelli: pang
07:02 < jonasschnelli> You remember the SetMerkleBranch PR for the wallet:
07:02 < jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3299
07:02 < jonasschnelli> The GUI does not detect RBF conflicts...
07:03 < sipa> ?
07:03 < jonasschnelli> You return 0 (=in mempool) if the hash is unset... is that correct
07:03 < jonasschnelli> (hash of the block)
07:03 < sipa> yes, it means the transaction is not known to be in a block
07:03 < jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L204
07:04 < sipa> that's outdated; it's not necessarily in the mempool
07:04 < jonasschnelli> I think the GUI needs an aditional mempool check then
07:05 < jonasschnelli> Somehow the wallet does not detect conflict with a transaction that is not in the mempool
07:05 < jonasschnelli> *conflicts
07:05 < sipa> for detecting what case?
07:05 < jonasschnelli> If a replace a transaction (RBF), I have two transaction in the transaction list, neither of them is marked conflicted.
07:06 < gmaxwell> $ ./bitcoin-cli stop
07:06 < gmaxwell> error: couldn't parse reply from server
07:06 < gmaxwell> 0_o
07:06 < jonasschnelli> (the first transaction is removed from the mempool)
07:06 < sipa> jonasschnelli: known to conflict is only for conflicting with confirmed transactions
07:07 < sipa> jonasschnelli: you can use IsTrusted ?
07:07 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 276 seconds]
07:07 < jonasschnelli> sipa: okay. Let me see..
07:07 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
07:07 < sipa> jonasschnelli: i don't know the gui, and i don't really know what you're talking about
07:08 < gmaxwell> hm. seems to be deadlocked
07:08 < jonasschnelli> hah. Yes. Forget about it. I'll work on it and show you some code... thats better understandable.
07:09 < GitHub105> [bitcoin] laanwj closed pull request #6774: IsSuperMajority() moved to separate soft forks unit (master...ISM_to_softforks_unit) https://github.com/bitcoin/bitcoin/pull/6774
07:13 < sipa> gmaxwell: https://github.com/sipa/bitcoin/commit/115157b45caa374719fa6ad2a3d46281c9109349
07:13 < sipa> gmaxwell: going to run with that to monitor
07:15 < sipa> gmaxwell: i think the inv sorting is suboptimal, in that it always puts transactions without unconfirmed dependencies first, even if they have lower individual feerate than dependent ones
07:15 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
07:15 < gmaxwell> Yes, it does.
07:16 < sipa> gmaxwell: after CPFP i guess we'll want to change it to sort by ancestor-combined-feerate, and build a set to submit based on it
07:16 < sipa> gmaxwell: but i doubt it matters at all now
07:18 < gmaxwell> I was aware of it, but didn't think it was worth the more core/computationally expensive handling. (issue being that the parent tx may already have been sent, so you can't just sort by feerate then move down all without parents-- or you'd just get ~what I have)
07:19 < sipa> i guess you'd just want to run CreateNewBlock on the subset of the mempool that overlaps with vInventoryToSend, with the reduces max size, and then send that :p
07:19  * sipa ducks
07:19 < gmaxwell> cached createnew block and intersect with the inventory. :P
07:20 < sipa> do you have any statistics for how this affects orphan tx?
07:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:21 < sipa> i guess you'd need a test setup with multiple nodes
07:21 < gmaxwell> not yet, though with only two nodes running it, I couldn't measure.
07:21 < gmaxwell> I believe it will completely eliminate them; except for garbage being sent by confused node, and except for the fact that we don't sync the mempool at start.
07:28 < Chris_Stewart_5> is the only difference between SCRIPT_VERIFY_STRICTENC & SCRIPT_VERIFY_DERSIG the fact that the former requires the hash type to be defined? 
07:30 < Chris_Stewart_5> specifically looking at these lines of code https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L191-L197
07:30 < sipa> Chris_Stewart_5: strictenc also disallows hybrid public key encoding
07:31 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
07:34 < Chris_Stewart_5> why isn't the hash type being defined in the bip66 specification? 
07:34 < sipa> because it's not necessary
07:34 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Quit: Conversation terminated!]
07:34 < sipa> the hashtype is included in the sighash, so you can't modify it
07:34 < sipa> or it would invalidate the signature
07:34 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
07:34 -!- cryptapus [~cyptapus@87.254.202.135] has joined #bitcoin-core-dev
07:34 -!- cryptapus [~cyptapus@87.254.202.135] has quit [Changing host]
07:34 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
07:45 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
07:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
08:08 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 246 seconds]
08:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
08:16 < GitHub37> [bitcoin] jonasschnelli opened pull request #7826: [Qt] show conflicts of unconfirmed transactions in the UI (master...2016/04/ui_mem_cflct) https://github.com/bitcoin/bitcoin/pull/7826
08:18 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:20 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
08:20 -!- gevs [~greg@ip-81-11-204-130.dsl.scarlet.be] has joined #bitcoin-core-dev
08:20 -!- gevs [~greg@ip-81-11-204-130.dsl.scarlet.be] has quit [Changing host]
08:20 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
08:22 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
08:25 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
08:26 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
08:27 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
08:29 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
08:50 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
09:04 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
09:05 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
09:21 < wumpus> hmm in lmdb reads happen inside a transaction as well, this makes it harder to fit into the current dbwrapper, resetting the transactino for every read is probably inefficient
09:31 < sipa> wumpus: not necessarily, i think
09:31 < sipa> otherwise, you could have a read transaction that persists, and is just closed whenever a write is performed, and then reopened
09:32 < sipa> to mimick the batch update model
09:32 < wumpus> http://symas.com/mdb/doc/group__mdb.html#ga8bf10cd91d3f3a83a34d04ce6b07992d
09:33 < wumpus> yes, that could work
10:15 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
10:17 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
10:41 -!- ^arubi is now known as arubi
11:12 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has quit [Quit: Leaving]
11:29 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 276 seconds]
11:33 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 244 seconds]
11:35 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev
11:41 -!- SteveTaylor [~textual@cpe-72-181-158-116.tx.res.rr.com] has quit [Max SendQ exceeded]
11:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:57 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:59 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
12:11 < wumpus> cool, I have bitcoind working with lmdb
12:11 < btcdrak> wumpus: that was fast
12:12 < btcdrak> the question is, is it faster? =)
12:12 < wumpus> well it's one big hack
12:12 < wumpus> I don't know yet
12:12 < wumpus> let's first see if it is correct, in my experience it's very easy to make something fast if it doesn't work properly ;)
12:13 < wumpus> but it feels quite fast
12:15 < gmaxwell> one thing to also benchmark agains is leveldb with the checks turned back down again too; as thats more apples to apples.
12:16 < wumpus> yes
12:22 < jonasschnelli> wumpus: well done... looking forward to see some benachmarks / footprint comparison! 
12:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
12:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:00 < GitHub93> [bitcoin] mrbandrews opened pull request #7827: Speed up getchaintips. (master...ba-fix-chaintips) https://github.com/bitcoin/bitcoin/pull/7827
13:02 < Chris_Stewart_5> sipa: Wrt to our discussion yesterday about executing scriptSigs & scriptPubKeys individually, was OP_CODESEPARATOR initially trying to allow this?
13:05 < Chris_Stewart_5> i.e. it indicates the ending of the scriptSig & beginning of the scriptPubKey?
13:06 < sipa> Chris_Stewart_5: it is assumed that it waas intended to allow delegation
13:07 < sipa> someone signing over the right to sign to someone else, under other conditions
13:19 < Chris_Stewart_5> it seems that you could have some sort of separator like that to say push ops can't transcent separator boundaries... not sure what the value added is though :-/ 
13:22 < GitHub50> [bitcoin] jtimon opened pull request #7828: Trivial: Globals: Explicitly pass const CChainParams& to ProcessMessage() (master...0.12.99-chainparams-trivial) https://github.com/bitcoin/bitcoin/pull/7828
13:24 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
13:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
13:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:30 < GitHub99> [bitcoin] jtimon opened pull request #7829: TODO: Kill "Params()" (master...0.12.99-todo-globals-chainparams) https://github.com/bitcoin/bitcoin/pull/7829
13:38 -!- cryptapus [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
14:03 < jtimon> newbies and full grown programmers get out of your dark conrners and comment on #7829 so that I can see you. (this is not part of the funded stuff, just you doing stuff for me and me giving advice to you if you want that)
14:05 < jtimon> the mission is not a priority or important, but if you want to get familiarized with github or whatever I'm happy to teach you with simple examples I care about
14:06 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
14:17 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:20 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
14:21 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
14:26 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
14:27 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
14:35 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
14:35 -!- d_t [~textual@185.69.203.10] has quit [Max SendQ exceeded]
14:35 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
14:35 -!- d_t [~textual@185.69.203.10] has quit [Max SendQ exceeded]
14:36 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
14:46 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
14:47 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
14:59 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:23 < kanzure> jtimon: why do you want pull request 7829 "never merged"?
15:40 < jtimon> kanzure: well, I'm happy merging all those TODO lines in the last commits, but it would be easier for me to keep track about what's been done and what is not if the PR is not merged. Besides that, I'm happy to merge a lot of TODO comments, no problem with me
15:42 < jtimon> kanzure: does that make any sense?
15:43 < kanzure> almost; the PR text could be more clear about what that PR is.... is this a good summary? "There is a set of changes that I would like to make. There's a lot of changes involved in this. To organize this work and to coordinate with others interested in helping make these changes, I have labeled TODOs in this pull request's source code. You are welcome to fork this and fix individual issues, and I will regularly rebase against the ...
15:43 < kanzure> ... master branch to keep everything updated."
15:43 < kanzure> (however, it's unclear to me if that is an accurate summary)
15:45 < jtimon> kanzure: I'm happy to change the description of the PR, do you think you get the general intend? offering myself as a "tutor" only for small things I want done? no money involved in either direction
15:45 < kanzure> if your intention was tutorship then that was not clear to me reading the PR text :)
15:46 < jtimon> I don't want to promise too much, but I think I could offer some free guidance with stupid examples I know all about
15:46 < jtimon> kanzure: that is good feedback
15:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:47 < kanzure> one other minor point of feedback is that if you want to attract novices to your pull request, saying "Probably nobody with bitcoin development experience will think this is a priority. I don't either." will not make it clear to novices that you think these changes are good or worth doing at all :)
15:48 < jtimon> but my intention is not really to start a tutorial, just to make people work for me on simple things I want done, and offer any help I can offer for them, whatever is more attractive without lying
15:48 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:49 < kanzure> right, you are offering mentorship/tutorship for how to make simple contributions to the project, in exchange for feedback and advice on a newcomer's other pull requests.    but this is not clear from the PR text.
15:50 < jtimon> kanzure: more good feedback, but I feel that's the truth (nobody is nervous about this not happenning soon enough), and it may actually be a relief for someone new (ie it doesn't matter if it takes you 3 weeks or 4, it will be welcome whenever you are ready because nobody is working on this urgently)
15:52 < jtimon> kanzure: I'm happy that you got the basic idea, please, don't hesiate from making this kind of feedback on the PR itself
15:52 < kanzure> i would start the PR text with something like: "I opened this PR so that newcomers to the Bitcoin Core project could make simple changes to get familiar with contributing to Bitcoin Core. I have marked a number of TODO comments in the source code of this pull request. The changes listed here are not critical to the project but they are good introductory material. Each TODO is relatively simple, and more experienced developers are busy ...
15:52 < kanzure> ... doing other tasks, making this an excellent chance for you to get feedback from me on basic contributions to Bitcoin Core. Hopefully this will help you streamline submissions to Core, please let me know how I can help and I'm also offering some promises/commitments (see below)."
15:54 < jtimon> ok, I pasted your comment on the PR
15:54 < jtimon> very grateful, but...
15:55 < jtimon> "I have marked a number of TODO comments in the source code of this pull request"
15:55 < jtimon> I haven't merged anything anywhere, at most #7828  as an example
15:56 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
16:04 < jtimon> kanzure: never mind, "of this pull request", re-read, all fine, thank you very much
16:05 < kanzure> yep
16:05 < jtimon> you captured the spirit and improved the description
16:06 < jtimon> in summary is that, free review for simple tasks I review, and I will try to push other people to review, etc
16:06 < jtimon> in summary is that, free review for simple tasks I select, and I will try to push other people to review, etc
16:09 < jtimon> I've met some developers that are shy because they are "C++ newbies" (to be honest, never was one because in the uni it was almast all C/C++ but some slides from older teachers still in pascal, but was never afraid of other languages and they shouldn't be either)
16:10 < jtimon> but I have to admit that moving from subversion to git was kind of a shock for me
16:10 < kanzure> bitcoin was your first introduction to git?
16:11 < jtimon> well, I fetch pybrain before that, but basically yes
16:11 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
16:11 < jtimon> never pushed anything to git that wasn't mine before git
16:11 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
16:11 < jtimon> before bitcoin
16:13 < jtimon> and never rebase -i until sipa told me that was possible ("this is what maaku means by re-writing history" I thought)
16:14 < jtimon> no, I'm lying, I did used git before with maaku, but I had never done interactive rebases until I had to contribute for the first time. for some reason I really needed to rewrite history
16:16 < jtimon> probably just squash 2 commits into one or something stupidly simple that just happened to be impossible for me before
16:17 < jtimon> if other people intend to get stuck in the same sptupid things that I did, I won't let them
16:35 -!- p15 [~p15@130.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
16:59 < jtimon> where is the longest branch for 0.12.1?
17:01 < jtimon> never mind, origin/0.12 already has 68/112/113
17:14 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
17:36 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
17:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
18:06 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
18:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
18:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-znbjwbxsjxslrqew] has quit [Quit: Connection closed for inactivity]
18:16 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-zbxpbuwomwpvyfuk] has quit [Quit: Connection closed for inactivity]
18:30 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:30 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
18:39 -!- RoyceX [~x@c-71-58-178-138.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
18:39 -!- RoyceX [~x@c-71-58-178-138.hsd1.pa.comcast.net] has quit [Changing host]
18:39 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
18:41 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]
18:43 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-rsouyldvlllpbjcn] has joined #bitcoin-core-dev
18:44 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
18:45 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
18:45 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
18:47 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 268 seconds]
19:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
19:02 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 244 seconds]
19:03 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
19:03 -!- BCBot [~BCBot@pc-5305.ethz.ch] has quit [Remote host closed the connection]
19:06 -!- BCBot [~BCBot@nb-10350.ethz.ch] has joined #bitcoin-core-dev
19:20 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:33 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]
19:40 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
19:45 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
19:59 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
20:00 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 250 seconds]
20:00 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 268 seconds]
20:00 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
20:04 -!- zooko [~user@2601:281:8001:26aa:b8c2:8784:acdd:620d] has joined #bitcoin-core-dev
20:14 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
20:15 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
20:23 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 268 seconds]
20:24 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
20:25 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
20:33 -!- Alopex [~bitcoin@176.9.70.183] has quit [Remote host closed the connection]
20:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:48 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 268 seconds]
20:50 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
20:51 -!- aj [aj@cerulean.erisian.com.au] has quit [Remote host closed the connection]
20:51 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
21:03 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
21:34 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
21:36 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:11 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
22:23 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 248 seconds]
22:27 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
22:39 -!- zooko [~user@2601:281:8001:26aa:b8c2:8784:acdd:620d] has quit [Ping timeout: 250 seconds]
22:40 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
22:42 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
22:49 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
22:49 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds]
22:49 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 260 seconds]
22:51 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
22:51 -!- morcos [~morcos@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
22:51 -!- zxzzt [~prod@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
22:53 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
22:54 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
23:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Read error: Connection reset by peer]
23:00 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has joined #bitcoin-core-dev
23:03 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
23:05 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-cszbqlnojkzumpdu] has joined #bitcoin-core-dev
23:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:12 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-fxnjudigjaumpucn] has joined #bitcoin-core-dev
23:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:14 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
23:17 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
23:23 -!- p15 [~p15@130.91.145.64.unassigned.bringover.net] has quit [Max SendQ exceeded]
23:25 -!- p15 [~p15@130.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev