12016-05-09T00:15:32 *** alpalp has joined #bitcoin-core-dev
22016-05-09T00:15:32 *** alpalp has joined #bitcoin-core-dev
32016-05-09T00:16:21 *** Guyver2 has quit IRC
42016-05-09T00:23:32 *** raedah1 has joined #bitcoin-core-dev
52016-05-09T00:26:17 *** raedah has quit IRC
62016-05-09T00:34:17 *** alpalp has quit IRC
72016-05-09T00:34:34 *** alpalp has joined #bitcoin-core-dev
82016-05-09T00:40:22 *** raedah has joined #bitcoin-core-dev
92016-05-09T00:51:10 *** Ylbam has quit IRC
102016-05-09T01:00:52 *** raedah1 has joined #bitcoin-core-dev
112016-05-09T01:01:26 *** raedah1 has quit IRC
122016-05-09T01:01:52 *** raedah1 has joined #bitcoin-core-dev
132016-05-09T01:04:29 *** raedah has quit IRC
142016-05-09T01:05:12 *** belcher has quit IRC
152016-05-09T01:08:40 *** baldur has joined #bitcoin-core-dev
162016-05-09T01:09:22 *** raedah1 is now known as raedah
172016-05-09T01:12:14 <Chris_Stewart_5> Is there an easy way to see the serialization for a transaction inside of CTransactionSignatureSerializer (not just the hash)?
182016-05-09T01:17:09 <sipa> replace it with a CDataStream :)
192016-05-09T01:20:45 <phantomcircuit> is there any reason not to encrypt the wallet by default with a null master key?
202016-05-09T01:20:46 <GitHub22> [bitcoin] pstratem opened pull request #8025: Increase DEFAULT_KEYPOOL_SIZE to 10000. (master...2016-05-08-wallet-defaults) https://github.com/bitcoin/bitcoin/pull/8025
212016-05-09T01:23:35 <Chris_Stewart_5> thank you so much sipa. I spent much more time than I would like to admit trying to figure that out :-)
222016-05-09T01:29:20 <phantomcircuit> BlueMatt, ^
232016-05-09T01:43:29 *** GAit has quit IRC
242016-05-09T01:43:34 <sipa> phantomcircuit: backward compatibility at the time
252016-05-09T01:43:42 <sipa> not really an argument anymore :)
262016-05-09T01:43:47 <phantomcircuit> k
272016-05-09T02:00:01 *** Alopex has quit IRC
282016-05-09T02:01:06 *** Alopex has joined #bitcoin-core-dev
292016-05-09T02:01:42 *** BashCo_ has joined #bitcoin-core-dev
302016-05-09T02:03:44 *** BashCo has quit IRC
312016-05-09T02:14:04 *** alpalp has quit IRC
322016-05-09T02:54:01 *** Alopex has quit IRC
332016-05-09T02:55:07 *** Alopex has joined #bitcoin-core-dev
342016-05-09T02:57:27 *** molz has quit IRC
352016-05-09T03:04:08 *** BashCo has joined #bitcoin-core-dev
362016-05-09T03:05:44 *** BashCo_ has quit IRC
372016-05-09T03:40:32 *** fengling has joined #bitcoin-core-dev
382016-05-09T03:46:38 <GitHub177> [bitcoin] pstratem opened pull request #8026: [WIP] Wallet: Cache CWalletDB pointer in CWallet to improve performance (master...2016-05-08-wallet-speed) https://github.com/bitcoin/bitcoin/pull/8026
392016-05-09T03:59:20 *** Chris_Stewart_5 has quit IRC
402016-05-09T04:05:58 *** moli has joined #bitcoin-core-dev
412016-05-09T04:24:01 *** Alopex has quit IRC
422016-05-09T04:25:07 *** Alopex has joined #bitcoin-core-dev
432016-05-09T04:48:34 *** kadoban has joined #bitcoin-core-dev
442016-05-09T04:50:02 *** Alopex has quit IRC
452016-05-09T04:51:07 *** Alopex has joined #bitcoin-core-dev
462016-05-09T04:55:50 *** fengling_ has joined #bitcoin-core-dev
472016-05-09T04:55:56 *** fengling has quit IRC
482016-05-09T05:02:00 *** BashCo_ has joined #bitcoin-core-dev
492016-05-09T05:04:20 *** BashCo has quit IRC
502016-05-09T05:06:02 *** Alopex has quit IRC
512016-05-09T05:07:07 *** Alopex has joined #bitcoin-core-dev
522016-05-09T05:08:48 *** Don_John has joined #bitcoin-core-dev
532016-05-09T05:22:57 *** fengling_ has quit IRC
542016-05-09T05:23:01 *** Alopex has quit IRC
552016-05-09T05:24:07 *** Alopex has joined #bitcoin-core-dev
562016-05-09T05:31:38 *** kadoban has quit IRC
572016-05-09T05:39:01 *** Alopex has quit IRC
582016-05-09T05:40:07 *** Alopex has joined #bitcoin-core-dev
592016-05-09T05:45:21 *** gill3s has joined #bitcoin-core-dev
602016-05-09T05:45:21 *** gill3s has joined #bitcoin-core-dev
612016-05-09T05:54:29 *** gill3s has quit IRC
622016-05-09T05:55:01 *** Alopex has quit IRC
632016-05-09T05:55:58 *** fengling_ has joined #bitcoin-core-dev
642016-05-09T05:56:06 *** Alopex has joined #bitcoin-core-dev
652016-05-09T06:26:34 *** xiangfu has joined #bitcoin-core-dev
662016-05-09T06:38:20 *** Ylbam has joined #bitcoin-core-dev
672016-05-09T06:42:54 *** BashCo_ has quit IRC
682016-05-09T06:45:57 *** fengling_ has quit IRC
692016-05-09T06:47:40 <phantomcircuit> sipa, btw i just had a ccache failure working on #8026
702016-05-09T06:52:47 <paveljanik> ccache failure?
712016-05-09T06:52:56 <GitHub143> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fbd84788e676...f17032f70328
722016-05-09T06:52:57 <GitHub143> bitcoin/master aa62b68 Pieter Wuille: Benchmark rolling bloom filter
732016-05-09T06:52:57 <GitHub143> bitcoin/master 1953c40 Pieter Wuille: More efficient bitsliced rolling Bloom filter...
742016-05-09T06:52:58 <GitHub143> bitcoin/master f17032f Wladimir J. van der Laan: Merge #7934: Improve rolling bloom filter performance and benchmark...
752016-05-09T06:53:06 <GitHub9> [bitcoin] laanwj closed pull request #7934: Improve rolling bloom filter performance and benchmark (master...benchrollingbloom) https://github.com/bitcoin/bitcoin/pull/7934
762016-05-09T06:54:09 *** assder has joined #bitcoin-core-dev
772016-05-09T06:55:21 *** murch has joined #bitcoin-core-dev
782016-05-09T06:57:02 <phantomcircuit> paveljanik, wallet.cpp was being compiled incorrectly
792016-05-09T06:57:15 <phantomcircuit> (or rather was compiling when it shouldn't have been)
802016-05-09T06:57:19 <phantomcircuit> ccache -C
812016-05-09T06:57:25 <phantomcircuit> and the issue disappeared
822016-05-09T06:57:43 <paveljanik> strange
832016-05-09T06:57:54 <paveljanik> never seen such issue with ccache...
842016-05-09T06:58:17 <phantomcircuit> haven't seen that kind of problem with it in... well yeah ever
852016-05-09T07:01:37 *** fengling_ has joined #bitcoin-core-dev
862016-05-09T07:02:24 *** gill3s has joined #bitcoin-core-dev
872016-05-09T07:21:17 <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
882016-05-09T07:28:30 *** BashCo has joined #bitcoin-core-dev
892016-05-09T07:38:25 *** gevs has quit IRC
902016-05-09T07:38:45 *** BashCo has quit IRC
912016-05-09T07:39:34 *** BashCo has joined #bitcoin-core-dev
922016-05-09T07:51:35 *** gevs has joined #bitcoin-core-dev
932016-05-09T07:54:33 *** BashCo has quit IRC
942016-05-09T07:57:50 *** Guyver2 has joined #bitcoin-core-dev
952016-05-09T08:02:52 *** BashCo has joined #bitcoin-core-dev
962016-05-09T08:04:20 *** gill3s has quit IRC
972016-05-09T08:06:20 *** xiangfu has quit IRC
982016-05-09T08:06:53 <phantomcircuit> i like how the trivial patch to change keypool size has tons of activity
992016-05-09T08:06:54 <phantomcircuit> :P
1002016-05-09T08:07:13 *** gill3s has joined #bitcoin-core-dev
1012016-05-09T08:08:56 *** xiangfu has joined #bitcoin-core-dev
1022016-05-09T08:11:31 <paveljanik> phantomcircuit, you are not the first though. MAX_BLOCK_SIZE...
1032016-05-09T08:14:10 <jonasschnelli> :)
1042016-05-09T08:15:31 <phantomcircuit> ha
1052016-05-09T08:15:40 <phantomcircuit> now i just need someone to review 8028
1062016-05-09T08:15:44 <phantomcircuit> it's almost as trivial
1072016-05-09T08:15:52 * phantomcircuit looks at jonasschnelli
1082016-05-09T08:19:59 * jonasschnelli will look at 8028
1092016-05-09T08:20:25 <jonasschnelli> I never liked the wtx.WriteToDisk()
1102016-05-09T08:20:39 *** AaronvanW has joined #bitcoin-core-dev
1112016-05-09T08:20:40 *** AaronvanW has joined #bitcoin-core-dev
1122016-05-09T08:21:02 *** BashCo_ has joined #bitcoin-core-dev
1132016-05-09T08:22:39 <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.
1142016-05-09T08:22:58 *** BashCo has quit IRC
1152016-05-09T08:23:33 *** gill3s has quit IRC
1162016-05-09T08:30:17 *** MarcoFalke has joined #bitcoin-core-dev
1172016-05-09T08:30:46 *** gill3s has joined #bitcoin-core-dev
1182016-05-09T08:30:52 <MarcoFalke> jonasschnelli, 8018 looks good. Mind to address the nit?
1192016-05-09T08:31:21 <jonasschnelli> MarcoFalke: yes. Will do in a couple of hours. Need to finish the open work before I can checkout the branch. :)
1202016-05-09T08:31:54 <MarcoFalke> sure, take your time.
1212016-05-09T08:32:07 * sipa casually mentions git-worktree, which allows checking out two branches simultaneously
1222016-05-09T08:35:21 <wumpus> git-worktree is great, it requires a pretty new git though, unfortunately
1232016-05-09T08:35:32 <jonasschnelli> hmm... I probably should check this.
1242016-05-09T08:35:45 <jonasschnelli> I have also multiple working copies to switch between work
1252016-05-09T08:35:54 <wumpus> yes I simply have mulitple clones now
1262016-05-09T08:35:59 <jonasschnelli> But loosing focus means loosing productivity. :)
1272016-05-09T08:36:22 <wumpus> will switch to git-worktree when I upgrade more widely to ubuntu 16.04
1282016-05-09T08:36:33 <sipa> jonasschnelli: you need to upgrade your brain to a multicore one
1292016-05-09T08:36:45 <jonasschnelli> haha... I already run on 8 cores!
1302016-05-09T08:36:53 <sipa> wumpus: no problems with ubuntu 16.04 here
1312016-05-09T08:37:16 <jonasschnelli> core-dev organizing, Pine64/Odroid installation, hardware wallet work, libbtc and managing a familiy... :)
1322016-05-09T08:37:19 <wumpus> sipa: no problems here either, but there is no supported upgrade path from 14.04 to 16.04 yet
1332016-05-09T08:37:32 <sipa> upgrading worked fine here
1342016-05-09T08:37:54 <wumpus> so all my 16.04 installations are either upgraded from 15.10 or new ones
1352016-05-09T08:38:01 <GitHub105> [bitcoin] fanquake opened pull request #8029: [Doc] Simplify OS X build notes (master...osx-build-notes) https://github.com/bitcoin/bitcoin/pull/8029
1362016-05-09T08:38:13 <sipa> i used do-release-upgrade -d
1372016-05-09T08:38:20 <gmaxwell> Hurray for the multiple clone workflow!
1382016-05-09T08:38:23 <gmaxwell> join us
1392016-05-09T08:39:30 <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 :)
1402016-05-09T08:39:48 *** xiangfu has quit IRC
1412016-05-09T08:41:14 <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 :)
1422016-05-09T08:41:27 <sipa> and if it fails, it's not like reinstalling is a disaster
1432016-05-09T08:41:37 * sipa zZzZ
1442016-05-09T08:42:34 <wumpus> heh :)
1452016-05-09T08:43:19 <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
1462016-05-09T08:46:14 *** MarcoFalke has quit IRC
1472016-05-09T08:50:45 *** Ginnarr has joined #bitcoin-core-dev
1482016-05-09T08:53:45 *** xiangfu has joined #bitcoin-core-dev
1492016-05-09T08:58:39 *** xiangfu has quit IRC
1502016-05-09T08:59:11 <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.
1512016-05-09T09:00:01 <gmaxwell> wumpus: there have been a couple of those incidents over the years.
1522016-05-09T09:04:19 <wumpus> ouch
1532016-05-09T09:06:08 <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...
1542016-05-09T09:06:43 <gmaxwell> better not delete "dance / greatesthits.mp3"
1552016-05-09T09:07:32 <kinlo> sigh, what's wrong with a call to unlink() ? why do ppl call the shell so much
1562016-05-09T09:08:11 <wumpus> yes, seems absurd to use the shell for that. Usage of system() is usually a code stink
1572016-05-09T09:08:46 *** G1lius has joined #bitcoin-core-dev
1582016-05-09T09:13:43 *** xiangfu has joined #bitcoin-core-dev
1592016-05-09T09:18:55 *** xiangfu has quit IRC
1602016-05-09T09:24:37 *** fengling_ has quit IRC
1612016-05-09T09:29:07 *** fengling__ has joined #bitcoin-core-dev
1622016-05-09T09:30:44 *** spudowiar has joined #bitcoin-core-dev
1632016-05-09T09:38:08 <jonasschnelli> can the cache-sizes be changed during runtime?
1642016-05-09T09:38:13 <jonasschnelli> Things like nCoinCacheUsage
1652016-05-09T09:49:29 <wumpus> no
1662016-05-09T09:49:50 <wumpus> (I don't think there's any deep reason for that not being possible though)
1672016-05-09T09:50:18 <wumpus> at least the size of the coin cache could be trivially changed, it's just a threshold
1682016-05-09T09:50:35 <gmaxwell> some kinds of datastructures are fairly hard to resize at runtime. ... bloom filters being an example.
1692016-05-09T09:50:40 <wumpus> the leveldb caches on the other hand probably require re-opening the dtabase
1702016-05-09T09:51:17 <wumpus> true, but I don't think we have any user-sizable bloom filters
1712016-05-09T09:54:23 <wumpus> travis is stil suffering from unrelated zmq issues: https://github.com/bitcoin/bitcoin/pull/8006
1722016-05-09T09:55:46 <wumpus> I think it makes sense to temporarily revert fa05e22e919b7e2e816606f0c0d3dea1bd325bfd so that missing python-zmq package is not fatal
1732016-05-09T09:58:36 *** amiller has quit IRC
1742016-05-09T09:59:21 <paveljanik> or you can temporarily add python-zmq to travis
1752016-05-09T09:59:34 <paveljanik> but anyway: +1
1762016-05-09T09:59:37 <GitHub128> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f17032f70328...e29cfc48fc08
1772016-05-09T09:59:38 <GitHub128> bitcoin/master c8b9248 21E14: Remove obsolete reference to CValidationState from UpdateCoins.
1782016-05-09T09:59:38 <GitHub128> bitcoin/master e29cfc4 Wladimir J. van der Laan: Merge #7976: Remove obsolete reference to CValidationState from UpdateCoins....
1792016-05-09T09:59:47 <GitHub10> [bitcoin] laanwj closed pull request #7976: Remove obsolete reference to CValidationState from UpdateCoins. (master...cleancoinsupdate) https://github.com/bitcoin/bitcoin/pull/7976
1802016-05-09T10:00:01 <wumpus> paveljanik: I'm not convinced that that solves the issue
1812016-05-09T10:00:26 <wumpus> last time I checked the travis configuration it *should* be okay, if not, that'd be the obvious solution
1822016-05-09T10:01:47 <paveljanik> you have checked that the tests were done using python2 and python-zmq (ie. python-zmq for Python2) was installed?
1832016-05-09T10:02:07 <wumpus> the tests cannot be done using python 2 anymore
1842016-05-09T10:02:35 <paveljanik> even if the branch was created at the time when python2 was used?
1852016-05-09T10:02:59 <wumpus> as I understand it, the travis testing merges your changes into master then runs the tests
1862016-05-09T10:03:05 <wumpus> so the python 3 test framework will get applied to it
1872016-05-09T10:03:56 *** fengling__ is now known as fengling
1882016-05-09T10:05:01 <paveljanik> wumpus, yes.
1892016-05-09T10:05:11 <paveljanik> in the case, you linked to, python-zmq was installed
1902016-05-09T10:05:20 <paveljanik> but python3-zmq was needed
1912016-05-09T10:05:29 <paveljanik> ie. travis used wrong config IMO
1922016-05-09T10:05:40 <paveljanik> the old one from pre-python3
1932016-05-09T10:05:58 <wumpus> ah! so it uses the travis configuration from the branch it is testing, not master with the changes merged in
1942016-05-09T10:05:59 *** Guest89406 has joined #bitcoin-core-dev
1952016-05-09T10:06:20 <wumpus> as I'm fairly sure master's travis.yml specifies python3-zmq correctly
1962016-05-09T10:06:24 <paveljanik> so rebasing the branch is the solution
1972016-05-09T10:06:26 <paveljanik> yup
1982016-05-09T10:06:47 *** gevs has quit IRC
1992016-05-09T10:07:50 <wumpus> yes, but asking everyone to rebase their pull request because of completely unrelated issues is messy
2002016-05-09T10:09:04 <phantomcircuit> i think travis is screwing up on 8026
2012016-05-09T10:09:26 <paveljanik> yes, so if travis is using the old config and new test scripts from master, then yes, reverting the mentioned commit can help
2022016-05-09T10:09:44 <phantomcircuit> hmm maybe not
2032016-05-09T10:10:40 <phantomcircuit> oh i see
2042016-05-09T10:10:41 <phantomcircuit> heh
2052016-05-09T10:10:54 <phantomcircuit> fundrawtransaction.py tries to encrypt the wallet...
2062016-05-09T10:13:49 <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
2072016-05-09T10:18:46 <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.
2082016-05-09T10:19:30 <jonasschnelli> Using 1.5GB would probably reduce IBD form a couple of days to a couple of hours
2092016-05-09T10:20:41 *** gill3s has quit IRC
2102016-05-09T10:20:55 <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
2112016-05-09T10:21:38 <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
2122016-05-09T10:23:16 <jonasschnelli> right
2132016-05-09T10:24:02 <wumpus> but a choice when first launching the software would make snse
2142016-05-09T10:24:42 <wumpus> sync as fast as possible, but hogging the computer, or sync slowly and steadily in the background, this could also set -par
2152016-05-09T10:41:45 *** laurentmt has joined #bitcoin-core-dev
2162016-05-09T10:43:27 *** laurentmt has quit IRC
2172016-05-09T11:15:57 *** fengling has quit IRC
2182016-05-09T11:17:18 *** gill3s has joined #bitcoin-core-dev
2192016-05-09T11:22:17 *** BashCo has joined #bitcoin-core-dev
2202016-05-09T11:25:18 *** BashCo_ has quit IRC
2212016-05-09T11:28:00 *** Ginnarr has quit IRC
2222016-05-09T11:34:23 <GitHub123> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e29cfc48fc08...a68f56e727c3
2232016-05-09T11:34:24 <GitHub123> bitcoin/master b02119e Pavel JanÃk: Remove useless argument to AlertNotify....
2242016-05-09T11:34:25 <GitHub123> bitcoin/master a68f56e Wladimir J. van der Laan: Merge #7958: Remove useless argument to AlertNotify....
2252016-05-09T11:34: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
2262016-05-09T11:35:01 *** BashCo has quit IRC
2272016-05-09T11:35:09 *** BashCo_ has joined #bitcoin-core-dev
2282016-05-09T11:36:19 *** jannes has joined #bitcoin-core-dev
2292016-05-09T11:36:41 <jonasschnelli> wumpus: what was the reason you have started with lmdb? Did you had problems compiling leveldb for Odroid?
2302016-05-09T11:36:58 <wumpus> leveldb was horribly slow on my odroid-C2
2312016-05-09T11:36:59 <jonasschnelli> I just successfully compiled (and running IBD) bitcoin-core master for Pine64
2322016-05-09T11:37:37 <wumpus> I noticed high I/O latency, but had nothing to compare to, so I wondered whether another database would do better
2332016-05-09T11:38:01 <wumpus> haven't had any problems with stability of leveldb on aarch64
2342016-05-09T11:38:32 <jonasschnelli> wumpus: But i guess you ran with a high DB cache?
2352016-05-09T11:39:35 <wumpus> yes, reasonably high, though the device has 2GB of memory so some care has to be taken not to invite the OOM killer
2362016-05-09T11:39:41 <jonasschnelli> I guess if i run with -dbcache=1500 it will result in only tiny disk i/o?
2372016-05-09T11:40:05 <wumpus> as long as not the entire utxo set fits in memory you'll have fairly much disk i/o, especially after flushes
2382016-05-09T11:40:56 <jonasschnelli> Right. This is a point.
2392016-05-09T11:41:22 <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.
2402016-05-09T11:41:29 *** raedah has quit IRC
2412016-05-09T11:42:33 <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
2422016-05-09T11:44:27 <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)
2432016-05-09T11:45:34 <jonasschnelli> wumpus: what i/o (disk) do you use? SDCard? USB/SSD?
2442016-05-09T11:46:02 <wumpus> I've tried with external USB2 hdd and with a network block device mounted over 1000gb link
2452016-05-09T11:46:25 <wumpus> sdcard is a pretty bad idea for the database, I've worn at least one USB stick that way :)
2462016-05-09T11:47:00 <jonasschnelli> Right. We discussed that before. 1GB link is probably the fastest i/o (next to the GPIO).
2472016-05-09T11:47:38 <wumpus> there's no SATA on the board unfortuantely or I'd have used that
2482016-05-09T11:47:54 <wumpus> yes the network I/O is fast
2492016-05-09T11:48:12 <wumpus> in throughput at least, latency was still disappointing here
2502016-05-09T11:48:55 <jonasschnelli> Hmm... good point. Latency might be very important for the utxo set
2512016-05-09T11:51:27 <jonasschnelli> Pine64<->USB2.0<->HDD should result in 30MB/s r/w. Not very powerful but should be enough for a full node.
2522016-05-09T11:51:32 <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
2532016-05-09T11:51:37 <jonasschnelli> Disabling bloom filter should be done then.
2542016-05-09T11:52:10 <wumpus> yes the throughput is good enough
2552016-05-09T11:52:19 <wumpus> especially for block storage
2562016-05-09T11:52:53 <jonasschnelli> But I guess also the latency. GBit Eth. has probably higher latencies (regarding utxo set)
2572016-05-09T12:01:47 <GitHub145> [bitcoin] s-matthew-english opened pull request #8031: improvement to readability (master...patch-3) https://github.com/bitcoin/bitcoin/pull/8031
2582016-05-09T12:05:58 *** bysherper has joined #bitcoin-core-dev
2592016-05-09T12:09:04 *** earlest has quit IRC
2602016-05-09T12:12:49 *** laurentmt has joined #bitcoin-core-dev
2612016-05-09T12:13:15 *** laurentmt has quit IRC
2622016-05-09T12:23:22 *** cryptapus_afk is now known as cryptapus
2632016-05-09T12:26:13 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2642016-05-09T12:31:10 *** Ylbam has quit IRC
2652016-05-09T12:49:34 *** MarcoFalke has joined #bitcoin-core-dev
2662016-05-09T12:53:53 <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) ...
2672016-05-09T12:54:11 <MarcoFalke> I am just guessing that it is caused by corrupt cache, though.
2682016-05-09T12:59:06 <wumpus> I've tried clearing the caches for a few pulls, yes, what I have not tried is clearing all the caches
2692016-05-09T12:59:24 <wumpus> (afraid it will hamper all testing)
2702016-05-09T13:00:16 <wumpus> but I can try clearing 7938, sure
2712016-05-09T13:00:37 <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.
2722016-05-09T13:02:34 <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.
2732016-05-09T13:02:59 <MarcoFalke> So the alternative would be to ignore unrelated errors as best as possible
2742016-05-09T13:03:32 <MarcoFalke> if they accumulate to high nubers, though, it might be better to disable the test...
2752016-05-09T13:03:36 <wumpus> but false positives are bad, the missing zmq error prevents all RPC tests from being run
2762016-05-09T13:04:26 <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
2772016-05-09T13:04:39 *** Ylbam has joined #bitcoin-core-dev
2782016-05-09T13:04:40 <MarcoFalke> I am assuming it would fail the other test as well because there is something wrong with the cached python version
2792016-05-09T13:05:03 <wumpus> I don't think there is anything wrong with the cached python version, apart from the missing python3-zmq package
2802016-05-09T13:05:39 <wumpus> I think it's simply a matter of the wrong package being installed
2812016-05-09T13:05:50 <wumpus> e.g. python-zmq is installed instead of python3-zmq
2822016-05-09T13:05:59 <wumpus> so the test fails to find it
2832016-05-09T13:07:10 <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.
2842016-05-09T13:07:23 <paveljanik> s/the/there/
2852016-05-09T13:07:31 <wumpus> that used to be the case
2862016-05-09T13:07:39 <paveljanik> yes
2872016-05-09T13:07:50 <paveljanik> But I respect the change.
2882016-05-09T13:08:02 <wumpus> until #7851, https://github.com/bitcoin/bitcoin/pull/8030 would temporarily bring back that behavior
2892016-05-09T13:09:30 <wumpus> I'm open to other solutions, but 'all old pulls have to be rebased' is not acceptable
2902016-05-09T13:09:43 <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 ...
2912016-05-09T13:10:06 <paveljanik> MarcoFalke, yes, of course. But slows down the work a bit.
2922016-05-09T13:10:19 <paveljanik> wumpus, yes, definitely. It can also help us to understand the problem.
2932016-05-09T13:10:22 <MarcoFalke> and I want travis to fail if pzthon-zmq is missing instead of just returning 'succeed'
2942016-05-09T13:10:24 <wumpus> as this would mean you could no longer submit pulls based on older commits for no good reason
2952016-05-09T13:10:26 <paveljanik> right now, we are all guessing only.
2962016-05-09T13:10:42 <MarcoFalke> 8030 temporarily, ACK from me
2972016-05-09T13:10:55 <wumpus> yes let's just try it
2982016-05-09T13:11:09 <paveljanik> +1
2992016-05-09T13:12:09 <GitHub109> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a68f56e727c3...409a8a1637d4
3002016-05-09T13:12:09 <GitHub109> bitcoin/master 65fee8e Wladimir J. van der Laan: test: Revert fatal-ness of missing python-zmq...
3012016-05-09T13:12:10 <GitHub109> bitcoin/master 409a8a1 Wladimir J. van der Laan: Merge #8030: test: Revert fatal-ness of missing python-zmq...
3022016-05-09T13:12:24 <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
3032016-05-09T13:13:13 <wumpus> re-triggering #8006
3042016-05-09T13:14:16 *** fengling has joined #bitcoin-core-dev
3052016-05-09T13:14:28 <wumpus> if it fails on something else now, it's clear that the problem goes deeper
3062016-05-09T13:15:59 * paveljanik grabs some popcorn ;-)
3072016-05-09T13:18:56 *** fengling has quit IRC
3082016-05-09T13:27:12 *** laurentmt has joined #bitcoin-core-dev
3092016-05-09T13:31:15 *** MarcoFalke has quit IRC
3102016-05-09T13:36:56 *** shesek has joined #bitcoin-core-dev
3112016-05-09T14:04:27 <wumpus> looks like it worked https://github.com/bitcoin/bitcoin/pull/8006
3122016-05-09T14:15:47 *** muftop has joined #bitcoin-core-dev
3132016-05-09T14:20:19 <wumpus> any other pulls that need travis respin now?
3142016-05-09T14:26:22 *** ghtdak has quit IRC
3152016-05-09T14:27:57 *** spudowiar has quit IRC
3162016-05-09T14:28:19 *** ghtdak has joined #bitcoin-core-dev
3172016-05-09T14:31:14 <BlueMatt> gmaxwell: yea, sipa and I spoke about collision-recovery and trying each tx or just requesting...
3182016-05-09T14:31:24 *** Giszmo has joined #bitcoin-core-dev
3192016-05-09T14:31:40 <BlueMatt> gmaxwell: I hadnt done it originally, but if I'm gonna drop it from 64 bits to something smaller it starts to matter
3202016-05-09T14:32:47 *** raedah has joined #bitcoin-core-dev
3212016-05-09T14:33:30 *** laurentmt has quit IRC
3222016-05-09T14:49:43 *** gill3s has quit IRC
3232016-05-09T14:54:57 *** MarcoFalke has joined #bitcoin-core-dev
3242016-05-09T14:59:45 *** spudowiar has joined #bitcoin-core-dev
3252016-05-09T15:00:45 <GitHub186> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/409a8a1637d4...3e90fe653420
3262016-05-09T15:00:46 <GitHub186> bitcoin/master 5ea4508 Jonas Schnelli: Autofind rpc tests --srcdir
3272016-05-09T15:00:47 <GitHub186> bitcoin/master 3e90fe6 MarcoFalke: Merge #8018: Autofind rpc tests --srcdir...
3282016-05-09T15:00:58 <GitHub197> [bitcoin] MarcoFalke closed pull request #8018: Autofind rpc tests --srcdir (master...2016/05/fix_test_srcdir) https://github.com/bitcoin/bitcoin/pull/8018
3292016-05-09T15:02:57 *** bsm1175321 has joined #bitcoin-core-dev
3302016-05-09T15:03:11 *** bsm1175321 is now known as bsm117532
3312016-05-09T15:03:50 *** raedah has quit IRC
3322016-05-09T15:04:27 *** gill3s has joined #bitcoin-core-dev
3332016-05-09T15:05:37 *** gill3s has quit IRC
3342016-05-09T15:06:09 *** gill3s has joined #bitcoin-core-dev
3352016-05-09T15:07:04 <GitHub98> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e90fe653420...4e14afe42fdd
3362016-05-09T15:07:05 <GitHub98> bitcoin/master fabbf6b MarcoFalke: [qa] Refactor test_framework and pull tester...
3372016-05-09T15:07:06 <GitHub98> bitcoin/master 2222dae MarcoFalke: [qa] Update README.md
3382016-05-09T15:07:06 <GitHub98> bitcoin/master fafb33c MarcoFalke: [qa] Stop other nodes, even when one fails to stop
3392016-05-09T15:07:19 <GitHub50> [bitcoin] MarcoFalke closed pull request #7971: [qa] Refactor test_framework and pull tester (master...Mf1604-qaRefactor) https://github.com/bitcoin/bitcoin/pull/7971
3402016-05-09T15:12:41 <jonasschnelli> gmaxwell, sipa: for keypools containing HD keys: do we need two keypools? one for internal (change), one for external usage?
3412016-05-09T15:13:31 <sipa> yes
3422016-05-09T15:13:42 <sipa> but i don't think that's a necessity for a first working version
3432016-05-09T15:14:38 <jonasschnelli> sipa, okay will start using only the external chain.
3442016-05-09T15:15:01 <jonasschnelli> Also,.. i will re-derive the external child key in each GenerateNewKey to keep the diff small and tight.
3452016-05-09T15:17:28 *** fengling has joined #bitcoin-core-dev
3462016-05-09T15:20:17 *** gill3s has quit IRC
3472016-05-09T15:21:51 *** BashCo_ has quit IRC
3482016-05-09T15:21:57 *** fengling has quit IRC
3492016-05-09T15:27:39 *** gill3s has joined #bitcoin-core-dev
3502016-05-09T15:33:42 *** raedah has joined #bitcoin-core-dev
3512016-05-09T15:40:35 *** CubicEarth has joined #bitcoin-core-dev
3522016-05-09T15:42:40 *** earlest has joined #bitcoin-core-dev
3532016-05-09T15:45:34 *** bysherper has quit IRC
3542016-05-09T15:45:52 *** BashCo has joined #bitcoin-core-dev
3552016-05-09T15:48:29 <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?
3562016-05-09T15:48:57 <jonasschnelli> Or do i have to generate a random IV and store if in the same data-record?
3572016-05-09T15:49:19 <jonasschnelli> nm, ... need to do the later
3582016-05-09T15:49:24 <sipa> you can just make the master key itself a wallet key
3592016-05-09T15:49:42 <sipa> and store the corresponding pubkeyhash in the wallet
3602016-05-09T15:49:52 <jonasschnelli> meh..
3612016-05-09T15:49:58 <sipa> so you automatically get the encryption benefits
3622016-05-09T15:50:11 <jonasschnelli> though about that. But do we really want to loose the CExtKey metadata?
3632016-05-09T15:50:26 <sipa> how do you mean?
3642016-05-09T15:50:28 <jonasschnelli> This would really be hard to extend then (if we would use a CKey for the master key)
3652016-05-09T15:50:38 <sipa> why?
3662016-05-09T15:51:24 <jonasschnelli> What if someone wants to later start a wallet with a xpriv at m/44/0/0?
3672016-05-09T15:52:02 <jonasschnelli> And how would we distinct between a normal CKey and a CKey thats used as bip32 masterkey?
3682016-05-09T15:52:08 <jonasschnelli> Just over the metadata?
3692016-05-09T15:52:24 <sipa> just make it a ckey that's not added to the keypool
3702016-05-09T15:52:33 <sipa> so it's never exposed as a receive address
3712016-05-09T15:52:55 <sipa> maybe add a field to its metadata to indicate that it's not a wallet key
3722016-05-09T15:53:42 <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.
3732016-05-09T15:53:51 <sipa> why?
3742016-05-09T15:54:17 <jonasschnelli> hmm... right, we could just store the pubkeyhash somewhere to identify the master key...
3752016-05-09T15:54:42 <jonasschnelli> But all "ckey" objects get passed into LoadCryptedKey
3762016-05-09T15:54:54 <sipa> yes, that's exactly what you want?
3772016-05-09T15:55:06 <jonasschnelli> What if the wallet is unencrypted?!
3782016-05-09T15:55:18 <sipa> then it's stored as an unencrypted key
3792016-05-09T15:55:23 <jonasschnelli> heh...
3802016-05-09T15:55:23 <sipa> also exactly what you want
3812016-05-09T15:55:50 <jonasschnelli> Where do we store the chaincode? Unencrypted in metadata?
3822016-05-09T15:56:01 <jonasschnelli> Ah.. wait.
3832016-05-09T15:56:06 <jonasschnelli> We always use setMaster()
3842016-05-09T15:56:09 *** raedah has quit IRC
3852016-05-09T15:56:09 <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
3862016-05-09T15:56:35 <sipa> you could avoid 3, and derive it at startup
3872016-05-09T15:56:44 <jonasschnelli> Okay. I'll see. This is simpler. Thanks for the sparring.
3882016-05-09T15:56:53 <jonasschnelli> 3 is necessary to refill the keypool i guess
3892016-05-09T15:57:11 <sipa> right, but when generating a new key, you can just check whether you already have the newly derived key
3902016-05-09T15:57:25 <sipa> and in that case, increment the (in-memory only) counter and try again
3912016-05-09T15:57:44 <jonasschnelli> okay... this could get slow if your keypool gets bigger
3922016-05-09T15:57:52 <sipa> perhaps you can even use exponential backoff, so it's only log(n) time in the number of keys
3932016-05-09T15:58:06 <jonasschnelli> I don't use flexible keypath for now. So your 2) is not necessary for now.
3942016-05-09T15:58:16 <jonasschnelli> Is will just use m/1/<key>
3952016-05-09T15:58:24 <jonasschnelli> To avoid another 50L of code
3962016-05-09T15:58:28 <sipa> ok
3972016-05-09T16:07:45 *** BashCo_ has joined #bitcoin-core-dev
3982016-05-09T16:10:06 *** raedah has joined #bitcoin-core-dev
3992016-05-09T16:10:12 *** BashCo has quit IRC
4002016-05-09T16:13:14 *** spudowiar has quit IRC
4012016-05-09T16:25:35 *** CubicEarth has quit IRC
4022016-05-09T16:40:58 *** kadoban has joined #bitcoin-core-dev
4032016-05-09T16:41:11 *** Ylbam has quit IRC
4042016-05-09T16:55:39 *** gill3s has quit IRC
4052016-05-09T17:00:40 *** muftop has quit IRC
4062016-05-09T17:01:01 *** raedah has quit IRC
4072016-05-09T17:01:36 *** muftop has joined #bitcoin-core-dev
4082016-05-09T17:02:30 *** raedah has joined #bitcoin-core-dev
4092016-05-09T17:06:09 *** raedah has quit IRC
4102016-05-09T17:07:24 *** raedah has joined #bitcoin-core-dev
4112016-05-09T17:19:53 *** fengling has joined #bitcoin-core-dev
4122016-05-09T17:24:36 *** fengling has quit IRC
4132016-05-09T17:26:49 *** raedah has joined #bitcoin-core-dev
4142016-05-09T17:27:02 *** Giszmo has quit IRC
4152016-05-09T17:29:26 *** G1lius has quit IRC
4162016-05-09T17:29:49 *** cheese_ has quit IRC
4172016-05-09T17:32:51 *** raedah has left #bitcoin-core-dev
4182016-05-09T17:38:23 *** Cheeseo has joined #bitcoin-core-dev
4192016-05-09T17:38:23 *** Cheeseo has joined #bitcoin-core-dev
4202016-05-09T17:44:11 *** BashCo has joined #bitcoin-core-dev
4212016-05-09T17:45:51 *** BashCo_ has quit IRC
4222016-05-09T17:46:32 *** Ylbam has joined #bitcoin-core-dev
4232016-05-09T17:46:47 *** Chris_Stewart_5 has quit IRC
4242016-05-09T17:49:47 *** waxmiguel_ has joined #bitcoin-core-dev
4252016-05-09T18:18:49 *** bysherper has joined #bitcoin-core-dev
4262016-05-09T18:22:04 *** earlest has quit IRC
4272016-05-09T18:27:13 *** raedah1 has joined #bitcoin-core-dev
4282016-05-09T18:28:50 *** gill3s has joined #bitcoin-core-dev
4292016-05-09T18:32:31 *** MarcoFalke has quit IRC
4302016-05-09T18:35:41 *** kadoban has quit IRC
4312016-05-09T18:37:39 *** molz has joined #bitcoin-core-dev
4322016-05-09T18:39:21 *** moli has quit IRC
4332016-05-09T18:39:40 *** moli has joined #bitcoin-core-dev
4342016-05-09T18:42:58 *** molz has quit IRC
4352016-05-09T18:44:22 *** earlest has joined #bitcoin-core-dev
4362016-05-09T18:47:34 *** bysherper has quit IRC
4372016-05-09T18:55:24 *** waxmiguel_ has quit IRC
4382016-05-09T19:00:44 *** molz has joined #bitcoin-core-dev
4392016-05-09T19:03:37 *** moli has quit IRC
4402016-05-09T19:05:23 *** molly has joined #bitcoin-core-dev
4412016-05-09T19:07:39 *** molz has quit IRC
4422016-05-09T19:14:34 *** molly has quit IRC
4432016-05-09T19:24:48 *** TomMc has joined #bitcoin-core-dev
4442016-05-09T19:46:49 *** fengling has joined #bitcoin-core-dev
4452016-05-09T19:51:37 *** fengling has quit IRC
4462016-05-09T19:58:54 <luke-jr> CodeShark: I think this is broken: if (pindex->nVersion > VERSIONBITS_LAST_OLD_BLOCK_VERSION && (pindex->nVersion & ~nExpectedVersion) != 0)
4472016-05-09T20:21:51 <gmaxwell> BlueMatt: sipa suggests the sender choose the size, and send a byte with the number of bytes, constrained to 4-8.
4482016-05-09T20:22:52 <gmaxwell> BlueMatt: sipa can probably suggest a decision table based on block/mempool size.
4492016-05-09T20:34:28 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4502016-05-09T20:43:47 *** Chris_Stewart_5 has quit IRC
4512016-05-09T20:47:10 *** jannes has quit IRC
4522016-05-09T20:52:14 *** BitcoinErrorLog has joined #bitcoin-core-dev
4532016-05-09T20:52:58 <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
4542016-05-09T20:53:08 <BlueMatt> though I'm not sure how useful that would be really well
4552016-05-09T20:56:20 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4562016-05-09T20:58:33 <sipa> BlueMatt: the formula is just log2(mempool_txn * unmatched_txn / failure_rate)
4572016-05-09T20:58:54 <sipa> if that's over 40, use 6 bytes, otherwise 5
4582016-05-09T21:02:21 <gmaxwell> BlueMatt: did you see my comment about adding the orphan pool to your search.
4592016-05-09T21:04:53 <BlueMatt> gmaxwell: I did not
4602016-05-09T21:05:06 <BlueMatt> valid point, but "meh"
4612016-05-09T21:07:02 <gmaxwell> BlueMatt: I instrumented my copy and a lot of the missed txn are in the orphan pool.
4622016-05-09T21:07:50 <BlueMatt> WTF :(
4632016-05-09T21:09:24 *** murch has quit IRC
4642016-05-09T21:11:07 <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.
4652016-05-09T21:11:23 <gmaxwell> it'll be much better with 0.13 widely deployed, but it's cheap to check the orphan pool.
4662016-05-09T21:20:54 <BlueMatt> yea, understood
4672016-05-09T21:31:26 <gmaxwell> (we also need to fix some of the orphan pool issues that the trickle improvements exposed)
4682016-05-09T21:32:34 <BlueMatt> yea, that
4692016-05-09T21:33:04 *** moli has joined #bitcoin-core-dev
4702016-05-09T21:49:49 *** fengling has joined #bitcoin-core-dev
4712016-05-09T21:54:36 *** fengling has quit IRC
4722016-05-09T21:56:38 *** erasmospunk has joined #bitcoin-core-dev
4732016-05-09T22:12:49 *** TomMc has quit IRC
4742016-05-09T22:20:33 *** kadoban has joined #bitcoin-core-dev
4752016-05-09T22:23:33 *** cryptapus_ has joined #bitcoin-core-dev
4762016-05-09T22:28:04 *** cryptapus_ has quit IRC
4772016-05-09T22:29:41 *** TomMc has joined #bitcoin-core-dev
4782016-05-09T22:50:52 *** Guyver2 has quit IRC
4792016-05-09T23:14:31 *** AaronvanW has quit IRC
4802016-05-09T23:38:24 *** belcher has joined #bitcoin-core-dev
4812016-05-09T23:38:55 *** cryptapus is now known as cryptapus_afk
4822016-05-09T23:40:48 *** tsunami11 has joined #bitcoin-core-dev
4832016-05-09T23:45:42 *** fengling has joined #bitcoin-core-dev
4842016-05-09T23:57:02 *** alpalp has joined #bitcoin-core-dev
4852016-05-09T23:57:02 *** alpalp has joined #bitcoin-core-dev