1 2016-07-07 00:01:44	0|luke-jr|cfields: kicked it
  2 2016-07-07 00:02:26	0|cfields|luke-jr: i've been watching the log, pretty confident we're good to go now. It was only working by chance before.
  3 2016-07-07 00:02:32	0|luke-jr|phantomcircuit: no, I agree
  4 2016-07-07 00:02:41	0|luke-jr|cfields: heh
  5 2016-07-07 00:07:04	0|GitHub83|[13bitcoin] 15mcelrath opened pull request #8311: Rename CTxinWitness -> CTxInWitness (06master...06CTxInWitness) 02https://github.com/bitcoin/bitcoin/pull/8311
  6 2016-07-07 00:07:22	0|bsm117532|dumb patch of the day...
  7 2016-07-07 00:08:33	0|sipa|hah
  8 2016-07-07 00:31:59	0|luke-jr|cfields: looks like a success :D
  9 2016-07-07 00:32:56	0|cfields|luke-jr: woohoo
 10 2016-07-07 00:33:44	0|cfields|luke-jr: for future reference, when behind cloudflare, apache needs mod_cloudflare, otherwise incoming ips are actually cloudflare proxy ips
 11 2016-07-07 00:33:49	0|cfields|who knew
 12 2016-07-07 00:33:51	0|luke-jr|XD
 13 2016-07-07 00:34:08	0|luke-jr|cfields: btw, can you set someone else up with access to raise our bus factor?
 14 2016-07-07 00:34:51	0|cfields|luke-jr: sure, i think there are several though
 15 2016-07-07 00:35:11	0|luke-jr|eh?
 16 2016-07-07 00:35:18	0|cfields|i believe wumpus/btcdrak/bluematt have access
 17 2016-07-07 00:35:36	0|luke-jr|wumpus said he didn't, and the other two didn't speak up IIRC
 18 2016-07-07 00:35:55	0|cfields|oh, hmm. ok, will check
 19 2016-07-07 00:36:58	0|cfields|there was an issue with dns after the move, maybe they're missing the new info
 20 2016-07-07 00:37:50	0|cfields|mm, it may be worth setting up some fancy deployment scripting stuff. Not sure what the latest/greatest is. chef/puppet/etc.
 21 2016-07-07 00:38:41	0|sipa|maybe wumpus has access but does not know it :)
 22 2016-07-07 00:39:07	0|luke-jr|heh
 23 2016-07-07 00:41:43	0|cfields|i think that's probably the case. i thought i lost access until btcdrak figured out the dns weirdness
 24 2016-07-07 00:50:28	0|phantomcircuit|cfields, he's going to run you over with a bus, quick run away!
 25 2016-07-07 00:58:17	0|luke-jr|…
 26 2016-07-07 01:00:49	0|cfields|heh
 27 2016-07-07 01:48:41	0|GitHub152|[13bitcoin] 15sdaftuar opened pull request #8312: Fix mempool DoS vulnerability from malleated transactions (06master...06mempool-malleability) 02https://github.com/bitcoin/bitcoin/pull/8312
 28 2016-07-07 05:24:28	0|wumpus|cfields: I don't think I ever received login details for the 'new' server, at least I don't remember
 29 2016-07-07 06:41:24	0|jonasschnelli|Ping MarcoFalke
 30 2016-07-07 06:41:46	0|jonasschnelli|I don't see how you could lost coins with the new HD feature...
 31 2016-07-07 06:41:56	0|jonasschnelli|*lose coins
 32 2016-07-07 06:45:26	0|wumpus|right - it just works, it exports/imports the keys. What it doesn't do is restore the HD seed, but you do lose the information needed to generate new addresses using the old seed after a export/import.  That means the backup gnerated in such a way is not forward-compatible as wallet.dat is
 33 2016-07-07 06:45:50	0|wumpus|anyhow it seems that https://github.com/bitcoin/bitcoin/pull/8206 solves this issue by adding it to dumpwallet, that's exactly what we want
 34 2016-07-07 06:48:04	0|wumpus|(well, not the importing-back the seed part, but at least it gives a way to export the seed)
 35 2016-07-07 06:48:25	0|wumpus|handling that properly will be more complex, as then the wallet would have multiple master keys
 36 2016-07-07 06:48:50	0|wumpus|(so which one to use for generating new addresses? it seems to even need an API change)
 37 2016-07-07 06:49:37	0|wumpus|such an invasive change is aboslutely too late for 0.13, we could try to sneak in #8206, or put a warning in the release notes
 38 2016-07-07 06:58:17	0|MarcoFalke|jonasschnelli: I was trying to do an actual backup. Not just dumpwallet
 39 2016-07-07 06:58:38	0|MarcoFalke|See the HD test: https://github.com/bitcoin/bitcoin/pull/8309
 40 2016-07-07 06:59:57	0|MarcoFalke|I don't understand that I cannot copy my wallet_hd.dat to external storage and then move it to a fresh box after I burned my old one.
 41 2016-07-07 07:00:33	0|MarcoFalke|the wallet.dat should contain the HD master key, thus I am able to derive all addresses and collect my coins.
 42 2016-07-07 07:00:42	0|MarcoFalke|So why does it fail?
 43 2016-07-07 07:09:28	0|jonasschnelli|MarcoFalke: the current HD feature will not auto-recover funds/keys you have created after the backup...
 44 2016-07-07 07:09:34	0|jonasschnelli|Did you ran into this issue?
 45 2016-07-07 07:09:41	0|MarcoFalke|nope
 46 2016-07-07 07:09:56	0|jonasschnelli|If you copy back your wallet.dat, it should be the same as it was before...
 47 2016-07-07 07:10:24	0|MarcoFalke|https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR65
 48 2016-07-07 07:10:35	0|MarcoFalke|This derives all the keys
 49 2016-07-07 07:10:39	0|MarcoFalke|(again)
 50 2016-07-07 07:11:10	0|MarcoFalke|Then asserts that the last derived key is identical to the last derived key of the first run
 51 2016-07-07 07:11:21	0|MarcoFalke|But somehow it does not update the balance
 52 2016-07-07 07:11:45	0|jonasschnelli|hmm...
 53 2016-07-07 07:12:35	0|jonasschnelli|MarcoFalke: if you call getnewaddress, you get the same address but not the received coins to this address, right?
 54 2016-07-07 07:12:53	0|jonasschnelli|I guess it requires a rescan (after getnewaddress)
 55 2016-07-07 07:12:55	0|MarcoFalke|jup
 56 2016-07-07 07:13:11	0|MarcoFalke|I tried rescan and reindex
 57 2016-07-07 07:13:23	0|jonasschnelli|reindex should not be necessary... rescan works?
 58 2016-07-07 07:13:28	0|MarcoFalke|no
 59 2016-07-07 07:14:42	0|jonasschnelli|let me test it locally... thanks for testing / writing the test!
 60 2016-07-07 07:15:03	0|jonasschnelli|I knew that the backup restore is not something users can easily do.
 61 2016-07-07 07:15:26	0|MarcoFalke|Correct, but there should be some way to do it
 62 2016-07-07 07:15:29	0|jonasschnelli|Not sure if we should have something more convenient (backup restore) for 0.13
 63 2016-07-07 07:15:35	0|jonasschnelli|Yes.
 64 2016-07-07 07:15:42	0|jonasschnelli|Maybe we discuss this tonight at the IRC meeting
 65 2016-07-07 07:16:16	0|MarcoFalke|oh
 66 2016-07-07 07:16:18	0|MarcoFalke|I got it
 67 2016-07-07 07:16:37	0|MarcoFalke|importprivkey breaks all future backups
 68 2016-07-07 07:16:43	0|MarcoFalke|:(
 69 2016-07-07 07:16:51	0|MarcoFalke|This should be fixed I assume
 70 2016-07-07 07:17:09	0|MarcoFalke|Maybe a small fix in the rescan logic
 71 2016-07-07 07:17:23	0|jonasschnelli|What's the reason for this?
 72 2016-07-07 07:17:27	0|MarcoFalke|no idea
 73 2016-07-07 07:17:39	0|jonasschnelli|Why does it breaks all future backups?
 74 2016-07-07 07:17:44	0|jonasschnelli|*break
 75 2016-07-07 07:18:10	0|MarcoFalke|Maybe only legacy keys are rescanned when there is at least one?
 76 2016-07-07 07:18:42	0|MarcoFalke|Need to look into the code...
 77 2016-07-07 07:19:26	0|jonasschnelli|If you are able to recreate the address you had before you restored your backup you should be capable of restoring the transactions with -rescan
 78 2016-07-07 07:19:35	0|jonasschnelli|Thanks for looking into the code
 79 2016-07-07 07:20:36	0|jonasschnelli|MarcoFalke: you could add a dumpwallet here (https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR71) and see if it dumps the missing/failed-to-restore-funds-from-key
 80 2016-07-07 07:32:27	0|MarcoFalke|More likely it is just a getbalance issue. I remember there were "some" issues lately
 81 2016-07-07 09:38:54	0|wumpus|what's wrong with getbalance?
 82 2016-07-07 15:29:20	0|jonasschnelli|MarcoFalke: I just create a regtest hd wallet (keypoolsize=1), did a backup right after creation, generated 100 blocks, stopped, deleted the wallet,.. then...
 83 2016-07-07 15:29:55	0|jonasschnelli|I reloaded the old wallet only containing 1 key, called 100 times getnewaddress, stopped, started with -rescan and could successful reconstruct the balance/wtxs
 84 2016-07-07 15:30:02	0|jonasschnelli|Seems to work...
 85 2016-07-07 15:30:21	0|jonasschnelli|Maybe need to check in conjunction with importprivkey...
 86 2016-07-07 15:43:20	0|GitHub155|[13bitcoin] 15yurizhykin opened pull request #8313: Use std::move() instead of copying/removing in TxMemPool (06master...06tx-delete) 02https://github.com/bitcoin/bitcoin/pull/8313
 87 2016-07-07 17:56:31	0|MarcoFalke|IsMine returns false for the txs involving the HD keys
 88 2016-07-07 17:57:05	0|zooko|Hey Core Devs: here's another patch we've been working on for Zcash which you might want upstream in Bitcoin Core: https://github.com/zcash/zcash/issues/915
 89 2016-07-07 17:57:32	0|zooko|We'll put in the time to merge it if desired.
 90 2016-07-07 17:58:14	0|gmaxwell|cfields: ^
 91 2016-07-07 17:58:16	0|zooko|I've asked Zcash engineer Taylor "earthrise" Hornby to support you on that if you want it.
 92 2016-07-07 17:58:46	0|zooko|The _other_ one that I mentioned a few days back turned out to have a bug — we were
 93 2016-07-07 17:58:53	0|cfields|zooko / gmaxwell: thanks
 94 2016-07-07 17:59:06	0|zooko|trying to measure time to validate a block packed full of worst-case quadratic signature.
 95 2016-07-07 17:59:18	0|zooko|And we were accidentally measuring time to check that the signature was already cached. ;-)
 96 2016-07-07 17:59:27	0|zooko|But we've fixed that, and now we have some results.
 97 2016-07-07 18:00:10	0|zooko|Oh, the results aren't visible here, yet, for some reason, but hopefully will be soon: https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=time+validatelargetx&env=1&revs=50&equid=off&quarts=on&extr=on
 98 2016-07-07 18:00:16	0|zooko|35s for 1 MB block, 140s for 2 MB block
 99 2016-07-07 18:01:23	0|cfields|zooko: hmm, i believe we already do those checks
