--- Day changed Thu Jul 14 2016 00:00 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] 00:00 < xinxi> sipa: are you there? 00:06 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 00:22 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection] 00:22 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 01:00 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 01:06 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev 01:08 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 01:09 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:14 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 01:19 -!- face [~face@mail.hmel.org] has quit [Read error: Connection reset by peer] 01:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:31 < GitHub51> [bitcoin] MarcoFalke opened pull request #8340: [qa] Solve merge conflict of 4324bd237c3147fc153ba5046c211f03e8ac956a (master...Mf1607-qaSolveMerge) https://github.com/bitcoin/bitcoin/pull/8340 01:59 < GitHub128> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca40ef6029c1...af9b7a9f2f73 01:59 < GitHub128> bitcoin/master 66668c4 MarcoFalke: [qa] Solve merge conflict of 4324bd237c3147fc153ba5046c211f03e8ac956a 01:59 < GitHub128> bitcoin/master af9b7a9 MarcoFalke: Merge #8340: [qa] Solve trivial merge conflict in p2p-segwit.py... 01:59 < GitHub111> [bitcoin] MarcoFalke closed pull request #8340: [qa] Solve trivial merge conflict in p2p-segwit.py (master...Mf1607-qaSolveMerge) https://github.com/bitcoin/bitcoin/pull/8340 02:02 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 02:38 < GitHub179> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/af9b7a9f2f73...bc94b8748782 02:38 < GitHub179> bitcoin/master b993671 Jonas Schnelli: [Wallet] keep HD seed during salvagewallet 02:38 < GitHub179> bitcoin/master bc94b87 Wladimir J. van der Laan: Merge #8324: [Wallet] keep HD seed during salvagewallet... 02:38 < GitHub199> [bitcoin] laanwj closed pull request #8324: [Wallet] keep HD seed during salvagewallet (master...2016/07/hd_salvage) https://github.com/bitcoin/bitcoin/pull/8324 02:47 -!- arubi [~ese168@unaffiliated/arubi] has quit [Quit: Leaving] 02:48 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 02:53 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection] 02:54 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 03:26 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection] 03:26 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 03:30 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 03:33 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 03:42 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection] 03:48 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hwqmhagmhmcaxfcc] has joined #bitcoin-core-dev 04:02 -!- chris200_ [~chris2000@p5DCB47C6.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 04:06 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 04:12 -!- mkarrer [~mkarrer@190.red-81-35-195.dynamicip.rima-tde.net] has quit [Ping timeout: 260 seconds] 04:14 -!- chris200_ [~chris2000@p5DCB47C6.dip0.t-ipconnect.de] has quit [] 04:15 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 04:24 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 04:24 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection] 04:24 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 04:25 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection] 04:26 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 04:31 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 04:33 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 04:34 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:02 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 05:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit] 05:28 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 05:32 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 05:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 05:55 < jtimon> NicolasDorier: updated https://github.com/jtimon/bitcoin/commits/0.12.99-consensus VerifyTx just lacks CheckTransaction (because it would be redundant with the call in CheckBlock()) now in there 06:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:07 -!- knightdk [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 06:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 06:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:12 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 06:23 < jtimon> jonasschnelli: what do you think I should do with the consensus PRs ? 06:23 < jonasschnelli> jtimon: I think you should do one small step after another... 06:24 < jtimon> those are 3 small steps one after the other 06:24 < jonasschnelli> But they do include the same commits. 06:24 < jtimon> imagine someone reviewed more than 2 of those little steps 06:24 < jonasschnelli> I think you should open only one PR ... 06:24 < jtimon> yeah, that's the "one after the other" part 06:25 < jonasschnelli> IMO the past has shown that we have not enough reviwers for the consensus parts.. 06:25 < jonasschnelli> This is why I think one PR at the time would be more efficient. 06:25 < sipa> i'm fine with the pure move consensus code PRs, after 0.13 branches off 06:25 < jtimon> jonasschnelli : so we should just give up? 06:25 < jonasschnelli> jtimon: no... sure not! 06:25 < sipa> for everything else (encapsulation, API)... *please* first document first 06:26 < jonasschnelli> I just think you will have more reviwers if there are clear distortable/small PRs 06:26 -!- mkarrer [~mkarrer@190.red-81-35-195.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 06:26 < jonasschnelli> jtimon: to have that said: I'm a big fan of the consensus encapsulation and I appreciate your work! 06:26 < jonasschnelli> I just try to optimize the workflow on that part 06:27 < jtimon> jonasschnelli: you can review one PR at a time, I was just hoping that some people would show more interest than that, they're actually pretty trivial 06:28 < sipa> same goes for NicolasDorier by the way 06:28 < sipa> these are big architectural changes, and i think everyone needs to be on board before going one way or another 06:28 < jonasschnelli> jtimon: I just think you will have more reviewers if you just focus on one PR 06:28 < jtimon> none of the open PRs are big architectural changes, one it's renaming files and the other 2 are moveonly 06:29 < sipa> jtimon: that's all fine 06:29 < jtimon> in https://github.com/jtimon/bitcoin/commits/0.12.99-consensus there are big architectural changes though 06:29 < sipa> jtimon: sorry, i think i've developed selective blindness for any PRs that mention consensus refactors 06:29 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 06:29 < jtimon> sipa: I could easily believe that 06:30 < jonasschnelli> sipa: while you are around (heh!), mind doing a quick review on https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/bip151_hkdf? Only technical, language will be checked by Jonathan Cross 06:31 < sipa> jonasschnelli: sorry, i need to read up on HKDF first 06:31 < jonasschnelli> sipa: sure: https://tools.ietf.org/html/rfc5869 06:32 < jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c 06:33 -!- anchow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 06:34 -!- knightdk [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has left #bitcoin-core-dev ["Leaving"] 06:34 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 06:34 -!- anchow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has quit [Client Quit] 06:37 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 06:37 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 06:38 < afk11> I can't wait for there to be more code to write bindings to. jtimon please keep going, I see what you're doing :) 06:40 < jtimon> afk11: thak you that's encouraging, but some review on #8337 (which contains #8329 (which contains #8328 )) would be much more encouraging :p 06:41 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has joined #bitcoin-core-dev 06:41 < jtimon> if people can't review the trivial things then they will never review the cool stuff like https://github.com/jtimon/bitcoin/commit/4215929d563097f19d8059dff8b0f7d5ba7aee59 06:42 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:42 < jtimon> in my plans I was thinking #8328 much later, but people keep f##$%^ing creating consensus files out of the consensus dir 06:43 < paveljanik> jtimon, just nACK them... 06:43 < sipa> jtimon: it's not always obvious 06:44 < sipa> jtimon: should prevector be in consensus, for example? 06:44 < sipa> consensus logic depends on it, but it's implementing a standard interface, and is more generically useful 06:44 < jtimon> sipa I would say prevector and versionbits were pretty obvious, you even asked me for versionbits, you even had it in the consensus dir and then for some reason you moved it out 06:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 06:45 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 06:45 < jtimon> prevector is a dependency of uint256, no? 06:45 < sipa> no 06:45 < sipa> it is of CScript 06:46 < jtimon> oh, yeah 06:46 < sipa> but even that... i'm not sure CScript storage in the long term belongs in consensus 06:46 < jtimon> I mean, prevector is currently needed in libconsensus for verifyScript 06:47 < sipa> ok, so your view that all dependencies for libconsensus (currently or in the near future) belong in the consensus/ directory? 06:47 < jtimon> well, let's start with the short term and complete libconsensus, no? in the long term I would change it from C++ to C... 06:47 < sipa> i'm just trying to understand your view 06:48 < sipa> i think you've thought this true, and have a good picture in your head of what belongs where 06:48 < sipa> but it's not obvious to me 06:48 < sipa> should everything that libconsensus depends on be in the consensus/ directory? 06:48 < jtimon> sipa: yes, and in the consensus packages only if they only depend on other things from consensus, crypto or libsecp256k1 (for example, pow is not ready for the consensus package because it still depends on chain.h) 06:49 < sipa> jtimon: so script/script.h, script/interpreter, primitives/*, ... move to consensus? 06:50 < jtimon> well, right now it's just a few that I'm renaming that are not required by current libconsensus (block, pow, utilmoneystr...) 06:50 < sipa> i 06:50 < sipa> i 06:50 < sipa> grrr! 06:51 < sipa> i'm not really talking about current PRs 06:51 < sipa> just about what you believe belongs where 06:51 < jtimon> I think it takes less time to read the changes in the makefile https://github.com/bitcoin/bitcoin/pull/8328/files#diff-480477e89f9b6ddafb30c4383dcdd705R90 than explaining but whatever... 06:51 < sipa> jtimon: i am not talking about your current PRs... 06:52 < jtimon> everything that's going to be needed for a complete libconsensus exposing verifyblock 06:52 < sipa> ok, thank you 06:52 < jtimon> sipa: that's fine, but there's a list right there 06:52 < sipa> does that include primitives? 06:52 < jtimon> yes, of course 06:52 < sipa> ok 06:53 < sipa> so if in a later stage i want to be able to build an SPV wallet from the codebase, and don't want to include the full consensus logic 06:53 < sipa> the wallet would still depend on the primitives inside the consensus directory? 06:53 < jtimon> in fact I forgot sigache in that PR, that will be needed too I guess 06:54 -!- arubi [~ese168@unaffiliated/arubi] has quit [Remote host closed the connection] 06:54 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 06:55 < jtimon> sipa: yeah at some point if we want to completely separate libconsensus, after bitcoin core itself calls its API, I see no other option than to duplicate some of the code in bitcoin core, but seems too far away in the future to be a big concern 06:55 < sipa> fair enough 06:55 < jtimon> first step is completing libconsensus while allowing bitcoin core to keep using its internals 06:56 < sipa> my expectation (but i don't care strongly) was that we'd have more than 1 layer... primitives being the lowest one with just serialization/data structures, and then consensus being allowed to depend on primitives but nothing else 06:56 < jtimon> I mean, the renaming (moving to the consensus dir) can be done at any time, but I think it makes things clearer 06:56 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection] 06:56 < sipa> sure 06:56 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 06:57 < jtimon> well, my expectation is that consensus is the lowest layer, it exposes function of different layers I guess (ie script tx header block) 06:57 -!- YOU-JI [~youyouyou@w190101.dynamic.ppp.asahi-net.or.jp] has joined #bitcoin-core-dev 06:57 -!- ebfull [~sean@c-50-170-183-94.hsd1.co.comcast.net] has quit [Quit: leaving] 06:59 < jtimon> I mean, the lowest layer is really the crypto dir and libsecp 07:00 < sipa> do those also move to consensus/ ? 07:00 < sipa> not all of crypto/ is needed in consensus 07:00 < jtimon> only one hash function wasn't last time I checked IIRC 07:00 < jtimon> but well, they're in the crypto dir already so... 07:01 < sipa> hmac, rfc6979, aes, sha512 07:01 < sipa> those are not needed in consensus 07:01 < jtimon> the whole folder is currently being built for libconsensus 07:01 < sipa> i'm aware 07:01 < sipa> (but i'm not sure that's a good thing) 07:02 < jtimon> yeah I have my doubts there too, it's not clear to me what do do with that when/if we want to make libconsensus a subtree or something 07:04 < jtimon> so I wouldn't oppose to take hmac, rfc6979, aes, sha512 out of libconsensus, but I'm not sure it's worth the effort 07:04 < jtimon> it's only touching the makefile anyway 07:05 < sipa> well, we'd be breaking apart script/ too 07:05 < jtimon> well, yeah, script is already being built in different packages 07:06 < jtimon> some are not consensus code like sign and standard 07:06 < sipa> indeed 07:06 < jtimon> what do you think about utilmoneystr ? 07:07 -!- YOU-JI [~youyouyou@w190101.dynamic.ppp.asahi-net.or.jp] has quit [Quit: Leaving...] 07:07 < sipa> i don't think string conversions belong in consensus 07:08 < jtimon> I believe we need it for this single error message: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1959 07:08 < jtimon> maaku was against leaving it out 07:08 < jtimon> but we could just print satoshis 07:09 < sipa> ideally consensus logic doesn't need to contain any error strings 07:10 < sipa> but the alternative is defining huge enums of error constants 07:17 < jtimon> I'm fine with having tinyformat for now, it's tiny, it says so in the name 07:17 < jtimon> but yeah, I guess the enum is what errorScript was about 07:20 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:26 < jeremyrubin> cfields: I was profiling prevector the other day, and was just thinking about switching it to move for CScript -- beat me to it, nice work :) 07:26 < cfields> jeremyrubin: heh, thanks. yea, profiling showed it to be very slow for copy/move. I'd be curious to see if you see similar results in the bench 07:27 < cfields> moves don't happen much in the current code (but will later), but lots of copies. 07:28 < jeremyrubin> yeah will profile it later today 07:29 < cfields> jeremyrubin: there's a bench in that commit. just 'git checkout HEAD~1 -- prevector.h' and rebuild to get the before numbers. 07:30 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 07:35 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 07:37 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 07:40 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:51 -!- cool_guy [~coolguy@c-73-208-30-216.hsd1.il.comcast.net] has joined #bitcoin-core-dev 07:51 < cool_guy> ASTOUNDING! I have discovered blockchain exploding technology. Send me your bitcoin and I will return MUCH more back to you, INSTANTLY. This is totally legitimate & vouched by the OPS of this channel. PM me to begin! 07:52 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ 07:52 -!- mode/#bitcoin-core-dev [+b *!*coolguy@*.hsd1.il.comcast.net] by sipa 07:52 -!- cool_guy was kicked from #bitcoin-core-dev by sipa [cool_guy] 07:58 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 08:02 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 08:03 -!- d_t [~textual@185.69.203.10] has quit [Read error: No route to host] 08:03 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 08:04 -!- d_t [~textual@185.69.203.10] has quit [Client Quit] 08:05 -!- xinxi [~xinxi@116.86.156.222] has quit [Read error: Connection reset by peer] 08:05 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 08:20 < morcos> cfields: i couldn't get your copy-move branch to compile. 08:20 < morcos> ./prevector.h:253:23: error: 'is_trivially_copyable' is not a member of 'std' 08:21 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 08:21 -!- zooko [~user@68.233.157.2] has joined #bitcoin-core-dev 08:23 < jeremyrubin> morcos: upgrade your compiler http://stackoverflow.com/questions/25123458/is-trivially-copyable-is-not-a-member-of-std 08:23 < jeremyrubin> cfields: maybe add these ifdef's for compat 08:32 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 08:36 < cfields> morcos: blah, just comment them out for now. they don't do anything other than throw an error if you try to (for ex) prevector<28, std::string> 08:37 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:37 < cfields> morcos: i'll try to find a trait implemented earlier 08:37 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 08:42 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 08:54 < cfields> looks like std::is_pod should work, need to double-check its guarantees though 08:57 <@sipa> when i want information about some standard library function, i usually just type it into my url bar 08:57 -!- mode/#bitcoin-core-dev [-o sipa] by sipa 08:58 < sipa> unfortunately, the browser interprets std:: as an address scheme 08:59 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:01 -!- xinxi [~xinxi@116.86.156.222] has quit [Read error: Connection reset by peer] 09:02 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 09:03 < cfields> heh 09:05 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 09:15 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 09:15 -!- d_t [~textual@185.69.203.10] has quit [Max SendQ exceeded] 09:16 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev 09:21 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:24 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion] 09:25 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 09:28 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Client Quit] 09:32 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 09:34 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 09:38 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 09:39 <@wumpus> putting " around it usually helps 09:42 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 09:47 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:54 -!- zooko [~user@68.233.157.2] has quit [Ping timeout: 264 seconds] 09:57 -!- zooko [~user@68.233.157.2] has joined #bitcoin-core-dev 10:20 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 10:21 -!- harrymm [~wayne@178.162.214.48] has joined #bitcoin-core-dev 10:21 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 10:23 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 258 seconds] 10:23 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 10:25 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 10:30 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 10:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:32 < bsm2357> So I have some confusion about OP_CODESEPARATOR and segwit. I don't see anywhere that the OP_CODESEPARATOR manipulations are actually performed when creating a SignatureHash. Is this just the responsibility of the caller to know what to do with OP_CODESEPARATOR? 10:33 < sipa> the placement of codeseparators influences what is passed as scriptCode to signaturehash 10:35 < sipa> note that codeseparators are assumed to be useless in their current form 10:35 < bsm2357> Heh 10:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 10:35 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 10:35 < bsm2357> Ok then client code. (I'm copying test cases from BIP143) 10:36 < sipa> but you should already be doing that 10:36 < sipa> bip143 does not affect the behaviour of code separators 10:38 < bsm2357> python-bitcoinlib is still annoying low-level. AFAICT it doesn't have any "sign transaction" function that would do this. It's up to you to manually call SignatureHash. 10:39 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 258 seconds] 10:40 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 10:42 < kanzure> SignatureHash isn't so bad 10:42 < kanzure> (besides the strange name; i appreciate jl2012's signature digest algorithm name idea) 10:44 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 10:44 -!- delinquentme [6c4d88e2@gateway/web/cgi-irc/kiwiirc.com/ip.108.77.136.226] has joined #bitcoin-core-dev 10:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:53 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 258 seconds] 10:59 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 11:09 < jtimon> meeting is now or in an hour? 11:11 < eragmus> jtimon: 49 min. 11:12 < jtimon> eragmus: yeah, thanks, it definitely didn't look like it was now ;) 11:12 < morcos> sipa: all the "inexpensive" checks in CheckInputs and CheckTxInputs are not parallelized. but with a signature cache and libsecp, those "inexpensive" checks are taking up almost all the time... would it make sense to bring all input level checks into what is now CScriptCheck? 11:15 < sipa> morcos: i always assumed the inexpensive checks are actually not expensive 11:15 < sipa> only fetching of the inputs is 11:15 < sipa> am i wrong 11:15 < sipa> ? 11:16 < morcos> sipa: i'm about to try to separately bench UpdateCoins 11:16 < morcos> but do you think the fetching is expensive if we are caching well? 11:16 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds] 11:17 < morcos> i mean i'm testing this with a huge cache, but it would be nice to know if we can increase our cache hit rate with a smarter hot caches, how much it can benefit us 11:18 < morcos> i'll do some benching to see, but just wondering if there was a more fundamental reason not to go in this direction if it helps 11:19 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 11:24 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds] 11:26 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:27 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 11:30 < morcos> sipa: yeah i think with a good dbcache then UpdateCoins is a small fraction of the time spent in " - Connect %u transactions". Like 15% of the time. 11:32 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds] 11:33 < morcos> When I get a chance, I'll test out moving many more of the input checks into the parallelized part. 11:35 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 11:37 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 11:37 < bsm2357> I'm still having a bit of trouble with segwit transactions, I'm getting error: 64: non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element). sipa or somebody, would you be so kind as to take a look at this tx and tell me if you see anything wrong? https://www.zerobin.net/?94c4f0fb71e982a1#Uc3l1MLgEB+W0izaZXvb7BohI6rMBxxuK6CzTWHh7fo= 11:37 < bsm2357> It's a P2WPKH so I'm confused, the script is implicit 11:38 < sipa> bsm2357: make bitcoind print out the signaturehash it is checking 11:38 < sipa> and compare that to the value you're signing 11:39 < bsm2357> This may still be a bad sighash then? 11:41 -!- yep [5ce333f1@gateway/web/freenode/ip.92.227.51.241] has joined #bitcoin-core-dev 11:41 < sdaftuar> bsm2357: you might find it helpful to review the p2p-segwit.py test in qa/rpc-tests, see for instance https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/p2p-segwit.py#L1236 11:41 < bsm2357> Ah nm, need to pass SIGVERSION_WITNESS_V0 to *use* the new SignatureHash... 11:41 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 11:42 < bsm2357> Thanks sdaftuar I've been reviewing that for days ;-) 11:42 < sdaftuar> haha okay :) 11:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 11:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:58 < morcos> sipa: as you may have realized, i was only measuring UpdateCoins, when of course HaveInputs is the big issue, thats another 40% of the time.. Still, room to improve, and I want to see how much HaveInputs can come down with more perfect caching. 11:59 <@wumpus> meeting time? 11:59 < jl2012> bsm2357: there are some test vectors in BIP143 12:00 < bsm2357> I know, I wrote tests for them! They all pass. :-P 12:00 < bsm2357> Thanks for that ;-) 12:00 < sipa> wumpus: ack 12:00 <@wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Jul 14 19:00:52 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 < instagibbs> actually here this time 12:01 < cfields> gmaxwell: ping for pings :) 12:01 <@wumpus> gmaxwell jonasschnelli sdaftuar jtimon kanzure MarcoFalke 12:01 < jonasschnelli> pong 12:02 <@wumpus> topic suggestions? 12:02 -!- gabridome [~gabridome@5.90.45.232] has joined #bitcoin-core-dev 12:02 < jonasschnelli> proposal: open 0.13 PRs (https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0) 12:02 <@wumpus> (besides 0.13.0rc1) 12:02 < instagibbs> segwit backport? 12:02 < sipa> ack topic 12:03 <@wumpus> #topic 0.13.0rc1 12:03 <@wumpus> #link https://github.com/bitcoin/bitcoin/milestone/20 12:03 < 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:03 < jonasschnelli> I have opened #8323 some days ago and I think we need to have this in 0.13 to avoid later HD/non-HD mix problems 12:03 <@wumpus> most of the remaining PRs have been merged, but there are still a few open 12:04 < jonasschnelli> I beg for reviews... 12:04 < instagibbs> jonasschnelli, I can review 12:04 <@wumpus> #link https://github.com/bitcoin/bitcoin/pull/8305 Improve handling of unconnecting headers by sdaftuar 12:04 <@wumpus> #link https://github.com/bitcoin/bitcoin/pull/8295 Mining-related fixups for 0.13.0 also by sdaftuar 12:04 <@wumpus> and jonasschnelli's 12:05 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8323 12:05 < instagibbs> #link https://github.com/bitcoin/bitcoin/pull/8323 12:05 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has left #bitcoin-core-dev ["Leaving"] 12:05 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 12:05 <@wumpus> I think #8305 is pretty much ready 12:06 <@wumpus> has ACK by sipa and is being tested by gmaxwell 12:06 < sdaftuar> i think sipa acked an earlier version of the code 12:06 < bsm2357> pong 12:06 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds] 12:06 < instagibbs> jeremyrubin *ping* 12:07 <@wumpus> cfields: has your comment there been addressed sufficiently? 12:07 < sdaftuar> oh, thanks sipa :) 12:07 -!- bsm2357 is now known as bsm117532 12:07 < cfields> wumpus: yes, i'm happy with the slow DOS trickle 12:08 < jeremyrubin> instagibbs: yes? 12:08 <@wumpus> as for #8295, mining changes are always harder to get people to review/test, I'd encourage people to get involved, though I see sipa ACKed that one too 12:09 < sipa> yeah, the reason i didn't include telhr 8295 approach myself was because i incorectly assumed it would require extra counters 12:09 <@wumpus> jonasschnelli: #8323 still has some open comments 12:09 < sipa> and the existing tests cover it 12:09 <@wumpus> trivial things though 12:09 < MarcoFalke> no blockers 12:09 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 12:09 < jonasschnelli> Yes. paveljanik just added some... will fix the trivials together (once there are some) 12:10 < morcos> sipa: are you referring to mining unit tests? 12:10 < sipa> morcos: yes 12:10 < sipa> (well, and any rpc test that mines) 12:10 < morcos> sipa: those aren't worth much, they've been in need of redoing for some time 12:10 < sipa> hmm, ok 12:10 <@wumpus> jonasschnelli: I'll also review and test it soon 12:10 < jonasschnelli> thanks 12:11 < morcos> not that i'm objecting to 8295 though 12:11 < sipa> morcos: i'll test by running old and new in parallel and comparing then 12:12 <@wumpus> great 12:13 <@wumpus> sdaftuar: I don't think all items of https://github.com/bitcoin/bitcoin/issues/8294 are currenly being addressed in PRs? 12:13 < luke-jr> a quick glance at 8323 suggests it won't make problems with key origin stuff, rihgt? 12:14 <@wumpus> sdaftuar: any blockers remaining there? 12:14 <@wumpus> (after all currenly 0.13-tagged PRs are merged) 12:14 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:14 <@wumpus> luke-jr: let's discuss that outside the meeting please 12:14 < luke-jr> …. 12:14 < sdaftuar> wumpus: i was waiting for #8295 to be merged before doing the release notes writeups 12:15 < sdaftuar> oh, should we talk about -blockmaxcost briefly? 12:15 <@wumpus> sdaftuar: oh release notes writeups aren't urgent, they need to be done for final but not rc1 12:15 < luke-jr> (what's the point of a meeting if not to discuss the topics raised?) 12:15 < sdaftuar> one of the to do items was better documentation for that option, but as has been pointed out, it's an awful name :) 12:16 < sipa> sdaftuar: suggested replacement? 12:16 <@wumpus> yes, the 'max cost' confuses people, they think it's about monetary cost 12:16 < petertodd> wumpus: +1 12:16 <@wumpus> (and that's also how translators translate it) 12:16 < luke-jr> >_< 12:16 <@wumpus> (and it's a public command line option so the help gets translated) 12:16 < sipa> we could have maxblockvsize instead 12:16 < petertodd> blockmaxcost is still just a size limit isn't it? 12:17 < gmaxwell> Cost has been a repeated source of confusion. 12:17 <@wumpus> but that means the help needs to be improved, not necessarily the option renamed 12:17 < luke-jr> well, it *is* indirectly monetary 12:17 < jeremyrubin> maybe utilization 12:17 < sipa> petertodd: it's the 'cost' as defined in the BIP, which is vsize*4 12:17 < gmaxwell> Score/points/weight/usage/ouchie/bitgo would all be better words for it. 12:17 < luke-jr> "network resource usage"? 12:17 < sdaftuar> sipa: i think my best idea was to change the term in the BIP. i think we use "block cost" in the BIP. if we change that to something more descriptive, "block size validation cost" or something, and reference that in the documentation for the option, then i think that'd be good enough maybe 12:17 <@wumpus> it's an abstract cost, and CS students understand that, but for most users it's confusing :) 12:18 < sipa> sdaftuar: yes, agree, let's makr it consistent, whatever we agree upon 12:18 < petertodd> sdaftuar: yeah, I think changing the BIP's term is a good idea too - it's still a size, just a redefined size 12:18 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 12:18 < CodeShark> #agree 12:18 <@wumpus> block size validation cost would already be better help than there is now 12:18 < luke-jr> petertodd: it's not a size. 12:18 < petertodd> notably, if we had referred to block size in the BIP, that'd help discourage the trolls... 12:18 < gmaxwell> "externality" 12:18 < gmaxwell> luke-jr: it is a size, in cost-space. 12:18 < sipa> well, any reason not use vsize? 12:18 < petertodd> segwit *is* a blocksize increase, so just continue to call it a size 12:18 < petertodd> sipa: vsize is fine 12:19 <@wumpus> yes vsize is fine 12:19 < btcdrak> yes 12:19 < petertodd> sipa: (so long as the help text explains what vsize is) 12:19 < luke-jr> vsize is inaccurate 12:19 < gmaxwell> V means validation? 12:19 < sipa> virtual 12:19 < luke-jr> going to *4 the meaning, so people specify x.25 now? 12:19 < btcdrak> v for vendetta 12:19 < sdaftuar> hm, we have been using vsize to refer to the scaled down value, not the *4 value? 12:19 < gmaxwell> ugh, there is nothing virtual about it. 12:19 < petertodd> gmaxwell: +1 12:19 < luke-jr> fractional values for consensus code? 12:19 < petertodd> sdaftuar: that's a mistake then 12:19 < sipa> sdaftuar: yes, cost == vsize * 4 12:19 < gmaxwell> re fractional values, haven't we learned from difficulty? 12:20 < sipa> vsize is cost, but scaled down for compatibility with old code 12:20 < sipa> so they don't start sending 4x fees etc 12:20 < gmaxwell> if we use fractional values for display friendlyness, other people will use them in consensus code and cause faults. 12:20 * luke-jr grabs a thesaurus 12:20 < gmaxwell> sipa: ::sigh:: point. 12:20 < btcdrak> agreed 12:20 < jeremyrubin> I like weight the best 12:20 <@wumpus> agree jeremyrubin 12:20 < jeremyrubin> because usually you would say a weighted sum 12:21 < sipa> jeremyrubin: nice idea 12:21 <@wumpus> weight is a pretty good term for it 12:21 < CodeShark> #agree 12:21 < btcdrak> good call 12:21 <@wumpus> and it's not used anywhere yet in bitcoin 12:21 < jeremyrubin> (gmaxwell: mentioned first) 12:21 < luke-jr> outlay? :/ 12:21 < luke-jr> weight sounds fine 12:22 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 264 seconds] 12:22 < jtimon> yeah, there's two sizes with their weights, it's a cost heuristic 12:22 <@wumpus> so: rename blockmaxcost to blockmaxweight? 12:22 < instagibbs> "weight" also carries a nice intuitive notion 12:22 < sipa> yes, and let's report weight for transactions too 12:22 < jeremyrubin> maxblockweightcostheuristic 12:23 < gmaxwell> I read that as block mascot. 12:23 <@wumpus> hehe 12:23 < petertodd> OTOH, if we just call the command line stuff a block size, we help educate people on the fact that segwit is a blocksize increase - some miners will leave it at 1000000, but that's a temporary problem 12:23 < jeremyrubin> virtualmaxblockweightcostheuristic 12:23 < jtimon> sorry, I missed the first 15 mins or so, but why do we need to rename blockmaxcost ? 12:23 < luke-jr> petertodd: size is something else 12:23 < gmaxwell> jtimon: because the word cost is confused as fee. 12:24 < sdaftuar> i think "block weight" and -blockmaxweight [ 12:24 < sdaftuar> both work okay 12:24 < btcdrak> ack 12:24 -!- gabridome1 [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 12:24 <@wumpus> jtimon: well it started as that the help for that option was confusing, then people realized the option was named terribly too, but please just read back :) 12:24 < jtimon> mhmm, no, it's costs for the miners, although that's also why they charge you fees 12:24 < luke-jr> weight also should be fine for GBT; nothing is released using the old cost stuff yet 12:24 < luke-jr> jtimon: is there a problem with "weight"? 12:25 < gmaxwell> in any case, I support the great cost to weight renaming. 12:25 < sipa> petertodd: that's what i did originally 12:25 <@wumpus> #action rename blockmaxcost to blockmaxweight 12:25 < jtimon> yeah, sorry I'll wait for botbot.me to update 12:25 < instagibbs> We can chew it over offline 12:25 < petertodd> sipa: well, ack your original idea :) 12:25 < sipa> petertodd: but then people started complaining that there had to be a way to limit the serialized size too 12:26 < jeremyrubin> jtimon: but that's not the units of the cost, otherwise you would denote it into BTC or something... 12:26 < btcdrak> jtimon: you can see.logs in slack 12:26 -!- gabridome [~gabridome@5.90.45.232] has quit [Ping timeout: 246 seconds] 12:27 < petertodd> jeremyrubin: blockbytescost :) 12:27 -!- gabridome1 [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Read error: Connection reset by peer] 12:27 -!- gabridome [~gabridome@5.90.70.21] has joined #bitcoin-core-dev 12:27 < jtimon> jeremyrubin: the cost for miners is in size, or in "costs relative to the maximum limit" or whatever, but sorry, let's move on 12:27 -!- gabridome1 [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 12:28 <@wumpus> other topics? 12:28 < sipa> segwit backport 12:28 <@wumpus> ah yes 12:28 <@wumpus> #topic segwit backport 12:28 < jtimon> btcdrak: I didn't knew, never used the bitcoin slack 12:28 -!- maaku [~quassel@173-228-107-141.dsl.static.fusionbroadband.com] has joined #bitcoin-core-dev 12:29 < sipa> wumpus: some people have raised concerns about backporting segwit to 0.12 12:29 <@wumpus> concerns about doing it at all? 12:29 < jtimon> what's the concern? 12:29 < luke-jr> ^ 12:29 <@wumpus> well, next chance is 0.13.1 12:29 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 12:29 < sipa> morcos, btcdrak: ? 12:30 < morcos> :), yes i was arguing that it would be a mistake 12:30 < jl2012> me too 12:30 < instagibbs> could you reiterate for the audience 12:30 < jtimon> if the backport doesn't get enough review and testing there's no new 0.12 release, simple, no? 12:30 < morcos> I dont' think that it's worth it. I'm not sure there are are benefits that outweight hte cost (weight) in terms of developer time and increased risk for bugs in the backport 12:31 < sipa> one concern i have is that it would likely be the first segwit code that gets actually deployed on the network, and that it is hard to give it the same amount of testing and review as 0.13 did 12:31 <@wumpus> I think it would easier for miners if it was backported to 0.12, but if it turns out to be too much technical difficulty/risk, well too bad I suppose... 12:31 < maaku> if that were the case then I would have to argue that we wait until 0.14.1 .. so strong argument is needed 12:31 < luke-jr> jtimon: backports never do, unless they're the tip release 12:31 < morcos> jtimon: agree that its that simple, but woudl be a shame for some people to sacrafice time backporting and reviewing if its not going to pass the bar 12:31 < btcdrak> yes. I share morcos concerns about backporting 12:31 -!- gabridome [~gabridome@5.90.70.21] has quit [Ping timeout: 260 seconds] 12:31 < luke-jr> wumpus: "too bad" may result in delayed deployment maybe 12:31 < jtimon> luke-jr: so all previous backported softforks were unsafe ? 12:31 < luke-jr> jtimon: such as? 12:31 <@wumpus> luke-jr: yes, but delay is better than messing up 12:32 < sipa> about this topic 12:32 < sipa> in the past we've seen miners often run even pre-release code 12:32 < jtimon> luke-jr: I don't know if any of them was unsafe, I'm asking 12:32 < sipa> if that is going to happen, my concerns about a backport go down 12:32 <@wumpus> I hate delays, but minimizing risk is the highest priority 12:32 < sipa> but so does its usefulness 12:32 < jl2012> have anyone asked miners that they really need a backport? 12:32 < maaku> i'm strongly against "too bad" -- we need to take our support guarantees seriously 12:32 < gmaxwell> the concern is mostly that we don't want to force people to quickly adopt 0.13 derrived code just to catch up with segwit, otherwise 0.13.1 would be fine. 12:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 12:33 < morcos> maaku: we already didn't backport CSV 12:33 <@wumpus> maaku: there are no guarantees 12:33 < maaku> people are running businesses assuming we support "current plus prior" not "current plus prior, except when it's inconvenient" 12:33 < gmaxwell> maaku: doing segwit in 0.13.1 isn't a violation of the process, that still remains no softforks in major feature releases. 12:33 <@wumpus> maaku: from the begining we've said that the plan would be 0.12.1, but if it would somehow lapse it would be 0.13.1 12:33 < maaku> gmaxwell: it would mean you could no longer mine on 0.12 12:33 < sipa> jl2012: that's the most important question 12:33 <@wumpus> this is not about 'inconvenient', this is about risk 12:33 < morcos> gmaxwell: are you more worried about miners or users? 12:34 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Read error: Connection reset by peer] 12:34 < gmaxwell> maaku: with things like CPFP I'm not sure that anyone will be mining on 0.12 in short order. But thats something we could inquire about. 12:34 < gmaxwell> morcos: users. 12:34 < morcos> i just think it's very likely to be safer consensus wise to upgrade to 0.13.1 from 0.12.1 than to upgrade to 0.12.2 (segwit backport) which is more likely to have bugs 12:34 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 12:34 <@wumpus> we wouldn't want a DAO scale disaster over over-hurried release of hardly-reviewed and tested code 12:35 < CodeShark> wumpus +1 12:35 < petertodd> miners that truly need v0.12 might be better off mining with a v0.12 node behind a segwit 0.13 node... 12:35 <@wumpus> so if it needs to be 0.13.1, it will be 0.13.1 12:35 < gmaxwell> Sure. 12:35 < morcos> wumpus: i thought it was definitely going to be 0.13.1, the question was whether we'd also make a 0.12.2? 12:35 < luke-jr> maaku: we need to stop guaranteeing things we can't providr 12:36 < achow101> how many miners even use backports? 12:36 <@wumpus> morcos: no - if it would be in 0.12.2, it could make it into 0.13.0 too 12:36 < gmaxwell> So one risk we have right now is that 0.13.x would end up releasing concurrently or likely ahead of 0.12.2, which would be bad for network consistency in general. 12:36 <@wumpus> morcos: assuming 0.12.2 is released before 0.13.0 of course 12:36 < luke-jr> achow101: all of htem right now I think 12:36 < jtimon> morcos: maybe rebasing my code to 0.13.1 is not easier than rebasing it to 0.12.2 12:36 <@wumpus> morcos: then again that ship sailed already 12:37 < morcos> ok, well i don't have a strong opinion on release numbers or timing. my objection is to spreading ourselves too thing by having to thoroughly review a very substantial set of changes in 2 code bases and then putting the network at risk 12:37 < gmaxwell> morcos: oh no, plan was always 0.12.2, but I agree it might be reasonable to not do that based on current timing. 12:38 < achow101> what about releasing 0.13.1 and then 0.12.2? 12:38 < morcos> i think segwit in master is now relatively well reviewed... it will be very difficult to get that level of review in the 0.12 branch, which woud make me uncomfortable releasing that 12:38 -!- fengling_ [~fengling@58.135.95.136] has joined #bitcoin-core-dev 12:38 < morcos> on top of that, its not something i'd want to spend my time on... i think all our time would be more wisely spent on moving forward with future work 12:38 <@wumpus> achow101: well if a backport is released at all, why would it matter in what order? 12:39 < gmaxwell> Wouldn't want to make a classic blunder, "never get involved in a land war in Asia"! 12:39 < morcos> anyway, sorry, i have to catch a train, got to run! 12:39 < sipa> assuming the demand for a backport of segwit is for users and not miners, releasing 0.12.2 with segwit backport after releasing it in 0.13 is not unreasonablr 12:39 < btcdrak> It's also a lot cleaner releasing in 0.13.1 because 0.12 would not have compact blocks 12:39 < luke-jr> wumpus: order matters a lot for testing 12:39 < petertodd> sipa: sure, if it removed getblocktemplate that'd be an easy idea to support 12:39 < gmaxwell> well right now 0.13.0 doesn't have CB for segwit, though I suppose 0.13.1 could. 12:39 < jtimon> sipa: yeah, I assumed that was the plan 12:40 < achow101> wumpus: for proper review of the backport without delaying deployment 12:40 <@wumpus> I do wish we had realized this sooner, instead of seeming like a last minute decision 12:40 < gmaxwell> wumpus: likewise. 12:40 <@wumpus> achow101: even fewer people will care about 0.12.x if 0.13 is already out 12:40 < gmaxwell> otoh, decisions to do _less_ at the last minute are better than decisions to do _more_. :) 12:40 < btcdrak> gmaxwell: right, but if we released 0.12.2 then segwit would not have CB. If we release with 0.13.1 then we get CB at the get go. 12:40 < sipa> i guess the question is what has priority: segwit backport or 0.13 release? 12:40 <@wumpus> gmaxwell: hah, fully agreed 12:40 < petertodd> sipa: 0.13 release I think 12:40 < gmaxwell> We have real problems with virtually no one ever using backports. 12:41 <@wumpus> for me the 0.13 release has priority 12:41 < helo> +1 release 12:41 < jonasschnelli> agree with wumpus 12:41 < sipa> my assumption was that we'd do 0.13.0, then 0.12.2 backport with segwit, then 0.13.1 release with segwit active 12:41 < gmaxwell> 0.13 release has priority. 12:41 < sipa> and if that is the case, a backport would be urgent 12:41 < jtimon> waiting to release 0.13 to release 0.12.2 first sounds stupid to me 12:41 < sipa> or 0.13.1 would suffer delays 12:41 < btcdrak> sipa: getting enough review for backport to 0.12.2 would be questionable. 12:41 < gmaxwell> sipa: yes, that was my expectation too, though the release of 0.13 would likely sabotage 0.12.2 deployment. 12:42 < luke-jr> IMO we should remove any promise to maintain older branches once the newer one has a release, and provide backports only as a at-your-own-risk basis 12:42 < petertodd> I'd suggest putting a "if you want 0.12.2 w/ segwit, please let us know" in the release nodes for v0.13.0 12:42 < jtimon> petertodd: that's a good idea 12:42 < jonasschnelli> Don't we take serious risks in BP SW in 0.12.2? Would it be evil to not BP SW to 0.12 and require 0.13 for SW? Would this delay supermajority activation significant? 12:42 < sipa> if there are critical bugs in 0.12.1, we can always release 0.12.2 to fix them 12:42 < btcdrak> we didnt backport CSV to 0.11 because the changes were too extensive - to be clear the backport was done, but we decided not to merge it (and there was not enough review either). 12:42 < petertodd> jtimon: I think we've done it before too 12:42 < jtimon> and depending on the response decide to the the backport or not 12:42 < sipa> btcdrak: tbh, i think that the difficulty of a segwit backport is not that hard 12:43 < gmaxwell> luke-jr: that would be unfortunate in that its the wrong direction for the industry. The lack of professionality in software lifecycle isn't something we should be cementing, though I'm not sure I see much choice when we don't actually get the review/testing. 12:43 < btcdrak> sipa: you would say that though :) 12:43 < sipa> btcdrak: the original segwit PR was made with mostly 0.12 code still 12:43 < gmaxwell> luke-jr: maybe we should start making more really disruptive changes in major releases. :) 12:43 -!- fengling_ [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 12:43 <@wumpus> 'maintain' older branches does not mean backport everything 12:43 < jonasschnelli> agree 12:43 < luke-jr> gmaxwell: I agree we should strive to support stable branches of course (as I've tried for years now), but the reality is we *can't* as things stand now 12:43 <@wumpus> just that serious and critical issues are addressed 12:43 < sipa> yes 0.12.2 can still happen if a serioud bug in 0.12.1 is founf 12:44 < luke-jr> wumpus: not supporting a deployed softfork is a critical issue for a full node 12:44 < jtimon> gmaxwell: I've been always in favor of doing disruptive refactors just before branching instead of right after 12:44 -!- gabridome [~gabridome@5.90.72.99] has joined #bitcoin-core-dev 12:44 < sipa> ok, i need to run 12:44 < jonasschnelli> luke-jr: SW could be deployed, I guess the majoriry is already on 0.13 and there is no need to keep 0.12 12:44 < sipa> i'll still work on a backport if there is demand 12:45 < luke-jr> jonasschnelli: that's a point I suppose 12:45 < gmaxwell> sipa: it might be a useful excercise from a review perspective in any case. 12:45 <@wumpus> jtimon: that increases the pre-release pressure even more, and the potential number of problems what need to be solved before release ('disruptive refactors' have been known to introduce serious bugs in some cases) 12:45 < petertodd> luke-jr: remember that you can always run a node not supporting a soft-fork behind one that does to get the same security 12:45 < luke-jr> petertodd: true; we should make this more well-known IMO 12:45 < luke-jr> not sure how many people realise it 12:46 < petertodd> luke-jr: good thing for the release notes! 12:46 < gmaxwell> I always point it out. 12:46 < jtimon> wumpus: I mean the of the kind that present low risk (like file renaming on moveonly commits) 12:46 < gmaxwell> but it's the sort of thing that needs a diagram. :) 12:46 < luke-jr> gmaxwell: did you for Eligius? :P 12:46 < CodeShark> petertodd +1 12:46 < maaku> has anyone actually quantified what level of review is required for a backport? 12:46 * luke-jr knows he overlooked it 12:46 < jtimon> wumpus: but I guess you're right about the pre-release preassure 12:46 < maaku> segwit was written against 0.12. 12:46 < luke-jr> actually, I guess it might not entirely work for CSV + mining 12:46 <@wumpus> jtimon: in any case I doubt raneming and moveonly commits are what really makes it difficult to backport things :) 12:46 <@wumpus> jtimon: more things like the mempool changes 12:47 < jl2012> petertodd: except you can't mine any segwit tx with a 0.12 behind 0.13 12:47 < btcdrak> well I'd like to see a refactoring window right after branching, maybe 2 weeks 12:47 < jtimon> but you don't need to backport segwit from the present, you backport it from when it was merged, no? 12:47 < gmaxwell> maaku: it's not been done yet, so no-- but right now in general we're struggling to maintain the backport releases at all, because virtually no one uses them. 12:48 < jtimon> how would any refactor now difficult backporting segwit? 12:48 < gmaxwell> luke-jr: I don't consider that a great configuration for mining, but I think I'd mentioned it for a prior softfork. 12:48 -!- gabridome1 [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Ping timeout: 276 seconds] 12:48 <@wumpus> we're spread really thin - agree fully on the 'don't get involved in a land war in asia' comment 12:49 < petertodd> jl2012: "can't mine" is a smaller group of people than all full node users 12:50 < jtimon> btcdrak: I would like to get refactor code reviewed during that "refactor window", just declaring the week of refactor doesn't make things get merged :p 12:50 < petertodd> incidentally, in my consulting practice I've always advised clients to use architectures where the exact behavior of full node implementations isn't important, which makes upgrades much less risky 12:51 < btcdrak> jtimon: ack 12:52 < gmaxwell> petertodd: careful, though that thinking also drives the "I made my own 'node' implementation and have plugged it directly into the public p2p network! yippie!" 12:52 < gmaxwell> in any case, short on time. Are we done on this subject? 12:53 < instagibbs> 8 minutes left 12:53 < petertodd> gmaxwell: well, my advice is to either use a lite-client w/ up-to-date full node, or if you're using bitcoin core, plan to put it behind an up-to-date node 12:53 < gmaxwell> petertodd: perhaps we should talk to harding and write a deployment guide that shows things like that layering and test infrastructure. 12:53 <@wumpus> seems so 12:54 < petertodd> gmaxwell: good idea 12:54 < gmaxwell> Generally you should have a two later setup in any case, don't put your production node up exposed to the internet... 12:54 < petertodd> gmaxwell: that too... 12:54 <@wumpus> other topics? last-minute announcements? 12:55 < gmaxwell> I was getting flammed on reddit that it's common knoweldge that bitcoin core's wallet was unusuable for commercial use. I tried to get some unpacking there: https://www.reddit.com/r/Bitcoin/comments/4snk48/roger_ver_and_his_supporters_are_pushing_policies/d5bb73w?context=3 might be worth looking at the comments. 12:56 < gmaxwell> As I've lamented in the past, commercial users just generally don't report issues they encounter. I don't know how to improve that. 12:56 < jtimon> can be after the meeting but... 12:56 <@wumpus> well if bitcoin core's wallet is unusable for commercial use, I wonder what wallet is.. 12:56 < bsm117532> FWIW I've been encountering wallet issues, and am working on a patch that addresses some of them, especially WRT segwit. 12:56 < gmaxwell> What I could extra there was related to wallet performance, which phantomcircuit has recently done some improvement (and has more in the pipeline) 12:56 < gmaxwell> wumpus: people use centeralized api providers instead almost universally. 12:56 < bsm117532> But I would like to see removal of "accounts". Is anyone working on that? 12:57 <@wumpus> bsm117532: I tried to introduce a label API for 0.13 to replace it, then deprecate accounts in 0.14 12:57 < petertodd> bsm117532: re: removing accounts, have you checked with joinmarket on what they'll do? they use accounts 12:57 <@wumpus> bsm117532: but that didn't get enough review 12:57 < jtimon> without having to ack or nack #8328 right now, general thoughts about moving consensus files to the consensus folder? I have heard different things, but if it's not clear, I will take it out of the base of my latest consensus branch 12:57 < jtimon> yay nay ? 12:58 <@wumpus> bsm117532: https://github.com/bitcoin/bitcoin/pull/7729 12:58 < sipa> jtimon: yay, after 0 12:58 < jtimon> sipa: yeah, I'm assuming after 0.13 branches 12:58 <@wumpus> petertodd: that'd be really ill-adviced, given that we've been discouraging use of them for years, are you sure? 12:58 < gmaxwell> ironically, one of the complaints I got there was that accounts are discouraged. ::shrugs:: 12:58 < sipa> though i prefer to leave some things as "base logic" like maaku suggests 12:58 < jtimon> I mean, if people want before I'm all in, but I highly doubt it 12:59 < btcdrak> we should ping belcher 12:59 < petertodd> wumpus: yes, I'm 99% sure - I use joinmarket all the time 12:59 < bsm117532> wumpus: I will review 7729 and try to offer some feedback 12:59 < btcdrak> he's got some homework then... 12:59 < maaku> as I wrote in the PR I think pushing everything used by consensus into `src/consensus` makes the source code less organized and less approachable by newbies 12:59 < luke-jr> I need to get back on the road, bbl 12:59 < sipa> maaku: agree 12:59 < jtimon> sipa: mhmm, you mean making another "base logic" dir and package in the makefile ? 13:00 < sipa> jtimon: well one such piece of base logic is primitives 13:00 < petertodd> maaku: less approchable? I'd argue more - makes it easier to understand what consensus is and isn't 13:00 <@wumpus> gmaxwell: it's also taking so insanely long to remove it 13:00 < jtimon> maaku: I strongly disagree (but maybe not all people are mostly interested in the consensus code like me) 13:00 <@wumpus> gmaxwell: same as I've seen with the label API pull - no one is really interested in it 13:00 < sipa> jtimon: things like prevector and so seem also more broadly usable than consensus 13:00 < maaku> petertodd: that's rarely someone's first question when approaching the code base 13:01 < afk11> I think keeping some base logic outside may work, ultimately serialization libraries might be soft-forks wrt an older consensus implementation 13:01 < sipa> time up 13:01 < btcdrak> well I hate to say it, but its not like the code is that approachable as is... 13:01 < gmaxwell> wumpus: is this the point where I hang my head in shame and point out that I've forgotten there was a label pull? 13:01 <@wumpus> #endmeeting 13:01 < lightningbot> Meeting ended Thu Jul 14 20:01:20 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.html 13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.txt 13:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.log.html 13:01 < jtimon> sipa: agreed, but libconsensus needs them if we're ever going to separate the library ala libsecp 13:01 < instagibbs> btcdrak, heh 13:01 < maaku> btcdrak: it is way better than when I started 13:01 < petertodd> maaku: my usual advice to people is to follow the block acceptance logic and read the consensus code to understand how the bitcoin protocol works 13:01 < maaku> so please don't make it worse 13:01 < sipa> jtimon: there's no problem in dependong on things outside of consensus 13:01 < gmaxwell> It's my guess that if the label stuff is done removing accounts is much easier, as that the only legit use. 13:02 <@wumpus> gmaxwell: https://github.com/bitcoin/bitcoin/pull/7729 13:02 < sipa> jtimon: we also depend on libstdc++ and an OS, righ 13:02 < btcdrak> maaku: beauty is in the eye of the beholder :-p 13:02 < petertodd> maaku: that's how I learned how the bitcoin protocol works 13:02 < jtimon> no, I mean, if at some point libconsensus becomes its own repo 13:02 < maaku> petertodd: that doesn't require the files to literally be in the same directory. 13:02 < jonasschnelli> Yes. We should reconsider wumpus 7729 13:02 * btcdrak is just teasing 13:02 < maaku> when you see #include