12017-03-04T00:02:39  <gmaxwell> no those figures are from using the scalar sha2 code.
  22017-03-04T00:03:06  <gmaxwell> AFAIK the only real place we can make good use of the parallel sha2 SSE code would be in hash tree computation, but that is complicated as you know.
  32017-03-04T00:03:24  <gmaxwell> IIRC the SIMD scalar sha2 is ~2x faster than ours, and the SIMD parallel sha2 is 3x faster than ours.
  42017-03-04T00:03:52  <luke-jr> merkle trees probably aren't a significant amount of hashing I think?
  52017-03-04T00:05:26  <gmaxwell> They're actually tons. because every node in it is three compression function runs. and there are txn*2 nodes in total.
  62017-03-04T00:05:46  <gmaxwell> so a block can have something like 24000 compression function runs.
  72017-03-04T00:06:22  <luke-jr> hmm
  82017-03-04T00:08:06  <sipa> so 8ms?
  92017-03-04T00:08:11  <sipa> that's significant
 102017-03-04T00:08:53  <sipa> assuming 3 GHz and 15 cpb for sha256
 112017-03-04T00:09:14  <TD-Linux> <wumpus> gmaxwell: it's a bit scary though as the external process will be able to keep a reference, and have all your key data :) <- you can seal the fd and verify the seal in the sandboxed process to eliminate this vulnerability
 122017-03-04T00:10:07  <gmaxwell> yes, it's non-trivial in terms of validation latency.
 132017-03-04T00:11:18  <TD-Linux> er actually disregard me, there is no read seal
 142017-03-04T00:15:06  *** afk11_ has joined #bitcoin-core-dev
 152017-03-04T00:16:49  *** mobilemo has joined #bitcoin-core-dev
 162017-03-04T00:18:02  *** wudayoda has quit IRC
 172017-03-04T00:19:08  *** mobilemo has left #bitcoin-core-dev
 182017-03-04T00:22:06  *** bityogi has quit IRC
 192017-03-04T00:50:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 202017-03-04T00:51:11  *** dodomojo has joined #bitcoin-core-dev
 212017-03-04T00:52:27  <jeremyrubin> hm Bitcoin Unlimited just added ~parallel block validation~ but I'm pretty sure it has no perforance benefit
 222017-03-04T00:52:49  <jeremyrubin> (in case anyone is looking at what they implemented)
 232017-03-04T00:53:30  <TD-Linux> jeremyrubin, correct, it is not a performance enhancement but an attempt to "fix" quadratic hashing
 242017-03-04T00:53:48  <jeremyrubin> wait what
 252017-03-04T00:54:01  <jeremyrubin> The parallel block validation?
 262017-03-04T00:54:03  <TD-Linux> yes
 272017-03-04T00:54:17  <sipa> it means that the node doesn't stall if your block takes a day to validate
 282017-03-04T00:54:25  <TD-Linux> yup, it'll just burn a core for a day
 292017-03-04T00:54:51  <TD-Linux> of course under the assumption that the block also gets orphaned.
 302017-03-04T00:55:11  <jeremyrubin> Yeah isn't that block hopefully just going to orphan
 312017-03-04T00:55:16  <jeremyrubin> if it takes that long to validate
 322017-03-04T00:55:18  <jeremyrubin> hmm
 332017-03-04T00:55:52  <sipa> also, since our validation is already parallel anyway, it makes both blocks slower
 342017-03-04T00:56:05  <jeremyrubin> yeah that's why I thought it was useless
 352017-03-04T00:56:18  <jeremyrubin> core can only do so many IPC
 362017-03-04T00:56:19  <TD-Linux> jeremyrubin, thus the question "how long is too long"
 372017-03-04T00:56:39  <jeremyrubin> Well... that seems to be a hard fork then?
 382017-03-04T00:57:09  <jeremyrubin> Because now you'll partition old nodes trying to validate whatever monster block (assuming it crashes/kills your node on old hardware)
 392017-03-04T00:57:25  <TD-Linux> jeremyrubin, it is likely to cause forks, yes.
 402017-03-04T00:57:30  <TD-Linux> itself it is not a hard fork.
 412017-03-04T00:59:14  <jeremyrubin> yeah, sorry was slightly imprecise with terminology
 422017-03-04T01:00:06  *** JackH has joined #bitcoin-core-dev
 432017-03-04T01:00:10  <jeremyrubin> it seems they don't mention it being a quadratic hashing fix in the documentation
 442017-03-04T01:00:45  <jeremyrubin> Also it seems quadratic hashing isn't really a problem before this either, just wait until the block gets orphaned?
 452017-03-04T01:01:40  <gmaxwell> yea, it clearly has some unexplored interactions with selfish mining too.  E.g. if you mine an empty block, now you hold it locally for a bit comfortable that if there is a block race, you'll win even though you announced later... you can be up to the typical validation time late in your announcement.
 462017-03-04T01:01:58  <gmaxwell> jeremyrubin: qudratic hashing is a _huge_ problem if you've ripped off the blocksize limit and done nothing about it.
 472017-03-04T01:02:29  <gmaxwell> a block could take days to hash and shut down the network. :P (except for collaborating miners that know to 'optimize out' checking that transaciton) :)
 482017-03-04T01:03:18  <jeremyrubin> Do we have a provision for abandoning a block mid validation if a longer header chain is seen?
 492017-03-04T01:03:30  <jeremyrubin> Probably a tighter way to address same concern.
 502017-03-04T01:04:45  <gmaxwell> it's not a concern for us. As it's not really easy to make excessively slow blocks in the concernsus rules and segwit completely fixes quadratic hashing.
 512017-03-04T01:05:15  <gmaxwell> could basically worry about it once it _ever_ would have made a difference, rather than adding complexity now.
 522017-03-04T01:05:44  <gmaxwell> (the complexity would be that that longer chain may be invalid, so you'll have to go back to validating the other thing, seems messy as heck)
 532017-03-04T01:06:04  <jeremyrubin> well... it can be a good "defensive" code in case a new compelxity attaack is ever found.
 542017-03-04T01:06:27  <gmaxwell> sure but has to be weighed against the complexity of the fix and the risk it implies.
 552017-03-04T01:06:44  <jeremyrubin> I think it's a simple rule; always be trying to validate the largest-POW chain
 562017-03-04T01:07:01  <TD-Linux> if such an attack was made, simply stalling is a pretty good failure option
 572017-03-04T01:07:23  <gmaxwell> (maybe if someone implemented it they'd find it was easy... though just testing it makes me feel uneasy, concurrency is really hard to test well.)
 582017-03-04T01:07:49  <jeremyrubin> fair!
 592017-03-04T01:08:39  <gmaxwell> jeremyrubin: we do that, subject to the fact that while validating a block we're effectively non-concurrent, so we won't learn about the longer chain until we're done.  So really the complexity there is just in safely increasing the concurrency. Which might be an independant good--- e.g. a side effect of the changes for the block testing stuff we were talking about a day ago.
 602017-03-04T01:11:10  <TD-Linux> certainly I'd hope for more tests than parallel validation has :^)
 612017-03-04T01:12:27  <gmaxwell> we don't really have a good test harness for testing concurrency.  data race freeness doesn't mean that a parallel algorihim will yield expected results in all ordering sequences.
 622017-03-04T01:15:57  <TD-Linux> some sort of framework that would cause all mutexes to block until the test explicitly lets them continue would be neat.
 632017-03-04T01:17:27  <gmaxwell> TD-Linux: well RR actually has neat stuff for making threaded execution determinstic, that I think could be listed into being a concurrency fuzzing tool.
 642017-03-04T01:18:16  <gmaxwell> e.g. replay from an to a given point... and then repeat the replay with many different values given to the RNG that schedules the threads, and see if you get different results.
 652017-03-04T01:18:18  <TD-Linux> gmaxwell, well if you want to fuzz rather than be explicit, doesn't rr's chaos mode already count?
 662017-03-04T01:18:25  <gmaxwell> oh does it already do this? lol
 672017-03-04T01:19:03  <luke-jr> [01:01:39] <gmaxwell> yea, it clearly has some unexplored interactions with selfish mining too.  E.g. if you mine an empty block, now you hold it locally for a bit comfortable that if there is a block race, you'll win even though you announced later… you can be up to the typical validation time late in your announcement. <-- they may claim this is a good thing, since it incentivises smaller blocks
 682017-03-04T01:20:22  <luke-jr> although in fact it incentivises blocks which meet relay-network policy even better
 692017-03-04T01:20:43  <luke-jr> or rather, the most-limited relay policy
 702017-03-04T01:20:48  <gmaxwell> the key point about selfish mining is that it gives excess returns to larger miners. So "incenticizes smaller blocks at the expense of decenteralization" ... missing the point. :P  Also,  not smaller but empty the validation time difference between a block and a slightly smaller one is neglgible, you have to make the block empty to reliably cut in front of others.
 712017-03-04T01:21:47  <gmaxwell> the latest BIP152 stuff is much more policy durable than prior stuff, since it will retain transactions rejected for policy reasons and still use them to reconstruct blocks.
 722017-03-04T01:23:08  <luke-jr> that's not a good thing IMO
 732017-03-04T01:23:32  <luke-jr> the network policy putting pressure on miners is a desirable trait
 742017-03-04T01:23:50  <luke-jr> although most-restrictive isn't the ideal either, so meh
 752017-03-04T01:24:10  <gmaxwell> 'network policy' doesn't matter, other miners policy matters. And moreover: doublespend is 'policy' that is not in the miners control.
 762017-03-04T01:24:23  <gmaxwell> Without extra someone spamming doublespends can considerably slow propagation.
 772017-03-04T01:25:13  <luke-jr> true, but if that's the only concern, we would want to limit the extra pool to just double spends
 782017-03-04T01:25:43  <gmaxwell> luke-jr: consider, without it there is pressure to not increase the minimum feerate in your mempool.
 792017-03-04T01:26:03  <gmaxwell> because it will make you slower to accept blocks from others with a lower minimum feerate.
 802017-03-04T01:26:31  <gmaxwell> (though I think there should probably be seperate extra pools for different kinds of rejections, adding complexity would have delayed getting it in)
 812017-03-04T01:26:59  <gmaxwell> luke-jr: also keep in mind that any time miners expirence delays the easiest solution for them is to just centeralize their pooling more.
 822017-03-04T01:27:18  <gmaxwell> they're not going to sit and go "oh that sucks, I'll twiddle my policy."
 832017-03-04T01:27:37  * luke-jr notes he didn't oppose extra-pool :P
 842017-03-04T01:28:43  <gmaxwell> fair enough.
 852017-03-04T01:54:25  *** abpa has quit IRC
 862017-03-04T01:55:33  *** dodomojo has quit IRC
 872017-03-04T01:57:05  *** dodomojo has joined #bitcoin-core-dev
 882017-03-04T02:08:10  *** dodomojo_ has joined #bitcoin-core-dev
 892017-03-04T02:11:28  *** dodomojo has quit IRC
 902017-03-04T02:12:53  *** kadoban has joined #bitcoin-core-dev
 912017-03-04T02:22:40  *** dodomojo has joined #bitcoin-core-dev
 922017-03-04T02:24:05  *** dodomoj__ has joined #bitcoin-core-dev
 932017-03-04T02:25:28  *** dodomojo_ has quit IRC
 942017-03-04T02:27:26  *** dodomojo_ has joined #bitcoin-core-dev
 952017-03-04T02:27:34  *** dodomojo has quit IRC
 962017-03-04T02:30:22  *** dodomoj__ has quit IRC
 972017-03-04T02:34:43  *** dodomojo has joined #bitcoin-core-dev
 982017-03-04T02:34:45  *** rafalcpp_ has joined #bitcoin-core-dev
 992017-03-04T02:35:19  *** rafalcpp has quit IRC
1002017-03-04T02:37:43  *** dodomojo_ has quit IRC
1012017-03-04T02:40:55  *** str4d has joined #bitcoin-core-dev
1022017-03-04T02:44:57  *** rafalcpp_ has quit IRC
1032017-03-04T02:45:32  *** rafalcpp_ has joined #bitcoin-core-dev
1042017-03-04T02:46:01  *** dodomojo_ has joined #bitcoin-core-dev
1052017-03-04T02:47:01  *** dodomoj__ has joined #bitcoin-core-dev
1062017-03-04T02:48:26  *** dodomoj__ has quit IRC
1072017-03-04T02:48:55  *** dodomojo has quit IRC
1082017-03-04T02:50:40  *** dodomojo_ has quit IRC
1092017-03-04T02:54:03  *** Ylbam has quit IRC
1102017-03-04T03:02:23  *** MarcoFalke has quit IRC
1112017-03-04T03:35:39  *** AaronvanW has quit IRC
1122017-03-04T03:42:10  *** Victor_sueca has joined #bitcoin-core-dev
1132017-03-04T03:44:57  *** Victorsueca has quit IRC
1142017-03-04T03:54:15  <luke-jr> #8694 is finally ready for final reviewing
1152017-03-04T03:54:17  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
1162017-03-04T04:15:09  *** cryptapus is now known as cryptapus_afk
1172017-03-04T04:15:29  <jeremyrubin> I'm debugging something; is there a threadsafe way to access pcoinstip during connectblock? I want to be able to access it from a scriptcheck
1182017-03-04T04:15:52  <jeremyrubin> I'm guessing I would have to add locks around the usage
1192017-03-04T04:16:19  <jeremyrubin> curious if anyone's done this before and if the performance decrease is bad
1202017-03-04T04:16:58  <jeremyrubin> (I think it might be doable to parallelize checking the inputs)
1212017-03-04T04:26:10  *** justanotheruser has quit IRC
1222017-03-04T04:29:34  *** moli_ has joined #bitcoin-core-dev
1232017-03-04T04:30:56  <jeremyrubin> hm I think i have something workable using shared_mutex
1242017-03-04T04:31:00  *** kadoban has quit IRC
1252017-03-04T04:31:28  *** molz_ has quit IRC
1262017-03-04T04:33:41  *** justanotheruser has joined #bitcoin-core-dev
1272017-03-04T05:04:09  *** Victor_sueca has quit IRC
1282017-03-04T05:05:17  *** Victor_sueca has joined #bitcoin-core-dev
1292017-03-04T05:07:04  *** str4d has quit IRC
1302017-03-04T05:42:46  *** dodomojo has joined #bitcoin-core-dev
1312017-03-04T05:49:36  *** Robinson has joined #bitcoin-core-dev
1322017-03-04T05:57:51  *** jannes has quit IRC
1332017-03-04T05:59:58  *** dodomojo has quit IRC
1342017-03-04T06:00:32  *** dodomojo has joined #bitcoin-core-dev
1352017-03-04T06:02:17  *** dodomojo_ has joined #bitcoin-core-dev
1362017-03-04T06:05:58  *** dodomojo has quit IRC
1372017-03-04T06:20:10  *** Robinson has quit IRC
1382017-03-04T06:21:55  *** dodomojo_ has quit IRC
1392017-03-04T06:23:49  *** dodomojo has joined #bitcoin-core-dev
1402017-03-04T06:34:51  *** str4d has joined #bitcoin-core-dev
1412017-03-04T06:36:23  *** dodomojo_ has joined #bitcoin-core-dev
1422017-03-04T06:37:06  *** dodomoj__ has joined #bitcoin-core-dev
1432017-03-04T06:39:24  *** dodomojo has quit IRC
1442017-03-04T06:40:37  *** dodomojo_ has quit IRC
1452017-03-04T06:44:50  *** whphhg has quit IRC
1462017-03-04T06:45:04  *** whphhg has joined #bitcoin-core-dev
1472017-03-04T06:46:59  *** whphhg has quit IRC
1482017-03-04T06:47:17  *** whphhg has joined #bitcoin-core-dev
1492017-03-04T06:48:59  *** whphhg has joined #bitcoin-core-dev
1502017-03-04T06:55:45  *** str4d has quit IRC
1512017-03-04T06:59:13  *** dodomoj__ has quit IRC
1522017-03-04T07:05:27  *** To7 has quit IRC
1532017-03-04T07:08:11  *** whphhg has quit IRC
1542017-03-04T07:08:23  *** whphhg has joined #bitcoin-core-dev
1552017-03-04T07:33:11  *** dodomojo has joined #bitcoin-core-dev
1562017-03-04T07:38:01  *** dodomojo has quit IRC
1572017-03-04T07:51:25  *** Victor_sueca has quit IRC
1582017-03-04T07:52:32  *** Victor_sueca has joined #bitcoin-core-dev
1592017-03-04T07:55:47  *** whphhg has quit IRC
1602017-03-04T08:00:00  *** Evel-Knievel has quit IRC
1612017-03-04T08:07:27  <bitcoin-git> [bitcoin] kobake opened pull request #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type) (master...fix-minus-operator-target-for-msvc-c4146) https://github.com/bitcoin/bitcoin/pull/9916
1622017-03-04T08:07:41  <luke-jr> jonasschnelli: can always not support gitian builds with the first introduction of a new feature ;)
1632017-03-04T08:16:34  *** Chris_Stewart_5 has quit IRC
1642017-03-04T08:18:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1652017-03-04T08:24:24  *** jyap has left #bitcoin-core-dev
1662017-03-04T08:27:45  *** dodomojo has joined #bitcoin-core-dev
1672017-03-04T08:31:55  *** dodomojo has quit IRC
1682017-03-04T08:32:16  *** Guyver2 has joined #bitcoin-core-dev
1692017-03-04T08:33:08  *** Evel-Knievel has joined #bitcoin-core-dev
1702017-03-04T08:34:01  *** d9b4bef9 has quit IRC
1712017-03-04T08:35:08  *** d9b4bef9 has joined #bitcoin-core-dev
1722017-03-04T09:21:51  *** dodomojo has joined #bitcoin-core-dev
1732017-03-04T09:24:14  *** Guyver2 has quit IRC
1742017-03-04T09:25:35  *** n1ce has quit IRC
1752017-03-04T09:26:10  *** dodomojo has quit IRC
1762017-03-04T09:26:32  *** n1ce has joined #bitcoin-core-dev
1772017-03-04T09:30:35  *** AaronvanW has joined #bitcoin-core-dev
1782017-03-04T09:46:29  *** Robinson has joined #bitcoin-core-dev
1792017-03-04T10:15:58  *** dodomojo has joined #bitcoin-core-dev
1802017-03-04T10:20:25  *** dodomojo has quit IRC
1812017-03-04T10:27:03  *** Victor_sueca is now known as Victorsueca
1822017-03-04T10:33:36  *** wvr has quit IRC
1832017-03-04T10:35:52  *** Aaronvan_ has joined #bitcoin-core-dev
1842017-03-04T10:37:00  *** AaronvanW has quit IRC
1852017-03-04T10:41:41  *** AaronvanW has joined #bitcoin-core-dev
1862017-03-04T10:41:41  *** AaronvanW has joined #bitcoin-core-dev
1872017-03-04T10:45:35  *** nemgun has quit IRC
1882017-03-04T10:49:27  *** Ylbam has joined #bitcoin-core-dev
1892017-03-04T10:56:08  *** afk11_ has quit IRC
1902017-03-04T11:11:41  *** MarcoFalke has joined #bitcoin-core-dev
1912017-03-04T12:35:30  *** MarcoFalke has quit IRC
1922017-03-04T12:44:49  *** MarcoFalke has joined #bitcoin-core-dev
1932017-03-04T12:48:57  *** MarcoFalke has quit IRC
1942017-03-04T12:53:11  *** MarcoFalke has joined #bitcoin-core-dev
1952017-03-04T13:14:46  <wumpus> whee I have RPC working over a UNIX socket
1962017-03-04T13:16:08  *** Giszmo has quit IRC
1972017-03-04T13:19:27  <wumpus> needed no changes to libevent on the server side. however to make bitcoin-cli be able to http over a UNIX socket needs a small change.
1982017-03-04T14:12:35  *** Giszmo has joined #bitcoin-core-dev
1992017-03-04T14:15:26  *** JackH has quit IRC
2002017-03-04T14:15:54  *** Robinson has quit IRC
2012017-03-04T14:24:38  *** riemann has joined #bitcoin-core-dev
2022017-03-04T14:24:44  *** Giszmo has quit IRC
2032017-03-04T15:07:55  *** Giszmo has joined #bitcoin-core-dev
2042017-03-04T15:08:14  *** Taek42 is now known as Taek
2052017-03-04T15:32:08  *** bityogi has joined #bitcoin-core-dev
2062017-03-04T15:40:20  *** dodomojo has joined #bitcoin-core-dev
2072017-03-04T15:45:00  *** dodomojo has quit IRC
2082017-03-04T15:45:48  *** Giszmo has quit IRC
2092017-03-04T15:46:32  <bitcoin-git> [bitcoin] laanwj opened pull request #9919: UNIX sockets support for RPC (master...2017_03_unix_socket) https://github.com/bitcoin/bitcoin/pull/9919
2102017-03-04T16:00:57  *** Giszmo has joined #bitcoin-core-dev
2112017-03-04T16:09:48  *** xiangfu has quit IRC
2122017-03-04T16:15:43  *** jtimon has joined #bitcoin-core-dev
2132017-03-04T16:15:45  *** xiangfu has joined #bitcoin-core-dev
2142017-03-04T16:40:59  *** laurentmt has joined #bitcoin-core-dev
2152017-03-04T16:42:00  *** laurentmt has quit IRC
2162017-03-04T17:10:04  *** Giszmo has quit IRC
2172017-03-04T17:12:04  *** Giszmo has joined #bitcoin-core-dev
2182017-03-04T17:16:31  *** Sosumi has joined #bitcoin-core-dev
2192017-03-04T18:00:22  *** belcher has quit IRC
2202017-03-04T18:00:40  <sipa> wumpus: nice
2212017-03-04T18:06:03  *** str4d has joined #bitcoin-core-dev
2222017-03-04T18:08:26  *** belcher has joined #bitcoin-core-dev
2232017-03-04T18:22:45  *** dodomojo has joined #bitcoin-core-dev
2242017-03-04T18:27:16  *** dodomojo has quit IRC
2252017-03-04T18:42:22  *** neha has quit IRC
2262017-03-04T18:44:11  *** neha has joined #bitcoin-core-dev
2272017-03-04T19:04:35  *** Giszmo has quit IRC
2282017-03-04T19:04:58  *** Giszmo has joined #bitcoin-core-dev
2292017-03-04T19:09:35  *** jtimon has quit IRC
2302017-03-04T19:34:16  *** bityogi has quit IRC
2312017-03-04T19:37:01  *** wudayoda has joined #bitcoin-core-dev
2322017-03-04T19:47:29  *** wudayoda has quit IRC
2332017-03-04T19:52:52  *** Guyver2 has joined #bitcoin-core-dev
2342017-03-04T20:00:57  *** neha has quit IRC
2352017-03-04T20:02:36  *** neha has joined #bitcoin-core-dev
2362017-03-04T20:11:13  *** dodomojo has joined #bitcoin-core-dev
2372017-03-04T20:15:25  *** dodomojo has quit IRC
2382017-03-04T20:17:59  *** wudayoda has joined #bitcoin-core-dev
2392017-03-04T20:23:21  *** wudayoda has quit IRC
2402017-03-04T20:25:55  *** To7 has joined #bitcoin-core-dev
2412017-03-04T20:26:00  *** abhishekcs10_ has joined #bitcoin-core-dev
2422017-03-04T20:48:48  *** Giszmo has quit IRC
2432017-03-04T20:50:26  *** wudayoda has joined #bitcoin-core-dev
2442017-03-04T20:54:58  *** wudayoda has quit IRC
2452017-03-04T21:06:54  *** murchandamus11 has joined #bitcoin-core-dev
2462017-03-04T21:07:12  *** rabidus_ has joined #bitcoin-core-dev
2472017-03-04T21:07:23  *** BashCo_ has joined #bitcoin-core-dev
2482017-03-04T21:12:03  *** Giszmo has joined #bitcoin-core-dev
2492017-03-04T21:13:10  <Lightsword> wumpus, would it be easy to also do block notifications over the unix socket?
2502017-03-04T21:13:19  *** Guyver2 has quit IRC
2512017-03-04T21:13:19  *** str4d has quit IRC
2522017-03-04T21:13:20  *** BashCo has quit IRC
2532017-03-04T21:13:20  *** harrymm has quit IRC
2542017-03-04T21:13:20  *** isle2983 has quit IRC
2552017-03-04T21:13:20  *** harding has quit IRC
2562017-03-04T21:13:20  *** haakonn has quit IRC
2572017-03-04T21:14:21  <Lightsword> current ckpool local block notification method is basically to execute a binary that then writes to a unix socket for notification of a block
2582017-03-04T21:14:23  *** MarcoFalke has quit IRC
2592017-03-04T21:14:23  *** AaronvanW has quit IRC
2602017-03-04T21:14:23  *** Evel-Knievel has quit IRC
2612017-03-04T21:14:23  *** justanotheruser has quit IRC
2622017-03-04T21:14:23  *** murchandamus1 has quit IRC
2632017-03-04T21:14:24  *** rabidus has quit IRC
2642017-03-04T21:14:24  *** baldur has quit IRC
2652017-03-04T21:14:25  *** pindarhk has quit IRC
2662017-03-04T21:14:25  *** squidicuz has quit IRC
2672017-03-04T21:14:26  *** so has quit IRC
2682017-03-04T21:14:28  *** Sosumi has quit IRC
2692017-03-04T21:15:23  *** MarcoFalke has joined #bitcoin-core-dev
2702017-03-04T21:17:40  *** justanotheruser has joined #bitcoin-core-dev
2712017-03-04T21:18:41  *** AaronvanW has joined #bitcoin-core-dev
2722017-03-04T21:18:41  *** Evel-Knievel has joined #bitcoin-core-dev
2732017-03-04T21:18:41  *** baldur has joined #bitcoin-core-dev
2742017-03-04T21:18:41  *** pindarhk has joined #bitcoin-core-dev
2752017-03-04T21:18:41  *** squidicuz has joined #bitcoin-core-dev
2762017-03-04T21:20:11  *** so has joined #bitcoin-core-dev
2772017-03-04T21:21:15  *** wudayoda has joined #bitcoin-core-dev
2782017-03-04T21:25:57  *** wudayoda has quit IRC
2792017-03-04T21:27:57  *** Giszmo has quit IRC
2802017-03-04T21:29:44  *** bityogi has joined #bitcoin-core-dev
2812017-03-04T21:33:51  <wumpus> Lightsword: everything that an be done over the current P2P port can also be done over the UNIX socket
2822017-03-04T21:33:56  <wumpus> eh, RPC port
2832017-03-04T21:34:33  <wumpus> I guess what you're looking for is #7949
2842017-03-04T21:34:35  <gribble> https://github.com/bitcoin/bitcoin/issues/7949 | [RPC] Add RPC long poll notifications by jonasschnelli · Pull Request #7949 · bitcoin/bitcoin · GitHub
2852017-03-04T21:35:16  <Lightsword> wumpus, not long polling, having bitcoind itself write to another app’s listening unix socket for notifications
2862017-03-04T21:36:47  *** Guyver2 has joined #bitcoin-core-dev
2872017-03-04T21:43:16  <wumpus> conceptually it's the same, apart from who calls who. In both cases the listeners get immediate notification. Longpolling is simpler as bitcoind doesn't need to keep track of who to notify, that's implied by who is listening
2882017-03-04T21:43:36  <wumpus> block notifications can also be broadcast over zeromq
2892017-03-04T21:48:37  *** dgenr8 has quit IRC
2902017-03-04T21:53:19  *** wudayoda has joined #bitcoin-core-dev
2912017-03-04T21:58:12  *** wudayoda has quit IRC
2922017-03-04T21:59:23  *** dodomojo has joined #bitcoin-core-dev
2932017-03-04T22:02:42  *** haakonn has joined #bitcoin-core-dev
2942017-03-04T22:02:42  *** str4d has joined #bitcoin-core-dev
2952017-03-04T22:02:42  *** harrymm has joined #bitcoin-core-dev
2962017-03-04T22:02:42  *** isle2983 has joined #bitcoin-core-dev
2972017-03-04T22:02:42  *** harding has joined #bitcoin-core-dev
2982017-03-04T22:03:27  *** dodomojo has quit IRC
2992017-03-04T22:04:02  *** haakonn is now known as Guest32541
3002017-03-04T22:10:19  *** Giszmo has joined #bitcoin-core-dev
3012017-03-04T22:15:35  *** chjj has quit IRC
3022017-03-04T22:17:31  *** bityogi has quit IRC
3032017-03-04T22:25:34  *** wudayoda has joined #bitcoin-core-dev
3042017-03-04T22:29:27  *** chjj has joined #bitcoin-core-dev
3052017-03-04T22:30:22  *** wudayoda has quit IRC
3062017-03-04T22:37:03  <jeremyrubin> how does one CreateNewBlock s.t. a witness is added?
3072017-03-04T22:37:42  <jeremyrubin> I'm having trouble writing a unit test using TestChain100 once segwit activates
3082017-03-04T22:43:02  <sipa> you need at least 3 retarget periods worth of blocks
3092017-03-04T22:44:40  *** Guyver2 has quit IRC
3102017-03-04T22:44:52  <jeremyrubin> ah so I need to be at > 432
3112017-03-04T22:48:46  <sipa> right
3122017-03-04T22:49:07  <sipa> 1 period before signalling starts, another before it's locked in, and a third before it is active
3132017-03-04T22:49:22  <jeremyrubin> hm ok
3142017-03-04T22:49:31  <jeremyrubin> that helped
3152017-03-04T22:49:37  <jeremyrubin> now I get witness mismatch
3162017-03-04T22:53:40  *** dodomojo has joined #bitcoin-core-dev
3172017-03-04T22:56:17  *** wudayoda has joined #bitcoin-core-dev
3182017-03-04T22:57:49  *** dodomojo has quit IRC
3192017-03-04T22:59:16  <jeremyrubin>     CMutableTransaction n;
3202017-03-04T22:59:16  <jeremyrubin>     {
3212017-03-04T22:59:16  <jeremyrubin>         std::vector<CMutableTransaction> txns;
3222017-03-04T22:59:16  <jeremyrubin>         n.vin.resize(1);
3232017-03-04T22:59:16  <jeremyrubin>         n.vin[0].prevout = COutPoint(txSpend.GetHash(), 0);
3242017-03-04T22:59:18  <jeremyrubin>         n.vout.resize(25);
3252017-03-04T22:59:21  <jeremyrubin>         n.nVersion = 1;
3262017-03-04T22:59:23  <jeremyrubin>         n.nLockTime = 0;
3272017-03-04T22:59:26  <jeremyrubin>         n.vin[0].scriptWitness = CScriptWitness();
3282017-03-04T22:59:28  <jeremyrubin>         n.vin[0].nSequence = CTxIn::SEQUENCE_FINAL;
3292017-03-04T22:59:31  <jeremyrubin>         for (auto& v : n.vout) {
3302017-03-04T22:59:33  <jeremyrubin>             v.scriptPubKey = CScript();
3312017-03-04T22:59:36  <jeremyrubin>             v.nValue = txSpend.vout[0].nValue / n.vout.size();
3322017-03-04T22:59:38  <jeremyrubin>         }
3332017-03-04T22:59:41  <jeremyrubin>         txns.push_back(n);
3342017-03-04T22:59:44  <jeremyrubin>         CreateAndProcessBlock(txns, scriptPubKey);
3352017-03-04T22:59:46  <jeremyrubin>     }
3362017-03-04T23:00:00  <jeremyrubin> (that's the part of the test I'm trying to write)
3372017-03-04T23:00:48  *** wudayoda has quit IRC
3382017-03-04T23:01:32  *** wasi has quit IRC
3392017-03-04T23:02:12  *** wasi has joined #bitcoin-core-dev
3402017-03-04T23:02:24  <sipa> please don't paste more than 3 lines
3412017-03-04T23:03:44  <jeremyrubin> sorry; forgot
3422017-03-04T23:17:03  *** Giszmo has quit IRC
3432017-03-04T23:27:41  *** wudayoda has joined #bitcoin-core-dev
3442017-03-04T23:32:36  *** wudayoda has quit IRC
3452017-03-04T23:47:38  *** dodomojo has joined #bitcoin-core-dev
3462017-03-04T23:52:04  *** dodomojo has quit IRC
3472017-03-04T23:54:36  *** riemann has quit IRC
3482017-03-04T23:59:43  *** wudayoda has joined #bitcoin-core-dev