1 2016-04-23T00:00:09  *** arowser has quit IRC
  2 2016-04-23T00:00:45  *** arowser has joined #bitcoin-core-dev
  3 2016-04-23T00:17:30  <sdaftuar> gmaxwell: hah, i made the same patch myself to see how big the changes were, then figured out that this must be exactly what sipa meant about the ever-expanding scope of that PR
  4 2016-04-23T00:21:09  *** frankenmint has joined #bitcoin-core-dev
  5 2016-04-23T00:43:00  *** Ylbam has quit IRC
  6 2016-04-23T00:53:11  *** belcher has quit IRC
  7 2016-04-23T01:04:09  *** mrkent_ has quit IRC
  8 2016-04-23T01:12:32  *** Kexkey has quit IRC
  9 2016-04-23T01:34:02  *** Alopex has quit IRC
 10 2016-04-23T01:34:44  *** ebfull has joined #bitcoin-core-dev
 11 2016-04-23T01:34:55  *** ebfull has quit IRC
 12 2016-04-23T01:35:07  *** Alopex has joined #bitcoin-core-dev
 13 2016-04-23T01:48:04  *** Chris_Stewart_5 has quit IRC
 14 2016-04-23T01:57:42  <gmaxwell> sdaftuar: I do feel kinda bad that it takes a mempool lock now several times for each transaction in the queue, but it's negligble. It could be easily optimized later, e.g. to have a function that took the set and populated a vector of {hash, depth, feerate} and dropped evicted transactions, all under a single lock acquisition. But that can be done another day...
 15 2016-04-23T01:58:15  <gmaxwell> the improvement from this for propagation of dependant transactions is really substantial, and I'd rather not delay it.
 16 2016-04-23T02:16:04  *** river__ has joined #bitcoin-core-dev
 17 2016-04-23T02:36:19  *** laurentmt has joined #bitcoin-core-dev
 18 2016-04-23T02:39:20  *** laurentmt has quit IRC
 19 2016-04-23T02:51:01  *** Alopex has quit IRC
 20 2016-04-23T02:52:06  *** Alopex has joined #bitcoin-core-dev
 21 2016-04-23T03:19:01  *** Alopex has quit IRC
 22 2016-04-23T03:19:25  *** frankenmint has quit IRC
 23 2016-04-23T03:20:06  *** Alopex has joined #bitcoin-core-dev
 24 2016-04-23T03:31:32  *** zooko has quit IRC
 25 2016-04-23T03:33:02  *** frankenmint has joined #bitcoin-core-dev
 26 2016-04-23T03:35:01  *** Alopex has quit IRC
 27 2016-04-23T03:36:07  *** Alopex has joined #bitcoin-core-dev
 28 2016-04-23T03:58:02  *** frankenmint has quit IRC
 29 2016-04-23T04:20:07  *** river__ has quit IRC
 30 2016-04-23T04:21:25  *** p15x has joined #bitcoin-core-dev
 31 2016-04-23T05:02:16  *** frankenmint has joined #bitcoin-core-dev
 32 2016-04-23T05:06:01  *** Alopex has quit IRC
 33 2016-04-23T05:07:06  *** Alopex has joined #bitcoin-core-dev
 34 2016-04-23T05:17:04  *** grassass has joined #bitcoin-core-dev
 35 2016-04-23T05:23:40  *** arowser has quit IRC
 36 2016-04-23T05:24:09  *** arowser has joined #bitcoin-core-dev
 37 2016-04-23T05:44:15  <phantomcircuit> wumpus, currently have fuzzing of CDataStream >> CBlock working
 38 2016-04-23T05:44:44  <wumpus> great!
 39 2016-04-23T05:45:03  <phantomcircuit> i figured that would exercise the most of the serialization stuff in one go
 40 2016-04-23T05:45:55  <phantomcircuit> also discovered that combining std::copy with violation of the strict aliasing rule is a bad idea
 41 2016-04-23T05:46:03  <phantomcircuit> (on the latest gcc at least)
 42 2016-04-23T05:46:39  <gmaxwell> violating aliasing rules is always a bad idea. :)
 43 2016-04-23T05:47:06  *** dermoth_ has quit IRC
 44 2016-04-23T05:50:53  <phantomcircuit> gmaxwell, i wasn't expecting it to violate the rule though
 45 2016-04-23T05:51:23  <phantomcircuit> (and there's no warning about it)
 46 2016-04-23T05:51:29  <phantomcircuit> ie thought it was char*
 47 2016-04-23T05:51:42  <gmaxwell> ah, no you were copying a vector, no?
 48 2016-04-23T05:52:02  <phantomcircuit> copying from std::vector<char> to uint32_t*
 49 2016-04-23T05:52:14  <gmaxwell> yea... not quite. :)
 50 2016-04-23T05:52:17  <gmaxwell> Have you tried introducing a bug and verifying that it finds it?
 51 2016-04-23T05:52:41  <phantomcircuit> currently im trying to identify which exceptions i should catch as "that's expected"
 52 2016-04-23T06:06:23  <phantomcircuit> gmaxwell, huh memcpy is void*
 53 2016-04-23T06:06:34  <phantomcircuit> i guess this is *also* violating sa
 54 2016-04-23T06:11:11  <phantomcircuit> it seems like catching std::ios_base::failure is enough
 55 2016-04-23T06:11:58  <gmaxwell> phantomcircuit: it isn't the protype that can violate SA, its whats done inside, if you implemented your own memcpy and did your accesses via char pointers you'd be fine.
 56 2016-04-23T06:12:46  <phantomcircuit> gmaxwell, i wonder if glibc memcpy is char* internally or not
 57 2016-04-23T06:13:33  *** arowser has quit IRC
 58 2016-04-23T06:13:58  *** arowser has joined #bitcoin-core-dev
 59 2016-04-23T06:22:33  <sipa> phantomcircuit: i assume it's written in asm :)
 60 2016-04-23T06:22:53  <gmaxwell> "lol"
 61 2016-04-23T06:32:54  *** frankenmint has quit IRC
 62 2016-04-23T06:33:02  *** Alopex has quit IRC
 63 2016-04-23T06:34:07  *** Alopex has joined #bitcoin-core-dev
 64 2016-04-23T06:49:01  *** Alopex has quit IRC
 65 2016-04-23T06:50:07  *** Alopex has joined #bitcoin-core-dev
 66 2016-04-23T07:12:49  *** arowser_ has joined #bitcoin-core-dev
 67 2016-04-23T07:14:26  *** arowser has quit IRC
 68 2016-04-23T07:22:39  *** Guyver2 has joined #bitcoin-core-dev
 69 2016-04-23T07:29:02  *** Alopex has quit IRC
 70 2016-04-23T07:30:07  *** Alopex has joined #bitcoin-core-dev
 71 2016-04-23T07:34:04  <luke-jr> phantomcircuit: it's SSSE3 usually :/
 72 2016-04-23T07:34:18  <luke-jr> I had to build my glibc with -mno-ssse3 or stuff crashed
 73 2016-04-23T07:34:29  <phantomcircuit> luke-jr, ha
 74 2016-04-23T07:35:01  * luke-jr never figured out why Haswell's SSSE3 seems to be broken in 32-bit mode.
 75 2016-04-23T07:37:29  <GitHub187> [bitcoin] laanwj opened pull request #7927: Minor changes to dbwrapper to simplify support for other databases (master...2016_04_dbwrapper_modernization) https://github.com/bitcoin/bitcoin/pull/7927
 76 2016-04-23T07:39:34  <gmaxwell> you mean 'x32' right?
 77 2016-04-23T07:41:40  <luke-jr> no, regular 32-bit
 78 2016-04-23T07:41:47  <gmaxwell> weird.
 79 2016-04-23T07:41:49  <luke-jr> I suspect x32 would work
 80 2016-04-23T07:42:00  <luke-jr> my best guess so far has been pointer alignment stuff
 81 2016-04-23T07:42:18  <gmaxwell> I assume it's not haswell, but some GCC bug.
 82 2016-04-23T07:42:25  <luke-jr> possible
 83 2016-04-23T07:42:36  <luke-jr> maybe Haswell is stricted on the spec than previous CPUs?
 84 2016-04-23T07:43:11  <sipa> i doubt the spec changed, but perhaps older cpus were more lenient with spec violations :)
 85 2016-04-23T07:43:35  <luke-jr> although it'd be a glibc *and* Mesa bug, as it turned up at least both implementations of memcpy (not sure why Mesa has a separate one, but oh well)
 86 2016-04-23T07:44:04  <luke-jr> or GCC, but I don't see how the compiler could be at fault for this
 87 2016-04-23T07:44:09  <luke-jr> IIRC it's inline asm
 88 2016-04-23T07:44:18  <luke-jr> (but I haven't looked at it in probably a year or so)
 89 2016-04-23T07:44:21  *** davec has quit IRC
 90 2016-04-23T07:50:02  *** davec has joined #bitcoin-core-dev
 91 2016-04-23T07:58:05  <phantomcircuit> luke-jr, that would explain why it does what i expect it to do
 92 2016-04-23T07:58:14  <luke-jr> ?
 93 2016-04-23T07:58:14  *** pmienk has joined #bitcoin-core-dev
 94 2016-04-23T07:58:29  <phantomcircuit> gmaxwell, it seems like the only way to ensure sa isn't being violated would be to copy byte by byte
 95 2016-04-23T08:06:14  <sipa> phantomcircuit: void* is allowed to alias any pointer, i think
 96 2016-04-23T08:08:15  <luke-jr> in C, at least; not sure about C++ - it complains if you do it implicitly, at least
 97 2016-04-23T08:12:55  *** Ylbam has joined #bitcoin-core-dev
 98 2016-04-23T08:23:35  *** PaulCape_ has quit IRC
 99 2016-04-23T08:24:01  *** PaulCapestany has joined #bitcoin-core-dev
100 2016-04-23T08:28:20  *** frankenmint has joined #bitcoin-core-dev
101 2016-04-23T08:34:23  *** Thireus1 has quit IRC
102 2016-04-23T08:41:53  *** Thireus has joined #bitcoin-core-dev
103 2016-04-23T08:55:42  *** p15x has quit IRC
104 2016-04-23T09:00:37  *** KHCkjhv has joined #bitcoin-core-dev
105 2016-04-23T09:08:24  *** KHCkjhv has quit IRC
106 2016-04-23T09:21:10  *** Guyver2 has quit IRC
107 2016-04-23T09:21:22  *** pmienk has quit IRC
108 2016-04-23T09:34:47  *** pmienk has joined #bitcoin-core-dev
109 2016-04-23T09:49:57  *** arowser_ has quit IRC
110 2016-04-23T09:50:13  *** arowser has joined #bitcoin-core-dev
111 2016-04-23T10:05:09  <sipa> i upgraded to xenial, did git -dfx, ccache -C, ./autogen.sh, ./configure, make -j5... and i get util.cpp:817:53: error: ‘COPYRIGHT_HOLDERS’ was not declared in this scope
112 2016-04-23T10:05:50  * sipa tries again
113 2016-04-23T10:06:50  <luke-jr> stale config.h somewhere?
114 2016-04-23T10:07:07  <sipa> after git -dfx ?
115 2016-04-23T10:07:14  <sipa> eh, git clean -dfx
116 2016-04-23T10:08:55  <luke-jr> hm, assuming our gitignore is okay that should eliminate any
117 2016-04-23T10:09:39  <sipa> git clean -dfx deletes all files not checked in
118 2016-04-23T10:09:44  <sipa> including ignored files
119 2016-04-23T10:09:50  <sipa> but also others
120 2016-04-23T10:10:07  <sipa> so gitignore is not relevant
121 2016-04-23T10:11:16  <luke-jr> hm
122 2016-04-23T10:11:36  <sipa> i think it's working now...
123 2016-04-23T10:11:40  <luke-jr> what changed?
124 2016-04-23T10:12:19  <sipa> i did git clean -dfx again...
125 2016-04-23T10:15:16  <luke-jr> strange
126 2016-04-23T10:15:40  <NicolasDorier> btw I got also the same error yestersday
127 2016-04-23T10:16:02  <luke-jr> I don't suppose either of you saved the config.h/log to compare?
128 2016-04-23T10:16:18  <NicolasDorier> I can reproduce one sec
129 2016-04-23T10:18:47  <NicolasDorier> luke-jr:  right now I have the error, what do you want I do to help fixing it ?
130 2016-04-23T10:19:24  <NicolasDorier> (I'm not linux wizard so step by step would be appreciated :p)
131 2016-04-23T10:20:32  <luke-jr> NicolasDorier: ideally, copy the entire bitcoin/ dir somewhere, then re-do it successfully and compare
132 2016-04-23T10:20:43  *** randy-waterhouse has joined #bitcoin-core-dev
133 2016-04-23T10:23:50  <NicolasDorier> k one sec.
134 2016-04-23T10:39:06  <NicolasDorier> mmh, now getting another error after git clean -dfx... but that might be unrelated to the earrlier copyright error as I'm not on master branch right now
135 2016-04-23T10:39:10  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/BO3RdE0Q/
136 2016-04-23T10:39:22  <NicolasDorier> will check out
137 2016-04-23T10:47:22  <NicolasDorier> nevermind was a space in the path
138 2016-04-23T10:47:29  <NicolasDorier> ah no
139 2016-04-23T10:47:37  *** arowser has quit IRC
140 2016-04-23T10:48:01  *** arowser has joined #bitcoin-core-dev
141 2016-04-23T11:04:26  <randy-waterhouse> recent commit 351abf9e035581e3320fbb72ec5b1fa452b09c2f (depends build) introduces following error http://pastebin.com/q5cP70y8 (and core dump) on bitcoin-qt
142 2016-04-23T11:10:22  *** AaronvanW has joined #bitcoin-core-dev
143 2016-04-23T11:14:29  <NicolasDorier> I could not reproduce the 'COPYRIGHT_HOLDERS' error after the first git clean -dfx. It compiled fine :/
144 2016-04-23T11:18:21  *** belcher has joined #bitcoin-core-dev
145 2016-04-23T11:18:23  <btcdrak> usually just a make clean;./autogen.sh solves this for me
146 2016-04-23T11:35:01  *** murch has joined #bitcoin-core-dev
147 2016-04-23T11:39:51  <luke-jr> NicolasDorier: ok, so now you have two dirs to compare, right?
148 2016-04-23T11:40:19  <NicolasDorier> yes. one which compile and the other with the error
149 2016-04-23T11:40:50  <NicolasDorier> but I wanted to replicate the bug wherer git clean -dfx does not solve the copyright error, it happened to me once as well
150 2016-04-23T11:41:44  <luke-jr> NicolasDorier: diff -ur firstdir seconddir >diff
151 2016-04-23T11:41:48  <luke-jr> then pastebin the diff file
152 2016-04-23T11:41:52  <NicolasDorier> ok
153 2016-04-23T11:41:56  <NicolasDorier> one sec
154 2016-04-23T11:45:26  <NicolasDorier> luke-jr it has more than 512kb does not see to be able to copy
155 2016-04-23T11:45:44  <luke-jr> dropbox?
156 2016-04-23T11:46:08  <NicolasDorier> one sec yes I'll find a way
157 2016-04-23T11:47:54  <NicolasDorier> luke-jr: https://aois.blob.core.windows.net/public/diff.txt
158 2016-04-23T11:48:18  <NicolasDorier> I need to run
159 2016-04-23T11:51:48  <NicolasDorier> in the bitcoin folder does not compile bitcoin2 does
160 2016-04-23T11:53:23  <sipa> are you sure the source code is the same across the two?
161 2016-04-23T11:53:34  <sipa> the dependencies are different, which is a bit suspicious
162 2016-04-23T11:55:16  <luke-jr> -rpcserver.h:
163 2016-04-23T11:55:17  <luke-jr> +rpc/server.h:
164 2016-04-23T11:55:19  <luke-jr> definitely not the same..
165 2016-04-23T11:56:10  <sipa> one looks 0.12, the other master
166 2016-04-23T12:30:36  *** jarret has quit IRC
167 2016-04-23T12:36:49  *** laurentmt has joined #bitcoin-core-dev
168 2016-04-23T12:40:57  *** laurentmt has quit IRC
169 2016-04-23T12:44:33  *** randy-waterhouse has quit IRC
170 2016-04-23T12:48:19  *** BashCo has quit IRC
171 2016-04-23T12:53:22  *** airmac has joined #bitcoin-core-dev
172 2016-04-23T12:53:50  <airmac> anyone wanna trade i got 29g of bitgold with trade for bitcoin intrested msg me for trade we can use escrow if you want
173 2016-04-23T12:54:28  <sipa> airmac: not here
174 2016-04-23T12:54:38  <sipa> #bitcoin-otc or similar channels please
175 2016-04-23T13:10:40  *** AaronvanW has quit IRC
176 2016-04-23T13:30:17  *** murch has quit IRC
177 2016-04-23T13:30:34  <nkuttler> sipa: already banned from everywhere
178 2016-04-23T13:31:14  <sipa> nkuttler: ok
179 2016-04-23T13:37:16  *** Thireus has quit IRC
180 2016-04-23T14:00:29  *** frankenmint has quit IRC
181 2016-04-23T14:12:06  *** frankenmint has joined #bitcoin-core-dev
182 2016-04-23T14:22:48  *** AaronvanW has joined #bitcoin-core-dev
183 2016-04-23T14:40:51  *** jarret has joined #bitcoin-core-dev
184 2016-04-23T14:50:55  *** laurentmt has joined #bitcoin-core-dev
185 2016-04-23T14:51:05  *** laurentmt has quit IRC
186 2016-04-23T14:58:00  <airmac> anyone wanna trade i got 29g of bitgold with trade for bitcoin intrested msg me for trade we can use escrow if you want\
187 2016-04-23T14:58:24  <belcher> wrong channel, go to #bitcoin-otc or similar
188 2016-04-23T14:59:16  *** ChanServ sets mode: +o sipa
189 2016-04-23T14:59:26  *** sipa sets mode: +b *!*cheers@168.1.79.*
190 2016-04-23T14:59:27  *** airmac was kicked by sipa (go elsewhere)
191 2016-04-23T15:00:02  *** ChanServ sets mode: -o sipa
192 2016-04-23T15:05:56  *** laurentmt has joined #bitcoin-core-dev
193 2016-04-23T15:20:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
194 2016-04-23T15:23:55  *** TomMc has joined #bitcoin-core-dev
195 2016-04-23T15:59:14  *** BCBot_ has joined #bitcoin-core-dev
196 2016-04-23T16:45:47  *** laurentmt has quit IRC
197 2016-04-23T16:56:10  <Chris_Stewart_5> How is this a valid test case? Shouldn't the 0x00 be pushed onto the stack by just an OP_0?
198 2016-04-23T16:56:13  <Chris_Stewart_5> ["0x01 0x00", "1", "MINIMALDATA"]
199 2016-04-23T16:58:14  <sipa> link?
200 2016-04-23T16:58:30  <sipa> ah, i get it
201 2016-04-23T16:58:50  <sipa> no, OP_0 pushes the empty vector onto the stack, not 0x00
202 2016-04-23T16:59:24  <Chris_Stewart_5> ooo.
203 2016-04-23T16:59:46  <Chris_Stewart_5> Tricky :-)
204 2016-04-23T17:00:59  <Chris_Stewart_5> Is that what this comment is saying? I didn't really understand the comment
205 2016-04-23T17:01:01  <Chris_Stewart_5> ["Numeric minimaldata rules are only applied when a stack item is numerically evaluated; the push itself is allowed"]
206 2016-04-23T17:01:32  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L598
207 2016-04-23T17:03:15  <sipa> yes, that's exactly what it's saying
208 2016-04-23T17:04:09  <sipa> MINIMALDATA includes 2 rules: for every push operation, the shortest possible form must be used 2) whenever a stack element is interpreter as a number, it must be in the shortest possible notation
209 2016-04-23T17:04:28  <sipa> here, 0x00 is pushed onto the stack with a push operation that satisfies 1)
210 2016-04-23T17:04:45  <sipa> 2) is not applicable, because it is not being interpreted as a number
211 2016-04-23T17:08:59  <Chris_Stewart_5> Ok that makes sense. Thanks sipa.
212 2016-04-23T17:47:22  *** molz has quit IRC
213 2016-04-23T17:52:20  *** moli has joined #bitcoin-core-dev
214 2016-04-23T18:17:35  *** Samdney has joined #bitcoin-core-dev
215 2016-04-23T18:54:25  *** molz has joined #bitcoin-core-dev
216 2016-04-23T18:56:58  *** moli has quit IRC
217 2016-04-23T19:20:21  *** supasonic has joined #bitcoin-core-dev
218 2016-04-23T19:25:44  <luke-jr> oops, we released 0.12.1 with no practical way to mine (GBT hasn't been updated for BIP 9) :x
219 2016-04-23T19:25:57  <luke-jr> well, practical and correct I guess
220 2016-04-23T19:26:29  <luke-jr> should I de-bundle BIP 9 GBT stuff from segwit, or just figure wait for that?
221 2016-04-23T19:32:03  <luke-jr> not sure there's a way to support 0.12.1 properly, so basically means the softfork "needs" to be delayed?
222 2016-04-23T19:32:15  *** JackH has joined #bitcoin-core-dev
223 2016-04-23T19:32:34  <sipa> how do you mean?
224 2016-04-23T19:32:43  <sipa> it's already being used by miners
225 2016-04-23T19:32:57  <luke-jr> sipa: there's no way for GBT clients to know what the rules are
226 2016-04-23T19:33:22  <sipa> there's no need for that if they're connecting to a trusted bitcoind
227 2016-04-23T19:33:42  <luke-jr> GBT requires it
228 2016-04-23T19:34:04  <luke-jr> since it could very well be needed
229 2016-04-23T19:34:24  <luke-jr> eg, with segwit the handling of txid/hash
230 2016-04-23T19:34:52  <sipa> so let's say there is a softfork that adds UTXO commitments
231 2016-04-23T19:35:08  <sipa> what you going to do? provide the entire utxo set in the GBT response?
232 2016-04-23T19:35:10  <luke-jr> I could hack libblkmaker to understand that the new "version" can be treated as the previous ones, but this will break as soon as that bit is reused
233 2016-04-23T19:35:20  <sipa> your view of reality is a dream
234 2016-04-23T19:35:32  <sipa> GBT is not being used the way you envision it
235 2016-04-23T19:35:46  <luke-jr> in such a case, the GBT client needs to be aware the commitment is required and where
236 2016-04-23T19:36:01  <luke-jr> so it can place the commitment from the local bitcoind in the right part of the block
237 2016-04-23T19:36:32  <sipa> or it could just not bother, and use a full node to construct the block proposals, which is in a much better position to do so, and already knows everything necessary (apart from coinbase outputs)
238 2016-04-23T19:36:36  <luke-jr> sipa: I wouldn't have even noticed this if it wasn't.
239 2016-04-23T19:36:53  <sipa> but no need to have thing discussion again
240 2016-04-23T19:37:22  <sipa> i'm fine with reporting what bip9 deployments are active and available in GBT
241 2016-04-23T19:37:37  <sipa> but please don't go claim that it's not possible to mine without
242 2016-04-23T19:37:49  *** Thireus has joined #bitcoin-core-dev
243 2016-04-23T19:37:50  <sipa> there is no real world mining now that needs such information
244 2016-04-23T19:37:55  <luke-jr> per spec, GBT clients cannot work with 0.12.1 as-is today.
245 2016-04-23T19:38:06  <luke-jr> and de facto miners implementing it do not work with it
246 2016-04-23T19:39:04  <sipa> why not? all deployed GBT clients in the world work fine with it
247 2016-04-23T19:39:06  <luke-jr> I'm just trying to find a clean way to fix this real-world problem miners are encountering
248 2016-04-23T19:39:09  <luke-jr> nope
249 2016-04-23T19:39:14  <sipa> how so?
250 2016-04-23T19:39:31  <luke-jr> the version field is unrecognised, so they throw an error
251 2016-04-23T19:40:55  <sipa> how do you mean?
252 2016-04-23T19:41:38  <luke-jr> https://github.com/bitcoin/libblkmaker/blob/master/blkmaker_jansson.c#L273
253 2016-04-23T19:42:26  <sipa> ok, so the software needs to be updated
254 2016-04-23T19:43:09  <sipa> i see what you're saying
255 2016-04-23T19:43:26  *** frankenmint has quit IRC
256 2016-04-23T19:43:48  <sipa> though i think most gbt clients just pass through the version field, and they would be fine, because bitcoind's block template always corresponds to a valid block
257 2016-04-23T19:44:17  <luke-jr> those would be fine now (albeit not per spec), but they'll break worse with segwit
258 2016-04-23T19:44:43  <luke-jr> I suppose libblkmaker can treat the case of (currentsoftforkversion && !bip9)
259 2016-04-23T19:44:59  <luke-jr> as long as the next softfork uses BIP9 GBT changes, that would protect against bit reuse
260 2016-04-23T19:45:18  <sipa> i think it may be best to disentangle the segwit changes from bip9 changes to gbt
261 2016-04-23T19:45:18  <luke-jr> does that sound reasonable?
262 2016-04-23T19:45:31  <luke-jr> ok
263 2016-04-23T19:46:11  <luke-jr> so today I will focus/prioritise 1) finish revising GBT BIP changes, 2) split BIP9 GBT code from segwit, 3) update libblkmaker to detect 0.12.1 situation
264 2016-04-23T19:47:50  <sipa> so i think we at least agreed that gbt should report the list of currently active rules, probably by name
265 2016-04-23T19:48:10  <sipa> (trying to remember the discussion we had before)
266 2016-04-23T19:49:26  <luke-jr> version: bits the server likes you to set, vbavailable: {name:bit} mapping array the server allows you to set, vbrequired: bits the server demands you to set
267 2016-04-23T19:49:47  <sipa> apart from that there were two other functions: 1) policy about which bits the server allows you to set/not set, and a suggestion 3) providing information about linkage between available bits and the deployment they correspond to
268 2016-04-23T19:50:25  <sipa> i'm a bit unconfortable with the last thing, as it's only useful in the case the client trusts the server
269 2016-04-23T19:51:13  <luke-jr> so libblkmaker will have a special case for 0x20000000 && !vbavailable, to handle 0.12.1 correctly
270 2016-04-23T19:51:34  <sipa> how will you deal with 0x20000001?
271 2016-04-23T19:52:35  <luke-jr> hm, I'm confused
272 2016-04-23T19:52:49  <luke-jr> I pulled 0x20000000 out of a recent block to be lazy, but that indicates no softforks, doesn't it? :x
273 2016-04-23T19:53:59  <luke-jr> oh, the begin time..
274 2016-04-23T19:54:23  <sipa> yes, after may 1st it will set 0x20000001
275 2016-04-23T19:54:49  <luke-jr> so I need to check for & 0xFFFFFFFE == 0x20000000
276 2016-04-23T19:55:21  <sipa> cfields: ^ relevant discussion
277 2016-04-23T19:56:32  <luke-jr> sipa: re vbrequired: the server can always reject submissions that clear bits it insists on, so this merely informs clients in advance so they can choose not to use that server
278 2016-04-23T20:02:34  <sipa> luke-jr: right, no problem with saying "these bits you must set, and these you may set"
279 2016-04-23T20:03:34  <sipa> i'm unconvinced about providing information about what bits corresponds with whicj deployment, as that is ourely informational with nonrelevance to what answers are acceptable
280 2016-04-23T20:03:53  <sipa> *which *purely
281 2016-04-23T20:04:01  <sipa> *no relevance
282 2016-04-23T20:04:52  <luke-jr> in the sense that you wish to discuss it further before proceeding that direction, or just a comment?
283 2016-04-23T20:05:06  <sipa> like, we also don't provide information about what the coinbase maturity is, while it could just as easily change in a softfork
284 2016-04-23T20:05:45  <luke-jr> things like that are why GBT says clients shouldn't make assumptions about block versions they don't understand ;)
285 2016-04-23T20:05:50  <sipa> my point is that this mapping information is going beyond the scope of the GBT call, and if clients which tovparticipate in voting, well, then they are responsible for knowing what means what
286 2016-04-23T20:06:03  <sipa> *wish to participate
287 2016-04-23T20:06:12  <luke-jr> "what means what" depends on blockchain context they lack
288 2016-04-23T20:06:30  <sipa> nno, it does not
289 2016-04-23T20:06:34  <sipa> it's in the bips
290 2016-04-23T20:06:54  <sipa> ah, there is one piece of context information they lack
291 2016-04-23T20:06:59  <sipa> mediantimepast
292 2016-04-23T20:08:08  <luke-jr> also testnet vs mainnet, but that's admittedly less important
293 2016-04-23T20:08:30  <sipa> i see
294 2016-04-23T20:08:41  <luke-jr> possibly becomes important if we try to use GBT for sidechains (but I'm not convinced that makes sense)
295 2016-04-23T20:08:58  *** Thireus has quit IRC
296 2016-04-23T20:10:26  *** frankenmint has joined #bitcoin-core-dev
297 2016-04-23T20:16:33  *** frankenmint has quit IRC
298 2016-04-23T20:23:22  <luke-jr> ok, step 1 done I hope: https://github.com/bitcoin/bips/pull/365
299 2016-04-23T20:25:28  *** zlover has joined #bitcoin-core-dev
300 2016-04-23T20:27:24  <btcdrak> luke-jr: your changes dont render properly https://i.imgur.com/Qmwqh0k.png
301 2016-04-23T20:27:39  *** Guyver2 has joined #bitcoin-core-dev
302 2016-04-23T20:29:33  <instagibbs> sipa, "Otherwise, going from WITNESS->P2SH+WITNESS would be possible, which is not a softfork." I don't grok this. Could you briefly explain it?
303 2016-04-23T20:30:00  <luke-jr> btcdrak: looks like none of the GBT stuff does, due to GitHub migration
304 2016-04-23T20:31:22  <luke-jr> https://help.github.com/articles/supported-mediawiki-formats/#unsupported-mediawiki-syntaxes :/
305 2016-04-23T20:33:12  <luke-jr> btcdrak: fixed by avoiding the templates
306 2016-04-23T20:35:17  *** Thireus has joined #bitcoin-core-dev
307 2016-04-23T21:04:29  <sipa> instagibbs: say you have a normal P2SH (not witness) output being spent
308 2016-04-23T21:04:48  <sipa> oh, no
309 2016-04-23T21:05:52  <sipa> instagibbs: say you have an invalid witness-in-p2sh spending
310 2016-04-23T21:06:42  <sipa> with just witness enabled, that's valid
311 2016-04-23T21:07:05  <instagibbs> wait what, is it invalid or invalid?
312 2016-04-23T21:07:11  *** arubi has joined #bitcoin-core-dev
313 2016-04-23T21:07:18  <instagibbs> err valid
314 2016-04-23T21:08:42  <sipa> say you have a p2sh output, and a corresponding input to spend it, which provides redeemscript which is a witness script, and then witness program that corresponds to it, but is invalid (say it's  wrong signature)
315 2016-04-23T21:09:31  <kanzure> why would enabling witness make that valid?
316 2016-04-23T21:09:45  <kanzure> wrong signatures should always be wrong
317 2016-04-23T21:10:07  <sipa> if you evaluate that with WITNESS, it is valid, because it's a p2sh outout, which is an anyone can spend
318 2016-04-23T21:11:00  <sipa> if you evaluate with WITNESS+P2SH, the P2SH evaluation happens, which triggers the witness logic, which is invalid
319 2016-04-23T21:11:03  <sipa> eh
320 2016-04-23T21:11:15  <sipa> that's all true, but not the reason why it's not a softfork
321 2016-04-23T21:11:54  <kanzure> oops just checked context. didn't see the question re: the comment. nevermind.
322 2016-04-23T21:15:28  <instagibbs> "say you have a p2sh output" are you saying this is a p2wsh or something similar
323 2016-04-23T21:15:56  <instagibbs> or just a plain p2sh like today
324 2016-04-23T21:16:50  <instagibbs> oh i see
325 2016-04-23T21:18:31  <instagibbs> I'm not quite getting the comment then, although I agree with what you're saying here
326 2016-04-23T21:19:51  <sipa> let me think again
327 2016-04-23T21:20:07  <instagibbs> it sounds like you're saying SOFTFORK1 this is valid, then adding SOFTFORK2 it's now invalid
328 2016-04-23T21:20:13  <instagibbs> which is def of softfork?
329 2016-04-23T21:20:47  <sipa> there is a similar rule for cleanstack, and that one i can explain
330 2016-04-23T21:21:33  <sipa> no, the problem is that when validation with  flags1 fails, but with flags1+flags2 succeeds, then it is not a aoftfork
331 2016-04-23T21:21:36  <sipa> and all flags should be softforks
332 2016-04-23T21:22:40  <sipa> mempool validations relies on that
333 2016-04-23T21:24:07  <instagibbs> I'm clearly missing something important here.
334 2016-04-23T21:24:26  <instagibbs> probably what the flag semantics are or something
335 2016-04-23T21:25:43  *** achow101 has joined #bitcoin-core-dev
336 2016-04-23T21:27:35  <instagibbs> oh... it's just talking about the actual implementation and program flow...
337 2016-04-23T21:27:52  * instagibbs smacks forehead 
338 2016-04-23T21:27:53  <sipa>  so, for ok, for WWITNESS and CLEANSTACK
339 2016-04-23T21:28:29  <sipa> any witness spend would fail CLEANSTACK validation
340 2016-04-23T21:28:38  <sipa> because it is just pushes
341 2016-04-23T21:28:52  <sipa> so it clearly does not satisfy CLEANSTACK
342 2016-04-23T21:29:18  <instagibbs> I misunderstood the comment, as I thought
343 2016-04-23T21:29:25  <sipa> unless when WITNESS is enabled, then we ignore the CLEANSTACK rule
344 2016-04-23T21:29:45  <sipa> thus, a change in flags from CLEANSTACK to CLEANSTACK+WITNESS is not a softfork
345 2016-04-23T21:29:49  <instagibbs> I read it as "BIP141 by itself is somehow a hardfork"
346 2016-04-23T21:29:57  <sipa> oh, no
347 2016-04-23T21:30:02  <instagibbs> totally get it now
348 2016-04-23T21:30:28  <sipa> we just make CLEANSTACK without WITNESS invalid, so such a change can never occur
349 2016-04-23T21:30:31  <sipa> ok!
350 2016-04-23T21:30:47  <luke-jr> sipa: does BIP68+112+113 have a VB name?
351 2016-04-23T21:30:57  <sipa> luke-jr: csv
352 2016-04-23T21:31:00  <luke-jr> k
353 2016-04-23T21:32:48  <instagibbs> thanks for the explanation!
354 2016-04-23T21:33:35  <luke-jr> sipa: am I correct in understanding that the block time itself is entirely unrelated to the meaning of bits?
355 2016-04-23T21:33:48  *** achow101 has quit IRC
356 2016-04-23T21:34:49  *** achow101 has joined #bitcoin-core-dev
357 2016-04-23T21:40:53  <sipa> luke-jr: the rules that apply to a block are purely a function of its ancestor block header
358 2016-04-23T21:40:54  *** phantomcircuit has quit IRC
359 2016-04-23T21:41:10  <sipa> not of its own timestamp or version
360 2016-04-23T21:41:11  *** phantomcircuit has joined #bitcoin-core-dev
361 2016-04-23T21:44:06  <luke-jr> k
362 2016-04-23T21:51:32  <luke-jr> wtf does this GCC thing mean: http://codepad.org/BfJgyPwQ :/
363 2016-04-23T21:53:47  <gmaxwell> luke-jr: it's pointing out that you should use MAX_VERSION_BITS_DEPLOYMENTS instead of MAX_VERSION_BITS_DEPLOYMENTS.
364 2016-04-23T21:54:05  <luke-jr> am I blind or something? those look the same to me :|
365 2016-04-23T21:54:22  *** Guyver2 has quit IRC
366 2016-04-23T21:54:49  <sipa> different namespace?
367 2016-04-23T21:55:03  <luke-jr> aha that could be it
368 2016-04-23T21:55:32  <luke-jr> yup
369 2016-04-23T21:55:33  <luke-jr> thanks
370 2016-04-23T22:09:39  <Lightsword> luke-jr, why not version GBT separately from the block version?
371 2016-04-23T22:10:19  <luke-jr> Lightsword: it doesn't make sense to do so
372 2016-04-23T22:11:39  <Lightsword> most of the time soft forks don’t require mining software changes though, so it would be a good way to signal that mining software needs to be upgraded
373 2016-04-23T22:12:03  *** Don_John has joined #bitcoin-core-dev
374 2016-04-23T22:12:39  <Lightsword> and in general mining software has no reason to care about the rules being enforced on the network since it assumes the template is valid anyways
375 2016-04-23T22:13:02  <luke-jr> Lightsword: well, previously, GBT had the version/force mutation for that, but nobody ever considered it worth using
376 2016-04-23T22:13:49  <Lightsword> luke-jr, so the mining software could actually enforce soft fork rules different from bitcoind?
377 2016-04-23T22:13:56  <luke-jr> the new BIP 9 stuff doesn't really break that either
378 2016-04-23T22:14:01  <luke-jr> Lightsword: ?
379 2016-04-23T22:14:15  <Lightsword> what is the purpose of version/force mutation?
380 2016-04-23T22:14:40  <luke-jr> Lightsword: tells clients to use the provided version despite their ignorance of its meaning
381 2016-04-23T22:15:10  <luke-jr> so the server could look at what the client supports (in the GBT request), and decide it was close enough
382 2016-04-23T22:15:34  <Lightsword> oh, is that for GBT pooled mining?
383 2016-04-23T22:17:23  <luke-jr> mutations are defined in BIP 23, yes, but GBT itself has no distinction between pools and bitcoind
384 2016-04-23T22:23:17  <Lightsword> luke-jr, so that would allow say embedded GBT clients to mine on a pool without support for segwit or only soft forks that have no GBT format changes like CSV?
385 2016-04-23T22:23:50  <sipa> Lightsword: the choice that miner clients have is choosing to vote for a deployment or not
386 2016-04-23T22:24:01  <sipa> not about rules that are actually enforced
387 2016-04-23T22:24:10  <luke-jr> Lightsword: there is no way to support segwit in GBT clients unless the GBT client is aware of the segwit changes.
388 2016-04-23T22:24:15  <sipa> those are set by the full node/server that has to accept them
389 2016-04-23T22:27:04  <Lightsword> so the miners connecting to the pool would be able to modify their block version number to whatever they want?
390 2016-04-23T22:27:24  <sipa> if the server supports it
391 2016-04-23T22:27:52  *** zlover has quit IRC
392 2016-04-23T22:29:38  <luke-jr> Lightsword: see https://github.com/bitcoin/bips/pull/365
393 2016-04-23T22:29:40  <Lightsword> ok, well from a practical point of view why wouldn’t it make sense for GBT to be versioned separately from the block version so that mining clients can easially determine if they have to upgrade or if they can just use the provided block version as is?
394 2016-04-23T22:30:40  <luke-jr> Lightsword: because that's not a simple boolean question, and provides no benefits over how GBT presently supports it
395 2016-04-23T22:31:18  <luke-jr> the CSV deployment *could* have used version/force for old GBT clients, but it did not.
396 2016-04-23T22:32:57  <Lightsword> I’m confused on what the purpose of the “name” field is, if miners have to be updated to recognize it why can’t they just decode the provided block version number and infer it themselves?
397 2016-04-23T22:33:30  *** aquentson has quit IRC
398 2016-04-23T22:34:11  <luke-jr> the block version number indicates the pending proposals, not the ones in effect
399 2016-04-23T22:35:34  <Lightsword> why would the mining software need to care about that specifically as opposed to just caring about whether it broke compatibility?
400 2016-04-23T22:37:34  *** achow101 has quit IRC
401 2016-04-23T22:37:47  <luke-jr> Lightsword: compatibility is only guaranteed with the known rules
402 2016-04-23T22:38:46  <Lightsword> luke-jr, but most soft fork rules are enforced by bitcoind by just not including transactions in the template, so in thsoe cases the GBT version would not need to be changed
403 2016-04-23T22:41:24  <Lightsword> am I missing something here? I don’t see why the GBT client would need to care about those types of rule changes since they are enforced by bitcoind simply excluding invalid transactions
404 2016-04-23T22:43:11  <luke-jr> Lightsword: eg, when the transactions and generation tx come from different servers
405 2016-04-23T22:48:17  <Lightsword> luke-jr, wouldn’t both of those be versioned? are you talking about a GBT client mining off of two different GBT sources at once?
406 2016-04-23T22:48:26  <luke-jr> yes
407 2016-04-23T22:49:13  <Lightsword> so wouldn’t the client be able to recognize that the GBT version from the transactions server and generation tx server are different?
408 2016-04-23T22:50:20  <luke-jr> …
409 2016-04-23T22:50:29  <luke-jr> you're suggesting they be the same
410 2016-04-23T22:52:55  <Lightsword> luke-jr, have previous soft forks restricted generation transaction validity?
411 2016-04-23T22:53:28  *** molz has quit IRC
412 2016-04-23T22:53:29  *** moli has joined #bitcoin-core-dev
413 2016-04-23T22:53:41  <sipa> Lightsword: by definition, all of them
414 2016-04-23T22:53:51  <sipa> ah, generation transaction, sorry
415 2016-04-23T22:54:09  <sipa> bip30 and bip34
416 2016-04-23T22:54:38  <luke-jr> ^
417 2016-04-23T22:55:23  <sipa> and bip141
418 2016-04-23T22:55:35  <Lightsword> ok, but some don’t as well right?
419 2016-04-23T22:56:01  <Lightsword> like CSV and BIP66?
420 2016-04-23T22:57:04  <luke-jr> Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
421 2016-04-23T22:58:03  *** achow101 has joined #bitcoin-core-dev
422 2016-04-23T22:58:40  <Lightsword> basically what I’m thinking is that we should have a GBT version indicator that should change to signal to the miner that additional rules need to be enforced, but only for rules that aren’t simply enforced by the excluding the transaction from the template
423 2016-04-23T22:59:00  *** pmienk has quit IRC
424 2016-04-23T23:00:14  <Lightsword> since the mining client doesn’t really need to care about a rule that is enforced simply by exclusion of a transaction
425 2016-04-23T23:00:35  <luke-jr> it might
426 2016-04-23T23:01:48  <Lightsword> in what sort of situation would that be?
427 2016-04-23T23:02:07  <luke-jr> [22:57:03] <luke-jr> Lightsword: GBT code exists which will merge transaction sets from multiple servers as well, if we want to get pedantic
428 2016-04-23T23:03:04  <Lightsword> does anybody actually do that?
429 2016-04-23T23:03:26  <luke-jr> dunno, doubt it
430 2016-04-23T23:03:58  <Lightsword> I mean, merging transactions means you have to support a lot of consensus logic within the mining software itself
431 2016-04-23T23:04:06  <luke-jr> not much
432 2016-04-23T23:05:18  <sipa> it also means you probably want a GBT that reports the entire mempool (or part of it), instead of something already tailored for a single block
433 2016-04-23T23:06:48  <luke-jr> perhaps a "rules/force" mutation would make sense
434 2016-04-23T23:06:54  *** laurentmt has joined #bitcoin-core-dev
435 2016-04-23T23:07:10  <luke-jr> then the server can evaluate if the client's supported rules are sufficient and override that check
436 2016-04-23T23:07:17  <Lightsword> since most mining software wouldn’t have the neccesary consensus logic to actually handle merging to begin with I would say it would be best to ignore that case for having a GBT version
437 2016-04-23T23:08:26  <Lightsword> basically the issue right now is we don’t have a way to signal when mining software needs to upgrade or even likely needs to upgrade, at least for the most recent soft forks
438 2016-04-23T23:08:50  <luke-jr> "version" did that pre-BIP9, and "rules" does it with BIP 9
439 2016-04-23T23:08:57  *** laurentmt has quit IRC
440 2016-04-23T23:10:40  *** pmienk has joined #bitcoin-core-dev
441 2016-04-23T23:10:58  <Lightsword> if the signaling method gets false positives on telling the mining software that it needs to upgrade then people will ignore those rules, the problem with using rules the way you have it right now is that fairly often the miner doesn’t actually care about the rules since it’s simply enforced by exclusion of transactions
442 2016-04-23T23:11:02  *** Thireus has joined #bitcoin-core-dev
443 2016-04-23T23:12:16  <Lightsword> IMO we need a way to signal to the miner that they need to enforce a rule that is not simply enforced by transaction exclusion otherwise miners will outright ignore rules all together
444 2016-04-23T23:12:33  <luke-jr> at their own risk
445 2016-04-23T23:13:57  <Lightsword> well if we have a soft fork that we know is enforced by transaction exclusion we should have a way to tell the mining client that they are ok as long as they are only including the transaction provided in the template
446 2016-04-23T23:14:11  <luke-jr> ok, that'd be a "rules/force" mutation..
447 2016-04-23T23:15:05  <sipa> luke-jr: ext filesystems have an extension mechanism that lists the enabled extensions in an FS in 3 classes 1) if you don't know about this, you're fine 2) if you don't know about this, you can only mount ro 3) if you don't know this, you can't mount
448 2016-04-23T23:15:23  <sipa> luke-jr: perhaps the active rules can use a similar classification
449 2016-04-23T23:16:16  <Lightsword> I’m confused on how mutable actually works
450 2016-04-23T23:16:30  * sipa doubts anyone uses mutable at all in GBT
451 2016-04-23T23:17:06  <luke-jr> server-side, mutable is typically static in practice, but the server could evaluate the client's capabilities and set a rules/force to tell them they're okay
452 2016-04-23T23:17:43  <sipa> i think you're overdesigning it, trying to cater to every possible use, without any real world demand
453 2016-04-23T23:17:44  <luke-jr> client-side, it tells the client what they're allowed to do with the template
454 2016-04-23T23:18:00  <luke-jr> sipa: yes, GBT is overdesigned and should be thrown out, but first we'd need a new protocol
455 2016-04-23T23:18:08  <Lightsword> well in practical sense bitcoind is the server and the stratum server is the client
456 2016-04-23T23:18:22  <luke-jr> Lightsword: you're only thinking about your one use case.
457 2016-04-23T23:18:34  <Lightsword> the use case that basically the entire network runs on though :P
458 2016-04-23T23:18:36  <sipa> the only one that matters
459 2016-04-23T23:18:39  <luke-jr> …
460 2016-04-23T23:18:48  <luke-jr> except the miners who don't.
461 2016-04-23T23:19:04  <Lightsword> which is almost certainly well below 1% of the network
462 2016-04-23T23:19:45  <Lightsword> hell, even eligius doesn’t allow GBT mining :P
463 2016-04-23T23:19:49  <luke-jr> so let's favour the centralised miners abusing their position, at the expense of the 1% who actually care to solo mine?
464 2016-04-23T23:19:53  <luke-jr> Lightsword: yes it does
465 2016-04-23T23:20:05  <Lightsword> it just redirects to stratum last I checked
466 2016-04-23T23:20:11  <luke-jr> you can disable the redirection
467 2016-04-23T23:20:32  <Lightsword> does anybody actually do that?
468 2016-04-23T23:20:42  <luke-jr> no idea, ask wizkid057
469 2016-04-23T23:21:36  <Lightsword> ok, well IMO it’s better to design a signaling method that’s actually going to be useful in practice rather than just getting ignored like it is right now
470 2016-04-23T23:22:13  <luke-jr> anyone know what testnet blocks made csv change states?
471 2016-04-23T23:22:36  <Lightsword> huh? i didn’t know it changed status
472 2016-04-23T23:22:45  <midnightmagic> Much of that ignored stance comes from the undeserved reputational damage that luke's suffered over the years, and the deliberate work that's gone *specifically* into being contrarian.
473 2016-04-23T23:23:36  <midnightmagic> like, re-written and re-designed *as a specific and incompatible alternative* to things like GBT.
474 2016-04-23T23:23:49  <luke-jr> Lightsword: splitting the rules list up like sipa suggested sounds like a possible approach, but would require approximately the same code to implement as rules/force would
475 2016-04-23T23:24:06  <sipa> not sure what you mean by rules/force
476 2016-04-23T23:24:32  <luke-jr> sipa: server evaluates the client's supported rules, and tells it that it can safely ignore the rules it doesn't know
477 2016-04-23T23:24:34  <Lightsword> midnightmagic, to be fair GBT is pretty much impractical for pooled mining
478 2016-04-23T23:24:45  * midnightmagic shrugs.
479 2016-04-23T23:25:04  <midnightmagic> And instead of making GBT better or including it in a superset, people did other things.
480 2016-04-23T23:25:45  <phantomcircuit> luke-jr, i'm some large % of testnet and running 73fc922ed64333d45f18d8a448f30cfa2ae0281e
481 2016-04-23T23:25:47  <luke-jr> midnightmagic: meh, GBT is fundamentally incompatible with sidechains, so it needs to be replaced anyway
482 2016-04-23T23:26:02  <luke-jr> phantomcircuit: ?
483 2016-04-23T23:26:13  <Lightsword> midnightmagic, well that’s what happens when something doesn’t fit people’s needs and redesigning it is easier than trying to fix it
484 2016-04-23T23:26:24  <phantomcircuit> you asked about testnet and csv; i did not answer your question but did provide additional information
485 2016-04-23T23:26:42  <luke-jr> phantomcircuit: I don't see an answer to my question >_
486 2016-04-23T23:26:43  <luke-jr> >_<
487 2016-04-23T23:26:50  *** Chris_Stewart_5 has quit IRC
488 2016-04-23T23:27:18  <phantomcircuit> luke-jr, i'm so helpful right
489 2016-04-23T23:27:21  *** AaronvanW has quit IRC
490 2016-04-23T23:27:25  <gmaxwell> Lightsword: consider what you're saying, that it's impratical to send the miner the block they're working on, once per block?  This should be setting off red alarm bells for you.
491 2016-04-23T23:27:51  <phantomcircuit> gmaxwell, i think you need more specific nouns
492 2016-04-23T23:28:06  <Lightsword> gmaxwell, when a “miner” is a server farm with 10k miners all directly connected to a pool…it’s going to be a problem in most cases
493 2016-04-23T23:28:10  <phantomcircuit> (actually i think this entire conversation needs more specific nouns)
494 2016-04-23T23:28:27  <Lightsword> even if the block size is 50k
495 2016-04-23T23:30:08  <Lightsword> it’s really a matter of what can send out the block update faster, miners aren’t likely to give up profit margin unless they have a really good reason to
496 2016-04-23T23:30:10  <gmaxwell> Lightsword: GBT isn't a protocol for dispatching to random hardware. But at the same time having 50k tcp connections from devices at one site to a pool makes no sense either.
497 2016-04-23T23:30:15  <phantomcircuit> gmaxwell, (switching topics) i'm finding the afl hang detection to be pretty annoying, it refuses to start a new run if a test case is even 1ms above the hang threshold... which means moving tests between a server and my laptop results in having to purge a bunch of tests (the server being much faster than my laptop)
498 2016-04-23T23:30:18  <phantomcircuit> any suggestion?
499 2016-04-23T23:30:19  *** achow101 has quit IRC
500 2016-04-23T23:30:41  <gmaxwell> phantomcircuit: up your threshold on the laptop.
501 2016-04-23T23:30:56  <Lightsword> gmaxwell, well that’s the reason stratum happened, because it was desgined for dispatching to random hardware more or less :P
502 2016-04-23T23:31:26  <gmaxwell> No, it's a crappy protocol for that too.
503 2016-04-23T23:31:26  <phantomcircuit> gmaxwell, it would be nice if it counted instructions instead but i assume that would be both harder and more expensive?
504 2016-04-23T23:31:39  <phantomcircuit> i thought x86 systems had performance counters that could efficiently do that though
505 2016-04-23T23:31:44  *** bitcoinfr has joined #bitcoin-core-dev
506 2016-04-23T23:31:52  <sipa> phantomcircuit: rdtsc
507 2016-04-23T23:32:02  <Lightsword> gmaxwell, sure but it was better than GBT for that and there wasn’t an alternative people could choose
508 2016-04-23T23:32:06  <sipa> doesn't count instructions, just clock cycles
509 2016-04-23T23:32:16  <bitcoinfr> .
510 2016-04-23T23:32:30  <phantomcircuit> sipa, that seems better actually
511 2016-04-23T23:32:41  <midnightmagic> Lightsword: they explicitly ignored most of the feedback about their new design, and in at least one case, it was done in a *trivially exploitable way.*
512 2016-04-23T23:33:03  <luke-jr> and made no effort to collaborate with others already working on GBT
513 2016-04-23T23:33:11  <luke-jr> but that's history, and irrelevant to what we do in BIP 9
514 2016-04-23T23:33:18  *** bitcoinfr has quit IRC
515 2016-04-23T23:33:30  <luke-jr> which is something that needs to get wrapped up sooner rather than later so solo mining is practical again
516 2016-04-23T23:33:34  <gmaxwell> Lightsword: You're suffering history rewrite in terms of the current state of the world, back when these protocols were created the world was very different than now.
517 2016-04-23T23:33:44  *** achow101 has joined #bitcoin-core-dev
518 2016-04-23T23:35:41  <Lightsword> was there much effort on either side to collaborate? at the time I thought luke was just arguing something along the lines of you shouldn’t use stratum you should use GBT instead
519 2016-04-23T23:38:57  <luke-jr> Lightsword: GBT was developed and revised over the course of a year or two, before stratum was even mentioned publicly
520 2016-04-23T23:39:15  <luke-jr> developed openly, with collaboration from multiple people
521 2016-04-23T23:53:38  <midnightmagic> yes, lots of attempts at collaboration and unification.
522 2016-04-23T23:57:59  <luke-jr> why does BOOST_FOREACH not work on UniValues? :<