12016-07-07T00:01:44  <luke-jr> cfields: kicked it
  22016-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.
  32016-07-07T00:02:31  <luke-jr> phantomcircuit: no, I agree
  42016-07-07T00:02:41  <luke-jr> cfields: heh
  52016-07-07T00:07:04  <GitHub83> [bitcoin] mcelrath opened pull request #8311: Rename CTxinWitness -> CTxInWitness (master...CTxInWitness) https://github.com/bitcoin/bitcoin/pull/8311
  62016-07-07T00:07:21  <bsm117532> dumb patch of the day...
  72016-07-07T00:08:32  <sipa> hah
  82016-07-07T00:31:58  <luke-jr> cfields: looks like a success :D
  92016-07-07T00:32:55  <cfields> luke-jr: woohoo
 102016-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
 112016-07-07T00:33:49  <cfields> who knew
 122016-07-07T00:33:51  <luke-jr> XD
 132016-07-07T00:34:08  <luke-jr> cfields: btw, can you set someone else up with access to raise our bus factor?
 142016-07-07T00:34:51  <cfields> luke-jr: sure, i think there are several though
 152016-07-07T00:35:11  <luke-jr> eh?
 162016-07-07T00:35:18  <cfields> i believe wumpus/btcdrak/bluematt have access
 172016-07-07T00:35:36  <luke-jr> wumpus said he didn't, and the other two didn't speak up IIRC
 182016-07-07T00:35:55  <cfields> oh, hmm. ok, will check
 192016-07-07T00:36:57  <cfields> there was an issue with dns after the move, maybe they're missing the new info
 202016-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.
 212016-07-07T00:38:41  <sipa> maybe wumpus has access but does not know it :)
 222016-07-07T00:39:07  <luke-jr> heh
 232016-07-07T00:41:43  <cfields> i think that's probably the case. i thought i lost access until btcdrak figured out the dns weirdness
 242016-07-07T00:41:44  *** fengling__ has joined #bitcoin-core-dev
 252016-07-07T00:46:26  *** fengling__ has quit IRC
 262016-07-07T00:50:28  <phantomcircuit> cfields, he's going to run you over with a bus, quick run away!
 272016-07-07T00:58:17  <luke-jr> …
 282016-07-07T01:00:48  <cfields> heh
 292016-07-07T01:15:49  *** JackH has quit IRC
 302016-07-07T01:18:47  *** fengling__ has joined #bitcoin-core-dev
 312016-07-07T01:25:43  *** Ylbam has quit IRC
 322016-07-07T01:38:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 332016-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
 342016-07-07T02:02:21  *** Chris_Stewart_5 has quit IRC
 352016-07-07T02:20:37  *** fengling__ is now known as fengling
 362016-07-07T02:58:39  *** sanada has quit IRC
 372016-07-07T02:58:49  *** sanada has joined #bitcoin-core-dev
 382016-07-07T03:00:28  *** eenoch has quit IRC
 392016-07-07T03:01:10  *** eenoch has joined #bitcoin-core-dev
 402016-07-07T03:18:04  *** zooko has quit IRC
 412016-07-07T03:40:40  *** bustd_soket has quit IRC
 422016-07-07T03:45:39  *** zooko has joined #bitcoin-core-dev
 432016-07-07T03:59:42  *** bustd_soket has joined #bitcoin-core-dev
 442016-07-07T04:10:31  *** Alopex has quit IRC
 452016-07-07T04:11:19  *** whphhg has quit IRC
 462016-07-07T04:11:37  *** Alopex has joined #bitcoin-core-dev
 472016-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
 482016-07-07T05:42:45  *** gabridome_ has joined #bitcoin-core-dev
 492016-07-07T05:43:42  *** gabridome_ has quit IRC
 502016-07-07T06:01:29  *** Ylbam has joined #bitcoin-core-dev
 512016-07-07T06:19:40  *** molz has joined #bitcoin-core-dev
 522016-07-07T06:21:17  *** molly has joined #bitcoin-core-dev
 532016-07-07T06:21:25  *** davec_ has quit IRC
 542016-07-07T06:21:51  *** davec has joined #bitcoin-core-dev
 552016-07-07T06:22:31  *** moli has quit IRC
 562016-07-07T06:24:13  *** molz has quit IRC
 572016-07-07T06:30:28  *** zooko has quit IRC
 582016-07-07T06:35:14  *** JackH has joined #bitcoin-core-dev
 592016-07-07T06:41:24  <jonasschnelli> Ping MarcoFalke
 602016-07-07T06:41:45  <jonasschnelli> I don't see how you could lost coins with the new HD feature...
 612016-07-07T06:41:56  <jonasschnelli> *lose coins
 622016-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
 632016-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
 642016-07-07T06:48:04  <wumpus> (well, not the importing-back the seed part, but at least it gives a way to export the seed)
 652016-07-07T06:48:25  <wumpus> handling that properly will be more complex, as then the wallet would have multiple master keys
 662016-07-07T06:48:50  <wumpus> (so which one to use for generating new addresses? it seems to even need an API change)
 672016-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
 682016-07-07T06:53:35  *** MarcoFalke has joined #bitcoin-core-dev
 692016-07-07T06:55:31  *** davidlj95 has quit IRC
 702016-07-07T06:58:16  <MarcoFalke> jonasschnelli: I was trying to do an actual backup. Not just dumpwallet
 712016-07-07T06:58:38  <MarcoFalke> See the HD test: https://github.com/bitcoin/bitcoin/pull/8309
 722016-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.
 732016-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.
 742016-07-07T07:00:42  <MarcoFalke> So why does it fail?
 752016-07-07T07:09:28  <jonasschnelli> MarcoFalke: the current HD feature will not auto-recover funds/keys you have created after the backup...
 762016-07-07T07:09:34  <jonasschnelli> Did you ran into this issue?
 772016-07-07T07:09:41  <MarcoFalke> nope
 782016-07-07T07:09:48  *** Amnez777 has quit IRC
 792016-07-07T07:09:56  <jonasschnelli> If you copy back your wallet.dat, it should be the same as it was before...
 802016-07-07T07:10:24  <MarcoFalke> https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR65
 812016-07-07T07:10:35  <MarcoFalke> This derives all the keys
 822016-07-07T07:10:39  <MarcoFalke> (again)
 832016-07-07T07:11:10  <MarcoFalke> Then asserts that the last derived key is identical to the last derived key of the first run
 842016-07-07T07:11:21  <MarcoFalke> But somehow it does not update the balance
 852016-07-07T07:11:44  <jonasschnelli> hmm...
 862016-07-07T07:11:59  *** Amnez777 has joined #bitcoin-core-dev
 872016-07-07T07:12:34  <jonasschnelli> MarcoFalke: if you call getnewaddress, you get the same address but not the received coins to this address, right?
 882016-07-07T07:12:53  <jonasschnelli> I guess it requires a rescan (after getnewaddress)
 892016-07-07T07:12:54  <MarcoFalke> jup
 902016-07-07T07:13:11  <MarcoFalke> I tried rescan and reindex
 912016-07-07T07:13:22  <jonasschnelli> reindex should not be necessary... rescan works?
 922016-07-07T07:13:27  <MarcoFalke> no
 932016-07-07T07:14:35  *** whphhg has joined #bitcoin-core-dev
 942016-07-07T07:14:42  <jonasschnelli> let me test it locally... thanks for testing / writing the test!
 952016-07-07T07:15:02  <jonasschnelli> I knew that the backup restore is not something users can easily do.
 962016-07-07T07:15:25  <MarcoFalke> Correct, but there should be some way to do it
 972016-07-07T07:15:28  <jonasschnelli> Not sure if we should have something more convenient (backup restore) for 0.13
 982016-07-07T07:15:34  <jonasschnelli> Yes.
 992016-07-07T07:15:42  <jonasschnelli> Maybe we discuss this tonight at the IRC meeting
