--- Day changed Fri Apr 08 2016 00:00 < wumpus> but hey, it's better than uninitialized memory, which it used to be before #6636 00:02 < paveljanik> what about using negative value instead? 00:04 < gmaxwell> then it probably sorts in the wrong position. 00:05 < paveljanik> if it is not excluded from the sort as evidently invalid value, yes. 00:05 < wumpus> it's not a good special marker. I think we return a negative result to mark 'unavailable information' in the fee estimaton calls and this confuses everyone, consistently 00:05 < wumpus> I think sipa's 'null' makes most sense 00:06 < wumpus> deleting the field completely may result in people complaiing 'oh noo why is this field not here it is documented!' 00:11 < wumpus> do we have a way to make a node stop syncing at a certain block? 00:12 < wumpus> oh I guess syncing until tip and then -connect=0.0.0.0 will do the job 00:16 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 00:16 < jonasschnelli> wumpus: I was also looking for this some time ago (for the UTXO set dump). I hardcoded something. 00:17 < wumpus> yes my idea now is to use one 'reference node' which does not receive new blocks, and make the other nodes sync from there 00:17 < wumpus> i'm also comparing utxo set dumps :) 00:18 < jonasschnelli> morcos: ping. Tell me when you have a couple of minutes to discuss the "new wallet" concerns. 00:19 < wumpus> so something like my 'label API' would be new wallet only? 00:20 < jonasschnelli> wumpus: Yes. I think it would be better. 00:20 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit] 00:20 < jonasschnelli> Because we don't need to take care about the account compatibility. 00:20 < wumpus> on the other hand it may give people a stepping stone to the new wallet 00:20 < wumpus> I agree 00:21 < jonasschnelli> But I'm fine with your PR for the old wallet. 00:21 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 00:21 < jonasschnelli> I just think we should merge the new wallet as soon as it make sense (not now) and go with the tiny steps (PRs). 00:21 < jonasschnelli> Peer reviews is really something that improves the quality. 00:22 < jonasschnelli> And developing it on a different branch will lead to _no_ peer review and a very big PR if we consider merging it back to the master repo. 00:23 < jonasschnelli> Merge ready could be: 1) remove accounts, 2) switch from BDB to LogDB, 3) simplify update logic 00:24 < wumpus> yes we should at least prevent the infinite delay problem that haunts wallet changes, and just merge it without the idea that the API is stable 00:24 < jonasschnelli> Yes. Just a code base where we can work on more aggressively and don't need to take care about every backward comp. API stableness. 00:26 < wumpus> with the understanding that it will likely just be disabled for the 0.13 release 00:26 < wumpus> or super-experimental 00:26 < wumpus> depending on where things are 00:28 < jonasschnelli> wumpus: yes. Certainly disabled for 0.13. My main short term focus is a new wallet codebase in the main repository to allow peer reviews. 00:29 < jonasschnelli> Deploying it to the broad user base is something different. 00:29 < jonasschnelli> Could be in 0.14, 0.15, depending on the progress. 00:29 < wumpus> right 00:29 < jonasschnelli> If it turns out as a bad idea, we can always remove it without loosing anything. 00:29 < jonasschnelli> (before deployed) 00:29 < wumpus> agree 00:32 < jonasschnelli> wumpus: re: --enable-debug-lockorder, hmm... is there no use case to log the maybe-deadlocks but no assertion that kills the app? 00:34 < wumpus> jonasschnelli: hey what a good idea 00:35 < wumpus> yes that may be best, unless it kills the application in a logging flood of deadlock notifications 00:35 < michagogo> 10:11:40 do we have a way to make a node stop syncing at a certain block? 00:35 < wumpus> but that's not my experience 00:35 < michagogo> Does blacklisting do that? 00:35 < wumpus> michagogo: but you can only blacklist a block *after* you have it, or not? 00:35 < michagogo> wumpus: that's what I'm not sure about 00:36 < michagogo> If that doesn't work, it should be made the case that it does :P 00:36 < wumpus> it's worth a try, I considered it but then rejected it on that basis, maybe just knowning about the header is enough 00:38 < wumpus> jonasschnelli: I vaguely remember we used to have those deadlock notifications non-fatal, then they would turn up here and there and people would report them but just carry on, it was less obnoxious than crashing, though still if it's false alarms ... :-) 00:40 < jonasschnelli> I think we should --enable-debug-lockorder to enable the whole detections,.. and maybe just remove the fatal assert? But sipa said he know how to solve this. So i'll wait a bit. 00:41 < wumpus> I think we should comment out the whole function until someone sorts out the problem 00:42 < wumpus> then when brining it back we can make the decision, should it crash or just report 00:42 < wumpus> but that's after we've fixed the non-sensical reports 00:43 < jonasschnelli> Agree 00:44 < wumpus> even having it as special autoconf option is not useful as long as it misfires 00:47 < jonasschnelli> CHANELINFO: we have now a bitcoin-core-dev mailing list @ linux foundation. Please subscribe! https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev 00:49 < jonasschnelli> Implementation details and things there where to much "Core-only" for bitcoin-dev list can now be discussed on bitcoin-core-dev 00:53 < jonasschnelli> why the heck does "sendtoaddress" has a "comment" and a "comment-to" argument? Isn't this very confusing? 00:54 < Luke-Jr> it's all confusing 00:54 < wumpus> yes 00:54 < wumpus> axe them 00:54 < Luke-Jr> should really just be one comment/label per address. simple and clean. 00:54 < sipa> it stores a comment on the address and a comment on the transaction, afaik :) 00:55 < jonasschnelli> hmm... I think we should only have comments for transactions. 00:55 < jonasschnelli> Doesn't labels for addresses as well as a "address book" implies address-resuse? 00:55 < Luke-Jr> jonasschnelli: addresses are transactions; the difference is an address may not have a blockchain-transaction yet (ie, it might just be a request) 00:55 < wumpus> no, not really, remember multiple addresses can have the same label jonasschnelli 00:55 < wumpus> label is just a way to group addresses 00:56 < jonasschnelli> wumpus: Ah. Right. That makes more sense. 00:56 < wumpus> 'all addresses I've sent to that belong to jonasschnelli' etc 00:56 < wumpus> 'all addresses Ive used to receive from XYZ' 00:56 < jonasschnelli> So a send-command then requires a comment (wtx) and a label (for the to address) 00:56 < jonasschnelli> What about a label for the change-address? Not necessary i guess 00:58 < wumpus> in any case, please make the command accept a structure 00:58 < wumpus> so you can have optinoal arguments as well as extensibility 00:58 < Luke-Jr> jonasschnelli: I don't see value in association with a wtx rather than an address. 00:58 < wumpus> not the current positional hellscape 00:58 < jonasschnelli> wumpus: Yes. What do you think in making the whole parameters for the new wallet an assoc. array? (A JSON object). 00:58 < wumpus> we don't have to lock this down now if the API is extensible 00:58 < wumpus> yes please 00:58 < jonasschnelli> So each parameter has always a key 00:58 < wumpus> right 00:58 < jonasschnelli> Okay... and maybe also auto-detecting JSON object in bitcoin-cli to get rid of the static conversion table. 00:58 < wumpus> yes I think a RPC call to get the command line to JSON conversion table would make sense 00:59 < wumpus> although OTOH it's not a server concern, it's more like 'give me machine parsable docuentation' 01:00 < jonasschnelli> Okay. 01:00 < wumpus> (I've forgotten the exact name for this, but I think there's even an issue open about it, about automatic discoverability of the interfaces etc) 01:01 < sipa> i remember something like that 01:01 < sipa> even some existing standard 01:01 < wumpus> right 01:02 < wumpus> 'introspection' is the word 01:02 < jonasschnelli> But isn't the JSON conversion table something 100% on the client side? 01:02 < wumpus> https://github.com/bitcoin/bitcoin/issues/4157 01:02 < wumpus> bingo 01:02 * jonasschnelli looking... 01:02 < wumpus> jonasschnelli: well in a way it is, but other applciations (such as a nice ncurses based interactive console) may want the same information 01:02 < jonasschnelli> ah. Something like a WSDL 01:03 < wumpus> basically to help the client know what fields are expected, what types, etc, without having to hardcode this 01:04 < wumpus> "The only drawback that I see is that bitcoin-cli (and other RPC command-line clients) would effectively have to do two roundtrips to the server. Once to get instructions on how to convert the command-line parameters to JSON, and once to do the actual command." apparently I forgot about a thing called caching :p 01:05 < jonasschnelli> wumpus: we could response a static JSON file that contains the "introspect". So people could store this on the client side. 01:05 < wumpus> exactly 01:05 < jonasschnelli> Like a SOAP WSDL 01:05 < jonasschnelli> Also, I'm not sure if a rpc-command prefix instead of a URL endpoint is more appropriate. At least the first is way more simple to implement. 01:05 < wumpus> mostly-static, it can change based on server configuration (different wallets, no wallet, etc) 01:06 < jonasschnelli> Agree 01:06 < GitHub117> [bitcoin] fanquake opened pull request #7838: [Doc] Update gitian build guide to debian 8.4.0 (master...gitian-debian-84) https://github.com/bitcoin/bitcoin/pull/7838 01:06 < sipa> whenever you trigger a rpc type conversion error 01:06 < jonasschnelli> We could use /wallet for the new wallet commands... or wallet_command at the same root (/) endpoint 01:06 < jonasschnelli> sipa: +1 01:06 < sipa> you get the new table 01:07 < wumpus> or add an optional header to the RPC request: Fail-if-conversion-table-hash-is-not: XXXXX 01:07 < wumpus> then on failure retrieve the new list and do the conversion and request again 01:08 < wumpus> jonasschnelli: yes, different endpoints is also possible, we've discussed this in the path for multi-wallet support 01:08 < wumpus> in the PAST 01:09 < wumpus> you'd have to rewrite the RPC server a bit though so you instance it multiple times 01:09 < jonasschnelli> Yes. Command prefixes would be much simpler. 01:09 -!- p15x [~p15x@175.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev 01:09 < jonasschnelli> Also the Multiwallet would be trivial with RPC argument structures. 01:09 < jonasschnelli> Just pass a {"wallet" : "wallet1", ... } 01:10 < wumpus> you mean command prefixes such as 'wallet.getinfo' 'mempool.getinfo' etc 01:10 < jonasschnelli> If no wallet is defined, use the "default" wallet 01:10 < wumpus> that won't help multiple wallets of the same type, of course 01:10 < wumpus> I wouldn't like wallet_wumpus.getinfo etc 01:10 < wumpus> right 01:10 < sipa> use separate url for each wallet 01:10 * jonasschnelli likes the . syntax. 01:11 < jonasschnelli> url endpoints is non-trivial to implement. 01:11 < wumpus> does JSONRPC even allow dots in method names? 01:11 < wumpus> it's pretty trivial to implement jonasschnelli 01:11 < jonasschnelli> hmm.. good question. :) 01:11 < sipa> jonasschnelli: it means that different wallets with different api can be loaded simultaneously 01:11 < wumpus> we've done quite some work in making that possible already 01:11 < jonasschnelli> okay... need to look at this. 01:11 < wumpus> just means we need some refactors which we really want anyway 01:11 < jonasschnelli> sipa: can you explain: "different wallets with different api can be loaded simultaneously"? 01:12 < wumpus> yes, if they have different endpoints, they can co-exist without even noticiing each other 01:12 < wumpus> (assuming they won't touch the same files etc) 01:12 < sipa> jonasschnelli: say we have a schnelliwallet, and then later someone implement a super simple sipwallet with a different api, using the same rpc table for both won't work 01:12 < jonasschnelli> something like /wallet/mywallet/getinfo and wallet/createnewwallet 01:13 < sipa> jonasschnelli: if they run on different urls, you get that for free 01:13 < wumpus> in any case, let's not do this all at once, the new wallet explicitly doesn't have a stable interface in the beginning 01:13 < jonasschnelli> okay. 01:13 < jonasschnelli> A /wallet endpoint makes sense for now I guess. 01:14 < jonasschnelli> Also for further process de-coupeling. 01:14 < jonasschnelli> (which is out of scope for now) 01:14 < wumpus> yes, URL separateion also brings that 01:14 < wumpus> good point 01:14 * gmaxwell reads things out of context 01:14 < gmaxwell> 01:11 < wumpus> it's pretty trivial to implement jonasschnelli 01:15 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:15 < jonasschnelli> gmaxwell: lol... 01:15 < wumpus> people will already instance multiple RPC proxies so whether that points to two URLs on the same server or different ports is a detail 01:15 < wumpus> gmaxwell: hahahahah oops 01:16 < jonasschnelli> Hm... now for the "bumpfee" RBF feature,.. do I really need to add a 6. argument to "sendtoaddress"? I can't see a better option to opt-into-RBF. 01:17 < gmaxwell> start adding data to the address field with delimiters that can't be in addresses. 01:17 * gmaxwell ducks 01:18 < jonasschnelli> gmaxwell: almost as good as "sendtoaddress-with-rfb" :-) 01:19 < gmaxwell> incidentally when comming up with new wallet-apis, it really should be possible to do things like "send all my funds, minus whatever fees are needed" or even "send at least x, but you can send a bit more to avoid creating change". 01:19 < wumpus> or just encode all arguments into the address with a special prefix 01:19 < gmaxwell> wumpus: we have that api already, it's called 'sendrawtransaction' :) 01:20 < wumpus> gmaxwell: this is for the old wallet API, for the new one the argument will be a structure so there's flexibility and expansibility, for the old one we're stuck with positional argument madness 01:20 < jonasschnelli> gmaxwell: "send all my funds, minus whatever fees are needed" is think this is already possible npw 01:20 < jonasschnelli> gmaxwell: sendtoaddress(, getbalance(), subtractfeefromamount=true) 01:20 < wumpus> yes 'subtractfeefromamount' 01:21 < jonasschnelli> Which is an awesome feature IMO 01:21 < wumpus> it's just that you don't want to add even more boolean arguments, like one for 'you can send a bit more to avoid creating change' 01:21 < wumpus> which should be possible with a better API 01:22 < jonasschnelli> wumpus: hah. True. I saw many people trying to move their balance from one to another wallet by slowly picking the total amount (like a in-human-fee-estimator) 01:23 < wumpus> haha yes I think I've done that once too 01:24 < wumpus> bisecting the number 01:25 < gmaxwell> oh when did that get added! I missed that. 01:25 < gmaxwell> that bisect behavior also then results in some stupid tiny amount being left in the wallet often. 01:26 < gmaxwell> but yes, it was just an aside comment for new APIs. 01:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 01:40 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Quit: Page closed] 01:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 01:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 01:58 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev 02:07 -!- JackH [~Jack@79-73-189-103.dynamic.dsl.as9105.com] has quit [Quit: Leaving] 02:11 < jonasschnelli> Hmm... doesn't this lead to wrong fee calculation: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1960 02:11 < jonasschnelli> (adding inputs after CreateTransaction) 02:11 < jonasschnelli> ping TheBlueMatt 02:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:13 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 02:20 < jonasschnelli> Never-mind! It's correct. 02:23 -!- p15x [~p15x@175.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 248 seconds] 02:23 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 02:24 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 02:49 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev 02:52 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 02:55 -!- fengling [~fengling@111.198.29.53] has quit [Quit: WeeChat 1.4] 03:02 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 03:46 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-xeswzqtxygevtnpf] has joined #bitcoin-core-dev 03:53 -!- spikeheadon [~spikes@122.168.199.215] has quit [Read error: Connection reset by peer] 04:13 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] 04:22 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 04:36 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 04:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 04:57 -!- fuc [~fuc@5.175.208.109] has joined #bitcoin-core-dev 05:02 -!- dermoth_ [~thomas@dsl-66-36-145-24.mtl.aei.ca] has joined #bitcoin-core-dev 05:02 -!- dermoth [~thomas@dsl-216-221-56-157.mtl.aei.ca] has quit [Disconnected by services] 05:02 -!- dermoth_ is now known as dermoth 05:04 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 05:13 < GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5851915a006a...232592a71f02 05:13 < GitHub69> bitcoin/master eda3d92 mruddy: Net: Add IPv6 Link-Local Address Support 05:13 < GitHub69> bitcoin/master 232592a Wladimir J. van der Laan: Merge #7570: Net: Add IPv6 Link-Local Address Support... 05:13 < GitHub33> [bitcoin] laanwj closed pull request #7570: Net: Add IPv6 Link-Local Address Support (master...ipv6-link-local) https://github.com/bitcoin/bitcoin/pull/7570 05:18 < GitHub179> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/232592a71f02...0afac87e8173 05:18 < GitHub179> bitcoin/master e4ba9f6 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates... 05:18 < GitHub179> bitcoin/master 5cb1d8a Suhas Daftuar: Tests: move get_bip9_status to util.py 05:18 < GitHub179> bitcoin/master da5fdbb Suhas Daftuar: Test relay of version 2 transactions 05:18 < GitHub186> [bitcoin] laanwj closed pull request #7835: Version 2 transactions remain non-standard until CSV activates (master...CSV-relay-after-softfork) https://github.com/bitcoin/bitcoin/pull/7835 05:22 < GitHub78> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/46898e7e942b4e04021aac3724eb4f2ec4cf567b 05:22 < GitHub78> bitcoin/0.12 46898e7 Suhas Daftuar: Version 2 transactions remain non-standard until CSV activates... 05:26 < GitHub35> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/465d30915cd3c1634b32f942c1faae32967e9805 05:26 < GitHub35> bitcoin/0.12 465d309 Wladimir J. van der Laan: doc: update release notes for #7835 05:26 < wumpus> * [new tag] v0.12.1rc2 -> v0.12.1rc2 05:28 -!- fuc is now known as MrHodl 05:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 05:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 05:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 05:41 < michagogo> wumpus: script running, should push sigs shortly 05:41 < wumpus> thanks! 05:41 < michagogo> If the previous PR is still around it'll just update that (and confuse the script), otherwise there'll be a new one 05:41 < MarcoFalke> Has anyone run the test suite on 0.12 yet? 05:42 < michagogo> (That last part isn't really a problem-- even though it runs in bash -e, it's the last line of the script IIRC so it shouldn't hurt anything) 05:44 < GitHub17> [bitcoin] dragongem45 opened pull request #7839: Expose information on whether transaction relayed is enabled in getne… (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7839 05:45 -!- Amnez777 [~Amnez777@37.157.216.147] has quit [Ping timeout: 260 seconds] 05:45 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has quit [Ping timeout: 252 seconds] 05:46 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev 05:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:48 -!- Amnez777 [~Amnez777@37.157.216.147] has joined #bitcoin-core-dev 05:49 < MarcoFalke> Is there a difference between `int(unsigned(1))` and `static_cast(unsigned(1))`? 05:49 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection] 05:53 < sipa> MarcoFalke: no, both will return the same int 05:53 < sipa> MarcoFalke: the first is weird C, the second is weird C++ :) 05:55 < MarcoFalke> but they are different from `(int) ((unsigned) (1))`? 05:55 < MarcoFalke> Assuming int and unsigned are any primitive type. 05:57 < sipa> TYPE(VAL) is only valid in C++ 05:57 < sipa> in C you have to use (TYPE)VAL 05:57 < sipa> int(5) is technically invoking the C++ constructor for int, with argument 5 05:57 -!- JackH [~Jack@79-73-189-103.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 05:57 < sipa> (int)5 is a C cast from 5 to int 05:57 < sipa> static_cast(5) is a C++ cast from 5 to int 05:58 < wumpus> TYPE(VAL) syntax also doesn't work with e.g. pointer types, and other types that aren't one word because they have specifiers (e.g. unsigned int) 05:58 < MarcoFalke> You can put (unsigned int) into braces and it should work, I think 05:59 < wumpus> yes but that's just a C cast then 05:59 < MarcoFalke> Ok, I was wondering what is preferred. E.g. static_cast(nSize) or int(nSize) 05:59 < MarcoFalke> re: negative fee rates 06:00 < sipa> the first 06:00 < MarcoFalke> so it's clear that a cast is happening? 06:00 < sipa> the latter is C style, and its behaviour is a bit unpredictable 06:01 < wumpus> I don't really care, more important when casting between int types is to handle overflows and underflows properly ,none of the C/C++ casts does that in itself 06:01 < sipa> MarcoFalke: see point 1 here: http://en.cppreference.com/w/cpp/language/explicit_cast 06:02 < wumpus> but yes in C++ using a C++ cast is probably best 06:03 < wumpus> isn't int(X) c++ syntax too, though? 06:03 < wumpus> in C, int doesn't have a constructor 06:03 < sipa> int(X) is C++, yes 06:03 < wumpus> you could only do (int)X 06:03 < sipa> but it's not a cast :) 06:03 < sipa> ... semantics, though 06:03 < wumpus> what is the difference in practice? 06:04 < wumpus> (for int, for other objects it probably invokes different methods) 06:04 < sipa> ok, i learned today: 06:04 < sipa> The functional cast expression consists of a simple type specifier or a typedef specifier (in other words, a single-word type name: unsigned int(expression) or int*(expression) are not valid), followed by a single expression in parentheses. This cast expression is exactly equivalent to the corresponding C-style cast expression. 06:04 < wumpus> ah, that makes sense 06:04 < sipa> so it's just extra C++ syntax equivalent to a C cast, with the same magic behaviour 06:11 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 06:16 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 06:17 -!- 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] 06:18 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev 06:22 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 06:26 < wumpus> I don't understand this line (target-bin/upgrade-system.sh in gitian): DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade > /dev/null > /var/cache/gitian/upgrade.log 2>&1 06:26 < wumpus> what is sent to /dev/null and what to the log file? 06:30 < wumpus> (my guess is everything goes to /dev/null and the second > is ignored, but I just don't know the syntax) 06:30 < helo> everything ends up in /var/cache/gitian/upgrade.log (out and err) 06:30 < wumpus> then what does the /dev/null do? 06:30 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 06:31 < sipa> wumpus: i believe i know the syntax, and that >/dev/null is redundant 06:31 < helo> nothing 06:31 < wumpus> okay 06:32 < sipa> just tested it 06:32 < sipa> (echo "stdout"; echo "stderr" >&2) >/dev/null >file 2>&1 06:32 < sipa> writes both stdout and stderr to file 06:33 < wumpus> awesome, thanks 06:33 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 06:38 < MarcoFalke> wumpus, do you really want to assert(int(nSize)>0)? nSize must represent a size of some GB (~ 1e9 GB, I think)... 06:39 < wumpus> should be >=0 I think? 06:39 < GitHub164> [bitcoin] sipa opened pull request #7840: Split and optimize inv queues and improve mempool privacy (master...splitinvtxblock) https://github.com/bitcoin/bitcoin/pull/7840 06:40 < wumpus> but yes, such an assertion makes sense, to make sure the number is within the right range 06:41 < wumpus> I don't think it'll ever trigger but better be safe than sorry 06:42 < MarcoFalke> You don't want to have some code to be triggered by p2p which will cause the assert to fail ... 06:42 < MarcoFalke> And remotly shut down any node 06:42 < wumpus> that may be preferrable to the alternative, whatever happens with the big negative fee 06:42 < MarcoFalke> if(nSize<0)nSize=max_nr 06:43 < MarcoFalke> what about this? 06:43 < wumpus> I don't like that, if somethat that wrong happens it's better to just stop, ignoring issues is worse than simply handling them 06:43 < MarcoFalke> ok 06:44 < wumpus> it's a bug in our code if a size of ~1e9 GB reaches the fee rate function 06:46 < morcos> wumpus: are you sure that should be the case (that it's a bug?). ok i guess 1e9 GB, maybe makes sense.. but you could make the argument that someone would use CFeeRate to report the average fee rate of the whole mempool or something. 06:47 < wumpus> well it overflows the integer range 06:47 < wumpus> how would you handle that? 06:47 < morcos> In other words, i think maybe its ok to have some reasonable limit, but maybe we should clearly flag that rather than just making assumptions on how CFeeRate is used.. 06:47 < helo> should data type validity be ensured during deserialization? 06:47 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 06:48 < morcos> I guess i just don't have a good mental model of where/when CFeeRate is used. So I agree good for it to be a bug when it overflows, but lets make sure that limit is high enough and comment the limitations well in CFeeRate. 1e9GB seems fine to me 06:48 < wumpus> I'm tired of this discussion already, I personally feel bad about silent c++ signed/unsigned casts and the potential overflow scenarios, but feel free to just ignore the issue for CFeerate. 06:49 < MarcoFalke> Will add the assert and the doc 06:49 < MarcoFalke> Hopefully everyone is happy then 06:49 < wumpus> as fee rates are not used to address into arrays this will probably never result in exploitable scenarios or memory crashes 06:50 < morcos> Yeah all I'm trying to suggest is that we make our assumptions explicit, sorry I probably didn't state that clearly 06:50 < morcos> so sounds good 06:51 < wumpus> the point is that a size_t can be larger than std::numeric_limits::max() on most platforms 06:51 < sipa> use ptrdiff_t *ducks* 06:51 < wumpus> so before the cast it makes sense to check that the value is <= that 06:51 < wumpus> what you do in that case depends on the circumstances, but in this case as it shoudl be a bug if such a big value reaches it an assertion makes sense, I'd think 06:52 < wumpus> sipa: right, that would just move the issue to the interface :) 06:53 < wumpus> so if you say "it should be able to handle the entire mempool", I still think it would be an abomination if the mempool was larger than half the virtual address space on 64-bit platforms :) 06:53 < GitHub19> [bitcoin] dragongem45 closed pull request #7839: Expose information on whether transaction relayed is enabled in getne… (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7839 06:55 -!- molly [~molly@unaffiliated/molly] has quit [Quit: Leaving] 06:56 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:01 < wumpus> helo: probably, as the deserializer has knowledge of the types involved 07:06 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:08 -!- lclc [~lclc@unaffiliated/lclc] has left #bitcoin-core-dev ["Konversation terminated!"] 07:08 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 07:08 < wumpus> if it doesn't check type validity, then who will? having deserialized objects in memory constructed with invalid bit patterns could be a security or stability issue 07:09 < wumpus> shit, just wiped the gitian output again by starting before I copied out the executables 07:18 < GitHub24> [bitcoin] dragongem45 opened pull request #7841: Expose information on whether transaction relayed is enabled in getnetwork (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7841 07:38 < morcos> sdaftuar: wumpus: i got a failure of bip68-sequence.py in 0.12.1rc2 . but its intermittant. looking into it. 07:39 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 07:49 -!- cryptapus_afk is now known as cryptapus 07:50 -!- cryptapus is now known as cryptapus_ 07:50 -!- cryptapus_ is now known as cryptapus__ 07:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 07:50 -!- cryptapus__ is now known as cryptapus 07:50 < morcos> i suspect the problem is that if the version of your bitcoind that generated your cache is old then the CSV activation doesn't happen as expected in that test 07:52 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 07:53 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 07:53 -!- bsm1175321 is now known as bsm117532 07:53 -!- 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] 07:54 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev 07:56 * MarcoFalke Should buy more ram so gitian can run while working 08:00 < morcos> yes thats the problem, i was confused b/c there are two cache directories. one in pull-tester and one in rpc-tests 08:00 < morcos> would it make sense for make clean to wipe out the cache directories? 08:01 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 08:07 < morcos> jonasschnelli: oops forgot to ping you. i'm here. 08:17 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 08:17 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 08:18 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 08:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 08:31 -!- yoghur114 [~jorn@131.224.198.111] has joined #bitcoin-core-dev 08:33 -!- yoghur114 [~jorn@131.224.198.111] has quit [Client Quit] 08:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:43 -!- abritoid [~abritoid@46.16.193.99] has quit [Quit: O.o] 08:48 < wumpus> morcos: so removing the cache made the problem go away? 09:02 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 09:03 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev 09:03 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host] 09:03 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:07 < morcos> wumpus: yep. it works fine with a fresh cache. 09:07 < morcos> it makes sense that the old cache wouldn't work 09:07 < wumpus> phew! 09:25 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:41 < btcdrak> why are gitian builds so slow in comparison to building on a non VM using same number of cores to compile with? 09:43 < MarcoFalke> depends take the longest time 09:48 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev 09:51 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 268 seconds] 09:53 < sdaftuar> morcos: oops, thanks for figuring it out. seems innocuous enough to not worry about fixing in 0.12.1? 09:53 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev 09:58 < GitHub122> [bitcoin] paveljanik opened pull request #7842: RPC: do not print minping time in getpeerinfo when no ping received yet (master...20160408_getpeerinfo_no_ping_yet) https://github.com/bitcoin/bitcoin/pull/7842 10:11 < instagibbs> during a reorg, when(if ever) does a node re-broadcast transactions that have re-entered the mempool 10:21 < morcos> instagibbs: i assume it does not 10:23 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:24 < instagibbs> matches up with my testing just making sure 10:25 < instagibbs> python testing kind of breaks when that happens, since many times it checks to ensure that mempools are synced 10:26 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Client Quit] 10:27 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 10:32 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection] 10:47 < btcdrak> interesting. I just noticed Github has started verifying GPG signed commits if you give it your key https://i.imgur.com/MNIYMm0.png 10:47 < sipa> btcdrak: yup, i uploaded mine 10:47 < btcdrak> https://i.imgur.com/KWHyAxe.png 10:48 < btcdrak> yeah that's cool. 10:49 -!- mesmer_ [~mesmer@unaffiliated/mesmer] has quit [Quit: Leaving] 10:49 -!- mesmer [~mesmer@unaffiliated/mesmer] has joined #bitcoin-core-dev 10:49 < sipa> drommels drommels en nog eens drommels 10:49 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 10:50 * btcdrak googles franticly 10:50 < btcdrak> "devils devils and further rattling" 10:51 * sipa curses at C++ globals initialization & destruction order 11:01 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds] 11:15 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 11:15 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 12:10 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 12:25 < cfields_> gitian builders: 0.12.1rc2 signatures are pushed 12:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 12:26 < ThomasV> are there ongoing projects to implement a utxo merkle tree in bitcoind ? 12:30 < ThomasV> btcdrak: you used to work on addrindex, is it still active? 12:31 < btcdrak> yes 12:31 < ThomasV> how does it work? 12:31 < btcdrak> See my fork 12:32 < sipa> ThomasV: you one that is committed to by the blockchain? 12:32 < sipa> *mean 12:32 < ThomasV> sipa: obviouly not.. you already told me that is not planned 12:33 < sipa> then why do you need to be a merkle tree? 12:33 < sipa> :) 12:34 < sipa> i am planning to make the gettxoutsetinfo RPC call compute a merkle on the fly of the utxo set (indexed by txid, not by address) 12:34 < sipa> so there could be future calls that query and produce proofs about it 12:34 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection] 12:34 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 12:35 < ThomasV> sipa: what kind of proofs do you mean? 12:35 < sipa> ThomasV: assuming that you get that merkle root from a trusted place, i can prove to you that a particular utxo exists or doesn't exist 12:36 < ThomasV> sipa: long term I want to add versum to electrum servers 12:36 < sipa> versum? 12:36 < ThomasV> https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj7s5S35P_LAhUI2SwKHYP7Du4QFggdMAA&url=https%3A%2F%2Fpeople.csail.mit.edu%2Fnickolai%2Fpapers%2Fvandenhooff-versum.pdf&usg=AFQjCNHfZH5-aM9YEgKwhDKqOjZBuugEMA 12:36 < ThomasV> err https://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf 12:36 < ThomasV> unless utxo commitments happen, of course 12:37 < ThomasV> that's why I prefer a merkle tree 12:37 < sipa> ok, i'll read it later 12:39 < ThomasV> sipa: btw, why is it that you decided to index by txid ? 12:40 < sipa> ThomasV: because that's what matters for validation 12:41 < ThomasV> oh sure 12:41 < sipa> constructing a merkle tree at least requires to have the data ordered by the lookup key 12:41 < sipa> and we already have the utxo set ordered by txid 12:42 < sipa> ThomasV: where are you based, btw? 12:43 < ThomasV> in Berlin 12:43 < ThomasV> btcdrak: which branch should I look at? 12:44 < btcdrak> addrindex-0.12 12:44 < btcdrak> also tagged and binaries built in releases tab 12:46 < sipa> ThomasV: ah, i'm in stuttgart currently 12:47 < ThomasV> sipa: permanently? I thought you were in zurich 12:47 < sipa> ThomasV: no, for a few days 12:47 < ThomasV> k 12:47 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has joined #bitcoin-core-dev 12:50 * sipa 's geography of germany is not very good 12:51 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has quit [Client Quit] 12:51 < GitHub61> [bitcoin] initaldk opened pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843 12:52 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev 12:52 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has quit [Remote host closed the connection] 12:53 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 13:04 < GitHub172> [bitcoin] sipa closed pull request #7843: Delete CONTRIBUTING.md (master...patch-3) https://github.com/bitcoin/bitcoin/pull/7843 13:20 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer] 13:20 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 13:29 < ThomasV> stuttgart is much closer to zurich than to berlin :) 13:39 < ThomasV> time to watch spacex tv.. 13:49 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 13:56 -!- s-matthew-englis [83dc09ae@gateway/web/freenode/ip.131.220.9.174] has joined #bitcoin-core-dev 13:56 -!- s-matthew-englis [83dc09ae@gateway/web/freenode/ip.131.220.9.174] has quit [Client Quit] 13:57 -!- matthew_english [83dc09ae@gateway/web/freenode/ip.131.220.9.174] has joined #bitcoin-core-dev 13:57 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 13:58 < matthew_english> hi paveljanik 13:58 < paveljanik> matthew_english, Hi! 13:59 < matthew_english> :) 13:59 < matthew_english> so- do you think we might be able to figure out how to commit this silly change? 13:59 < paveljanik> yup 14:00 < paveljanik> please do again step by step what I wrote to you and lets pause in vi :-) 14:00 < matthew_english> thank you for your help thus far also 14:00 < matthew_english> ok coo 14:00 < matthew_english> cool 14:00 < matthew_english> so I'll delete the repo and reclone it- one moment... 14:00 < paveljanik> yes 14:00 < paveljanik> I'll do it here too 14:00 < matthew_english> ok 14:01 < matthew_english> i downloaded my own fork 14:01 < matthew_english> alright 14:01 < matthew_english> now I'm in vi 14:01 < paveljanik> so you see two lines starting with pick, right? 14:02 < matthew_english> righto 14:02 * paveljanik is an Emacs user 8) 14:02 < matthew_english> haha I'm a sublime user 14:02 < paveljanik> so go to the second line 14:02 < matthew_english> very lame 14:02 < matthew_english> but 14:02 < matthew_english> I want to start using emacs 14:02 < matthew_english> ok 14:02 < matthew_english> and must press 'i' isn't it? 14:02 < paveljanik> push x to delete one character, repeat until there is no p i c k :-) 14:03 < matthew_english> ok 14:03 < matthew_english> done 14:03 < paveljanik> then i and type squash or s, it is enough 14:03 < paveljanik> so your first line reads pick something 14:03 < paveljanik> second line s something 14:03 < paveljanik> then you are ready to exit 14:03 < matthew_english> ok cool 14:03 < paveljanik> Esc : wq 14:03 < matthew_english> the :q 14:03 < matthew_english> ah ok cool 14:03 < paveljanik> you know more than me :-) 14:04 < paveljanik> This command instructs git to squash the second commit, to hide it 14:04 < paveljanik> and now you'll see git commit message 14:04 < matthew_english> to make the two into one 14:04 < matthew_english> I guess 14:04 < matthew_english> hmm 14:04 < paveljanik> it contains both lines - from the first and also from the second squashed commit 14:04 < paveljanik> right? 14:04 < paveljanik> they are both the same in your case. 14:05 < matthew_english> can I do 'git status' to see it? 14:05 < paveljanik> you can use git log (in the other terminal, yes) 14:05 < paveljanik> but you are in the middle of rebase... 14:05 < matthew_english> I did git log 14:05 < paveljanik> git log shows you commit messages 14:06 < paveljanik> yes 14:06 < matthew_english> but I don't see a commit message 14:06 < matthew_english> it just says 'update polcy.cpp' twice 14:06 -!- matthew_english [83dc09ae@gateway/web/freenode/ip.131.220.9.174] has left #bitcoin-core-dev [] 14:06 < paveljanik> we will move to PM 14:13 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 250 seconds] 14:31 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 14:37 < GitHub111> [bitcoin] sipa opened pull request #7846: Clean up lockorder data of destroyed mutexes (master...cleanlocks) https://github.com/bitcoin/bitcoin/pull/7846 14:49 < Chris_Stewart_5> Does the 'bool' returned by EvalScript inside of interpreter indicate that the transaction has been marked invalid, or that the script execution ended in the returned bool value?' 14:50 < sipa> EvalScript just evaluates, it doesn't check success conditions 14:50 < sipa> so if it returns false, it means an error occurred 14:50 < sipa> VerifyScript tests the success conditions for use in transactions 14:50 < Chris_Stewart_5> because shouldn't the top of the stack indicate if the script exectuion was true/false? 14:50 < sipa> yes, VerifyScript tests that 14:51 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has quit [Quit: Page closed] 14:51 < Chris_Stewart_5> gotcha. Thanks for the clarification 14:59 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] 15:00 < kanzure> for emails rejected on the bitcoin-core-dev mailing list, should they also be forwarded to bitcoin-dev-moderation@lists.ozlabs.org or should that feed remain for bitcoin-dev mailing list rejection only? 15:01 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 250 seconds] 15:02 -!- xabbix [~xabbix@bzq-79-178-52-49.red.bezeqint.net] has joined #bitcoin-core-dev 15:02 -!- xabbix [~xabbix@bzq-79-178-52-49.red.bezeqint.net] has quit [Changing host] 15:02 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev 15:16 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 15:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 15:55 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 15:58 < GitHub158> [bitcoin] gmaxwell closed pull request #7805: Eliminate TX trickle bypass, sort TX invs for privacy and priority. (master...sorted_invs) https://github.com/bitcoin/bitcoin/pull/7805 16:03 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 16:06 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 16:10 -!- river__ [uid155689@gateway/web/irccloud.com/x-yxxlxrsxngalzybn] has quit [Quit: Connection closed for inactivity] 16:14 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 16:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 16:31 -!- Cory [~C@unaffiliated/cory] has quit [] 16:38 -!- PRab [~chatzilla@c-68-51-175-167.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 16:42 -!- PRab [~chatzilla@c-68-51-175-167.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 16:52 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 16:54 -!- cryptapus is now known as cryptapus_afk 16:58 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds] 17:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 17:21 < GitHub129> [bitcoin] mruddy opened pull request #7847: doc: add arch linux build example (master...doc-build-arch-linux) https://github.com/bitcoin/bitcoin/pull/7847 17:24 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds] 18:01 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ndvovvicnwwbekvn] has quit [Quit: Connection closed for inactivity] 18:07 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:08 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton] 18:08 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] 18:30 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:35 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 18:44 -!- xabbix [~xabbix@unaffiliated/xabbix] has quit [Ping timeout: 246 seconds] 18:44 -!- xabbix [~xabbix@unaffiliated/xabbix] has joined #bitcoin-core-dev 18:49 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 18:49 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev 19:08 -!- jtimon [~quassel@227.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 19:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 19:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:42 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 268 seconds] 19:42 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 19:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 20:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:05 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection] 21:08 -!- electrumuser [~foobar@181.121.64.244] has joined #bitcoin-core-dev 21:53 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 21:57 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 22:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:19 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 22:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds] 23:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:00 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has joined #bitcoin-core-dev 23:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:37 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #bitcoin-core-dev 23:44 < GitHub163> [bitcoin] laanwj opened pull request #7848: Divergence between 32- and 64-bit when hashing >4GB affects `gettxoutsetinfo` (master...2016_04_hash_4gb_utxoset) https://github.com/bitcoin/bitcoin/pull/7848 23:58 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:59 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev