1 2016-07-07T00:01:44  <luke-jr> cfields: kicked it
  2 2016-07-07T00:02:25  <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-07T00:02:31  <luke-jr> phantomcircuit: no, I agree
  4 2016-07-07T00:02:41  <luke-jr> cfields: heh
  5 2016-07-07T00:07:04  <GitHub83> [bitcoin] mcelrath opened pull request #8311: Rename CTxinWitness -> CTxInWitness (master...CTxInWitness) https://github.com/bitcoin/bitcoin/pull/8311
  6 2016-07-07T00:07:21  <bsm117532> dumb patch of the day...
  7 2016-07-07T00:08:32  <sipa> hah
  8 2016-07-07T00:31:58  <luke-jr> cfields: looks like a success :D
  9 2016-07-07T00:32:55  <cfields> luke-jr: woohoo
 10 2016-07-07T00:33:44  <cfields> luke-jr: for future reference, when behind cloudflare, apache needs mod_cloudflare, otherwise incoming ips are actually cloudflare proxy ips
 11 2016-07-07T00:33:49  <cfields> who knew
 12 2016-07-07T00:33:51  <luke-jr> XD
 13 2016-07-07T00:34:08  <luke-jr> cfields: btw, can you set someone else up with access to raise our bus factor?
 14 2016-07-07T00:34:51  <cfields> luke-jr: sure, i think there are several though
 15 2016-07-07T00:35:11  <luke-jr> eh?
 16 2016-07-07T00:35:18  <cfields> i believe wumpus/btcdrak/bluematt have access
 17 2016-07-07T00:35:36  <luke-jr> wumpus said he didn't, and the other two didn't speak up IIRC
 18 2016-07-07T00:35:55  <cfields> oh, hmm. ok, will check
 19 2016-07-07T00:36:57  <cfields> there was an issue with dns after the move, maybe they're missing the new info
 20 2016-07-07T00:37:50  <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-07T00:38:41  <sipa> maybe wumpus has access but does not know it :)
 22 2016-07-07T00:39:07  <luke-jr> heh
 23 2016-07-07T00:41:43  <cfields> i think that's probably the case. i thought i lost access until btcdrak figured out the dns weirdness
 24 2016-07-07T00:41:44  *** fengling__ has joined #bitcoin-core-dev
 25 2016-07-07T00:46:26  *** fengling__ has quit IRC
 26 2016-07-07T00:50:28  <phantomcircuit> cfields, he's going to run you over with a bus, quick run away!
 27 2016-07-07T00:58:17  <luke-jr> …
 28 2016-07-07T01:00:48  <cfields> heh
 29 2016-07-07T01:15:49  *** JackH has quit IRC
 30 2016-07-07T01:18:47  *** fengling__ has joined #bitcoin-core-dev
 31 2016-07-07T01:25:43  *** Ylbam has quit IRC
 32 2016-07-07T01:38:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 33 2016-07-07T01:48:40  <GitHub152> [bitcoin] sdaftuar opened pull request #8312: Fix mempool DoS vulnerability from malleated transactions (master...mempool-malleability) https://github.com/bitcoin/bitcoin/pull/8312
 34 2016-07-07T02:02:21  *** Chris_Stewart_5 has quit IRC
 35 2016-07-07T02:20:37  *** fengling__ is now known as fengling
 36 2016-07-07T02:58:39  *** sanada has quit IRC
 37 2016-07-07T02:58:49  *** sanada has joined #bitcoin-core-dev
 38 2016-07-07T03:00:28  *** eenoch has quit IRC
 39 2016-07-07T03:01:10  *** eenoch has joined #bitcoin-core-dev
 40 2016-07-07T03:18:04  *** zooko has quit IRC
 41 2016-07-07T03:40:40  *** bustd_soket has quit IRC
 42 2016-07-07T03:45:39  *** zooko has joined #bitcoin-core-dev
 43 2016-07-07T03:59:42  *** bustd_soket has joined #bitcoin-core-dev
 44 2016-07-07T04:10:31  *** Alopex has quit IRC
 45 2016-07-07T04:11:19  *** whphhg has quit IRC
 46 2016-07-07T04:11:37  *** Alopex has joined #bitcoin-core-dev
 47 2016-07-07T05:24:28  <wumpus> cfields: I don't think I ever received login details for the 'new' server, at least I don't remember
 48 2016-07-07T05:42:45  *** gabridome_ has joined #bitcoin-core-dev
 49 2016-07-07T05:43:42  *** gabridome_ has quit IRC
 50 2016-07-07T06:01:29  *** Ylbam has joined #bitcoin-core-dev
 51 2016-07-07T06:19:40  *** molz has joined #bitcoin-core-dev
 52 2016-07-07T06:21:17  *** molly has joined #bitcoin-core-dev
 53 2016-07-07T06:21:25  *** davec_ has quit IRC
 54 2016-07-07T06:21:51  *** davec has joined #bitcoin-core-dev
 55 2016-07-07T06:22:31  *** moli has quit IRC
 56 2016-07-07T06:24:13  *** molz has quit IRC
 57 2016-07-07T06:30:28  *** zooko has quit IRC
 58 2016-07-07T06:35:14  *** JackH has joined #bitcoin-core-dev
 59 2016-07-07T06:41:24  <jonasschnelli> Ping MarcoFalke
 60 2016-07-07T06:41:45  <jonasschnelli> I don't see how you could lost coins with the new HD feature...
 61 2016-07-07T06:41:56  <jonasschnelli> *lose coins
 62 2016-07-07T06:45:26  <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
 63 2016-07-07T06:45:50  <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
 64 2016-07-07T06:48:04  <wumpus> (well, not the importing-back the seed part, but at least it gives a way to export the seed)
 65 2016-07-07T06:48:25  <wumpus> handling that properly will be more complex, as then the wallet would have multiple master keys
 66 2016-07-07T06:48:50  <wumpus> (so which one to use for generating new addresses? it seems to even need an API change)
 67 2016-07-07T06:49:37  <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
 68 2016-07-07T06:53:35  *** MarcoFalke has joined #bitcoin-core-dev
 69 2016-07-07T06:55:31  *** davidlj95 has quit IRC
 70 2016-07-07T06:58:16  <MarcoFalke> jonasschnelli: I was trying to do an actual backup. Not just dumpwallet
 71 2016-07-07T06:58:38  <MarcoFalke> See the HD test: https://github.com/bitcoin/bitcoin/pull/8309
 72 2016-07-07T06:59:57  <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.
 73 2016-07-07T07:00:33  <MarcoFalke> the wallet.dat should contain the HD master key, thus I am able to derive all addresses and collect my coins.
 74 2016-07-07T07:00:42  <MarcoFalke> So why does it fail?
 75 2016-07-07T07:09:28  <jonasschnelli> MarcoFalke: the current HD feature will not auto-recover funds/keys you have created after the backup...
 76 2016-07-07T07:09:34  <jonasschnelli> Did you ran into this issue?
 77 2016-07-07T07:09:41  <MarcoFalke> nope
 78 2016-07-07T07:09:48  *** Amnez777 has quit IRC
 79 2016-07-07T07:09:56  <jonasschnelli> If you copy back your wallet.dat, it should be the same as it was before...
 80 2016-07-07T07:10:24  <MarcoFalke> https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR65
 81 2016-07-07T07:10:35  <MarcoFalke> This derives all the keys
 82 2016-07-07T07:10:39  <MarcoFalke> (again)
 83 2016-07-07T07:11:10  <MarcoFalke> Then asserts that the last derived key is identical to the last derived key of the first run
 84 2016-07-07T07:11:21  <MarcoFalke> But somehow it does not update the balance
 85 2016-07-07T07:11:44  <jonasschnelli> hmm...
 86 2016-07-07T07:11:59  *** Amnez777 has joined #bitcoin-core-dev
 87 2016-07-07T07:12:34  <jonasschnelli> MarcoFalke: if you call getnewaddress, you get the same address but not the received coins to this address, right?
 88 2016-07-07T07:12:53  <jonasschnelli> I guess it requires a rescan (after getnewaddress)
 89 2016-07-07T07:12:54  <MarcoFalke> jup
 90 2016-07-07T07:13:11  <MarcoFalke> I tried rescan and reindex
 91 2016-07-07T07:13:22  <jonasschnelli> reindex should not be necessary... rescan works?
 92 2016-07-07T07:13:27  <MarcoFalke> no
 93 2016-07-07T07:14:35  *** whphhg has joined #bitcoin-core-dev
 94 2016-07-07T07:14:42  <jonasschnelli> let me test it locally... thanks for testing / writing the test!
 95 2016-07-07T07:15:02  <jonasschnelli> I knew that the backup restore is not something users can easily do.
 96 2016-07-07T07:15:25  <MarcoFalke> Correct, but there should be some way to do it
 97 2016-07-07T07:15:28  <jonasschnelli> Not sure if we should have something more convenient (backup restore) for 0.13
 98 2016-07-07T07:15:34  <jonasschnelli> Yes.
 99 2016-07-07T07:15:42  <jonasschnelli> Maybe we discuss this tonight at the IRC meeting
