1 2016-07-19 01:01:40	0|BlueMatt|why is the hd wallet seed interpreted as an ecdsa privkey in a few places?
  2 2016-07-19 01:01:50	0|BlueMatt|that seems like type confusion in a cryptographic system
  3 2016-07-19 01:02:03	0|BlueMatt|though afaict its not really used as a pubkey anywhere, this seems like a very, very bad idea generally
  4 2016-07-19 01:03:42	0|BlueMatt|(every way I can think about it its nbd, just seems like bad practice)
  5 2016-07-19 01:06:00	0|sipa|BlueMatt: it's the other way around... we generate a (valid) private key, and then reinterpret it as a seed
  6 2016-07-19 01:06:10	0|BlueMatt|yes, this seems strange
  7 2016-07-19 01:06:16	0|sipa|this surprised me too
  8 2016-07-19 01:06:28	0|BlueMatt|because it seems to be the pubkey thing is only used to go find the data that we want to hash
  9 2016-07-19 01:06:44	0|sipa|but i only noticed it after merge, and i can't find any problems with it
 10 2016-07-19 01:07:06	0|BlueMatt|yea, I mean it doesnt seem to be broken, just bad practice
 11 2016-07-19 01:07:22	0|BlueMatt|(for encrypted wallets we store the pubkey-version in plaintext on disk, afaict, which is not ideal)
 12 2016-07-19 01:07:32	0|BlueMatt|^ about the only real issue I see
 13 2016-07-19 01:07:57	0|gmaxwell|more or less bypasses the kdf then.
 14 2016-07-19 01:08:09	0|sipa|what kdf?
 15 2016-07-19 01:08:22	0|sipa|bip32 does not have any
 16 2016-07-19 01:08:48	0|gmaxwell|The computationally hard function used for the passphrase in wallet encryption.  But nevermind, I'm incorrect, it doesn't bypass it.
 17 2016-07-19 01:09:04	0|sipa|ah, for encryption - no, indeed
 18 2016-07-19 01:09:10	0|BlueMatt|gmaxwell: no, remember the padding bug
 19 2016-07-19 01:09:11	0|BlueMatt|:(
 20 2016-07-19 01:09:36	0|gmaxwell|I don't consider the padding bug interesting.
 21 2016-07-19 01:09:40	0|sipa|still needs KDF; just no ec operation anymore
 22 2016-07-19 01:09:48	0|BlueMatt|gmaxwell: indeed, I consider it a novelty
 23 2016-07-19 01:10:49	0|sipa|BlueMatt: the alternative for the bip32 derivation is that we'd use the private key of the generated root as master key (with chaincode stored on disk), rather than treating it as a seed
 24 2016-07-19 01:11:03	0|sipa|which would pretty much have identical security properties
 25 2016-07-19 01:11:41	0|BlueMatt|sipa: kinda, ideally we wouldnt store the pubkey of that on disk
 26 2016-07-19 01:11:56	0|BlueMatt|sipa: actually, your suggestion is worse
 27 2016-07-19 01:12:00	0|BlueMatt|well, different
 28 2016-07-19 01:12:30	0|gmaxwell|I believe there is a way to quickly disqualify candidate private keys without EC operations in any case; assuming you know two signatures with that key.
 29 2016-07-19 01:12:47	0|BlueMatt|well, maybe better? right now you need to have your wallet unlocked to create new pubkeys (ie scan the chain, ish)
 30 2016-07-19 01:13:00	0|BlueMatt|but we could store master pubkey on disk and then we wouldnt
 31 2016-07-19 01:13:05	0|BlueMatt|dunno if better, but different
 32 2016-07-19 01:13:22	0|sipa|BlueMatt: it uses hardened derivation, so you always need to unlock in any case
 33 2016-07-19 01:13:28	0|BlueMatt|gmaxwell: mmm, didnt know that
 34 2016-07-19 01:13:35	0|gmaxwell|BlueMatt: that would require using public derrivation.
 35 2016-07-19 01:13:38	0|BlueMatt|sipa: ahh
 36 2016-07-19 01:13:45	0|BlueMatt|well, I mean you could store that as well
 37 2016-07-19 01:21:31	0|BlueMatt|is there any way to get an rpc or so to give you the master key?
 38 2016-07-19 01:21:38	0|BlueMatt|if you dump it, probably?
 39 2016-07-19 01:29:10	0|BlueMatt|the way I read the current code, every time we go to GenerateNewKey() we will iterate over every key we have already generated before generating a new one (as we never call SetHDChain to store the updated counter on disk)....anyone with a test hd wallet lying around want to see what their disk-counter is?
 40 2016-07-19 01:40:33	0|BlueMatt|hmm...I also dont see any discussion of the non-switch of FEATURE_LATEST on the pr....this might complicate future wallet changes...it seems to me that this locks us in such that the next change to wallet version must either be the same non-default or we will, at that time, have to force hd wallets to be the default
 41 2016-07-19 01:41:32	0|BlueMatt|I'm not strictly aginst this, just noting that it seems it was not at all discussed but locks us into a future path
 42 2016-07-19 01:44:11	0|BlueMatt|oh ffs, ok, I'ma copy this into the hd wallet pr
 43 2016-07-19 01:49:00	0|BlueMatt|ok, https://github.com/bitcoin/bitcoin/pull/8035#issuecomment-233508913
 44 2016-07-19 01:49:03	0|BlueMatt|few more there, too
 45 2016-07-19 02:12:45	0|luke-jr|BlueMatt: the odd thing IMO is that it isn't already default, but I'm okay with that
 46 2016-07-19 02:13:01	0|luke-jr|normally the default would be bumped immediately, and -walletupgrade needed for old wallets
 47 2016-07-19 08:27:13	0|jonasschnelli|luke-jr: how do you mean not the default? Per default core 0.13 will generate hd wallets (when starting a new wallet).
 48 2016-07-19 08:47:26	0|MarcoFalke|Also you can't do -walletupgrade to get an HD wallet
 49 2016-07-19 08:58:05	0|jonasschnelli|Yes. That would not work. HD can only be enabled during creation.
 50 2016-07-19 08:58:11	0|jonasschnelli|(for now)
 51 2016-07-19 09:57:22	0|GitHub114|13bitcoin/060.13 14df85463 15Pieter Wuille: Some 0.13 release notes about p2p changes
 52 2016-07-19 09:57:22	0|GitHub114|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/37269105c881...a07c8a032c0d
 53 2016-07-19 09:57:23	0|GitHub114|13bitcoin/060.13 14a07c8a0 15Wladimir J. van der Laan: Merge #8361: Some 0.13 release notes about p2p changes...
 54 2016-07-19 09:57:23	0|GitHub99|[13bitcoin] 15laanwj closed pull request #8361: Some 0.13 release notes about p2p changes (060.13...06relnotes-0.13) 02https://github.com/bitcoin/bitcoin/pull/8361
 55 2016-07-19 10:09:35	0|GitHub70|13bitcoin/06master 142c06bae 15Suhas Daftuar: Rename "block cost" to "block weight"
 56 2016-07-19 10:09:35	0|GitHub70|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5e3557b8e363...ca7550e128a3
 57 2016-07-19 10:09:36	0|GitHub70|13bitcoin/06master 14ca7550e 15Wladimir J. van der Laan: Merge #8363: Rename "block cost" to "block weight"...
 58 2016-07-19 10:09:50	0|GitHub19|[13bitcoin] 15laanwj closed pull request #8363: Rename "block cost" to "block weight" (06master...06cost-to-weight) 02https://github.com/bitcoin/bitcoin/pull/8363
 59 2016-07-19 10:10:53	0|GitHub24|13bitcoin/060.13 14fca1a41 15Suhas Daftuar: Rename "block cost" to "block weight"...
 60 2016-07-19 10:10:53	0|GitHub24|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/fca1a415cec6b7655448ce8b30778784ab4c181e
 61 2016-07-19 10:13:30	0|GitHub123|13bitcoin/06master 14a4f137f 15Jonas Schnelli: [Wallet] Ensure <0.13 clients can't open HD wallets
 62 2016-07-19 10:13:30	0|GitHub123|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ca7550e128a3...045106b4f13c
 63 2016-07-19 10:13:31	0|GitHub123|13bitcoin/06master 14045106b 15Wladimir J. van der Laan: Merge #8367: [Wallet] Ensure <0.13 clients can't open HD wallets...
 64 2016-07-19 10:13:43	0|GitHub41|[13bitcoin] 15laanwj closed pull request #8367: [Wallet] Ensure <0.13 clients can't open HD wallets (06master...062016/07/hd_minversion_014) 02https://github.com/bitcoin/bitcoin/pull/8367
 65 2016-07-19 10:14:28	0|GitHub48|13bitcoin/060.13 143b38a6a 15Jonas Schnelli: [Wallet] Ensure <0.13 clients can't open HD wallets
 66 2016-07-19 10:14:28	0|GitHub48|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/fca1a415cec6...24f117ef05f5
 67 2016-07-19 10:14:28	0|GitHub68|[13bitcoin] 15laanwj closed pull request #8366: [0.13] [Wallet] Ensure <0.13 clients can't open HD wallets (060.13...062016/07/hd_minversion) 02https://github.com/bitcoin/bitcoin/pull/8366
 68 2016-07-19 10:14:29	0|GitHub48|13bitcoin/060.13 1424f117e 15Wladimir J. van der Laan: Merge #8366: [0.13] [Wallet] Ensure <0.13 clients can't open HD wallets...
 69 2016-07-19 10:18:21	0|MarcoFalke|rc1 time? *.*
 70 2016-07-19 10:19:05	0|MarcoFalke|wait what about 8362?
 71 2016-07-19 10:24:36	0|GitHub184|13bitcoin/060.13 14ec8f5fc 15Wladimir J. van der Laan: doc: Add list of pulls and authors to release notes
 72 2016-07-19 10:24:36	0|GitHub184|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/ec8f5fc8b5f68ddf7fed0d74a5ec82e6b03f7f92
 73 2016-07-19 10:25:26	0|GitHub126|[13bitcoin] 15laanwj closed pull request #8360: doc: Add a few items to release notes (060.13...062016_07_release_notes) 02https://github.com/bitcoin/bitcoin/pull/8360
 74 2016-07-19 10:25:26	0|GitHub184|13bitcoin/060.13 14ded0599 15Wladimir J. van der Laan: doc: Add a few items to release notes...
 75 2016-07-19 10:25:26	0|GitHub184|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/ec8f5fc8b5f6...d6bb231a9fa9
 76 2016-07-19 10:25:27	0|GitHub184|13bitcoin/060.13 14d6bb231 15Wladimir J. van der Laan: Merge #8360: doc: Add a few items to release notes...
 77 2016-07-19 10:36:58	0|wumpus|going to tag rc1 in a bit
 78 2016-07-19 10:37:58	0|wumpus|anything that really still needs to go in? last chance
 79 2016-07-19 10:39:12	0|jonasschnelli|wumpus: what about TheBlueMatts concern about FEATURE_HD?
 80 2016-07-19 10:39:31	0|jonasschnelli|I have worked out a PR that can support a set of strings (features).
 81 2016-07-19 10:39:35	0|wumpus|I don't see it as a large problem
 82 2016-07-19 10:39:38	0|jonasschnelli|But probably to late for 0.13
 83 2016-07-19 10:39:58	0|sipa|i think string-based features can wait until later
 84 2016-07-19 10:40:05	0|wumpus|over time, HD wallets are probably going to be the default anyway, and the at-least-0.13 requirement is not a big issue
 85 2016-07-19 10:40:19	0|jonasschnelli|The only concern is, that if we introduce another feature (lets say KEY_ORIGIN_FLAGS [there is a PR]) that this feature would require 0.13 even if it would be compatible with < 0.13.
 86 2016-07-19 10:40:20	0|wumpus|I think how you handled the transfer period is fine
 87 2016-07-19 10:40:27	0|MarcoFalke|Jup, we can just make -upgradewallet take care of this
 88 2016-07-19 10:40:33	0|MarcoFalke|There is plenty of time till .14
 89 2016-07-19 10:40:36	0|wumpus|jonasschnelli: I don't see that as a big problem honestly
 90 2016-07-19 10:40:42	0|jonasschnelli|Yes. Agree.
 91 2016-07-19 10:40:55	0|jonasschnelli|But let me PR the set-of-strings feature work for later usage
 92 2016-07-19 10:40:59	0|wumpus|yes, we need a better feature system for the wallet, but it's not urgent
 93 2016-07-19 10:41:07	0|sipa|string-based features is a much more clean solution... but the current one works fine as long as versioning is completely serial
 94 2016-07-19 10:41:27	0|jonasschnelli|Yes. The optional HDness made it a bit more complex.
 95 2016-07-19 10:41:29	0|wumpus|I don't see the-next-feature-will-require-at-least-0.13 as a problem, as that'd likely be the case anyway
 96 2016-07-19 10:41:34	0|wumpus|it doesn't force actually using HD does it?
 97 2016-07-19 10:41:48	0|sipa|indeed
 98 2016-07-19 10:42:01	0|MarcoFalke|Also we don't do feature backports, so it should be easy
 99 2016-07-19 10:42:06	0|wumpus|right
100 2016-07-19 10:42:14	0|sipa|wumpus: there is still time for release notes, right?
101 2016-07-19 10:42:18	0|jonasschnelli|If we add another feature, we cannot go bellow FEATURE_HD. So all new features will require HD support.
102 2016-07-19 10:42:25	0|wumpus|#8362 is lacking a rationale: what bug is fixed there?
103 2016-07-19 10:42:28	0|jonasschnelli|We could no longer add features that run with <0.13
104 2016-07-19 10:42:35	0|wumpus|sipa: yes, there is no need to do that before rc1
105 2016-07-19 10:43:30	0|wumpus|jonasschnelli: they require hd *support*, they don't require the wallet to be hd
106 2016-07-19 10:43:46	0|wumpus|jonasschnelli: the latter I would see as a problem, but not this
107 2016-07-19 10:43:55	0|jonasschnelli|Sure. The point is only, that we can't add optional features that would run on 0.12 and below.
108 2016-07-19 10:44:17	0|MarcoFalke|We don't do that?
109 2016-07-19 10:44:19	0|wumpus|we could. Just don't increase the wallet min version?
110 2016-07-19 10:44:20	0|sipa|i'd also like to see 8365 in... but it needs more review/discussion than we can do at this point, i'm afraid
111 2016-07-19 10:44:42	0|jonasschnelli|wumpus: Yes. But you would need to increase it over FEATURE_HD.
112 2016-07-19 10:44:57	0|MarcoFalke|I guess 8365 is not a blocker for rc1?
113 2016-07-19 10:44:59	0|wumpus|jonasschnelli: why?
114 2016-07-19 10:45:38	0|wumpus|you can give it any value, depending on the first version that would be able to cope with it. But aren't features always introduced in the future?
115 2016-07-19 10:45:49	0|sipa|MarcoFalke: i think we've neglected fixing #8079 for some reason, and i don't like needing to say now "sorry, we didn't care enough to fix this bug we accidentally introduced"
116 2016-07-19 10:46:12	0|jonasschnelli|I think your right..
117 2016-07-19 10:47:03	0|jonasschnelli|Yes. Its not a problem. Indeed.
118 2016-07-19 10:47:10	0|wumpus|phew :)
119 2016-07-19 10:47:21	0|wumpus|we shouldn't add any new blockers for rc1
120 2016-07-19 10:47:30	0|wumpus|I'm sure rc2 will be necessary anyhow
121 2016-07-19 10:47:36	0|wumpus|major releases always have long rc cycles
122 2016-07-19 10:47:46	0|wumpus|the sooner we start testing, the better
123 2016-07-19 10:48:03	0|jonasschnelli|Yes.
124 2016-07-19 10:48:08	0|MarcoFalke|agree. There is so much to test
125 2016-07-19 10:48:11	0|wumpus|unless there is a really a critical this-will-crash-everything or security issue, of course
126 2016-07-19 10:48:43	0|MarcoFalke|Neither 8365 nor 8362 are critical
127 2016-07-19 10:50:55	0|sipa|i think 8362 has actually 0 effect in practice
128 2016-07-19 10:51:34	0|sipa|as GBT does not report the coinbase's sigops, and the 'generateblocks' call ignores it
129 2016-07-19 10:53:43	0|MarcoFalke|ERROR: src/leveldb is not a subtree
130 2016-07-19 10:53:47	0|MarcoFalke|https://travis-ci.org/bitcoin/bitcoin/jobs/145713130
131 2016-07-19 10:54:32	0|MarcoFalke|weird
132 2016-07-19 10:58:21	0|wumpus|MarcoFalke: travis issue or repository issue?
133 2016-07-19 10:58:37	0|MarcoFalke|Likely a travis issue
134 2016-07-19 10:59:20	0|wumpus|this is git-subtree-check.sh failing on something?
135 2016-07-19 11:01:47	0|wumpus|* [new tag]         v0.13.0rc1 -> v0.13.0rc1
136 2016-07-19 11:03:56	0|sipa|$ ./contrib/devtools/git-subtree-check.sh src/leveldb
137 2016-07-19 11:03:56	0|sipa|src/leveldb in HEAD was last updated to upstream commit 20ca81f08fb7fa108923a091668e447dcf5c6b9d (tree 1c185cba2ddcb6a77ece1094bc22aea072db84d1)
138 2016-07-19 11:03:59	0|sipa|src/leveldb in HEAD currently refers to tree 1c185cba2ddcb6a77ece1094bc22aea072db84d1
139 2016-07-19 11:04:02	0|sipa|GOOD
140 2016-07-19 11:13:27	0|sipa|should i rebuild base image?
141 2016-07-19 11:14:49	0|MarcoFalke|Gitian should handle this?
142 2016-07-19 11:14:56	0|jonasschnelli|Not sure.
143 2016-07-19 11:15:28	0|jonasschnelli|When did we update to Trusty? I guess sipa hasn't used gitian since the 0.12 release. :)
144 2016-07-19 11:15:36	0|sipa|i have a trusty image already
145 2016-07-19 11:15:38	0|sipa|but it's old
146 2016-07-19 11:15:43	0|jonasschnelli|Give it a try. :)
147 2016-07-19 11:15:43	0|MarcoFalke|Mine is from Dec 13
148 2016-07-19 11:15:44	0|sipa|i assume there have been point releases?
149 2016-07-19 11:15:49	0|sipa|already deleted the old one
150 2016-07-19 11:16:12	0|jonasschnelli|Jan  6  2016 base-trusty-amd64.qcow2
151 2016-07-19 11:16:34	0|sipa|hmm qcow2
152 2016-07-19 11:16:39	0|sipa|mine does not have any extension
153 2016-07-19 11:17:41	0|jonasschnelli|No idea why... :)
154 2016-07-19 11:17:54	0|jonasschnelli|https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/
155 2016-07-19 11:22:00	0|sipa|do i need the mac thing?
156 2016-07-19 11:22:57	0|jonasschnelli|Yes.
157 2016-07-19 11:23:04	0|jonasschnelli|sipa: I'll open you an URL.
158 2016-07-19 11:23:39	0|jonasschnelli|https://bitcoin.jonasschnelli.ch/MacOSX10.11.sdk.tar.gz
159 2016-07-19 11:23:53	0|jonasschnelli|(don't tell Tim Cook)
160 2016-07-19 11:27:08	0|sipa|should i use lxc or not?
161 2016-07-19 11:27:50	0|GitHub180|[13bitcoin] 15jonasschnelli opened pull request #8369: [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" (06master...062016/07/wallet_features) 02https://github.com/bitcoin/bitcoin/pull/8369
162 2016-07-19 11:27:58	0|jonasschnelli|sipa: I use KVM. Never got warm with LXC
163 2016-07-19 11:28:18	0|achow101|yay gitian building
164 2016-07-19 11:28:58	0|sipa|jonasschnelli: the gitian-building.md guide says use lxn
165 2016-07-19 11:28:59	0|sipa|lxc
166 2016-07-19 11:29:13	0|jonasschnelli|Its because wumpus uses LXC and write the doc. :)
167 2016-07-19 11:29:17	0|jonasschnelli|*wrote
168 2016-07-19 11:29:19	0|sipa|ah
169 2016-07-19 11:29:32	0|jonasschnelli|But I think its good if we have build of both worlds.
170 2016-07-19 11:29:39	0|jonasschnelli|*builds
171 2016-07-19 11:29:40	0|sipa|so it should work and result in identical builds?
172 2016-07-19 11:29:49	0|jonasschnelli|Yes. (I hope).
173 2016-07-19 11:29:56	0|jonasschnelli|I always uses KVM and had the same hashes
174 2016-07-19 11:32:14	0|jonasschnelli|MarcoFalke: what do I need to pass to gbuild to use parallelism? I now pass "-j2 --memory 3000" (had crashed with -j5)... but a tripple build takes >80mins.
175 2016-07-19 11:32:19	0|wumpus|yes, KVM and LXC both work, and yield indentical results
176 2016-07-19 11:32:24	0|MarcoFalke|j is default 2
177 2016-07-19 11:32:46	0|jonasschnelli|Okay. I uses -j5 without -memory 3000 in the past... maybe this was the issue.
178 2016-07-19 11:32:54	0|jonasschnelli|There are no other arguments?
179 2016-07-19 11:32:58	0|wumpus|I use LXC because I don't like nesting qemus
180 2016-07-19 11:32:59	0|MarcoFalke|but memory default is 2000, I think
181 2016-07-19 11:33:14	0|MarcoFalke|./gbuild -help
182 2016-07-19 11:33:21	0|wumpus|I have KVM on an older machine though and last time the gitian build just worked with it
183 2016-07-19 11:33:50	0|jonasschnelli|We should really extend gitian-builder to support ECDSA and add a binary verified to Qt
184 2016-07-19 11:34:09	0|wumpus|LXC is somewhat harder to set up though
185 2016-07-19 11:34:16	0|jonasschnelli|*binary verifier
186 2016-07-19 11:34:17	0|MarcoFalke|wumpus: Why nest. Run it on metal?
187 2016-07-19 11:34:25	0|jonasschnelli|metal?
188 2016-07-19 11:34:34	0|MarcoFalke|no virtual cpu
189 2016-07-19 11:34:38	0|MarcoFalke|the actual hardware
190 2016-07-19 11:35:04	0|jonasschnelli|ah
191 2016-07-19 11:35:06	0|wumpus|MarcoFalke: meh, too much bother - the big machine i have runs tons of VMs, and I don't really want to install anything in the top level
192 2016-07-19 11:37:02	0|MarcoFalke|I wonder how long it would take on my machine if I was using the nested approach
193 2016-07-19 11:37:28	0|wumpus|(of course it would be possible to dual-boot it into something else, for example with an external harddisk, but that means shutting down all other things)
194 2016-07-19 11:37:43	0|sipa|wumpus: you don't use VirtualBox?
195 2016-07-19 11:38:32	0|wumpus|I use virsh (from libvirt), inside there I have a debian VM, and inside that runs LXC with the builder
196 2016-07-19 11:38:33	0|MarcoFalke|But I always populate caches, so it runs quick on the actual tag
197 2016-07-19 11:39:24	0|wumpus|virsh is a bit unwieldy to set up, but nice and efficient if you have lots of VM instances
198 2016-07-19 11:39:36	0|wumpus|it doesn't have a nice user interface like virtualbox
199 2016-07-19 11:40:52	0|achow101|what about vmware?
200 2016-07-19 11:41:23	0|jonasschnelli|achow101: vmware, who knows whats running inside the VM then... :-)
201 2016-07-19 11:41:29	0|jonasschnelli|(or on the host)
202 2016-07-19 11:42:08	0|jonasschnelli|But I have to admit, I'm also using VMWare on my local mac. But for gitian it won't work I guess (at least not with significant fiddling).
203 2016-07-19 11:42:15	0|wumpus|I don't know anything about vmware, last time I used it must be some time in the 90's :)
204 2016-07-19 11:43:16	0|wumpus|but in principle you can run LXC inside *any* kind of virtualization
205 2016-07-19 11:44:21	0|sipa|ah, kvm does not work inside virtualbox?
206 2016-07-19 11:44:35	0|wumpus|as it simply uses linux' namespacing to keep processes contained, instead of virtualizing actual hardware, it doesn't need any special CPU bits either
207 2016-07-19 11:44:38	0|jonasschnelli|sipa: no.
208 2016-07-19 11:44:42	0|jonasschnelli|But in VM ware
209 2016-07-19 11:44:55	0|wumpus|sipa: I don't think so; or only with special cpus
210 2016-07-19 11:44:58	0|sipa|jonasschnelli: knowing that would have saved me a lot of time :)
211 2016-07-19 11:44:59	0|jonasschnelli|sipa: AFAIK VirtualBox has no native KVM support
212 2016-07-19 11:45:06	0|jonasschnelli|sipa: you didn't asked. :)
213 2016-07-19 11:45:15	0|wumpus|there is something as 'nested virtualization' , but I have no idea what supports it
214 2016-07-19 11:45:26	0|sipa|i was just following the guide, and you said KVM worked fine :)
215 2016-07-19 11:45:50	0|wumpus|you can also disable the CPU virtualization completely and use x86 emulation, but then compiling will likely take a year or so :-)
216 2016-07-19 11:46:00	0|jonasschnelli|sipa: I just run gitian-builder on my host
217 2016-07-19 11:46:27	0|jonasschnelli|I don't care about running in host mode because it's in a remote servercenter anyways.
218 2016-07-19 11:48:38	0|achow101|if anyone cares, here's a script I made for gitian building: https://gist.github.com/achow101/1bdd85cd4934b61a373d
219 2016-07-19 11:49:56	0|jonasschnelli|achow101: nice. I won't publish mine. It's a hell of a mess!
220 2016-07-19 11:50:08	0|wumpus|yes it looks better than my set of hacks too :)
221 2016-07-19 11:50:34	0|jonasschnelli|I had to add some html / apaxy hacks to get the html pages up: https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/
222 2016-07-19 11:50:40	0|jonasschnelli|Also it copies around the build.log, etc.
223 2016-07-19 11:51:11	0|jonasschnelli|achow101 looks pretty nice. You could also add support for building a PR and optional disable platforms...
224 2016-07-19 11:51:19	0|wumpus|especially copying the result immediately after the build can avoid a lot of annoyance, is my experience
225 2016-07-19 11:52:19	0|achow101|jonasschnelli: how does building from a PR work?
226 2016-07-19 11:52:56	0|wumpus|my script does automatically copy files which should be uploaded (and rename where necessary), and creates a SHA256SUMS. Although this will need to be updated for 0.13, with the new naming for the linux files, thinking of it.
227 2016-07-19 11:53:05	0|jonasschnelli|achow101: my scripts does something like: /bin/gbuild "+gbuildadd+" --commit signature="+VERSIONCOMMIT+"
228 2016-07-19 11:53:26	0|sipa|wumpus: ah, yes, i'll need to update my script as well...
229 2016-07-19 11:53:27	0|jonasschnelli|stuff like: --url bitcoin="+giturl+"
230 2016-07-19 11:53:46	0|jonasschnelli|*me agrees with sipa
231 2016-07-19 11:54:18	0|wumpus|yes possibly, mine is too hacky and specific to my setup to upload though
232 2016-07-19 11:54:37	0|wumpus|e.g. I don't have the GPG keys on the machine that builds, for example
233 2016-07-19 11:55:12	0|jonasschnelli|achow101: also check: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#building-an-alternative-repository
234 2016-07-19 11:56:10	0|achow101|jonasschnelli: thanks.
235 2016-07-19 11:56:12	0|wumpus|the rest is pretty much just copy/paste from the release notes. So at some point the script needs to be customized that much before it's useful, that providing an example isn't much more useful than just pointing at the release notes :)
236 2016-07-19 11:56:58	0|wumpus|yes --url bitcoin=${URI} --commit bitcoin=${COMMIT}  can be very useful. You can also use local paths.
237 2016-07-19 12:08:51	0|jonasschnelli|linux build complete: hashes to compare: https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/
238 2016-07-19 12:09:07	0|jonasschnelli|19499e5a569d5d8685a043bf3e5cf9d34450733333295b636af84d7a2589d881  bitcoin-0.13.0-x86_64-linux-gnu.tar.gz
239 2016-07-19 12:09:16	0|jonasschnelli|all: https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/bitcoin-linux-0.13-build.assert
240 2016-07-19 12:09:59	0|wumpus|all match with my build, even the ARM ones
241 2016-07-19 12:15:24	0|wumpus|windows build: http://www.hastebin.com/luwelodopa
242 2016-07-19 12:20:44	0|achow101|how big should I make -j and -m to make it build faster?
243 2016-07-19 12:22:08	0|sipa|-j: not more than you have cpu cores
244 2016-07-19 12:22:23	0|sipa|-m: something like 1500 times the number you pass to j
245 2016-07-19 12:22:37	0|sipa|but -m also not more than the physical memory you have in your vm
246 2016-07-19 12:28:50	0|kinlo|-j should be a bit higher then cores right?  you usually end up with processes waiting for disk and not utilizing cpu, so oversubscribing a bit should increase speed
247 2016-07-19 12:29:41	0|sipa|i've tried various numbers between 5 and 10 (i have 4 core, 8 threads), but it doesn't seem to matter much for overall compilation speed
248 2016-07-19 12:31:23	0|wumpus|kinlo: I usually use cores+1 for that reason, but haven't benchmarked wether it is any faster
249 2016-07-19 12:32:02	0|sipa|my gitian build scripts seems to use -j 4 -m 8000
250 2016-07-19 12:32:12	0|sipa|but no idea how those numbers came about
251 2016-07-19 12:32:23	0|wumpus|compiling bitcoin is quite CPU intensive, so the i/o overhead may be very little in comparison, it may not be the same for every project
252 2016-07-19 12:33:24	0|wumpus|e.g. for a project such as tor with tons of C files that compile very quickly, I think using -j >> cores will achieve more, as all those gcc's spend a relatively large part of their lifespan accessing disk
253 2016-07-19 12:35:29	0|kinlo|I usually only compile the kernel, noticed speedups there but indeed, makes sense...
254 2016-07-19 12:36:27	0|wumpus|kernel is similar
255 2016-07-19 12:37:28	0|achow101|I set my -j to double the cores I have. I don't know whether that makes a significant difference though
256 2016-07-19 12:45:18	0|jonasschnelli|match with wumpuses windows hashes: https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/bitcoin-win-0.13-build.assert
257 2016-07-19 13:31:30	0|achow101|linux build finally done. Matches wumpus and jonasschnelli hashes
258 2016-07-19 13:32:09	0|jonasschnelli|Nice!
259 2016-07-19 13:32:17	0|sipa|still going here...
260 2016-07-19 13:41:05	0|btcdrak|isnt -m deprecated and ignored now?
261 2016-07-19 13:41:23	0|sipa|on lxc it has no effect i think
262 2016-07-19 13:41:47	0|btcdrak|according to man pages it's ignored
263 2016-07-19 13:41:54	0|btcdrak|(GNU Make 4.0)
264 2016-07-19 13:42:05	0|sipa|it's a parameter to gbuild
265 2016-07-19 13:42:10	0|btcdrak|ah
266 2016-07-19 13:57:47	0|GitHub182|[13bitcoin] 15jonasschnelli opened pull request #8371: [Qt] Add out-of-sync modal info layer (06master...062016/07/UI-out-of-sync) 02https://github.com/bitcoin/bitcoin/pull/8371
267 2016-07-19 13:58:36	0|MarcoFalke|looks neat
268 2016-07-19 14:01:28	0|jonasschnelli|would be cool if this modal info layer would have two sliders: one for dbcache mem, one for CPU (-par)
269 2016-07-19 14:03:38	0|MarcoFalke|how come the mac mismatches?
270 2016-07-19 14:04:00	0|MarcoFalke|https://github.com/bitcoin-core/gitian.sigs/pull/359#issue-166339496
271 2016-07-19 14:05:12	0|MarcoFalke|three builders, three different bitcoin-0.13.0-osx-unsigned.tar.gz
272 2016-07-19 14:05:58	0|achow101|that's a problem isn't it
273 2016-07-19 14:07:17	0|jonasschnelli|hmm..
274 2016-07-19 14:08:35	0|jonasschnelli|Yes. OSX build are non-deterministic...
275 2016-07-19 14:10:03	0|jonasschnelli|Hmm.. on my end I have some strange Qt5.5 packages: https://github.com/bitcoin-core/gitian.sigs/blob/master/0.13.0rc1-osx-unsigned/jonasschnelli/bitcoin-osx-0.13-build.assert#L808
276 2016-07-19 14:10:14	0|jonasschnelli|maybe issue with the cache
277 2016-07-19 14:11:55	0|MarcoFalke|Is it due to my depends faketime patch?
278 2016-07-19 14:14:18	0|jonasschnelli|MarcoFalke: could be. But I think more likely my Qt5.6 PKGConfig hacking patch
279 2016-07-19 14:21:14	0|MarcoFalke|but bdb is a mismatch as well? You didn't fiddle with this
280 2016-07-19 14:25:05	0|jonasschnelli|I guess mismatches are okay in the packages...
281 2016-07-19 14:27:42	0|MarcoFalke|right
282 2016-07-19 14:56:35	0|achow101|Also have an OSX mismatch
283 2016-07-19 14:59:07	0|GitHub185|[13bitcoin] 15UdjinM6 opened pull request #8372: Fix AddRef() usage for CNode (06master...06fixNodeRefCount) 02https://github.com/bitcoin/bitcoin/pull/8372
284 2016-07-19 16:00:07	0|michagogo|Could someone please paste a `git diff v0.12.1..v0.13.0rc1 doc/release-process.md`?
285 2016-07-19 16:05:36	0|MarcoFalke|http://pastebin.ubuntu.com/20051707/
286 2016-07-19 16:15:49	0|wumpus|jonasschnelli: aren't the osx-unsigned always non-deterministic? cfields can confirm this, but I remember something like that
287 2016-07-19 16:17:54	0|cfields|wumpus: mm, i don't believe so.
288 2016-07-19 16:18:02	0|cfields|internet was down this morning, building now.
289 2016-07-19 16:19:43	0|gmaxwell|[semi-OT for this channel] https://www.reddit.com/r/Bitcoin/comments/4tly0n/blockstream_announces_an_open_patent_pledge_and/
290 2016-07-19 16:21:13	0|michagogo|MarcoFalke: thanks!
291 2016-07-19 16:21:34	0|cfields|wumpus / jonasschnelli / achow101: could one of you make your osx build results available for comparison? I'm building now, not sure exactly what to ask for in particular yet.
292 2016-07-19 16:31:02	0|jonasschnelli|cfields: https://bitcoin.jonasschnelli.ch/releasebuilds/v0.13.0rc1/
293 2016-07-19 16:31:16	0|jonasschnelli|And there are two signatures in the gitian sigs repo.
294 2016-07-19 16:31:34	0|jonasschnelli|Plus MarcoFalkes PR (also OS X sig)
295 2016-07-19 16:32:29	0|cfields|jonasschnelli: great, thanks.
296 2016-07-19 16:41:32	0|michagogo|My builds are dubbing now
297 2016-07-19 16:41:34	0|michagogo|Running
298 2016-07-19 16:41:45	0|michagogo|(Qt rebuild :-( )
299 2016-07-19 16:41:51	0|achow101|cfields: everything I built is at https://github.com/achow101/bitcoin/releases/tag/v0.13.0rc1. sigs have been PR'ed
300 2016-07-19 16:42:12	0|cfields|achow101: thanks
301 2016-07-19 16:45:30	0|cfields|jonasschnelli: hmm, our end-result osx binaries are the same, despite the different tarball hashes. I'm thinking it might just be timestamps in .tar's or so
302 2016-07-19 16:45:32	0|cfields|looking deeper now.
303 2016-07-19 16:50:21	0|cfields|whoops, nm. the osx64.tar.gz is the same for everyone.
304 2016-07-19 16:53:15	0|michagogo|Wait, we bumped the SDK?
305 2016-07-19 16:53:25	0|MarcoFalke|jup
306 2016-07-19 16:53:33	0|michagogo|:-/
307 2016-07-19 16:55:13	0|cfields|achow101 / jonasschnelli: either of you have the bitcoin-0.13.0-osx-unsigned.tar.gz available?
308 2016-07-19 16:56:31	0|achow101|cfields: is that file supposed to be produced? I don't see it
309 2016-07-19 16:56:50	0|cfields|achow101: your script probably automatically moves it to gitian/inputs
310 2016-07-19 16:57:10	0|michagogo|(I'm still not used to having things like my browser launch instantaneously...)
311 2016-07-19 16:59:20	0|achow101|cfields: found it (I think) and uploaded to the page I linked earlier
312 2016-07-19 16:59:28	0|cfields|achow101: thanks
313 2016-07-19 17:10:09	0|jl2012|to build for osx, should I just put the MacOSX10.11.sdk.tar.gz to the inputs directory?
314 2016-07-19 17:10:20	0|achow101|jl2012: yes
315 2016-07-19 17:10:48	0|jl2012|thanks
316 2016-07-19 17:19:06	0|sdaftuar|sipa: in #8365 i noticed you didn't change the rpc handlers to output the sigops-adjusted-vsize.  was that intentional?  looks like the mempool rpc's would do the right thing, but decoderawtransaction would report unadjusted vsize
317 2016-07-19 17:20:31	0|cfields|aha, found the difference
318 2016-07-19 17:20:55	0|cfields|looks like the DS_Store generator isn't deterministic somehow. mine doesn't match achow101's
319 2016-07-19 17:21:34	0|sipa|sdaftuar: it's intentional, but i'm not sure what the best approach is
320 2016-07-19 17:21:38	0|MarcoFalke|You can also run twice and it doesn't match
321 2016-07-19 17:21:48	0|achow101|cfields: so how is that fixed?
322 2016-07-19 17:22:05	0|cfields|achow101: looking now to see how/why it differs
323 2016-07-19 17:22:40	0|sdaftuar|sipa: seems like the cleanest thing would be for vsize to our policy-adjusted vsize, and for us to add a field to the output which is the transaction weight
324 2016-07-19 17:23:10	0|sipa|sdaftuar: the difficulty is determining the sigops...
325 2016-07-19 17:23:15	0|sipa|for wallet txn
326 2016-07-19 17:23:28	0|sipa|for raw transactions it's just impossuble
327 2016-07-19 17:24:42	0|sdaftuar|i was thinking that there's an ambiguity for things that are in our mempool, but right i see your point
328 2016-07-19 17:25:45	0|sipa|i'd rather try to make sure we never produce transactions ourselves for which it has an effect :)
329 2016-07-19 17:27:30	0|sdaftuar|yeah, that might work fine for the wallet code.  i'm a little worried that the approach of having two different sizes we use, a policy size and an actual size, will be error prone in the future.
330 2016-07-19 17:27:44	0|sdaftuar|so i was just trying to go through and identify every usage to make sure it made sense
331 2016-07-19 17:29:34	0|sdaftuar|seems like if we do end up eventually changing bytespersigop to 50, it'll be easy for wallet users to accidentally generate transactions that are affected by the policy
332 2016-07-19 17:29:46	0|sdaftuar|if you have a bunch of p2pkh outputs, you'll hit it
333 2016-07-19 17:31:52	0|sipa|really?
334 2016-07-19 17:31:56	0|sipa|signatures are 72 bytes
335 2016-07-19 17:32:08	0|sdaftuar|outputs -- legacy sigop count will get you
336 2016-07-19 17:33:32	0|sdaftuar|for instance, i found this tx, which is a bit extreme, but illustrates the point: https://www.blocktrail.com/BTC/tx/c9daddde3379f16e11a547b34e9723c7b5ca71c82bf1213fc93bf13d81cd601f
337 2016-07-19 17:34:47	0|sdaftuar|that's the one i found with sigop cost of 9644
338 2016-07-19 19:11:25	0|BlueMatt|wumpus: needed a fix for "I think IsKeyType should be changed to include hdchain, not add an explicit hdchain check in ::Recover, since we probably definitely want it in ::LoadWallet as well." first
339 2016-07-19 19:11:34	0|BlueMatt|that is very bad behavior
340 2016-07-19 19:12:54	0|BlueMatt|oh, you already tagged rc1...ugh
341 2016-07-19 19:17:27	0|BlueMatt|wumpus: also you merged 8367 without fixing the bug I pointed out in it..........
342 2016-07-19 19:21:18	0|gmaxwell|BlueMatt: open a PR to fix it. your "not that it really matters" might have understated your expectation that it would get fixed.
343 2016-07-19 19:21:54	0|BlueMatt|I mean I figured it'd get fixed before merge, even if its not a huge deal
344 2016-07-19 19:27:10	0|sipa|BlueMatt: i'm sure there'll be a second rc anyway
345 2016-07-19 19:27:40	0|sipa|i guess wumpus wanted to get an rc out to get testing from a wider audience
346 2016-07-19 19:27:53	0|cfields|i think i have the osx determinism issue worked out. any gitian builders around to verify?
347 2016-07-19 19:27:53	0|gmaxwell|we're seriously late on the RC. It was good to get one out.
348 2016-07-19 19:28:03	0|BlueMatt|yeayea, I'm not suggesting anything is gonna catch fire, just saying there are a few things here to fix for rc2
349 2016-07-19 19:31:37	0|MarcoFalke|The check is dead code and the strings in the exceptions need the function names adjusted ...
350 2016-07-19 19:31:56	0|MarcoFalke|It is good to have rc1 out. We can fix those later
351 2016-07-19 19:32:07	0|MarcoFalke|cfields: I can try
352 2016-07-19 19:32:29	0|cfields|MarcoFalke: ok. tested by hand, plugging it all in now. ready in ~10min
353 2016-07-19 19:32:29	0|MarcoFalke|Is it just a descriptor bump or do we need rc2 already?
354 2016-07-19 19:33:07	0|achow101|cfields: I can try it too
355 2016-07-19 19:34:15	0|cfields|MarcoFalke: i'll leave it up to wumpus. it's the .DS_Store, which is inconsequential and has no influence on the binary. but it means that gitian results won't match.
356 2016-07-19 19:34:51	0|michagogo|Got the new SDK -- my rc1 is building right now
357 2016-07-19 19:39:47	0|luke-jr|did we bump ds_store Python or smth? O.o
358 2016-07-19 19:44:42	0|GitHub16|[13bitcoin] 15theuni opened pull request #8373: Fix OSX non-deterministic dmg (06master...06biplist-determinism) 02https://github.com/bitcoin/bitcoin/pull/8373
359 2016-07-19 19:47:04	0|luke-jr|ahh
360 2016-07-19 19:54:37	0|cfields|luke-jr: think there's any way to post-process an existing ds_store with unsorted plists inside so that we can just fix it up in the gitian descriptor for rc1?
361 2016-07-19 19:55:38	0|luke-jr|I would imagine so, but meh? :/
362 2016-07-19 19:55:59	0|cfields|luke-jr: otherwise i don't think i can sign rc1
363 2016-07-19 19:58:54	0|luke-jr|cfields: can DS_Store do anything malicious? why not just compare the binaries without it?
364 2016-07-19 19:58:58	0|cfields|hmm, i guess that's not right. that file's outside of the .app, so i suppose it's not signed at all
365 2016-07-19 19:59:55	0|luke-jr|right
366 2016-07-19 20:00:19	0|luke-jr|so it's not a technical issue AFAIK, just potentially philosophical
367 2016-07-19 20:01:49	0|cfields|yep. i guess a few builders could manually fixup inside gitian to force an order, then at least there's a reference for a matching hash
368 2016-07-19 20:02:46	0|cfields|but yes, since it's not signed data and everyone's binaries should match, i'll carry on signing as usual
369 2016-07-19 20:04:20	0|michagogo|If you push the sigs before my script finishes running, it should grab them and generate sigs for the -signeds too
370 2016-07-19 20:04:45	0|michagogo|(I'm going to sleep now, but the PR should be pushed automatically)
371 2016-07-19 20:08:21	0|GitHub18|[13bitcoin] 15sdaftuar opened pull request #8374: Add release notes for mining changes (060.13...06release-notes-mining) 02https://github.com/bitcoin/bitcoin/pull/8374
372 2016-07-19 20:08:34	0|cfields|michagogo: great, thanks
373 2016-07-19 20:20:00	0|achow101|Finished my build with cfields patch
374 2016-07-19 20:20:21	0|achow101|0269f915640886ba16c73450ab2dbcdde0304fa79807414c7e0cf4d4ba8f39df  src/bitcoin-0.13.99.tar.gz
375 2016-07-19 20:20:21	0|achow101|9fa6b31128eee2cfa535774fe4eebaa384f0471c094ce6ee6aefe9aef93f134b  bitcoin-0.13.99-osx-unsigned.dmg
376 2016-07-19 20:20:21	0|achow101|e2e33efea3d2c86d34391b3be20d032343b359909cdbe55b1153ba109ae5af4f  bitcoin-0.13.99-osx-unsigned.tar.gz
377 2016-07-19 20:20:21	0|achow101|fc5a233b3be260ec7be63f699bbc128240ad190692cd5d4a82cc1352eb3c57df  bitcoin-0.13.99-osx64.tar.gz
378 2016-07-19 20:20:22	0|achow101|ab0a5e271e81fb48cf355f866a105eca12713260e703da35330ae66e03336367  bitcoin-osx-0.13-res.yml
379 2016-07-19 20:26:07	0|MarcoFalke|achow101: You applied the patch on the gitian vm?
380 2016-07-19 20:26:29	0|achow101|yes
381 2016-07-19 20:28:56	0|MarcoFalke|cfields: Let us know if signing the binaries worked out for you
382 2016-07-19 20:31:38	0|luke-jr|at least bloated spam discourages miners from including it
383 2016-07-19 20:56:20	0|cfields|MarcoFalke: will do, still working on it.
384 2016-07-19 20:56:36	0|MarcoFalke|great
385 2016-07-19 20:58:07	0|achow101|ran the build again and got the same results
386 2016-07-19 20:59:14	0|cfields|achow101: to clarify, you're testing master now, right?
387 2016-07-19 20:59:23	0|achow101|yes
388 2016-07-19 21:00:09	0|cfields|ok
389 2016-07-19 21:20:43	0|cfields|0.13.0rc1 sigs pushed.
390 2016-07-19 21:21:09	0|cfields|achow101: building master with that PR on top now. thanks for doing that so quickly :)
391 2016-07-19 21:24:17	0|cfields|achow101: actually, before i build, could you specify the commit you built? Not sure if you cherry-picked or merged, and that'll change the result
392 2016-07-19 21:26:36	0|achow101|I grabbed the diff and applied it.
393 2016-07-19 21:26:55	0|achow101|probably wasn't the right thing to do, but i was being lazy
394 2016-07-19 21:29:52	0|cfields|achow101: mm, i don't think i'm going to be able to match your result, then
395 2016-07-19 21:29:56	0|achow101|err. actually I think I just built your branch. I was originally just going to use the diff but I screwed something up
396 2016-07-19 21:31:18	0|cfields|3b3ce25df6cc, then?
397 2016-07-19 21:31:56	0|achow101|yes
398 2016-07-19 21:32:30	0|cfields|ok great, building that.
399 2016-07-19 21:36:59	0|phantomcircuit|jonasschnelli, i rebased 8152 can you review again
400 2016-07-19 21:45:16	0|phantomcircuit|jonasschnelli, why does CHDKeyStore::PrivateKeyDerivation take the keypath as a string?
401 2016-07-19 23:20:17	0|Chris_Stewart_5|Is nFilterBytes suppose to be a compact sized unsigned integer on this documentation? https://bitcoin.org/en/developer-reference#filterload
402 2016-07-19 23:22:33	0|phantomcircuit|Chris_Stewart_5, the docs there are literally wrong
403 2016-07-19 23:22:37	0|phantomcircuit|the literal serialization is
404 2016-07-19 23:22:49	0|phantomcircuit|serialized vector of uint8_t
405 2016-07-19 23:23:04	0|sipa|phantomcircuit: the docs always make lengths of vectors explicit
406 2016-07-19 23:23:15	0|phantomcircuit|uint32_t nhashfuncs, uint32_t ntweak, uint8_t nflags
407 2016-07-19 23:23:24	0|phantomcircuit|sipa, either way it's missing ntweak entirely
408 2016-07-19 23:23:28	0|sipa|ah
409 2016-07-19 23:23:33	0|sipa|eh, no?
410 2016-07-19 23:23:37	0|phantomcircuit|oh no it's not
411 2016-07-19 23:23:38	0|phantomcircuit|what
412 2016-07-19 23:23:48	0|Chris_Stewart_5|nTweak is there, is there suppose to be a tweak along with it?
413 2016-07-19 23:23:53	0|phantomcircuit|oh the weird warning makes it look like there's nothing below the fold
414 2016-07-19 23:24:20	0|sipa|Chris_Stewart_5: to answer your first question: yes
415 2016-07-19 23:24:26	0|phantomcircuit|yeah nvm it's right
416 2016-07-19 23:24:27	0|sipa|it's a compact integer
417 2016-07-19 23:26:03	0|Chris_Stewart_5|I've had issues even trying to find the classes/structs that correspond to some of these messages, where can I find the actual message structure in core?
418 2016-07-19 23:28:17	0|Chris_Stewart_5|If I do a search I find references to 'FilterLoad' for instance in main.cpp, protocol.cpp and protocol.h but no class or struct, unless i'm missing something obvious
419 2016-07-19 23:30:29	0|sipa|{
420 2016-07-19 23:30:29	0|sipa|CBloomFilter filter;
421 2016-07-19 23:30:29	0|sipa|else if (strCommand == NetMsgType::FILTERLOAD)
422 2016-07-19 23:30:30	0|sipa|vRecv >> filter;
423 2016-07-19 23:30:38	0|sipa|CBloomFilter is defined in bloom.h
424 2016-07-19 23:31:20	0|Chris_Stewart_5|and there is some ffunction defined in CBloomFilter to deserialize the DataStream?
425 2016-07-19 23:36:26	0|Chris_Stewart_5|I'm just following the stack and it seems like we go from streams.h -> serialize.h which starts parsing the varint, but I don't see where the contents are explicitly passed to a constructure or anything
426 2016-07-19 23:36:47	0|Chris_Stewart_5|is there some C++ convention going on here?
427 2016-07-19 23:37:09	0|sipa|there is a lot of magic in serialize.h
428 2016-07-19 23:38:00	0|sipa|ADD_SERIALIZE_METHODS expands into the necessary serialization boilerplate
429 2016-07-19 23:39:12	0|Chris_Stewart_5|oh ok. Does it use some sort of reflection to call the necessary constructors?
430 2016-07-19 23:39:36	0|sipa|there are no constructors inbolved
431 2016-07-19 23:39:57	0|sipa|the constructor of CBloomFilter is invoked on the line where filter is declared
432 2016-07-19 23:40:38	0|sipa|the 'vRecv >> filter' just reads data from vRecv stream and fills filter with it
433 2016-07-19 23:42:48	0|Chris_Stewart_5|and this 'fill' function is defined in ADD_SERIALIZE_METHODS?
434 2016-07-19 23:44:08	0|GitHub8|[13bitcoin] 15pstratem opened pull request #8375: Move key derivation logic from GenerateNewKey to DeriveNewKey (06master...062016-07-19-cwallet-derivenewkey) 02https://github.com/bitcoin/bitcoin/pull/8375
435 2016-07-19 23:44:51	0|sipa|yes, it's called Deserializr
436 2016-07-19 23:44:57	0|sipa|Deserializr
437 2016-07-19 23:45:02	0|sipa|grr, stupid keyboard
438 2016-07-19 23:45:04	0|sipa|Deserialize
439 2016-07-19 23:45:35	0|Chris_Stewart_5|Your 'e' key wants you to go to sleep :-). Thanks sipa
440 2016-07-19 23:50:14	0|phantomcircuit|i think it's easier to read that way ^