1 2016-07-14T00:00:09  *** fengling_ has joined #bitcoin-core-dev
  2 2016-07-14T00:05:06  *** fengling_ has quit IRC
  3 2016-07-14T00:25:36  <cfields> sipa: https://github.com/theuni/bitcoin/commits/copy-move
  4 2016-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)
  5 2016-07-14T00:28:13  <cfields> ofc those are suspiciously high. curious to see if others get anywhere near the same numbers
  6 2016-07-14T00:28:28  *** spudowiar has quit IRC
  7 2016-07-14T00:29:37  <phantomcircuit> cfields: how did you benchmark that?
  8 2016-07-14T00:29:56  <cfields> phantomcircuit: benchmark is included
  9 2016-07-14T00:30:42  <phantomcircuit> oh that reminds me
 10 2016-07-14T00:30:48  <phantomcircuit> cfields, can you look at doing a fuzzing framework?
 11 2016-07-14T00:31:06  <phantomcircuit> literally just needs to be an executable that takes input on stdin
 12 2016-07-14T00:31:08  <cfields> phantomcircuit: i thought you were working on one?
 13 2016-07-14T00:31:22  <phantomcircuit> my modifications to the build process to do this didn't seem to work right consistently
 14 2016-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
 15 2016-07-14T00:31:48  <cfields> phantomcircuit: oh, you just need the build changes skeleton?
 16 2016-07-14T00:31:54  <phantomcircuit> yeah
 17 2016-07-14T00:32:03  <phantomcircuit> the fuzzing executable itself is pretty trivial
 18 2016-07-14T00:32:14  <phantomcircuit> and i suspect the build changes are trivial too but not for me :)
 19 2016-07-14T00:32:17  <cfields> phantomcircuit: sure, though, you should basically be able to copy Makefile.bench.include
 20 2016-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
 21 2016-07-14T00:34:14  <cfields> phantomcircuit: you're going to have to lay out exactly what you want. multiple executables gets more complicated
 22 2016-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
 23 2016-07-14T00:35:28  <phantomcircuit> i guess it could also be an executable with cli flags to select which test to run
 24 2016-07-14T00:36:22  <phantomcircuit> having them all be in a single executable isn't ideal for the fuzzer
 25 2016-07-14T00:36:30  <phantomcircuit> gmaxwell, ^ opinions?
 26 2016-07-14T00:36:59  <sipa> cfields: concept ack, i'll review in detail later
 27 2016-07-14T00:37:08  <sipa> on the copy/move
 28 2016-07-14T00:37:53  <cfields> sipa: thanks. if you'd prefer to make it class-safe, i can work on that instead
 29 2016-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
 30 2016-07-14T00:46:24  <sipa> cfields: i'm impressed by how much faster it id
 31 2016-07-14T00:46:29  <sipa> *it os
 32 2016-07-14T00:46:53  <sipa> ah, but that's move compared to the old placement new based approach?
 33 2016-07-14T00:46:53  <cfields> sipa: you reproduced? or going by my numbers?
 34 2016-07-14T00:47:01  <sipa> going by your numbers
 35 2016-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
 36 2016-07-14T00:49:30  <sipa> cfields: also, is the script/transaction move constructor/assignment actually invoked anywhere?
 37 2016-07-14T00:50:50  *** baldur has joined #bitcoin-core-dev
 38 2016-07-14T00:50:57  <cfields> sipa: unsure, but I suspect that there are plenty of places that pass in rvalues ala: myfunction(CScript())
 39 2016-07-14T00:52:03  <sipa> cfields: well, easy enough to create an explocit move constructor and putting a printf or gdb breakpoint in it
 40 2016-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.
 41 2016-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.
 42 2016-07-14T00:55:04  *** fengling_ has joined #bitcoin-core-dev
 43 2016-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
 44 2016-07-14T01:06:22  *** Chris_Stewart_5 has quit IRC
 45 2016-07-14T01:13:04  *** adamg has quit IRC
 46 2016-07-14T01:14:15  *** davec has quit IRC
 47 2016-07-14T01:15:47  *** Ylbam has quit IRC
 48 2016-07-14T01:19:04  *** shangzhou has quit IRC
 49 2016-07-14T01:19:32  *** Kexkey has joined #bitcoin-core-dev
 50 2016-07-14T01:19:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 51 2016-07-14T01:27:19  *** belcher has quit IRC
 52 2016-07-14T01:32:25  *** Kexkey has quit IRC
 53 2016-07-14T01:45:00  *** justanotheruser has quit IRC
 54 2016-07-14T01:47:22  *** justanotheruser has joined #bitcoin-core-dev
 55 2016-07-14T01:48:33  *** Chris_Stewart_5 has quit IRC
 56 2016-07-14T01:55:30  *** Justinus has joined #bitcoin-core-dev
 57 2016-07-14T02:06:09  *** davec has joined #bitcoin-core-dev
 58 2016-07-14T02:26:13  *** frankenmint has joined #bitcoin-core-dev
 59 2016-07-14T02:30:31  *** frankenmint has quit IRC
 60 2016-07-14T02:45:55  *** xinxi has joined #bitcoin-core-dev
 61 2016-07-14T02:50:39  *** xinxi has quit IRC
 62 2016-07-14T03:28:03  *** luke-jr has joined #bitcoin-core-dev
 63 2016-07-14T03:48:48  *** afk11 has quit IRC
 64 2016-07-14T03:54:55  *** afk11 has joined #bitcoin-core-dev
 65 2016-07-14T03:54:55  *** afk11 has quit IRC
 66 2016-07-14T03:54:55  *** afk11 has joined #bitcoin-core-dev
 67 2016-07-14T04:44:03  *** d_t has joined #bitcoin-core-dev
 68 2016-07-14T04:46:08  *** kadoban has joined #bitcoin-core-dev
 69 2016-07-14T05:43:55  *** d_t has quit IRC
 70 2016-07-14T05:54:05  *** RoyceX has joined #bitcoin-core-dev
 71 2016-07-14T05:54:05  *** RoyceX has joined #bitcoin-core-dev
 72 2016-07-14T05:57:28  *** Cheeseo has quit IRC
 73 2016-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
 74 2016-07-14T06:17:47  <GitHub69> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4831a16223db...1bc9c8085f71
 75 2016-07-14T06:17:47  <GitHub69> bitcoin/master 252675e Pieter Wuille: Do not send witnesses in cmpctblock
 76 2016-07-14T06:17:48  <GitHub69> bitcoin/master 1bc9c80 Wladimir J. van der Laan: Merge #8271: [bugfix] Do not send witnesses in cmpctblock...
 77 2016-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
 78 2016-07-14T06:18:57  <GitHub15> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1bc9c8085f71...4324bd237c31
 79 2016-07-14T06:18:57  <GitHub15> bitcoin/master 36ae37a Bob McElrath: Rename CTxinWitness -> CTxInWitness
 80 2016-07-14T06:18:58  <GitHub15> bitcoin/master 4324bd2 Wladimir J. van der Laan: Merge #8311: Rename CTxinWitness -> CTxInWitness...
 81 2016-07-14T06:19:06  <GitHub181> [bitcoin] laanwj closed pull request #8311: Rename CTxinWitness -> CTxInWitness (master...CTxInWitness) https://github.com/bitcoin/bitcoin/pull/8311
 82 2016-07-14T06:21:33  <GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4324bd237c31...ca40ef6029c1
 83 2016-07-14T06:21:34  <GitHub56> bitcoin/master bb66a11 Suhas Daftuar: Fix DoS vulnerability in mempool acceptance...
 84 2016-07-14T06:21:34  <GitHub56> bitcoin/master 46c9620 Suhas Daftuar: Test that unnecessary witnesses can't be used for mempool DoS...
 85 2016-07-14T06:21:35  <GitHub56> bitcoin/master ca40ef6 Wladimir J. van der Laan: Merge #8312: Fix mempool DoS vulnerability from malleated transactions...
 86 2016-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
 87 2016-07-14T06:33:47  *** xinxi has joined #bitcoin-core-dev
 88 2016-07-14T06:47:45  *** paveljanik has joined #bitcoin-core-dev
 89 2016-07-14T07:00:12  *** arubi has quit IRC
 90 2016-07-14T07:00:24  <xinxi> sipa: are you there?
 91 2016-07-14T07:06:16  *** arubi has joined #bitcoin-core-dev
 92 2016-07-14T07:22:05  *** xinxi has quit IRC
 93 2016-07-14T07:22:55  *** xinxi has joined #bitcoin-core-dev
 94 2016-07-14T08:00:00  *** frankenmint has joined #bitcoin-core-dev
 95 2016-07-14T08:06:54  *** face has joined #bitcoin-core-dev
 96 2016-07-14T08:08:55  *** jannes has joined #bitcoin-core-dev
 97 2016-07-14T08:09:23  *** MarcoFalke has joined #bitcoin-core-dev
 98 2016-07-14T08:14:37  *** moli has quit IRC
 99 2016-07-14T08:19:02  *** face has quit IRC
