12016-07-14T00:00:09  *** fengling_ has joined #bitcoin-core-dev
  22016-07-14T00:05:06  *** fengling_ has quit IRC
  32016-07-14T00:25:36  <cfields> sipa: https://github.com/theuni/bitcoin/commits/copy-move
  42016-07-14T00:26:26  <cfields> sipa: benchmark shows copying is ~100x faster. moving is ~1000x (as there were no moves before, and moves are little more than pointer swapping)
  52016-07-14T00:28:13  <cfields> ofc those are suspiciously high. curious to see if others get anywhere near the same numbers
  62016-07-14T00:28:28  *** spudowiar has quit IRC
  72016-07-14T00:29:37  <phantomcircuit> cfields: how did you benchmark that?
  82016-07-14T00:29:56  <cfields> phantomcircuit: benchmark is included
  92016-07-14T00:30:42  <phantomcircuit> oh that reminds me
 102016-07-14T00:30:48  <phantomcircuit> cfields, can you look at doing a fuzzing framework?
 112016-07-14T00:31:06  <phantomcircuit> literally just needs to be an executable that takes input on stdin
 122016-07-14T00:31:08  <cfields> phantomcircuit: i thought you were working on one?
 132016-07-14T00:31:22  <phantomcircuit> my modifications to the build process to do this didn't seem to work right consistently
 142016-07-14T00:31:42  <phantomcircuit> yeah i was and it worked for me but it broke the build process in weird ways i dont understand because autotools
 152016-07-14T00:31:48  <cfields> phantomcircuit: oh, you just need the build changes skeleton?
 162016-07-14T00:31:54  <phantomcircuit> yeah
 172016-07-14T00:32:03  <phantomcircuit> the fuzzing executable itself is pretty trivial
 182016-07-14T00:32:14  <phantomcircuit> and i suspect the build changes are trivial too but not for me :)
 192016-07-14T00:32:17  <cfields> phantomcircuit: sure, though, you should basically be able to copy Makefile.bench.include
 202016-07-14T00:32:50  <phantomcircuit> i tried that first and somehow screwed it up so i ended up copying bitcoin-tx stuff but that's not great cause i actually do want multiple executables
 212016-07-14T00:34:14  <cfields> phantomcircuit: you're going to have to lay out exactly what you want. multiple executables gets more complicated
 222016-07-14T00:34:46  <phantomcircuit> i could also do it the way i was doing it before which is to make the first few bytes of the fuzzing input select which test to run
 232016-07-14T00:35:28  <phantomcircuit> i guess it could also be an executable with cli flags to select which test to run
 242016-07-14T00:36:22  <phantomcircuit> having them all be in a single executable isn't ideal for the fuzzer
 252016-07-14T00:36:30  <phantomcircuit> gmaxwell, ^ opinions?
 262016-07-14T00:36:59  <sipa> cfields: concept ack, i'll review in detail later
 272016-07-14T00:37:08  <sipa> on the copy/move
 282016-07-14T00:37:53  <cfields> sipa: thanks. if you'd prefer to make it class-safe, i can work on that instead
 292016-07-14T00:39:41  <cfields> sipa: but if so, i think it's worth having 2 versions. the POD implementation is much quicker and would suffer if lumped into per-element copies/moves
 302016-07-14T00:46:24  <sipa> cfields: i'm impressed by how much faster it id
 312016-07-14T00:46:29  <sipa> *it os
 322016-07-14T00:46:53  <sipa> ah, but that's move compared to the old placement new based approach?
 332016-07-14T00:46:53  <cfields> sipa: you reproduced? or going by my numbers?
 342016-07-14T00:47:01  <sipa> going by your numbers
 352016-07-14T00:48:18  <cfields> sipa: for move, if malloc'd, all you need to do is copy the pointer. so it's extremely light compared to the previous deep copy
 362016-07-14T00:49:30  <sipa> cfields: also, is the script/transaction move constructor/assignment actually invoked anywhere?
 372016-07-14T00:50:50  *** baldur has joined #bitcoin-core-dev
 382016-07-14T00:50:57  <cfields> sipa: unsure, but I suspect that there are plenty of places that pass in rvalues ala: myfunction(CScript())
 392016-07-14T00:52:03  <sipa> cfields: well, easy enough to create an explocit move constructor and putting a printf or gdb breakpoint in it
 402016-07-14T00:52:43  <gmaxwell> phantomcircuit: A single executable can be done, with top level branches. Because of aliasing it may be somewhat less effective than seperate, but I don't think it makes a big deal. Biggest downside is that you can't easily focus further testing.
 412016-07-14T00:53:46  <cfields> sipa: oh, if you're asking if the moves are actually resolved, yes, i tested that. in the prevector bench, I added a quick version with the exact same operations. CScript was sped up exactly the same amount.
 422016-07-14T00:55:04  *** fengling_ has joined #bitcoin-core-dev
 432016-07-14T00:57:34  <cfields> sipa: more precisely, I just stuck an assert(0) into the CTransaction move assignment oper, and test_bitcoin aborts right away
 442016-07-14T01:06:22  *** Chris_Stewart_5 has quit IRC
 452016-07-14T01:13:04  *** adamg has quit IRC
 462016-07-14T01:14:15  *** davec has quit IRC
 472016-07-14T01:15:47  *** Ylbam has quit IRC
 482016-07-14T01:19:04  *** shangzhou has quit IRC
 492016-07-14T01:19:32  *** Kexkey has joined #bitcoin-core-dev
 502016-07-14T01:19:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 512016-07-14T01:27:19  *** belcher has quit IRC
 522016-07-14T01:32:25  *** Kexkey has quit IRC
 532016-07-14T01:45:00  *** justanotheruser has quit IRC
 542016-07-14T01:47:22  *** justanotheruser has joined #bitcoin-core-dev
 552016-07-14T01:48:33  *** Chris_Stewart_5 has quit IRC
 562016-07-14T01:55:30  *** Justinus has joined #bitcoin-core-dev
 572016-07-14T02:06:09  *** davec has joined #bitcoin-core-dev
 582016-07-14T02:26:13  *** frankenmint has joined #bitcoin-core-dev
 592016-07-14T02:30:31  *** frankenmint has quit IRC
 602016-07-14T02:45:55  *** xinxi has joined #bitcoin-core-dev
 612016-07-14T02:50:39  *** xinxi has quit IRC
 622016-07-14T03:28:03  *** luke-jr has joined #bitcoin-core-dev
 632016-07-14T03:48:48  *** afk11 has quit IRC
 642016-07-14T03:54:55  *** afk11 has joined #bitcoin-core-dev
 652016-07-14T03:54:55  *** afk11 has quit IRC
 662016-07-14T03:54:55  *** afk11 has joined #bitcoin-core-dev
 672016-07-14T04:44:03  *** d_t has joined #bitcoin-core-dev
 682016-07-14T04:46:08  *** kadoban has joined #bitcoin-core-dev
 692016-07-14T05:43:55  *** d_t has quit IRC
 702016-07-14T05:54:05  *** RoyceX has joined #bitcoin-core-dev
 712016-07-14T05:54:05  *** RoyceX has joined #bitcoin-core-dev
 722016-07-14T05:57:28  *** Cheeseo has quit IRC
 732016-07-14T06:05:37  <GitHub118> [bitcoin] NicolasDorier opened pull request #8339: Consensuslib: Block Verify / Transaction Verify [Work in progress]  (master...blkconsensus) https://github.com/bitcoin/bitcoin/pull/8339
 742016-07-14T06:17:47  <GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4831a16223db...1bc9c8085f71
 752016-07-14T06:17:47  <GitHub69> bitcoin/master 252675e Pieter Wuille: Do not send witnesses in cmpctblock
 762016-07-14T06:17:48  <GitHub69> bitcoin/master 1bc9c80 Wladimir J. van der Laan: Merge #8271: [bugfix] Do not send witnesses in cmpctblock...
 772016-07-14T06:17:57  <GitHub138> [bitcoin] laanwj closed pull request #8271: [bugfix] Do not send witnesses in cmpctblock (master...nowitnesscb) https://github.com/bitcoin/bitcoin/pull/8271
 782016-07-14T06:18:57  <GitHub15> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1bc9c8085f71...4324bd237c31
 792016-07-14T06:18:57  <GitHub15> bitcoin/master 36ae37a Bob McElrath: Rename CTxinWitness -> CTxInWitness
 802016-07-14T06:18:58  <GitHub15> bitcoin/master 4324bd2 Wladimir J. van der Laan: Merge #8311: Rename CTxinWitness -> CTxInWitness...
 812016-07-14T06:19:06  <GitHub181> [bitcoin] laanwj closed pull request #8311: Rename CTxinWitness -> CTxInWitness (master...CTxInWitness) https://github.com/bitcoin/bitcoin/pull/8311
 822016-07-14T06:21:33  <GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4324bd237c31...ca40ef6029c1
 832016-07-14T06:21:34  <GitHub56> bitcoin/master bb66a11 Suhas Daftuar: Fix DoS vulnerability in mempool acceptance...
 842016-07-14T06:21:34  <GitHub56> bitcoin/master 46c9620 Suhas Daftuar: Test that unnecessary witnesses can't be used for mempool DoS...
 852016-07-14T06:21:35  <GitHub56> bitcoin/master ca40ef6 Wladimir J. van der Laan: Merge #8312: Fix mempool DoS vulnerability from malleated transactions...
 862016-07-14T06:21:44  <GitHub79> [bitcoin] laanwj closed pull request #8312: Fix mempool DoS vulnerability from malleated transactions (master...mempool-malleability) https://github.com/bitcoin/bitcoin/pull/8312
 872016-07-14T06:33:47  *** xinxi has joined #bitcoin-core-dev
 882016-07-14T06:47:45  *** paveljanik has joined #bitcoin-core-dev
 892016-07-14T07:00:12  *** arubi has quit IRC
 902016-07-14T07:00:24  <xinxi> sipa: are you there?
 912016-07-14T07:06:16  *** arubi has joined #bitcoin-core-dev
 922016-07-14T07:22:05  *** xinxi has quit IRC
 932016-07-14T07:22:55  *** xinxi has joined #bitcoin-core-dev
 942016-07-14T08:00:00  *** frankenmint has joined #bitcoin-core-dev
 952016-07-14T08:06:54  *** face has joined #bitcoin-core-dev
 962016-07-14T08:08:55  *** jannes has joined #bitcoin-core-dev
 972016-07-14T08:09:23  *** MarcoFalke has joined #bitcoin-core-dev
 982016-07-14T08:14:37  *** moli has quit IRC
 992016-07-14T08:19:02  *** face has quit IRC
