--- Day changed Mon May 09 2016
00:01 -!- fengling_ [~fengling@111.198.29.53] has joined #bitcoin-core-dev
00:02 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
00:21 < GitHub6> [bitcoin] pstratem opened pull request #8028: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk (master...2016-05-09-cwalletdb-writetx) https://github.com/bitcoin/bitcoin/pull/8028
00:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:38 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 265 seconds]
00:39 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
00:39 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:51 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
00:54 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]
00:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:03 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:04 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
01:06 -!- xiangfu [~xiangfu@49.4.170.106] has quit [Ping timeout: 276 seconds]
01:07 < phantomcircuit> i like how the trivial patch to change keypool size has tons of activity
01:07 < phantomcircuit> :P
01:07 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
01:09 -!- xiangfu [~xiangfu@49.4.170.106] has joined #bitcoin-core-dev
01:11 < paveljanik> phantomcircuit, you are not the first though. MAX_BLOCK_SIZE...
01:14 < jonasschnelli> :)
01:15 < phantomcircuit> ha
01:16 < phantomcircuit> now i just need someone to review 8028
01:16 < phantomcircuit> it's almost as trivial
01:16  * phantomcircuit looks at jonasschnelli 
01:20  * jonasschnelli will look at 8028
01:20 < jonasschnelli> I never liked the wtx.WriteToDisk()
01:21 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has joined #bitcoin-core-dev
01:21 -!- AaronvanW [~ewout@172pc231.sshunet.nl] has quit [Changing host]
01:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:21 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:23 < gmaxwell> BlueMatt: I think pieter told you that your compact block recovery should request the txn when there is a collision.  You should also have the recovery check the orphan pool for txn.
01:23 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]
01:23 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
01:30 -!- MarcoFalke [81bbf086@gateway/web/cgi-irc/kiwiirc.com/ip.129.187.240.134] has joined #bitcoin-core-dev
01:31 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
01:31 < MarcoFalke> jonasschnelli, 8018 looks good. Mind to address the nit?
01:31 < jonasschnelli> MarcoFalke: yes. Will do in a couple of hours. Need to finish the open work before I can checkout the branch. :)
01:32 < MarcoFalke> sure, take your time.
01:32  * sipa casually mentions git-worktree, which allows checking out two branches simultaneously
01:35 < wumpus> git-worktree is great, it requires a pretty new git though, unfortunately
01:35 < jonasschnelli> hmm... I probably should check this.
01:36 < jonasschnelli> I have also multiple working copies to switch between work
01:36 < wumpus> yes I simply have mulitple clones now
01:36 < jonasschnelli> But loosing focus means loosing productivity. :)
01:36 < wumpus> will switch to git-worktree when I upgrade more widely to ubuntu 16.04
01:36 < sipa> jonasschnelli: you need to upgrade your brain to a multicore one
01:37 < jonasschnelli> haha... I already run on 8 cores!
01:37 < sipa> wumpus: no problems with ubuntu 16.04 here
01:37 < jonasschnelli> core-dev organizing, Pine64/Odroid installation, hardware wallet work, libbtc and managing a familiy... :)
01:37 < wumpus> sipa: no problems here either, but there is no supported upgrade path from 14.04 to 16.04 yet
01:37 < sipa> upgrading worked fine here
01:38 < wumpus> so all my 16.04 installations are either upgraded from 15.10 or new ones
01:38 < GitHub105> [bitcoin] fanquake opened pull request #8029: [Doc] Simplify OS X build notes (master...osx-build-notes) https://github.com/bitcoin/bitcoin/pull/8029
01:38 < sipa> i used do-release-upgrade -d
01:38 < gmaxwell> Hurray for the multiple clone workflow!
01:38 < gmaxwell> join us
01:39 < wumpus> well what Ubuntu says is that "14.04 LTS to LTS upgrades will be enabled with the 16.04.1 LTS point release, in approximately 3 months time.". I think it's the safer option. I can wait 3 months for that anyhow :)
01:40 -!- xiangfu [~xiangfu@49.4.170.106] has quit [Ping timeout: 265 seconds]
01:41 < sipa> wumpus: ha, i didn't bother to look that up and just used the dev upgrade... it has always worked fine in the past :)
01:41 < sipa> and if it fails, it's not like reinstalling is a disaster
01:41  * sipa zZzZ
01:42 < wumpus> heh :)
01:43 < wumpus> I've had very mixed experiences with upgrading, usually it goes fine, but I've also had it crash during upgrade once, or apparently upgrade fine that have an avalanche of errors at the next start
01:46 -!- MarcoFalke [81bbf086@gateway/web/cgi-irc/kiwiirc.com/ip.129.187.240.134] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
01:51 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
01:54 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
01:58 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 246 seconds]
01:59 < wumpus> worst upgrade experience I ever had was with slackware, a bug in a documentation(!) package upgrader caused a rm -rf /, when I was wondering why it was taking so long it was nearly too late. These days I keep good backups.
02:00 < gmaxwell> wumpus: there have been a couple of those incidents over the years.
02:04 < wumpus> ouch
02:06 < gmaxwell> one of the popular linux music players ("amarok"?) had a system("rm -rf "||unquoted_file_name); for when you told it to delete a file...
02:07 < gmaxwell> better not delete "dance / greatesthits.mp3"
02:07 < kinlo> sigh, what's wrong with a call to unlink() ?  why do ppl call the shell so much
02:08 < wumpus> yes, seems absurd to use the shell for that. Usage of system() is usually a code stink
02:09 -!- G1lius [~stefangil@109.201.143.198] has joined #bitcoin-core-dev
02:14 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
02:19 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
02:24 -!- fengling_ [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
02:29 -!- fengling__ [~fengling@111.198.29.53] has joined #bitcoin-core-dev
02:31 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
02:38 < jonasschnelli> can the cache-sizes be changed during runtime?
02:38 < jonasschnelli> Things like nCoinCacheUsage
02:49 < wumpus> no
02:50 < wumpus> (I don't think there's any deep reason for that not being possible though)
02:50 < wumpus> at least the size of the coin cache could be trivially changed, it's just a threshold
02:50 < gmaxwell> some kinds of datastructures are fairly hard to resize at runtime. ... bloom filters being an example.
02:51 < wumpus> the leveldb caches on the other hand probably require re-opening the dtabase
02:51 < wumpus> true, but I don't think we have any user-sizable bloom filters
02:54 < wumpus> travis is stil suffering from unrelated zmq issues: https://github.com/bitcoin/bitcoin/pull/8006
02:56 < wumpus> I think it makes sense to temporarily revert fa05e22e919b7e2e816606f0c0d3dea1bd325bfd so that missing python-zmq package is not fatal
02:58 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 276 seconds]
02:59 < paveljanik> or you can temporarily add python-zmq to travis
02:59 < paveljanik> but anyway: +1
02:59 < GitHub128> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f17032f70328...e29cfc48fc08
02:59 < GitHub128> bitcoin/master c8b9248 21E14: Remove obsolete reference to CValidationState from UpdateCoins.
02:59 < GitHub128> bitcoin/master e29cfc4 Wladimir J. van der Laan: Merge #7976: Remove obsolete reference to CValidationState from UpdateCoins....
03:00 < GitHub10> [bitcoin] laanwj closed pull request #7976: Remove obsolete reference to CValidationState from UpdateCoins. (master...cleancoinsupdate) https://github.com/bitcoin/bitcoin/pull/7976
03:00 < wumpus> paveljanik: I'm not convinced that that solves the issue
03:00 < wumpus> last time I checked the travis configuration it *should* be okay, if not, that'd be the obvious solution
03:02 < paveljanik> you have checked that the tests were done using python2 and python-zmq (ie. python-zmq for Python2) was installed?
03:02 < wumpus> the tests cannot be done using python 2 anymore
03:02 < paveljanik> even if the branch was created at the time when python2 was used?
03:03 < wumpus> as I understand it, the travis testing merges your changes into master then runs the tests
03:03 < wumpus> so the python 3 test framework will get applied to it
03:04 -!- fengling__ is now known as fengling
03:05 < paveljanik> wumpus, yes.
03:05 < paveljanik> in the case, you linked to, python-zmq was installed
03:05 < paveljanik> but python3-zmq was needed
03:05 < paveljanik> ie. travis used wrong config IMO
03:06 < paveljanik> the old one from pre-python3
03:06 < wumpus> ah! so it uses the travis configuration from the branch it is testing, not master with the changes merged in
03:06 -!- Guest89406 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev
03:06 < wumpus> as I'm fairly sure master's travis.yml specifies python3-zmq correctly
03:06 < paveljanik> so rebasing the branch is the solution
03:06 < paveljanik> yup
03:07 -!- gevs [~greg@unaffiliated/gevs] has quit [Ping timeout: 260 seconds]
03:08 < wumpus> yes, but asking everyone to rebase their pull request because of completely unrelated issues is messy
03:09 < phantomcircuit> i think travis is screwing up on 8026
03:09 < paveljanik> yes, so if travis is using the old config and new test scripts from master, then yes, reverting the mentioned commit can help
03:10 < phantomcircuit> hmm maybe not
03:11 < phantomcircuit> oh i see
03:11 < phantomcircuit> heh
03:11 < phantomcircuit> fundrawtransaction.py tries to encrypt the wallet...
03:14 < GitHub96> [bitcoin] laanwj opened pull request #8030: test: Revert fatal-ness of missing python-zmq (master...2016_05_revert_zmq_req_tests) https://github.com/bitcoin/bitcoin/pull/8030
03:19 < jonasschnelli> The idea I had with resize the caches was that Bitcoin-Qt could ask for a db cache size during first run (like the datadir), then It could allocate ~>1GB, after IBD it could reduce it back to 100MB.
03:19 < jonasschnelli> Using 1.5GB would probably reduce IBD form a couple of days to a couple of hours
03:21 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
03:21 < wumpus> sounds like a good idea to me, probably the same option should hold when the node has been down for a while, while catching up
03:21 < wumpus> it should be optional of course; not everyone cares about fast sync speed, some people prefer it to happen in the background with as little system load (cpu, memory) as possible
03:23 < jonasschnelli> right
03:24 < wumpus> but a choice when first launching the software would make snse
03:25 < wumpus> sync as fast as possible, but hogging the computer, or sync slowly and steadily in the background, this could also set -par
03:42 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
03:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
04:16 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
04:17 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
04:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
04:25 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds]
04:28 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:34 < GitHub123> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e29cfc48fc08...a68f56e727c3
04:34 < GitHub123> bitcoin/master b02119e Pavel Janík: Remove useless argument to AlertNotify....
04:34 < GitHub123> bitcoin/master a68f56e Wladimir J. van der Laan: Merge #7958: Remove useless argument to AlertNotify....
04:34 < GitHub31> [bitcoin] laanwj closed pull request #7958: Remove useless argument to AlertNotify. (master...20160427_AlertNotify_remove_arg) https://github.com/bitcoin/bitcoin/pull/7958
04:35 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
04:35 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
04:36 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
04:37 < jonasschnelli> wumpus: what was the reason you have started with lmdb? Did you had problems compiling leveldb for Odroid?
04:37 < wumpus> leveldb was horribly slow on my odroid-C2
04:37 < jonasschnelli> I just successfully compiled (and running IBD) bitcoin-core master for Pine64
04:37 < wumpus> I noticed high I/O latency, but had nothing to compare to, so I wondered whether another database would do better
04:38 < wumpus> haven't had any problems with stability of leveldb on aarch64
04:38 < jonasschnelli> wumpus: But i guess you ran with a high DB cache?
04:39 < wumpus> yes, reasonably high, though the device has 2GB  of memory so some care has to be taken not to invite the OOM killer
04:40 < jonasschnelli> I guess if i run with -dbcache=1500 it will result in only tiny disk i/o?
04:40 < wumpus> as long as not the entire utxo set fits in memory you'll have fairly much disk i/o, especially after flushes
04:41 < jonasschnelli> Right. This is a point.
04:41 < wumpus> anyhow I wanted a lmdb branch to be able to compare databases, many people said they were going to try with lmdb over the years and no one actually did it :) And ARM going 64-bit as well makes it somewhat more attractive.
04:41 -!- raedah [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
04:42 < wumpus> I also have a dummydb branch, whose point is to have the entire utxo set in memory but in a more compact format than expanded -dbcache
04:44 < wumpus> e.g. an utxo dump takes about 1.5GB, whereas a sync with -dbcache=<lots> goes to about 5.5GB of memory usage, so there is some scope there (not enough to fit everything into the 2GB of memory of the odroid probably, there will always be some overhead, but okay)
04:45 < jonasschnelli> wumpus: what i/o (disk) do you use? SDCard? USB/SSD?
04:46 < wumpus> I've tried with external USB2 hdd and with a network block device mounted over 1000gb link
04:46 < wumpus> sdcard is a pretty bad idea for the database, I've worn at least one USB stick that way :)
04:47 < jonasschnelli> Right. We discussed that before. 1GB link is probably the fastest i/o (next to the GPIO).
04:47 < wumpus> there's no SATA on the board unfortuantely or I'd have used that
04:48 < wumpus> yes the network I/O is fast
04:48 < wumpus> in throughput at least, latency was still disappointing here
04:49 < jonasschnelli> Hmm... good point. Latency might be very important for the utxo set
04:51 < jonasschnelli> Pine64<->USB2.0<->HDD should result in 30MB/s r/w. Not very powerful but should be enough for a full node.
04:51 < wumpus> as for databases my (inconclusive) results seems to be that lmdb was somewhat better in query latency, but leveldb seems to be faster in writing
04:51 < jonasschnelli> Disabling bloom filter should be done then.
04:52 < wumpus> yes the throughput is good enough
04:52 < wumpus> especially for block storage
04:53 < jonasschnelli> But I guess also the latency. GBit Eth. has probably higher latencies (regarding utxo set)
05:02 < GitHub145> [bitcoin] s-matthew-english opened pull request #8031: improvement to readability (master...patch-3) https://github.com/bitcoin/bitcoin/pull/8031
05:06 -!- bysherper [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
05:09 -!- earlest [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
05:13 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
05:13 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
05:23 -!- cryptapus_afk is now known as cryptapus
05:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wkvlmznxgfxnpddr] has quit [Quit: Connection closed for inactivity]
05:49 -!- MarcoFalke [81bbe55b@gateway/web/cgi-irc/kiwiirc.com/ip.129.187.229.91] has joined #bitcoin-core-dev
05:54 < MarcoFalke> wumpus, have you tried clearing the travis cache? If you look at  7938 there are also other pulls messed up (This one prob due to the cpp11 switch) ...
05:54 < MarcoFalke> I am just guessing that it is caused by corrupt cache, though.
05:59 < wumpus> I've tried clearing the caches for a few pulls, yes, what I have not tried is clearing all the caches
05:59 < wumpus> (afraid it will hamper all testing)
06:00 < wumpus> but I can try clearing 7938, sure
06:00 < MarcoFalke> As I understand it, it should only make it slower until there is a commit to -master. But if you prefer to disable the zmq error, fine with me.
06:02 < MarcoFalke> I'd rather have more travis failures than less because the test can only tell you something is wrong. They can never tell you something is right.
06:03 < MarcoFalke> So the alternative would be to ignore unrelated errors as best as possible
06:03 < MarcoFalke> if they accumulate to high nubers, though, it might be better to disable the test...
06:03 < wumpus> but false positives are bad, the missing zmq error prevents all RPC tests from being run
06:04 < wumpus> it's preferable to just not run the zmq test - especially if the pull in question doesn't change anything zmq related at all
06:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-obnkpuiyrbflptaf] has joined #bitcoin-core-dev
06:05 < MarcoFalke> I am assuming it would fail the other test as well because there is something wrong with the cached python version
06:05 < wumpus> I don't think there is anything wrong with the cached python version, apart from the missing python3-zmq package
06:06 < wumpus> I think it's simply a matter of the wrong package being installed
06:06 < wumpus> e.g. python-zmq is installed instead of python3-zmq
06:06 < wumpus> so the test fails to find it
06:07 < paveljanik> But anyway, this is the only test that needs separate package installed. I think it should be written as it "succeeds" when the is no such package. It will make testing easier on clean installs, will shorten the documentation etc.
06:07 < paveljanik> s/the/there/
06:07 < wumpus> that used to be the case
06:07 < paveljanik> yes
06:08 < paveljanik> But I respect the change.
06:08 < wumpus> until #7851, https://github.com/bitcoin/bitcoin/pull/8030 would temporarily bring back that behavior
06:09 < wumpus> I'm open to other solutions, but 'all old pulls have to be rebased' is not acceptable
06:10 < MarcoFalke> paveljanik, The error message is pretty clear how to fix the issue on the user side (#ERROR: \"import zmq\" failed. Set ENABLE_ZMQ=0 or ...
06:10 < paveljanik> MarcoFalke, yes, of course. But slows down the work a bit.
06:10 < paveljanik> wumpus, yes, definitely. It can also help us to understand the problem.
06:10 < MarcoFalke> and I want travis to fail if pzthon-zmq is missing instead of just returning 'succeed'
06:10 < wumpus> as this would mean you could no longer submit pulls based on older commits for no good reason
06:10 < paveljanik> right now, we are all guessing only.
06:11 < MarcoFalke> 8030 temporarily, ACK from me
06:11 < wumpus> yes let's just try it
06:11 < paveljanik> +1
06:12 < GitHub109> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a68f56e727c3...409a8a1637d4
06:12 < GitHub109> bitcoin/master 65fee8e Wladimir J. van der Laan: test: Revert fatal-ness of missing python-zmq...
06:12 < GitHub109> bitcoin/master 409a8a1 Wladimir J. van der Laan: Merge #8030: test: Revert fatal-ness of missing python-zmq...
06:12 < GitHub21> [bitcoin] laanwj closed pull request #8030: test: Revert fatal-ness of missing python-zmq (master...2016_05_revert_zmq_req_tests) https://github.com/bitcoin/bitcoin/pull/8030
06:13 < wumpus> re-triggering #8006
06:14 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
06:14 < wumpus> if it fails on something else now, it's clear that the problem goes deeper
06:16  * paveljanik grabs some popcorn ;-)
06:19 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
06:27 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:31 -!- MarcoFalke [81bbe55b@gateway/web/cgi-irc/kiwiirc.com/ip.129.187.229.91] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
06:37 -!- shesek [~shesek@bzq-84-110-33-207.red.bezeqint.net] has joined #bitcoin-core-dev
07:04 < wumpus> looks like it worked https://github.com/bitcoin/bitcoin/pull/8006
07:16 -!- muftop [~muft0p@50.248.81.65] has joined #bitcoin-core-dev
07:20 < wumpus> any other pulls that need travis respin now?
07:26 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 260 seconds]
07:28 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
07:28 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
07:31 < BlueMatt> gmaxwell: yea, sipa and I spoke about collision-recovery and trying each tx or just requesting...
07:31 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:32 < BlueMatt> gmaxwell: I hadnt done it originally, but if I'm gonna drop it from 64 bits to something smaller it starts to matter
07:33 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
07:33 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
07:50 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
07:55 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
08:00 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
08:01 < GitHub186> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/409a8a1637d4...3e90fe653420
08:01 < GitHub186> bitcoin/master 5ea4508 Jonas Schnelli: Autofind rpc tests --srcdir
08:01 < GitHub186> bitcoin/master 3e90fe6 MarcoFalke: Merge #8018: Autofind rpc tests --srcdir...
08:01 < GitHub197> [bitcoin] MarcoFalke closed pull request #8018: Autofind rpc tests --srcdir (master...2016/05/fix_test_srcdir) https://github.com/bitcoin/bitcoin/pull/8018
08:03 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
08:03 -!- bsm1175321 is now known as bsm117532
08:04 -!- raedah [~raedah3@172.56.39.105] has quit [Quit: Leaving]
08:04 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
08:05 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Client Quit]
08:06 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
08:07 < GitHub98> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e90fe653420...4e14afe42fdd
08:07 < GitHub98> bitcoin/master fabbf6b MarcoFalke: [qa] Refactor test_framework and pull tester...
08:07 < GitHub98> bitcoin/master 2222dae MarcoFalke: [qa] Update README.md
08:07 < GitHub98> bitcoin/master fafb33c MarcoFalke: [qa] Stop other nodes, even when one fails to stop
08:07 < GitHub50> [bitcoin] MarcoFalke closed pull request #7971: [qa] Refactor test_framework and pull tester (master...Mf1604-qaRefactor) https://github.com/bitcoin/bitcoin/pull/7971
08:13 < jonasschnelli> gmaxwell, sipa: for keypools containing HD keys: do we need two keypools? one for internal (change), one for external usage?
08:13 < sipa> yes
08:14 < sipa> but i don't think that's a necessity for a first working version
08:14 < jonasschnelli> sipa, okay will start using only the external chain.
08:15 < jonasschnelli> Also,.. i will re-derive the external child key in each GenerateNewKey to keep the diff small and tight.
08:17 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
08:20 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
08:22 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:22 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
08:27 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
08:34 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
08:40 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has joined #bitcoin-core-dev
08:43 -!- earlest [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
08:45 -!- bysherper [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
08:46 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:48 < jonasschnelli> sipa, if we only have one hd master key in the database, would a static AES IV be okay for encrypting/decrypting the master key?
08:49 < jonasschnelli> Or do i have to generate a random IV and store if in the same data-record?
08:49 < jonasschnelli> nm, ... need to do the later
08:49 < sipa> you can just make the master key itself a wallet key
08:50 < sipa> and store the corresponding pubkeyhash in the wallet
08:50 < jonasschnelli> meh..
08:50 < sipa> so you automatically get the encryption benefits
08:50 < jonasschnelli> though about that. But do we really want to loose the CExtKey metadata?
08:50 < sipa> how do you mean?
08:50 < jonasschnelli> This would really be hard to extend then (if we would use a CKey for the master key)
08:50 < sipa> why?
08:51 < jonasschnelli> What if someone wants to later start a wallet with a xpriv at m/44/0/0?
08:52 < jonasschnelli> And how would we distinct between a normal CKey and a CKey thats used as bip32 masterkey?
08:52 < jonasschnelli> Just over the metadata?
08:52 < sipa> just make it a ckey that's not added to the keypool
08:52 < sipa> so it's never exposed as a receive address
08:53 < sipa> maybe add a field to its metadata to indicate that it's not a wallet key
08:54 < jonasschnelli> hmm... but ckey is used for crypted keys, right? At least during db load we need to identify the ckey that is used for a master key.
08:54 < sipa> why?
08:54 < jonasschnelli> hmm... right, we could just store the pubkeyhash somewhere to identify the master key...
08:55 < jonasschnelli> But all "ckey" objects get passed into LoadCryptedKey
08:55 < sipa> yes, that's exactly what you want?
08:55 < jonasschnelli> What if the wallet is unencrypted?!
08:55 < sipa> then it's stored as an unencrypted key
08:55 < jonasschnelli> heh...
08:55 < sipa> also exactly what you want
08:56 < jonasschnelli> Where do we store the chaincode? Unencrypted in metadata?
08:56 < jonasschnelli> Ah.. wait.
08:56 < jonasschnelli> We always use setMaster()
08:56 -!- raedah [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
08:56 < sipa> yes, you'd have a hdderive wallet record which stores 1) the pubkeyhash of the master key 2) the path for derivation 3) how many keys have been derived already
08:56 < sipa> you could avoid 3, and derive it at startup
08:57 < jonasschnelli> Okay. I'll see. This is simpler. Thanks for the sparring.
08:57 < jonasschnelli> 3 is necessary to refill the keypool i guess
08:57 < sipa> right, but when generating a new key, you can just check whether you already have the newly derived key
08:57 < sipa> and in that case, increment the (in-memory only) counter and try again
08:58 < jonasschnelli> okay... this could get slow if your keypool gets bigger
08:58 < sipa> perhaps you can even use exponential backoff, so it's only log(n) time in the number of keys
08:58 < jonasschnelli> I don't use flexible keypath for now. So your 2) is not necessary for now.
08:58 < jonasschnelli> Is will just use m/1/<key>
08:58 < jonasschnelli> To avoid another 50L of code
08:58 < sipa> ok
09:08 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:10 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
09:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds]
09:13 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: probably dropping off the net for a very long time]
09:25 -!- CubicEarth [~cubiceart@c-73-68-232-79.hsd1.ma.comcast.net] has quit []
09:41 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
09:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-obnkpuiyrbflptaf] has quit [Quit: Connection closed for inactivity]
09:55 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:01 -!- muftop [~muft0p@50.248.81.65] has quit [Ping timeout: 244 seconds]
10:01 -!- raedah [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
10:01 -!- muftop [~shitstain@50.248.81.65] has joined #bitcoin-core-dev
10:02 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
10:06 -!- raedah [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
10:07 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
10:08 -!- raedah [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
10:20 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
10:24 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
10:27 -!- raedah [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
10:27 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
10:29 -!- G1lius [~stefangil@109.201.143.198] has quit []
10:30 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
10:33 -!- raedah [~raedah3@172.56.39.105] has left #bitcoin-core-dev ["Leaving"]
10:38 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
10:44 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:46 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
10:46 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-clntsfhqzacevmxq] has joined #bitcoin-core-dev
10:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
10:50 -!- waxmiguel_ [70d02459@gateway/web/freenode/ip.112.208.36.89] has joined #bitcoin-core-dev
11:19 -!- bysherper [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
11:22 -!- earlest [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
11:27 -!- raedah1 [~raedah3@172.56.39.105] has joined #bitcoin-core-dev
11:27 -!- raedah1 [~raedah3@172.56.39.105] has quit [Remote host closed the connection]
11:29 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev
11:32 -!- 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]
11:36 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds]
11:38 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:39 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:40 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:43 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:44 -!- earlest [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
11:47 -!- bysherper [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
11:55 -!- waxmiguel_ [70d02459@gateway/web/freenode/ip.112.208.36.89] has quit [Ping timeout: 250 seconds]
12:01 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:03 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
12:05 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:07 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
12:14 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:25 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
12:47 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
12:51 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
12:59 < luke-jr> CodeShark: I think this is broken: if (pindex->nVersion > VERSIONBITS_LAST_OLD_BLOCK_VERSION && (pindex->nVersion & ~nExpectedVersion) != 0)
13:22 < gmaxwell> BlueMatt: sipa suggests the sender choose the size, and send a byte with the number of bytes, constrained to 4-8. 
13:23 < gmaxwell> BlueMatt: sipa can probably suggest a decision table based on block/mempool size.
13:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
13:47 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
13:52 -!- BitcoinErrorLog [~bitcoiner@c-71-203-187-87.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
13:53 < BlueMatt> gmaxwell: yea, I was thinking I might have to split udp vs tcp for size, but thats a good point that you could even lookup-table-it
13:53 < BlueMatt> though I'm not sure how useful that would be really well
13:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:58 < sipa> BlueMatt: the formula is just log2(mempool_txn * unmatched_txn / failure_rate)
13:59 < sipa> if that's over 40, use 6 bytes, otherwise 5
14:02 < gmaxwell> BlueMatt: did you see my comment about adding the orphan pool to your search.
14:05 < BlueMatt> gmaxwell: I did not
14:05 < BlueMatt> valid point, but "meh"
14:07 < gmaxwell> BlueMatt: I instrumented my copy and a lot of the missed txn are in the orphan pool.
14:08 < BlueMatt> WTF :(
14:09 -!- murch [~murch@p4FE3A38F.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
14:11 < gmaxwell> actually it makes a lot of sense until the node has been up a long time. the reason is that txn get stuck outside of the chain due to missing parents thanks to trickling.
14:11 < gmaxwell> it'll be much better with 0.13 widely deployed, but it's cheap to check the orphan pool.
14:21 < BlueMatt> yea, understood
14:31 < gmaxwell> (we also need to fix some of the orphan pool issues that the trickle improvements exposed)
14:32 < BlueMatt> yea, that
14:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
14:50 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
14:54 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
14:56 -!- erasmospunk [~erasmospu@151.41.35.121] has joined #bitcoin-core-dev
15:13 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 252 seconds]
15:20 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
15:23 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:28 -!- cryptapus_ [~cyptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds]
15:30 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
15:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:14 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
16:38 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
16:39 -!- cryptapus is now known as cryptapus_afk
16:41 -!- tsunami11 [47e1442d@gateway/web/freenode/ip.71.225.68.45] has joined #bitcoin-core-dev
16:46 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
16:57 -!- alpalp [~allen@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
16:57 -!- alpalp [~allen@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
16:57 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev
17:24 -!- tsunami11 [47e1442d@gateway/web/freenode/ip.71.225.68.45] has quit [Ping timeout: 250 seconds]
17:29 -!- bysherper [~denetrabu@96.93.57.150] has joined #bitcoin-core-dev
17:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-clntsfhqzacevmxq] has quit [Quit: Connection closed for inactivity]
17:31 -!- earlest [~denetrabu@96.93.57.150] has quit [Ping timeout: 240 seconds]
17:35 -!- mode/#bitcoin-core-dev [+o btcdrak] by ChanServ
17:35 -!- mode/#bitcoin-core-dev [+q slackircbridge!*@*] by btcdrak
17:35 -!- mode/#bitcoin-core-dev [-o btcdrak] by ChanServ
17:39 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
17:39 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
17:44 -!- mode/#bitcoin-core-dev [+o btcdrak] by ChanServ
17:45 -!- mode/#bitcoin-core-dev [-o btcdrak] by ChanServ
17:56 -!- Justinus [~Justinus@192.122.131.41] has quit [Remote host closed the connection]
17:57 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
17:58 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
17:59 -!- erasmospunk [~erasmospu@151.41.35.121] has quit [Remote host closed the connection]
17:59 -!- erasmospunk [~erasmospu@151.41.35.121] has joined #bitcoin-core-dev
18:00 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
18:02 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
18:02 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
18:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
18:05 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
18:06 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
18:09 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
18:09 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
18:19 < GitHub94> [bitcoin] wtogami opened pull request #8033: Fix Socks5() connect failures to be less noisy and unnecessarily scary (master...proxy_fail_too_scary) https://github.com/bitcoin/bitcoin/pull/8033
18:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
18:28 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 265 seconds]
18:47 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev
18:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:59 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:03 -!- erasmospunk [~erasmospu@151.41.35.121] has quit [Remote host closed the connection]
19:10 -!- anchow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
19:23 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
19:25 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]
19:34 -!- anchow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving]
19:44 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev
19:45 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 276 seconds]
19:45 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined #bitcoin-core-dev
19:53 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds]
20:07 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev
20:21 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Remote host closed the connection]
20:22 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
20:25 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
20:27 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
20:34 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 244 seconds]
20:36 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
21:04 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
21:06 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
21:07 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
21:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:34 -!- fengling [~fengling@111.198.29.53] has quit [Quit: WeeChat 1.4]
21:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:57 -!- challisto [~challisto@unaffiliated/challisto] has quit [Quit: Leaving]
22:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 265 seconds]
22:21 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Quit: Leaving.]
22:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:08 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving]
23:10 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
23:13 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
23:32 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
23:35 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
23:40 < GitHub23> [bitcoin] fanquake opened pull request #8034: [doc][trivial] Add basic git squash workflow (master...contrib-squash) https://github.com/bitcoin/bitcoin/pull/8034
23:46 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]