100 2016-07-14T08:21:55  *** Guyver2 has joined #bitcoin-core-dev
101 2016-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
102 2016-07-14T08:59:07  <GitHub128> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ca40ef6029c1...af9b7a9f2f73
103 2016-07-14T08:59:07  <GitHub128> bitcoin/master 66668c4 MarcoFalke: [qa] Solve merge conflict of 4324bd237c3147fc153ba5046c211f03e8ac956a
104 2016-07-14T08:59:08  <GitHub128> bitcoin/master af9b7a9 MarcoFalke: Merge #8340: [qa] Solve trivial merge conflict in p2p-segwit.py...
105 2016-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
106 2016-07-14T09:02:19  *** MarcoFalke has left #bitcoin-core-dev
107 2016-07-14T09:38:20  <GitHub179> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/af9b7a9f2f73...bc94b8748782
108 2016-07-14T09:38:20  <GitHub179> bitcoin/master b993671 Jonas Schnelli: [Wallet] keep HD seed during salvagewallet
109 2016-07-14T09:38:21  <GitHub179> bitcoin/master bc94b87 Wladimir J. van der Laan: Merge #8324: [Wallet] keep HD seed during salvagewallet...
110 2016-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
111 2016-07-14T09:47:57  *** arubi has quit IRC
112 2016-07-14T09:48:12  *** arubi has joined #bitcoin-core-dev
113 2016-07-14T09:53:57  *** arubi has quit IRC
114 2016-07-14T09:54:12  *** arubi has joined #bitcoin-core-dev
115 2016-07-14T10:26:18  *** arubi has quit IRC
116 2016-07-14T10:26:28  *** arubi has joined #bitcoin-core-dev
117 2016-07-14T10:30:06  *** fengling_ has quit IRC
118 2016-07-14T10:33:34  *** moli has joined #bitcoin-core-dev
119 2016-07-14T10:42:55  *** frankenmint has quit IRC
120 2016-07-14T10:48:01  *** Ylbam has joined #bitcoin-core-dev
121 2016-07-14T11:02:27  *** chris200_ has joined #bitcoin-core-dev
122 2016-07-14T11:06:12  *** Sosumi has joined #bitcoin-core-dev
123 2016-07-14T11:12:52  *** mkarrer has quit IRC
124 2016-07-14T11:14:59  *** chris200_ has quit IRC
125 2016-07-14T11:15:58  *** frankenmint has joined #bitcoin-core-dev
126 2016-07-14T11:24:01  *** jtimon has joined #bitcoin-core-dev
127 2016-07-14T11:24:04  *** arubi has quit IRC
128 2016-07-14T11:24:16  *** arubi has joined #bitcoin-core-dev
129 2016-07-14T11:25:30  *** frankenmint has quit IRC
130 2016-07-14T11:26:27  *** fengling_ has joined #bitcoin-core-dev
131 2016-07-14T11:31:26  *** fengling_ has quit IRC
132 2016-07-14T11:33:52  *** laurentmt has joined #bitcoin-core-dev
133 2016-07-14T11:34:06  *** laurentmt has quit IRC
134 2016-07-14T12:02:35  *** frankenmint has joined #bitcoin-core-dev
135 2016-07-14T12:14:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
136 2016-07-14T12:16:39  *** Chris_Stewart_5 has quit IRC
137 2016-07-14T12:28:02  *** fengling_ has joined #bitcoin-core-dev
138 2016-07-14T12:32:46  *** fengling_ has quit IRC
139 2016-07-14T12:41:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
140 2016-07-14T12:46:43  *** Chris_Stewart_5 has quit IRC
141 2016-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
142 2016-07-14T13:00:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
143 2016-07-14T13:07:03  *** knightdk has joined #bitcoin-core-dev
144 2016-07-14T13:11:30  *** Chris_Stewart_5 has quit IRC
145 2016-07-14T13:11:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
146 2016-07-14T13:12:27  *** laurentmt has joined #bitcoin-core-dev
147 2016-07-14T13:23:25  <jtimon> jonasschnelli: what do you think I should do with the consensus PRs ?
148 2016-07-14T13:23:48  <jonasschnelli> jtimon: I think you should do one small step after another...
149 2016-07-14T13:24:03  <jtimon> those are 3 small steps one after the other
150 2016-07-14T13:24:25  <jonasschnelli> But they do include the same commits.
151 2016-07-14T13:24:35  <jtimon> imagine someone reviewed more than 2 of those little steps
152 2016-07-14T13:24:37  <jonasschnelli> I think you should open only one PR ...
153 2016-07-14T13:24:48  <jtimon> yeah, that's the "one after the other" part
154 2016-07-14T13:25:09  <jonasschnelli> IMO the past has shown that we have not enough reviwers for the consensus parts..
155 2016-07-14T13:25:20  <jonasschnelli> This is why I think one PR at the time would be more efficient.
156 2016-07-14T13:25:24  <sipa> i'm fine with the pure move consensus code PRs, after 0.13 branches off
157 2016-07-14T13:25:30  <jtimon> jonasschnelli : so we should just give up?
158 2016-07-14T13:25:37  <jonasschnelli> jtimon: no... sure not!
159 2016-07-14T13:25:48  <sipa> for everything else (encapsulation, API)... *please* first document first
160 2016-07-14T13:26:04  <jonasschnelli> I just think you will have more reviwers if there are clear distortable/small PRs
161 2016-07-14T13:26:27  *** mkarrer has joined #bitcoin-core-dev
162 2016-07-14T13:26:40  <jonasschnelli> jtimon: to have that said: I'm a big fan of the consensus encapsulation and I appreciate your work!
163 2016-07-14T13:26:54  <jonasschnelli> I just try to optimize the workflow on that part
164 2016-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
165 2016-07-14T13:28:03  <sipa> same goes for NicolasDorier by the way
166 2016-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
167 2016-07-14T13:28:30  <jonasschnelli> jtimon: I just think you will have more reviewers if you just focus on one PR
168 2016-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
169 2016-07-14T13:29:04  <sipa> jtimon: that's all fine
170 2016-07-14T13:29:19  <jtimon> in https://github.com/jtimon/bitcoin/commits/0.12.99-consensus there are big architectural changes though
171 2016-07-14T13:29:26  <sipa> jtimon: sorry, i think i've developed selective blindness for any PRs that mention consensus refactors
172 2016-07-14T13:29:28  *** fengling_ has joined #bitcoin-core-dev
173 2016-07-14T13:29:40  <jtimon> sipa: I could easily believe that
174 2016-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
175 2016-07-14T13:31:42  <sipa> jonasschnelli: sorry, i need to read up on HKDF first
176 2016-07-14T13:31:57  <jonasschnelli> sipa: sure: https://tools.ietf.org/html/rfc5869
177 2016-07-14T13:32:26  <jonasschnelli> openssl impl: https://github.com/openssl/openssl/blob/master/crypto/kdf/hkdf.c
178 2016-07-14T13:33:23  *** anchow101 has joined #bitcoin-core-dev
179 2016-07-14T13:34:20  *** knightdk has left #bitcoin-core-dev
180 2016-07-14T13:34:26  *** fengling_ has quit IRC
181 2016-07-14T13:34:45  *** anchow101 has quit IRC
182 2016-07-14T13:37:19  *** achow101 has quit IRC
183 2016-07-14T13:37:38  *** achow101 has joined #bitcoin-core-dev
184 2016-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 :)
185 2016-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
186 2016-07-14T13:41:17  *** Frederic94500 has joined #bitcoin-core-dev
187 2016-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
188 2016-07-14T13:42:40  *** Chris_St1 has joined #bitcoin-core-dev
189 2016-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
190 2016-07-14T13:43:04  <paveljanik> jtimon, just nACK them...
191 2016-07-14T13:43:18  <sipa> jtimon: it's not always obvious
192 2016-07-14T13:44:04  <sipa> jtimon: should prevector be in consensus, for example?
193 2016-07-14T13:44:33  <sipa> consensus logic depends on it, but it's implementing a standard interface, and is more generically useful
194 2016-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
195 2016-07-14T13:45:21  *** Chris_Stewart_5 has quit IRC
196 2016-07-14T13:45:25  *** TomMc has joined #bitcoin-core-dev
197 2016-07-14T13:45:38  <jtimon> prevector is a dependency of uint256, no?
198 2016-07-14T13:45:42  <sipa> no
199 2016-07-14T13:45:54  <sipa> it is of CScript
200 2016-07-14T13:46:00  <jtimon> oh, yeah
201 2016-07-14T13:46:20  <sipa> but even that... i'm not sure CScript storage in the long term belongs in consensus
202 2016-07-14T13:46:35  <jtimon> I mean, prevector is currently needed in libconsensus for verifyScript
203 2016-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?
204 2016-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...
205 2016-07-14T13:47:45  <sipa> i'm just trying to understand your view
206 2016-07-14T13:48:00  <sipa> i think you've thought this true, and have a good picture in your head of what belongs where
207 2016-07-14T13:48:03  <sipa> but it's not obvious to me
208 2016-07-14T13:48:31  <sipa> should everything that libconsensus depends on be in the consensus/ directory?
209 2016-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)
210 2016-07-14T13:49:20  <sipa> jtimon: so script/script.h, script/interpreter, primitives/*, ... move to consensus?
211 2016-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...)
212 2016-07-14T13:50:52  <sipa> i
213 2016-07-14T13:50:53  <sipa> i
214 2016-07-14T13:50:56  <sipa> grrr!
215 2016-07-14T13:51:03  <sipa> i'm not really talking about current PRs
216 2016-07-14T13:51:10  <sipa> just about what you believe belongs where
217 2016-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...
218 2016-07-14T13:51:58  <sipa> jtimon: i am not talking about your current PRs...
219 2016-07-14T13:52:07  <jtimon> everything that's going to be needed for a complete libconsensus exposing verifyblock
220 2016-07-14T13:52:14  <sipa> ok, thank you
221 2016-07-14T13:52:21  <jtimon> sipa: that's fine, but there's a list right there
222 2016-07-14T13:52:21  <sipa> does that include primitives?
223 2016-07-14T13:52:39  <jtimon> yes, of course
224 2016-07-14T13:52:53  <sipa> ok
225 2016-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
226 2016-07-14T13:53:33  <sipa> the wallet would still depend on the primitives inside the consensus directory?
227 2016-07-14T13:53:38  <jtimon> in fact I forgot sigache in that PR, that will be needed too I guess
228 2016-07-14T13:54:10  *** arubi has quit IRC
229 2016-07-14T13:54:23  *** arubi has joined #bitcoin-core-dev
230 2016-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
231 2016-07-14T13:55:34  <sipa> fair enough
232 2016-07-14T13:55:44  <jtimon> first step is completing libconsensus while allowing bitcoin core to keep using its internals
233 2016-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
234 2016-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
235 2016-07-14T13:56:49  *** frankenmint has quit IRC
236 2016-07-14T13:56:50  <sipa> sure
237 2016-07-14T13:56:54  *** Chris_St1 has quit IRC
238 2016-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)
239 2016-07-14T13:57:51  *** YOU-JI has joined #bitcoin-core-dev
240 2016-07-14T13:57:52  *** ebfull has quit IRC
241 2016-07-14T13:59:48  <jtimon> I mean, the lowest layer is really the crypto dir and libsecp
242 2016-07-14T14:00:00  <sipa> do those also move to consensus/ ?
243 2016-07-14T14:00:08  <sipa> not all of crypto/ is needed in consensus
244 2016-07-14T14:00:31  <jtimon> only one hash function wasn't last time I checked IIRC
245 2016-07-14T14:00:48  <jtimon> but well, they're in the crypto dir already so...
246 2016-07-14T14:01:00  <sipa> hmac, rfc6979, aes, sha512
247 2016-07-14T14:01:06  <sipa> those are not needed in consensus
248 2016-07-14T14:01:14  <jtimon> the whole folder is currently being built for libconsensus
249 2016-07-14T14:01:22  <sipa> i'm aware
250 2016-07-14T14:01:31  <sipa> (but i'm not sure that's a good thing)
251 2016-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
252 2016-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
253 2016-07-14T14:04:53  <jtimon> it's only touching the makefile anyway
254 2016-07-14T14:05:00  <sipa> well, we'd be breaking apart script/ too
255 2016-07-14T14:05:38  <jtimon> well, yeah, script is already being built in different packages
256 2016-07-14T14:06:02  <jtimon> some are not consensus code like sign and standard
257 2016-07-14T14:06:08  <sipa> indeed
258 2016-07-14T14:06:58  <jtimon> what do you think about utilmoneystr ?
259 2016-07-14T14:07:17  *** YOU-JI has quit IRC
260 2016-07-14T14:07:29  <sipa> i don't think string conversions belong in consensus
261 2016-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
262 2016-07-14T14:08:32  <jtimon> maaku was against leaving it out
263 2016-07-14T14:08:50  <jtimon> but we could just print satoshis
264 2016-07-14T14:09:39  <sipa> ideally consensus logic doesn't need to contain any error strings
265 2016-07-14T14:10:15  <sipa> but the alternative is defining huge enums of error constants
266 2016-07-14T14:17:09  <jtimon> I'm fine with having tinyformat for now, it's tiny, it says so in the name
267 2016-07-14T14:17:54  <jtimon> but yeah, I guess the enum is what errorScript was about
268 2016-07-14T14:20:38  *** Chris_St1 has joined #bitcoin-core-dev
269 2016-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 :)
270 2016-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
271 2016-07-14T14:27:31  <cfields> moves don't happen much in the current code (but will later), but lots of copies.
272 2016-07-14T14:28:02  <jeremyrubin> yeah will profile it later today
273 2016-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.
274 2016-07-14T14:30:58  *** fengling_ has joined #bitcoin-core-dev
275 2016-07-14T14:35:46  *** fengling_ has quit IRC
276 2016-07-14T14:37:58  *** Chris_St1 has quit IRC
277 2016-07-14T14:40:13  *** Chris_St1 has joined #bitcoin-core-dev
278 2016-07-14T14:51:46  *** cool_guy has joined #bitcoin-core-dev
279 2016-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!
280 2016-07-14T14:52:41  *** ChanServ sets mode: +o sipa
281 2016-07-14T14:52:46  *** sipa sets mode: +b *!*coolguy@*.hsd1.il.comcast.net
282 2016-07-14T14:52:46  *** cool_guy was kicked by sipa (cool_guy)
283 2016-07-14T14:58:12  *** laurentmt has quit IRC
284 2016-07-14T15:02:02  *** d_t has joined #bitcoin-core-dev
285 2016-07-14T15:03:15  *** d_t has quit IRC
286 2016-07-14T15:03:29  *** d_t has joined #bitcoin-core-dev
287 2016-07-14T15:04:45  *** d_t has quit IRC
288 2016-07-14T15:05:10  *** xinxi has quit IRC
289 2016-07-14T15:05:37  *** xinxi has joined #bitcoin-core-dev
290 2016-07-14T15:20:12  <morcos> cfields: i couldn't get your copy-move branch to compile.
291 2016-07-14T15:20:34  <morcos> ./prevector.h:253:23: error: 'is_trivially_copyable' is not a member of 'std'
292 2016-07-14T15:21:24  *** Chris_St1 has quit IRC
293 2016-07-14T15:21:45  *** zooko has joined #bitcoin-core-dev
294 2016-07-14T15:23:38  <jeremyrubin> morcos: upgrade your compiler http://stackoverflow.com/questions/25123458/is-trivially-copyable-is-not-a-member-of-std
295 2016-07-14T15:23:49  <jeremyrubin> cfields: maybe add these ifdef's for compat
296 2016-07-14T15:32:33  *** fengling_ has joined #bitcoin-core-dev
297 2016-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>
298 2016-07-14T15:37:03  *** Chris_St1 has joined #bitcoin-core-dev
299 2016-07-14T15:37:10  <cfields> morcos: i'll try to find a trait implemented earlier
300 2016-07-14T15:37:26  *** fengling_ has quit IRC
301 2016-07-14T15:42:15  *** Chris_St1 has quit IRC
302 2016-07-14T15:54:03  <cfields> looks like std::is_pod should work, need to double-check its guarantees though
303 2016-07-14T15:57:53  <sipa> when i want information about some standard library function, i usually just type it into my url bar
304 2016-07-14T15:57:57  *** sipa sets mode: -o sipa
305 2016-07-14T15:58:13  <sipa> unfortunately, the browser interprets std:: as an address scheme
306 2016-07-14T15:59:37  *** Chris_St1 has joined #bitcoin-core-dev
307 2016-07-14T16:01:40  *** xinxi has quit IRC
308 2016-07-14T16:02:22  *** xinxi has joined #bitcoin-core-dev
309 2016-07-14T16:03:37  <cfields> heh
310 2016-07-14T16:05:34  *** Chris_St1 has quit IRC
311 2016-07-14T16:15:40  *** d_t has joined #bitcoin-core-dev
312 2016-07-14T16:16:15  *** d_t has joined #bitcoin-core-dev
313 2016-07-14T16:21:35  *** Chris_St1 has joined #bitcoin-core-dev
314 2016-07-14T16:24:07  *** Arnavion has quit IRC
315 2016-07-14T16:25:45  *** Arnavion has joined #bitcoin-core-dev
316 2016-07-14T16:28:34  *** Arnavion has quit IRC
317 2016-07-14T16:32:49  *** Arnavion has joined #bitcoin-core-dev
318 2016-07-14T16:34:06  *** fengling_ has joined #bitcoin-core-dev
319 2016-07-14T16:38:46  *** fengling_ has quit IRC
320 2016-07-14T16:39:13  <wumpus> putting " around it usually helps
321 2016-07-14T16:42:39  *** Chris_St1 has quit IRC
322 2016-07-14T16:47:06  *** Chris_St1 has joined #bitcoin-core-dev
323 2016-07-14T16:54:28  *** zooko has quit IRC
324 2016-07-14T16:57:40  *** zooko has joined #bitcoin-core-dev
325 2016-07-14T17:20:41  *** MarcoFalke has joined #bitcoin-core-dev
326 2016-07-14T17:21:16  *** harrymm has joined #bitcoin-core-dev
327 2016-07-14T17:21:27  *** molz has joined #bitcoin-core-dev
328 2016-07-14T17:23:06  *** [b__b] has quit IRC
329 2016-07-14T17:23:12  *** moli has quit IRC
330 2016-07-14T17:25:01  *** [b__b] has joined #bitcoin-core-dev
331 2016-07-14T17:30:23  *** Chris_St1 has quit IRC
332 2016-07-14T17:30:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
333 2016-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?
334 2016-07-14T17:33:58  <sipa> the placement of codeseparators influences what is passed as scriptCode to signaturehash
335 2016-07-14T17:35:00  <sipa> note that codeseparators are assumed to be useless in their current form
336 2016-07-14T17:35:27  <bsm2357> Heh
337 2016-07-14T17:35:32  *** Chris_Stewart_5 has quit IRC
338 2016-07-14T17:35:39  *** fengling_ has joined #bitcoin-core-dev
339 2016-07-14T17:35:39  <bsm2357> Ok then client code.  (I'm copying test cases from BIP143)
340 2016-07-14T17:36:26  <sipa> but you should already be doing that
341 2016-07-14T17:36:49  <sipa> bip143 does not affect the behaviour of code separators
342 2016-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.
343 2016-07-14T17:39:12  *** [b__b] has quit IRC
344 2016-07-14T17:40:26  *** fengling_ has quit IRC
345 2016-07-14T17:42:35  <kanzure> SignatureHash isn't so bad
346 2016-07-14T17:42:47  <kanzure> (besides the strange name; i appreciate jl2012's signature digest algorithm name idea)
347 2016-07-14T17:44:05  *** [b__b] has joined #bitcoin-core-dev
348 2016-07-14T17:44:56  *** delinquentme has joined #bitcoin-core-dev
349 2016-07-14T17:50:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
350 2016-07-14T17:53:23  *** [b__b] has quit IRC
351 2016-07-14T17:59:37  *** [b__b] has joined #bitcoin-core-dev
352 2016-07-14T18:09:05  <jtimon> meeting is now or in an hour?
353 2016-07-14T18:11:23  <eragmus> jtimon: 49 min.
354 2016-07-14T18:12:00  <jtimon> eragmus: yeah, thanks, it definitely didn't look like it was now ;)
355 2016-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?
356 2016-07-14T18:15:42  <sipa> morcos: i always assumed the inexpensive checks are actually not expensive
357 2016-07-14T18:15:52  <sipa> only fetching of the inputs is
358 2016-07-14T18:15:55  <sipa> am i wrong
359 2016-07-14T18:15:57  <sipa> ?
360 2016-07-14T18:16:29  <morcos> sipa: i'm about to try to separately bench UpdateCoins
361 2016-07-14T18:16:41  <morcos> but do you think the fetching is expensive if we are caching well?
362 2016-07-14T18:16:46  *** jtimon has quit IRC
363 2016-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
364 2016-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
365 2016-07-14T18:19:11  *** [b__b] has quit IRC
366 2016-07-14T18:24:10  *** molz has quit IRC
367 2016-07-14T18:26:39  *** moli has joined #bitcoin-core-dev
368 2016-07-14T18:27:24  *** [b__b] has joined #bitcoin-core-dev
369 2016-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.
370 2016-07-14T18:32:42  *** [b__b] has quit IRC
371 2016-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.
372 2016-07-14T18:35:39  *** [b__b] has joined #bitcoin-core-dev
373 2016-07-14T18:37:06  *** fengling_ has joined #bitcoin-core-dev
374 2016-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=
375 2016-07-14T18:37:52  <bsm2357> It's a P2WPKH so I'm confused, the script is implicit
376 2016-07-14T18:38:48  <sipa> bsm2357: make bitcoind print out the signaturehash it is checking
377 2016-07-14T18:38:56  <sipa> and compare that to the value you're signing
378 2016-07-14T18:39:27  <bsm2357> This may still be a bad sighash then?
379 2016-07-14T18:41:07  *** yep has joined #bitcoin-core-dev
380 2016-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
381 2016-07-14T18:41:38  <bsm2357> Ah nm, need to pass SIGVERSION_WITNESS_V0 to *use* the new SignatureHash...
382 2016-07-14T18:41:46  *** fengling_ has quit IRC
383 2016-07-14T18:42:00  <bsm2357> Thanks sdaftuar I've been reviewing that for days ;-)
384 2016-07-14T18:42:14  <sdaftuar> haha okay :)
385 2016-07-14T18:54:17  *** Chris_Stewart_5 has quit IRC
386 2016-07-14T18:55:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
387 2016-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.
388 2016-07-14T18:59:42  <wumpus> meeting time?
389 2016-07-14T18:59:45  <jl2012> bsm2357: there are some test vectors in BIP143
390 2016-07-14T19:00:04  <bsm2357> I know, I wrote tests for them!  They all pass.  :-P
391 2016-07-14T19:00:15  <bsm2357> Thanks for that ;-)
392 2016-07-14T19:00:40  <sipa> wumpus: ack
393 2016-07-14T19:00:52  <wumpus> #startmeeting
394 2016-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.
395 2016-07-14T19:00:52  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
396 2016-07-14T19:00:53  <instagibbs> actually here this time
397 2016-07-14T19:01:47  <cfields> gmaxwell: ping for pings :)
398 2016-07-14T19:01:48  <wumpus> gmaxwell jonasschnelli sdaftuar jtimon kanzure MarcoFalke
399 2016-07-14T19:01:57  <jonasschnelli> pong
400 2016-07-14T19:02:33  <wumpus> topic suggestions?
401 2016-07-14T19:02:40  *** gabridome has joined #bitcoin-core-dev
402 2016-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)
403 2016-07-14T19:02:42  <wumpus> (besides 0.13.0rc1)
404 2016-07-14T19:02:52  <instagibbs> segwit backport?
405 2016-07-14T19:02:58  <sipa> ack topic
406 2016-07-14T19:03:13  <wumpus> #topic 0.13.0rc1
407 2016-07-14T19:03:20  <wumpus> #link https://github.com/bitcoin/bitcoin/milestone/20
408 2016-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
409 2016-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
410 2016-07-14T19:03:48  <wumpus> most of the remaining PRs have been merged, but there are still a few open
411 2016-07-14T19:04:09  <jonasschnelli> I beg for reviews...
412 2016-07-14T19:04:13  <instagibbs> jonasschnelli, I can review
413 2016-07-14T19:04:24  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8305 Improve handling of unconnecting headers by sdaftuar
414 2016-07-14T19:04:44  <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8295 Mining-related fixups for 0.13.0 also by sdaftuar
415 2016-07-14T19:04:49  <wumpus> and jonasschnelli's
416 2016-07-14T19:05:04  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8323
417 2016-07-14T19:05:14  <instagibbs> #link https://github.com/bitcoin/bitcoin/pull/8323
418 2016-07-14T19:05:27  *** achow101 has left #bitcoin-core-dev
419 2016-07-14T19:05:37  *** achow101 has joined #bitcoin-core-dev
420 2016-07-14T19:05:38  <wumpus> I think #8305 is pretty much ready
421 2016-07-14T19:06:02  <wumpus> has ACK by sipa and is being tested by gmaxwell
422 2016-07-14T19:06:10  <sdaftuar> i think sipa acked an earlier version of the code
423 2016-07-14T19:06:12  <bsm2357> pong
424 2016-07-14T19:06:36  *** pmienk has quit IRC
425 2016-07-14T19:06:37  <instagibbs> jeremyrubin *ping*
426 2016-07-14T19:07:00  <wumpus> cfields: has your comment there been addressed sufficiently?
427 2016-07-14T19:07:19  <sdaftuar> oh, thanks sipa :)
428 2016-07-14T19:07:32  *** bsm2357 is now known as bsm117532
429 2016-07-14T19:07:51  <cfields> wumpus: yes, i'm happy with the slow DOS trickle
430 2016-07-14T19:08:04  <jeremyrubin> instagibbs: yes?
431 2016-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
432 2016-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
433 2016-07-14T19:09:27  <wumpus> jonasschnelli: #8323 still has some open comments
434 2016-07-14T19:09:40  <sipa> and the existing tests cover it
435 2016-07-14T19:09:41  <wumpus> trivial things though
436 2016-07-14T19:09:48  <MarcoFalke> no blockers
437 2016-07-14T19:09:56  *** d_t has quit IRC
438 2016-07-14T19:09:58  <jonasschnelli> Yes. paveljanik just added some... will fix the trivials together (once there are some)
439 2016-07-14T19:10:05  <morcos> sipa: are you referring to mining unit tests?
440 2016-07-14T19:10:10  <sipa> morcos: yes
441 2016-07-14T19:10:25  <sipa> (well, and any rpc test that mines)
442 2016-07-14T19:10:30  <morcos> sipa: those aren't worth much, they've been in need of redoing for some time
443 2016-07-14T19:10:43  <sipa> hmm, ok
444 2016-07-14T19:10:49  <wumpus> jonasschnelli: I'll also review and test it soon
445 2016-07-14T19:10:55  <jonasschnelli> thanks
446 2016-07-14T19:11:03  <morcos> not that i'm objecting to 8295 though
447 2016-07-14T19:11:07  <sipa> morcos: i'll test by running old and new in parallel and comparing then
448 2016-07-14T19:12:08  <wumpus> great
449 2016-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?
450 2016-07-14T19:13:29  <luke-jr> a quick glance at 8323 suggests it won't make problems with key origin stuff, rihgt?
451 2016-07-14T19:14:09  <wumpus> sdaftuar: any blockers remaining there?
452 2016-07-14T19:14:20  <wumpus> (after all currenly 0.13-tagged PRs are merged)
453 2016-07-14T19:14:34  *** jtimon has joined #bitcoin-core-dev
454 2016-07-14T19:14:35  <wumpus> luke-jr: let's discuss that outside the meeting please
455 2016-07-14T19:14:51  <luke-jr> ….
456 2016-07-14T19:14:57  <sdaftuar> wumpus: i was waiting for #8295 to be merged before doing the release notes writeups
457 2016-07-14T19:15:14  <sdaftuar> oh, should we talk about -blockmaxcost briefly?
458 2016-07-14T19:15:16  <wumpus> sdaftuar: oh release notes writeups aren't urgent, they need to be done for final but not rc1
459 2016-07-14T19:15:17  <luke-jr> (what's the point of a meeting if not to discuss the topics raised?)
460 2016-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 :)
461 2016-07-14T19:16:08  <sipa> sdaftuar: suggested replacement?
462 2016-07-14T19:16:25  <wumpus> yes, the 'max cost' confuses people, they think it's about monetary cost
463 2016-07-14T19:16:31  <petertodd> wumpus: +1
464 2016-07-14T19:16:33  <wumpus> (and that's also how translators translate it)
465 2016-07-14T19:16:40  <luke-jr> >_<
466 2016-07-14T19:16:50  <wumpus> (and it's a public command line option so the help gets translated)
467 2016-07-14T19:16:59  <sipa> we could have maxblockvsize instead
468 2016-07-14T19:16:59  <petertodd> blockmaxcost is still just a size limit isn't it?
469 2016-07-14T19:17:02  <gmaxwell> Cost has been a repeated source of confusion.
470 2016-07-14T19:17:02  <wumpus> but that means the help needs to be improved, not necessarily the option renamed
471 2016-07-14T19:17:03  <luke-jr> well, it *is* indirectly monetary
472 2016-07-14T19:17:17  <jeremyrubin> maybe utilization
473 2016-07-14T19:17:20  <sipa> petertodd: it's the 'cost' as defined in the BIP, which is vsize*4
474 2016-07-14T19:17:40  <gmaxwell> Score/points/weight/usage/ouchie/bitgo  would all be better words for it.
475 2016-07-14T19:17:42  <luke-jr> "network resource usage"?
476 2016-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
477 2016-07-14T19:17:43  <wumpus> it's an abstract cost, and CS students understand that, but for most users it's confusing :)
478 2016-07-14T19:18:01  <sipa> sdaftuar: yes, agree, let's makr it consistent, whatever we agree upon
479 2016-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
480 2016-07-14T19:18:17  *** pmienk has joined #bitcoin-core-dev
481 2016-07-14T19:18:23  <CodeShark> #agree
482 2016-07-14T19:18:24  <wumpus> block size validation cost would already be better help than there is now
483 2016-07-14T19:18:30  <luke-jr> petertodd: it's not a size.
484 2016-07-14T19:18:32  <petertodd> notably, if we had referred to block size in the BIP, that'd help discourage the trolls...
485 2016-07-14T19:18:33  <gmaxwell> "externality"
486 2016-07-14T19:18:44  <gmaxwell> luke-jr: it is a size, in cost-space.
487 2016-07-14T19:18:47  <sipa> well, any reason not use vsize?
488 2016-07-14T19:18:49  <petertodd> segwit *is* a blocksize increase, so just continue to call it a size
489 2016-07-14T19:18:53  <petertodd> sipa: vsize is fine
490 2016-07-14T19:19:00  <wumpus> yes vsize is fine
491 2016-07-14T19:19:09  <btcdrak>  yes
492 2016-07-14T19:19:10  <petertodd> sipa: (so long as the help text explains what vsize is)
493 2016-07-14T19:19:12  <luke-jr> vsize is inaccurate
494 2016-07-14T19:19:15  <gmaxwell> V means validation?
495 2016-07-14T19:19:21  <sipa> virtual
496 2016-07-14T19:19:24  <luke-jr> going to *4 the meaning, so people specify x.25 now?
497 2016-07-14T19:19:27  <sdaftuar> hm, we have been using vsize to refer to the scaled down value, not the *4 value?
498 2016-07-14T19:19:27  <btcdrak> v for vendetta
499 2016-07-14T19:19:28  <gmaxwell> ugh, there is nothing virtual about it.
500 2016-07-14T19:19:36  <petertodd> gmaxwell: +1
501 2016-07-14T19:19:38  <luke-jr> fractional values for consensus code?
502 2016-07-14T19:19:50  <petertodd> sdaftuar: that's a mistake then
503 2016-07-14T19:19:56  <sipa> sdaftuar: yes, cost == vsize * 4
504 2016-07-14T19:19:59  <gmaxwell> re fractional values, haven't we learned from difficulty?
505 2016-07-14T19:20:06  <sipa> vsize is cost, but scaled down for compatibility with old code
506 2016-07-14T19:20:15  <sipa> so they don't start sending 4x fees etc
507 2016-07-14T19:20:18  <gmaxwell> if we use fractional values for display friendlyness, other people will use them in consensus code and cause faults.
508 2016-07-14T19:20:35  * luke-jr grabs a thesaurus
509 2016-07-14T19:20:36  <gmaxwell> sipa: ::sigh:: point.
510 2016-07-14T19:20:37  <btcdrak> agreed
511 2016-07-14T19:20:46  <jeremyrubin> I like weight the best
512 2016-07-14T19:20:56  <wumpus> agree jeremyrubin
513 2016-07-14T19:20:59  <jeremyrubin> because usually you would say a weighted sum
514 2016-07-14T19:21:05  <sipa> jeremyrubin: nice idea
515 2016-07-14T19:21:07  <wumpus> weight is a pretty good term for it
516 2016-07-14T19:21:09  <CodeShark> #agree
517 2016-07-14T19:21:17  <btcdrak> good call
518 2016-07-14T19:21:21  <wumpus> and it's not used anywhere yet in bitcoin
519 2016-07-14T19:21:24  <jeremyrubin> (gmaxwell: mentioned first)
520 2016-07-14T19:21:33  <luke-jr> outlay? :/
521 2016-07-14T19:21:41  <luke-jr> weight sounds fine
522 2016-07-14T19:22:04  *** [b__b] has quit IRC
523 2016-07-14T19:22:30  <jtimon> yeah, there's two sizes with their weights, it's a cost heuristic
524 2016-07-14T19:22:40  <wumpus> so: rename blockmaxcost to blockmaxweight?
525 2016-07-14T19:22:43  <instagibbs> "weight" also carries a nice intuitive notion
526 2016-07-14T19:22:57  <sipa> yes, and let's report weight for transactions too
527 2016-07-14T19:22:57  <jeremyrubin> maxblockweightcostheuristic
528 2016-07-14T19:23:06  <gmaxwell> I read that as block mascot.
529 2016-07-14T19:23:18  <wumpus> hehe
530 2016-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
531 2016-07-14T19:23:21  <jeremyrubin> virtualmaxblockweightcostheuristic
532 2016-07-14T19:23:21  <jtimon> sorry, I missed the first 15 mins or so, but why do we need to rename blockmaxcost ?
533 2016-07-14T19:23:32  <luke-jr> petertodd: size is something else
534 2016-07-14T19:23:33  <gmaxwell> jtimon: because the word cost is confused as fee.
535 2016-07-14T19:24:02  <sdaftuar> i think "block weight" and -blockmaxweight [
536 2016-07-14T19:24:11  <sdaftuar> both work okay
537 2016-07-14T19:24:14  <btcdrak> ack
538 2016-07-14T19:24:17  *** gabridome1 has joined #bitcoin-core-dev
539 2016-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 :)
540 2016-07-14T19:24:35  <jtimon> mhmm, no, it's costs for the miners, although that's also why they charge you fees
541 2016-07-14T19:24:40  <luke-jr> weight also should be fine for GBT; nothing is released using the old cost stuff yet
542 2016-07-14T19:24:59  <luke-jr> jtimon: is there a problem with "weight"?
543 2016-07-14T19:25:08  <gmaxwell> in any case, I support the great cost to weight renaming.
544 2016-07-14T19:25:09  <sipa> petertodd: that's what i did originally
545 2016-07-14T19:25:14  <wumpus> #action rename blockmaxcost to blockmaxweight
546 2016-07-14T19:25:23  <jtimon> yeah, sorry I'll wait for botbot.me to update
547 2016-07-14T19:25:26  <instagibbs> We can chew it over offline
548 2016-07-14T19:25:29  <petertodd> sipa: well, ack your original idea :)
549 2016-07-14T19:25:46  <sipa> petertodd: but then people started complaining that there had to be a way to limit the serialized size too
550 2016-07-14T19:26:01  <jeremyrubin> jtimon: but that's not the units of the cost, otherwise you would denote it into BTC or something...
551 2016-07-14T19:26:05  <btcdrak> jtimon: you can see.logs in slack
552 2016-07-14T19:26:15  *** gabridome has quit IRC
553 2016-07-14T19:27:00  <petertodd> jeremyrubin: blockbytescost :)
554 2016-07-14T19:27:04  *** gabridome1 has quit IRC
555 2016-07-14T19:27:19  *** gabridome has joined #bitcoin-core-dev
556 2016-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
557 2016-07-14T19:27:58  *** gabridome1 has joined #bitcoin-core-dev
558 2016-07-14T19:28:20  <wumpus> other topics?
559 2016-07-14T19:28:28  <sipa> segwit backport
560 2016-07-14T19:28:31  <wumpus> ah yes
561 2016-07-14T19:28:34  <wumpus> #topic segwit backport
562 2016-07-14T19:28:39  <jtimon> btcdrak: I didn't knew, never used the bitcoin slack
563 2016-07-14T19:28:49  *** maaku has joined #bitcoin-core-dev
564 2016-07-14T19:29:04  <sipa> wumpus: some people have raised concerns about backporting segwit to 0.12
565 2016-07-14T19:29:24  <wumpus> concerns about doing it at all?
566 2016-07-14T19:29:25  <jtimon> what's the concern?
567 2016-07-14T19:29:31  <luke-jr> ^
568 2016-07-14T19:29:35  <wumpus> well, next chance is 0.13.1
569 2016-07-14T19:29:50  *** [b__b] has joined #bitcoin-core-dev
570 2016-07-14T19:29:51  <sipa> morcos, btcdrak: ?
571 2016-07-14T19:30:21  <morcos> :), yes i was arguing that it would be a mistake
572 2016-07-14T19:30:33  <jl2012> me too
573 2016-07-14T19:30:36  <instagibbs> could you reiterate for the audience
574 2016-07-14T19:30:49  <jtimon> if the backport doesn't get enough review and testing there's no new 0.12 release, simple, no?
575 2016-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
576 2016-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
577 2016-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...
578 2016-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
579 2016-07-14T19:31:10  <luke-jr> jtimon: backports never do, unless they're the tip release
580 2016-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
581 2016-07-14T19:31:34  <btcdrak> yes. I share morcos concerns about backporting
582 2016-07-14T19:31:37  *** gabridome has quit IRC
583 2016-07-14T19:31:44  <luke-jr> wumpus: "too bad" may result in delayed deployment maybe
584 2016-07-14T19:31:46  <jtimon> luke-jr: so all previous backported softforks were unsafe ?
585 2016-07-14T19:31:58  <luke-jr> jtimon: such as?
586 2016-07-14T19:31:59  <wumpus> luke-jr: yes, but delay is better than messing up
587 2016-07-14T19:32:08  <sipa> about this topic
588 2016-07-14T19:32:21  <sipa> in the past we've seen miners often run even pre-release code
589 2016-07-14T19:32:27  <jtimon> luke-jr: I don't know if any of them was unsafe, I'm asking
590 2016-07-14T19:32:34  <sipa> if that is going to happen, my concerns about a backport go down
591 2016-07-14T19:32:38  <wumpus> I hate delays, but minimizing risk is the highest priority
592 2016-07-14T19:32:39  <sipa> but so does its usefulness
593 2016-07-14T19:32:40  <jl2012> have anyone asked miners that they really need a backport?
594 2016-07-14T19:32:41  <maaku> i'm strongly against "too bad" -- we need to take our support guarantees seriously
595 2016-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.
596 2016-07-14T19:33:01  *** spudowiar has joined #bitcoin-core-dev
597 2016-07-14T19:33:03  <morcos> maaku: we already didn't backport CSV
598 2016-07-14T19:33:11  <wumpus> maaku: there are no guarantees
599 2016-07-14T19:33:11  <maaku> people are running businesses assuming we support "current plus prior" not "current plus prior, except when it's inconvenient"
600 2016-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.
601 2016-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
602 2016-07-14T19:33:49  <maaku> gmaxwell: it would mean you could no longer mine on 0.12
603 2016-07-14T19:33:50  <sipa> jl2012: that's the most important question
604 2016-07-14T19:33:56  <wumpus> this is not about 'inconvenient', this is about risk
605 2016-07-14T19:33:58  <morcos> gmaxwell: are you more worried about miners or users?
606 2016-07-14T19:34:16  *** [b__b] has quit IRC
607 2016-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.
608 2016-07-14T19:34:26  <gmaxwell> morcos: users.
609 2016-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
610 2016-07-14T19:34:35  *** [b__b] has joined #bitcoin-core-dev
611 2016-07-14T19:34:49  <wumpus> we wouldn't want a DAO scale disaster over over-hurried release of hardly-reviewed and tested code
612 2016-07-14T19:35:03  <CodeShark> wumpus +1
613 2016-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...
614 2016-07-14T19:35:09  <wumpus> so if it needs to be 0.13.1, it will be 0.13.1
615 2016-07-14T19:35:25  <gmaxwell> Sure.
616 2016-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?
617 2016-07-14T19:35:44  <luke-jr> maaku: we need to stop guaranteeing things we can't providr
618 2016-07-14T19:36:01  <achow101> how many miners even use backports?
619 2016-07-14T19:36:05  <wumpus> morcos: no - if it would be in 0.12.2, it could make it into 0.13.0 too
620 2016-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.
621 2016-07-14T19:36:17  <wumpus> morcos: assuming 0.12.2 is released before 0.13.0 of course
622 2016-07-14T19:36:18  <luke-jr> achow101: all of htem right now I think
623 2016-07-14T19:36:22  <jtimon> morcos: maybe rebasing my code to 0.13.1 is not easier than rebasing it to 0.12.2
624 2016-07-14T19:36:24  <wumpus> morcos: then again that ship sailed already
625 2016-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
626 2016-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.
627 2016-07-14T19:38:08  <achow101> what about releasing 0.13.1 and then 0.12.2?
628 2016-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
629 2016-07-14T19:38:35  *** fengling_ has joined #bitcoin-core-dev
630 2016-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
631 2016-07-14T19:38:53  <wumpus> achow101: well if a backport is released at all, why would it matter in what order?
632 2016-07-14T19:39:00  <gmaxwell> Wouldn't want to make a classic blunder, "never get involved in a land war in Asia"!
633 2016-07-14T19:39:00  <morcos> anyway, sorry, i have to catch a train, got to run!
634 2016-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
635 2016-07-14T19:39:30  <btcdrak> It's also a lot cleaner releasing in 0.13.1 because 0.12 would not have compact blocks
636 2016-07-14T19:39:37  <luke-jr> wumpus: order matters a lot for testing
637 2016-07-14T19:39:48  <petertodd> sipa: sure, if it removed getblocktemplate that'd be an easy idea to support
638 2016-07-14T19:39:56  <gmaxwell> well right now 0.13.0 doesn't have CB for segwit, though I suppose 0.13.1 could.
639 2016-07-14T19:39:57  <jtimon> sipa: yeah, I assumed that was the plan
640 2016-07-14T19:40:00  <achow101> wumpus: for proper review of the backport without delaying deployment
641 2016-07-14T19:40:03  <wumpus> I do wish we had realized this sooner, instead of seeming like a last minute decision
642 2016-07-14T19:40:09  <gmaxwell> wumpus: likewise.
643 2016-07-14T19:40:21  <wumpus> achow101: even fewer people will care about 0.12.x if 0.13 is already out
644 2016-07-14T19:40:31  <gmaxwell> otoh, decisions to do _less_ at the last minute are better than decisions to do _more_. :)
645 2016-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.
646 2016-07-14T19:40:37  <sipa> i guess the question is what has priority: segwit backport or 0.13 release?
647 2016-07-14T19:40:38  <wumpus> gmaxwell: hah, fully agreed
648 2016-07-14T19:40:54  <petertodd> sipa: 0.13 release I think
649 2016-07-14T19:41:00  <gmaxwell> We have real problems with virtually no one ever using backports.
650 2016-07-14T19:41:06  <wumpus> for me the 0.13 release has priority
651 2016-07-14T19:41:09  <helo> +1 release
652 2016-07-14T19:41:17  <jonasschnelli> agree with wumpus
653 2016-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
654 2016-07-14T19:41:30  <gmaxwell> 0.13 release has priority.
655 2016-07-14T19:41:33  <sipa> and if that is the case, a backport would be urgent
656 2016-07-14T19:41:36  <jtimon> waiting to release 0.13 to release 0.12.2 first sounds stupid to me
657 2016-07-14T19:41:43  <sipa> or 0.13.1 would suffer delays
658 2016-07-14T19:41:55  <btcdrak> sipa: getting enough review for backport to 0.12.2 would be questionable.
659 2016-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.
660 2016-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
661 2016-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
662 2016-07-14T19:42:24  <jtimon> petertodd: that's a good idea
663 2016-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?
664 2016-07-14T19:42:37  <sipa> if there are critical bugs in 0.12.1, we can always release 0.12.2 to fix them
665 2016-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).
666 2016-07-14T19:42:39  <petertodd> jtimon: I think we've done it before too
667 2016-07-14T19:42:56  <jtimon> and depending on the response decide to the the backport or not
668 2016-07-14T19:42:57  <sipa> btcdrak: tbh, i think that the difficulty of a segwit backport is not that hard
669 2016-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.
670 2016-07-14T19:43:11  <btcdrak> sipa: you would say that though :)
671 2016-07-14T19:43:12  <sipa> btcdrak: the original segwit PR was made with mostly 0.12 code still
672 2016-07-14T19:43:14  <gmaxwell> luke-jr: maybe we should start making more really disruptive changes in major releases. :)
673 2016-07-14T19:43:26  *** fengling_ has quit IRC
674 2016-07-14T19:43:29  <wumpus> 'maintain' older branches does not mean backport everything
675 2016-07-14T19:43:35  <jonasschnelli> agree
676 2016-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
677 2016-07-14T19:43:48  <wumpus> just that serious and critical issues are addressed
678 2016-07-14T19:43:53  <sipa> yes  0.12.2 can still happen if a serioud bug in 0.12.1 is founf
679 2016-07-14T19:44:06  <luke-jr> wumpus: not supporting a deployed softfork is a critical issue for a full node
680 2016-07-14T19:44:08  <jtimon> gmaxwell: I've been always in favor of doing disruptive refactors just before branching instead of right after
681 2016-07-14T19:44:27  *** gabridome has joined #bitcoin-core-dev
682 2016-07-14T19:44:39  <sipa> ok, i need to run
683 2016-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
684 2016-07-14T19:44:57  <sipa> i'll still work on a backport if there is demand
685 2016-07-14T19:45:08  <luke-jr> jonasschnelli: that's a point I suppose
686 2016-07-14T19:45:16  <gmaxwell> sipa: it might be a useful excercise from a review perspective in any case.
687 2016-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)
688 2016-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
689 2016-07-14T19:45:52  <luke-jr> petertodd: true; we should make this more well-known IMO
690 2016-07-14T19:45:58  <luke-jr> not sure how many people realise it
691 2016-07-14T19:46:02  <petertodd> luke-jr: good thing for the release notes!
692 2016-07-14T19:46:05  <gmaxwell> I always point it out.
693 2016-07-14T19:46:08  <jtimon> wumpus: I mean the of the kind that present low risk (like file renaming on moveonly commits)
694 2016-07-14T19:46:16  <gmaxwell> but it's the sort of thing that needs a diagram. :)
695 2016-07-14T19:46:20  <luke-jr> gmaxwell: did you for Eligius? :P
696 2016-07-14T19:46:26  <CodeShark> petertodd +1
697 2016-07-14T19:46:32  <maaku> has anyone actually quantified what level of review is required for a backport?
698 2016-07-14T19:46:32  * luke-jr knows he overlooked it
699 2016-07-14T19:46:33  <jtimon> wumpus: but I guess you're right about the pre-release preassure
700 2016-07-14T19:46:47  <maaku> segwit was written against 0.12.
701 2016-07-14T19:46:48  <luke-jr> actually, I guess it might not entirely work for CSV + mining
702 2016-07-14T19:46:48  <wumpus> jtimon: in any case I doubt raneming and moveonly commits are what really makes it difficult to backport things :)
703 2016-07-14T19:46:53  <wumpus> jtimon: more things like the mempool changes
704 2016-07-14T19:47:34  <jl2012> petertodd: except you can't mine any segwit tx with a 0.12 behind 0.13
705 2016-07-14T19:47:40  <btcdrak> well I'd like to see a refactoring window right after branching, maybe 2 weeks
706 2016-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?
707 2016-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.
708 2016-07-14T19:48:11  <jtimon> how would any refactor now difficult backporting segwit?
709 2016-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.
710 2016-07-14T19:48:33  *** gabridome1 has quit IRC
711 2016-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
712 2016-07-14T19:49:16  <petertodd> jl2012: "can't mine" is a smaller group of people than all full node users
713 2016-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
714 2016-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
715 2016-07-14T19:51:54  <btcdrak> jtimon: ack
716 2016-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!"
717 2016-07-14T19:52:56  <gmaxwell> in any case, short on time. Are we done on this subject?
718 2016-07-14T19:53:03  <instagibbs> 8 minutes left
719 2016-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
720 2016-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.
721 2016-07-14T19:53:55  <wumpus> seems so
722 2016-07-14T19:54:01  <petertodd> gmaxwell: good idea
723 2016-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...
724 2016-07-14T19:54:29  <petertodd> gmaxwell: that too...
725 2016-07-14T19:54:47  <wumpus> other topics? last-minute announcements?
726 2016-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.
727 2016-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.
728 2016-07-14T19:56:11  <jtimon> can be after the meeting but...
729 2016-07-14T19:56:12  <wumpus> well if bitcoin core's wallet is unusable for commercial use, I wonder what wallet is..
730 2016-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.
731 2016-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)
732 2016-07-14T19:56:42  <gmaxwell> wumpus: people use centeralized api providers instead almost universally.
733 2016-07-14T19:56:55  <bsm117532> But I would like to see removal of "accounts".  Is anyone working on that?
734 2016-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
735 2016-07-14T19:57:21  <petertodd> bsm117532: re: removing accounts, have you checked with joinmarket on what they'll do? they use accounts
736 2016-07-14T19:57:28  <wumpus> bsm117532: but that didn't get enough review
737 2016-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
738 2016-07-14T19:57:54  <jtimon> yay nay ?
739 2016-07-14T19:58:02  <wumpus> bsm117532: https://github.com/bitcoin/bitcoin/pull/7729
740 2016-07-14T19:58:06  <sipa> jtimon: yay, after 0
741 2016-07-14T19:58:25  <jtimon> sipa: yeah, I'm assuming after 0.13 branches
742 2016-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?
743 2016-07-14T19:58:52  <gmaxwell> ironically, one of the complaints I got there was that accounts are discouraged. ::shrugs::
744 2016-07-14T19:58:56  <sipa> though i prefer to leave some things as "base logic" like maaku suggests
745 2016-07-14T19:58:58  <jtimon> I mean, if people want before I'm all in, but I highly doubt it
746 2016-07-14T19:59:12  <btcdrak> we should ping belcher
747 2016-07-14T19:59:13  <petertodd> wumpus: yes, I'm 99% sure - I use joinmarket all the time
748 2016-07-14T19:59:34  <bsm117532> wumpus: I will review 7729 and try to offer some feedback
749 2016-07-14T19:59:39  <btcdrak> he's got some homework then...
750 2016-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
751 2016-07-14T19:59:50  <luke-jr> I need to get back on the road, bbl
752 2016-07-14T19:59:53  <sipa> maaku: agree
753 2016-07-14T19:59:56  <jtimon> sipa: mhmm, you mean making another "base logic" dir and package in the makefile ?
754 2016-07-14T20:00:13  <sipa> jtimon: well one such piece of base logic is primitives
755 2016-07-14T20:00:26  <petertodd> maaku: less approchable? I'd argue more - makes it easier to understand what consensus is and isn't
756 2016-07-14T20:00:29  <wumpus> gmaxwell: it's also taking so insanely long to remove it
757 2016-07-14T20:00:37  <jtimon> maaku: I strongly disagree (but maybe not all people are mostly interested in the consensus code like me)
758 2016-07-14T20:00:49  <wumpus> gmaxwell: same as I've seen with the label API pull - no one is really interested in it
759 2016-07-14T20:00:54  <sipa> jtimon: things like prevector and so seem also more broadly usable than consensus
760 2016-07-14T20:00:58  <maaku> petertodd: that's rarely someone's first question when approaching the code base
761 2016-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
762 2016-07-14T20:01:15  <sipa> time up
763 2016-07-14T20:01:18  <btcdrak> well I hate to say it, but its not like the code is that approachable as is...
764 2016-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?
765 2016-07-14T20:01:20  <wumpus> #endmeeting
766 2016-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)
767 2016-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
768 2016-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
769 2016-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
770 2016-07-14T20:01:28  <jtimon> sipa: agreed, but libconsensus needs them if we're ever going to separate the library ala libsecp
771 2016-07-14T20:01:31  <instagibbs> btcdrak, heh
772 2016-07-14T20:01:36  <maaku> btcdrak: it is way better than when I started
773 2016-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
774 2016-07-14T20:01:42  <maaku> so please don't make it worse
775 2016-07-14T20:01:48  <sipa> jtimon: there's no problem in dependong on things outside of consensus
776 2016-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.
777 2016-07-14T20:02:04  <wumpus> gmaxwell:  https://github.com/bitcoin/bitcoin/pull/7729
778 2016-07-14T20:02:05  <sipa> jtimon: we also depend on libstdc++ and an OS, righ
779 2016-07-14T20:02:07  <petertodd> maaku: that's how I learned how the bitcoin protocol works
780 2016-07-14T20:02:07  <btcdrak> maaku: beauty is in the eye of the beholder :-p
781 2016-07-14T20:02:11  <jtimon> no, I mean, if at some point libconsensus becomes its own repo
782 2016-07-14T20:02:17  <maaku> petertodd: that doesn't require the files to literally be in the same directory.
783 2016-07-14T20:02:24  <jonasschnelli> Yes. We should reconsider wumpus  7729
784 2016-07-14T20:02:28  * btcdrak is just teasing
785 2016-07-14T20:02:30  <maaku> when you see #include <script/interpreter.h> you know to find it in the src/script folder
786 2016-07-14T20:02:31  <sipa> jtimon: ok, so there may be a 3rd repo/library with just data structured and serialization
787 2016-07-14T20:02:32  *** spudowiar has quit IRC
788 2016-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
789 2016-07-14T20:02:53  <maaku> i would very much like a libbitcoinserialization for other purposes
790 2016-07-14T20:02:53  <sipa> wumpus: agree, i forgot there was a pull
791 2016-07-14T20:03:06  <wumpus> then people complain 'there are no tests'... well duh
792 2016-07-14T20:03:06  <maaku> (there's a lot of api changes to get there though)
793 2016-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?
794 2016-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.
795 2016-07-14T20:03:17  <jtimon> that would work
796 2016-07-14T20:03:17  <instagibbs> "No shit" - wumpus 2016
797 2016-07-14T20:03:28  <petertodd> instagibbs: ...for president!
798 2016-07-14T20:03:30  * petertodd ducks
799 2016-07-14T20:03:31  <instagibbs> i lol'd
800 2016-07-14T20:03:57  *** maaku has left #bitcoin-core-dev
801 2016-07-14T20:04:11  <petertodd> maaku: fwiw, I already do that kind of separation in python-bitcoinlib, with everything consensus under bitcoin.core
802 2016-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)
803 2016-07-14T20:04:43  *** Frederic94500 has quit IRC
804 2016-07-14T20:05:10  <btcdrak> I'm going to talk with belcher about accounts see what his plans are
805 2016-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...
806 2016-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
807 2016-07-14T20:05:49  <gmaxwell> which, IMO, is the only sensible thing accounts actually does in any case.
808 2016-07-14T20:05:55  <bsm117532> That's what I gather, looks good.  I'll test it.
809 2016-07-14T20:06:05  <btcdrak> petertodd: maybe they should use my addrindex patch.
810 2016-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
811 2016-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 )
812 2016-07-14T20:06:24  <wumpus> petertodd: oh good, in that case there is no problem at all
813 2016-07-14T20:06:27  <gmaxwell> does account bookkeeping even do anything with watch addresses?
814 2016-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
815 2016-07-14T20:06:53  <bsm117532> Hmmm I would need watchonly addresses attached to my labels.
816 2016-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)
817 2016-07-14T20:07:14  *** frankenmint has joined #bitcoin-core-dev
818 2016-07-14T20:07:51  *** afk11 has quit IRC
819 2016-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!
820 2016-07-14T20:09:38  <wumpus> petertodd: yes, joinmarket works with a pruned node
821 2016-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...
822 2016-07-14T20:10:32  <jtimon> what about using utilmoneystr in libconsensus or not? maaku and I are in disagreement here
823 2016-07-14T20:10:38  <jtimon> oh, damm, he left
824 2016-07-14T20:11:00  <sipa> jtimon: i say get rid of that formatting
825 2016-07-14T20:11:04  <sipa> it's debug output
826 2016-07-14T20:11:17  <gmaxwell> anything with "str" doesn't sound like it belongs in consensus code. :P
827 2016-07-14T20:11:24  <sipa> in the long term, concensus logic should not do error formatting
828 2016-07-14T20:11:51  <petertodd> gmaxwell: we need a semi-consensus library for stuff like that :)
829 2016-07-14T20:12:22  <petertodd> gmaxwell: maybe, like dante's rings of hell...
830 2016-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
831 2016-07-14T20:12:48  *** frankenmint has quit IRC
832 2016-07-14T20:12:59  <jtimon> gmaxwell: well, I wasn't planning on removing tinyformat, at least not yet, but this is one line
833 2016-07-14T20:13:22  <jtimon> this line: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1959
834 2016-07-14T20:13:24  *** afk11 has joined #bitcoin-core-dev
835 2016-07-14T20:13:24  *** afk11 has quit IRC
836 2016-07-14T20:13:24  *** afk11 has joined #bitcoin-core-dev
837 2016-07-14T20:14:00  <jtimon> well, not that one actually, L1961
838 2016-07-14T20:14:53  <jtimon> is there a date for the 0.13 fork?
839 2016-07-14T20:16:09  <jtimon> wumpus: or estimation?
840 2016-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...
841 2016-07-14T20:16:56  <instagibbs> *if 0.12.2 is dropped
842 2016-07-14T20:25:52  *** Chris_Stewart_5 has quit IRC
843 2016-07-14T20:29:17  *** spudowiar has joined #bitcoin-core-dev
844 2016-07-14T20:32:32  *** adamg has joined #bitcoin-core-dev
845 2016-07-14T20:33:39  *** yep has quit IRC
846 2016-07-14T20:33:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
847 2016-07-14T20:39:33  <gmaxwell> instagibbs: I agree. sipa's implementation also seemed to be working pretty well on testnet.
848 2016-07-14T20:40:09  *** fengling_ has joined #bitcoin-core-dev
849 2016-07-14T20:42:48  *** ArthurNumbanumba has quit IRC
850 2016-07-14T20:45:06  *** fengling_ has quit IRC
851 2016-07-14T20:47:52  *** MarcoFalke has left #bitcoin-core-dev
852 2016-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
853 2016-07-14T21:02:02  *** Chris_Stewart_5 has quit IRC
854 2016-07-14T21:17:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
855 2016-07-14T21:23:36  *** ArthurNumbanumba has joined #bitcoin-core-dev
856 2016-07-14T21:24:28  *** frankenmint has joined #bitcoin-core-dev
857 2016-07-14T21:31:09  *** jannes has quit IRC
858 2016-07-14T21:31:11  *** achow101 has quit IRC
859 2016-07-14T21:33:12  *** TomMc has quit IRC
860 2016-07-14T21:33:26  <jtimon> updated #8329 without  #8328
861 2016-07-14T21:33:37  <jtimon> moveonly, one commit
862 2016-07-14T21:41:41  *** fengling_ has joined #bitcoin-core-dev
863 2016-07-14T21:42:43  *** achow101 has joined #bitcoin-core-dev
864 2016-07-14T21:46:26  *** fengling_ has quit IRC
865 2016-07-14T21:47:34  *** TomMc has joined #bitcoin-core-dev
866 2016-07-14T21:51:04  *** afk11 has quit IRC
867 2016-07-14T21:53:25  *** delinquentme has quit IRC
868 2016-07-14T21:57:41  *** afk11 has joined #bitcoin-core-dev
869 2016-07-14T21:57:41  *** afk11 has quit IRC
870 2016-07-14T21:57:41  *** afk11 has joined #bitcoin-core-dev
871 2016-07-14T22:02:22  *** spudowiar has quit IRC
872 2016-07-14T22:17:24  *** TomMc has quit IRC
873 2016-07-14T22:24:58  *** Samdney has joined #bitcoin-core-dev
874 2016-07-14T22:27:09  *** gabridome1 has joined #bitcoin-core-dev
875 2016-07-14T22:28:22  *** d_t has joined #bitcoin-core-dev
876 2016-07-14T22:28:43  *** gabridome2 has joined #bitcoin-core-dev
877 2016-07-14T22:28:56  *** gabridome has quit IRC
878 2016-07-14T22:31:24  *** gabridome1 has quit IRC
879 2016-07-14T22:32:03  *** d_t has quit IRC
880 2016-07-14T22:32:09  *** gabridome has joined #bitcoin-core-dev
881 2016-07-14T22:34:54  *** gabridome2 has quit IRC
882 2016-07-14T22:43:09  *** fengling_ has joined #bitcoin-core-dev
883 2016-07-14T22:47:46  *** fengling_ has quit IRC
884 2016-07-14T22:52:40  <BlueMatt> <denisx> the only thing I needed to change for building on freebsd was the DEFINE of FREEBSD
885 2016-07-14T22:52:45  <BlueMatt> <denisx> it was FREEBSD10.3 but it should only be FREEBSD
886 2016-07-14T22:52:51  <BlueMatt> cfields: know whats up with that?
887 2016-07-14T22:54:24  *** Guyver2 has quit IRC
888 2016-07-14T22:55:10  *** ArthurNumbanumba has quit IRC
889 2016-07-14T22:56:21  *** BitcoinErrorLog has joined #bitcoin-core-dev
890 2016-07-14T23:03:46  *** laurentmt has joined #bitcoin-core-dev
891 2016-07-14T23:04:32  *** laurentmt has quit IRC
892 2016-07-14T23:08:51  *** ArthurNumbanumba has joined #bitcoin-core-dev
893 2016-07-14T23:38:34  *** delinquentme has joined #bitcoin-core-dev
894 2016-07-14T23:44:10  *** fengling_ has joined #bitcoin-core-dev
895 2016-07-14T23:49:06  *** fengling_ has quit IRC
896 2016-07-14T23:53:07  *** LeMiner2 has joined #bitcoin-core-dev
897 2016-07-14T23:55:40  *** LeMiner has quit IRC
898 2016-07-14T23:55:40  *** LeMiner2 is now known as LeMiner