--- Day changed Mon Oct 19 2015
00:03 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
00:35 -!- equil_ [~equil@195-154-199-164.rev.poneytelecom.eu] has joined #bitcoin-core-dev
01:02 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 265 seconds]
01:15 < Luke-Jr> gmaxwell: caching ordered tx list is faster than removing smart time. good enough? :x
01:16 < gmaxwell> Luke-Jr: so what happens when the wallet is huge?
01:17 < gmaxwell> then we end up with this gigantic tx list cache in ram. :(
01:17 < Luke-Jr> eh, right now we store all the tx anyway..
01:17 < Luke-Jr> is storing a list of pointers all that much more?
01:19 < gmaxwell> I guess not, probably only another three gigabytes of ram with the whole blockchain in your wallet.
01:20 < gmaxwell> I'm not super keen on this whole issue existing though. :-/
01:25 < gmaxwell> Re: 6844 I am twitching a bit about more things being added to the rest api, while little effort has been performed to gain strong confidence that it's not a remote code execution vector. IIRC, we were able to crash the node via it when it went in and we addressed that by disabling it by default. I absolutely don't want to crap on 6844 itself, as it looks like a great feature. But we are making 
01:26 < gmaxwell> an error if we continue to offer a potentially insecure external interface and make it more and more attractive to turn it on and expose it.
01:29 < gmaxwell> (keep in mind that even if it is localhost only; a local webbrowser has almost free reign over it.)
01:32 < phantomcircuit> whoa what?
01:32 < phantomcircuit> you can remotely crash the rest api?
01:35 < gmaxwell> phantomcircuit: Could initially. I'm unsure if it's fixed, it's a huge attack surface in any case-- we don't have any fuzzing harness for it either. 
01:35 < gmaxwell> (the prior crash I was aware of was just send it an infinityish sized request...)
01:55 < wumpus> it's relatively safe as long as the JSON parser is not used for input data, and if there is an input argument it is just a simple linear string directly part of the URI, with straightforward validation
01:56 < wumpus> the crash was a case where JSON spirit was used to parse input data query, which had a known out of memory crash if you make structures too deep
01:56 < gmaxwell> heh. I found a (local) buffer overflow bug in wget while trying to crash it.
01:56 < wumpus> IMO REST is for 'trivial, quickly answered, traightforward queries', not where you need to pass in JSON encoded monstriosities
01:57 < jonasschnelli> wumpus, yes. Probably a good idea. What about maximum length of URLs in case of submit tx?
01:57 < wumpus> gmaxwell: that could still be interesting; some scripts are bound to pass remote input to wget's parameters
01:57 < wumpus> jonasschnelli: there definitely should be a limit!
01:58 < jonasschnelli> wumpus: right. But it might be, that http clients or proxys are using limits lower then the user might expect.
01:58 < jonasschnelli> I think for large tx /GET is not suitable.
01:58  * wumpus wishes he had more time to hunt for vulnerabilities in bitcoind's codebase
01:58 < jonasschnelli> POST with hex/bin should be supported IMO
01:59 < wumpus> using GET to provide input for tx submission is very un-restful
01:59 < jonasschnelli> most webservers (and probably proxys) have a limit of 8KB for URL (HTTP GET) length
01:59 < wumpus> should be PUT?
02:00 < wumpus> or yes, POST
02:00 < jonasschnelli> wumpus: agree. PUT or POST would be better. But there comes in the question of supporting JSON... which is a security risk.
02:00 < wumpus> no, no JSON
02:00 < jonasschnelli> Maybe just support BIN/HEX
02:00 < wumpus> just raw POST data
02:00 < jonasschnelli> (or only BIN)
02:00 < jonasschnelli> wumpus: agree.
02:01 < wumpus> JSON  is ok for returning data in some cases, but should not be *parsed* in REST
02:02 < Luke-Jr> can we parse plain English language instead?
02:02  * Luke-Jr hides
02:02 < wumpus> Luke-Jr: http://inform7.com/ ? :p
02:05 < gmaxwell> please don't do the rest submittx at all if its only bin, if it won't take hex it will be massively less used, and we'll just have more code to hang around and bloat the codebase; while people will continue to eschew bitcoin core and use some web api that actually gives an interface people expect. :-/
02:05 < gmaxwell> okay, I feel better now-- I have a whole bunchof fuzzers running against it at the moment and it's not immediately dying.
02:05 < gmaxwell> \O/
02:05 < jonasschnelli> gmaxwell: agree. Hex should be supported in the first place.
02:06 < wumpus> hex is fine, just don't add a zillion kinds of input formats...
02:07 < wumpus> each one adds more attack surface
02:07 < Luke-Jr> tonal pls
02:07 < wumpus> hah...
02:07 < Luke-Jr> (no, tonal isn't used for binary data..)
02:08 < Luke-Jr> is -connect=0 the best way to avoid any external interactions with p2p?
02:08 < wumpus> -connect=0.0.0.0 
02:08 < Luke-Jr> k
02:09 < wumpus> -connect=0 will work too, but will spam your debug.log with errors
02:10 < wumpus> but yes I feel bad about adding more and more to the REST interface as well. Initially it was meant to just request data, making it possible to submit transactions unauthenticated is a different thing.
02:10 < wumpus> I understand why it's useful of course...
02:12 < Luke-Jr> IMO it will get horridly abused
02:12 < Luke-Jr> when Eligius offered such a thing, it got hard-coded into spam scripts
02:13 < wumpus> you're not *supposed* to offer REST interface to the open internet, but lacking auth it may be easy to do accidentally (same as zillions of other critical systems are accidentally on the internet)
02:13 < gmaxwell> I dunno if there is any real reason to do anything but hex.
02:13 < gmaxwell> I suppose if block submission was also supported then the hex overhead would be pretty unwelcome.
02:13 < gmaxwell> and for that we'd want binary data. so there might be a uniformity argument.
02:13 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Remote host closed the connection]
02:13 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
02:14 -!- Guest52664 [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has quit [Remote host closed the connection]
02:14 -!- gmaxwell is now known as Guest89849
02:14 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev
02:14 -!- petertodd is now known as Guest82934
02:15 < wumpus> binary is the least risky to accept, I don't think there's anything to be won by not accepting that
02:15 < wumpus> then again I don't really care, if you want to make it hex-only, be my guest, just don't add JSON parsing
02:16 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds]
02:16 < wumpus> (or any encoding more involved than straightforward encode-two-characters-to-one like hex)
02:20 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
02:24 < GitHub21> [bitcoin] luke-jr opened pull request #6851: Optimisation: Store transaction list order in memory rather than compute it every need (master...opti_txorder) https://github.com/bitcoin/bitcoin/pull/6851
02:26 < wumpus> Luke-Jr: why is -zapwallettxes performance a goal?
02:27 < wumpus> isn't that a troubleshooting option that should be quite rarely used?
02:28 < Luke-Jr> wumpus: I don't know, gmaxwell was annoyed it was taking some guy with a big wallet 9 hours. Apparently it's more common because we don't handle malleability right still.
02:29 < Luke-Jr> wumpus: but right now, it sorts the entire wallet's transactions every time it adds a new transaction to the wallet. so it's pretty bad.
02:29 < GitHub48> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d78a880900c1...5888046323dd
02:29 < GitHub48> bitcoin/master d2e3fbc Thomas Kerin: Mention PHP bindings to libbitcoinconsensus
02:29 < GitHub48> bitcoin/master 5888046 Wladimir J. van der Laan: Merge pull request #6849...
02:29 < GitHub130> [bitcoin] laanwj closed pull request #6849: Mention PHP bindings to libbitcoinconsensus (master...bitcoinconsensus-php-bindings) https://github.com/bitcoin/bitcoin/pull/6849
02:30 < wumpus> we had a RPC pull request at some point where it was possible to remove conflicted transactions one-by-one, I greatly preferred that to the hammer that is zapwallettxes
02:31 < wumpus> it's pretty bad but does it warrant using more memory even in the cases where people don't use zapwallettxes?
02:32 < wumpus> I don't think so - memory usage of bitcoind is already famously bad
02:32 < Luke-Jr> for the wallet? I've only heard complaints when people fail to configure their mempool policy
02:33 < wumpus> sorry to be grumpy about this but there's so many people complaining about that
02:33 < wumpus> well the entire wallet is kept in memory at alll times
02:34 < Luke-Jr> yes, that's why I didn't think the overhead from this would be significant ;)
02:35 < Luke-Jr> (my hot wallet has been in regularish use since 2009 and hasn't reached 40 MB yet..)
02:35 < wumpus> i don't like "it's already bad, so making it any worse doesn't matter" arguments, but ok...
02:35 < Luke-Jr> 2010*
02:36 < dcousens> IMHO, I'd argue the REST API shouldn't exist at all
02:36 < dcousens> Its trivial to expose it via the RPC if you want to do that
02:37 < wumpus> that was my argument too; it could just as well have been an external script that wraps RPC and proides a new API
02:37 < dcousens> For the same reasons Guest89849 (gmaxwell) mentioned before, its just a huge surface vector for limited gain
02:38 < wumpus> but who listens to me...
02:38 < Luke-Jr> wumpus: the benefits IMO significantly outweigh the costs. someone would need to be running some major service provider to use a lot of memory for the wallet, and that use case is just out of reach for bitcoind's wallet without any kind of major rewrite
02:38 < wumpus> not everything has to be in the monolithic bitcoind executable
02:38 < Luke-Jr> even aside from zap, it improves performance for listtransactions RPC etc
02:42 < wumpus> Luke-Jr: oh if it helps perfomance in other places too you should definitely mention that!
02:42 < dcousens> wumpus: Luke-Jr has mentioned a few times now people writing their own mempool policy, which is fine, and maybe including stricter default policies might be slightly controversial (too restrictive etc),  but,  maybe some pre-written policies that users can easily enable that have some sane defaults would be beneficial?
02:42 < wumpus> Luke-Jr: I wasn't aware, and just 'it improves zapwallettx' is not a big selling point to me
02:43 < Luke-Jr> k, added it to the summary. looks like it's *just* listtransactions
02:43 < wumpus> dcousens: if someone wants to write and test them, I don't see why not, there are some pulls that factor out the mempool policy stuff which makes it easier to create custom ones, at least in theory
02:44 < dcousens> wumpus: I mean, I guess that would be the ideal case right?
02:44 < dcousens> Everyone configuring their policy to what they are happy with
02:44 < wumpus> dcousens: the ideal case - from the network view - is that everyone runs the same, predictable policy
02:44 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
02:44 < dcousens> wumpus: true, but varying hardware requirements mean that is difficult to cater for
02:45 < dcousens> So, I guess, you could go the highly configurable policy route
02:45 < wumpus> dcousens: if people insist on using their own mempool policy on their miner there's no way to prevent that, and arguably it shouldn't be made more difficult than necessary to prevent stupid issues from patching
02:45 < dcousens> Or what seems to be the current direction, scalable policy which matches your hardware (if configured)
02:45 < wumpus> dcousens: but I'm not sure it makes sense to talk about the ideal case there
02:46 < wumpus> how does hardware determine the policy? just how much memory available?
02:46 < dcousens> wumpus: yes
02:46 < wumpus> if so, adding a parameter to set the amount of memory used (with as little impact otherwise) would be preferable
02:46 < Luke-Jr> wumpus: everyone running the same predictable policy necessarily implies centralisation and censorship risk
02:46 < wumpus> that's the whole point of the mempool limiting
02:47 < wumpus> add limiting but don't mess up the network too much or introduce DDoSes
02:47 < wumpus> I don't see the point of 'highly configurable policy' just to work around hardware limitations
02:47 < dcousens> Luke-Jr: only if the default policy is restrictive right?
02:48 < Luke-Jr> dcousens: which it must be
02:48 < dcousens> Luke-Jr: or do you mean, encouraging people just to use the bundled policy is the centralizatoin risk?
02:48 < dcousens> (as it seemed you implied to me last night)
02:49 < wumpus> Luke-Jr: censorship risk? that's a strawman, I'm talking a about a *sane* default policy, not some blacklist hellscape
02:49 < Luke-Jr> dcousens: I was responding to wumpus saying ideal is everyone on the same policy.
02:49 < wumpus> if bitcoin core starts to include code that censors specific transactions/senders, start running very fast
02:49 < Luke-Jr> wumpus: a unified policy means there is someone making the decisions
02:50 < dcousens> Luke-Jr: you could say the same thing about a unified protocol
02:51 -!- zveda [zveda@gateway/vpn/mullvad/x-ikilwfkccbmwewii] has joined #bitcoin-core-dev
02:51 -!- zveda [zveda@gateway/vpn/mullvad/x-ikilwfkccbmwewii] has left #bitcoin-core-dev ["Ex-Chat"]
02:56 < wumpus> right, it is about encouraging people to use the same or similar policy for relaying, there is no mechanism to force nodes to use a certain policy. And if someone powerful wanted to censor it'd be much more effective to approach the (heavily centralized) miners than trying to get it merged upstream.
03:01 < GitHub166> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5888046323dd...fc41278e9689
03:01 < GitHub166> bitcoin/master 99963b9 Mitchell Cash: Correct spelling mistakes in doc folder...
03:01 < GitHub166> bitcoin/master fc41278 Wladimir J. van der Laan: Merge pull request #6843...
03:01 < GitHub177> [bitcoin] laanwj closed pull request #6843: Trivial: Correct spelling mistakes in doc folder (master...spelling_fixes) https://github.com/bitcoin/bitcoin/pull/6843
03:13 < GitHub163> [bitcoin] laanwj opened pull request #6852: build: make sure OpenSSL heeds noexecstack (master...2015_10_openssl_noexecstack) https://github.com/bitcoin/bitcoin/pull/6852
03:15 < GitHub98> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fc41278e9689...5f5ee0f3ce6b
03:15 < GitHub98> bitcoin/master 0658d0b Alex Morcos: temporarily comment out rpcbind.py...
03:15 < GitHub98> bitcoin/master 5f5ee0f Wladimir J. van der Laan: Merge pull request #6837...
03:15 < GitHub134> [bitcoin] laanwj closed pull request #6837: Cleanup rpc-tests.py (master...fixupRPCtests) https://github.com/bitcoin/bitcoin/pull/6837
03:44 < GitHub199> [bitcoin] laanwj closed pull request #6162: Use 512-bit arithmetic for difficulty retarget calculation. (master...regtest_consensus_fix) https://github.com/bitcoin/bitcoin/pull/6162
03:48 -!- murr4y [murray@kvikshaug.no] has joined #bitcoin-core-dev
03:54 -!- equil_ [~equil@195-154-199-164.rev.poneytelecom.eu] has quit [Ping timeout: 264 seconds]
03:56 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
03:56 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
04:20 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
04:58 -!- ParadoxSpiral [~ParadoxSp@p508B9AF1.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:13 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 272 seconds]
05:26 < GitHub124> [bitcoin] CodeShark opened pull request #6853: Added fNoRetargeting field to Consensus::Params (master...fNoRetargeting) https://github.com/bitcoin/bitcoin/pull/6853
05:39 < CodeShark> why are the travis tests failing on windows? https://travis-ci.org/bitcoin/bitcoin/jobs/86161511
05:40 < btcdrak> Trolling for reviews/ACKs please https://github.com/bitcoin/bitcoin/pull/6566 (Median past locktime)
05:44 -!- malte [~malte@2a00:d0c0:200:0:b9:1a:9c2c:1] has quit [Ping timeout: 252 seconds]
05:47 -!- malte [~malte@alkaid.uberspace.de] has joined #bitcoin-core-dev
06:01 < GitHub52> [bitcoin] laanwj opened pull request #6854: devtools: Add security-check.py (master...2015_10_security_checks) https://github.com/bitcoin/bitcoin/pull/6854
06:03 < GitHub166> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5f5ee0f3ce6b...da7d57fb9501
06:03 < GitHub166> bitcoin/master bfcdc21 Wladimir J. van der Laan: build: make sure OpenSSL heeds noexecstack...
06:03 < GitHub166> bitcoin/master da7d57f Wladimir J. van der Laan: Merge pull request #6852...
06:03 < GitHub39> [bitcoin] laanwj closed pull request #6852: build: make sure OpenSSL heeds noexecstack (master...2015_10_openssl_noexecstack) https://github.com/bitcoin/bitcoin/pull/6852
06:05 < GitHub136> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/21e58b8e3544987db0bdaa91c23bb398e655bd21
06:05 < GitHub136> bitcoin/0.11 21e58b8 Wladimir J. van der Laan: build: make sure OpenSSL heeds noexecstack...
06:05 < GitHub70> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/0b3fd07fd24a96b205d4f85d00157d5f115fad9e
06:05 < GitHub70> bitcoin/0.10 0b3fd07 Wladimir J. van der Laan: build: make sure OpenSSL heeds noexecstack...
06:09 < kanzure> wumpus: for rescan locking, would be nice to show lock status in another rpc command.
06:09 < kanzure> lock statuses per thread or something
06:20 < wumpus> meh, I don't think debugging information belongs on RPC
06:20 < wumpus> at least not something that low level - can't gdb show locking debug information?
06:22 < wumpus> I guess it could be something explicitly enabled with --enable-debug like DEBUG_LOGCONTENTION
06:22 < wumpus> LOCK*
06:27 < GitHub47> [bitcoin] laanwj closed pull request #6836: Bring historical release notes up to date (0.10...0.10-add-release-notes) https://github.com/bitcoin/bitcoin/pull/6836
06:27 < GitHub169> [bitcoin] laanwj pushed 2 new commits to 0.10: https://github.com/bitcoin/bitcoin/compare/0b3fd07fd24a...7e9a9874f3cc
06:27 < GitHub169> bitcoin/0.10 fb818b6 Micha: Bring historical release notes up to date...
06:27 < GitHub169> bitcoin/0.10 7e9a987 Wladimir J. van der Laan: Merge pull request #6836...
06:29 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 264 seconds]
07:00 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer]
07:00 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev
07:00 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host]
07:00 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
07:10 -!- Guest82934 is now known as petertodd
07:20 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
07:23 < wumpus> the more I think about it the more I think we should have implemented REST as a separate script that wraps the RPC interface... I really don't like how another interface to the same things is converging more and more on RPC's functionality
07:24 < btcdrak> ^
07:25 < btcdrak> wumpus: could still be changed that way now
07:26 < wumpus> yes
07:28 < wumpus> with libevent's http, and univalue-as-as-library it shouldn't be that difficult at all
07:31 < wumpus> (even to do it in C wouldn't, I mean, in python it's obviously easy)
07:32 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
07:37 < btcdrak> wumpus: so really, if you want this to be done you'll have to refuse to merge new duplicate REST methods until the wrapper is done.
07:37 < wumpus> if I want it to be done I'll have to do it myself...
08:05 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
08:14 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
08:14 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
08:15 -!- malte [~malte@alkaid.uberspace.de] has quit [Ping timeout: 252 seconds]
08:21 -!- malte [~malte@alkaid.uberspace.de] has joined #bitcoin-core-dev
08:22 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
09:00 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:06 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
09:18 -!- Guest89849 is now known as gmaxwell
09:18 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has quit [Changing host]
09:18 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
09:23 < GitHub73> [bitcoin] lclc opened pull request #6855: [REST] API versioning (master...restVersioning) https://github.com/bitcoin/bitcoin/pull/6855
--- Log closed Mon Oct 19 09:30:46 2015
--- Log opened Mon Oct 19 09:31:23 2015
09:31 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev
09:31 -!- Irssi: #bitcoin-core-dev: Total of 68 nicks [0 ops, 0 halfops, 0 voices, 68 normal]
09:31 -!- petertodd is now known as Guest98736
09:35 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has joined #bitcoin-core-dev
09:35 -!- jcorgan [~jcorgan@ec2-54-67-38-167.us-west-1.compute.amazonaws.com] has quit [Changing host]
09:35 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
09:37 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
09:39 -!- Irssi: Join to #bitcoin-core-dev was synced in 540 secs
09:55 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Remote host closed the connection]
09:56 < gmaxwell> wumpus: I like that too.
09:56 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
09:57 -!- maaku is now known as Guest17159
10:33 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
10:33 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
10:33 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
10:53 -!- Guest17159 is now known as maaku
11:29 -!- maaku [~quassel@botbot.xen.prgmr.com] has quit [Remote host closed the connection]
11:30 -!- maaku [~quassel@botbot.xen.prgmr.com] has joined #bitcoin-core-dev
11:30 -!- maaku is now known as Guest13301
11:31 -!- Guest13301 is now known as maaku
12:28 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 260 seconds]
12:32 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:38 < GitHub130> [bitcoin] morcos opened pull request #6856: Do not allow block file pruning during reindex. (master...noPruneDuringReindex) https://github.com/bitcoin/bitcoin/pull/6856
12:41 -!- maaku__ [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev
12:44 < GitHub123> [bitcoin] morcos opened pull request #6857: Require nLastBlockFile to be the highest numbered file. (master...nLastBlockFile) https://github.com/bitcoin/bitcoin/pull/6857
13:08 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
13:16 -!- ParadoxSpiral [~ParadoxSp@p508B9AF1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
13:49 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
14:07 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 250 seconds]
14:10 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Ping timeout: 268 seconds]
14:12 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
14:31 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:40 -!- midnightmagic_ [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
14:43 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Disconnected by services]
14:44 -!- midnightmagic_ is now known as midnightmagic
16:54 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qbcxeduyeasabbni] has quit [Quit: Connection closed for inactivity]
17:15 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
17:18 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
17:28 < Luke-Jr> How important is memory comparison for #6851 ? I get a std::bad_alloc with my test wallet, so I'll need to find something less spammy and start over :/
17:34 < gmaxwell> Luke-Jr: how much memory does the host you're testing on have?
17:35 < Luke-Jr> gmaxwell: 16 GB, but 32-bit can only alloc <4 GB
17:36 < Luke-Jr> I'm not surprised that a wallet with dice addresses overflows it.
17:37 < gmaxwell> Luke-Jr: did you try turning down caching? ... we're already pretty close to the wire address space wise on 4gb to begin with.
17:38 < Luke-Jr> I didn't. But IIRC dice uses >4 GB of transactions in the blockchain, so really I don't expect anything to help except remaking the wallet with a lower volume address
17:45 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
17:55 -!- Jaamg [jhpiloma@gateway/shell/tkk.fi/x-sbbebcqcbuvuwpgc] has quit [Ping timeout: 240 seconds]
18:17 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:01 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
20:35 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has quit [Ping timeout: 268 seconds]
20:48 -!- baldur [~baldur@pool-173-52-43-219.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
21:56 < Luke-Jr> ok, so I did the memory comparison on Eligius's mining key
21:56 < Luke-Jr> = 10184 wtxns
21:57 < Luke-Jr> ps showed lower memory usage (in all three of SIZE, VSZ, and SZ) for the optimised/cached bitcoind. Obviously it couldn't have been actually reduced, so I conclude it's unmeasurably small.
22:04 -!- phantomcircuit [~phantomci@strateman.ninja] has quit [Ping timeout: 260 seconds]
22:10 < gmaxwell> 10000 isn't that many. :(
22:12 < Luke-Jr> gmaxwell: not enough to at least show a measurable difference if it were a problematic increase?
22:12  * Luke-Jr ponders how he has no block sources with 10 connections :/
22:14 < Luke-Jr> cute, my next block is inflight from an XT node which is apparently not sending it?
22:20 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
22:27 -!- ParadoxSpiral [~ParadoxSp@p508B9AF1.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
22:36 -!- ParadoxSpiral [~ParadoxSp@p508B9AF1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
23:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-upqwkcyzshifosnk] has joined #bitcoin-core-dev
23:27 < wumpus> curious
23:36 -!- Thireus [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
23:48 < wumpus> how openbsd, even with the recent release, still manages to package a BDB that is *older* than the 4.8 required to build bitcoin core
23:55 < Luke-Jr> lol
23:56 < midnightmagic> netcraft confirms it..?
23:59  * Luke-Jr ponders if it would be difficult to gitian-build bitcoind for Android <.<