1 2016-09-07 02:08:25	0|GitHub16|[13bitcoin] 15isle2983 opened pull request #8674: tools for analyzing, updating and adding copyright headers in souce files (06master...06copyright-scripts) 02https://github.com/bitcoin/bitcoin/pull/8674
  2 2016-09-07 02:11:10	0|GitHub51|[13bitcoin] 15isle2983 opened pull request #8675: Make copyright header lines uniform (06master...06copyright-made-uniform) 02https://github.com/bitcoin/bitcoin/pull/8675
  3 2016-09-07 02:16:58	0|GitHub38|[13bitcoin] 15isle2983 opened pull request #8676: Add missing copyright headers (06master...06missing-copyright) 02https://github.com/bitcoin/bitcoin/pull/8676
  4 2016-09-07 08:31:26	0|gmaxwell|Perhaps some release advice for us, https://blogs.msdn.microsoft.com/oldnewthing/20160906-00/?p=94255
  5 2016-09-07 08:35:06	0|jonasschnelli|gmaxwell: so we need to have a backdrop wallpaper in Qt: :)
  6 2016-09-07 08:35:40	0|jonasschnelli|But besides that, I think different splash screens between major versions would indeed be good
  7 2016-09-07 08:36:03	0|jonasschnelli|Not sure how to adapt this to bitcoind though, :)
  8 2016-09-07 08:37:39	0|Yogh|print a hot original welcome message when starting the daemon?
  9 2016-09-07 08:37:42	0|gmaxwell|just the general principle that if the chrome doesn't change many people will assume not much has changed.
 10 2016-09-07 11:10:47	0|GitHub123|13bitcoin/06master 14144ed76 15Pieter Wuille: Fix some locks...
 11 2016-09-07 11:10:47	0|GitHub123|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8ea44405e76f...e2a1a1ee8951
 12 2016-09-07 11:10:48	0|GitHub123|13bitcoin/06master 14e2a1a1e 15Pieter Wuille: Merge #8606: Fix some locks...
 13 2016-09-07 11:10:56	0|GitHub69|[13bitcoin] 15sipa closed pull request #8606: Fix some locks (06master...06lockfix) 02https://github.com/bitcoin/bitcoin/pull/8606
 14 2016-09-07 11:20:19	0|GitHub6|13bitcoin/06master 14eb3596f 15Gregory Maxwell: Do not add random inbound peers to addrman....
 15 2016-09-07 11:20:19	0|GitHub6|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e2a1a1ee8951...5b2ea29cf4fd
 16 2016-09-07 11:20:20	0|GitHub6|13bitcoin/06master 145b2ea29 15Pieter Wuille: Merge #8594: Do not add random inbound peers to addrman....
 17 2016-09-07 11:20:34	0|GitHub39|[13bitcoin] 15sipa closed pull request #8594: Do not add random inbound peers to addrman. (06master...06no_inbound_addr) 02https://github.com/bitcoin/bitcoin/pull/8594
 18 2016-09-07 11:54:07	0|GitHub136|[13bitcoin] 15paveljanik opened pull request #8677: Do not shadow upper local variable 'send', prevent -Wshadow compiler warning. (06master...0620160907_Wshadow_8606) 02https://github.com/bitcoin/bitcoin/pull/8677
 19 2016-09-07 14:06:38	0|OxADADA|sup
 20 2016-09-07 14:08:55	0|GitHub150|[13bitcoin] 15jonasschnelli opened pull request #8678: [Qt][CoinControl] fix UI bug that could result in paying unexpected fee (06master...062016/09/qt_cc_ui_radrio_fix) 02https://github.com/bitcoin/bitcoin/pull/8678
 21 2016-09-07 14:47:07	0|GitHub71|[13bitcoin] 15sipa opened pull request #8679: [0.13] Various backports (060.13...06backports_0.13) 02https://github.com/bitcoin/bitcoin/pull/8679
 22 2016-09-07 16:56:18	0|skyraider|trying to make setup.py install find a package with wheels-only (no sdist) archives on pypi. pythonwheels.com claims setuptools supports wheels, but https://github.com/pypa/setuptools/issues/558 claims setuptools does not support wheels. i'm running into "No local packages or working download links found for mypackage==myversion".
 23 2016-09-07 16:56:27	0|skyraider|wrong channel, disregard.
 24 2016-09-07 17:23:16	0|GitHub157|[13bitcoin] 15theuni opened pull request #8680: Address Travis spurious failures (06master...06rpc-waitforblock) 02https://github.com/bitcoin/bitcoin/pull/8680
 25 2016-09-07 17:26:57	0|GitHub23|[13bitcoin] 15MarcoFalke closed pull request #8644: [0.13 backport] Check for compatibility with download in FindNextBlocksToDownload (060.13...06findnext_backport) 02https://github.com/bitcoin/bitcoin/pull/8644
 26 2016-09-07 17:37:27	0|GitHub1|13bitcoin/06master 14426e7bc 15Jeremy Rubin: Fix obvious assignment/equality error in test
 27 2016-09-07 17:37:27	0|GitHub1|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5b2ea29cf4fd...ec139a5621a9
 28 2016-09-07 17:37:28	0|GitHub1|13bitcoin/06master 14ec139a5 15MarcoFalke: Merge #8673: Trivial: Fix obvious assignment/equality error in test...
 29 2016-09-07 17:37:42	0|GitHub128|[13bitcoin] 15MarcoFalke closed pull request #8673: Trivial: Fix obvious assignment/equality error in test (06master...06fix_arith_tests_trivial) 02https://github.com/bitcoin/bitcoin/pull/8673
 30 2016-09-07 18:15:12	0|sipa|MarcoFalke oops, i missed you already had a backport
 31 2016-09-07 19:25:09	0|morcos|sipa: i'm trying to dive back into things now, and picking up the benchmarking for speeding up ConnectBlock to try and help jeremyrubin's stuff get finalized.  It appears that connecting transactions slowed down somewhat significantly in master.  I think this is due to 8524.
 32 2016-09-07 19:25:43	0|morcos|For now those hash calculations are just extraneous, but even post segwit, i think the effect is you've moved the hashing from something thats parallelized to something thats not
 33 2016-09-07 19:26:56	0|morcos|the benefit of solving the O(n^2) problem dominates of course in the worst case, but in the typical case, i think this is maybe a slowdown we'd like to avoid
 34 2016-09-07 19:27:18	0|morcos|just wondering if you'd thought about any of this, or whether it makes sense to store these hashes from ATMP?
 35 2016-09-07 19:28:51	0|sipa|morcos: i'm perfectly fine with moving the hashing to a more parallellizable place
 36 2016-09-07 19:29:08	0|gmaxwell|Why was it parallel before but not now?  I don't think we care if there is parallel hashing within a single transaction (that seems too fine grained to me), so long as multiple transactions could run in parallel?
 37 2016-09-07 19:29:32	0|sipa|all sighash precalc now runs in the main thread
 38 2016-09-07 19:29:45	0|morcos|its tricky to parallelize because then you need to synchronize a cache for them right... which is what you were trying to avoid
 39 2016-09-07 19:30:16	0|gmaxwell|but the cache need not be shared across transactions
 40 2016-09-07 19:30:50	0|morcos|gmaxwell: yeah what sipa said, the main thread which is connecting the transactions going to end up being the bottle neck,  not sure how many script verification cores are required for that to be the case, but its good to not push more and more stuff into that
 41 2016-09-07 19:31:15	0|sipa|though it does run simultaneously with other transactions' normal signature checks
 42 2016-09-07 19:31:28	0|morcos|perhaps there is a design that puts all scriptchecks from a single tx onto a single thread
 43 2016-09-07 19:31:30	0|sipa|but yes, for the average case, moving more into the main thread is not good
 44 2016-09-07 19:32:08	0|morcos|but that breaks down for a really big tx
 45 2016-09-07 19:32:47	0|gmaxwell|ah, main thread. but .. yes, I think you should keep the scriptchecks for a single transaction togeather, process them as a group, and share the hashing along with them.  ... it wouldn't exploit parallelism for big transactions, but I don't know if thats really needed.
 46 2016-09-07 19:34:01	0|jeremyrubin|i think maybe if you can estimate by #inputs or something
 47 2016-09-07 19:34:24	0|jeremyrubin|and split it if too big
 48 2016-09-07 19:34:35	0|jeremyrubin|but you won't be parallel if you have, say, one big txn
 49 2016-09-07 19:34:42	0|gmaxwell|previously the dispatch overhead made that irrelevant-- but perhaps with jeremyrubin's work the overhead is low enough to make that kind of parallelism useful for something.
 50 2016-09-07 19:36:45	0|morcos|so what are your thoughts on caching the hashes for a tx in AcceptToMemoryPool and then the main thread can still check that first before calculating them itself, so maybe that would be pretty fast
 51 2016-09-07 19:37:26	0|morcos|would need only simple synchronization on that b/c its only accessed by ATMP and the main thread
 52 2016-09-07 19:37:30	0|jeremyrubin|What about using some kind of atomic future for the hashes
 53 2016-09-07 19:37:44	0|jeremyrubin|First script check to get there evaluates it and fills it in?
 54 2016-09-07 19:37:47	0|gmaxwell|uh the cacheline bouncing, it hurts.
 55 2016-09-07 19:38:08	0|gmaxwell|morcos: similar to how we have the transaction id hash just calculated once (hopefully) and carried around with the transaction?
 56 2016-09-07 19:38:09	0|jeremyrubin|Well...
 57 2016-09-07 19:38:12	0|jeremyrubin|actually not that bad
 58 2016-09-07 19:38:27	0|jeremyrubin|MESI state only causes invalidation on write
 59 2016-09-07 19:38:34	0|jeremyrubin|which happens once
 60 2016-09-07 19:38:45	0|gmaxwell|there is no actual meaningful concurrency here, however.
 61 2016-09-07 19:39:46	0|gmaxwell|only false concurency created by logistics.  (to the extent this hashing is done multiple times, it's only because its being done redundantly)
 62 2016-09-07 19:41:12	0|gmaxwell|morcos: or store validation flags in the mempool and assume valid if the same flags are still in effect ...
 63 2016-09-07 19:41:36	0|sdaftuar|gmaxwell: gah
 64 2016-09-07 19:41:40	0|morcos|gmaxwell: ha, the validation cache, that scares me!
 65 2016-09-07 19:42:02	0|morcos|but yeah i think easy enough to just store the hashes
 66 2016-09-07 19:45:18	0|morcos|ok, well not an emergency, just wanted to see what thoughts you guys had, will circle back when we have a proposed change
 67 2016-09-07 20:21:45	0|Chris_Stewart_5|jeremyrubin: With your new pull request (#8670), are you suggesting writing a new testing framework specific to bitcoin from scratch?
 68 2016-09-07 20:36:39	0|jeremyrubin|The content of the tests will not change, just the runner.
 69 2016-09-07 20:36:45	0|jeremyrubin|Chris_Stewart_5: ^^
 70 2016-09-07 21:54:23	0|sipa|jeremyrubin: feature request: a command line argument to make the binary crash on test failure
 71 2016-09-07 21:54:30	0|sipa|so a core dump file gets created
 72 2016-09-07 21:57:01	0|jeremyrubin|sipa: please put in the issue to keep it catalouged
 73 2016-09-07 21:57:18	0|jeremyrubin|but good suggestion; I was trying to get core dumps on travis for a while and couldn't
 74 2016-09-07 22:08:08	0|kanzure|what were you trying? the after_failure stuff wasn't working for you or something? or it did work, but couldn't find the actual core dumps, and therefore couldn't upload those somewhere?
 75 2016-09-07 22:08:26	0|kanzure|btw i also think running gdb bt might be good enough in after_failure
 76 2016-09-07 22:08:36	0|kanzure|perhaps once for each core dump too
 77 2016-09-07 22:12:35	0|sipa|jeremyrubin: agree, will report on issur
 78 2016-09-07 22:16:00	0|kanzure|jeremyrubin: for 8670 perhaps the silly xml outputs should be considered, and (separately) compatibility with mutation testing.
 79 2016-09-07 22:18:50	0|jeremyrubin|kanzure: how about jsons the kids like those these days
 80 2016-09-07 22:19:28	0|kanzure|yeah but i forget the name of the json test output 'standard'/format
 81 2016-09-07 22:20:02	0|BlueMatt|kanzure: how about the first personw ho needs that can implement it
 82 2016-09-07 22:20:17	0|gmaxwell|ugh
 83 2016-09-07 22:20:21	0|kanzure|BlueMatt: the issuetext is asking for
 84 2016-09-07 22:20:25	0|kanzure|ok whatever. i don't care.
 85 2016-09-07 22:21:26	0|kanzure|it would be more efficient to complain about the issue text in particular in the future :)
 86 2016-09-07 22:21:40	0|BlueMatt|yes
 87 2016-09-07 22:48:50	0|veleiro|Im trying to build v0.13.0 from source on a beaglebone black with debian jessie, i had to compile db4.8 from source but i installed libboost-all-dev, but in the ./configure stage the error i see is "configure: error: No working boost sleep implementation found." I went through https://github.com/bitcoin/bitcoin/issues/3003 with no success
 88 2016-09-07 22:49:33	0|veleiro|also, the build readme isnt clear about compiling boost from source
 89 2016-09-07 22:49:53	0|sipa|that's surprising
 90 2016-09-07 22:50:06	0|sipa|libboost-all-dev should have a sleep implementatio
 91 2016-09-07 22:50:21	0|sipa|is itp possible you have multiple boost versions side by side?
 92 2016-09-07 22:52:15	0|veleiro|its possible that i may have tried to compile boost from source when i went through this before, but it was a few weeks, but wouldnt ./configure use the system package version unless specified otherwise?
 93 2016-09-07 22:53:05	0|veleiro|i'll try to remove all boost and see whats left over
 94 2016-09-07 22:53:41	0|sipa|it searches in many places
 95 2016-09-07 22:53:59	0|sipa|what os is this?
 96 2016-09-07 22:54:03	0|sipa|and diatribution
 97 2016-09-07 22:54:08	0|veleiro|debian 8 jessie
 98 2016-09-07 22:54:15	0|veleiro|on armv7
 99 2016-09-07 22:54:25	0|sipa|that should work fine
100 2016-09-07 22:54:34	0|sipa|you can also try to do a depends build
101 2016-09-07 22:54:48	0|GitHub190|[13bitcoin] 15JeremyRubin opened pull request #8681: Performance Regression Fix: Pre-Allocate txChanged vector (06master...06fix-perf-regressed-txChanged) 02https://github.com/bitcoin/bitcoin/pull/8681
102 2016-09-07 22:54:48	0|sipa|which builds all dependencies for you and creates a static buildd
103 2016-09-07 22:56:38	0|veleiro|looks like something is also in /usr/local/include/boost/ after removing boost libraries. I'll try a depends build
104 2016-09-07 22:57:11	0|sipa|cd into depends/
105 2016-09-07 22:57:15	0|sipa|and follow the readme
106 2016-09-07 23:03:03	0|cfields|iirc "No working boost sleep" is kinda code for "boost failed to compile on the sleep test"
107 2016-09-07 23:03:41	0|cfields|i'd suggest that we fix that, except that the test can go away after the std::thread PR goes in
108 2016-09-07 23:07:46	0|sipa|\o/
109 2016-09-07 23:29:27	0|cfields|morcos / jeremyrubin: as jeremyrubin suggested above, here's a quick hack at a simple future for the new hashing: https://github.com/theuni/bitcoin/commit/e93f724f0554dae43063080ea9d6c87650315c6e
110 2016-09-07 23:30:33	0|cfields|in that commit the wait() is directly after the calculation, so it can only be worse. Would need to experiment with how early we can begin hashing to offload the most
111 2016-09-07 23:34:17	0|veleiro|error in depends build too :( got any ideas? I couldnt find anything right off: "error: toolset gcc initialization: error: provided command 'armv7l-unknown-linux-gnueabihf-g++' not found" (gcc version 4.9.2)
112 2016-09-07 23:35:04	0|jeremyrubin|cfields: that was fast
113 2016-09-07 23:36:52	0|jeremyrubin|Hm
114 2016-09-07 23:37:06	0|jeremyrubin|I like the general idea...
115 2016-09-07 23:38:27	0|jeremyrubin|Initially I figured that the scriptcheck threads could, on a first visited policy, compute these hashes.
116 2016-09-07 23:38:34	0|jeremyrubin|Obviously putting them earlier is better
117 2016-09-07 23:39:14	0|jeremyrubin|Also std::mutex is :/
118 2016-09-07 23:40:06	0|jeremyrubin|nicer to have cooridnation free.
119 2016-09-07 23:40:11	0|jeremyrubin|I have an idea
120 2016-09-07 23:40:19	0|jeremyrubin|CBlock is immutable?
121 2016-09-07 23:40:29	0|jeremyrubin|What if you just pass a pointer to it
122 2016-09-07 23:40:41	0|jeremyrubin|and have the background thread ONLY do all the hashes
123 2016-09-07 23:52:07	0|cfields|jeremyrubin: sure, it was just a quick hack. I figured it'd be helpful to have the scriptcheck threads do it, but that got complicated in my head pretty quickly. Figured it'd be worth experimenting before committing to the complication
124 2016-09-07 23:53:09	0|cfields|jeremyrubin: i don't think the overhead of the mutex/condvar is significant enough to throw off the "is it worth doing" tests :)
125 2016-09-07 23:55:00	0|cfields|jeremyrubin: and sure, makes sense to do on the per-block level, but only if we don't end up caching in ATMP