1 2016-05-09 01:12:14 0|Chris_Stewart_5|Is there an easy way to see the serialization for a transaction inside of CTransactionSignatureSerializer (not just the hash)?
2 2016-05-09 01:17:09 0|sipa|replace it with a CDataStream :)
3 2016-05-09 01:20:46 0|phantomcircuit|is there any reason not to encrypt the wallet by default with a null master key?
4 2016-05-09 01:20:47 0|GitHub22|[13bitcoin] 15pstratem opened pull request #8025: Increase DEFAULT_KEYPOOL_SIZE to 10000. (06master...062016-05-08-wallet-defaults) 02 https://github.com/bitcoin/bitcoin/pull/8025
5 2016-05-09 01:23:35 0|Chris_Stewart_5|thank you so much sipa. I spent much more time than I would like to admit trying to figure that out :-)
6 2016-05-09 01:29:20 0|phantomcircuit|BlueMatt, ^
7 2016-05-09 01:43:34 0|sipa|phantomcircuit: backward compatibility at the time
8 2016-05-09 01:43:42 0|sipa|not really an argument anymore :)
9 2016-05-09 01:43:47 0|phantomcircuit|k
10 2016-05-09 03:46:39 0|GitHub177|[13bitcoin] 15pstratem opened pull request #8026: [WIP] Wallet: Cache CWalletDB pointer in CWallet to improve performance (06master...062016-05-08-wallet-speed) 02 https://github.com/bitcoin/bitcoin/pull/8026
11 2016-05-09 06:47:41 0|phantomcircuit|sipa, btw i just had a ccache failure working on #8026
12 2016-05-09 06:52:47 0|paveljanik|ccache failure?
13 2016-05-09 06:52:56 0|GitHub143|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/fbd84788e676...f17032f70328
14 2016-05-09 06:52:57 0|GitHub143|13bitcoin/06master 141953c40 15Pieter Wuille: More efficient bitsliced rolling Bloom filter...
15 2016-05-09 06:52:57 0|GitHub143|13bitcoin/06master 14aa62b68 15Pieter Wuille: Benchmark rolling bloom filter
16 2016-05-09 06:52:58 0|GitHub143|13bitcoin/06master 14f17032f 15Wladimir J. van der Laan: Merge #7934: Improve rolling bloom filter performance and benchmark...
17 2016-05-09 06:53:06 0|GitHub9|[13bitcoin] 15laanwj closed pull request #7934: Improve rolling bloom filter performance and benchmark (06master...06benchrollingbloom) 02 https://github.com/bitcoin/bitcoin/pull/7934
18 2016-05-09 06:57:02 0|phantomcircuit|paveljanik, wallet.cpp was being compiled incorrectly
19 2016-05-09 06:57:16 0|phantomcircuit|(or rather was compiling when it shouldn't have been)
20 2016-05-09 06:57:19 0|phantomcircuit|ccache -C
21 2016-05-09 06:57:25 0|phantomcircuit|and the issue disappeared
22 2016-05-09 06:57:44 0|paveljanik|strange
23 2016-05-09 06:57:54 0|paveljanik|never seen such issue with ccache...
24 2016-05-09 06:58:18 0|phantomcircuit|haven't seen that kind of problem with it in... well yeah ever
25 2016-05-09 07:21:17 0|GitHub6|[13bitcoin] 15pstratem opened pull request #8028: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk (06master...062016-05-09-cwalletdb-writetx) 02 https://github.com/bitcoin/bitcoin/pull/8028
26 2016-05-09 08:06:53 0|phantomcircuit|i like how the trivial patch to change keypool size has tons of activity
27 2016-05-09 08:06:54 0|phantomcircuit|:P
28 2016-05-09 08:11:32 0|paveljanik|phantomcircuit, you are not the first though. MAX_BLOCK_SIZE...
29 2016-05-09 08:14:10 0|jonasschnelli|:)
30 2016-05-09 08:15:31 0|phantomcircuit|ha
31 2016-05-09 08:15:40 0|phantomcircuit|now i just need someone to review 8028
32 2016-05-09 08:15:44 0|phantomcircuit|it's almost as trivial
33 2016-05-09 08:20:26 0|jonasschnelli|I never liked the wtx.WriteToDisk()
34 2016-05-09 08:22:40 0|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.
35 2016-05-09 08:30:52 0|MarcoFalke|jonasschnelli, 8018 looks good. Mind to address the nit?
36 2016-05-09 08:31:21 0|jonasschnelli|MarcoFalke: yes. Will do in a couple of hours. Need to finish the open work before I can checkout the branch. :)
37 2016-05-09 08:31:55 0|MarcoFalke|sure, take your time.
38 2016-05-09 08:35:21 0|wumpus|git-worktree is great, it requires a pretty new git though, unfortunately
39 2016-05-09 08:35:33 0|jonasschnelli|hmm... I probably should check this.
40 2016-05-09 08:35:45 0|jonasschnelli|I have also multiple working copies to switch between work
41 2016-05-09 08:35:54 0|wumpus|yes I simply have mulitple clones now
42 2016-05-09 08:35:59 0|jonasschnelli|But loosing focus means loosing productivity. :)
43 2016-05-09 08:36:23 0|wumpus|will switch to git-worktree when I upgrade more widely to ubuntu 16.04
44 2016-05-09 08:36:33 0|sipa|jonasschnelli: you need to upgrade your brain to a multicore one
45 2016-05-09 08:36:45 0|jonasschnelli|haha... I already run on 8 cores!
46 2016-05-09 08:36:53 0|sipa|wumpus: no problems with ubuntu 16.04 here
47 2016-05-09 08:37:16 0|jonasschnelli|core-dev organizing, Pine64/Odroid installation, hardware wallet work, libbtc and managing a familiy... :)
48 2016-05-09 08:37:19 0|wumpus|sipa: no problems here either, but there is no supported upgrade path from 14.04 to 16.04 yet
49 2016-05-09 08:37:32 0|sipa|upgrading worked fine here
50 2016-05-09 08:37:55 0|wumpus|so all my 16.04 installations are either upgraded from 15.10 or new ones
51 2016-05-09 08:38:01 0|GitHub105|[13bitcoin] 15fanquake opened pull request #8029: [Doc] Simplify OS X build notes (06master...06osx-build-notes) 02 https://github.com/bitcoin/bitcoin/pull/8029
52 2016-05-09 08:38:13 0|sipa|i used do-release-upgrade -d
53 2016-05-09 08:38:20 0|gmaxwell|Hurray for the multiple clone workflow!
54 2016-05-09 08:38:23 0|gmaxwell|join us
55 2016-05-09 08:39:30 0|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 :)
56 2016-05-09 08:41:15 0|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 :)
57 2016-05-09 08:41:28 0|sipa|and if it fails, it's not like reinstalling is a disaster
58 2016-05-09 08:42:34 0|wumpus|heh :)
59 2016-05-09 08:43:19 0|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
60 2016-05-09 08:59:11 0|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.
61 2016-05-09 09:00:02 0|gmaxwell|wumpus: there have been a couple of those incidents over the years.
62 2016-05-09 09:04:19 0|wumpus|ouch
63 2016-05-09 09:06:08 0|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...
64 2016-05-09 09:06:43 0|gmaxwell|better not delete "dance / greatesthits.mp3"
65 2016-05-09 09:07:33 0|kinlo|sigh, what's wrong with a call to unlink() ? why do ppl call the shell so much
66 2016-05-09 09:08:11 0|wumpus|yes, seems absurd to use the shell for that. Usage of system() is usually a code stink
67 2016-05-09 09:38:08 0|jonasschnelli|can the cache-sizes be changed during runtime?
68 2016-05-09 09:38:13 0|jonasschnelli|Things like nCoinCacheUsage
69 2016-05-09 09:49:29 0|wumpus|no
70 2016-05-09 09:49:50 0|wumpus|(I don't think there's any deep reason for that not being possible though)
71 2016-05-09 09:50:18 0|wumpus|at least the size of the coin cache could be trivially changed, it's just a threshold
72 2016-05-09 09:50:35 0|gmaxwell|some kinds of datastructures are fairly hard to resize at runtime. ... bloom filters being an example.
73 2016-05-09 09:50:40 0|wumpus|the leveldb caches on the other hand probably require re-opening the dtabase
74 2016-05-09 09:51:17 0|wumpus|true, but I don't think we have any user-sizable bloom filters
75 2016-05-09 09:54:24 0|wumpus|travis is stil suffering from unrelated zmq issues: https://github.com/bitcoin/bitcoin/pull/8006
76 2016-05-09 09:55:46 0|wumpus|I think it makes sense to temporarily revert fa05e22e919b7e2e816606f0c0d3dea1bd325bfd so that missing python-zmq package is not fatal
77 2016-05-09 09:59:21 0|paveljanik|or you can temporarily add python-zmq to travis
78 2016-05-09 09:59:34 0|paveljanik|but anyway: +1
79 2016-05-09 09:59:38 0|GitHub128|13bitcoin/06master 14c8b9248 1521E14: Remove obsolete reference to CValidationState from UpdateCoins.
80 2016-05-09 09:59:38 0|GitHub128|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/f17032f70328...e29cfc48fc08
81 2016-05-09 09:59:39 0|GitHub128|13bitcoin/06master 14e29cfc4 15Wladimir J. van der Laan: Merge #7976: Remove obsolete reference to CValidationState from UpdateCoins....
82 2016-05-09 09:59:48 0|GitHub10|[13bitcoin] 15laanwj closed pull request #7976: Remove obsolete reference to CValidationState from UpdateCoins. (06master...06cleancoinsupdate) 02 https://github.com/bitcoin/bitcoin/pull/7976
83 2016-05-09 10:00:02 0|wumpus|paveljanik: I'm not convinced that that solves the issue
84 2016-05-09 10:00:26 0|wumpus|last time I checked the travis configuration it *should* be okay, if not, that'd be the obvious solution
85 2016-05-09 10:01:47 0|paveljanik|you have checked that the tests were done using python2 and python-zmq (ie. python-zmq for Python2) was installed?
86 2016-05-09 10:02:07 0|wumpus|the tests cannot be done using python 2 anymore
87 2016-05-09 10:02:35 0|paveljanik|even if the branch was created at the time when python2 was used?
88 2016-05-09 10:02:59 0|wumpus|as I understand it, the travis testing merges your changes into master then runs the tests
89 2016-05-09 10:03:05 0|wumpus|so the python 3 test framework will get applied to it
90 2016-05-09 10:05:02 0|paveljanik|wumpus, yes.
91 2016-05-09 10:05:11 0|paveljanik|in the case, you linked to, python-zmq was installed
92 2016-05-09 10:05:20 0|paveljanik|but python3-zmq was needed
93 2016-05-09 10:05:29 0|paveljanik|ie. travis used wrong config IMO
94 2016-05-09 10:05:40 0|paveljanik|the old one from pre-python3
95 2016-05-09 10:05:58 0|wumpus|ah! so it uses the travis configuration from the branch it is testing, not master with the changes merged in
96 2016-05-09 10:06:20 0|wumpus|as I'm fairly sure master's travis.yml specifies python3-zmq correctly
97 2016-05-09 10:06:25 0|paveljanik|so rebasing the branch is the solution
98 2016-05-09 10:06:27 0|paveljanik|yup
99 2016-05-09 10:07:51 0|wumpus|yes, but asking everyone to rebase their pull request because of completely unrelated issues is messy
100 2016-05-09 10:09:05 0|phantomcircuit|i think travis is screwing up on 8026
101 2016-05-09 10:09:26 0|paveljanik|yes, so if travis is using the old config and new test scripts from master, then yes, reverting the mentioned commit can help
102 2016-05-09 10:09:45 0|phantomcircuit|hmm maybe not
103 2016-05-09 10:10:40 0|phantomcircuit|oh i see
104 2016-05-09 10:10:42 0|phantomcircuit|heh
105 2016-05-09 10:10:54 0|phantomcircuit|fundrawtransaction.py tries to encrypt the wallet...
106 2016-05-09 10:13:49 0|GitHub96|[13bitcoin] 15laanwj opened pull request #8030: test: Revert fatal-ness of missing python-zmq (06master...062016_05_revert_zmq_req_tests) 02 https://github.com/bitcoin/bitcoin/pull/8030
107 2016-05-09 10:18:47 0|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.
108 2016-05-09 10:19:30 0|jonasschnelli|Using 1.5GB would probably reduce IBD form a couple of days to a couple of hours
109 2016-05-09 10:20:56 0|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
110 2016-05-09 10:21:38 0|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
111 2016-05-09 10:23:17 0|jonasschnelli|right
112 2016-05-09 10:24:02 0|wumpus|but a choice when first launching the software would make snse
113 2016-05-09 10:24:42 0|wumpus|sync as fast as possible, but hogging the computer, or sync slowly and steadily in the background, this could also set -par
114 2016-05-09 11:34:24 0|GitHub123|13bitcoin/06master 14b02119e 15Pavel JanÃÂk: Remove useless argument to AlertNotify....
115 2016-05-09 11:34:24 0|GitHub123|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/e29cfc48fc08...a68f56e727c3
116 2016-05-09 11:34:25 0|GitHub123|13bitcoin/06master 14a68f56e 15Wladimir J. van der Laan: Merge #7958: Remove useless argument to AlertNotify....
117 2016-05-09 11:34:34 0|GitHub31|[13bitcoin] 15laanwj closed pull request #7958: Remove useless argument to AlertNotify. (06master...0620160427_AlertNotify_remove_arg) 02 https://github.com/bitcoin/bitcoin/pull/7958
118 2016-05-09 11:36:41 0|jonasschnelli|wumpus: what was the reason you have started with lmdb? Did you had problems compiling leveldb for Odroid?
119 2016-05-09 11:36:58 0|wumpus|leveldb was horribly slow on my odroid-C2
120 2016-05-09 11:36:59 0|jonasschnelli|I just successfully compiled (and running IBD) bitcoin-core master for Pine64
121 2016-05-09 11:37:37 0|wumpus|I noticed high I/O latency, but had nothing to compare to, so I wondered whether another database would do better
122 2016-05-09 11:38:01 0|wumpus|haven't had any problems with stability of leveldb on aarch64
123 2016-05-09 11:38:32 0|jonasschnelli|wumpus: But i guess you ran with a high DB cache?
124 2016-05-09 11:39:35 0|wumpus|yes, reasonably high, though the device has 2GB of memory so some care has to be taken not to invite the OOM killer
125 2016-05-09 11:39:41 0|jonasschnelli|I guess if i run with -dbcache=1500 it will result in only tiny disk i/o?
126 2016-05-09 11:40:05 0|wumpus|as long as not the entire utxo set fits in memory you'll have fairly much disk i/o, especially after flushes
127 2016-05-09 11:40:56 0|jonasschnelli|Right. This is a point.
128 2016-05-09 11:41:23 0|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.
129 2016-05-09 11:42:34 0|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
130 2016-05-09 11:44:27 0|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)
131 2016-05-09 11:45:34 0|jonasschnelli|wumpus: what i/o (disk) do you use? SDCard? USB/SSD?
132 2016-05-09 11:46:03 0|wumpus|I've tried with external USB2 hdd and with a network block device mounted over 1000gb link
133 2016-05-09 11:46:26 0|wumpus|sdcard is a pretty bad idea for the database, I've worn at least one USB stick that way :)
134 2016-05-09 11:47:00 0|jonasschnelli|Right. We discussed that before. 1GB link is probably the fastest i/o (next to the GPIO).
135 2016-05-09 11:47:38 0|wumpus|there's no SATA on the board unfortuantely or I'd have used that
136 2016-05-09 11:47:55 0|wumpus|yes the network I/O is fast
137 2016-05-09 11:48:12 0|wumpus|in throughput at least, latency was still disappointing here
138 2016-05-09 11:48:55 0|jonasschnelli|Hmm... good point. Latency might be very important for the utxo set
139 2016-05-09 11:51:27 0|jonasschnelli|Pine64<->USB2.0<->HDD should result in 30MB/s r/w. Not very powerful but should be enough for a full node.
140 2016-05-09 11:51:32 0|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
141 2016-05-09 11:51:38 0|jonasschnelli|Disabling bloom filter should be done then.
142 2016-05-09 11:52:10 0|wumpus|yes the throughput is good enough
143 2016-05-09 11:52:19 0|wumpus|especially for block storage
144 2016-05-09 11:52:54 0|jonasschnelli|But I guess also the latency. GBit Eth. has probably higher latencies (regarding utxo set)
145 2016-05-09 12:01:47 0|GitHub145|[13bitcoin] 15s-matthew-english opened pull request #8031: improvement to readability (06master...06patch-3) 02 https://github.com/bitcoin/bitcoin/pull/8031
146 2016-05-09 12:53:53 0|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) ...
147 2016-05-09 12:54:11 0|MarcoFalke|I am just guessing that it is caused by corrupt cache, though.
148 2016-05-09 12:59:06 0|wumpus|I've tried clearing the caches for a few pulls, yes, what I have not tried is clearing all the caches
149 2016-05-09 12:59:24 0|wumpus|(afraid it will hamper all testing)
150 2016-05-09 13:00:17 0|wumpus|but I can try clearing 7938, sure
151 2016-05-09 13:00:37 0|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.
152 2016-05-09 13:02:35 0|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.
153 2016-05-09 13:03:00 0|MarcoFalke|So the alternative would be to ignore unrelated errors as best as possible
154 2016-05-09 13:03:32 0|MarcoFalke|if they accumulate to high nubers, though, it might be better to disable the test...
155 2016-05-09 13:03:36 0|wumpus|but false positives are bad, the missing zmq error prevents all RPC tests from being run
156 2016-05-09 13:04:26 0|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
157 2016-05-09 13:04:40 0|MarcoFalke|I am assuming it would fail the other test as well because there is something wrong with the cached python version
158 2016-05-09 13:05:03 0|wumpus|I don't think there is anything wrong with the cached python version, apart from the missing python3-zmq package
159 2016-05-09 13:05:39 0|wumpus|I think it's simply a matter of the wrong package being installed
160 2016-05-09 13:05:50 0|wumpus|e.g. python-zmq is installed instead of python3-zmq
161 2016-05-09 13:05:59 0|wumpus|so the test fails to find it
162 2016-05-09 13:07:10 0|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.
163 2016-05-09 13:07:23 0|paveljanik|s/the/there/
164 2016-05-09 13:07:31 0|wumpus|that used to be the case
165 2016-05-09 13:07:39 0|paveljanik|yes
166 2016-05-09 13:07:50 0|paveljanik|But I respect the change.
167 2016-05-09 13:08:02 0|wumpus|until #7851, https://github.com/bitcoin/bitcoin/pull/8030 would temporarily bring back that behavior
168 2016-05-09 13:09:30 0|wumpus|I'm open to other solutions, but 'all old pulls have to be rebased' is not acceptable
169 2016-05-09 13:09:43 0|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 ...
170 2016-05-09 13:10:06 0|paveljanik|MarcoFalke, yes, of course. But slows down the work a bit.
171 2016-05-09 13:10:19 0|paveljanik|wumpus, yes, definitely. It can also help us to understand the problem.
172 2016-05-09 13:10:23 0|MarcoFalke|and I want travis to fail if pzthon-zmq is missing instead of just returning 'succeed'
173 2016-05-09 13:10:24 0|wumpus|as this would mean you could no longer submit pulls based on older commits for no good reason
174 2016-05-09 13:10:27 0|paveljanik|right now, we are all guessing only.
175 2016-05-09 13:10:43 0|MarcoFalke|8030 temporarily, ACK from me
176 2016-05-09 13:10:56 0|wumpus|yes let's just try it
177 2016-05-09 13:11:10 0|paveljanik|+1
178 2016-05-09 13:12:09 0|GitHub109|13bitcoin/06master 1465fee8e 15Wladimir J. van der Laan: test: Revert fatal-ness of missing python-zmq...
179 2016-05-09 13:12:09 0|GitHub109|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/a68f56e727c3...409a8a1637d4
180 2016-05-09 13:12:10 0|GitHub109|13bitcoin/06master 14409a8a1 15Wladimir J. van der Laan: Merge #8030: test: Revert fatal-ness of missing python-zmq...
181 2016-05-09 13:12:24 0|GitHub21|[13bitcoin] 15laanwj closed pull request #8030: test: Revert fatal-ness of missing python-zmq (06master...062016_05_revert_zmq_req_tests) 02 https://github.com/bitcoin/bitcoin/pull/8030
182 2016-05-09 13:13:13 0|wumpus|re-triggering #8006
183 2016-05-09 13:14:28 0|wumpus|if it fails on something else now, it's clear that the problem goes deeper
184 2016-05-09 14:04:28 0|wumpus|looks like it worked https://github.com/bitcoin/bitcoin/pull/8006
185 2016-05-09 14:20:19 0|wumpus|any other pulls that need travis respin now?
186 2016-05-09 14:31:14 0|BlueMatt|gmaxwell: yea, sipa and I spoke about collision-recovery and trying each tx or just requesting...
187 2016-05-09 14:31:40 0|BlueMatt|gmaxwell: I hadnt done it originally, but if I'm gonna drop it from 64 bits to something smaller it starts to matter
188 2016-05-09 15:00:46 0|GitHub186|13bitcoin/06master 145ea4508 15Jonas Schnelli: Autofind rpc tests --srcdir
189 2016-05-09 15:00:46 0|GitHub186|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/409a8a1637d4...3e90fe653420
190 2016-05-09 15:00:47 0|GitHub186|13bitcoin/06master 143e90fe6 15MarcoFalke: Merge #8018: Autofind rpc tests --srcdir...
191 2016-05-09 15:00:58 0|GitHub197|[13bitcoin] 15MarcoFalke closed pull request #8018: Autofind rpc tests --srcdir (06master...062016/05/fix_test_srcdir) 02 https://github.com/bitcoin/bitcoin/pull/8018
192 2016-05-09 15:07:05 0|GitHub98|[13bitcoin] 15MarcoFalke pushed 5 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/3e90fe653420...4e14afe42fdd
193 2016-05-09 15:07:06 0|GitHub98|13bitcoin/06master 142222dae 15MarcoFalke: [qa] Update README.md
194 2016-05-09 15:07:06 0|GitHub98|13bitcoin/06master 14fabbf6b 15MarcoFalke: [qa] Refactor test_framework and pull tester...
195 2016-05-09 15:07:07 0|GitHub98|13bitcoin/06master 14fafb33c 15MarcoFalke: [qa] Stop other nodes, even when one fails to stop
196 2016-05-09 15:07:19 0|GitHub50|[13bitcoin] 15MarcoFalke closed pull request #7971: [qa] Refactor test_framework and pull tester (06master...06Mf1604-qaRefactor) 02 https://github.com/bitcoin/bitcoin/pull/7971
197 2016-05-09 15:12:42 0|jonasschnelli|gmaxwell, sipa: for keypools containing HD keys: do we need two keypools? one for internal (change), one for external usage?
198 2016-05-09 15:13:31 0|sipa|yes
199 2016-05-09 15:13:42 0|sipa|but i don't think that's a necessity for a first working version
200 2016-05-09 15:14:39 0|jonasschnelli|sipa, okay will start using only the external chain.
201 2016-05-09 15:15:01 0|jonasschnelli|Also,.. i will re-derive the external child key in each GenerateNewKey to keep the diff small and tight.
202 2016-05-09 15:48:29 0|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?
203 2016-05-09 15:48:58 0|jonasschnelli|Or do i have to generate a random IV and store if in the same data-record?
204 2016-05-09 15:49:19 0|jonasschnelli|nm, ... need to do the later
205 2016-05-09 15:49:25 0|sipa|you can just make the master key itself a wallet key
206 2016-05-09 15:49:42 0|sipa|and store the corresponding pubkeyhash in the wallet
207 2016-05-09 15:49:52 0|jonasschnelli|meh..
208 2016-05-09 15:49:58 0|sipa|so you automatically get the encryption benefits
209 2016-05-09 15:50:12 0|jonasschnelli|though about that. But do we really want to loose the CExtKey metadata?
210 2016-05-09 15:50:26 0|sipa|how do you mean?
211 2016-05-09 15:50:29 0|jonasschnelli|This would really be hard to extend then (if we would use a CKey for the master key)
212 2016-05-09 15:50:39 0|sipa|why?
213 2016-05-09 15:51:24 0|jonasschnelli|What if someone wants to later start a wallet with a xpriv at m/44/0/0?
214 2016-05-09 15:52:03 0|jonasschnelli|And how would we distinct between a normal CKey and a CKey thats used as bip32 masterkey?
215 2016-05-09 15:52:08 0|jonasschnelli|Just over the metadata?
216 2016-05-09 15:52:25 0|sipa|just make it a ckey that's not added to the keypool
217 2016-05-09 15:52:33 0|sipa|so it's never exposed as a receive address
218 2016-05-09 15:52:55 0|sipa|maybe add a field to its metadata to indicate that it's not a wallet key
219 2016-05-09 15:53:42 0|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.
220 2016-05-09 15:53:51 0|sipa|why?
221 2016-05-09 15:54:17 0|jonasschnelli|hmm... right, we could just store the pubkeyhash somewhere to identify the master key...
222 2016-05-09 15:54:42 0|jonasschnelli|But all "ckey" objects get passed into LoadCryptedKey
223 2016-05-09 15:54:54 0|sipa|yes, that's exactly what you want?
224 2016-05-09 15:55:07 0|jonasschnelli|What if the wallet is unencrypted?!
225 2016-05-09 15:55:19 0|sipa|then it's stored as an unencrypted key
226 2016-05-09 15:55:23 0|jonasschnelli|heh...
227 2016-05-09 15:55:23 0|sipa|also exactly what you want
228 2016-05-09 15:55:50 0|jonasschnelli|Where do we store the chaincode? Unencrypted in metadata?
229 2016-05-09 15:56:01 0|jonasschnelli|Ah.. wait.
230 2016-05-09 15:56:07 0|jonasschnelli|We always use setMaster()
231 2016-05-09 15:56:09 0|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
232 2016-05-09 15:56:35 0|sipa|you could avoid 3, and derive it at startup
233 2016-05-09 15:56:44 0|jonasschnelli|Okay. I'll see. This is simpler. Thanks for the sparring.
234 2016-05-09 15:56:53 0|jonasschnelli|3 is necessary to refill the keypool i guess
235 2016-05-09 15:57:11 0|sipa|right, but when generating a new key, you can just check whether you already have the newly derived key
236 2016-05-09 15:57:25 0|sipa|and in that case, increment the (in-memory only) counter and try again
237 2016-05-09 15:57:44 0|jonasschnelli|okay... this could get slow if your keypool gets bigger
238 2016-05-09 15:57:52 0|sipa|perhaps you can even use exponential backoff, so it's only log(n) time in the number of keys
239 2016-05-09 15:58:06 0|jonasschnelli|I don't use flexible keypath for now. So your 2) is not necessary for now.
240 2016-05-09 15:58:16 0|jonasschnelli|Is will just use m/1/<key>
241 2016-05-09 15:58:24 0|jonasschnelli|To avoid another 50L of code
242 2016-05-09 15:58:29 0|sipa|ok
243 2016-05-09 19:58:54 0|luke-jr|CodeShark: I think this is broken: if (pindex->nVersion > VERSIONBITS_LAST_OLD_BLOCK_VERSION && (pindex->nVersion & ~nExpectedVersion) != 0)
244 2016-05-09 20:21:51 0|gmaxwell|BlueMatt: sipa suggests the sender choose the size, and send a byte with the number of bytes, constrained to 4-8.
245 2016-05-09 20:22:52 0|gmaxwell|BlueMatt: sipa can probably suggest a decision table based on block/mempool size.
246 2016-05-09 20:52:58 0|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
247 2016-05-09 20:53:08 0|BlueMatt|though I'm not sure how useful that would be really well
248 2016-05-09 20:58:33 0|sipa|BlueMatt: the formula is just log2(mempool_txn * unmatched_txn / failure_rate)
249 2016-05-09 20:58:54 0|sipa|if that's over 40, use 6 bytes, otherwise 5
250 2016-05-09 21:02:22 0|gmaxwell|BlueMatt: did you see my comment about adding the orphan pool to your search.
251 2016-05-09 21:04:53 0|BlueMatt|gmaxwell: I did not
252 2016-05-09 21:05:06 0|BlueMatt|valid point, but "meh"
253 2016-05-09 21:07:02 0|gmaxwell|BlueMatt: I instrumented my copy and a lot of the missed txn are in the orphan pool.
254 2016-05-09 21:07:50 0|BlueMatt|WTF :(
255 2016-05-09 21:11:07 0|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.
256 2016-05-09 21:11:24 0|gmaxwell|it'll be much better with 0.13 widely deployed, but it's cheap to check the orphan pool.
257 2016-05-09 21:20:54 0|BlueMatt|yea, understood
258 2016-05-09 21:31:26 0|gmaxwell|(we also need to fix some of the orphan pool issues that the trickle improvements exposed)
259 2016-05-09 21:32:35 0|BlueMatt|yea, that