100 2016-07-07T07:16:16  <MarcoFalke> oh
101 2016-07-07T07:16:18  <MarcoFalke> I got it
102 2016-07-07T07:16:37  <MarcoFalke> importprivkey breaks all future backups
103 2016-07-07T07:16:42  <MarcoFalke> :(
104 2016-07-07T07:16:51  <MarcoFalke> This should be fixed I assume
105 2016-07-07T07:17:08  <MarcoFalke> Maybe a small fix in the rescan logic
106 2016-07-07T07:17:23  <jonasschnelli> What's the reason for this?
107 2016-07-07T07:17:27  <MarcoFalke> no idea
108 2016-07-07T07:17:38  <jonasschnelli> Why does it breaks all future backups?
109 2016-07-07T07:17:44  <jonasschnelli> *break
110 2016-07-07T07:18:10  <MarcoFalke> Maybe only legacy keys are rescanned when there is at least one?
111 2016-07-07T07:18:42  <MarcoFalke> Need to look into the code...
112 2016-07-07T07:19:26  <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
113 2016-07-07T07:19:35  <jonasschnelli> Thanks for looking into the code
114 2016-07-07T07:20:36  <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
115 2016-07-07T07:25:19  *** davidlj95 has joined #bitcoin-core-dev
116 2016-07-07T07:32:27  <MarcoFalke> More likely it is just a getbalance issue. I remember there were "some" issues lately
117 2016-07-07T07:37:17  *** rubensayshi has joined #bitcoin-core-dev
118 2016-07-07T07:43:40  *** rubensayshi has quit IRC
119 2016-07-07T07:45:04  *** moli has joined #bitcoin-core-dev
120 2016-07-07T07:46:15  *** molly has quit IRC
121 2016-07-07T07:53:26  *** fengling has quit IRC
122 2016-07-07T07:58:06  *** rubensayshi has joined #bitcoin-core-dev
123 2016-07-07T08:00:21  *** fengling has joined #bitcoin-core-dev
124 2016-07-07T08:08:34  *** Evel-Knievel has quit IRC
125 2016-07-07T08:09:02  *** Evel-Knievel has joined #bitcoin-core-dev
126 2016-07-07T08:38:17  *** kadoban has quit IRC
127 2016-07-07T08:40:26  *** fengling has quit IRC
128 2016-07-07T08:51:36  *** davidlj95 has quit IRC
129 2016-07-07T08:53:12  *** davidlj95 has joined #bitcoin-core-dev
130 2016-07-07T08:53:58  *** fengling has joined #bitcoin-core-dev
131 2016-07-07T09:10:47  *** AaronvanW has quit IRC
132 2016-07-07T09:13:54  *** AaronvanW has joined #bitcoin-core-dev
133 2016-07-07T09:17:15  *** moli has quit IRC
134 2016-07-07T09:17:44  *** moli has joined #bitcoin-core-dev
135 2016-07-07T09:38:54  <wumpus> what's wrong with getbalance?
136 2016-07-07T09:42:17  *** Guyver2 has joined #bitcoin-core-dev
137 2016-07-07T09:56:38  *** davidlj95 has quit IRC
138 2016-07-07T10:08:34  *** Justinus has quit IRC
139 2016-07-07T10:39:06  *** fengling has quit IRC
140 2016-07-07T10:45:34  *** fengling has joined #bitcoin-core-dev
141 2016-07-07T10:48:52  *** davidlj95 has joined #bitcoin-core-dev
142 2016-07-07T10:52:01  *** jannes has joined #bitcoin-core-dev
143 2016-07-07T11:25:46  *** fengling has quit IRC
144 2016-07-07T11:32:07  *** laurentmt has joined #bitcoin-core-dev
145 2016-07-07T11:50:32  *** laurentmt has quit IRC
146 2016-07-07T12:22:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
147 2016-07-07T12:22:59  *** fengling has joined #bitcoin-core-dev
148 2016-07-07T12:52:26  *** fengling has quit IRC
149 2016-07-07T13:03:40  *** murch has joined #bitcoin-core-dev
150 2016-07-07T13:33:57  *** rubensayshi has quit IRC
151 2016-07-07T13:49:42  *** fengling has joined #bitcoin-core-dev
152 2016-07-07T13:54:21  *** rubensayshi has joined #bitcoin-core-dev
153 2016-07-07T13:54:26  *** fengling has quit IRC
154 2016-07-07T14:17:12  *** rubensayshi has quit IRC
155 2016-07-07T14:23:31  *** afk11 has quit IRC
156 2016-07-07T14:33:01  *** rubensayshi has joined #bitcoin-core-dev
157 2016-07-07T14:51:13  *** fengling has joined #bitcoin-core-dev
158 2016-07-07T14:56:06  *** fengling has quit IRC
159 2016-07-07T15:16:04  *** Chris_Stewart_5 has quit IRC
160 2016-07-07T15:29:20  <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...
161 2016-07-07T15:29:54  <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
162 2016-07-07T15:30:02  <jonasschnelli> Seems to work...
163 2016-07-07T15:30:20  <jonasschnelli> Maybe need to check in conjunction with importprivkey...
164 2016-07-07T15:31:17  *** zooko has joined #bitcoin-core-dev
165 2016-07-07T15:31:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
166 2016-07-07T15:43:20  <GitHub155> [bitcoin] yurizhykin opened pull request #8313: Use std::move() instead of copying/removing in TxMemPool (master...tx-delete) https://github.com/bitcoin/bitcoin/pull/8313
167 2016-07-07T15:52:53  *** fengling has joined #bitcoin-core-dev
168 2016-07-07T15:54:05  *** afk11 has joined #bitcoin-core-dev
169 2016-07-07T15:54:05  *** afk11 has quit IRC
170 2016-07-07T15:54:05  *** afk11 has joined #bitcoin-core-dev
171 2016-07-07T15:57:46  *** fengling has quit IRC
172 2016-07-07T16:05:01  *** rubensayshi has quit IRC
173 2016-07-07T16:21:24  *** spudowiar has joined #bitcoin-core-dev
174 2016-07-07T17:05:47  *** zooko has quit IRC
175 2016-07-07T17:28:17  *** zooko has joined #bitcoin-core-dev
176 2016-07-07T17:55:53  *** fengling has joined #bitcoin-core-dev
177 2016-07-07T17:56:31  <MarcoFalke> IsMine returns false for the txs involving the HD keys
178 2016-07-07T17:57:05  <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
179 2016-07-07T17:57:32  <zooko> We'll put in the time to merge it if desired.
180 2016-07-07T17:58:13  <gmaxwell> cfields: ^
181 2016-07-07T17:58:15  *** jannes has quit IRC
182 2016-07-07T17:58:16  <zooko> I've asked Zcash engineer Taylor "earthrise" Hornby to support you on that if you want it.
183 2016-07-07T17:58:45  <zooko> The _other_ one that I mentioned a few days back turned out to have a bug — we were
184 2016-07-07T17:58:53  <cfields> zooko / gmaxwell: thanks
185 2016-07-07T17:59:06  <zooko> trying to measure time to validate a block packed full of worst-case quadratic signature.
186 2016-07-07T17:59:18  <zooko> And we were accidentally measuring time to check that the signature was already cached. ;-)
187 2016-07-07T17:59:26  <zooko> But we've fixed that, and now we have some results.
188 2016-07-07T18:00:09  <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
189 2016-07-07T18:00:15  <zooko> 35s for 1 MB block, 140s for 2 MB block
190 2016-07-07T18:00:46  *** fengling has quit IRC
191 2016-07-07T18:01:23  <cfields> zooko: hmm, i believe we already do those checks
192 2016-07-07T18:01:53  <cfields> we might not verify FORTIFY_SOURCE, though
193 2016-07-07T18:04:01  <cfields> zooko: mind pointing Taylor to "make check-security"? If there's a check we're missing, we would certainly add it
194 2016-07-07T18:10:16  * michagogo watches a reindex fly by on his new Sandisk X400
195 2016-07-07T18:11:50  * bsm117532 struts out his two RAID0 Samsung 950 Pros...for the reindex... ;-)
196 2016-07-07T18:12:31  <michagogo> Heh, nice
197 2016-07-07T18:13:08  <michagogo> Up to block 216k after about 40 minutes
198 2016-07-07T18:18:56  <bsm117532> Yeah my reindex is CPU bound.
199 2016-07-07T18:22:36  <gmaxwell> OT, but of interest: http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
200 2016-07-07T18:33:09  *** spudowiar has quit IRC
201 2016-07-07T18:39:46  <GitHub148> [bitcoin] theuni opened pull request #8314: Fix pkg-config issues for 0.13 (master...fix-pkg-config) https://github.com/bitcoin/bitcoin/pull/8314
202 2016-07-07T18:41:54  *** zooko has quit IRC
203 2016-07-07T18:45:24  <GitHub155> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/91abb77970f4...0cca2feb357a
204 2016-07-07T18:45:24  <GitHub155> bitcoin/master fa6ad56 MarcoFalke: [travis] Update SDK_URL
205 2016-07-07T18:45:25  <GitHub155> bitcoin/master 0cca2fe Jonas Schnelli: Merge #8304: [travis] Update SDK_URL...
206 2016-07-07T18:45:34  <GitHub94> [bitcoin] jonasschnelli closed pull request #8304: [travis] Update SDK_URL (master...Mf1606-travisSDKURL) https://github.com/bitcoin/bitcoin/pull/8304
207 2016-07-07T18:46:36  <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?
208 2016-07-07T18:46:52  <sipa> i have not looked into HKDF, but we should
209 2016-07-07T18:47:16  <jonasschnelli> RFC: https://tools.ietf.org/html/rfc5869
210 2016-07-07T18:49:23  <jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
211 2016-07-07T18:54:01  *** zooko has joined #bitcoin-core-dev
212 2016-07-07T18:55:11  <zooko> cfields: done: https://github.com/zcash/zcash/issues/1071
213 2016-07-07T18:57:23  *** fengling has joined #bitcoin-core-dev
214 2016-07-07T18:58:15  <jonasschnelli> gmaxwell: https://people.xiph.org/~greg/auth0.txt, why does AUTHCHALLENGE require "believed_server_pubkey"?
215 2016-07-07T18:59:15  <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.
216 2016-07-07T18:59:33  <btcdrak> meeting time?
217 2016-07-07T18:59:39  <jonasschnelli> yes
218 2016-07-07T18:59:40  <petertodd> yup
219 2016-07-07T18:59:57  <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
220 2016-07-07T19:00:10  <wumpus> #startmeeting
221 2016-07-07T19:00:10  <lightningbot> Meeting started Thu Jul  7 19:00:10 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
222 2016-07-07T19:00:10  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
223 2016-07-07T19:00:13  <cfields> gmaxwell: thanks. here.
224 2016-07-07T19:00:16  <sdaftuar> hi
225 2016-07-07T19:00:28  <gmaxwell> Welcome to meeting.
226 2016-07-07T19:00:39  *** instagibbs2 has joined #bitcoin-core-dev
227 2016-07-07T19:00:43  <wumpus> proposed topic: 0.13.0rc1
228 2016-07-07T19:00:51  <petertodd> wumpus: ack
229 2016-07-07T19:00:56  <gmaxwell> This week was a week of many reverts. Reverting will continue until morale improves.
230 2016-07-07T19:01:01  <michagogo> Hi
231 2016-07-07T19:01:03  <wumpus> #topic 0.13.0rc1
232 2016-07-07T19:01:13  <sipa> somewhat present
233 2016-07-07T19:01:19  <jonasschnelli> Are we +1 day with the 0.13 splitoff?
234 2016-07-07T19:01:19  <wumpus> foremost, I cannot build a release at this moment, as gitian lxc building is broken
235 2016-07-07T19:01:21  <sdaftuar> wumpus: so there are a couple bugs that still need to be fixed for 0.13
236 2016-07-07T19:01:21  <MarcoFalke> Is the HD issue a blocker for the rc?
237 2016-07-07T19:01:37  <wumpus> https://github.com/bitcoin/bitcoin/issues/8212 / https://github.com/bitcoin/bitcoin/pull/8213
238 2016-07-07T19:01:50  <cfields> wumpus: ok. I'll handle those next.
239 2016-07-07T19:01:53  <wumpus> MarcoFalke: which HD issue?
240 2016-07-07T19:02:02  <MarcoFalke> I couldn't restore from a HD backup
241 2016-07-07T19:02:03  <jonasschnelli> I think there is no "real" HD issue
242 2016-07-07T19:02:06  *** fengling has quit IRC
243 2016-07-07T19:02:07  <michagogo> wumpus: Broken in what way?
244 2016-07-07T19:02:16  <wumpus> michagogo: please read the issues
245 2016-07-07T19:02:17  <MarcoFalke> jonasschnelli: Could you look into the travis failure
246 2016-07-07T19:02:19  <MarcoFalke> ?
247 2016-07-07T19:02:23  <jonasschnelli> Yes. Will do..
248 2016-07-07T19:02:24  <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.
249 2016-07-07T19:02:28  <michagogo> (Sorry, I've not had much free time for this stuff in the past months)
250 2016-07-07T19:02:35  * michagogo goes to check
251 2016-07-07T19:02:40  <wumpus> if HD is broken, we have to disable  it for 0.13
252 2016-07-07T19:02:47  <michagogo> (Gitian issues or Bitcoin Core?)
253 2016-07-07T19:02:53  <wumpus> or at least rc1
254 2016-07-07T19:02:57  <MarcoFalke> gmaxwell: You can see the issue on travis
255 2016-07-07T19:02:57  <jonasschnelli> Sure. Let me check MarcoFalke HD test
256 2016-07-07T19:03:06  <MarcoFalke> It is either an error in my test code
257 2016-07-07T19:03:06  <gmaxwell> Disabling it indeed would be an option.
258 2016-07-07T19:03:15  <MarcoFalke> or some issue with IsMine() or something else
259 2016-07-07T19:03:27  <gmaxwell> This may be a current design limitation if my understanding is correct. But I'm happy to discuss elsewhere/elsetime.
260 2016-07-07T19:03:33  <MarcoFalke> I'd rather fix it than disable it
261 2016-07-07T19:03:40  <cfields> MarcoFalke: link to travis failure?
262 2016-07-07T19:03:42  <wumpus> I don't want to block rc1 too long
263 2016-07-07T19:03:45  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
264 2016-07-07T19:03:52  <wumpus> rather have a test release out as soon as possible
265 2016-07-07T19:03:54  <btcdrak> remaining issue/prs for 0.13 https://github.com/bitcoin/bitcoin/milestones/0.13.0
266 2016-07-07T19:04:02  <MarcoFalke> pull 8309
267 2016-07-07T19:04:06  <MarcoFalke> cfields: ^
268 2016-07-07T19:04:11  <gmaxwell> lets talk about the other things then move on to the hd issue as it's own topic.
269 2016-07-07T19:04:12  <cfields> thanks
270 2016-07-07T19:04:30  <wumpus> planning was to do rc1 yesterday, but it was clear it wasn't possible
271 2016-07-07T19:04:46  <wumpus> btcdrak: some things can be merged as-is I think
272 2016-07-07T19:04:52  <MarcoFalke> Also there are some issues open by sdaftuar
273 2016-07-07T19:05:00  <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
274 2016-07-07T19:05:28  <wumpus> #7678 (release notes) is a TODO for -final, not rc1, could use some help there though
275 2016-07-07T19:06:13  <wumpus> are they ready for merge?
276 2016-07-07T19:06:15  <btcdrak> sdaftuar those should be tagged with the milestone then
277 2016-07-07T19:06:27  <sipa> i will write some release notes for the tx relay changes
278 2016-07-07T19:06:35  <sipa> (but not now)
279 2016-07-07T19:06:48  <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
280 2016-07-07T19:06:50  <wumpus> right, release notes is not urgent now, just needs to be done before final
281 2016-07-07T19:06:54  <wumpus> let's worry about rc1 now
282 2016-07-07T19:07:12  <sdaftuar> #8305 and #8295 are done as far as i know
283 2016-07-07T19:07:17  <sdaftuar> (no review though)
284 2016-07-07T19:07:32  <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
285 2016-07-07T19:08:19  <gmaxwell> I've been very busy with testing, in fact.
286 2016-07-07T19:08:38  <wumpus> testing is good
287 2016-07-07T19:08:47  <wumpus> releasing rc1 will result in a lot of testing, too
288 2016-07-07T19:09:16  <sipa> wumpus: i was less active the past week; i'll be back tomorrow
289 2016-07-07T19:10:31  <wumpus> ok I see jonasschnelli already added 0.13 milestone to sdaftuar's pulls, thanks
290 2016-07-07T19:10:35  <jonasschnelli> Yes.
291 2016-07-07T19:10:42  <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
292 2016-07-07T19:11:43  <petertodd> i'll try to look at 8312 this weekend
293 2016-07-07T19:11:44  <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
294 2016-07-07T19:12:40  <cfields> wumpus: i can look into a quick-hack work-around for rc1. but iirc, it's hard to avoid until ubuntu fixes
295 2016-07-07T19:13:34  <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
296 2016-07-07T19:13:48  <cfields> wumpus: quick alternative would bt c/p the descriptor to linux-arm.yml for now
297 2016-07-07T19:14:00  <gmaxwell> will we be able to distribute arm linux binaries for 0.13?
298 2016-07-07T19:14:23  <wumpus> gmaxwell: yes, that was done, but it has added an awkward requirement to the gitian build descriptor
299 2016-07-07T19:14:24  <jonasschnelli> yes
300 2016-07-07T19:15:31  <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.
301 2016-07-07T19:15:34  <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)
302 2016-07-07T19:16:46  <petertodd> wumpus: ack
303 2016-07-07T19:17:12  <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 :)
304 2016-07-07T19:17:53  <cfields> ok
305 2016-07-07T19:18:08  <wumpus> #action wumpus contact devrandom about https://github.com/devrandom/gitian-builder/pull/123
306 2016-07-07T19:18:12  <achow101> what about segwit deployment parameters
307 2016-07-07T19:18:23  <btcdrak> achow101: not for 0.13.0
308 2016-07-07T19:18:42  <wumpus> we could add that as proposed topic, but not relevant for 0.13
309 2016-07-07T19:19:06  <sipa> achow101: first backport to 0.12, figuring out cb+segwit, and planning releases
310 2016-07-07T19:19:08  <btcdrak> achow101: it's explained in https://bitcoincore.org/en/lifecycle/#consensus-rules
311 2016-07-07T19:19:11  <MarcoFalke> #action Help with review on https://github.com/bitcoin/bitcoin/milestone/20
312 2016-07-07T19:19:17  <wumpus> we're done with this topic though so i'm ok with switching
313 2016-07-07T19:20:14  <gmaxwell> Okay can we talk briefly about the HD wallet thing?
314 2016-07-07T19:20:20  <wumpus> #topic HD wallet issue
315 2016-07-07T19:20:43  <sipa> what is the hd wallet issue number?
316 2016-07-07T19:20:56  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
317 2016-07-07T19:21:00  <jonasschnelli> Its a PR (failing test)
318 2016-07-07T19:21:29  <jonasschnelli> currently looking at it.
319 2016-07-07T19:21:31  <MarcoFalke> The rpc-test is pretty simple: usehd=1, then backup wallet.dat
320 2016-07-07T19:21:35  <jonasschnelli> The addresses are re-generated deterministic... but somehow reindex fails..
321 2016-07-07T19:21:36  <MarcoFalke> Do some transactions and discard wallet.dat
322 2016-07-07T19:21:36  <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.
323 2016-07-07T19:21:39  <gmaxwell> But I could misunderstand.
324 2016-07-07T19:22:07  <jonasschnelli> Yes. The simples HD feature does not cover restores...
325 2016-07-07T19:22:17  <MarcoFalke> I am running rescan and reindex. None of it fixes it
326 2016-07-07T19:22:18  <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.
327 2016-07-07T19:22:20  <jonasschnelli> Restore is manual work (including a rescan)
328 2016-07-07T19:22:36  <gmaxwell> if a rescan isn't fixing it, thats a more serious issue than I was thinking.
329 2016-07-07T19:23:01  <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)
330 2016-07-07T19:23:02  <jonasschnelli> Yes... I currently trying to find out why MarcoFalke test fails even after a rescan.
331 2016-07-07T19:23:20  <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.
332 2016-07-07T19:23:21  <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?
333 2016-07-07T19:23:25  <jonasschnelli> But IMO it's unrelated to HD,... the keys are recreated.
334 2016-07-07T19:23:49  <wumpus> yes, I think this scary, I don't think this is ready for a release
335 2016-07-07T19:23:52  <gmaxwell> wumpus: it's the same keys every time, no defeating.
336 2016-07-07T19:23:56  <jonasschnelli> Sure. Let me first try to find the root cause before we consider a revert
337 2016-07-07T19:24:16  <MarcoFalke> agree
338 2016-07-07T19:24:18  <wumpus> rever wouldn't be necessary, just default the flag to false
339 2016-07-07T19:24:46  <wumpus> it defaults to true for new wallets now which is what makes it scary if it would be somehow broken
340 2016-07-07T19:24:47  <jonasschnelli> Sure. But we probably don't want to ship a (per default disabled) feature which _could_ includes bugs. :)
341 2016-07-07T19:24:47  <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.
342 2016-07-07T19:24:56  <petertodd> wumpus: is the flag documented in --help?
343 2016-07-07T19:25:34  <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.
344 2016-07-07T19:25:39  <jonasschnelli> MarcoFalke: have you tried the test with HD disabled (just import your created keys)?
345 2016-07-07T19:25:55  <gmaxwell> I haven't looked at it yet myself except passively watching the discussion.
346 2016-07-07T19:25:59  <sipa> likewise
347 2016-07-07T19:26:04  <sipa> i will look soon
348 2016-07-07T19:26:04  <MarcoFalke> no
349 2016-07-07T19:26:20  <jonasschnelli> I think without knowing the root cause of the problem actions are useless.
350 2016-07-07T19:26:33  <wumpus> agreed
351 2016-07-07T19:26:40  <sipa> agree; we need to understand it
352 2016-07-07T19:26:41  <jonasschnelli> I will know more about it in a couple of hours.
353 2016-07-07T19:26:47  <sipa> and i believe there is plenty of time for that
354 2016-07-07T19:27:08  <wumpus> before when?
355 2016-07-07T19:27:11  <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.
356 2016-07-07T19:27:27  <wumpus> yes, need to disable it completely then, I agree
357 2016-07-07T19:27:41  <jonasschnelli> Yes. But it could also be a serious import/rescan issue (not related to HD)
358 2016-07-07T19:28:09  <wumpus> the non-HD rescan test passes, right?
359 2016-07-07T19:28:19  <MarcoFalke> yes
360 2016-07-07T19:28:23  <sipa> i believe that rpc test is less elaborate
361 2016-07-07T19:28:47  <wumpus> did you try your new test without HD MarcoFalke?
362 2016-07-07T19:28:50  <jonasschnelli> I think we would need the same test (that fails) without HD
363 2016-07-07T19:29:18  <MarcoFalke> You can't create keys deterministically without HD
364 2016-07-07T19:29:33  <jonasschnelli> I can see the exact keys in the wallet after the restore but I can see rescan failing to reconstruct the wtxs.
365 2016-07-07T19:29:37  <sipa> no need to discuss the details here
366 2016-07-07T19:29:43  <wumpus> oh sure, you can't do exactly the dsame thing
367 2016-07-07T19:29:44  <jonasschnelli> MarcoFalke: you could create 100 keys and reimport them...
368 2016-07-07T19:30:05  <jonasschnelli> anyways,... I'll have a look at it and will report on the PR
369 2016-07-07T19:30:07  <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.
370 2016-07-07T19:30:14  <jonasschnelli> ack
371 2016-07-07T19:30:15  <wumpus> right
372 2016-07-07T19:30:19  <wumpus> any other topics?
373 2016-07-07T19:31:07  <gmaxwell> Sure, an announcement:
374 2016-07-07T19:31:47  <sipa> *crickets*
375 2016-07-07T19:31:54  <jonasschnelli> oO
376 2016-07-07T19:32:20  * petertodd braces for an incoming text wall
377 2016-07-07T19:32:34  <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.
378 2016-07-07T19:32:44  <petertodd> +1
379 2016-07-07T19:32:58  <jonasschnelli> Saw this. Impressive work! Well done.
380 2016-07-07T19:33:01  <gmaxwell> (actually 98% of the time in the last day)
381 2016-07-07T19:33:11  <btcdrak> Also the FIBRE website is http://bitcoinfibre.org/
382 2016-07-07T19:33:14  <cfields> nice!
383 2016-07-07T19:33:17  <wumpus> awesome!
384 2016-07-07T19:33:23  <gmaxwell> And his deployment uses only cheap VPSes.
385 2016-07-07T19:33:38  <sipa> wow, i saw the website but hadn't appreciated how good the numbers were
386 2016-07-07T19:33:45  <sipa> i just looked at how oretty the graphs were
387 2016-07-07T19:33:54  <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. :)
388 2016-07-07T19:34:18  <sipa> we need neutrino-based transmissions.
389 2016-07-07T19:34:25  <petertodd> sipa: lol, I was just about to say
390 2016-07-07T19:34:34  <gmaxwell> Stats are at http://bitcoinrelaynetwork.org/stats_ng.html   there is also plety of room to improve the software/protocol still.
391 2016-07-07T19:34:37  <petertodd> sipa: reminds me, I wrote a short story about that awhile back...
392 2016-07-07T19:35:10  <wumpus> neutrono-based transmissions are easy, compared to the receiver part :)
393 2016-07-07T19:35:21  <btcdrak> The github project is at https://github.com/bitcoinfibre
394 2016-07-07T19:35:54  <petertodd> wumpus: what? don't you have a few tonnes of heavy water laying around?
395 2016-07-07T19:36:21  <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.
396 2016-07-07T19:36:26  <sipa> i believe production of heavy water may be more decentralized than sha256 asic mining production.
397 2016-07-07T19:37:00  <petertodd> sipa: yes! https://www.youtube.com/watch?v=Sxl78pWW8Vk
398 2016-07-07T19:38:18  <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. :(
399 2016-07-07T19:38:33  <wumpus> petertodd: of course I do, but not enough shielded undergorund space to put it
400 2016-07-07T19:39:20  <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.
401 2016-07-07T19:39:36  <petertodd> wumpus: that's why I took up caving
402 2016-07-07T19:39:40  *** anchow101 has joined #bitcoin-core-dev
403 2016-07-07T19:40:01  <cfields> gmaxwell: what's the reason for an additional binary?
404 2016-07-07T19:40:31  <cfields> gmaxwell: oh, you mean default to testnet until final release?
405 2016-07-07T19:40:31  <wumpus> gmaxwell: we could do that now, eg before the rc1
406 2016-07-07T19:40:47  <wumpus> well at least if I could build releases, dang
407 2016-07-07T19:40:51  <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.
408 2016-07-07T19:41:03  *** anchow101 has quit IRC
409 2016-07-07T19:41:18  <wumpus> cfields: not the rc1 itself, more like a master-build-with-only-testnet-enabled
410 2016-07-07T19:41:54  <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.
411 2016-07-07T19:41:54  <wumpus> rc1 should definitely have mainnet by default, like any rc
412 2016-07-07T19:42:26  *** kxie has joined #bitcoin-core-dev
413 2016-07-07T19:42:32  <wumpus> gmaxwell: did you see #8285? it's super-easy now for windows GUI users
414 2016-07-07T19:42:38  <cfields> hmm
415 2016-07-07T19:42:40  <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
416 2016-07-07T19:42:50  <petertodd> gmaxwell: I wonder if a wrapper script with -testnet would help those users?
417 2016-07-07T19:42:55  <gmaxwell> but perhaps thats too much for now. :)
418 2016-07-07T19:43:18  <wumpus> https://github.com/bitcoin/bitcoin/pull/8285 exactly does that
419 2016-07-07T19:43:22  <cfields> wumpus: ah nice, i missed that
420 2016-07-07T19:43:27  <gmaxwell> I didn't see it.
421 2016-07-07T19:43:36  <gmaxwell> (or forgot seeing it!)
422 2016-07-07T19:43:59  <petertodd> wumpus: ah cool, thanks!
423 2016-07-07T19:44:03  <gmaxwell> Thats really awesome.
424 2016-07-07T19:44:21  <petertodd> wumpus: just like mainnet/testnet wallets on my android phone
425 2016-07-07T19:44:49  <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.
426 2016-07-07T19:44:51  <wumpus> petertodd: indeed, bitcoin wallet for android has been doing a similar thing
427 2016-07-07T19:44:58  <gmaxwell> if you could do builds. :P
428 2016-07-07T19:46:16  <cfields> heh, hint taken. Working on the split descriptors now.
429 2016-07-07T19:47:29  <wumpus> thanks cfields
430 2016-07-07T19:47:34  <wumpus> any other topics?
431 2016-07-07T19:47:44  <petertodd> wumpus: happy halving day :
432 2016-07-07T19:47:45  <petertodd> )
433 2016-07-07T19:47:46  <petertodd> :)
434 2016-07-07T19:48:05  <wumpus> hah, same to you
435 2016-07-07T19:48:39  <gmaxwell> I wonder if there is some scifi where halving day is where half the people die? it seems right.
436 2016-07-07T19:48:41  <petertodd> wumpus: I'll be hiding in a cave most of that day fyi - so if the world ends don't call me :P
437 2016-07-07T19:49:04  <petertodd> gmaxwell: satoshi should have made it a 10% think, so we could call it DECIMATION DAY
438 2016-07-07T19:49:19  <petertodd> *thing
439 2016-07-07T19:49:30  <wumpus> petertodd: that sounds like a wise thing to do, hide in a cave until it blows over
440 2016-07-07T19:49:49  <sipa> i wish i had a cave here
441 2016-07-07T19:49:54  <sipa> i'm in the middle of paris
442 2016-07-07T19:50:00  <sipa> and there is some football thing
443 2016-07-07T19:50:16  <petertodd> sipa: you've got the most awesome sewer system, and the catacombs!
444 2016-07-07T19:50:18  <gmaxwell> sipa: catacombs.
445 2016-07-07T19:50:33  <sipa> catacombs close in 10 minutes.
446 2016-07-07T19:50:47  <petertodd> sipa: "officially" speaking...
447 2016-07-07T19:51:01  <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)
448 2016-07-07T19:51:08  <sipa> hah.
449 2016-07-07T19:51:11  <jonasschnelli> All light are green. :)
450 2016-07-07T19:51:12  <sipa> yay
451 2016-07-07T19:51:13  <gmaxwell> pfft. plenty of people have gone after hours and spent the rest of their lives there.
452 2016-07-07T19:51:22  <jonasschnelli>  self.node_args[1].extend(['-rescan']) should be  self.node_args[1] + ['-rescan']
453 2016-07-07T19:51:56  <MarcoFalke> Wow
454 2016-07-07T19:52:24  <wumpus> jonasschnelli: wow, very good news, and you found it within the meeting :D
455 2016-07-07T19:52:25  <petertodd> jonasschnelli: oh, is node_args[1] a tuple?
456 2016-07-07T19:52:39  <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.
457 2016-07-07T19:52:48  <jonasschnelli> I'm not familiar with extend() but seems to be the wrong function for that purpose.
458 2016-07-07T19:53:05  <jonasschnelli> But I guess we want MarcoFalke's RPC test in 0.13! :)
459 2016-07-07T19:53:19  <petertodd> jonasschnelli: extend() is list only, and modifies in place
460 2016-07-07T19:53:57  <wumpus> yes, extend is in place and returns nothing
461 2016-07-07T19:54:23  <jonasschnelli> At least we tested again the HD feature...
462 2016-07-07T19:54:38  <sipa> 6 minutes
463 2016-07-07T19:54:51  <sipa> are we done?
464 2016-07-07T19:54:59  <gmaxwell> sipa: until we lose you to the catacombs?
465 2016-07-07T19:54:59  <wumpus> I think so?
466 2016-07-07T19:55:31  <wumpus> #endmeeting
467 2016-07-07T19:55:31  <lightningbot> Meeting ended Thu Jul  7 19:55:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
468 2016-07-07T19:55:31  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.html
469 2016-07-07T19:55:31  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.txt
470 2016-07-07T19:55:31  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.log.html
471 2016-07-07T19:56:26  <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
472 2016-07-07T19:56:34  <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!
473 2016-07-07T19:57:02  <btcdrak> looks like it's working agian
474 2016-07-07T19:57:23  <jonasschnelli> gmaxwell: re https://people.xiph.org/~greg/auth0.txt, can the client fingerprint the serve by just getting a 64byte compact ECsig?
475 2016-07-07T19:57:27  <wumpus> sdaftuar: agree with leaving it untranslated
476 2016-07-07T19:57:27  <jonasschnelli> *server
477 2016-07-07T19:57:34  <sdaftuar> wumpus: ok thanks!
478 2016-07-07T19:57:37  <gmaxwell> jonasschnelli: Not unless it knows the public key.
479 2016-07-07T19:58:05  <jonasschnelli> I just try to find a/the concrete reason for the believed_server_pubkey in H(session_id || "1" || believed_server_pubkey)
480 2016-07-07T19:58:10  <gmaxwell> jonasschnelli: If the server has no match for X1 the protocol is just filled with padding at that point.
481 2016-07-07T19:58:40  <jonasschnelli> How could the client fingerprint when believed_server_pubkey would not be there?
482 2016-07-07T19:58:42  <wumpus> sdaftuar: I think some of the InitWarnings are translated, but anyhow, nothing new is going to get translated for 0.13.0
483 2016-07-07T19:58:44  <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)
484 2016-07-07T19:58:50  *** instagibbs2 has quit IRC
485 2016-07-07T19:59:27  <wumpus> sdaftuar: and it's going to be a rare message for people to see, so even otherwise probably a waste of translators time :)
486 2016-07-07T19:59:32  <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.
487 2016-07-07T19:59:54  <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
488 2016-07-07T20:00:05  <jonasschnelli> gmaxwell: ah... even for standard compact normalized signatures?
489 2016-07-07T20:00:08  <sdaftuar> versus doign a LogPrint() or something
490 2016-07-07T20:01:35  <jonasschnelli> gmaxwell: I thought in order to do this, it would require a recoverable signature (something like libsecp256k1s secp256k1_ecdsa_recoverable_signature_serialize_compact)
491 2016-07-07T20:02:51  <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
492 2016-07-07T20:02:53  <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.
493 2016-07-07T20:11:16  <gmaxwell> jonasschnelli: Does it make sense now?
494 2016-07-07T20:16:10  <jonasschnelli> gmaxwell: Okay. Got it. Thanks for the patience to explain.
495 2016-07-07T20:27:11  <bsm117532> Maybe I'm missing something...why does BIP 144 not define this transaction format as nVersion=2?
496 2016-07-07T20:27:44  <sipa> because it does not add anything
497 2016-07-07T20:27:55  <sipa> nVersion is part of the transaction data
498 2016-07-07T20:28:02  <sipa> so you can't modify it upon relay
499 2016-07-07T20:28:28  <sipa> bip144 adds an extra serialization flag that is not hashed into the txid
500 2016-07-07T20:29:03  <gmaxwell> jonasschnelli: no problem.
501 2016-07-07T20:29:47  <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?
502 2016-07-07T20:29:49  <bsm117532> 01000000000101ca3cd3084fee7a0a4746f7b41ce65c6f0778b6643515d4ad07798ee70a374b470000000016001486553e1ea2d97539d116fe878b2d3c69f6eb4faaffffffff01a01cc10767ffffff160014963f8e056d9aff20bc8ae5a0126e33ea9b2e399d6b483045022100b664937800fd386e936ac4b340d86c1417e5257ec9308879b96a2a9761a7c8ec022056f25e9e898968c0acf97fec8a0f501af9b0c19a9bcfc3cbd95c75d32c9895870121036efd8cc9de281efe42ef653c4abbb9459024e336cc4fe56622e68c6aa2574e1800000000
503 2016-07-07T20:30:01  <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
504 2016-07-07T20:30:59  <sipa> message cut off
505 2016-07-07T20:31:05  <sipa> can you paste it somewhere?
506 2016-07-07T20:31:17  <bsm117532> Sure
507 2016-07-07T20:32:48  <bsm117532> https://www.zerobin.net/?5f1a8550abf9f104#t/ID9UEgNXlzp7m3Vr31/Vvz7I5GwWfnNMGqF7Rkbg0=
508 2016-07-07T20:33:35  <bsm117532> Hmmm that output is clearly borked.
509 2016-07-07T20:34:08  *** [b__b] has quit IRC
510 2016-07-07T20:35:09  <bsm117532> Would bitcoin-cli decoderawtransaction abort due to the negative output there?  That might be my problem...
511 2016-07-07T20:35:19  *** [b__b] has joined #bitcoin-core-dev
512 2016-07-07T20:37:08  *** luke-jr has quit IRC
513 2016-07-07T20:37:23  <bsm117532> Decoderawtransaction still doesn't like it after making that output positive: https://www.zerobin.net/?afb35cd1b41acb5e#EXgtfGe6+ZRZinaximJV0ptmxbqNDqF4nI71HDF3/I8=
514 2016-07-07T20:40:03  *** spudowiar has joined #bitcoin-core-dev
515 2016-07-07T20:56:30  * bsm117532 finds a test vector in BIP 143...
516 2016-07-07T21:00:13  *** fengling has joined #bitcoin-core-dev
517 2016-07-07T21:05:06  *** fengling has quit IRC
518 2016-07-07T21:16:05  *** MarcoFalke has left #bitcoin-core-dev
519 2016-07-07T21:52:44  *** spudowiar has quit IRC
520 2016-07-07T22:00:01  <sipa> bsm117532: negative output?
521 2016-07-07T22:00:31  <bsm117532> I fixed that, it wasn't the problem.
522 2016-07-07T22:01:39  *** fengling has joined #bitcoin-core-dev
523 2016-07-07T22:01:57  <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.
524 2016-07-07T22:03:55  <sipa> OP_0 <hashed pubkey> goes into the output
525 2016-07-07T22:04:08  <sipa> the scriptSig spending segwit outouts is always empty
526 2016-07-07T22:04:14  <bsm117532> I'm also missing the array length in the witness.
527 2016-07-07T22:04:15  <sipa> unless it's P2SH
528 2016-07-07T22:04:19  <bsm117532> Ok, gotcha
529 2016-07-07T22:06:26  *** fengling has quit IRC
530 2016-07-07T22:21:43  *** murch has quit IRC
531 2016-07-07T22:22:39  *** pmienk has quit IRC
532 2016-07-07T22:25:41  *** pmienk has joined #bitcoin-core-dev
533 2016-07-07T22:27:31  *** Guyver2 has quit IRC
534 2016-07-07T22:29:02  *** belcher has joined #bitcoin-core-dev
535 2016-07-07T22:29:39  *** luke-jr has joined #bitcoin-core-dev
536 2016-07-07T23:03:12  *** fengling has joined #bitcoin-core-dev
537 2016-07-07T23:08:06  *** fengling has quit IRC
538 2016-07-07T23:13:53  *** justanot1eruser has joined #bitcoin-core-dev
539 2016-07-07T23:14:45  *** justanotheruser has quit IRC
540 2016-07-07T23:15:00  *** justanot1eruser is now known as justanotheruser
541 2016-07-07T23:21:22  *** kadoban has joined #bitcoin-core-dev
542 2016-07-07T23:35:14  *** bitcoin-core-dev has joined #bitcoin-core-dev