12016-04-23T00:00:09  *** arowser has quit IRC
  22016-04-23T00:00:45  *** arowser has joined #bitcoin-core-dev
  32016-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
  42016-04-23T00:21:09  *** frankenmint has joined #bitcoin-core-dev
  52016-04-23T00:43:00  *** Ylbam has quit IRC
  62016-04-23T00:53:11  *** belcher has quit IRC
  72016-04-23T01:04:09  *** mrkent_ has quit IRC
  82016-04-23T01:12:32  *** Kexkey has quit IRC
  92016-04-23T01:34:02  *** Alopex has quit IRC
 102016-04-23T01:34:44  *** ebfull has joined #bitcoin-core-dev
 112016-04-23T01:34:55  *** ebfull has quit IRC
 122016-04-23T01:35:07  *** Alopex has joined #bitcoin-core-dev
 132016-04-23T01:48:04  *** Chris_Stewart_5 has quit IRC
 142016-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...
 152016-04-23T01:58:15  <gmaxwell> the improvement from this for propagation of dependant transactions is really substantial, and I'd rather not delay it.
 162016-04-23T02:16:04  *** river__ has joined #bitcoin-core-dev
 172016-04-23T02:36:19  *** laurentmt has joined #bitcoin-core-dev
 182016-04-23T02:39:20  *** laurentmt has quit IRC
 192016-04-23T02:51:01  *** Alopex has quit IRC
 202016-04-23T02:52:06  *** Alopex has joined #bitcoin-core-dev
 212016-04-23T03:19:01  *** Alopex has quit IRC
 222016-04-23T03:19:25  *** frankenmint has quit IRC
 232016-04-23T03:20:06  *** Alopex has joined #bitcoin-core-dev
 242016-04-23T03:31:32  *** zooko has quit IRC
 252016-04-23T03:33:02  *** frankenmint has joined #bitcoin-core-dev
 262016-04-23T03:35:01  *** Alopex has quit IRC
 272016-04-23T03:36:07  *** Alopex has joined #bitcoin-core-dev
 282016-04-23T03:58:02  *** frankenmint has quit IRC
 292016-04-23T04:20:07  *** river__ has quit IRC
 302016-04-23T04:21:25  *** p15x has joined #bitcoin-core-dev
 312016-04-23T05:02:16  *** frankenmint has joined #bitcoin-core-dev
 322016-04-23T05:06:01  *** Alopex has quit IRC
 332016-04-23T05:07:06  *** Alopex has joined #bitcoin-core-dev
 342016-04-23T05:17:04  *** grassass has joined #bitcoin-core-dev
 352016-04-23T05:23:40  *** arowser has quit IRC
 362016-04-23T05:24:09  *** arowser has joined #bitcoin-core-dev
 372016-04-23T05:44:15  <phantomcircuit> wumpus, currently have fuzzing of CDataStream >> CBlock working
 382016-04-23T05:44:44  <wumpus> great!
 392016-04-23T05:45:03  <phantomcircuit> i figured that would exercise the most of the serialization stuff in one go
 402016-04-23T05:45:55  <phantomcircuit> also discovered that combining std::copy with violation of the strict aliasing rule is a bad idea
 412016-04-23T05:46:03  <phantomcircuit> (on the latest gcc at least)
 422016-04-23T05:46:39  <gmaxwell> violating aliasing rules is always a bad idea. :)
 432016-04-23T05:47:06  *** dermoth_ has quit IRC
 442016-04-23T05:50:53  <phantomcircuit> gmaxwell, i wasn't expecting it to violate the rule though
 452016-04-23T05:51:23  <phantomcircuit> (and there's no warning about it)
 462016-04-23T05:51:29  <phantomcircuit> ie thought it was char*
 472016-04-23T05:51:42  <gmaxwell> ah, no you were copying a vector, no?
 482016-04-23T05:52:02  <phantomcircuit> copying from std::vector<char> to uint32_t*
 492016-04-23T05:52:14  <gmaxwell> yea... not quite. :)
 502016-04-23T05:52:17  <gmaxwell> Have you tried introducing a bug and verifying that it finds it?
 512016-04-23T05:52:41  <phantomcircuit> currently im trying to identify which exceptions i should catch as "that's expected"
 522016-04-23T06:06:23  <phantomcircuit> gmaxwell, huh memcpy is void*
 532016-04-23T06:06:34  <phantomcircuit> i guess this is *also* violating sa
 542016-04-23T06:11:11  <phantomcircuit> it seems like catching std::ios_base::failure is enough
 552016-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.
 562016-04-23T06:12:46  <phantomcircuit> gmaxwell, i wonder if glibc memcpy is char* internally or not
 572016-04-23T06:13:33  *** arowser has quit IRC
 582016-04-23T06:13:58  *** arowser has joined #bitcoin-core-dev
 592016-04-23T06:22:33  <sipa> phantomcircuit: i assume it's written in asm :)
 602016-04-23T06:22:53  <gmaxwell> "lol"
 612016-04-23T06:32:54  *** frankenmint has quit IRC
 622016-04-23T06:33:02  *** Alopex has quit IRC
 632016-04-23T06:34:07  *** Alopex has joined #bitcoin-core-dev
 642016-04-23T06:49:01  *** Alopex has quit IRC
 652016-04-23T06:50:07  *** Alopex has joined #bitcoin-core-dev
 662016-04-23T07:12:49  *** arowser_ has joined #bitcoin-core-dev
 672016-04-23T07:14:26  *** arowser has quit IRC
 682016-04-23T07:22:39  *** Guyver2 has joined #bitcoin-core-dev
 692016-04-23T07:29:02  *** Alopex has quit IRC
 702016-04-23T07:30:07  *** Alopex has joined #bitcoin-core-dev
 712016-04-23T07:34:04  <luke-jr> phantomcircuit: it's SSSE3 usually :/
 722016-04-23T07:34:18  <luke-jr> I had to build my glibc with -mno-ssse3 or stuff crashed
 732016-04-23T07:34:29  <phantomcircuit> luke-jr, ha
 742016-04-23T07:35:01  * luke-jr never figured out why Haswell's SSSE3 seems to be broken in 32-bit mode.
 752016-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
 762016-04-23T07:39:34  <gmaxwell> you mean 'x32' right?
 772016-04-23T07:41:40  <luke-jr> no, regular 32-bit
 782016-04-23T07:41:47  <gmaxwell> weird.
 792016-04-23T07:41:49  <luke-jr> I suspect x32 would work
 802016-04-23T07:42:00  <luke-jr> my best guess so far has been pointer alignment stuff
 812016-04-23T07:42:18  <gmaxwell> I assume it's not haswell, but some GCC bug.
 822016-04-23T07:42:25  <luke-jr> possible
 832016-04-23T07:42:36  <luke-jr> maybe Haswell is stricted on the spec than previous CPUs?
 842016-04-23T07:43:11  <sipa> i doubt the spec changed, but perhaps older cpus were more lenient with spec violations :)
 852016-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)
 862016-04-23T07:44:04  <luke-jr> or GCC, but I don't see how the compiler could be at fault for this
 872016-04-23T07:44:09  <luke-jr> IIRC it's inline asm
 882016-04-23T07:44:18  <luke-jr> (but I haven't looked at it in probably a year or so)
 892016-04-23T07:44:21  *** davec has quit IRC
 902016-04-23T07:50:02  *** davec has joined #bitcoin-core-dev
 912016-04-23T07:58:05  <phantomcircuit> luke-jr, that would explain why it does what i expect it to do
 922016-04-23T07:58:14  <luke-jr> ?
 932016-04-23T07:58:14  *** pmienk has joined #bitcoin-core-dev
 942016-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
 952016-04-23T08:06:14  <sipa> phantomcircuit: void* is allowed to alias any pointer, i think
 962016-04-23T08:08:15  <luke-jr> in C, at least; not sure about C++ - it complains if you do it implicitly, at least
 972016-04-23T08:12:55  *** Ylbam has joined #bitcoin-core-dev
 982016-04-23T08:23:35  *** PaulCape_ has quit IRC
 992016-04-23T08:24:01  *** PaulCapestany has joined #bitcoin-core-dev
1002016-04-23T08:28:20  *** frankenmint has joined #bitcoin-core-dev
1012016-04-23T08:34:23  *** Thireus1 has quit IRC
1022016-04-23T08:41:53  *** Thireus has joined #bitcoin-core-dev
1032016-04-23T08:55:42  *** p15x has quit IRC
1042016-04-23T09:00:37  *** KHCkjhv has joined #bitcoin-core-dev
1052016-04-23T09:08:24  *** KHCkjhv has quit IRC
1062016-04-23T09:21:10  *** Guyver2 has quit IRC
1072016-04-23T09:21:22  *** pmienk has quit IRC
1082016-04-23T09:34:47  *** pmienk has joined #bitcoin-core-dev
1092016-04-23T09:49:57  *** arowser_ has quit IRC
1102016-04-23T09:50:13  *** arowser has joined #bitcoin-core-dev
1112016-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
1122016-04-23T10:05:50  * sipa tries again
1132016-04-23T10:06:50  <luke-jr> stale config.h somewhere?
1142016-04-23T10:07:07  <sipa> after git -dfx ?
1152016-04-23T10:07:14  <sipa> eh, git clean -dfx
1162016-04-23T10:08:55  <luke-jr> hm, assuming our gitignore is okay that should eliminate any
1172016-04-23T10:09:39  <sipa> git clean -dfx deletes all files not checked in
1182016-04-23T10:09:44  <sipa> including ignored files
1192016-04-23T10:09:50  <sipa> but also others
1202016-04-23T10:10:07  <sipa> so gitignore is not relevant
1212016-04-23T10:11:16  <luke-jr> hm
1222016-04-23T10:11:36  <sipa> i think it's working now...
1232016-04-23T10:11:40  <luke-jr> what changed?
1242016-04-23T10:12:19  <sipa> i did git clean -dfx again...
1252016-04-23T10:15:16  <luke-jr> strange
1262016-04-23T10:15:40  <NicolasDorier> btw I got also the same error yestersday
1272016-04-23T10:16:02  <luke-jr> I don't suppose either of you saved the config.h/log to compare?
1282016-04-23T10:16:18  <NicolasDorier> I can reproduce one sec
1292016-04-23T10:18:47  <NicolasDorier> luke-jr:  right now I have the error, what do you want I do to help fixing it ?
1302016-04-23T10:19:24  <NicolasDorier> (I'm not linux wizard so step by step would be appreciated :p)
1312016-04-23T10:20:32  <luke-jr> NicolasDorier: ideally, copy the entire bitcoin/ dir somewhere, then re-do it successfully and compare
1322016-04-23T10:20:43  *** randy-waterhouse has joined #bitcoin-core-dev
1332016-04-23T10:23:50  <NicolasDorier> k one sec.
1342016-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
1352016-04-23T10:39:10  <NicolasDorier> https://usercontent.irccloud-cdn.com/file/BO3RdE0Q/
1362016-04-23T10:39:22  <NicolasDorier> will check out
1372016-04-23T10:47:22  <NicolasDorier> nevermind was a space in the path
1382016-04-23T10:47:29  <NicolasDorier> ah no
1392016-04-23T10:47:37  *** arowser has quit IRC
1402016-04-23T10:48:01  *** arowser has joined #bitcoin-core-dev
1412016-04-23T11:04:26  <randy-waterhouse> recent commit 351abf9e035581e3320fbb72ec5b1fa452b09c2f (depends build) introduces following error http://pastebin.com/q5cP70y8 (and core dump) on bitcoin-qt
1422016-04-23T11:10:22  *** AaronvanW has joined #bitcoin-core-dev
1432016-04-23T11:14:29  <NicolasDorier> I could not reproduce the 'COPYRIGHT_HOLDERS' error after the first git clean -dfx. It compiled fine :/
1442016-04-23T11:18:21  *** belcher has joined #bitcoin-core-dev
1452016-04-23T11:18:23  <btcdrak> usually just a make clean;./autogen.sh solves this for me
1462016-04-23T11:35:01  *** murch has joined #bitcoin-core-dev
1472016-04-23T11:39:51  <luke-jr> NicolasDorier: ok, so now you have two dirs to compare, right?
1482016-04-23T11:40:19  <NicolasDorier> yes. one which compile and the other with the error
1492016-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
1502016-04-23T11:41:44  <luke-jr> NicolasDorier: diff -ur firstdir seconddir >diff
1512016-04-23T11:41:48  <luke-jr> then pastebin the diff file
1522016-04-23T11:41:52  <NicolasDorier> ok
1532016-04-23T11:41:56  <NicolasDorier> one sec
1542016-04-23T11:45:26  <NicolasDorier> luke-jr it has more than 512kb does not see to be able to copy
1552016-04-23T11:45:44  <luke-jr> dropbox?
1562016-04-23T11:46:08  <NicolasDorier> one sec yes I'll find a way
1572016-04-23T11:47:54  <NicolasDorier> luke-jr: https://aois.blob.core.windows.net/public/diff.txt
1582016-04-23T11:48:18  <NicolasDorier> I need to run
1592016-04-23T11:51:48  <NicolasDorier> in the bitcoin folder does not compile bitcoin2 does
1602016-04-23T11:53:23  <sipa> are you sure the source code is the same across the two?
1612016-04-23T11:53:34  <sipa> the dependencies are different, which is a bit suspicious
1622016-04-23T11:55:16  <luke-jr> -rpcserver.h:
1632016-04-23T11:55:17  <luke-jr> +rpc/server.h:
1642016-04-23T11:55:19  <luke-jr> definitely not the same..
1652016-04-23T11:56:10  <sipa> one looks 0.12, the other master
1662016-04-23T12:30:36  *** jarret has quit IRC
1672016-04-23T12:36:49  *** laurentmt has joined #bitcoin-core-dev
1682016-04-23T12:40:57  *** laurentmt has quit IRC
1692016-04-23T12:44:33  *** randy-waterhouse has quit IRC
1702016-04-23T12:48:19  *** BashCo has quit IRC
1712016-04-23T12:53:22  *** airmac has joined #bitcoin-core-dev
1722016-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
1732016-04-23T12:54:28  <sipa> airmac: not here
1742016-04-23T12:54:38  <sipa> #bitcoin-otc or similar channels please
1752016-04-23T13:10:40  *** AaronvanW has quit IRC
1762016-04-23T13:30:17  *** murch has quit IRC
1772016-04-23T13:30:34  <nkuttler> sipa: already banned from everywhere
1782016-04-23T13:31:14  <sipa> nkuttler: ok
1792016-04-23T13:37:16  *** Thireus has quit IRC
1802016-04-23T14:00:29  *** frankenmint has quit IRC
1812016-04-23T14:12:06  *** frankenmint has joined #bitcoin-core-dev
1822016-04-23T14:22:48  *** AaronvanW has joined #bitcoin-core-dev
1832016-04-23T14:40:51  *** jarret has joined #bitcoin-core-dev
1842016-04-23T14:50:55  *** laurentmt has joined #bitcoin-core-dev
1852016-04-23T14:51:05  *** laurentmt has quit IRC
1862016-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\
1872016-04-23T14:58:24  <belcher> wrong channel, go to #bitcoin-otc or similar
1882016-04-23T14:59:16  *** ChanServ sets mode: +o sipa
1892016-04-23T14:59:26  *** sipa sets mode: +b *!*cheers@168.1.79.*
1902016-04-23T14:59:27  *** airmac was kicked by sipa (go elsewhere)
1912016-04-23T15:00:02  *** ChanServ sets mode: -o sipa
1922016-04-23T15:05:56  *** laurentmt has joined #bitcoin-core-dev
1932016-04-23T15:20:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1942016-04-23T15:23:55  *** TomMc has joined #bitcoin-core-dev
1952016-04-23T15:59:14  *** BCBot_ has joined #bitcoin-core-dev
1962016-04-23T16:45:47  *** laurentmt has quit IRC
1972016-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?
1982016-04-23T16:56:13  <Chris_Stewart_5> ["0x01 0x00", "1", "MINIMALDATA"]
1992016-04-23T16:58:14  <sipa> link?
2002016-04-23T16:58:30  <sipa> ah, i get it
2012016-04-23T16:58:50  <sipa> no, OP_0 pushes the empty vector onto the stack, not 0x00
2022016-04-23T16:59:24  <Chris_Stewart_5> ooo.
2032016-04-23T16:59:46  <Chris_Stewart_5> Tricky :-)
2042016-04-23T17:00:59  <Chris_Stewart_5> Is that what this comment is saying? I didn't really understand the comment
2052016-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"]
2062016-04-23T17:01:32  <Chris_Stewart_5> https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L598
2072016-04-23T17:03:15  <sipa> yes, that's exactly what it's saying
2082016-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
2092016-04-23T17:04:28  <sipa> here, 0x00 is pushed onto the stack with a push operation that satisfies 1)
2102016-04-23T17:04:45  <sipa> 2) is not applicable, because it is not being interpreted as a number
2112016-04-23T17:08:59  <Chris_Stewart_5> Ok that makes sense. Thanks sipa.
2122016-04-23T17:47:22  *** molz has quit IRC
2132016-04-23T17:52:20  *** moli has joined #bitcoin-core-dev
2142016-04-23T18:17:35  *** Samdney has joined #bitcoin-core-dev
2152016-04-23T18:54:25  *** molz has joined #bitcoin-core-dev
2162016-04-23T18:56:58  *** moli has quit IRC
2172016-04-23T19:20:21  *** supasonic has joined #bitcoin-core-dev
2182016-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
2192016-04-23T19:25:57  <luke-jr> well, practical and correct I guess
2202016-04-23T19:26:29  <luke-jr> should I de-bundle BIP 9 GBT stuff from segwit, or just figure wait for that?
2212016-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?
2222016-04-23T19:32:15  *** JackH has joined #bitcoin-core-dev
2232016-04-23T19:32:34  <sipa> how do you mean?
2242016-04-23T19:32:43  <sipa> it's already being used by miners
2252016-04-23T19:32:57  <luke-jr> sipa: there's no way for GBT clients to know what the rules are
2262016-04-23T19:33:22  <sipa> there's no need for that if they're connecting to a trusted bitcoind
2272016-04-23T19:33:42  <luke-jr> GBT requires it
2282016-04-23T19:34:04  <luke-jr> since it could very well be needed
2292016-04-23T19:34:24  <luke-jr> eg, with segwit the handling of txid/hash
2302016-04-23T19:34:52  <sipa> so let's say there is a softfork that adds UTXO commitments
2312016-04-23T19:35:08  <sipa> what you going to do? provide the entire utxo set in the GBT response?
2322016-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
2332016-04-23T19:35:20  <sipa> your view of reality is a dream
2342016-04-23T19:35:32  <sipa> GBT is not being used the way you envision it
2352016-04-23T19:35:46  <luke-jr> in such a case, the GBT client needs to be aware the commitment is required and where
2362016-04-23T19:36:01  <luke-jr> so it can place the commitment from the local bitcoind in the right part of the block
2372016-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)
2382016-04-23T19:36:36  <luke-jr> sipa: I wouldn't have even noticed this if it wasn't.
2392016-04-23T19:36:53  <sipa> but no need to have thing discussion again
2402016-04-23T19:37:22  <sipa> i'm fine with reporting what bip9 deployments are active and available in GBT
2412016-04-23T19:37:37  <sipa> but please don't go claim that it's not possible to mine without
2422016-04-23T19:37:49  *** Thireus has joined #bitcoin-core-dev
2432016-04-23T19:37:50  <sipa> there is no real world mining now that needs such information
2442016-04-23T19:37:55  <luke-jr> per spec, GBT clients cannot work with 0.12.1 as-is today.
2452016-04-23T19:38:06  <luke-jr> and de facto miners implementing it do not work with it
2462016-04-23T19:39:04  <sipa> why not? all deployed GBT clients in the world work fine with it
2472016-04-23T19:39:06  <luke-jr> I'm just trying to find a clean way to fix this real-world problem miners are encountering
2482016-04-23T19:39:09  <luke-jr> nope
2492016-04-23T19:39:14  <sipa> how so?
2502016-04-23T19:39:31  <luke-jr> the version field is unrecognised, so they throw an error
2512016-04-23T19:40:55  <sipa> how do you mean?
2522016-04-23T19:41:38  <luke-jr> https://github.com/bitcoin/libblkmaker/blob/master/blkmaker_jansson.c#L273
2532016-04-23T19:42:26  <sipa> ok, so the software needs to be updated
2542016-04-23T19:43:09  <sipa> i see what you're saying
2552016-04-23T19:43:26  *** frankenmint has quit IRC
2562016-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
2572016-04-23T19:44:17  <luke-jr> those would be fine now (albeit not per spec), but they'll break worse with segwit
2582016-04-23T19:44:43  <luke-jr> I suppose libblkmaker can treat the case of (currentsoftforkversion && !bip9)
2592016-04-23T19:44:59  <luke-jr> as long as the next softfork uses BIP9 GBT changes, that would protect against bit reuse
2602016-04-23T19:45:18  <sipa> i think it may be best to disentangle the segwit changes from bip9 changes to gbt
2612016-04-23T19:45:18  <luke-jr> does that sound reasonable?
2622016-04-23T19:45:31  <luke-jr> ok
2632016-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
2642016-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
2652016-04-23T19:48:10  <sipa> (trying to remember the discussion we had before)
2662016-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
2672016-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
2682016-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
2692016-04-23T19:51:13  <luke-jr> so libblkmaker will have a special case for 0x20000000 && !vbavailable, to handle 0.12.1 correctly
2702016-04-23T19:51:34  <sipa> how will you deal with 0x20000001?
2712016-04-23T19:52:35  <luke-jr> hm, I'm confused
2722016-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
2732016-04-23T19:53:59  <luke-jr> oh, the begin time..
2742016-04-23T19:54:23  <sipa> yes, after may 1st it will set 0x20000001
2752016-04-23T19:54:49  <luke-jr> so I need to check for & 0xFFFFFFFE == 0x20000000
2762016-04-23T19:55:21  <sipa> cfields: ^ relevant discussion
2772016-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
2782016-04-23T20:02:34  <sipa> luke-jr: right, no problem with saying "these bits you must set, and these you may set"
2792016-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
2802016-04-23T20:03:53  <sipa> *which *purely
2812016-04-23T20:04:01  <sipa> *no relevance
2822016-04-23T20:04:52  <luke-jr> in the sense that you wish to discuss it further before proceeding that direction, or just a comment?
2832016-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
2842016-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 ;)
2852016-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
2862016-04-23T20:06:03  <sipa> *wish to participate
2872016-04-23T20:06:12  <luke-jr> "what means what" depends on blockchain context they lack
2882016-04-23T20:06:30  <sipa> nno, it does not
2892016-04-23T20:06:34  <sipa> it's in the bips
2902016-04-23T20:06:54  <sipa> ah, there is one piece of context information they lack
2912016-04-23T20:06:59  <sipa> mediantimepast
2922016-04-23T20:08:08  <luke-jr> also testnet vs mainnet, but that's admittedly less important
2932016-04-23T20:08:30  <sipa> i see
2942016-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)
2952016-04-23T20:08:58  *** Thireus has quit IRC
2962016-04-23T20:10:26  *** frankenmint has joined #bitcoin-core-dev
2972016-04-23T20:16:33  *** frankenmint has quit IRC
2982016-04-23T20:23:22  <luke-jr> ok, step 1 done I hope: https://github.com/bitcoin/bips/pull/365
2992016-04-23T20:25:28  *** zlover has joined #bitcoin-core-dev
3002016-04-23T20:27:24  <btcdrak> luke-jr: your changes dont render properly https://i.imgur.com/Qmwqh0k.png
3012016-04-23T20:27:39  *** Guyver2 has joined #bitcoin-core-dev
3022016-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?
3032016-04-23T20:30:00  <luke-jr> btcdrak: looks like none of the GBT stuff does, due to GitHub migration
3042016-04-23T20:31:22  <luke-jr> https://help.github.com/articles/supported-mediawiki-formats/#unsupported-mediawiki-syntaxes :/
3052016-04-23T20:33:12  <luke-jr> btcdrak: fixed by avoiding the templates
3062016-04-23T20:35:17  *** Thireus has joined #bitcoin-core-dev
3072016-04-23T21:04:29  <sipa> instagibbs: say you have a normal P2SH (not witness) output being spent
3082016-04-23T21:04:48  <sipa> oh, no
3092016-04-23T21:05:52  <sipa> instagibbs: say you have an invalid witness-in-p2sh spending
3102016-04-23T21:06:42  <sipa> with just witness enabled, that's valid
3112016-04-23T21:07:05  <instagibbs> wait what, is it invalid or invalid?
3122016-04-23T21:07:11  *** arubi has joined #bitcoin-core-dev
3132016-04-23T21:07:18  <instagibbs> err valid
3142016-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)
3152016-04-23T21:09:31  <kanzure> why would enabling witness make that valid?
3162016-04-23T21:09:45  <kanzure> wrong signatures should always be wrong
3172016-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
3182016-04-23T21:11:00  <sipa> if you evaluate with WITNESS+P2SH, the P2SH evaluation happens, which triggers the witness logic, which is invalid
3192016-04-23T21:11:03  <sipa> eh
3202016-04-23T21:11:15  <sipa> that's all true, but not the reason why it's not a softfork
3212016-04-23T21:11:54  <kanzure> oops just checked context. didn't see the question re: the comment. nevermind.
3222016-04-23T21:15:28  <instagibbs> "say you have a p2sh output" are you saying this is a p2wsh or something similar
3232016-04-23T21:15:56  <instagibbs> or just a plain p2sh like today
3242016-04-23T21:16:50  <instagibbs> oh i see
3252016-04-23T21:18:31  <instagibbs> I'm not quite getting the comment then, although I agree with what you're saying here
3262016-04-23T21:19:51  <sipa> let me think again
3272016-04-23T21:20:07  <instagibbs> it sounds like you're saying SOFTFORK1 this is valid, then adding SOFTFORK2 it's now invalid
3282016-04-23T21:20:13  <instagibbs> which is def of softfork?
3292016-04-23T21:20:47  <sipa> there is a similar rule for cleanstack, and that one i can explain
3302016-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
3312016-04-23T21:21:36  <sipa> and all flags should be softforks
3322016-04-23T21:22:40  <sipa> mempool validations relies on that
3332016-04-23T21:24:07  <instagibbs> I'm clearly missing something important here.
3342016-04-23T21:24:26  <instagibbs> probably what the flag semantics are or something
3352016-04-23T21:25:43  *** achow101 has joined #bitcoin-core-dev
3362016-04-23T21:27:35  <instagibbs> oh... it's just talking about the actual implementation and program flow...
3372016-04-23T21:27:52  * instagibbs smacks forehead 
3382016-04-23T21:27:53  <sipa>  so, for ok, for WWITNESS and CLEANSTACK
3392016-04-23T21:28:29  <sipa> any witness spend would fail CLEANSTACK validation
3402016-04-23T21:28:38  <sipa> because it is just pushes
3412016-04-23T21:28:52  <sipa> so it clearly does not satisfy CLEANSTACK
3422016-04-23T21:29:18  <instagibbs> I misunderstood the comment, as I thought
3432016-04-23T21:29:25  <sipa> unless when WITNESS is enabled, then we ignore the CLEANSTACK rule
3442016-04-23T21:29:45  <sipa> thus, a change in flags from CLEANSTACK to CLEANSTACK+WITNESS is not a softfork
3452016-04-23T21:29:49  <instagibbs> I read it as "BIP141 by itself is somehow a hardfork"
3462016-04-23T21:29:57  <sipa> oh, no
3472016-04-23T21:30:02  <instagibbs> totally get it now
3482016-04-23T21:30:28  <sipa> we just make CLEANSTACK without WITNESS invalid, so such a change can never occur
3492016-04-23T21:30:31  <sipa> ok!
3502016-04-23T21:30:47  <luke-jr> sipa: does BIP68+112+113 have a VB name?
3512016-04-23T21:30:57  <sipa> luke-jr: csv
3522016-04-23T21:31:00  <luke-jr> k
3532016-04-23T21:32:48  <instagibbs> thanks for the explanation!
3542016-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?
3552016-04-23T21:33:48  *** achow101 has quit IRC
3562016-04-23T21:34:49  *** achow101 has joined #bitcoin-core-dev
3572016-04-23T21:40:53  <sipa> luke-jr: the rules that apply to a block are purely a function of its ancestor block header
3582016-04-23T21:40:54  *** phantomcircuit has quit IRC
3592016-04-23T21:41:10  <sipa> not of its own timestamp or version
3602016-04-23T21:41:11  *** phantomcircuit has joined #bitcoin-core-dev
3612016-04-23T21:44:06  <luke-jr> k
3622016-04-23T21:51:32  <luke-jr> wtf does this GCC thing mean: http://codepad.org/BfJgyPwQ :/
3632016-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.
3642016-04-23T21:54:05  <luke-jr> am I blind or something? those look the same to me :|
3652016-04-23T21:54:22  *** Guyver2 has quit IRC
3662016-04-23T21:54:49  <sipa> different namespace?
3672016-04-23T21:55:03  <luke-jr> aha that could be it
3682016-04-23T21:55:32  <luke-jr> yup
3692016-04-23T21:55:33  <luke-jr> thanks
3702016-04-23T22:09:39  <Lightsword> luke-jr, why not version GBT separately from the block version?
3712016-04-23T22:10:19  <luke-jr> Lightsword: it doesn't make sense to do so
3722016-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
3732016-04-23T22:12:03  *** Don_John has joined #bitcoin-core-dev
3742016-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
3752016-04-23T22:13:02  <luke-jr> Lightsword: well, previously, GBT had the version/force mutation for that, but nobody ever considered it worth using
3762016-04-23T22:13:49  <Lightsword> luke-jr, so the mining software could actually enforce soft fork rules different from bitcoind?
3772016-04-23T22:13:56  <luke-jr> the new BIP 9 stuff doesn't really break that either
3782016-04-23T22:14:01  <luke-jr> Lightsword: ?
3792016-04-23T22:14:15  <Lightsword> what is the purpose of version/force mutation?
3802016-04-23T22:14:40  <luke-jr> Lightsword: tells clients to use the provided version despite their ignorance of its meaning
3812016-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
3822016-04-23T22:15:34  <Lightsword> oh, is that for GBT pooled mining?
3832016-04-23T22:17:23  <luke-jr> mutations are defined in BIP 23, yes, but GBT itself has no distinction between pools and bitcoind
3842016-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?
3852016-04-23T22:23:50  <sipa> Lightsword: the choice that miner clients have is choosing to vote for a deployment or not
3862016-04-23T22:24:01  <sipa> not about rules that are actually enforced
3872016-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.
3882016-04-23T22:24:15  <sipa> those are set by the full node/server that has to accept them
3892016-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?
3902016-04-23T22:27:24  <sipa> if the server supports it
3912016-04-23T22:27:52  *** zlover has quit IRC
3922016-04-23T22:29:38  <luke-jr> Lightsword: see https://github.com/bitcoin/bips/pull/365
3932016-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?
3942016-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
3952016-04-23T22:31:18  <luke-jr> the CSV deployment *could* have used version/force for old GBT clients, but it did not.
3962016-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?
3972016-04-23T22:33:30  *** aquentson has quit IRC
3982016-04-23T22:34:11  <luke-jr> the block version number indicates the pending proposals, not the ones in effect
3992016-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?
4002016-04-23T22:37:34  *** achow101 has quit IRC
4012016-04-23T22:37:47  <luke-jr> Lightsword: compatibility is only guaranteed with the known rules
4022016-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
4032016-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
4042016-04-23T22:43:11  <luke-jr> Lightsword: eg, when the transactions and generation tx come from different servers
4052016-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?
4062016-04-23T22:48:26  <luke-jr> yes
4072016-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?
4082016-04-23T22:50:20  <luke-jr> …
4092016-04-23T22:50:29  <luke-jr> you're suggesting they be the same
4102016-04-23T22:52:55  <Lightsword> luke-jr, have previous soft forks restricted generation transaction validity?
4112016-04-23T22:53:28  *** molz has quit IRC
4122016-04-23T22:53:29  *** moli has joined #bitcoin-core-dev
4132016-04-23T22:53:41  <sipa> Lightsword: by definition, all of them
4142016-04-23T22:53:51  <sipa> ah, generation transaction, sorry
4152016-04-23T22:54:09  <sipa> bip30 and bip34
4162016-04-23T22:54:38  <luke-jr> ^
4172016-04-23T22:55:23  <sipa> and bip141
4182016-04-23T22:55:35  <Lightsword> ok, but some don’t as well right?
4192016-04-23T22:56:01  <Lightsword> like CSV and BIP66?
4202016-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
4212016-04-23T22:58:03  *** achow101 has joined #bitcoin-core-dev
4222016-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
4232016-04-23T22:59:00  *** pmienk has quit IRC
4242016-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
4252016-04-23T23:00:35  <luke-jr> it might
4262016-04-23T23:01:48  <Lightsword> in what sort of situation would that be?
4272016-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
4282016-04-23T23:03:04  <Lightsword> does anybody actually do that?
4292016-04-23T23:03:26  <luke-jr> dunno, doubt it
4302016-04-23T23:03:58  <Lightsword> I mean, merging transactions means you have to support a lot of consensus logic within the mining software itself
4312016-04-23T23:04:06  <luke-jr> not much
4322016-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
4332016-04-23T23:06:48  <luke-jr> perhaps a "rules/force" mutation would make sense
4342016-04-23T23:06:54  *** laurentmt has joined #bitcoin-core-dev
4352016-04-23T23:07:10  <luke-jr> then the server can evaluate if the client's supported rules are sufficient and override that check
4362016-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
4372016-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
4382016-04-23T23:08:50  <luke-jr> "version" did that pre-BIP9, and "rules" does it with BIP 9
4392016-04-23T23:08:57  *** laurentmt has quit IRC
4402016-04-23T23:10:40  *** pmienk has joined #bitcoin-core-dev
4412016-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
4422016-04-23T23:11:02  *** Thireus has joined #bitcoin-core-dev
4432016-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
4442016-04-23T23:12:33  <luke-jr> at their own risk
4452016-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
4462016-04-23T23:14:11  <luke-jr> ok, that'd be a "rules/force" mutation..
4472016-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
4482016-04-23T23:15:23  <sipa> luke-jr: perhaps the active rules can use a similar classification
4492016-04-23T23:16:16  <Lightsword> I’m confused on how mutable actually works
4502016-04-23T23:16:30  * sipa doubts anyone uses mutable at all in GBT
4512016-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
4522016-04-23T23:17:43  <sipa> i think you're overdesigning it, trying to cater to every possible use, without any real world demand
4532016-04-23T23:17:44  <luke-jr> client-side, it tells the client what they're allowed to do with the template
4542016-04-23T23:18:00  <luke-jr> sipa: yes, GBT is overdesigned and should be thrown out, but first we'd need a new protocol
4552016-04-23T23:18:08  <Lightsword> well in practical sense bitcoind is the server and the stratum server is the client
4562016-04-23T23:18:22  <luke-jr> Lightsword: you're only thinking about your one use case.
4572016-04-23T23:18:34  <Lightsword> the use case that basically the entire network runs on though :P
4582016-04-23T23:18:36  <sipa> the only one that matters
4592016-04-23T23:18:39  <luke-jr> …
4602016-04-23T23:18:48  <luke-jr> except the miners who don't.
4612016-04-23T23:19:04  <Lightsword> which is almost certainly well below 1% of the network
4622016-04-23T23:19:45  <Lightsword> hell, even eligius doesn’t allow GBT mining :P
4632016-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?
4642016-04-23T23:19:53  <luke-jr> Lightsword: yes it does
4652016-04-23T23:20:05  <Lightsword> it just redirects to stratum last I checked
4662016-04-23T23:20:11  <luke-jr> you can disable the redirection
4672016-04-23T23:20:32  <Lightsword> does anybody actually do that?
4682016-04-23T23:20:42  <luke-jr> no idea, ask wizkid057
4692016-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
4702016-04-23T23:22:13  <luke-jr> anyone know what testnet blocks made csv change states?
4712016-04-23T23:22:36  <Lightsword> huh? i didn’t know it changed status
4722016-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.
4732016-04-23T23:23:36  <midnightmagic> like, re-written and re-designed *as a specific and incompatible alternative* to things like GBT.
4742016-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
4752016-04-23T23:24:06  <sipa> not sure what you mean by rules/force
4762016-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
4772016-04-23T23:24:34  <Lightsword> midnightmagic, to be fair GBT is pretty much impractical for pooled mining
4782016-04-23T23:24:45  * midnightmagic shrugs.
4792016-04-23T23:25:04  <midnightmagic> And instead of making GBT better or including it in a superset, people did other things.
4802016-04-23T23:25:45  <phantomcircuit> luke-jr, i'm some large % of testnet and running 73fc922ed64333d45f18d8a448f30cfa2ae0281e
4812016-04-23T23:25:47  <luke-jr> midnightmagic: meh, GBT is fundamentally incompatible with sidechains, so it needs to be replaced anyway
4822016-04-23T23:26:02  <luke-jr> phantomcircuit: ?
4832016-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
4842016-04-23T23:26:24  <phantomcircuit> you asked about testnet and csv; i did not answer your question but did provide additional information
4852016-04-23T23:26:42  <luke-jr> phantomcircuit: I don't see an answer to my question >_
4862016-04-23T23:26:43  <luke-jr> >_<
4872016-04-23T23:26:50  *** Chris_Stewart_5 has quit IRC
4882016-04-23T23:27:18  <phantomcircuit> luke-jr, i'm so helpful right
4892016-04-23T23:27:21  *** AaronvanW has quit IRC
4902016-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.
4912016-04-23T23:27:51  <phantomcircuit> gmaxwell, i think you need more specific nouns
4922016-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
4932016-04-23T23:28:10  <phantomcircuit> (actually i think this entire conversation needs more specific nouns)
4942016-04-23T23:28:27  <Lightsword> even if the block size is 50k
4952016-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
4962016-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.
4972016-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)
4982016-04-23T23:30:18  <phantomcircuit> any suggestion?
4992016-04-23T23:30:19  *** achow101 has quit IRC
5002016-04-23T23:30:41  <gmaxwell> phantomcircuit: up your threshold on the laptop.
5012016-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
5022016-04-23T23:31:26  <gmaxwell> No, it's a crappy protocol for that too.
5032016-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?
5042016-04-23T23:31:39  <phantomcircuit> i thought x86 systems had performance counters that could efficiently do that though
5052016-04-23T23:31:44  *** bitcoinfr has joined #bitcoin-core-dev
5062016-04-23T23:31:52  <sipa> phantomcircuit: rdtsc
5072016-04-23T23:32:02  <Lightsword> gmaxwell, sure but it was better than GBT for that and there wasn’t an alternative people could choose
5082016-04-23T23:32:06  <sipa> doesn't count instructions, just clock cycles
5092016-04-23T23:32:16  <bitcoinfr> .
5102016-04-23T23:32:30  <phantomcircuit> sipa, that seems better actually
5112016-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.*
5122016-04-23T23:33:03  <luke-jr> and made no effort to collaborate with others already working on GBT
5132016-04-23T23:33:11  <luke-jr> but that's history, and irrelevant to what we do in BIP 9
5142016-04-23T23:33:18  *** bitcoinfr has quit IRC
5152016-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
5162016-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.
5172016-04-23T23:33:44  *** achow101 has joined #bitcoin-core-dev
5182016-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
5192016-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
5202016-04-23T23:39:15  <luke-jr> developed openly, with collaboration from multiple people
5212016-04-23T23:53:38  <midnightmagic> yes, lots of attempts at collaboration and unification.
5222016-04-23T23:57:59  <luke-jr> why does BOOST_FOREACH not work on UniValues? :<