100 2016-07-07 18:01:53	0|cfields|we might not verify FORTIFY_SOURCE, though
101 2016-07-07 18:04:01	0|cfields|zooko: mind pointing Taylor to "make check-security"? If there's a check we're missing, we would certainly add it
102 2016-07-07 18:12:32	0|michagogo|Heh, nice
103 2016-07-07 18:13:09	0|michagogo|Up to block 216k after about 40 minutes
104 2016-07-07 18:18:57	0|bsm117532|Yeah my reindex is CPU bound.
105 2016-07-07 18:22:36	0|gmaxwell|OT, but of interest: http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
106 2016-07-07 18:39:46	0|GitHub148|[13bitcoin] 15theuni opened pull request #8314: Fix pkg-config issues for 0.13 (06master...06fix-pkg-config) 02https://github.com/bitcoin/bitcoin/pull/8314
107 2016-07-07 18:45:25	0|GitHub155|13bitcoin/06master 14fa6ad56 15MarcoFalke: [travis] Update SDK_URL
108 2016-07-07 18:45:25	0|GitHub155|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/91abb77970f4...0cca2feb357a
109 2016-07-07 18:45:26	0|GitHub155|13bitcoin/06master 140cca2fe 15Jonas Schnelli: Merge #8304: [travis] Update SDK_URL...
110 2016-07-07 18:45:35	0|GitHub94|[13bitcoin] 15jonasschnelli closed pull request #8304: [travis] Update SDK_URL (06master...06Mf1606-travisSDKURL) 02https://github.com/bitcoin/bitcoin/pull/8304
111 2016-07-07 18:46:36	0|jonasschnelli|gmaxwell, sipa: Bip151: what do you think by using HKDF instead of a single SHA_HMAC to derive the symmetric cipher key from the ECDH secret?
112 2016-07-07 18:46:53	0|sipa|i have not looked into HKDF, but we should
113 2016-07-07 18:47:16	0|jonasschnelli|RFC: https://tools.ietf.org/html/rfc5869
114 2016-07-07 18:49:23	0|jonasschnelli|openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
115 2016-07-07 18:55:12	0|zooko|cfields: done: https://github.com/zcash/zcash/issues/1071
116 2016-07-07 18:58:16	0|jonasschnelli|gmaxwell: https://people.xiph.org/~greg/auth0.txt, why does AUTHCHALLENGE require "believed_server_pubkey"?
117 2016-07-07 18:59:16	0|gmaxwell|jonasschnelli: so client cannot fingerprint the server. If he doesn't know the pubkey for the server the server will not respond using it.
118 2016-07-07 18:59:33	0|btcdrak|meeting time?
119 2016-07-07 18:59:39	0|jonasschnelli|yes
120 2016-07-07 18:59:41	0|petertodd|yup
121 2016-07-07 18:59:57	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
122 2016-07-07 19:00:10	0|wumpus|#startmeeting
123 2016-07-07 19:00:11	0|lightningbot|Meeting started Thu Jul  7 19:00:10 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
124 2016-07-07 19:00:11	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
125 2016-07-07 19:00:14	0|cfields|gmaxwell: thanks. here.
126 2016-07-07 19:00:17	0|sdaftuar|hi
127 2016-07-07 19:00:28	0|gmaxwell|Welcome to meeting.
128 2016-07-07 19:00:44	0|wumpus|proposed topic: 0.13.0rc1
129 2016-07-07 19:00:51	0|petertodd|wumpus: ack
130 2016-07-07 19:00:57	0|gmaxwell|This week was a week of many reverts. Reverting will continue until morale improves.
131 2016-07-07 19:01:01	0|michagogo|Hi
132 2016-07-07 19:01:04	0|wumpus|#topic 0.13.0rc1
133 2016-07-07 19:01:13	0|sipa|somewhat present
134 2016-07-07 19:01:19	0|jonasschnelli|Are we +1 day with the 0.13 splitoff?
135 2016-07-07 19:01:20	0|wumpus|foremost, I cannot build a release at this moment, as gitian lxc building is broken
136 2016-07-07 19:01:21	0|MarcoFalke|Is the HD issue a blocker for the rc?
137 2016-07-07 19:01:21	0|sdaftuar|wumpus: so there are a couple bugs that still need to be fixed for 0.13
138 2016-07-07 19:01:38	0|wumpus|https://github.com/bitcoin/bitcoin/issues/8212 / https://github.com/bitcoin/bitcoin/pull/8213
139 2016-07-07 19:01:50	0|cfields|wumpus: ok. I'll handle those next.
140 2016-07-07 19:01:53	0|wumpus|MarcoFalke: which HD issue?
141 2016-07-07 19:02:03	0|MarcoFalke|I couldn't restore from a HD backup
142 2016-07-07 19:02:04	0|jonasschnelli|I think there is no "real" HD issue
143 2016-07-07 19:02:08	0|michagogo|wumpus: Broken in what way?
144 2016-07-07 19:02:17	0|MarcoFalke|jonasschnelli: Could you look into the travis failure
145 2016-07-07 19:02:17	0|wumpus|michagogo: please read the issues
146 2016-07-07 19:02:19	0|MarcoFalke|?
147 2016-07-07 19:02:24	0|jonasschnelli|Yes. Will do..
148 2016-07-07 19:02:25	0|gmaxwell|MarcoFalke: It's unclear to me if we understand the issue you've encountered completely, if we do not understand it, I think it is a blocker.
149 2016-07-07 19:02:29	0|michagogo|(Sorry, I've not had much free time for this stuff in the past months)
150 2016-07-07 19:02:40	0|wumpus|if HD is broken, we have to disable  it for 0.13
151 2016-07-07 19:02:48	0|michagogo|(Gitian issues or Bitcoin Core?)
152 2016-07-07 19:02:54	0|wumpus|or at least rc1
153 2016-07-07 19:02:57	0|MarcoFalke|gmaxwell: You can see the issue on travis
154 2016-07-07 19:02:58	0|jonasschnelli|Sure. Let me check MarcoFalke HD test
155 2016-07-07 19:03:06	0|MarcoFalke|It is either an error in my test code
156 2016-07-07 19:03:07	0|gmaxwell|Disabling it indeed would be an option.
157 2016-07-07 19:03:15	0|MarcoFalke|or some issue with IsMine() or something else
158 2016-07-07 19:03:27	0|gmaxwell|This may be a current design limitation if my understanding is correct. But I'm happy to discuss elsewhere/elsetime.
159 2016-07-07 19:03:33	0|MarcoFalke|I'd rather fix it than disable it
160 2016-07-07 19:03:40	0|cfields|MarcoFalke: link to travis failure?
161 2016-07-07 19:03:42	0|wumpus|I don't want to block rc1 too long
162 2016-07-07 19:03:46	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8309/files
163 2016-07-07 19:03:52	0|wumpus|rather have a test release out as soon as possible
164 2016-07-07 19:03:54	0|btcdrak|remaining issue/prs for 0.13 https://github.com/bitcoin/bitcoin/milestones/0.13.0
165 2016-07-07 19:04:02	0|MarcoFalke|pull 8309
166 2016-07-07 19:04:07	0|MarcoFalke|cfields: ^
167 2016-07-07 19:04:11	0|gmaxwell|lets talk about the other things then move on to the hd issue as it's own topic.
168 2016-07-07 19:04:13	0|cfields|thanks
169 2016-07-07 19:04:30	0|wumpus|planning was to do rc1 yesterday, but it was clear it wasn't possible
170 2016-07-07 19:04:47	0|wumpus|btcdrak: some things can be merged as-is I think
171 2016-07-07 19:04:52	0|MarcoFalke|Also there are some issues open by sdaftuar
172 2016-07-07 19:05:01	0|sdaftuar|#8305 (headers sync issue), #8312 (mempool DoS post-segwit merge), and #8295 (mining code fixes post segwit-merge) are all meant for 0.13.0
173 2016-07-07 19:05:28	0|wumpus|#7678 (release notes) is a TODO for -final, not rc1, could use some help there though
174 2016-07-07 19:06:14	0|wumpus|are they ready for merge?
175 2016-07-07 19:06:15	0|btcdrak|sdaftuar those should be tagged with the milestone then
176 2016-07-07 19:06:28	0|sipa|i will write some release notes for the tx relay changes
177 2016-07-07 19:06:35	0|sipa|(but not now)
178 2016-07-07 19:06:49	0|sdaftuar|i believe all could be merged now.  after discussing with sipa, i think i'll make #8312 simpler even than it is now, since no one has reviewed anyway
179 2016-07-07 19:06:50	0|wumpus|right, release notes is not urgent now, just needs to be done before final
180 2016-07-07 19:06:55	0|wumpus|let's worry about rc1 now
181 2016-07-07 19:07:13	0|sdaftuar|#8305 and #8295 are done as far as i know
182 2016-07-07 19:07:18	0|sdaftuar|(no review though)
183 2016-07-07 19:07:33	0|wumpus|yes the problem is review - I don't think people are very active at the moment, probably tired from all the big merges such as segwit
184 2016-07-07 19:08:19	0|gmaxwell|I've been very busy with testing, in fact.
185 2016-07-07 19:08:38	0|wumpus|testing is good
186 2016-07-07 19:08:47	0|wumpus|releasing rc1 will result in a lot of testing, too
187 2016-07-07 19:09:16	0|sipa|wumpus: i was less active the past week; i'll be back tomorrow
188 2016-07-07 19:10:26	0|wumpus|ok I see jonasschnelli already added 0.13 milestone to sdaftuar's pulls, thanks
189 2016-07-07 19:10:35	0|jonasschnelli|Yes.
190 2016-07-07 19:10:41	0|cfields|I've been inactive as well. Nice and refreshed now, I can help with review of 8295/8312 once the build issues are worked out
191 2016-07-07 19:11:43	0|petertodd|i'll try to look at 8312 this weekend
192 2016-07-07 19:11:44	0|wumpus|cfields: I wish we could get rid of the as-root patching requirement for arm linux, it'd make things much easier build-ssytem wise
193 2016-07-07 19:12:41	0|cfields|wumpus: i can look into a quick-hack work-around for rc1. but iirc, it's hard to avoid until ubuntu fixes
194 2016-07-07 19:13:34	0|wumpus|cfields: well for 0.14 we can switch to 16.04, which I guess has fixed this, but for 0.13 we're stuck with it. I don't mind the gitian prepare script change, but I'm not sure what the gitian people think about it, devrandom hasnt' commented on it
195 2016-07-07 19:13:49	0|cfields|wumpus: quick alternative would bt c/p the descriptor to linux-arm.yml for now
196 2016-07-07 19:14:00	0|gmaxwell|will we be able to distribute arm linux binaries for 0.13?
197 2016-07-07 19:14:23	0|wumpus|gmaxwell: yes, that was done, but it has added an awkward requirement to the gitian build descriptor
198 2016-07-07 19:14:24	0|jonasschnelli|yes
199 2016-07-07 19:15:31	0|cfields|wumpus: would you like me to just copy the descriptor for now? The issue is the conflicting toolchains, so that would solve it. It would just mean an extra gbuild.
200 2016-07-07 19:15:35	0|wumpus|in any case, to conclude this topic: https://github.com/bitcoin/bitcoin/milestone/20 is an accurate reflection of what has to be done before rc1? (apart from the release notes issue)
201 2016-07-07 19:16:47	0|petertodd|wumpus: ack
202 2016-07-07 19:17:12	0|wumpus|cfields: I'll try to contact devrandom about the gitian change, if we can't speed that up, I think splitting up the descriptor makes sense. It does mean temporary changes to the release process, I preferred it this way :)
203 2016-07-07 19:17:54	0|cfields|ok
204 2016-07-07 19:18:08	0|wumpus|#action wumpus contact devrandom about https://github.com/devrandom/gitian-builder/pull/123
205 2016-07-07 19:18:12	0|achow101|what about segwit deployment parameters
206 2016-07-07 19:18:23	0|btcdrak|achow101: not for 0.13.0
207 2016-07-07 19:18:42	0|wumpus|we could add that as proposed topic, but not relevant for 0.13
208 2016-07-07 19:19:07	0|sipa|achow101: first backport to 0.12, figuring out cb+segwit, and planning releases
209 2016-07-07 19:19:09	0|btcdrak|achow101: it's explained in https://bitcoincore.org/en/lifecycle/#consensus-rules
210 2016-07-07 19:19:11	0|MarcoFalke|#action Help with review on https://github.com/bitcoin/bitcoin/milestone/20
211 2016-07-07 19:19:18	0|wumpus|we're done with this topic though so i'm ok with switching
212 2016-07-07 19:20:14	0|gmaxwell|Okay can we talk briefly about the HD wallet thing?
213 2016-07-07 19:20:20	0|wumpus|#topic HD wallet issue
214 2016-07-07 19:20:44	0|sipa|what is the hd wallet issue number?
215 2016-07-07 19:20:56	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8309/files
216 2016-07-07 19:21:00	0|jonasschnelli|Its a PR (failing test)
217 2016-07-07 19:21:15	0|jonasschnelli|currently looking at it.
218 2016-07-07 19:21:21	0|MarcoFalke|The rpc-test is pretty simple: usehd=1, then backup wallet.dat
219 2016-07-07 19:21:30	0|jonasschnelli|The addresses are re-generated deterministic... but somehow reindex fails..
220 2016-07-07 19:21:31	0|MarcoFalke|Do some transactions and discard wallet.dat
221 2016-07-07 19:21:34	0|gmaxwell|If I understand the issue correctly there is a design limitation that we can easily work around.  I believe the limitation is that it only scans the keys currently in the pool, and when the pool expands it doesn't go back at all, and it doesn't expand the pool based on used keys as it goes. This means that recovery will miss things without a recan in many cases.
222 2016-07-07 19:21:39	0|gmaxwell|But I could misunderstand.
223 2016-07-07 19:22:07	0|jonasschnelli|Yes. The simples HD feature does not cover restores...
224 2016-07-07 19:22:18	0|gmaxwell|If I am not incorrect here, then simply setting the keypool default really large when usehd is set would be an adequate workaround, I believe.
225 2016-07-07 19:22:18	0|MarcoFalke|I am running rescan and reindex. None of it fixes it
226 2016-07-07 19:22:20	0|jonasschnelli|Restore is manual work (including a rescan)
227 2016-07-07 19:22:36	0|gmaxwell|if a rescan isn't fixing it, thats a more serious issue than I was thinking.
228 2016-07-07 19:23:02	0|MarcoFalke|I was logging the result of IsMine on each tx and it retured false, so the transactions were never added to the wallet in the second run (rescan)
229 2016-07-07 19:23:03	0|jonasschnelli|Yes... I currently trying to find out why MarcoFalke test fails even after a rescan.
230 2016-07-07 19:23:20	0|gmaxwell|In any case we cannot RC it with a serious doubt about it not working. It could be disabled in an RC if needed.
231 2016-07-07 19:23:22	0|wumpus|but if you set keypool really large then it will generate and store all those keys, defeating the purpose of using HD in the first place, or not?
232 2016-07-07 19:23:24	0|jonasschnelli|But IMO it's unrelated to HD,... the keys are recreated.
233 2016-07-07 19:23:49	0|wumpus|yes, I think this scary, I don't think this is ready for a release
234 2016-07-07 19:23:53	0|gmaxwell|wumpus: it's the same keys every time, no defeating.
235 2016-07-07 19:23:57	0|jonasschnelli|Sure. Let me first try to find the root cause before we consider a revert
236 2016-07-07 19:24:16	0|MarcoFalke|agree
237 2016-07-07 19:24:19	0|wumpus|rever wouldn't be necessary, just default the flag to false
238 2016-07-07 19:24:46	0|wumpus|it defaults to true for new wallets now which is what makes it scary if it would be somehow broken
239 2016-07-07 19:24:47	0|gmaxwell|In any case we cannot RC it with a serious doubt about it not working. It could be disabled in an RC if needed. If the issue can be reduced to needs rescan I described then I think increasing the pool is adequate.
240 2016-07-07 19:24:47	0|jonasschnelli|Sure. But we probably don't want to ship a (per default disabled) feature which _could_ includes bugs. :)
241 2016-07-07 19:24:57	0|petertodd|wumpus: is the flag documented in --help?
242 2016-07-07 19:25:34	0|gmaxwell|We need to understand the issue at a minimum or make it unavailable, too risky as even an option. IMO. But I don't have any doubt that we will understand the issue in a day or so.
243 2016-07-07 19:25:39	0|jonasschnelli|MarcoFalke: have you tried the test with HD disabled (just import your created keys)?
244 2016-07-07 19:25:55	0|gmaxwell|I haven't looked at it yet myself except passively watching the discussion.
245 2016-07-07 19:26:00	0|sipa|likewise
246 2016-07-07 19:26:04	0|sipa|i will look soon
247 2016-07-07 19:26:05	0|MarcoFalke|no
248 2016-07-07 19:26:20	0|jonasschnelli|I think without knowing the root cause of the problem actions are useless.
249 2016-07-07 19:26:34	0|wumpus|agreed
250 2016-07-07 19:26:41	0|sipa|agree; we need to understand it
251 2016-07-07 19:26:42	0|jonasschnelli|I will know more about it in a couple of hours.
252 2016-07-07 19:26:48	0|sipa|and i believe there is plenty of time for that
253 2016-07-07 19:27:08	0|wumpus|before when?
254 2016-07-07 19:27:11	0|gmaxwell|Okay well the action is to determine the issue(s). :)  Though if wumpus decides to cut an RC before we do, I'd ask that the option be disabled in it.
255 2016-07-07 19:27:27	0|wumpus|yes, need to disable it completely then, I agree
256 2016-07-07 19:27:42	0|jonasschnelli|Yes. But it could also be a serious import/rescan issue (not related to HD)
257 2016-07-07 19:28:10	0|wumpus|the non-HD rescan test passes, right?
258 2016-07-07 19:28:19	0|MarcoFalke|yes
259 2016-07-07 19:28:24	0|sipa|i believe that rpc test is less elaborate
260 2016-07-07 19:28:47	0|wumpus|did you try your new test without HD MarcoFalke?
261 2016-07-07 19:28:50	0|jonasschnelli|I think we would need the same test (that fails) without HD
262 2016-07-07 19:29:18	0|MarcoFalke|You can't create keys deterministically without HD
263 2016-07-07 19:29:33	0|jonasschnelli|I can see the exact keys in the wallet after the restore but I can see rescan failing to reconstruct the wtxs.
264 2016-07-07 19:29:38	0|sipa|no need to discuss the details here
265 2016-07-07 19:29:43	0|wumpus|oh sure, you can't do exactly the dsame thing
266 2016-07-07 19:29:45	0|jonasschnelli|MarcoFalke: you could create 100 keys and reimport them...
267 2016-07-07 19:30:05	0|jonasschnelli|anyways,... I'll have a look at it and will report on the PR
268 2016-07-07 19:30:08	0|gmaxwell|in any case, I think this can move outside the meeting now, we known what general things we need to do to make progress.
269 2016-07-07 19:30:14	0|jonasschnelli|ack
270 2016-07-07 19:30:15	0|wumpus|right
271 2016-07-07 19:30:19	0|wumpus|any other topics?
272 2016-07-07 19:31:07	0|gmaxwell|Sure, an announcement:
273 2016-07-07 19:31:47	0|sipa|*crickets*
274 2016-07-07 19:31:55	0|jonasschnelli|oO
275 2016-07-07 19:32:31	0|gmaxwell|Matt has announced his new relaynetwork work that uses UDP and FEC, http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/  the current not really fully cooked software gets worldwide block propagation 99% of the time in less than 100ms over the fiber-path distances.
276 2016-07-07 19:32:45	0|petertodd|+1
277 2016-07-07 19:32:58	0|jonasschnelli|Saw this. Impressive work! Well done.
278 2016-07-07 19:33:01	0|gmaxwell|(actually 98% of the time in the last day)
279 2016-07-07 19:33:12	0|btcdrak|Also the FIBRE website is http://bitcoinfibre.org/
280 2016-07-07 19:33:14	0|cfields|nice!
281 2016-07-07 19:33:17	0|wumpus|awesome!
282 2016-07-07 19:33:24	0|gmaxwell|And his deployment uses only cheap VPSes.
283 2016-07-07 19:33:39	0|sipa|wow, i saw the website but hadn't appreciated how good the numbers were
284 2016-07-07 19:33:46	0|sipa|i just looked at how oretty the graphs were
285 2016-07-07 19:33:54	0|gmaxwell|may be of some interest to some people, he's trying to get other people to setup parallel networks, and put up an extensive guide, including tricks for getting access to low latency connectivity between asia and europe. :)
286 2016-07-07 19:34:18	0|sipa|we need neutrino-based transmissions.
287 2016-07-07 19:34:26	0|petertodd|sipa: lol, I was just about to say
288 2016-07-07 19:34:34	0|gmaxwell|Stats are at http://bitcoinrelaynetwork.org/stats_ng.html   there is also plety of room to improve the software/protocol still.
289 2016-07-07 19:34:38	0|petertodd|sipa: reminds me, I wrote a short story about that awhile back...
290 2016-07-07 19:35:10	0|wumpus|neutrono-based transmissions are easy, compared to the receiver part :)
291 2016-07-07 19:35:21	0|btcdrak|The github project is at https://github.com/bitcoinfibre
292 2016-07-07 19:35:55	0|petertodd|wumpus: what? don't you have a few tonnes of heavy water laying around?
293 2016-07-07 19:36:21	0|gmaxwell|Including the actual speed of light delays, he gets worldwide sync in 98% of the time in under 238ms, 80% in under 165ms.  So thats all fun.
294 2016-07-07 19:36:27	0|sipa|i believe production of heavy water may be more decentralized than sha256 asic mining production.
295 2016-07-07 19:37:00	0|petertodd|sipa: yes! https://www.youtube.com/watch?v=Sxl78pWW8Vk
296 2016-07-07 19:38:19	0|gmaxwell|onto other subjects, I'd still like to see a testnet-defaulting binary during the RCs. My contribution to that effort was getting master working correctly on testnet again. :) but I haven't done anything else. :(
297 2016-07-07 19:38:33	0|wumpus|petertodd: of course I do, but not enough shielded undergorund space to put it
298 2016-07-07 19:39:20	0|gmaxwell|there are trillions of gallons of heavy water not so many miles from me; ... it's just unfortunately mixed with lots of light water and salt.
299 2016-07-07 19:39:36	0|petertodd|wumpus: that's why I took up caving
300 2016-07-07 19:40:02	0|cfields|gmaxwell: what's the reason for an additional binary?
301 2016-07-07 19:40:31	0|cfields|gmaxwell: oh, you mean default to testnet until final release?
302 2016-07-07 19:40:32	0|wumpus|gmaxwell: we could do that now, eg before the rc1
303 2016-07-07 19:40:47	0|wumpus|well at least if I could build releases, dang
304 2016-07-07 19:40:52	0|gmaxwell|wumpus: yea, I think we should too, we just couldn't do it when testnet was getting stuck for many, but it's fixed now.
305 2016-07-07 19:41:18	0|wumpus|cfields: not the rc1 itself, more like a master-build-with-only-testnet-enabled
306 2016-07-07 19:41:54	0|gmaxwell|cfields: I've found that a lot of people would like to play with it are actually thrown off by setting an option. It's not so intutive for GUI users.  I think this would greatly increase testnet usage to have builds that work more like bitcoin/altcoin installs.
307 2016-07-07 19:41:54	0|wumpus|rc1 should definitely have mainnet by default, like any rc
308 2016-07-07 19:42:32	0|wumpus|gmaxwell: did you see #8285? it's super-easy now for windows GUI users
309 2016-07-07 19:42:38	0|cfields|hmm
310 2016-07-07 19:42:40	0|gmaxwell|one possibility I considered is that we could just sniff the binary name and have -testnet and -testnet-qt change the default, and ship a link. :P
311 2016-07-07 19:42:51	0|petertodd|gmaxwell: I wonder if a wrapper script with -testnet would help those users?
312 2016-07-07 19:42:55	0|gmaxwell|but perhaps thats too much for now. :)
313 2016-07-07 19:43:18	0|wumpus|https://github.com/bitcoin/bitcoin/pull/8285 exactly does that
314 2016-07-07 19:43:22	0|cfields|wumpus: ah nice, i missed that
315 2016-07-07 19:43:28	0|gmaxwell|I didn't see it.
316 2016-07-07 19:43:37	0|gmaxwell|(or forgot seeing it!)
317 2016-07-07 19:43:59	0|petertodd|wumpus: ah cool, thanks!
318 2016-07-07 19:44:03	0|gmaxwell|Thats really awesome.
319 2016-07-07 19:44:22	0|petertodd|wumpus: just like mainnet/testnet wallets on my android phone
320 2016-07-07 19:44:50	0|gmaxwell|in any case, it's still left with the 'upgrade testnet without upgrading mainnet' issue, that a testnet only build from master would fix.
321 2016-07-07 19:44:51	0|wumpus|petertodd: indeed, bitcoin wallet for android has been doing a similar thing
322 2016-07-07 19:44:58	0|gmaxwell|if you could do builds. :P
323 2016-07-07 19:46:16	0|cfields|heh, hint taken. Working on the split descriptors now.
324 2016-07-07 19:46:59	0|wumpus|thanks cfields
325 2016-07-07 19:47:34	0|wumpus|any other topics?
326 2016-07-07 19:47:45	0|petertodd|)
327 2016-07-07 19:47:45	0|petertodd|wumpus: happy halving day :
328 2016-07-07 19:47:47	0|petertodd|:)
329 2016-07-07 19:48:05	0|wumpus|hah, same to you
330 2016-07-07 19:48:40	0|gmaxwell|I wonder if there is some scifi where halving day is where half the people die? it seems right.
331 2016-07-07 19:48:41	0|petertodd|wumpus: I'll be hiding in a cave most of that day fyi - so if the world ends don't call me :P
332 2016-07-07 19:49:04	0|petertodd|gmaxwell: satoshi should have made it a 10% think, so we could call it DECIMATION DAY
333 2016-07-07 19:49:19	0|petertodd|*thing
334 2016-07-07 19:49:31	0|wumpus|petertodd: that sounds like a wise thing to do, hide in a cave until it blows over
335 2016-07-07 19:49:49	0|sipa|i wish i had a cave here
336 2016-07-07 19:49:54	0|sipa|i'm in the middle of paris
337 2016-07-07 19:50:01	0|sipa|and there is some football thing
338 2016-07-07 19:50:16	0|petertodd|sipa: you've got the most awesome sewer system, and the catacombs!
339 2016-07-07 19:50:18	0|gmaxwell|sipa: catacombs.
340 2016-07-07 19:50:33	0|sipa|catacombs close in 10 minutes.
341 2016-07-07 19:50:48	0|petertodd|sipa: "officially" speaking...
342 2016-07-07 19:51:01	0|jonasschnelli|shortly back to the HD issue: I think it's a simple bug in the test https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR71 ( self.node_args[1].extend(['-rescan']) does not work)
343 2016-07-07 19:51:09	0|sipa|hah.
344 2016-07-07 19:51:11	0|jonasschnelli|All light are green. :)
345 2016-07-07 19:51:13	0|gmaxwell|pfft. plenty of people have gone after hours and spent the rest of their lives there.
346 2016-07-07 19:51:13	0|sipa|yay
347 2016-07-07 19:51:22	0|jonasschnelli|self.node_args[1].extend(['-rescan']) should be  self.node_args[1] + ['-rescan']
348 2016-07-07 19:51:57	0|MarcoFalke|Wow
349 2016-07-07 19:52:25	0|petertodd|jonasschnelli: oh, is node_args[1] a tuple?
350 2016-07-07 19:52:25	0|wumpus|jonasschnelli: wow, very good news, and you found it within the meeting :D
351 2016-07-07 19:52:39	0|gmaxwell|that may just leave us with the surprising behavior that it doesn't fill the pool on its own. which would be good news, since thats easy to workaround.
352 2016-07-07 19:52:48	0|jonasschnelli|I'm not familiar with extend() but seems to be the wrong function for that purpose.
353 2016-07-07 19:53:06	0|jonasschnelli|But I guess we want MarcoFalke's RPC test in 0.13! :)
354 2016-07-07 19:53:20	0|petertodd|jonasschnelli: extend() is list only, and modifies in place
355 2016-07-07 19:53:57	0|wumpus|yes, extend is in place and returns nothing
356 2016-07-07 19:54:23	0|jonasschnelli|At least we tested again the HD feature...
357 2016-07-07 19:54:39	0|sipa|6 minutes
358 2016-07-07 19:54:52	0|sipa|are we done?
359 2016-07-07 19:54:59	0|gmaxwell|sipa: until we lose you to the catacombs?
360 2016-07-07 19:54:59	0|wumpus|I think so?
361 2016-07-07 19:55:31	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.log.html
362 2016-07-07 19:55:31	0|lightningbot|Meeting ended Thu Jul  7 19:55:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
363 2016-07-07 19:55:31	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.html
364 2016-07-07 19:55:31	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.txt
365 2016-07-07 19:55:31	0|wumpus|#endmeeting
366 2016-07-07 19:56:26	0|sdaftuar|wumpus: can you advise how to handle the warning string in #8295, if -blockminsize is given? i left it untranslated inside an InitWarning, wasn't sure if that was the right thing to do
367 2016-07-07 19:56:34	0|petertodd|fyi, I can't dig it up right now because webbtc.com is broken, but I noticed the other day that we had the first CSV redemption on mainnet!
368 2016-07-07 19:57:03	0|btcdrak|looks like it's working agian
369 2016-07-07 19:57:24	0|jonasschnelli|gmaxwell: re https://people.xiph.org/~greg/auth0.txt, can the client fingerprint the serve by just getting a 64byte compact ECsig?
370 2016-07-07 19:57:27	0|wumpus|sdaftuar: agree with leaving it untranslated
371 2016-07-07 19:57:28	0|jonasschnelli|*server
372 2016-07-07 19:57:35	0|sdaftuar|wumpus: ok thanks!
373 2016-07-07 19:57:37	0|gmaxwell|jonasschnelli: Not unless it knows the public key.
374 2016-07-07 19:58:05	0|jonasschnelli|I just try to find a/the concrete reason for the believed_server_pubkey in H(session_id || "1" || believed_server_pubkey)
375 2016-07-07 19:58:10	0|gmaxwell|jonasschnelli: If the server has no match for X1 the protocol is just filled with padding at that point.
376 2016-07-07 19:58:40	0|jonasschnelli|How could the client fingerprint when believed_server_pubkey would not be there?
377 2016-07-07 19:58:42	0|wumpus|sdaftuar: I think some of the InitWarnings are translated, but anyhow, nothing new is going to get translated for 0.13.0
378 2016-07-07 19:58:44	0|gmaxwell|jonasschnelli: As I said, it prevent fingerprinting.  The server does not learn what public key the client is expecting; the client cannot learn what public key the server is using (unless it already knows it)
379 2016-07-07 19:59:28	0|wumpus|sdaftuar: and it's going to be a rare message for people to see, so even otherwise probably a waste of translators time :)
380 2016-07-07 19:59:33	0|gmaxwell|jonasschnelli: if that was not there the client would send the AUTHCHALLENGE and the server would reply with a signature in the AUTHREPLY, which the public key can be extracted from.
381 2016-07-07 19:59:55	0|sdaftuar|wumpus: makes sense to me, just wasn't sure if we were allowed to put untranslated strings into things that might hit the gui
382 2016-07-07 20:00:05	0|jonasschnelli|gmaxwell: ah... even for standard compact normalized signatures?
383 2016-07-07 20:00:08	0|sdaftuar|versus doign a LogPrint() or something
384 2016-07-07 20:01:35	0|jonasschnelli|gmaxwell: I thought in order to do this, it would require a recoverable signature (something like libsecp256k1s secp256k1_ecdsa_recoverable_signature_serialize_compact)
385 2016-07-07 20:02:51	0|wumpus|sdaftuar: normally would prefer not, but for (detailed) errors can make an exception - not translating them makes them easier to google, for example, and very technical things tend to get translated badly
386 2016-07-07 20:02:54	0|gmaxwell|jonasschnelli: no, without the extra data you just have two possibilties (well 4 with very very low probablity), so no resistance to fingerprinting at all.
387 2016-07-07 20:11:17	0|gmaxwell|jonasschnelli: Does it make sense now?
388 2016-07-07 20:16:10	0|jonasschnelli|gmaxwell: Okay. Got it. Thanks for the patience to explain.
389 2016-07-07 20:27:11	0|bsm117532|Maybe I'm missing something...why does BIP 144 not define this transaction format as nVersion=2?
390 2016-07-07 20:27:44	0|sipa|because it does not add anything
391 2016-07-07 20:27:56	0|sipa|nVersion is part of the transaction data
392 2016-07-07 20:28:03	0|sipa|so you can't modify it upon relay
393 2016-07-07 20:28:28	0|sipa|bip144 adds an extra serialization flag that is not hashed into the txid
394 2016-07-07 20:29:03	0|gmaxwell|jonasschnelli: no problem.
395 2016-07-07 20:29:47	0|bsm117532|So I've got python-bitcoinlib serializing and deserializing according to what I read in BIP 144, but decoderawtransaction doesn't like my serialization.  Does anyone have a moment to take a look at this thing and tell me what I've done wrong?
396 2016-07-07 20:29:50	0|bsm117532|01000000000101ca3cd3084fee7a0a4746f7b41ce65c6f0778b6643515d4ad07798ee70a374b470000000016001486553e1ea2d97539d116fe878b2d3c69f6eb4faaffffffff01a01cc10767ffffff160014963f8e056d9aff20bc8ae5a0126e33ea9b2e399d6b483045022100b664937800fd386e936ac4b340d86c1417e5257ec9308879b96a2a9761a7c8ec022056f25e9e898968c0acf97fec8a0f501af9b0c19a9bcfc3cbd95c75d32c9895870121036efd8cc9de281efe42ef653c4abbb9459024e336cc4fe56622e68c6aa2574e1800000000
397 2016-07-07 20:30:01	0|bsm117532|CTransaction([CTxIn(COutPoint(lx('474b370ae78e7907add4153564b678076f5ce61cb4f746470a7aee4f08d33cca'), 0), CScript([x(''), x('86553e1ea2d97539d116fe878b2d3c69f6eb4faa')]), 0xffffffff)], [CTxOut(-656999900000, CScript([x(''), x('963f8e056d9aff20bc8ae5a0126e33ea9b2e399d')]))], 0, 1, CScript([x('3045022100b664937800fd386e936ac4b340d86c1417e5257ec9308879b96a2a9761a7c8ec022056f25e9e898968c0acf97fec8a0f501af9b0c19a9bcfc3cbd95c75d32c98958701'), x('036e
398 2016-07-07 20:31:00	0|sipa|message cut off
399 2016-07-07 20:31:05	0|sipa|can you paste it somewhere?
400 2016-07-07 20:31:17	0|bsm117532|Sure
401 2016-07-07 20:32:49	0|bsm117532|https://www.zerobin.net/?5f1a8550abf9f104#t/ID9UEgNXlzp7m3Vr31/Vvz7I5GwWfnNMGqF7Rkbg0=
402 2016-07-07 20:33:36	0|bsm117532|Hmmm that output is clearly borked.
403 2016-07-07 20:35:09	0|bsm117532|Would bitcoin-cli decoderawtransaction abort due to the negative output there?  That might be my problem...
404 2016-07-07 20:37:24	0|bsm117532|Decoderawtransaction still doesn't like it after making that output positive: https://www.zerobin.net/?afb35cd1b41acb5e#EXgtfGe6+ZRZinaximJV0ptmxbqNDqF4nI71HDF3/I8=
405 2016-07-07 22:00:01	0|sipa|bsm117532: negative output?
406 2016-07-07 22:00:31	0|bsm117532|I fixed that, it wasn't the problem.
407 2016-07-07 22:01:57	0|bsm117532|So, my input script isn't empty, it's OP_0 <hashed pubkey> as BIP 141 says.  But in your test vectors in BIP 143, the input script for P2WPKH is empty.
408 2016-07-07 22:03:56	0|sipa|OP_0 <hashed pubkey> goes into the output
409 2016-07-07 22:04:09	0|sipa|the scriptSig spending segwit outouts is always empty
410 2016-07-07 22:04:15	0|bsm117532|I'm also missing the array length in the witness.
411 2016-07-07 22:04:15	0|sipa|unless it's P2SH
412 2016-07-07 22:04:20	0|bsm117532|Ok, gotcha