--- Day changed Thu Jul 07 2016
00:00 < MarcoFalke> the wallet.dat should contain the HD master key, thus I am able to derive all addresses and collect my coins.
00:00 < MarcoFalke> So why does it fail?
00:09 < jonasschnelli> MarcoFalke: the current HD feature will not auto-recover funds/keys you have created after the backup...
00:09 < jonasschnelli> Did you ran into this issue?
00:09 < MarcoFalke> nope
00:09 -!- Amnez777 [~Amnez777@37.157.216.155] has quit [Ping timeout: 276 seconds]
00:09 < jonasschnelli> If you copy back your wallet.dat, it should be the same as it was before...
00:10 < MarcoFalke> https://github.com/bitcoin/bitcoin/pull/8309/files#diff-ee4afcd6c3d5f19104c21bcc03407aeaR65
00:10 < MarcoFalke> This derives all the keys
00:10 < MarcoFalke> (again)
00:11 < MarcoFalke> Then asserts that the last derived key is identical to the last derived key of the first run
00:11 < MarcoFalke> But somehow it does not update the balance
00:11 < jonasschnelli> hmm...
00:11 -!- Amnez777 [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev
00:12 < jonasschnelli> MarcoFalke: if you call getnewaddress, you get the same address but not the received coins to this address, right?
00:12 < jonasschnelli> I guess it requires a rescan (after getnewaddress)
00:12 < MarcoFalke> jup
00:13 < MarcoFalke> I tried rescan and reindex
00:13 < jonasschnelli> reindex should not be necessary... rescan works?
00:13 < MarcoFalke> no
00:14 -!- whphhg [whphhg@gateway/vpn/mullvad/x-ffjjahvtzzvufmsm] has joined #bitcoin-core-dev
00:14 < jonasschnelli> let me test it locally... thanks for testing / writing the test!
00:15 < jonasschnelli> I knew that the backup restore is not something users can easily do.
00:15 < MarcoFalke> Correct, but there should be some way to do it
00:15 < jonasschnelli> Not sure if we should have something more convenient (backup restore) for 0.13
00:15 < jonasschnelli> Yes.
00:15 < jonasschnelli> Maybe we discuss this tonight at the IRC meeting
00:16 < MarcoFalke> oh
00:16 < MarcoFalke> I got it
00:16 < MarcoFalke> importprivkey breaks all future backups
00:16 < MarcoFalke> :(
00:16 < MarcoFalke> This should be fixed I assume
00:17 < MarcoFalke> Maybe a small fix in the rescan logic
00:17 < jonasschnelli> What's the reason for this?
00:17 < MarcoFalke> no idea
00:17 < jonasschnelli> Why does it breaks all future backups?
00:17 < jonasschnelli> *break
00:18 < MarcoFalke> Maybe only legacy keys are rescanned when there is at least one?
00:18 < MarcoFalke> Need to look into the code...
00:19 < 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
00:19 < jonasschnelli> Thanks for looking into the code
00:20 < 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
00:25 -!- davidlj95 [~davidlj95@deic-dyn-254.uab.es] has joined #bitcoin-core-dev
00:32 < MarcoFalke> More likely it is just a getbalance issue. I remember there were "some" issues lately
00:37 -!- rubensayshi [~ruben@82.201.93.170] has joined #bitcoin-core-dev
00:43 -!- rubensayshi [~ruben@82.201.93.170] has quit [Ping timeout: 264 seconds]
00:45 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
00:46 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
00:53 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
00:58 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
01:00 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
01:08 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 240 seconds]
01:09 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
01:38 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
01:40 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
01:51 -!- davidlj95 [~davidlj95@deic-dyn-254.uab.es] has quit [Ping timeout: 258 seconds]
01:53 -!- davidlj95 [~davidlj95@deic-dyn-254.uab.es] has joined #bitcoin-core-dev
01:53 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
02:10 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
02:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:17 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
02:17 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
02:38 <@wumpus> what's wrong with getbalance?
02:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:56 -!- davidlj95 [~davidlj95@deic-dyn-254.uab.es] has quit [Ping timeout: 244 seconds]
03:08 -!- Justinus [~Justinus@192.122.131.41] has quit [Remote host closed the connection]
03:39 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
03:45 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
03:48 -!- davidlj95 [~davidlj95@deic-dyn-232.uab.es] has joined #bitcoin-core-dev
03:52 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
04:25 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
04:32 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
04:50 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
05:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:22 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
05:52 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
06:03 -!- murch [~murch@p4FE39F1F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
06:33 -!- rubensayshi [~ruben@82.201.93.169] has quit [Ping timeout: 276 seconds]
06:49 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
06:54 -!- rubensayshi [~ruben@31.21.36.222] has joined #bitcoin-core-dev
06:54 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
07:17 -!- rubensayshi [~ruben@31.21.36.222] has quit [Ping timeout: 246 seconds]
07:23 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: ZNC 1.6.3 - http://znc.in]
07:33 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
07:51 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
07:56 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
08:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:29 < 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...
08:29 < 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
08:30 < jonasschnelli> Seems to work...
08:30 < jonasschnelli> Maybe need to check in conjunction with importprivkey...
08:31 -!- zooko [~user@73.95.138.235] has joined #bitcoin-core-dev
08:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:43 < 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
08:52 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
08:54 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev
08:54 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
08:54 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
08:57 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
09:05 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
09:21 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
10:05 -!- zooko [~user@73.95.138.235] has quit [Ping timeout: 260 seconds]
10:28 -!- zooko [~user@2601:281:8000:8387:3966:4b5a:81a:4ae6] has joined #bitcoin-core-dev
10:55 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
10:56 < MarcoFalke> IsMine returns false for the txs involving the HD keys
10:57 < 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
10:57 < zooko> We'll put in the time to merge it if desired.
10:58 < gmaxwell> cfields: ^
10:58 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
10:58 < zooko> I've asked Zcash engineer Taylor "earthrise" Hornby to support you on that if you want it.
10:58 < zooko> The _other_ one that I mentioned a few days back turned out to have a bug — we were
10:58 < cfields> zooko / gmaxwell: thanks
10:59 < zooko> trying to measure time to validate a block packed full of worst-case quadratic signature.
10:59 < zooko> And we were accidentally measuring time to check that the signature was already cached. ;-)
10:59 < zooko> But we've fixed that, and now we have some results.
11:00 < 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
11:00 < zooko> 35s for 1 MB block, 140s for 2 MB block
11:00 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
11:01 < cfields> zooko: hmm, i believe we already do those checks
11:01 < cfields> we might not verify FORTIFY_SOURCE, though
11:04 < cfields> zooko: mind pointing Taylor to "make check-security"? If there's a check we're missing, we would certainly add it
11:10  * michagogo watches a reindex fly by on his new Sandisk X400
11:11  * bsm117532 struts out his two RAID0 Samsung 950 Pros...for the reindex... ;-)
11:12 < michagogo> Heh, nice
11:13 < michagogo> Up to block 216k after about 40 minutes
11:18 < bsm117532> Yeah my reindex is CPU bound.
11:22 < gmaxwell> OT, but of interest: http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
11:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: cya'll]
11:39 < 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
11:41 -!- zooko [~user@2601:281:8000:8387:3966:4b5a:81a:4ae6] has quit [Ping timeout: 250 seconds]
11:45 < GitHub155> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/91abb77970f4...0cca2feb357a
11:45 < GitHub155> bitcoin/master fa6ad56 MarcoFalke: [travis] Update SDK_URL
11:45 < GitHub155> bitcoin/master 0cca2fe Jonas Schnelli: Merge #8304: [travis] Update SDK_URL...
11:45 < GitHub94> [bitcoin] jonasschnelli closed pull request #8304: [travis] Update SDK_URL (master...Mf1606-travisSDKURL) https://github.com/bitcoin/bitcoin/pull/8304
11:46 < 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?
11:46 < sipa> i have not looked into HKDF, but we should
11:47 < jonasschnelli> RFC: https://tools.ietf.org/html/rfc5869
11:49 < jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
11:54 -!- zooko [~user@2601:281:8000:8387:3966:4b5a:81a:4ae6] has joined #bitcoin-core-dev
11:55 < zooko> cfields: done: https://github.com/zcash/zcash/issues/1071
11:57 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
11:58 < jonasschnelli> gmaxwell: https://people.xiph.org/~greg/auth0.txt, why does AUTHCHALLENGE require "believed_server_pubkey"?
11:59 < 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.
11:59 < btcdrak> meeting time?
11:59 < jonasschnelli> yes
11:59 < petertodd> yup
11:59 < 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
12:00 <@wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Jul  7 19:00:10 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < cfields> gmaxwell: thanks. here.
12:00 < sdaftuar> hi
12:00 < gmaxwell> Welcome to meeting.
12:00 -!- instagibbs2 [~test@2607:fb90:1365:48b6:a772:25e6:b2d9:9058] has joined #bitcoin-core-dev
12:00 <@wumpus> proposed topic: 0.13.0rc1
12:00 < petertodd> wumpus: ack
12:00 < gmaxwell> This week was a week of many reverts. Reverting will continue until morale improves.
12:01 < michagogo> Hi
12:01 <@wumpus> #topic 0.13.0rc1
12:01 < sipa> somewhat present
12:01 < jonasschnelli> Are we +1 day with the 0.13 splitoff?
12:01 <@wumpus> foremost, I cannot build a release at this moment, as gitian lxc building is broken
12:01 < sdaftuar> wumpus: so there are a couple bugs that still need to be fixed for 0.13
12:01 < MarcoFalke> Is the HD issue a blocker for the rc?
12:01 <@wumpus> https://github.com/bitcoin/bitcoin/issues/8212 / https://github.com/bitcoin/bitcoin/pull/8213
12:01 < cfields> wumpus: ok. I'll handle those next.
12:01 <@wumpus> MarcoFalke: which HD issue?
12:02 < MarcoFalke> I couldn't restore from a HD backup
12:02 < jonasschnelli> I think there is no "real" HD issue
12:02 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
12:02 < michagogo> wumpus: Broken in what way?
12:02 <@wumpus> michagogo: please read the issues
12:02 < MarcoFalke> jonasschnelli: Could you look into the travis failure
12:02 < MarcoFalke> ?
12:02 < jonasschnelli> Yes. Will do..
12:02 < 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.
12:02 < michagogo> (Sorry, I've not had much free time for this stuff in the past months)
12:02  * michagogo goes to check
12:02 <@wumpus> if HD is broken, we have to disable  it for 0.13
12:02 < michagogo> (Gitian issues or Bitcoin Core?)
12:02 <@wumpus> or at least rc1
12:02 < MarcoFalke> gmaxwell: You can see the issue on travis
12:02 < jonasschnelli> Sure. Let me check MarcoFalke HD test
12:03 < MarcoFalke> It is either an error in my test code
12:03 < gmaxwell> Disabling it indeed would be an option.
12:03 < MarcoFalke> or some issue with IsMine() or something else
12:03 < gmaxwell> This may be a current design limitation if my understanding is correct. But I'm happy to discuss elsewhere/elsetime.
12:03 < MarcoFalke> I'd rather fix it than disable it
12:03 < cfields> MarcoFalke: link to travis failure?
12:03 <@wumpus> I don't want to block rc1 too long
12:03 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
12:03 <@wumpus> rather have a test release out as soon as possible
12:03 < btcdrak> remaining issue/prs for 0.13 https://github.com/bitcoin/bitcoin/milestones/0.13.0
12:04 < MarcoFalke> pull 8309
12:04 < MarcoFalke> cfields: ^
12:04 < gmaxwell> lets talk about the other things then move on to the hd issue as it's own topic.
12:04 < cfields> thanks
12:04 <@wumpus> planning was to do rc1 yesterday, but it was clear it wasn't possible
12:04 <@wumpus> btcdrak: some things can be merged as-is I think
12:04 < MarcoFalke> Also there are some issues open by sdaftuar
12:05 < 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
12:05 <@wumpus> #7678 (release notes) is a TODO for -final, not rc1, could use some help there though
12:06 <@wumpus> are they ready for merge?
12:06 < btcdrak> sdaftuar those should be tagged with the milestone then
12:06 < sipa> i will write some release notes for the tx relay changes
12:06 < sipa> (but not now)
12:06 < 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
12:06 <@wumpus> right, release notes is not urgent now, just needs to be done before final
12:06 <@wumpus> let's worry about rc1 now
12:07 < sdaftuar> #8305 and #8295 are done as far as i know
12:07 < sdaftuar> (no review though)
12:07 <@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
12:08 < gmaxwell> I've been very busy with testing, in fact.
12:08 <@wumpus> testing is good
12:08 <@wumpus> releasing rc1 will result in a lot of testing, too
12:09 < sipa> wumpus: i was less active the past week; i'll be back tomorrow
12:10 <@wumpus> ok I see jonasschnelli already added 0.13 milestone to sdaftuar's pulls, thanks
12:10 < jonasschnelli> Yes.
12:10 < 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
12:11 < petertodd> i'll try to look at 8312 this weekend
12:11 <@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
12:12 < cfields> wumpus: i can look into a quick-hack work-around for rc1. but iirc, it's hard to avoid until ubuntu fixes
12:13 <@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
12:13 < cfields> wumpus: quick alternative would bt c/p the descriptor to linux-arm.yml for now
12:14 < gmaxwell> will we be able to distribute arm linux binaries for 0.13? 
12:14 <@wumpus> gmaxwell: yes, that was done, but it has added an awkward requirement to the gitian build descriptor
12:14 < jonasschnelli> yes
12:15 < 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.
12:15 <@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)
12:16 < petertodd> wumpus: ack
12:17 <@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 :)
12:17 < cfields> ok
12:18 <@wumpus> #action wumpus contact devrandom about https://github.com/devrandom/gitian-builder/pull/123
12:18 < achow101> what about segwit deployment parameters
12:18 < btcdrak> achow101: not for 0.13.0
12:18 <@wumpus> we could add that as proposed topic, but not relevant for 0.13
12:19 < sipa> achow101: first backport to 0.12, figuring out cb+segwit, and planning releases
12:19 < btcdrak> achow101: it's explained in https://bitcoincore.org/en/lifecycle/#consensus-rules
12:19 < MarcoFalke> #action Help with review on https://github.com/bitcoin/bitcoin/milestone/20
12:19 <@wumpus> we're done with this topic though so i'm ok with switching
12:20 < gmaxwell> Okay can we talk briefly about the HD wallet thing? 
12:20 <@wumpus> #topic HD wallet issue
12:20 < sipa> what is the hd wallet issue number?
12:20 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8309/files
12:21 < jonasschnelli> Its a PR (failing test)
12:21 < jonasschnelli> currently looking at it.
12:21 < MarcoFalke> The rpc-test is pretty simple: usehd=1, then backup wallet.dat
12:21 < jonasschnelli> The addresses are re-generated deterministic... but somehow reindex fails..
12:21 < MarcoFalke> Do some transactions and discard wallet.dat
12:21 < 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.
12:21 < gmaxwell> But I could misunderstand.
12:22 < jonasschnelli> Yes. The simples HD feature does not cover restores...
12:22 < MarcoFalke> I am running rescan and reindex. None of it fixes it
12:22 < 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.
12:22 < jonasschnelli> Restore is manual work (including a rescan)
12:22 < gmaxwell> if a rescan isn't fixing it, thats a more serious issue than I was thinking.
12:23 < 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)
12:23 < jonasschnelli> Yes... I currently trying to find out why MarcoFalke test fails even after a rescan.
12:23 < 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.
12:23 <@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? 
12:23 < jonasschnelli> But IMO it's unrelated to HD,... the keys are recreated.
12:23 <@wumpus> yes, I think this scary, I don't think this is ready for a release
12:23 < gmaxwell> wumpus: it's the same keys every time, no defeating. 
12:23 < jonasschnelli> Sure. Let me first try to find the root cause before we consider a revert
12:24 < MarcoFalke> agree
12:24 <@wumpus> rever wouldn't be necessary, just default the flag to false
12:24 <@wumpus> it defaults to true for new wallets now which is what makes it scary if it would be somehow broken
12:24 < jonasschnelli> Sure. But we probably don't want to ship a (per default disabled) feature which _could_ includes bugs. :)
12:24 < 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. 
12:24 < petertodd> wumpus: is the flag documented in --help?
12:25 < 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.
12:25 < jonasschnelli> MarcoFalke: have you tried the test with HD disabled (just import your created keys)?
12:25 < gmaxwell> I haven't looked at it yet myself except passively watching the discussion.
12:26 < sipa> likewise
12:26 < sipa> i will look soon
12:26 < MarcoFalke> no
12:26 < jonasschnelli> I think without knowing the root cause of the problem actions are useless.
12:26 <@wumpus> agreed
12:26 < sipa> agree; we need to understand it
12:26 < jonasschnelli> I will know more about it in a couple of hours.
12:26 < sipa> and i believe there is plenty of time for that
12:27 <@wumpus> before when?
12:27 < 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.
12:27 <@wumpus> yes, need to disable it completely then, I agree
12:27 < jonasschnelli> Yes. But it could also be a serious import/rescan issue (not related to HD)
12:28 <@wumpus> the non-HD rescan test passes, right?
12:28 < MarcoFalke> yes
12:28 < sipa> i believe that rpc test is less elaborate
12:28 <@wumpus> did you try your new test without HD MarcoFalke?
12:28 < jonasschnelli> I think we would need the same test (that fails) without HD
12:29 < MarcoFalke> You can't create keys deterministically without HD
12:29 < jonasschnelli> I can see the exact keys in the wallet after the restore but I can see rescan failing to reconstruct the wtxs.
12:29 < sipa> no need to discuss the details here
12:29 <@wumpus> oh sure, you can't do exactly the dsame thing
12:29 < jonasschnelli> MarcoFalke: you could create 100 keys and reimport them...
12:30 < jonasschnelli> anyways,... I'll have a look at it and will report on the PR
12:30 < 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.
12:30 < jonasschnelli> ack
12:30 <@wumpus> right
12:30 <@wumpus> any other topics?
12:31 < gmaxwell> Sure, an announcement: 
12:31 < sipa> *crickets*
12:31 < jonasschnelli> oO
12:32  * petertodd braces for an incoming text wall
12:32 < 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.
12:32 < petertodd> +1
12:32 < jonasschnelli> Saw this. Impressive work! Well done.
12:33 < gmaxwell> (actually 98% of the time in the last day)
12:33 < btcdrak> Also the FIBRE website is http://bitcoinfibre.org/
12:33 < cfields> nice!
12:33 <@wumpus> awesome!
12:33 < gmaxwell> And his deployment uses only cheap VPSes. 
12:33 < sipa> wow, i saw the website but hadn't appreciated how good the numbers were
12:33 < sipa> i just looked at how oretty the graphs were
12:33 < 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. :)
12:34 < sipa> we need neutrino-based transmissions.
12:34 < petertodd> sipa: lol, I was just about to say
12:34 < gmaxwell> Stats are at http://bitcoinrelaynetwork.org/stats_ng.html   there is also plety of room to improve the software/protocol still.
12:34 < petertodd> sipa: reminds me, I wrote a short story about that awhile back...
12:35 <@wumpus> neutrono-based transmissions are easy, compared to the receiver part :)
12:35 < btcdrak> The github project is at https://github.com/bitcoinfibre
12:35 < petertodd> wumpus: what? don't you have a few tonnes of heavy water laying around?
12:36 < 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.
12:36 < sipa> i believe production of heavy water may be more decentralized than sha256 asic mining production.
12:37 < petertodd> sipa: yes! https://www.youtube.com/watch?v=Sxl78pWW8Vk
12:38 < 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. :(
12:38 <@wumpus> petertodd: of course I do, but not enough shielded undergorund space to put it
12:39 < 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.
12:39 < petertodd> wumpus: that's why I took up caving
12:39 -!- anchow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
12:40 < cfields> gmaxwell: what's the reason for an additional binary?
12:40 < cfields> gmaxwell: oh, you mean default to testnet until final release?
12:40 <@wumpus> gmaxwell: we could do that now, eg before the rc1
12:40 <@wumpus> well at least if I could build releases, dang
12:40 < 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.
12:41 -!- anchow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has quit [Client Quit]
12:41 <@wumpus> cfields: not the rc1 itself, more like a master-build-with-only-testnet-enabled
12:41 < 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.
12:41 <@wumpus> rc1 should definitely have mainnet by default, like any rc
12:42 -!- kxie [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has joined #bitcoin-core-dev
12:42 <@wumpus> gmaxwell: did you see #8285? it's super-easy now for windows GUI users
12:42 < cfields> hmm
12:42 < 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
12:42 < petertodd> gmaxwell: I wonder if a wrapper script with -testnet would help those users?
12:42 < gmaxwell> but perhaps thats too much for now. :)
12:43 <@wumpus> https://github.com/bitcoin/bitcoin/pull/8285 exactly does that
12:43 < cfields> wumpus: ah nice, i missed that
12:43 < gmaxwell> I didn't see it.
12:43 < gmaxwell> (or forgot seeing it!)
12:43 < petertodd> wumpus: ah cool, thanks!
12:44 < gmaxwell> Thats really awesome.
12:44 < petertodd> wumpus: just like mainnet/testnet wallets on my android phone
12:44 < 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.
12:44 <@wumpus> petertodd: indeed, bitcoin wallet for android has been doing a similar thing
12:44 < gmaxwell> if you could do builds. :P
12:46 < cfields> heh, hint taken. Working on the split descriptors now.
12:46 <@wumpus> thanks cfields
12:47 <@wumpus> any other topics?
12:47 < petertodd> wumpus: happy halving day :
12:47 < petertodd> )
12:47 < petertodd> :)
12:48 <@wumpus> hah, same to you
12:48 < gmaxwell> I wonder if there is some scifi where halving day is where half the people die? it seems right.
12:48 < petertodd> wumpus: I'll be hiding in a cave most of that day fyi - so if the world ends don't call me :P
12:49 < petertodd> gmaxwell: satoshi should have made it a 10% think, so we could call it DECIMATION DAY
12:49 < petertodd> *thing
12:49 <@wumpus> petertodd: that sounds like a wise thing to do, hide in a cave until it blows over 
12:49 < sipa> i wish i had a cave here
12:49 < sipa> i'm in the middle of paris
12:50 < sipa> and there is some football thing
12:50 < petertodd> sipa: you've got the most awesome sewer system, and the catacombs!
12:50 < gmaxwell> sipa: catacombs.
12:50 < sipa> catacombs close in 10 minutes.
12:50 < petertodd> sipa: "officially" speaking...
12:51 < 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)
12:51 < sipa> hah.
12:51 < jonasschnelli> All light are green. :)
12:51 < sipa> yay
12:51 < gmaxwell> pfft. plenty of people have gone after hours and spent the rest of their lives there.
12:51 < jonasschnelli>  self.node_args[1].extend(['-rescan']) should be  self.node_args[1] + ['-rescan']
12:51 < MarcoFalke> Wow
12:52 <@wumpus> jonasschnelli: wow, very good news, and you found it within the meeting :D 
12:52 < petertodd> jonasschnelli: oh, is node_args[1] a tuple?
12:52 < 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.
12:52 < jonasschnelli> I'm not familiar with extend() but seems to be the wrong function for that purpose.
12:53 < jonasschnelli> But I guess we want MarcoFalke's RPC test in 0.13! :)
12:53 < petertodd> jonasschnelli: extend() is list only, and modifies in place
12:53 <@wumpus> yes, extend is in place and returns nothing
12:54 < jonasschnelli> At least we tested again the HD feature... 
12:54 < sipa> 6 minutes
12:54 < sipa> are we done?
12:54 < gmaxwell> sipa: until we lose you to the catacombs?
12:54 <@wumpus> I think so?
12:55 <@wumpus> #endmeeting
12:55 < lightningbot> Meeting ended Thu Jul  7 19:55:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:55 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.html
12:55 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.txt
12:55 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-07-19.00.log.html
12:56 < 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
12:56 < 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!
12:57 < btcdrak> looks like it's working agian
12:57 < jonasschnelli> gmaxwell: re https://people.xiph.org/~greg/auth0.txt, can the client fingerprint the serve by just getting a 64byte compact ECsig?
12:57 <@wumpus> sdaftuar: agree with leaving it untranslated
12:57 < jonasschnelli> *server
12:57 < sdaftuar> wumpus: ok thanks!
12:57 < gmaxwell> jonasschnelli: Not unless it knows the public key.
12:58 < jonasschnelli> I just try to find a/the concrete reason for the believed_server_pubkey in H(session_id || "1" || believed_server_pubkey)
12:58 < gmaxwell> jonasschnelli: If the server has no match for X1 the protocol is just filled with padding at that point.
12:58 < jonasschnelli> How could the client fingerprint when believed_server_pubkey would not be there? 
12:58 <@wumpus> sdaftuar: I think some of the InitWarnings are translated, but anyhow, nothing new is going to get translated for 0.13.0
12:58 < 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)
12:58 -!- instagibbs2 [~test@2607:fb90:1365:48b6:a772:25e6:b2d9:9058] has quit [Quit: Hermes - Material IRC Client - https://numixproject.org/]
12:59 <@wumpus> sdaftuar: and it's going to be a rare message for people to see, so even otherwise probably a waste of translators time :)
12:59 < 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. 
12:59 < 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
13:00 < jonasschnelli> gmaxwell: ah... even for standard compact normalized signatures?
13:00 < sdaftuar> versus doign a LogPrint() or something
13:01 < jonasschnelli> gmaxwell: I thought in order to do this, it would require a recoverable signature (something like libsecp256k1s secp256k1_ecdsa_recoverable_signature_serialize_compact)
13:02 <@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
13:02 < 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.
13:11 < gmaxwell> jonasschnelli: Does it make sense now?
13:16 < jonasschnelli> gmaxwell: Okay. Got it. Thanks for the patience to explain.
13:27 < bsm117532> Maybe I'm missing something...why does BIP 144 not define this transaction format as nVersion=2?
13:27 < sipa> because it does not add anything
13:27 < sipa> nVersion is part of the transaction data
13:28 < sipa> so you can't modify it upon relay
13:28 < sipa> bip144 adds an extra serialization flag that is not hashed into the txid
13:29 < gmaxwell> jonasschnelli: no problem.
13:29 < 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?
13:29 < bsm117532> 01000000000101ca3cd3084fee7a0a4746f7b41ce65c6f0778b6643515d4ad07798ee70a374b470000000016001486553e1ea2d97539d116fe878b2d3c69f6eb4faaffffffff01a01cc10767ffffff160014963f8e056d9aff20bc8ae5a0126e33ea9b2e399d6b483045022100b664937800fd386e936ac4b340d86c1417e5257ec9308879b96a2a9761a7c8ec022056f25e9e898968c0acf97fec8a0f501af9b0c19a9bcfc3cbd95c75d32c9895870121036efd8cc9de281efe42ef653c4abbb9459024e336cc4fe56622e68c6aa2574e1800000000
13:30 < 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
13:30 < sipa> message cut off
13:31 < sipa> can you paste it somewhere?
13:31 < bsm117532> Sure
13:32 < bsm117532> https://www.zerobin.net/?5f1a8550abf9f104#t/ID9UEgNXlzp7m3Vr31/Vvz7I5GwWfnNMGqF7Rkbg0=
13:33 < bsm117532> Hmmm that output is clearly borked.
13:34 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 250 seconds]
13:35 < bsm117532> Would bitcoin-cli decoderawtransaction abort due to the negative output there?  That might be my problem...
13:35 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
13:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
13:37 < bsm117532> Decoderawtransaction still doesn't like it after making that output positive: https://www.zerobin.net/?afb35cd1b41acb5e#EXgtfGe6+ZRZinaximJV0ptmxbqNDqF4nI71HDF3/I8=
13:40 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
13:56  * bsm117532 finds a test vector in BIP 143...
14:00 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
14:05 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
14:16 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []
14:52 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
15:00 < sipa> bsm117532: negative output?
15:00 < bsm117532> I fixed that, it wasn't the problem.
15:01 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
15:01 < 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.
15:03 < sipa> OP_0 <hashed pubkey> goes into the output
15:04 < sipa> the scriptSig spending segwit outouts is always empty
15:04 < bsm117532> I'm also missing the array length in the witness.
15:04 < sipa> unless it's P2SH
15:04 < bsm117532> Ok, gotcha
15:06 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
15:21 -!- murch [~murch@p4FE39F1F.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
15:22 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving]
15:25 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
15:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]
15:29 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
15:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
16:03 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
16:08 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
16:13 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:14 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Disconnected by services]
16:15 -!- justanot1eruser is now known as justanotheruser
16:21 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
16:35 -!- bitcoin-core-dev [46b70690@gateway/web/freenode/ip.70.183.6.144] has joined #bitcoin-core-dev
16:36 -!- bitcoin-core-dev [46b70690@gateway/web/freenode/ip.70.183.6.144] has quit [Client Quit]
17:04 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
17:09 -!- fengling [~fengling@58.135.95.137] has quit [Ping timeout: 240 seconds]
17:16 < GitHub177> [bitcoin] theuni opened pull request #8315: gitian: Don't require sudo for Linux. (master...gitian-no-sudo) https://github.com/bitcoin/bitcoin/pull/8315
18:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-gitenwozpomznzik] has quit [Quit: Connection closed for inactivity]
18:06 -!- fengling [~fengling@58.135.95.137] has joined #bitcoin-core-dev
18:25 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:24 -!- zooko [~user@2601:281:8000:8387:3966:4b5a:81a:4ae6] has quit [Ping timeout: 250 seconds]
20:55 < kanzure> hm http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
21:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds]
21:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:13 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
21:16 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
21:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
21:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
21:31 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
22:53 -!- kxie [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has quit [Quit: Page closed]
23:10 -!- Anduck [~anduck@unaffiliated/anduck] has joined #bitcoin-core-dev
23:20 < GitHub85> [bitcoin] laanwj closed pull request #8213: gitian: Move as-root preparation to gitian prepare script (master...2016_06_gitian_linux_prepare_script) https://github.com/bitcoin/bitcoin/pull/8213
23:26 -!- JackH [~Jack@79.73.186.51] has quit [Ping timeout: 260 seconds]
23:32 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lpzcqtneknqiijjz] has joined #bitcoin-core-dev
23:37 < GitHub137> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0cca2feb357a...6ae20df823d1
23:37 < GitHub137> bitcoin/master cf2ef78 Cory Fields: build: require boost for bench
23:37 < GitHub137> bitcoin/master 6ae20df Wladimir J. van der Laan: Merge #8310: build: require boost for bench...
23:37 < GitHub58> [bitcoin] laanwj closed pull request #8310: build: require boost for bench (master...fix-bench-boost) https://github.com/bitcoin/bitcoin/pull/8310