1002016-07-14T08:21:55  *** Guyver2 has joined #bitcoin-core-dev
1012016-07-14T08:31:21  <GitHub51> [bitcoin] MarcoFalke opened pull request #8340: [qa] Solve merge conflict of 4324bd237c3147fc153ba5046c211f03e8ac956a (master...Mf1607-qaSolveMerge) https://github.com/bitcoin/bitcoin/pull/8340
1022016-07-14T08:59:07  <GitHub128> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca40ef6029c1...af9b7a9f2f73
1032016-07-14T08:59:07  <GitHub128> bitcoin/master 66668c4 MarcoFalke: [qa] Solve merge conflict of 4324bd237c3147fc153ba5046c211f03e8ac956a
1042016-07-14T08:59:08  <GitHub128> bitcoin/master af9b7a9 MarcoFalke: Merge #8340: [qa] Solve trivial merge conflict in p2p-segwit.py...
1052016-07-14T08:59:17  <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
1062016-07-14T09:02:19  *** MarcoFalke has left #bitcoin-core-dev
1072016-07-14T09:38:20  <GitHub179> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/af9b7a9f2f73...bc94b8748782
1082016-07-14T09:38:20  <GitHub179> bitcoin/master b993671 Jonas Schnelli: [Wallet] keep HD seed during salvagewallet
1092016-07-14T09:38:21  <GitHub179> bitcoin/master bc94b87 Wladimir J. van der Laan: Merge #8324: [Wallet] keep HD seed during salvagewallet...
1102016-07-14T09:38:33  <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
1112016-07-14T09:47:57  *** arubi has quit IRC
1122016-07-14T09:48:12  *** arubi has joined #bitcoin-core-dev
1132016-07-14T09:53:57  *** arubi has quit IRC
1142016-07-14T09:54:12  *** arubi has joined #bitcoin-core-dev
1152016-07-14T10:26:18  *** arubi has quit IRC
1162016-07-14T10:26:28  *** arubi has joined #bitcoin-core-dev
1172016-07-14T10:30:06  *** fengling_ has quit IRC
1182016-07-14T10:33:34  *** moli has joined #bitcoin-core-dev
1192016-07-14T10:42:55  *** frankenmint has quit IRC
1202016-07-14T10:48:01  *** Ylbam has joined #bitcoin-core-dev
1212016-07-14T11:02:27  *** chris200_ has joined #bitcoin-core-dev
1222016-07-14T11:06:12  *** Sosumi has joined #bitcoin-core-dev
1232016-07-14T11:12:52  *** mkarrer has quit IRC
1242016-07-14T11:14:59  *** chris200_ has quit IRC
1252016-07-14T11:15:58  *** frankenmint has joined #bitcoin-core-dev
1262016-07-14T11:24:01  *** jtimon has joined #bitcoin-core-dev
1272016-07-14T11:24:04  *** arubi has quit IRC
1282016-07-14T11:24:16  *** arubi has joined #bitcoin-core-dev
1292016-07-14T11:25:30  *** frankenmint has quit IRC
1302016-07-14T11:26:27  *** fengling_ has joined #bitcoin-core-dev
1312016-07-14T11:31:26  *** fengling_ has quit IRC
1322016-07-14T11:33:52  *** laurentmt has joined #bitcoin-core-dev
1332016-07-14T11:34:06  *** laurentmt has quit IRC
1342016-07-14T12:02:35  *** frankenmint has joined #bitcoin-core-dev
1352016-07-14T12:14:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1362016-07-14T12:16:39  *** Chris_Stewart_5 has quit IRC
1372016-07-14T12:28:02  *** fengling_ has joined #bitcoin-core-dev
1382016-07-14T12:32:46  *** fengling_ has quit IRC
1392016-07-14T12:41:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1402016-07-14T12:46:43  *** Chris_Stewart_5 has quit IRC
1412016-07-14T12:55:27  <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
1422016-07-14T13:00:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1432016-07-14T13:07:03  *** knightdk has joined #bitcoin-core-dev
1442016-07-14T13:11:30  *** Chris_Stewart_5 has quit IRC
1452016-07-14T13:11:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1462016-07-14T13:12:27  *** laurentmt has joined #bitcoin-core-dev
1472016-07-14T13:23:25  <jtimon> jonasschnelli: what do you think I should do with the consensus PRs ?
1482016-07-14T13:23:48  <jonasschnelli> jtimon: I think you should do one small step after another...
1492016-07-14T13:24:03  <jtimon> those are 3 small steps one after the other
1502016-07-14T13:24:25  <jonasschnelli> But they do include the same commits.
1512016-07-14T13:24:35  <jtimon> imagine someone reviewed more than 2 of those little steps
1522016-07-14T13:24:37  <jonasschnelli> I think you should open only one PR ...
1532016-07-14T13:24:48  <jtimon> yeah, that's the "one after the other" part
1542016-07-14T13:25:09  <jonasschnelli> IMO the past has shown that we have not enough reviwers for the consensus parts..
1552016-07-14T13:25:20  <jonasschnelli> This is why I think one PR at the time would be more efficient.
1562016-07-14T13:25:24  <sipa> i'm fine with the pure move consensus code PRs, after 0.13 branches off
1572016-07-14T13:25:30  <jtimon> jonasschnelli : so we should just give up?
1582016-07-14T13:25:37  <jonasschnelli> jtimon: no... sure not!
1592016-07-14T13:25:48  <sipa> for everything else (encapsulation, API)... *please* first document first
1602016-07-14T13:26:04  <jonasschnelli> I just think you will have more reviwers if there are clear distortable/small PRs
1612016-07-14T13:26:27  *** mkarrer has joined #bitcoin-core-dev
1622016-07-14T13:26:40  <jonasschnelli> jtimon: to have that said: I'm a big fan of the consensus encapsulation and I appreciate your work!
1632016-07-14T13:26:54  <jonasschnelli> I just try to optimize the workflow on that part
1642016-07-14T13:27:58  <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
1652016-07-14T13:28:03  <sipa> same goes for NicolasDorier by the way
1662016-07-14T13:28:23  <sipa> these are big architectural changes, and i think everyone needs to be on board before going one way or another
1672016-07-14T13:28:30  <jonasschnelli> jtimon: I just think you will have more reviewers if you just focus on one PR
1682016-07-14T13:28:57  <jtimon> none of the open PRs are big architectural changes, one it's renaming files and the other 2 are moveonly
1692016-07-14T13:29:04  <sipa> jtimon: that's all fine
1702016-07-14T13:29:19  <jtimon> in https://github.com/jtimon/bitcoin/commits/0.12.99-consensus there are big architectural changes though
1712016-07-14T13:29:26  <sipa> jtimon: sorry, i think i've developed selective blindness for any PRs that mention consensus refactors
1722016-07-14T13:29:28  *** fengling_ has joined #bitcoin-core-dev
1732016-07-14T13:29:40  <jtimon> sipa: I could easily believe that
1742016-07-14T13:30:31  <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
1752016-07-14T13:31:42  <sipa> jonasschnelli: sorry, i need to read up on HKDF first
1762016-07-14T13:31:57  <jonasschnelli> sipa: sure: https://tools.ietf.org/html/rfc5869
1772016-07-14T13:32:26  <jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
1782016-07-14T13:33:23  *** anchow101 has joined #bitcoin-core-dev
1792016-07-14T13:34:20  *** knightdk has left #bitcoin-core-dev
1802016-07-14T13:34:26  *** fengling_ has quit IRC
1812016-07-14T13:34:45  *** anchow101 has quit IRC
1822016-07-14T13:37:19  *** achow101 has quit IRC
1832016-07-14T13:37:38  *** achow101 has joined #bitcoin-core-dev
1842016-07-14T13:38:37  <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 :)
1852016-07-14T13:40:30  <jtimon> afk11: thak you that's encouraging, but some review on #8337 (which contains #8329 (which contains #8328 )) would be much more encouraging :p
1862016-07-14T13:41:17  *** Frederic94500 has joined #bitcoin-core-dev
1872016-07-14T13:41:50  <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
1882016-07-14T13:42:40  *** Chris_St1 has joined #bitcoin-core-dev
1892016-07-14T13:42:43  <jtimon> in my plans I was thinking #8328 much later, but people keep f##$%^ing creating consensus files out of the consensus dir
1902016-07-14T13:43:04  <paveljanik> jtimon, just nACK them...
1912016-07-14T13:43:18  <sipa> jtimon: it's not always obvious
1922016-07-14T13:44:04  <sipa> jtimon: should prevector be in consensus, for example?
1932016-07-14T13:44:33  <sipa> consensus logic depends on it, but it's implementing a standard interface, and is more generically useful
1942016-07-14T13:44:58  <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
1952016-07-14T13:45:21  *** Chris_Stewart_5 has quit IRC
1962016-07-14T13:45:25  *** TomMc has joined #bitcoin-core-dev
1972016-07-14T13:45:38  <jtimon> prevector is a dependency of uint256, no?
1982016-07-14T13:45:42  <sipa> no
1992016-07-14T13:45:54  <sipa> it is of CScript
2002016-07-14T13:46:00  <jtimon> oh, yeah
2012016-07-14T13:46:20  <sipa> but even that... i'm not sure CScript storage in the long term belongs in consensus
2022016-07-14T13:46:35  <jtimon> I mean, prevector is currently needed in libconsensus for verifyScript
2032016-07-14T13:47:15  <sipa> ok, so your view that all dependencies for libconsensus (currently or in the near future) belong in the consensus/ directory?
2042016-07-14T13:47:27  <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...
2052016-07-14T13:47:45  <sipa> i'm just trying to understand your view
2062016-07-14T13:48:00  <sipa> i think you've thought this true, and have a good picture in your head of what belongs where
2072016-07-14T13:48:03  <sipa> but it's not obvious to me
2082016-07-14T13:48:31  <sipa> should everything that libconsensus depends on be in the consensus/ directory?
2092016-07-14T13:48: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)
2102016-07-14T13:49:20  <sipa> jtimon: so script/script.h, script/interpreter, primitives/*, ... move to consensus?
2112016-07-14T13:50:35  <jtimon> well, right now it's just a few that I'm renaming that are not required by current libconsensus (block, pow, utilmoneystr...)
2122016-07-14T13:50:52  <sipa> i
2132016-07-14T13:50:53  <sipa> i
2142016-07-14T13:50:56  <sipa> grrr!
2152016-07-14T13:51:03  <sipa> i'm not really talking about current PRs
2162016-07-14T13:51:10  <sipa> just about what you believe belongs where
2172016-07-14T13:51:37  <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...
2182016-07-14T13:51:58  <sipa> jtimon: i am not talking about your current PRs...
2192016-07-14T13:52:07  <jtimon> everything that's going to be needed for a complete libconsensus exposing verifyblock
2202016-07-14T13:52:14  <sipa> ok, thank you
2212016-07-14T13:52:21  <jtimon> sipa: that's fine, but there's a list right there
2222016-07-14T13:52:21  <sipa> does that include primitives?
2232016-07-14T13:52:39  <jtimon> yes, of course
2242016-07-14T13:52:53  <sipa> ok
2252016-07-14T13:53:23  <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
2262016-07-14T13:53:33  <sipa> the wallet would still depend on the primitives inside the consensus directory?
2272016-07-14T13:53:38  <jtimon> in fact I forgot sigache in that PR, that will be needed too I guess
2282016-07-14T13:54:10  *** arubi has quit IRC
2292016-07-14T13:54:23  *** arubi has joined #bitcoin-core-dev
2302016-07-14T13:55:11  <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
2312016-07-14T13:55:34  <sipa> fair enough
2322016-07-14T13:55:44  <jtimon> first step is completing libconsensus while allowing bitcoin core to keep using its internals
2332016-07-14T13:56:23  <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
2342016-07-14T13:56:45  <jtimon> I mean, the renaming (moving to the consensus dir) can be done at any time, but I think it makes things clearer
2352016-07-14T13:56:49  *** frankenmint has quit IRC
2362016-07-14T13:56:50  <sipa> sure
2372016-07-14T13:56:54  *** Chris_St1 has quit IRC
2382016-07-14T13:57:46  <jtimon> well, my expectation is that consensus is the lowest layer, it exposes function of different layers I guess (ie script tx header block)
2392016-07-14T13:57:51  *** YOU-JI has joined #bitcoin-core-dev
2402016-07-14T13:57:52  *** ebfull has quit IRC
2412016-07-14T13:59:48  <jtimon> I mean, the lowest layer is really the crypto dir and libsecp
2422016-07-14T14:00:00  <sipa> do those also move to consensus/ ?
2432016-07-14T14:00:08  <sipa> not all of crypto/ is needed in consensus
2442016-07-14T14:00:31  <jtimon> only one hash function wasn't last time I checked IIRC
2452016-07-14T14:00:48  <jtimon> but well, they're in the crypto dir already so...
2462016-07-14T14:01:00  <sipa> hmac, rfc6979, aes, sha512
2472016-07-14T14:01:06  <sipa> those are not needed in consensus
2482016-07-14T14:01:14  <jtimon> the whole folder is currently being built for libconsensus
2492016-07-14T14:01:22  <sipa> i'm aware
2502016-07-14T14:01:31  <sipa> (but i'm not sure that's a good thing)
2512016-07-14T14:02:29  <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
2522016-07-14T14:04:13  <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
2532016-07-14T14:04:53  <jtimon> it's only touching the makefile anyway
2542016-07-14T14:05:00  <sipa> well, we'd be breaking apart script/ too
2552016-07-14T14:05:38  <jtimon> well, yeah, script is already being built in different packages
2562016-07-14T14:06:02  <jtimon> some are not consensus code like sign and standard
2572016-07-14T14:06:08  <sipa> indeed
2582016-07-14T14:06:58  <jtimon> what do you think about utilmoneystr ?
2592016-07-14T14:07:17  *** YOU-JI has quit IRC
2602016-07-14T14:07:29  <sipa> i don't think string conversions belong in consensus
2612016-07-14T14:08:09  <jtimon> I believe we need it for this single error message: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1959
2622016-07-14T14:08:32  <jtimon> maaku was against leaving it out
2632016-07-14T14:08:50  <jtimon> but we could just print satoshis
2642016-07-14T14:09:39  <sipa> ideally consensus logic doesn't need to contain any error strings
2652016-07-14T14:10:15  <sipa> but the alternative is defining huge enums of error constants
2662016-07-14T14:17:09  <jtimon> I'm fine with having tinyformat for now, it's tiny, it says so in the name
2672016-07-14T14:17:54  <jtimon> but yeah, I guess the enum is what errorScript was about
2682016-07-14T14:20:38  *** Chris_St1 has joined #bitcoin-core-dev
2692016-07-14T14:26:13  <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 :)
2702016-07-14T14:26:54  <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
2712016-07-14T14:27:31  <cfields> moves don't happen much in the current code (but will later), but lots of copies.
2722016-07-14T14:28:02  <jeremyrubin> yeah will profile it later today
2732016-07-14T14:29:18  <cfields> jeremyrubin: there's a bench in that commit. just 'git checkout HEAD~1 -- prevector.h' and rebuild to get the before numbers.
2742016-07-14T14:30:58  *** fengling_ has joined #bitcoin-core-dev
2752016-07-14T14:35:46  *** fengling_ has quit IRC
2762016-07-14T14:37:58  *** Chris_St1 has quit IRC
2772016-07-14T14:40:13  *** Chris_St1 has joined #bitcoin-core-dev
2782016-07-14T14:51:46  *** cool_guy has joined #bitcoin-core-dev
2792016-07-14T14:51: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!
2802016-07-14T14:52:41  *** ChanServ sets mode: +o sipa
2812016-07-14T14:52:46  *** sipa sets mode: +b *!*coolguy@*.hsd1.il.comcast.net
2822016-07-14T14:52:46  *** cool_guy was kicked by sipa (cool_guy)
2832016-07-14T14:58:12  *** laurentmt has quit IRC
2842016-07-14T15:02:02  *** d_t has joined #bitcoin-core-dev
2852016-07-14T15:03:15  *** d_t has quit IRC
2862016-07-14T15:03:29  *** d_t has joined #bitcoin-core-dev
2872016-07-14T15:04:45  *** d_t has quit IRC
2882016-07-14T15:05:10  *** xinxi has quit IRC
2892016-07-14T15:05:37  *** xinxi has joined #bitcoin-core-dev
2902016-07-14T15:20:12  <morcos> cfields: i couldn't get your copy-move branch to compile.
2912016-07-14T15:20:34  <morcos> ./prevector.h:253:23: error: 'is_trivially_copyable' is not a member of 'std'
2922016-07-14T15:21:24  *** Chris_St1 has quit IRC
2932016-07-14T15:21:45  *** zooko has joined #bitcoin-core-dev
2942016-07-14T15:23:38  <jeremyrubin> morcos: upgrade your compiler http://stackoverflow.com/questions/25123458/is-trivially-copyable-is-not-a-member-of-std
2952016-07-14T15:23:49  <jeremyrubin> cfields: maybe add these ifdef's for compat
2962016-07-14T15:32:33  *** fengling_ has joined #bitcoin-core-dev
2972016-07-14T15:36:20  <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>
2982016-07-14T15:37:03  *** Chris_St1 has joined #bitcoin-core-dev
2992016-07-14T15:37:10  <cfields> morcos: i'll try to find a trait implemented earlier
3002016-07-14T15:37:26  *** fengling_ has quit IRC
3012016-07-14T15:42:15  *** Chris_St1 has quit IRC
3022016-07-14T15:54:03  <cfields> looks like std::is_pod should work, need to double-check its guarantees though
3032016-07-14T15:57:53  <sipa> when i want information about some standard library function, i usually just type it into my url bar
3042016-07-14T15:57:57  *** sipa sets mode: -o sipa
3052016-07-14T15:58:13  <sipa> unfortunately, the browser interprets std:: as an address scheme
3062016-07-14T15:59:37  *** Chris_St1 has joined #bitcoin-core-dev
3072016-07-14T16:01:40  *** xinxi has quit IRC
3082016-07-14T16:02:22  *** xinxi has joined #bitcoin-core-dev
3092016-07-14T16:03:37  <cfields> heh
3102016-07-14T16:05:34  *** Chris_St1 has quit IRC
3112016-07-14T16:15:40  *** d_t has joined #bitcoin-core-dev
3122016-07-14T16:16:15  *** d_t has joined #bitcoin-core-dev
3132016-07-14T16:21:35  *** Chris_St1 has joined #bitcoin-core-dev
3142016-07-14T16:24:07  *** Arnavion has quit IRC
3152016-07-14T16:25:45  *** Arnavion has joined #bitcoin-core-dev
3162016-07-14T16:28:34  *** Arnavion has quit IRC
3172016-07-14T16:32:49  *** Arnavion has joined #bitcoin-core-dev
3182016-07-14T16:34:06  *** fengling_ has joined #bitcoin-core-dev
3192016-07-14T16:38:46  *** fengling_ has quit IRC
3202016-07-14T16:39:13  <wumpus> putting " around it usually helps
3212016-07-14T16:42:39  *** Chris_St1 has quit IRC
3222016-07-14T16:47:06  *** Chris_St1 has joined #bitcoin-core-dev
3232016-07-14T16:54:28  *** zooko has quit IRC
3242016-07-14T16:57:40  *** zooko has joined #bitcoin-core-dev
3252016-07-14T17:20:41  *** MarcoFalke has joined #bitcoin-core-dev
3262016-07-14T17:21:16  *** harrymm has joined #bitcoin-core-dev
3272016-07-14T17:21:27  *** molz has joined #bitcoin-core-dev
3282016-07-14T17:23:06  *** [b__b] has quit IRC
3292016-07-14T17:23:12  *** moli has quit IRC
3302016-07-14T17:25:01  *** [b__b] has joined #bitcoin-core-dev
3312016-07-14T17:30:23  *** Chris_St1 has quit IRC
3322016-07-14T17:30:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3332016-07-14T17:32:34  <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?
3342016-07-14T17:33:58  <sipa> the placement of codeseparators influences what is passed as scriptCode to signaturehash
3352016-07-14T17:35:00  <sipa> note that codeseparators are assumed to be useless in their current form
3362016-07-14T17:35:27  <bsm2357> Heh
3372016-07-14T17:35:32  *** Chris_Stewart_5 has quit IRC
3382016-07-14T17:35:39  *** fengling_ has joined #bitcoin-core-dev
3392016-07-14T17:35:39  <bsm2357> Ok then client code.  (I'm copying test cases from BIP143)
3402016-07-14T17:36:26  <sipa> but you should already be doing that
3412016-07-14T17:36:49  <sipa> bip143 does not affect the behaviour of code separators
3422016-07-14T17:38:00  <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.
3432016-07-14T17:39:12  *** [b__b] has quit IRC
3442016-07-14T17:40:26  *** fengling_ has quit IRC
3452016-07-14T17:42:35  <kanzure> SignatureHash isn't so bad
3462016-07-14T17:42:47  <kanzure> (besides the strange name; i appreciate jl2012's signature digest algorithm name idea)
3472016-07-14T17:44:05  *** [b__b] has joined #bitcoin-core-dev
3482016-07-14T17:44:56  *** delinquentme has joined #bitcoin-core-dev
3492016-07-14T17:50:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3502016-07-14T17:53:23  *** [b__b] has quit IRC
3512016-07-14T17:59:37  *** [b__b] has joined #bitcoin-core-dev
3522016-07-14T18:09:05  <jtimon> meeting is now or in an hour?
3532016-07-14T18:11:23  <eragmus> jtimon: 49 min.
3542016-07-14T18:12:00  <jtimon> eragmus: yeah, thanks, it definitely didn't look like it was now ;)
3552016-07-14T18:12:39  <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?
3562016-07-14T18:15:42  <sipa> morcos: i always assumed the inexpensive checks are actually not expensive
3572016-07-14T18:15:52  <sipa> only fetching of the inputs is
3582016-07-14T18:15:55  <sipa> am i wrong
3592016-07-14T18:15:57  <sipa> ?
3602016-07-14T18:16:29  <morcos> sipa: i'm about to try to separately bench UpdateCoins
3612016-07-14T18:16:41  <morcos> but do you think the fetching is expensive if we are caching well?
3622016-07-14T18:16:46  *** jtimon has quit IRC
3632016-07-14T18:17:12  <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
3642016-07-14T18:18:40  <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
3652016-07-14T18:19:11  *** [b__b] has quit IRC
3662016-07-14T18:24:10  *** molz has quit IRC
3672016-07-14T18:26:39  *** moli has joined #bitcoin-core-dev
3682016-07-14T18:27:24  *** [b__b] has joined #bitcoin-core-dev
3692016-07-14T18:30:27  <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.
3702016-07-14T18:32:42  *** [b__b] has quit IRC
3712016-07-14T18:33:25  <morcos> When I get a chance, I'll test out moving many more of the input checks into the parallelized part.
3722016-07-14T18:35:39  *** [b__b] has joined #bitcoin-core-dev
3732016-07-14T18:37:06  *** fengling_ has joined #bitcoin-core-dev
3742016-07-14T18:37:32  <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=
3752016-07-14T18:37:52  <bsm2357> It's a P2WPKH so I'm confused, the script is implicit
3762016-07-14T18:38:48  <sipa> bsm2357: make bitcoind print out the signaturehash it is checking
3772016-07-14T18:38:56  <sipa> and compare that to the value you're signing
3782016-07-14T18:39:27  <bsm2357> This may still be a bad sighash then?
3792016-07-14T18:41:07  *** yep has joined #bitcoin-core-dev
3802016-07-14T18:41:37  <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
3812016-07-14T18:41:38  <bsm2357> Ah nm, need to pass SIGVERSION_WITNESS_V0 to *use* the new SignatureHash...
3822016-07-14T18:41:46  *** fengling_ has quit IRC
3832016-07-14T18:42:00  <bsm2357> Thanks sdaftuar I've been reviewing that for days ;-)
3842016-07-14T18:42:14  <sdaftuar> haha okay :)
3852016-07-14T18:54:17  *** Chris_Stewart_5 has quit IRC
3862016-07-14T18:55:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3872016-07-14T18:58:25  <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.
3882016-07-14T18:59:42  <wumpus> meeting time?
3892016-07-14T18:59:45  <jl2012> bsm2357: there are some test vectors in BIP143
3902016-07-14T19:00:04  <bsm2357> I know, I wrote tests for them!  They all pass.  :-P
3912016-07-14T19:00:15  <bsm2357> Thanks for that ;-)
3922016-07-14T19:00:40  <sipa> wumpus: ack
3932016-07-14T19:00:52  <wumpus> #startmeeting
3942016-07-14T19:00:52  <lightningbot> Meeting started Thu Jul 14 19:00:52 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3952016-07-14T19:00:52  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3962016-07-14T19:00:53  <instagibbs> actually here this time
3972016-07-14T19:01:47  <cfields> gmaxwell: ping for pings :)
3982016-07-14T19:01:48  <wumpus> gmaxwell jonasschnelli sdaftuar jtimon kanzure MarcoFalke
3992016-07-14T19:01:57  <jonasschnelli> pong
4002016-07-14T19:02:33  <wumpus> topic suggestions?
4012016-07-14T19:02:40  *** gabridome has joined #bitcoin-core-dev
4022016-07-14T19:02:41  <jonasschnelli> proposal: open 0.13 PRs (https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0)
4032016-07-14T19:02:42  <wumpus> (besides 0.13.0rc1)
4042016-07-14T19:02:52  <instagibbs> segwit backport?
4052016-07-14T19:02:58  <sipa> ack topic
4062016-07-14T19:03:13  <wumpus> #topic 0.13.0rc1
4072016-07-14T19:03:20  <wumpus> #link https://github.com/bitcoin/bitcoin/milestone/20
4082016-07-14T19:03:29  <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
4092016-07-14T19:03:48  <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
4102016-07-14T19:03:48  <wumpus> most of the remaining PRs have been merged, but there are still a few open
4112016-07-14T19:04:09  <jonasschnelli> I beg for reviews...
4122016-07-14T19:04:13  <instagibbs> jonasschnelli, I can review
4132016-07-14T19:04:24  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8305 Improve handling of unconnecting headers by sdaftuar
4142016-07-14T19:04:44  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8295 Mining-related fixups for 0.13.0 also by sdaftuar
4152016-07-14T19:04:49  <wumpus> and jonasschnelli's
4162016-07-14T19:05:04  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8323
4172016-07-14T19:05:14  <instagibbs> #link https://github.com/bitcoin/bitcoin/pull/8323
4182016-07-14T19:05:27  *** achow101 has left #bitcoin-core-dev
4192016-07-14T19:05:37  *** achow101 has joined #bitcoin-core-dev
4202016-07-14T19:05:38  <wumpus> I think #8305 is pretty much ready
4212016-07-14T19:06:02  <wumpus> has ACK by sipa and is being tested by gmaxwell
4222016-07-14T19:06:10  <sdaftuar> i think sipa acked an earlier version of the code
4232016-07-14T19:06:12  <bsm2357> pong
4242016-07-14T19:06:36  *** pmienk has quit IRC
4252016-07-14T19:06:37  <instagibbs> jeremyrubin *ping*
4262016-07-14T19:07:00  <wumpus> cfields: has your comment there been addressed sufficiently?
4272016-07-14T19:07:19  <sdaftuar> oh, thanks sipa :)
4282016-07-14T19:07:32  *** bsm2357 is now known as bsm117532
4292016-07-14T19:07:51  <cfields> wumpus: yes, i'm happy with the slow DOS trickle
4302016-07-14T19:08:04  <jeremyrubin> instagibbs: yes?
4312016-07-14T19:08:32  <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
4322016-07-14T19:09:13  <sipa> yeah, the reason i didn't include telhr 8295 approach myself was because i incorectly assumed it would require extra counters
4332016-07-14T19:09:27  <wumpus> jonasschnelli: #8323 still has some open comments
4342016-07-14T19:09:40  <sipa> and the existing tests cover it
4352016-07-14T19:09:41  <wumpus> trivial things though
4362016-07-14T19:09:48  <MarcoFalke> no blockers
4372016-07-14T19:09:56  *** d_t has quit IRC
4382016-07-14T19:09:58  <jonasschnelli> Yes. paveljanik just added some... will fix the trivials together (once there are some)
4392016-07-14T19:10:05  <morcos> sipa: are you referring to mining unit tests?
4402016-07-14T19:10:10  <sipa> morcos: yes
4412016-07-14T19:10:25  <sipa> (well, and any rpc test that mines)
4422016-07-14T19:10:30  <morcos> sipa: those aren't worth much, they've been in need of redoing for some time
4432016-07-14T19:10:43  <sipa> hmm, ok
4442016-07-14T19:10:49  <wumpus> jonasschnelli: I'll also review and test it soon
4452016-07-14T19:10:55  <jonasschnelli> thanks
4462016-07-14T19:11:03  <morcos> not that i'm objecting to 8295 though
4472016-07-14T19:11:07  <sipa> morcos: i'll test by running old and new in parallel and comparing then
4482016-07-14T19:12:08  <wumpus> great
4492016-07-14T19:13:19  <wumpus> sdaftuar: I don't think all items of https://github.com/bitcoin/bitcoin/issues/8294 are currenly being addressed in PRs?
4502016-07-14T19:13:29  <luke-jr> a quick glance at 8323 suggests it won't make problems with key origin stuff, rihgt?
4512016-07-14T19:14:09  <wumpus> sdaftuar: any blockers remaining there?
4522016-07-14T19:14:20  <wumpus> (after all currenly 0.13-tagged PRs are merged)
4532016-07-14T19:14:34  *** jtimon has joined #bitcoin-core-dev
4542016-07-14T19:14:35  <wumpus> luke-jr: let's discuss that outside the meeting please
4552016-07-14T19:14:51  <luke-jr> ….
4562016-07-14T19:14:57  <sdaftuar> wumpus: i was waiting for #8295 to be merged before doing the release notes writeups
4572016-07-14T19:15:14  <sdaftuar> oh, should we talk about -blockmaxcost briefly?
4582016-07-14T19:15:16  <wumpus> sdaftuar: oh release notes writeups aren't urgent, they need to be done for final but not rc1
4592016-07-14T19:15:17  <luke-jr> (what's the point of a meeting if not to discuss the topics raised?)
4602016-07-14T19:15:41  <sdaftuar> one of the to do items was better documentation for that option, but as has been pointed out, it's an awful name :)
4612016-07-14T19:16:08  <sipa> sdaftuar: suggested replacement?
4622016-07-14T19:16:25  <wumpus> yes, the 'max cost' confuses people, they think it's about monetary cost
4632016-07-14T19:16:31  <petertodd> wumpus: +1
4642016-07-14T19:16:33  <wumpus> (and that's also how translators translate it)
4652016-07-14T19:16:40  <luke-jr> >_<
4662016-07-14T19:16:50  <wumpus> (and it's a public command line option so the help gets translated)
4672016-07-14T19:16:59  <sipa> we could have maxblockvsize instead
4682016-07-14T19:16:59  <petertodd> blockmaxcost is still just a size limit isn't it?
4692016-07-14T19:17:02  <gmaxwell> Cost has been a repeated source of confusion.
4702016-07-14T19:17:02  <wumpus> but that means the help needs to be improved, not necessarily the option renamed
4712016-07-14T19:17:03  <luke-jr> well, it *is* indirectly monetary
4722016-07-14T19:17:17  <jeremyrubin> maybe utilization
4732016-07-14T19:17:20  <sipa> petertodd: it's the 'cost' as defined in the BIP, which is vsize*4
4742016-07-14T19:17:40  <gmaxwell> Score/points/weight/usage/ouchie/bitgo  would all be better words for it.
4752016-07-14T19:17:42  <luke-jr> "network resource usage"?
4762016-07-14T19:17:43  <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
4772016-07-14T19:17:43  <wumpus> it's an abstract cost, and CS students understand that, but for most users it's confusing :)
4782016-07-14T19:18:01  <sipa> sdaftuar: yes, agree, let's makr it consistent, whatever we agree upon
4792016-07-14T19:18:15  <petertodd> sdaftuar: yeah, I think changing the BIP's term is a good idea too - it's still a size, just a redefined size
4802016-07-14T19:18:17  *** pmienk has joined #bitcoin-core-dev
4812016-07-14T19:18:23  <CodeShark> #agree
4822016-07-14T19:18:24  <wumpus> block size validation cost would already be better help than there is now
4832016-07-14T19:18:30  <luke-jr> petertodd: it's not a size.
4842016-07-14T19:18:32  <petertodd> notably, if we had referred to block size in the BIP, that'd help discourage the trolls...
4852016-07-14T19:18:33  <gmaxwell> "externality"
4862016-07-14T19:18:44  <gmaxwell> luke-jr: it is a size, in cost-space.
4872016-07-14T19:18:47  <sipa> well, any reason not use vsize?
4882016-07-14T19:18:49  <petertodd> segwit *is* a blocksize increase, so just continue to call it a size
4892016-07-14T19:18:53  <petertodd> sipa: vsize is fine
4902016-07-14T19:19:00  <wumpus> yes vsize is fine
4912016-07-14T19:19:09  <btcdrak>  yes
4922016-07-14T19:19:10  <petertodd> sipa: (so long as the help text explains what vsize is)
4932016-07-14T19:19:12  <luke-jr> vsize is inaccurate
4942016-07-14T19:19:15  <gmaxwell> V means validation?
4952016-07-14T19:19:21  <sipa> virtual
4962016-07-14T19:19:24  <luke-jr> going to *4 the meaning, so people specify x.25 now?
4972016-07-14T19:19:27  <sdaftuar> hm, we have been using vsize to refer to the scaled down value, not the *4 value?
4982016-07-14T19:19:27  <btcdrak> v for vendetta
4992016-07-14T19:19:28  <gmaxwell> ugh, there is nothing virtual about it.
5002016-07-14T19:19:36  <petertodd> gmaxwell: +1
5012016-07-14T19:19:38  <luke-jr> fractional values for consensus code?
5022016-07-14T19:19:50  <petertodd> sdaftuar: that's a mistake then
5032016-07-14T19:19:56  <sipa> sdaftuar: yes, cost == vsize * 4
5042016-07-14T19:19:59  <gmaxwell> re fractional values, haven't we learned from difficulty?
5052016-07-14T19:20:06  <sipa> vsize is cost, but scaled down for compatibility with old code
5062016-07-14T19:20:15  <sipa> so they don't start sending 4x fees etc
5072016-07-14T19:20:18  <gmaxwell> if we use fractional values for display friendlyness, other people will use them in consensus code and cause faults.
5082016-07-14T19:20:35  * luke-jr grabs a thesaurus
5092016-07-14T19:20:36  <gmaxwell> sipa: ::sigh:: point.
5102016-07-14T19:20:37  <btcdrak> agreed
5112016-07-14T19:20:46  <jeremyrubin> I like weight the best
5122016-07-14T19:20:56  <wumpus> agree jeremyrubin
5132016-07-14T19:20:59  <jeremyrubin> because usually you would say a weighted sum
5142016-07-14T19:21:05  <sipa> jeremyrubin: nice idea
5152016-07-14T19:21:07  <wumpus> weight is a pretty good term for it
5162016-07-14T19:21:09  <CodeShark> #agree
5172016-07-14T19:21:17  <btcdrak> good call
5182016-07-14T19:21:21  <wumpus> and it's not used anywhere yet in bitcoin
5192016-07-14T19:21:24  <jeremyrubin> (gmaxwell: mentioned first)
5202016-07-14T19:21:33  <luke-jr> outlay? :/
5212016-07-14T19:21:41  <luke-jr> weight sounds fine
5222016-07-14T19:22:04  *** [b__b] has quit IRC
5232016-07-14T19:22:30  <jtimon> yeah, there's two sizes with their weights, it's a cost heuristic
5242016-07-14T19:22:40  <wumpus> so: rename blockmaxcost to blockmaxweight?
5252016-07-14T19:22:43  <instagibbs> "weight" also carries a nice intuitive notion
5262016-07-14T19:22:57  <sipa> yes, and let's report weight for transactions too
5272016-07-14T19:22:57  <jeremyrubin> maxblockweightcostheuristic
5282016-07-14T19:23:06  <gmaxwell> I read that as block mascot.
5292016-07-14T19:23:18  <wumpus> hehe
5302016-07-14T19:23:19  <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
5312016-07-14T19:23:21  <jeremyrubin> virtualmaxblockweightcostheuristic
5322016-07-14T19:23:21  <jtimon> sorry, I missed the first 15 mins or so, but why do we need to rename blockmaxcost ?
5332016-07-14T19:23:32  <luke-jr> petertodd: size is something else
5342016-07-14T19:23:33  <gmaxwell> jtimon: because the word cost is confused as fee.
5352016-07-14T19:24:02  <sdaftuar> i think "block weight" and -blockmaxweight [
5362016-07-14T19:24:11  <sdaftuar> both work okay
5372016-07-14T19:24:14  <btcdrak> ack
5382016-07-14T19:24:17  *** gabridome1 has joined #bitcoin-core-dev
5392016-07-14T19:24:31  <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 :)
5402016-07-14T19:24:35  <jtimon> mhmm, no, it's costs for the miners, although that's also why they charge you fees
5412016-07-14T19:24:40  <luke-jr> weight also should be fine for GBT; nothing is released using the old cost stuff yet
5422016-07-14T19:24:59  <luke-jr> jtimon: is there a problem with "weight"?
5432016-07-14T19:25:08  <gmaxwell> in any case, I support the great cost to weight renaming.
5442016-07-14T19:25:09  <sipa> petertodd: that's what i did originally
5452016-07-14T19:25:14  <wumpus> #action rename blockmaxcost to blockmaxweight
5462016-07-14T19:25:23  <jtimon> yeah, sorry I'll wait for botbot.me to update
5472016-07-14T19:25:26  <instagibbs> We can chew it over offline
5482016-07-14T19:25:29  <petertodd> sipa: well, ack your original idea :)
5492016-07-14T19:25:46  <sipa> petertodd: but then people started complaining that there had to be a way to limit the serialized size too
5502016-07-14T19:26:01  <jeremyrubin> jtimon: but that's not the units of the cost, otherwise you would denote it into BTC or something...
5512016-07-14T19:26:05  <btcdrak> jtimon: you can see.logs in slack
5522016-07-14T19:26:15  *** gabridome has quit IRC
5532016-07-14T19:27:00  <petertodd> jeremyrubin: blockbytescost :)
5542016-07-14T19:27:04  *** gabridome1 has quit IRC
5552016-07-14T19:27:19  *** gabridome has joined #bitcoin-core-dev
5562016-07-14T19:27:34  <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
5572016-07-14T19:27:58  *** gabridome1 has joined #bitcoin-core-dev
5582016-07-14T19:28:20  <wumpus> other topics?
5592016-07-14T19:28:28  <sipa> segwit backport
5602016-07-14T19:28:31  <wumpus> ah yes
5612016-07-14T19:28:34  <wumpus> #topic segwit backport
5622016-07-14T19:28:39  <jtimon> btcdrak: I didn't knew, never used the bitcoin slack
5632016-07-14T19:28:49  *** maaku has joined #bitcoin-core-dev
5642016-07-14T19:29:04  <sipa> wumpus: some people have raised concerns about backporting segwit to 0.12
5652016-07-14T19:29:24  <wumpus> concerns about doing it at all?
5662016-07-14T19:29:25  <jtimon> what's the concern?
5672016-07-14T19:29:31  <luke-jr> ^
5682016-07-14T19:29:35  <wumpus> well, next chance is 0.13.1
5692016-07-14T19:29:50  *** [b__b] has joined #bitcoin-core-dev
5702016-07-14T19:29:51  <sipa> morcos, btcdrak: ?
5712016-07-14T19:30:21  <morcos> :), yes i was arguing that it would be a mistake
5722016-07-14T19:30:33  <jl2012> me too
5732016-07-14T19:30:36  <instagibbs> could you reiterate for the audience
5742016-07-14T19:30:49  <jtimon> if the backport doesn't get enough review and testing there's no new 0.12 release, simple, no?
5752016-07-14T19:30:54  <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
5762016-07-14T19:31:04  <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
5772016-07-14T19:31:04  <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...
5782016-07-14T19:31:06  <maaku> if that were the case then I would have to argue that we wait until 0.14.1 .. so strong argument is needed
5792016-07-14T19:31:10  <luke-jr> jtimon: backports never do, unless they're the tip release
5802016-07-14T19:31:28  <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
5812016-07-14T19:31:34  <btcdrak> yes. I share morcos concerns about backporting
5822016-07-14T19:31:37  *** gabridome has quit IRC
5832016-07-14T19:31:44  <luke-jr> wumpus: "too bad" may result in delayed deployment maybe
5842016-07-14T19:31:46  <jtimon> luke-jr: so all previous backported softforks were unsafe ?
5852016-07-14T19:31:58  <luke-jr> jtimon: such as?
5862016-07-14T19:31:59  <wumpus> luke-jr: yes, but delay is better than messing up
5872016-07-14T19:32:08  <sipa> about this topic
5882016-07-14T19:32:21  <sipa> in the past we've seen miners often run even pre-release code
5892016-07-14T19:32:27  <jtimon> luke-jr: I don't know if any of them was unsafe, I'm asking
5902016-07-14T19:32:34  <sipa> if that is going to happen, my concerns about a backport go down
5912016-07-14T19:32:38  <wumpus> I hate delays, but minimizing risk is the highest priority
5922016-07-14T19:32:39  <sipa> but so does its usefulness
5932016-07-14T19:32:40  <jl2012> have anyone asked miners that they really need a backport?
5942016-07-14T19:32:41  <maaku> i'm strongly against "too bad" -- we need to take our support guarantees seriously
5952016-07-14T19:32:46  <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.
5962016-07-14T19:33:01  *** spudowiar has joined #bitcoin-core-dev
5972016-07-14T19:33:03  <morcos> maaku: we already didn't backport CSV
5982016-07-14T19:33:11  <wumpus> maaku: there are no guarantees
5992016-07-14T19:33:11  <maaku> people are running businesses assuming we support "current plus prior" not "current plus prior, except when it's inconvenient"
6002016-07-14T19:33:18  <gmaxwell> maaku: doing segwit in 0.13.1 isn't a violation of the process, that still remains no softforks in major feature releases.
6012016-07-14T19:33:37  <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
6022016-07-14T19:33:49  <maaku> gmaxwell: it would mean you could no longer mine on 0.12
6032016-07-14T19:33:50  <sipa> jl2012: that's the most important question
6042016-07-14T19:33:56  <wumpus> this is not about 'inconvenient', this is about risk
6052016-07-14T19:33:58  <morcos> gmaxwell: are you more worried about miners or users?
6062016-07-14T19:34:16  *** [b__b] has quit IRC
6072016-07-14T19:34:18  <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.
6082016-07-14T19:34:26  <gmaxwell> morcos: users.
6092016-07-14T19:34:35  <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
6102016-07-14T19:34:35  *** [b__b] has joined #bitcoin-core-dev
6112016-07-14T19:34:49  <wumpus> we wouldn't want a DAO scale disaster over over-hurried release of hardly-reviewed and tested code
6122016-07-14T19:35:03  <CodeShark> wumpus +1
6132016-07-14T19:35:07  <petertodd> miners that truly need v0.12 might be better off mining with a v0.12 node behind a segwit 0.13 node...
6142016-07-14T19:35:09  <wumpus> so if it needs to be 0.13.1, it will be 0.13.1
6152016-07-14T19:35:25  <gmaxwell> Sure.
6162016-07-14T19:35:39  <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?
6172016-07-14T19:35:44  <luke-jr> maaku: we need to stop guaranteeing things we can't providr
6182016-07-14T19:36:01  <achow101> how many miners even use backports?
6192016-07-14T19:36:05  <wumpus> morcos: no - if it would be in 0.12.2, it could make it into 0.13.0 too
6202016-07-14T19:36:14  <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.
6212016-07-14T19:36:17  <wumpus> morcos: assuming 0.12.2 is released before 0.13.0 of course
6222016-07-14T19:36:18  <luke-jr> achow101: all of htem right now I think
6232016-07-14T19:36:22  <jtimon> morcos: maybe rebasing my code to 0.13.1 is not easier than rebasing it to 0.12.2
6242016-07-14T19:36:24  <wumpus> morcos: then again that ship sailed already
6252016-07-14T19:37:31  <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
6262016-07-14T19:37:32  <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.
6272016-07-14T19:38:08  <achow101> what about releasing 0.13.1 and then 0.12.2?
6282016-07-14T19:38:20  <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
6292016-07-14T19:38:35  *** fengling_ has joined #bitcoin-core-dev
6302016-07-14T19:38:53  <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
6312016-07-14T19:38:53  <wumpus> achow101: well if a backport is released at all, why would it matter in what order?
6322016-07-14T19:39:00  <gmaxwell> Wouldn't want to make a classic blunder, "never get involved in a land war in Asia"!
6332016-07-14T19:39:00  <morcos> anyway, sorry, i have to catch a train, got to run!
6342016-07-14T19:39:03  <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
6352016-07-14T19:39:30  <btcdrak> It's also a lot cleaner releasing in 0.13.1 because 0.12 would not have compact blocks
6362016-07-14T19:39:37  <luke-jr> wumpus: order matters a lot for testing
6372016-07-14T19:39:48  <petertodd> sipa: sure, if it removed getblocktemplate that'd be an easy idea to support
6382016-07-14T19:39:56  <gmaxwell> well right now 0.13.0 doesn't have CB for segwit, though I suppose 0.13.1 could.
6392016-07-14T19:39:57  <jtimon> sipa: yeah, I assumed that was the plan
6402016-07-14T19:40:00  <achow101> wumpus: for proper review of the backport without delaying deployment
6412016-07-14T19:40:03  <wumpus> I do wish we had realized this sooner, instead of seeming like a last minute decision
6422016-07-14T19:40:09  <gmaxwell> wumpus: likewise.
6432016-07-14T19:40:21  <wumpus> achow101: even fewer people will care about 0.12.x if 0.13 is already out
6442016-07-14T19:40:31  <gmaxwell> otoh, decisions to do _less_ at the last minute are better than decisions to do _more_. :)
6452016-07-14T19:40:35  <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.
6462016-07-14T19:40:37  <sipa> i guess the question is what has priority: segwit backport or 0.13 release?
6472016-07-14T19:40:38  <wumpus> gmaxwell: hah, fully agreed
6482016-07-14T19:40:54  <petertodd> sipa: 0.13 release I think
6492016-07-14T19:41:00  <gmaxwell> We have real problems with virtually no one ever using backports.
6502016-07-14T19:41:06  <wumpus> for me the 0.13 release has priority
6512016-07-14T19:41:09  <helo> +1 release
6522016-07-14T19:41:17  <jonasschnelli> agree with wumpus
6532016-07-14T19:41:18  <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
6542016-07-14T19:41:30  <gmaxwell> 0.13 release has priority.
6552016-07-14T19:41:33  <sipa> and if that is the case, a backport would be urgent
6562016-07-14T19:41:36  <jtimon> waiting to release 0.13 to release 0.12.2 first sounds stupid to me
6572016-07-14T19:41:43  <sipa> or 0.13.1 would suffer delays
6582016-07-14T19:41:55  <btcdrak> sipa: getting enough review for backport to 0.12.2 would be questionable.
6592016-07-14T19:41:57  <gmaxwell> sipa: yes, that was my expectation too, though the release of 0.13 would likely sabotage 0.12.2 deployment.
6602016-07-14T19:42:00  <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
6612016-07-14T19:42:08  <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
6622016-07-14T19:42:24  <jtimon> petertodd: that's a good idea
6632016-07-14T19:42:35  <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?
6642016-07-14T19:42:37  <sipa> if there are critical bugs in 0.12.1, we can always release 0.12.2 to fix them
6652016-07-14T19:42:37  <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).
6662016-07-14T19:42:39  <petertodd> jtimon: I think we've done it before too
6672016-07-14T19:42:56  <jtimon> and depending on the response decide to the the backport or not
6682016-07-14T19:42:57  <sipa> btcdrak: tbh, i think that the difficulty of a segwit backport is not that hard
6692016-07-14T19:43:02  <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.
6702016-07-14T19:43:11  <btcdrak> sipa: you would say that though :)
6712016-07-14T19:43:12  <sipa> btcdrak: the original segwit PR was made with mostly 0.12 code still
6722016-07-14T19:43:14  <gmaxwell> luke-jr: maybe we should start making more really disruptive changes in major releases. :)
6732016-07-14T19:43:26  *** fengling_ has quit IRC
6742016-07-14T19:43:29  <wumpus> 'maintain' older branches does not mean backport everything
6752016-07-14T19:43:35  <jonasschnelli> agree
6762016-07-14T19:43:37  <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
6772016-07-14T19:43:48  <wumpus> just that serious and critical issues are addressed
6782016-07-14T19:43:53  <sipa> yes  0.12.2 can still happen if a serioud bug in 0.12.1 is founf
6792016-07-14T19:44:06  <luke-jr> wumpus: not supporting a deployed softfork is a critical issue for a full node
6802016-07-14T19:44:08  <jtimon> gmaxwell: I've been always in favor of doing disruptive refactors just before branching instead of right after
6812016-07-14T19:44:27  *** gabridome has joined #bitcoin-core-dev
6822016-07-14T19:44:39  <sipa> ok, i need to run
6832016-07-14T19:44:49  <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
6842016-07-14T19:44:57  <sipa> i'll still work on a backport if there is demand
6852016-07-14T19:45:08  <luke-jr> jonasschnelli: that's a point I suppose
6862016-07-14T19:45:16  <gmaxwell> sipa: it might be a useful excercise from a review perspective in any case.
6872016-07-14T19:45:19  <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)
6882016-07-14T19:45:27  <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
6892016-07-14T19:45:52  <luke-jr> petertodd: true; we should make this more well-known IMO
6902016-07-14T19:45:58  <luke-jr> not sure how many people realise it
6912016-07-14T19:46:02  <petertodd> luke-jr: good thing for the release notes!
6922016-07-14T19:46:05  <gmaxwell> I always point it out.
6932016-07-14T19:46:08  <jtimon> wumpus: I mean the of the kind that present low risk (like file renaming on moveonly commits)
6942016-07-14T19:46:16  <gmaxwell> but it's the sort of thing that needs a diagram. :)
6952016-07-14T19:46:20  <luke-jr> gmaxwell: did you for Eligius? :P
6962016-07-14T19:46:26  <CodeShark> petertodd +1
6972016-07-14T19:46:32  <maaku> has anyone actually quantified what level of review is required for a backport?
6982016-07-14T19:46:32  * luke-jr knows he overlooked it
6992016-07-14T19:46:33  <jtimon> wumpus: but I guess you're right about the pre-release preassure
7002016-07-14T19:46:47  <maaku> segwit was written against 0.12.
7012016-07-14T19:46:48  <luke-jr> actually, I guess it might not entirely work for CSV + mining
7022016-07-14T19:46:48  <wumpus> jtimon: in any case I doubt raneming and moveonly commits are what really makes it difficult to backport things :)
7032016-07-14T19:46:53  <wumpus> jtimon: more things like the mempool changes
7042016-07-14T19:47:34  <jl2012> petertodd: except you can't mine any segwit tx with a 0.12 behind 0.13
7052016-07-14T19:47:40  <btcdrak> well I'd like to see a refactoring window right after branching, maybe 2 weeks
7062016-07-14T19:47:41  <jtimon> but you don't need to backport segwit from the present, you backport it from when it was merged, no?
7072016-07-14T19:47:54  <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.
7082016-07-14T19:48:11  <jtimon> how would any refactor now difficult backporting segwit?
7092016-07-14T19:48:15  <gmaxwell> luke-jr: I don't consider that a great configuration for mining, but I think I'd mentioned it for a prior softfork.
7102016-07-14T19:48:33  *** gabridome1 has quit IRC
7112016-07-14T19:48:45  <wumpus> we're spread really thin - agree fully on the 'don't get involved in a land war in asia' comment
7122016-07-14T19:49:16  <petertodd> jl2012: "can't mine" is a smaller group of people than all full node users
7132016-07-14T19:50:14  <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
7142016-07-14T19:50:17  <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
7152016-07-14T19:51:54  <btcdrak> jtimon: ack
7162016-07-14T19:52:14  <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!"
7172016-07-14T19:52:56  <gmaxwell> in any case, short on time. Are we done on this subject?
7182016-07-14T19:53:03  <instagibbs> 8 minutes left
7192016-07-14T19:53:08  <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
7202016-07-14T19:53:54  <gmaxwell> petertodd: perhaps we should talk to harding and write a deployment guide that  shows things like that layering and test infrastructure.
7212016-07-14T19:53:55  <wumpus> seems so
7222016-07-14T19:54:01  <petertodd> gmaxwell: good idea
7232016-07-14T19:54:15  <gmaxwell> Generally you should have a two later setup in any case, don't put your production node up exposed to the internet...
7242016-07-14T19:54:29  <petertodd> gmaxwell: that too...
7252016-07-14T19:54:47  <wumpus> other topics? last-minute announcements?
7262016-07-14T19:55:38  <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.
7272016-07-14T19:56:00  <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.
7282016-07-14T19:56:11  <jtimon> can be after the meeting but...
7292016-07-14T19:56:12  <wumpus> well if bitcoin core's wallet is unusable for commercial use, I wonder what wallet is..
7302016-07-14T19:56:25  <bsm117532> FWIW I've been encountering wallet issues, and am working on a patch that addresses some of them, especially WRT segwit.
7312016-07-14T19:56:28  <gmaxwell> What I could extra there was related to wallet performance, which phantomcircuit has recently done some improvement (and has more in the pipeline)
7322016-07-14T19:56:42  <gmaxwell> wumpus: people use centeralized api providers instead almost universally.
7332016-07-14T19:56:55  <bsm117532> But I would like to see removal of "accounts".  Is anyone working on that?
7342016-07-14T19:57:17  <wumpus> bsm117532: I tried to introduce a label API for 0.13 to replace it, then deprecate accounts in 0.14
7352016-07-14T19:57:21  <petertodd> bsm117532: re: removing accounts, have you checked with joinmarket on what they'll do? they use accounts
7362016-07-14T19:57:28  <wumpus> bsm117532: but that didn't get enough review
7372016-07-14T19:57:41  <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
7382016-07-14T19:57:54  <jtimon> yay nay ?
7392016-07-14T19:58:02  <wumpus> bsm117532: https://github.com/bitcoin/bitcoin/pull/7729
7402016-07-14T19:58:06  <sipa> jtimon: yay, after 0
7412016-07-14T19:58:25  <jtimon> sipa: yeah, I'm assuming after 0.13 branches
7422016-07-14T19:58:51  <wumpus> petertodd: that'd be really ill-adviced, given that we've been discouraging use of them for years, are you sure?
7432016-07-14T19:58:52  <gmaxwell> ironically, one of the complaints I got there was that accounts are discouraged. ::shrugs::
7442016-07-14T19:58:56  <sipa> though i prefer to leave some things as "base logic" like maaku suggests
7452016-07-14T19:58:58  <jtimon> I mean, if people want before I'm all in, but I highly doubt it
7462016-07-14T19:59:12  <btcdrak> we should ping belcher
7472016-07-14T19:59:13  <petertodd> wumpus: yes, I'm 99% sure - I use joinmarket all the time
7482016-07-14T19:59:34  <bsm117532> wumpus: I will review 7729 and try to offer some feedback
7492016-07-14T19:59:39  <btcdrak> he's got some homework then...
7502016-07-14T19:59:45  <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
7512016-07-14T19:59:50  <luke-jr> I need to get back on the road, bbl
7522016-07-14T19:59:53  <sipa> maaku: agree
7532016-07-14T19:59:56  <jtimon> sipa: mhmm, you mean making another "base logic" dir and package in the makefile ?
7542016-07-14T20:00:13  <sipa> jtimon: well one such piece of base logic is primitives
7552016-07-14T20:00:26  <petertodd> maaku: less approchable? I'd argue more - makes it easier to understand what consensus is and isn't
7562016-07-14T20:00:29  <wumpus> gmaxwell: it's also taking so insanely long to remove it
7572016-07-14T20:00:37  <jtimon> maaku: I strongly disagree (but maybe not all people are mostly interested in the consensus code like me)
7582016-07-14T20:00:49  <wumpus> gmaxwell: same as I've seen with the label API pull - no one is really interested in it
7592016-07-14T20:00:54  <sipa> jtimon: things like prevector and so seem also more broadly usable than consensus
7602016-07-14T20:00:58  <maaku> petertodd: that's rarely someone's first question when approaching the code base
7612016-07-14T20:01:00  <afk11> I think keeping some base logic outside may work, ultimately serialization libraries might be soft-forks wrt an older consensus implementation
7622016-07-14T20:01:15  <sipa> time up
7632016-07-14T20:01:18  <btcdrak> well I hate to say it, but its not like the code is that approachable as is...
7642016-07-14T20:01:20  <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?
7652016-07-14T20:01:20  <wumpus> #endmeeting
7662016-07-14T20:01:21  <lightningbot> Meeting ended Thu Jul 14 20:01:20 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7672016-07-14T20:01:21  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.html
7682016-07-14T20:01:21  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.txt
7692016-07-14T20:01:21  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.log.html
7702016-07-14T20:01:28  <jtimon> sipa: agreed, but libconsensus needs them if we're ever going to separate the library ala libsecp
7712016-07-14T20:01:31  <instagibbs> btcdrak, heh
7722016-07-14T20:01:36  <maaku> btcdrak: it is way better than when I started
7732016-07-14T20:01:40  <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
7742016-07-14T20:01:42  <maaku> so please don't make it worse
7752016-07-14T20:01:48  <sipa> jtimon: there's no problem in dependong on things outside of consensus
7762016-07-14T20:01:57  <gmaxwell> It's my guess that if the label stuff is done removing accounts is much easier, as that the only legit use.
7772016-07-14T20:02:04  <wumpus> gmaxwell:  https://github.com/bitcoin/bitcoin/pull/7729
7782016-07-14T20:02:05  <sipa> jtimon: we also depend on libstdc++ and an OS, righ
7792016-07-14T20:02:07  <petertodd> maaku: that's how I learned how the bitcoin protocol works
7802016-07-14T20:02:07  <btcdrak> maaku: beauty is in the eye of the beholder :-p
7812016-07-14T20:02:11  <jtimon> no, I mean, if at some point libconsensus becomes its own repo
7822016-07-14T20:02:17  <maaku> petertodd: that doesn't require the files to literally be in the same directory.
7832016-07-14T20:02:24  <jonasschnelli> Yes. We should reconsider wumpus  7729
7842016-07-14T20:02:28  * btcdrak is just teasing
7852016-07-14T20:02:30  <maaku> when you see #include <script/interpreter.h> you know to find it in the src/script folder
7862016-07-14T20:02:31  <sipa> jtimon: ok, so there may be a 3rd repo/library with just data structured and serialization
7872016-07-14T20:02:32  *** spudowiar has quit IRC
7882016-07-14T20:02:42  <wumpus> gmaxwell: I proposed an API there; didn't write tests yet as I was just interested if that was what people had in mind, but discussion never really got started
7892016-07-14T20:02:53  <maaku> i would very much like a libbitcoinserialization for other purposes
7902016-07-14T20:02:53  <sipa> wumpus: agree, i forgot there was a pull
7912016-07-14T20:03:06  <wumpus> then people complain 'there are no tests'... well duh
7922016-07-14T20:03:06  <maaku> (there's a lot of api changes to get there though)
7932016-07-14T20:03:07  <jtimon> sipa: oh, I see we would separate some tools like prevector and serialization into a library that libconsensus would depend on?
7942016-07-14T20:03:12  <petertodd> maaku: being in the same directory makes it very easy to tell people "here's the consensus code, read it" - took me personally awhile to figure out what was an wasn't consensus. Equally, once it gets split into a separate repo, that's basically mandatory.
7952016-07-14T20:03:17  <jtimon> that would work
7962016-07-14T20:03:17  <instagibbs> "No shit" - wumpus 2016
7972016-07-14T20:03:28  <petertodd> instagibbs: ...for president!
7982016-07-14T20:03:30  * petertodd ducks
7992016-07-14T20:03:31  <instagibbs> i lol'd
8002016-07-14T20:03:57  *** maaku has left #bitcoin-core-dev
8012016-07-14T20:04:11  <petertodd> maaku: fwiw, I already do that kind of separation in python-bitcoinlib, with everything consensus under bitcoin.core
8022016-07-14T20:04:20  <bsm117532> wumpus: FWIW I'm working on a commercial product that will include a bitcoin full node.  It needs to fund transactions for many users, so the "label" idea sounds appropriate.  But, I'll mostly be querying txids.  (Which is one reason I've been working on getting segwit into python-bitcoinlib)
8032016-07-14T20:04:43  *** Frederic94500 has quit IRC
8042016-07-14T20:05:10  <btcdrak> I'm going to talk with belcher about accounts see what his plans are
8052016-07-14T20:05:17  <petertodd> wumpus: oh, re: joinmarket, I should point out that it uses accounts with watch-only addresses, which isn't the usual accounts usecase that we're concerned about...
8062016-07-14T20:05:28  <wumpus> bsm117532: right - the label functionality is the minimum functionality in that regard that we need to keep, it removes the bookkeeping stuff, but still allows grouping addresses under a name
8072016-07-14T20:05:49  <gmaxwell> which, IMO, is the only sensible thing accounts actually does in any case.
8082016-07-14T20:05:55  <bsm117532> That's what I gather, looks good.  I'll test it.
8092016-07-14T20:06:05  <btcdrak> petertodd: maybe they should use my addrindex patch.
8102016-07-14T20:06:07  <petertodd> wumpus: yeah, I'll bet you joinmarket would be fine with just labeling functionality - I doubt it ever uses the bookkeeping of accounts
8112016-07-14T20:06:14  <jtimon> so it seems the consensus folder thing is not clear, see? not that hard to say no fast, closing #8328 and taking the renames out of https://github.com/jtimon/bitcoin/commits/0.12.99-consensus (and #8329 and #8337 )
8122016-07-14T20:06:24  <wumpus> petertodd: oh good, in that case there is no problem at all
8132016-07-14T20:06:27  <gmaxwell> does account bookkeeping even do anything with watch addresses?
8142016-07-14T20:06:48  <jtimon> btw, I'm sure you guys could find things that you don't like in that branch already, please to leave it all for the refactor week
8152016-07-14T20:06:53  <bsm117532> Hmmm I would need watchonly addresses attached to my labels.
8162016-07-14T20:07:12  <petertodd> btcdrak: only as an option - way more convenient to not have to keep those huge indexes unless you really have too, and joinmarket (should) work just fine with a pruned node (haven't tested that myself yet)
8172016-07-14T20:07:14  *** frankenmint has joined #bitcoin-core-dev
8182016-07-14T20:07:51  *** afk11 has quit IRC
8192016-07-14T20:07:52  <petertodd> wumpus: yeah, I may be wrong, but it's probably not a major fix if there even is a problem - sorry for the false alarm!
8202016-07-14T20:09:38  <wumpus> petertodd: yes, joinmarket works with a pruned node
8212016-07-14T20:10:32  <gmaxwell> I think joinmarket really wants multiwallet support in any case, what it wants is a watching wallet to track relevant JM transactions...
8222016-07-14T20:10:32  <jtimon> what about using utilmoneystr in libconsensus or not? maaku and I are in disagreement here
8232016-07-14T20:10:38  <jtimon> oh, damm, he left
8242016-07-14T20:11:00  <sipa> jtimon: i say get rid of that formatting
8252016-07-14T20:11:04  <sipa> it's debug output
8262016-07-14T20:11:17  <gmaxwell> anything with "str" doesn't sound like it belongs in consensus code. :P
8272016-07-14T20:11:24  <sipa> in the long term, concensus logic should not do error formatting
8282016-07-14T20:11:51  <petertodd> gmaxwell: we need a semi-consensus library for stuff like that :)
8292016-07-14T20:12:22  <petertodd> gmaxwell: maybe, like dante's rings of hell...
8302016-07-14T20:12:25  <jtimon> yeah, me too, but he says showing satoshis would be breaking CAmount's encapsulation by treating it as an integer. I mean, I would be happy with not printing the values at all, but I guess that's worse
8312016-07-14T20:12:48  *** frankenmint has quit IRC
8322016-07-14T20:12:59  <jtimon> gmaxwell: well, I wasn't planning on removing tinyformat, at least not yet, but this is one line
8332016-07-14T20:13:22  <jtimon> this line: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1959
8342016-07-14T20:13:24  *** afk11 has joined #bitcoin-core-dev
8352016-07-14T20:13:24  *** afk11 has quit IRC
8362016-07-14T20:13:24  *** afk11 has joined #bitcoin-core-dev
8372016-07-14T20:14:00  <jtimon> well, not that one actually, L1961
8382016-07-14T20:14:53  <jtimon> is there a date for the 0.13 fork?
8392016-07-14T20:16:09  <jtimon> wumpus: or estimation?
8402016-07-14T20:16:28  <instagibbs> sipa, fwiw I think CB should be SW-ready for 0.13.1. Wasn't sure where people landed, but I would consider shipping without a bug...
8412016-07-14T20:16:56  <instagibbs> *if 0.12.2 is dropped
8422016-07-14T20:25:52  *** Chris_Stewart_5 has quit IRC
8432016-07-14T20:29:17  *** spudowiar has joined #bitcoin-core-dev
8442016-07-14T20:32:32  *** adamg has joined #bitcoin-core-dev
8452016-07-14T20:33:39  *** yep has quit IRC
8462016-07-14T20:33:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8472016-07-14T20:39:33  <gmaxwell> instagibbs: I agree. sipa's implementation also seemed to be working pretty well on testnet.
8482016-07-14T20:40:09  *** fengling_ has joined #bitcoin-core-dev
8492016-07-14T20:42:48  *** ArthurNumbanumba has quit IRC
8502016-07-14T20:45:06  *** fengling_ has quit IRC
8512016-07-14T20:47:52  *** MarcoFalke has left #bitcoin-core-dev
8522016-07-14T20:55:11  <GitHub177> [bitcoin] jtimon closed pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
8532016-07-14T21:02:02  *** Chris_Stewart_5 has quit IRC
8542016-07-14T21:17:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
8552016-07-14T21:23:36  *** ArthurNumbanumba has joined #bitcoin-core-dev
8562016-07-14T21:24:28  *** frankenmint has joined #bitcoin-core-dev
8572016-07-14T21:31:09  *** jannes has quit IRC
8582016-07-14T21:31:11  *** achow101 has quit IRC
8592016-07-14T21:33:12  *** TomMc has quit IRC
8602016-07-14T21:33:26  <jtimon> updated #8329 without  #8328
8612016-07-14T21:33:37  <jtimon> moveonly, one commit
8622016-07-14T21:41:41  *** fengling_ has joined #bitcoin-core-dev
8632016-07-14T21:42:43  *** achow101 has joined #bitcoin-core-dev
8642016-07-14T21:46:26  *** fengling_ has quit IRC
8652016-07-14T21:47:34  *** TomMc has joined #bitcoin-core-dev
8662016-07-14T21:51:04  *** afk11 has quit IRC
8672016-07-14T21:53:25  *** delinquentme has quit IRC
8682016-07-14T21:57:41  *** afk11 has joined #bitcoin-core-dev
8692016-07-14T21:57:41  *** afk11 has quit IRC
8702016-07-14T21:57:41  *** afk11 has joined #bitcoin-core-dev
8712016-07-14T22:02:22  *** spudowiar has quit IRC
8722016-07-14T22:17:24  *** TomMc has quit IRC
8732016-07-14T22:24:58  *** Samdney has joined #bitcoin-core-dev
8742016-07-14T22:27:09  *** gabridome1 has joined #bitcoin-core-dev
8752016-07-14T22:28:22  *** d_t has joined #bitcoin-core-dev
8762016-07-14T22:28:43  *** gabridome2 has joined #bitcoin-core-dev
8772016-07-14T22:28:56  *** gabridome has quit IRC
8782016-07-14T22:31:24  *** gabridome1 has quit IRC
8792016-07-14T22:32:03  *** d_t has quit IRC
8802016-07-14T22:32:09  *** gabridome has joined #bitcoin-core-dev
8812016-07-14T22:34:54  *** gabridome2 has quit IRC
8822016-07-14T22:43:09  *** fengling_ has joined #bitcoin-core-dev
8832016-07-14T22:47:46  *** fengling_ has quit IRC
8842016-07-14T22:52:40  <BlueMatt> <denisx> the only thing I needed to change for building on freebsd was the DEFINE of FREEBSD
8852016-07-14T22:52:45  <BlueMatt> <denisx> it was FREEBSD10.3 but it should only be FREEBSD
8862016-07-14T22:52:51  <BlueMatt> cfields: know whats up with that?
8872016-07-14T22:54:24  *** Guyver2 has quit IRC
8882016-07-14T22:55:10  *** ArthurNumbanumba has quit IRC
8892016-07-14T22:56:21  *** BitcoinErrorLog has joined #bitcoin-core-dev
8902016-07-14T23:03:46  *** laurentmt has joined #bitcoin-core-dev
8912016-07-14T23:04:32  *** laurentmt has quit IRC
8922016-07-14T23:08:51  *** ArthurNumbanumba has joined #bitcoin-core-dev
8932016-07-14T23:38:34  *** delinquentme has joined #bitcoin-core-dev
8942016-07-14T23:44:10  *** fengling_ has joined #bitcoin-core-dev
8952016-07-14T23:49:06  *** fengling_ has quit IRC
8962016-07-14T23:53:07  *** LeMiner2 has joined #bitcoin-core-dev
8972016-07-14T23:55:40  *** LeMiner has quit IRC
8982016-07-14T23:55:40  *** LeMiner2 is now known as LeMiner