1002016-07-07T07:16:16  <MarcoFalke> oh
1012016-07-07T07:16:18  <MarcoFalke> I got it
1022016-07-07T07:16:37  <MarcoFalke> importprivkey breaks all future backups
1032016-07-07T07:16:42  <MarcoFalke> :(
1042016-07-07T07:16:51  <MarcoFalke> This should be fixed I assume
1052016-07-07T07:17:08  <MarcoFalke> Maybe a small fix in the rescan logic
1062016-07-07T07:17:23  <jonasschnelli> What's the reason for this?
1072016-07-07T07:17:27  <MarcoFalke> no idea
1082016-07-07T07:17:38  <jonasschnelli> Why does it breaks all future backups?
1092016-07-07T07:17:44  <jonasschnelli> *break
1102016-07-07T07:18:10  <MarcoFalke> Maybe only legacy keys are rescanned when there is at least one?
1112016-07-07T07:18:42  <MarcoFalke> Need to look into the code...
1122016-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
1132016-07-07T07:19:35  <jonasschnelli> Thanks for looking into the code
1142016-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
1152016-07-07T07:25:19  *** davidlj95 has joined #bitcoin-core-dev
1162016-07-07T07:32:27  <MarcoFalke> More likely it is just a getbalance issue. I remember there were "some" issues lately
1172016-07-07T07:37:17  *** rubensayshi has joined #bitcoin-core-dev
1182016-07-07T07:43:40  *** rubensayshi has quit IRC
1192016-07-07T07:45:04  *** moli has joined #bitcoin-core-dev
1202016-07-07T07:46:15  *** molly has quit IRC
1212016-07-07T07:53:26  *** fengling has quit IRC
1222016-07-07T07:58:06  *** rubensayshi has joined #bitcoin-core-dev
1232016-07-07T08:00:21  *** fengling has joined #bitcoin-core-dev
1242016-07-07T08:08:34  *** Evel-Knievel has quit IRC
1252016-07-07T08:09:02  *** Evel-Knievel has joined #bitcoin-core-dev
1262016-07-07T08:38:17  *** kadoban has quit IRC
1272016-07-07T08:40:26  *** fengling has quit IRC
1282016-07-07T08:51:36  *** davidlj95 has quit IRC
1292016-07-07T08:53:12  *** davidlj95 has joined #bitcoin-core-dev
1302016-07-07T08:53:58  *** fengling has joined #bitcoin-core-dev
1312016-07-07T09:10:47  *** AaronvanW has quit IRC
1322016-07-07T09:13:54  *** AaronvanW has joined #bitcoin-core-dev
1332016-07-07T09:17:15  *** moli has quit IRC
1342016-07-07T09:17:44  *** moli has joined #bitcoin-core-dev
1352016-07-07T09:38:54  <wumpus> what's wrong with getbalance?
1362016-07-07T09:42:17  *** Guyver2 has joined #bitcoin-core-dev
1372016-07-07T09:56:38  *** davidlj95 has quit IRC
1382016-07-07T10:08:34  *** Justinus has quit IRC
1392016-07-07T10:39:06  *** fengling has quit IRC
1402016-07-07T10:45:34  *** fengling has joined #bitcoin-core-dev
1412016-07-07T10:48:52  *** davidlj95 has joined #bitcoin-core-dev
1422016-07-07T10:52:01  *** jannes has joined #bitcoin-core-dev
1432016-07-07T11:25:46  *** fengling has quit IRC
1442016-07-07T11:32:07  *** laurentmt has joined #bitcoin-core-dev
1452016-07-07T11:50:32  *** laurentmt has quit IRC
1462016-07-07T12:22:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1472016-07-07T12:22:59  *** fengling has joined #bitcoin-core-dev
1482016-07-07T12:52:26  *** fengling has quit IRC
1492016-07-07T13:03:40  *** murch has joined #bitcoin-core-dev
1502016-07-07T13:33:57  *** rubensayshi has quit IRC
1512016-07-07T13:49:42  *** fengling has joined #bitcoin-core-dev
1522016-07-07T13:54:21  *** rubensayshi has joined #bitcoin-core-dev
1532016-07-07T13:54:26  *** fengling has quit IRC
1542016-07-07T14:17:12  *** rubensayshi has quit IRC
1552016-07-07T14:23:31  *** afk11 has quit IRC
1562016-07-07T14:33:01  *** rubensayshi has joined #bitcoin-core-dev
1572016-07-07T14:51:13  *** fengling has joined #bitcoin-core-dev
1582016-07-07T14:56:06  *** fengling has quit IRC
1592016-07-07T15:16:04  *** Chris_Stewart_5 has quit IRC
1602016-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...
1612016-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
1622016-07-07T15:30:02  <jonasschnelli> Seems to work...
1632016-07-07T15:30:20  <jonasschnelli> Maybe need to check in conjunction with importprivkey...
1642016-07-07T15:31:17  *** zooko has joined #bitcoin-core-dev
1652016-07-07T15:31:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1662016-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
1672016-07-07T15:52:53  *** fengling has joined #bitcoin-core-dev
1682016-07-07T15:54:05  *** afk11 has joined #bitcoin-core-dev
1692016-07-07T15:54:05  *** afk11 has quit IRC
1702016-07-07T15:54:05  *** afk11 has joined #bitcoin-core-dev
1712016-07-07T15:57:46  *** fengling has quit IRC
1722016-07-07T16:05:01  *** rubensayshi has quit IRC
1732016-07-07T16:21:24  *** spudowiar has joined #bitcoin-core-dev
1742016-07-07T17:05:47  *** zooko has quit IRC
1752016-07-07T17:28:17  *** zooko has joined #bitcoin-core-dev
1762016-07-07T17:55:53  *** fengling has joined #bitcoin-core-dev
1772016-07-07T17:56:31  <MarcoFalke> IsMine returns false for the txs involving the HD keys
1782016-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
1792016-07-07T17:57:32  <zooko> We'll put in the time to merge it if desired.
1802016-07-07T17:58:13  <gmaxwell> cfields: ^
1812016-07-07T17:58:15  *** jannes has quit IRC
1822016-07-07T17:58:16  <zooko> I've asked Zcash engineer Taylor "earthrise" Hornby to support you on that if you want it.
1832016-07-07T17:58:45  <zooko> The _other_ one that I mentioned a few days back turned out to have a bug — we were
1842016-07-07T17:58:53  <cfields> zooko / gmaxwell: thanks
1852016-07-07T17:59:06  <zooko> trying to measure time to validate a block packed full of worst-case quadratic signature.
1862016-07-07T17:59:18  <zooko> And we were accidentally measuring time to check that the signature was already cached. ;-)
1872016-07-07T17:59:26  <zooko> But we've fixed that, and now we have some results.
1882016-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
1892016-07-07T18:00:15  <zooko> 35s for 1 MB block, 140s for 2 MB block
1902016-07-07T18:00:46  *** fengling has quit IRC
1912016-07-07T18:01:23  <cfields> zooko: hmm, i believe we already do those checks
1922016-07-07T18:01:53  <cfields> we might not verify FORTIFY_SOURCE, though
1932016-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
1942016-07-07T18:10:16  * michagogo watches a reindex fly by on his new Sandisk X400
1952016-07-07T18:11:50  * bsm117532 struts out his two RAID0 Samsung 950 Pros...for the reindex... ;-)
1962016-07-07T18:12:31  <michagogo> Heh, nice
1972016-07-07T18:13:08  <michagogo> Up to block 216k after about 40 minutes
1982016-07-07T18:18:56  <bsm117532> Yeah my reindex is CPU bound.
1992016-07-07T18:22:36  <gmaxwell> OT, but of interest: http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
2002016-07-07T18:33:09  *** spudowiar has quit IRC
2012016-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
2022016-07-07T18:41:54  *** zooko has quit IRC
2032016-07-07T18:45:24  <GitHub155> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/91abb77970f4...0cca2feb357a
2042016-07-07T18:45:24  <GitHub155> bitcoin/master fa6ad56 MarcoFalke: [travis] Update SDK_URL
2052016-07-07T18:45:25  <GitHub155> bitcoin/master 0cca2fe Jonas Schnelli: Merge #8304: [travis] Update SDK_URL...
2062016-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
2072016-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?
2082016-07-07T18:46:52  <sipa> i have not looked into HKDF, but we should
2092016-07-07T18:47:16  <jonasschnelli> RFC: https://tools.ietf.org/html/rfc5869
2102016-07-07T18:49:23  <jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
2112016-07-07T18:54:01  *** zooko has joined #bitcoin-core-dev
2122016-07-07T18:55:11  <zooko> cfields: done: https://github.com/zcash/zcash/issues/1071
2132016-07-07T18:57:23  *** fengling has joined #bitcoin-core-dev
2142016-07-07T18:58:15  <jonasschnelli> gmaxwell: https://people.xiph.org/~greg/auth0.txt, why does AUTHCHALLENGE require "believed_server_pubkey"?
2152016-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.
2162016-07-07T18:59:33  <btcdrak> meeting time?
2172016-07-07T18:59:39  <jonasschnelli> yes
2182016-07-07T18:59:40  <petertodd> yup
2192016-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
2202016-07-07T19:00:10  <wumpus> #startmeeting
2212016-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.
2222016-07-07T19:00:10  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2232016-07-07T19:00:13  <cfields> gmaxwell: thanks. here.
2242016-07-07T19:00:16  <sdaftuar> hi
2252016-07-07T19:00:28  <gmaxwell> Welcome to meeting.
2262016-07-07T19:00:39  *** instagibbs2 has joined #bitcoin-core-dev
2272016-07-07T19:00:43  <wumpus> proposed topic: 0.13.0rc1
2282016-07-07T19:00:51  <petertodd> wumpus: ack
2292016-07-07T19:00:56  <gmaxwell> This week was a week of many reverts. Reverting will continue until morale improves.
2302016-07-07T19:01:01  <michagogo> Hi
2312016-07-07T19:01:03  <wumpus> #topic 0.13.0rc1
2322016-07-07T19:01:13  <sipa> somewhat present
2332016-07-07T19:01:19  <jonasschnelli> Are we +1 day with the 0.13 splitoff?
2342016-07-07T19:01:19  <wumpus> foremost, I cannot build a release at this moment, as gitian lxc building is broken
2352016-07-07T19:01:21  <sdaftuar> wumpus: so there are a couple bugs that still need to be fixed for 0.13
2362016-07-07T19:01:21  <MarcoFalke> Is the HD issue a blocker for the rc?
2372016-07-07T19:01:37  <wumpus> https://github.com/bitcoin/bitcoin/issues/8212 / https://github.com/bitcoin/bitcoin/pull/8213
2382016-07-07T19:01:50  <cfields> wumpus: ok. I'll handle those next.
2392016-07-07T19:01:53  <wumpus> MarcoFalke: which HD issue?
2402016-07-07T19:02:02  <MarcoFalke> I couldn't restore from a HD backup
2412016-07-07T19:02:03  <jonasschnelli> I think there is no "real" HD issue
2422016-07-07T19:02:06  *** fengling has quit IRC
2432016-07-07T19:02:07  <michagogo> wumpus: Broken in what way?
2442016-07-07T19:02:16  <wumpus> michagogo: please read the issues
2452016-07-07T19:02:17  <MarcoFalke> jonasschnelli: Could you look into the travis failure
2462016-07-07T19:02:19  <MarcoFalke> ?
2472016-07-07T19:02:23  <jonasschnelli> Yes. Will do..
2482016-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.
2492016-07-07T19:02:28  <michagogo> (Sorry, I've not had much free time for this stuff in the past months)
2502016-07-07T19:02:35  * michagogo goes to check
2512016-07-07T19:02:40  <wumpus> if HD is broken, we have to disable  it for 0.13
2522016-07-07T19:02:47  <michagogo> (Gitian issues or Bitcoin Core?)
2532016-07-07T19:02:53  <wumpus> or at least rc1
2542016-07-07T19:02:57  <MarcoFalke> gmaxwell: You can see the issue on travis
2552016-07-07T19:02:57  <jonasschnelli> Sure. Let me check MarcoFalke HD test
2562016-07-07T19:03:06  <MarcoFalke> It is either an error in my test code
2572016-07-07T19:03:06  <gmaxwell> Disabling it indeed would be an option.
2582016-07-07T19:03:15  <MarcoFalke> or some issue with IsMine() or something else
2592016-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.
2602016-07-07T19:03:33  <MarcoFalke> I'd rather fix it than disable it
2612016-07-07T19:03:40  <cfields> MarcoFalke: link to travis failure?
2622016-07-07T19:03:42  <wumpus> I don't want to block rc1 too long
2632016-07-07T19:03:45  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
2642016-07-07T19:03:52  <wumpus> rather have a test release out as soon as possible
2652016-07-07T19:03:54  <btcdrak> remaining issue/prs for 0.13 https://github.com/bitcoin/bitcoin/milestones/0.13.0
2662016-07-07T19:04:02  <MarcoFalke> pull 8309
2672016-07-07T19:04:06  <MarcoFalke> cfields: ^
2682016-07-07T19:04:11  <gmaxwell> lets talk about the other things then move on to the hd issue as it's own topic.
2692016-07-07T19:04:12  <cfields> thanks
2702016-07-07T19:04:30  <wumpus> planning was to do rc1 yesterday, but it was clear it wasn't possible
2712016-07-07T19:04:46  <wumpus> btcdrak: some things can be merged as-is I think
2722016-07-07T19:04:52  <MarcoFalke> Also there are some issues open by sdaftuar
2732016-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
2742016-07-07T19:05:28  <wumpus> #7678 (release notes) is a TODO for -final, not rc1, could use some help there though
2752016-07-07T19:06:13  <wumpus> are they ready for merge?
2762016-07-07T19:06:15  <btcdrak> sdaftuar those should be tagged with the milestone then
2772016-07-07T19:06:27  <sipa> i will write some release notes for the tx relay changes
2782016-07-07T19:06:35  <sipa> (but not now)
2792016-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
2802016-07-07T19:06:50  <wumpus> right, release notes is not urgent now, just needs to be done before final
2812016-07-07T19:06:54  <wumpus> let's worry about rc1 now
2822016-07-07T19:07:12  <sdaftuar> #8305 and #8295 are done as far as i know
2832016-07-07T19:07:17  <sdaftuar> (no review though)
2842016-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
2852016-07-07T19:08:19  <gmaxwell> I've been very busy with testing, in fact.
2862016-07-07T19:08:38  <wumpus> testing is good
2872016-07-07T19:08:47  <wumpus> releasing rc1 will result in a lot of testing, too
2882016-07-07T19:09:16  <sipa> wumpus: i was less active the past week; i'll be back tomorrow
2892016-07-07T19:10:31  <wumpus> ok I see jonasschnelli already added 0.13 milestone to sdaftuar's pulls, thanks
2902016-07-07T19:10:35  <jonasschnelli> Yes.
2912016-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
2922016-07-07T19:11:43  <petertodd> i'll try to look at 8312 this weekend
2932016-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
2942016-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
2952016-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
2962016-07-07T19:13:48  <cfields> wumpus: quick alternative would bt c/p the descriptor to linux-arm.yml for now
2972016-07-07T19:14:00  <gmaxwell> will we be able to distribute arm linux binaries for 0.13?
2982016-07-07T19:14:23  <wumpus> gmaxwell: yes, that was done, but it has added an awkward requirement to the gitian build descriptor
2992016-07-07T19:14:24  <jonasschnelli> yes
3002016-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.
3012016-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)
3022016-07-07T19:16:46  <petertodd> wumpus: ack
3032016-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 :)
3042016-07-07T19:17:53  <cfields> ok
3052016-07-07T19:18:08  <wumpus> #action wumpus contact devrandom about https://github.com/devrandom/gitian-builder/pull/123
3062016-07-07T19:18:12  <achow101> what about segwit deployment parameters
3072016-07-07T19:18:23  <btcdrak> achow101: not for 0.13.0
3082016-07-07T19:18:42  <wumpus> we could add that as proposed topic, but not relevant for 0.13
3092016-07-07T19:19:06  <sipa> achow101: first backport to 0.12, figuring out cb+segwit, and planning releases
3102016-07-07T19:19:08  <btcdrak> achow101: it's explained in https://bitcoincore.org/en/lifecycle/#consensus-rules
3112016-07-07T19:19:11  <MarcoFalke> #action Help with review on https://github.com/bitcoin/bitcoin/milestone/20
3122016-07-07T19:19:17  <wumpus> we're done with this topic though so i'm ok with switching
3132016-07-07T19:20:14  <gmaxwell> Okay can we talk briefly about the HD wallet thing?
3142016-07-07T19:20:20  <wumpus> #topic HD wallet issue
3152016-07-07T19:20:43  <sipa> what is the hd wallet issue number?
3162016-07-07T19:20:56  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
3172016-07-07T19:21:00  <jonasschnelli> Its a PR (failing test)
3182016-07-07T19:21:29  <jonasschnelli> currently looking at it.
3192016-07-07T19:21:31  <MarcoFalke> The rpc-test is pretty simple: usehd=1, then backup wallet.dat
3202016-07-07T19:21:35  <jonasschnelli> The addresses are re-generated deterministic... but somehow reindex fails..
3212016-07-07T19:21:36  <MarcoFalke> Do some transactions and discard wallet.dat
3222016-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.
3232016-07-07T19:21:39  <gmaxwell> But I could misunderstand.
3242016-07-07T19:22:07  <jonasschnelli> Yes. The simples HD feature does not cover restores...
3252016-07-07T19:22:17  <MarcoFalke> I am running rescan and reindex. None of it fixes it
3262016-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.
3272016-07-07T19:22:20  <jonasschnelli> Restore is manual work (including a rescan)
3282016-07-07T19:22:36  <gmaxwell> if a rescan isn't fixing it, thats a more serious issue than I was thinking.
3292016-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)
3302016-07-07T19:23:02  <jonasschnelli> Yes... I currently trying to find out why MarcoFalke test fails even after a rescan.
3312016-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.
3322016-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?
3332016-07-07T19:23:25  <jonasschnelli> But IMO it's unrelated to HD,... the keys are recreated.
3342016-07-07T19:23:49  <wumpus> yes, I think this scary, I don't think this is ready for a release
3352016-07-07T19:23:52  <gmaxwell> wumpus: it's the same keys every time, no defeating.
3362016-07-07T19:23:56  <jonasschnelli> Sure. Let me first try to find the root cause before we consider a revert
3372016-07-07T19:24:16  <MarcoFalke> agree
3382016-07-07T19:24:18  <wumpus> rever wouldn't be necessary, just default the flag to false
3392016-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
3402016-07-07T19:24:47  <jonasschnelli> Sure. But we probably don't want to ship a (per default disabled) feature which _could_ includes bugs. :)
3412016-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.
3422016-07-07T19:24:56  <petertodd> wumpus: is the flag documented in --help?
3432016-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.
3442016-07-07T19:25:39  <jonasschnelli> MarcoFalke: have you tried the test with HD disabled (just import your created keys)?
3452016-07-07T19:25:55  <gmaxwell> I haven't looked at it yet myself except passively watching the discussion.
3462016-07-07T19:25:59  <sipa> likewise
3472016-07-07T19:26:04  <sipa> i will look soon
3482016-07-07T19:26:04  <MarcoFalke> no
3492016-07-07T19:26:20  <jonasschnelli> I think without knowing the root cause of the problem actions are useless.
3502016-07-07T19:26:33  <wumpus> agreed
3512016-07-07T19:26:40  <sipa> agree; we need to understand it
3522016-07-07T19:26:41  <jonasschnelli> I will know more about it in a couple of hours.
3532016-07-07T19:26:47  <sipa> and i believe there is plenty of time for that
3542016-07-07T19:27:08  <wumpus> before when?
3552016-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.
3562016-07-07T19:27:27  <wumpus> yes, need to disable it completely then, I agree
3572016-07-07T19:27:41  <jonasschnelli> Yes. But it could also be a serious import/rescan issue (not related to HD)
3582016-07-07T19:28:09  <wumpus> the non-HD rescan test passes, right?
3592016-07-07T19:28:19  <MarcoFalke> yes
3602016-07-07T19:28:23  <sipa> i believe that rpc test is less elaborate
3612016-07-07T19:28:47  <wumpus> did you try your new test without HD MarcoFalke?
3622016-07-07T19:28:50  <jonasschnelli> I think we would need the same test (that fails) without HD
3632016-07-07T19:29:18  <MarcoFalke> You can't create keys deterministically without HD
3642016-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.
3652016-07-07T19:29:37  <sipa> no need to discuss the details here
3662016-07-07T19:29:43  <wumpus> oh sure, you can't do exactly the dsame thing
3672016-07-07T19:29:44  <jonasschnelli> MarcoFalke: you could create 100 keys and reimport them...
3682016-07-07T19:30:05  <jonasschnelli> anyways,... I'll have a look at it and will report on the PR
3692016-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.
3702016-07-07T19:30:14  <jonasschnelli> ack
3712016-07-07T19:30:15  <wumpus> right
3722016-07-07T19:30:19  <wumpus> any other topics?
3732016-07-07T19:31:07  <gmaxwell> Sure, an announcement:
3742016-07-07T19:31:47  <sipa> *crickets*
3752016-07-07T19:31:54  <jonasschnelli> oO
3762016-07-07T19:32:20  * petertodd braces for an incoming text wall
3772016-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.
3782016-07-07T19:32:44  <petertodd> +1
3792016-07-07T19:32:58  <jonasschnelli> Saw this. Impressive work! Well done.
3802016-07-07T19:33:01  <gmaxwell> (actually 98% of the time in the last day)
3812016-07-07T19:33:11  <btcdrak> Also the FIBRE website is http://bitcoinfibre.org/
3822016-07-07T19:33:14  <cfields> nice!
3832016-07-07T19:33:17  <wumpus> awesome!
3842016-07-07T19:33:23  <gmaxwell> And his deployment uses only cheap VPSes.
3852016-07-07T19:33:38  <sipa> wow, i saw the website but hadn't appreciated how good the numbers were
3862016-07-07T19:33:45  <sipa> i just looked at how oretty the graphs were
3872016-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. :)
3882016-07-07T19:34:18  <sipa> we need neutrino-based transmissions.
3892016-07-07T19:34:25  <petertodd> sipa: lol, I was just about to say
3902016-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.
3912016-07-07T19:34:37  <petertodd> sipa: reminds me, I wrote a short story about that awhile back...
3922016-07-07T19:35:10  <wumpus> neutrono-based transmissions are easy, compared to the receiver part :)
3932016-07-07T19:35:21  <btcdrak> The github project is at https://github.com/bitcoinfibre
3942016-07-07T19:35:54  <petertodd> wumpus: what? don't you have a few tonnes of heavy water laying around?
3952016-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.
3962016-07-07T19:36:26  <sipa> i believe production of heavy water may be more decentralized than sha256 asic mining production.
3972016-07-07T19:37:00  <petertodd> sipa: yes! https://www.youtube.com/watch?v=Sxl78pWW8Vk
3982016-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. :(
3992016-07-07T19:38:33  <wumpus> petertodd: of course I do, but not enough shielded undergorund space to put it
4002016-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.
4012016-07-07T19:39:36  <petertodd> wumpus: that's why I took up caving
4022016-07-07T19:39:40  *** anchow101 has joined #bitcoin-core-dev
4032016-07-07T19:40:01  <cfields> gmaxwell: what's the reason for an additional binary?
4042016-07-07T19:40:31  <cfields> gmaxwell: oh, you mean default to testnet until final release?
4052016-07-07T19:40:31  <wumpus> gmaxwell: we could do that now, eg before the rc1
4062016-07-07T19:40:47  <wumpus> well at least if I could build releases, dang
4072016-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.
4082016-07-07T19:41:03  *** anchow101 has quit IRC
4092016-07-07T19:41:18  <wumpus> cfields: not the rc1 itself, more like a master-build-with-only-testnet-enabled
4102016-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.
4112016-07-07T19:41:54  <wumpus> rc1 should definitely have mainnet by default, like any rc
4122016-07-07T19:42:26  *** kxie has joined #bitcoin-core-dev
4132016-07-07T19:42:32  <wumpus> gmaxwell: did you see #8285? it's super-easy now for windows GUI users
4142016-07-07T19:42:38  <cfields> hmm
4152016-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
4162016-07-07T19:42:50  <petertodd> gmaxwell: I wonder if a wrapper script with -testnet would help those users?
4172016-07-07T19:42:55  <gmaxwell> but perhaps thats too much for now. :)
4182016-07-07T19:43:18  <wumpus> https://github.com/bitcoin/bitcoin/pull/8285 exactly does that
4192016-07-07T19:43:22  <cfields> wumpus: ah nice, i missed that
4202016-07-07T19:43:27  <gmaxwell> I didn't see it.
4212016-07-07T19:43:36  <gmaxwell> (or forgot seeing it!)
4222016-07-07T19:43:59  <petertodd> wumpus: ah cool, thanks!
4232016-07-07T19:44:03  <gmaxwell> Thats really awesome.
4242016-07-07T19:44:21  <petertodd> wumpus: just like mainnet/testnet wallets on my android phone
4252016-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.
4262016-07-07T19:44:51  <wumpus> petertodd: indeed, bitcoin wallet for android has been doing a similar thing
4272016-07-07T19:44:58  <gmaxwell> if you could do builds. :P
4282016-07-07T19:46:16  <cfields> heh, hint taken. Working on the split descriptors now.
4292016-07-07T19:47:29  <wumpus> thanks cfields
4302016-07-07T19:47:34  <wumpus> any other topics?
4312016-07-07T19:47:44  <petertodd> wumpus: happy halving day :
4322016-07-07T19:47:45  <petertodd> )
4332016-07-07T19:47:46  <petertodd> :)
4342016-07-07T19:48:05  <wumpus> hah, same to you
4352016-07-07T19:48:39  <gmaxwell> I wonder if there is some scifi where halving day is where half the people die? it seems right.
4362016-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
4372016-07-07T19:49:04  <petertodd> gmaxwell: satoshi should have made it a 10% think, so we could call it DECIMATION DAY
4382016-07-07T19:49:19  <petertodd> *thing
4392016-07-07T19:49:30  <wumpus> petertodd: that sounds like a wise thing to do, hide in a cave until it blows over
4402016-07-07T19:49:49  <sipa> i wish i had a cave here
4412016-07-07T19:49:54  <sipa> i'm in the middle of paris
4422016-07-07T19:50:00  <sipa> and there is some football thing
4432016-07-07T19:50:16  <petertodd> sipa: you've got the most awesome sewer system, and the catacombs!
4442016-07-07T19:50:18  <gmaxwell> sipa: catacombs.
4452016-07-07T19:50:33  <sipa> catacombs close in 10 minutes.
4462016-07-07T19:50:47  <petertodd> sipa: "officially" speaking...
4472016-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)
4482016-07-07T19:51:08  <sipa> hah.
4492016-07-07T19:51:11  <jonasschnelli> All light are green. :)
4502016-07-07T19:51:12  <sipa> yay
4512016-07-07T19:51:13  <gmaxwell> pfft. plenty of people have gone after hours and spent the rest of their lives there.
4522016-07-07T19:51:22  <jonasschnelli>  self.node_args[1].extend(['-rescan']) should be  self.node_args[1] + ['-rescan']
4532016-07-07T19:51:56  <MarcoFalke> Wow
4542016-07-07T19:52:24  <wumpus> jonasschnelli: wow, very good news, and you found it within the meeting :D
4552016-07-07T19:52:25  <petertodd> jonasschnelli: oh, is node_args[1] a tuple?
4562016-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.
4572016-07-07T19:52:48  <jonasschnelli> I'm not familiar with extend() but seems to be the wrong function for that purpose.
4582016-07-07T19:53:05  <jonasschnelli> But I guess we want MarcoFalke's RPC test in 0.13! :)
4592016-07-07T19:53:19  <petertodd> jonasschnelli: extend() is list only, and modifies in place
4602016-07-07T19:53:57  <wumpus> yes, extend is in place and returns nothing
4612016-07-07T19:54:23  <jonasschnelli> At least we tested again the HD feature...
4622016-07-07T19:54:38  <sipa> 6 minutes
4632016-07-07T19:54:51  <sipa> are we done?
4642016-07-07T19:54:59  <gmaxwell> sipa: until we lose you to the catacombs?
4652016-07-07T19:54:59  <wumpus> I think so?
4662016-07-07T19:55:31  <wumpus> #endmeeting
4672016-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)
4682016-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
4692016-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
4702016-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
4712016-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
4722016-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!
4732016-07-07T19:57:02  <btcdrak> looks like it's working agian
4742016-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?
4752016-07-07T19:57:27  <wumpus> sdaftuar: agree with leaving it untranslated
4762016-07-07T19:57:27  <jonasschnelli> *server
4772016-07-07T19:57:34  <sdaftuar> wumpus: ok thanks!
4782016-07-07T19:57:37  <gmaxwell> jonasschnelli: Not unless it knows the public key.
4792016-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)
4802016-07-07T19:58:10  <gmaxwell> jonasschnelli: If the server has no match for X1 the protocol is just filled with padding at that point.
4812016-07-07T19:58:40  <jonasschnelli> How could the client fingerprint when believed_server_pubkey would not be there?
4822016-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
4832016-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)
4842016-07-07T19:58:50  *** instagibbs2 has quit IRC
4852016-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 :)
4862016-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.
4872016-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
4882016-07-07T20:00:05  <jonasschnelli> gmaxwell: ah... even for standard compact normalized signatures?
4892016-07-07T20:00:08  <sdaftuar> versus doign a LogPrint() or something
4902016-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)
4912016-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
4922016-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.
4932016-07-07T20:11:16  <gmaxwell> jonasschnelli: Does it make sense now?
4942016-07-07T20:16:10  <jonasschnelli> gmaxwell: Okay. Got it. Thanks for the patience to explain.
4952016-07-07T20:27:11  <bsm117532> Maybe I'm missing something...why does BIP 144 not define this transaction format as nVersion=2?
4962016-07-07T20:27:44  <sipa> because it does not add anything
4972016-07-07T20:27:55  <sipa> nVersion is part of the transaction data
4982016-07-07T20:28:02  <sipa> so you can't modify it upon relay
4992016-07-07T20:28:28  <sipa> bip144 adds an extra serialization flag that is not hashed into the txid
5002016-07-07T20:29:03  <gmaxwell> jonasschnelli: no problem.
5012016-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?
5022016-07-07T20:29:49  <bsm117532> 01000000000101ca3cd3084fee7a0a4746f7b41ce65c6f0778b6643515d4ad07798ee70a374b470000000016001486553e1ea2d97539d116fe878b2d3c69f6eb4faaffffffff01a01cc10767ffffff160014963f8e056d9aff20bc8ae5a0126e33ea9b2e399d6b483045022100b664937800fd386e936ac4b340d86c1417e5257ec9308879b96a2a9761a7c8ec022056f25e9e898968c0acf97fec8a0f501af9b0c19a9bcfc3cbd95c75d32c9895870121036efd8cc9de281efe42ef653c4abbb9459024e336cc4fe56622e68c6aa2574e1800000000
5032016-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
5042016-07-07T20:30:59  <sipa> message cut off
5052016-07-07T20:31:05  <sipa> can you paste it somewhere?
5062016-07-07T20:31:17  <bsm117532> Sure
5072016-07-07T20:32:48  <bsm117532> https://www.zerobin.net/?5f1a8550abf9f104#t/ID9UEgNXlzp7m3Vr31/Vvz7I5GwWfnNMGqF7Rkbg0=
5082016-07-07T20:33:35  <bsm117532> Hmmm that output is clearly borked.
5092016-07-07T20:34:08  *** [b__b] has quit IRC
5102016-07-07T20:35:09  <bsm117532> Would bitcoin-cli decoderawtransaction abort due to the negative output there?  That might be my problem...
5112016-07-07T20:35:19  *** [b__b] has joined #bitcoin-core-dev
5122016-07-07T20:37:08  *** luke-jr has quit IRC
5132016-07-07T20:37:23  <bsm117532> Decoderawtransaction still doesn't like it after making that output positive: https://www.zerobin.net/?afb35cd1b41acb5e#EXgtfGe6+ZRZinaximJV0ptmxbqNDqF4nI71HDF3/I8=
5142016-07-07T20:40:03  *** spudowiar has joined #bitcoin-core-dev
5152016-07-07T20:56:30  * bsm117532 finds a test vector in BIP 143...
5162016-07-07T21:00:13  *** fengling has joined #bitcoin-core-dev
5172016-07-07T21:05:06  *** fengling has quit IRC
5182016-07-07T21:16:05  *** MarcoFalke has left #bitcoin-core-dev
5192016-07-07T21:52:44  *** spudowiar has quit IRC
5202016-07-07T22:00:01  <sipa> bsm117532: negative output?
5212016-07-07T22:00:31  <bsm117532> I fixed that, it wasn't the problem.
5222016-07-07T22:01:39  *** fengling has joined #bitcoin-core-dev
5232016-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.
5242016-07-07T22:03:55  <sipa> OP_0 <hashed pubkey> goes into the output
5252016-07-07T22:04:08  <sipa> the scriptSig spending segwit outouts is always empty
5262016-07-07T22:04:14  <bsm117532> I'm also missing the array length in the witness.
5272016-07-07T22:04:15  <sipa> unless it's P2SH
5282016-07-07T22:04:19  <bsm117532> Ok, gotcha
5292016-07-07T22:06:26  *** fengling has quit IRC
5302016-07-07T22:21:43  *** murch has quit IRC
5312016-07-07T22:22:39  *** pmienk has quit IRC
5322016-07-07T22:25:41  *** pmienk has joined #bitcoin-core-dev
5332016-07-07T22:27:31  *** Guyver2 has quit IRC
5342016-07-07T22:29:02  *** belcher has joined #bitcoin-core-dev
5352016-07-07T22:29:39  *** luke-jr has joined #bitcoin-core-dev
5362016-07-07T23:03:12  *** fengling has joined #bitcoin-core-dev
5372016-07-07T23:08:06  *** fengling has quit IRC
5382016-07-07T23:13:53  *** justanot1eruser has joined #bitcoin-core-dev
5392016-07-07T23:14:45  *** justanotheruser has quit IRC
5402016-07-07T23:15:00  *** justanot1eruser is now known as justanotheruser
5412016-07-07T23:21:22  *** kadoban has joined #bitcoin-core-dev
5422016-07-07T23:35:14  *** bitcoin-core-dev has joined #bitcoin-core-dev