1 2016-05-10 01:18:45	0|GitHub94|[13bitcoin] 15wtogami opened pull request #8033: Fix Socks5() connect failures to be less noisy and unnecessarily scary (06master...06proxy_fail_too_scary) 02https://github.com/bitcoin/bitcoin/pull/8033
  2 2016-05-10 06:40:24	0|GitHub23|[13bitcoin] 15fanquake opened pull request #8034: [doc][trivial] Add basic git squash workflow (06master...06contrib-squash) 02https://github.com/bitcoin/bitcoin/pull/8034
  3 2016-05-10 07:18:04	0|jonasschnelli|I'm impressed how bitcoin-core does perform on a 29$ computer (Pine64). Progress=0.5~ in <24h. dbcache=1500. Using a cheap/slow USB stick.
  4 2016-05-10 07:30:07	0|btcdrak|jonasschnelli: did your Pine64 arrive already?
  5 2016-05-10 07:30:21	0|jonasschnelli|Yes. Its syncing next to me.
  6 2016-05-10 07:30:27	0|wumpus|jonasschnelli: nice result
  7 2016-05-10 07:31:22	0|jonasschnelli|I really think this machine could allow my long-term goal: a full node in a box for ~50USD.
  8 2016-05-10 07:32:13	0|jonasschnelli|Nice casing, some led for status indicator. Could come with a 128GB usb stick with the blockchain preloaded. People can refect/re-IBD if they like (led could indicate re-index)
  9 2016-05-10 07:32:26	0|jonasschnelli|"your bank at home"
 10 2016-05-10 07:39:45	0|wumpus|sipa: how do you measure exact cycle counts in #8020?
 11 2016-05-10 07:41:14	0|wumpus|jonasschnelli: such a thing has also always been my plan, but yes up to now devices have always been too weak for that. People using bitcoind on a RPi are just practicing masochism.
 12 2016-05-10 07:41:59	0|jonasschnelli|wumpus: Agree. Ordoid and Pine are capable. RPi is probably not.
 13 2016-05-10 07:42:52	0|jonasschnelli|can you measure it with gdb by stepping single instructions?
 14 2016-05-10 07:42:58	0|jonasschnelli|(on ASM level)
 15 2016-05-10 07:44:05	0|wumpus|I think he uses 'performance counters' with some profiler, it's certainly possible to count instructions and cycles with linux' 'perf' for example on a larger scale but I've never been able to do so on a per-function level
 16 2016-05-10 07:44:20	0|wumpus|so yes I wonder what exact software
 17 2016-05-10 07:45:44	0|wumpus|try 'perf stat ls' for example
 18 2016-05-10 07:48:19	0|wumpus|of course the number of cycles will be different per CPU type, even between different vendors and models
 19 2016-05-10 07:49:00	0|wumpus|but still it's nice to be able to measure it that precisely
 20 2016-05-10 07:52:56	0|wumpus|what is possible with perf is 'sampling' e.g. making it probe the counters a certain number of amount per second, it's possible t ocreate some nice flame graph diagrams that way where most of resources are spent: http://www.brendangregg.com/flamegraphs.html
 21 2016-05-10 07:54:04	0|wumpus|there is even a 'perf top' to see what processes/functions consume most CPU cycles globally
 22 2016-05-10 07:58:16	0|jonasschnelli|`perf top` is nice
 23 2016-05-10 07:58:30	0|jonasschnelli|hah: 33.96%  bitcoind                   [.] (anonymous namespace)::sha256::Transform(unsigned int*, unsigned char const*)
 24 2016-05-10 08:00:28	0|wumpus|heh yes bitcoind spends a lot of time in sha256, leveldb spends a lot of time in crc32c
 25 2016-05-10 08:01:20	0|wumpus|a more optimized sha256 (for example using sse intrinsics) could likely speed up things, there's so much hashing
 26 2016-05-10 08:02:26	0|wumpus|this is why everyone wants the cpus with sha256 instructions to be finally released
 27 2016-05-10 08:02:37	0|wumpus|which reminds me, jonasschnelli what are the extension bits in /proc/cpuinfo on your aarch64 board?
 28 2016-05-10 08:03:04	0|wumpus|odroid C2 had the crc32 extension but not sha :(
 29 2016-05-10 08:03:15	0|wumpus|s/had/has
 30 2016-05-10 08:03:31	0|jonasschnelli|hah: Features	: fp asimd aes pmull sha1 sha2 crc32
 31 2016-05-10 08:03:38	0|wumpus|awesome!
 32 2016-05-10 08:03:50	0|jonasschnelli|(but the pref stats above are from a different computer)
 33 2016-05-10 08:03:59	0|wumpus|Features        : fp asimd crc32
 34 2016-05-10 08:04:18	0|wumpus|I'd expected so: perf stat and friends by far work best on x86
 35 2016-05-10 08:04:53	0|wumpus|performance counter support for other CPUs is stil catching up, though it sometimes works
 36 2016-05-10 08:05:07	0|jonasschnelli|Would openCL be something to speed up SHA256 batch calculation? At least for desktop pcs?
 37 2016-05-10 08:05:55	0|wumpus|in any case from what I understand this means you can use the vsha256hq_u32 vsha256h2q_u32 vsha256su0q_u32 vsha256su1q_u32 NEON intrinsics on that board
 38 2016-05-10 08:06:33	0|wumpus|I don't know yet how to implement sha256::Transform with them, as I lost interest as it's not possible with my board, but it should be possible :-)
 39 2016-05-10 08:07:02	0|jonasschnelli|Hmm... yes. This sounds after another weekend project. :)
 40 2016-05-10 08:07:12	0|jonasschnelli|But free weekends are so precious and rare!
 41 2016-05-10 08:08:22	0|wumpus|sha256 is an inherently linear operation, I'm not sure how well itlends itself to OpenCL paralellization. Indeed maybe if you can manage to queue up a lot of different things to be  SHA256'ed at once
 42 2016-05-10 08:08:37	0|wumpus|same for doing secp256k1 operations in opencl
 43 2016-05-10 08:09:16	0|wumpus|at the least, GPUs became a lot better with integer operations compared to the time I used it a lot, partially thanks to bitcoin mining :-)
 44 2016-05-10 08:09:28	0|jonasschnelli|Yes. But the main problems is probably how to split of batches and not loose performance in syncing back these wored-down batches.
 45 2016-05-10 08:09:34	0|jonasschnelli|*worked
 46 2016-05-10 08:10:13	0|wumpus|yes, exactly, usually the problem is how to structure the work at a higher level
 47 2016-05-10 08:10:38	0|wumpus|in any case I think there is low hanging fruit in the form of better CPU implementations
 48 2016-05-10 08:11:35	0|jonasschnelli|Right. And I don't expect good GPUs in most bitcoind machines.
 49 2016-05-10 08:11:47	0|jonasschnelli|(mostly VPS/servers or barbones)
 50 2016-05-10 08:11:49	0|wumpus|e.g. there are also some practical issues with GPUs, they tend to be even less reliable (on average) than CPUs, and prone to overheating
 51 2016-05-10 08:12:48	0|wumpus|that too, who wants to use their high end gaming machine to sync the chain (except to show off how fast it can be done)
 52 2016-05-10 08:21:21	0|wumpus|paper about fast sha256 implementations using SSE4.2 and AVX instructions https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/sha-256-implementations-paper.pdf
 53 2016-05-10 08:33:41	0|GitHub195|13bitcoin/06master 143902a29 15Tyler Hardin: Qt: Delay user confirmation of send...
 54 2016-05-10 08:33:41	0|GitHub195|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4e14afe42fdd...b33824b76cbf
 55 2016-05-10 08:33:42	0|GitHub195|13bitcoin/06master 14b33824b 15Jonas Schnelli: Merge #8012: Qt: Delay user confirmation of send...
 56 2016-05-10 08:33:51	0|GitHub160|[13bitcoin] 15jonasschnelli closed pull request #8012: Qt: Delay user confirmation of send (06master...06send-delay) 02https://github.com/bitcoin/bitcoin/pull/8012
 57 2016-05-10 09:21:56	0|GitHub8|[13bitcoin] 15jonasschnelli opened pull request #8035: [Wallet] Add simplest BIP32/deterministic key generation implementation (06master...062016/05/simplest_hd) 02https://github.com/bitcoin/bitcoin/pull/8035
 58 2016-05-10 09:26:39	0|GitHub24|[13bitcoin] 15jonasschnelli closed pull request #6265: Add HD/Bip32 support (06master...062015/06/wallet_bip32) 02https://github.com/bitcoin/bitcoin/pull/6265
 59 2016-05-10 09:26:54	0|GitHub98|[13bitcoin] 15jonasschnelli closed pull request #7273: [Wallet] Simple HD/BIP32 support (06master...062016/01/hdsimple) 02https://github.com/bitcoin/bitcoin/pull/7273
 60 2016-05-10 09:27:45	0|gmaxwell|bluematt: sipa:  Another proposed implementation tweak for compactblocks:  The sender can use the formula to decide the length to send.  The reciever can then also use the formula, and if their mempool is too big for the number of bytes sent, it can just the top subset of the mempool.
 61 2016-05-10 09:29:50	0|jonasschnelli|gmaxwell, sipa: Maybe you find time to review the "simplest" HD PR: https://github.com/bitcoin/bitcoin/pull/8035
 62 2016-05-10 09:29:56	0|gmaxwell|BlueMatt: if you get sipa' implementation tweaks in, I'll get some public nodes up running it.   Maybe with a little hack to continually INV top of the mempool to you every block, in order to hotstart you.  (otherwise you have to run it for a day to get realistic hit rates)
 63 2016-05-10 09:30:06	0|gmaxwell|jonasschnelli: awesome.
 64 2016-05-10 09:30:57	0|jonasschnelli|Breaking up the CHDChain data-model would save another 10-20 lines. But would lead to a ugly design.
 65 2016-05-10 10:08:31	0|GitHub152|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b33824b76cbf...5767e80dda7a
 66 2016-05-10 10:08:32	0|GitHub152|13bitcoin/06master 14166e4b0 15Pavel Janík: Notify other serviceQueue thread we are finished to prevent deadlocks.
 67 2016-05-10 10:08:32	0|GitHub152|13bitcoin/06master 14db18ab2 15Pavel Janík: Reenable multithread scheduler test.
 68 2016-05-10 10:08:33	0|GitHub152|13bitcoin/06master 145767e80 15Wladimir J. van der Laan: Merge #8016: Fix multithread CScheduler and reenable test...
 69 2016-05-10 10:08:41	0|GitHub32|[13bitcoin] 15laanwj closed pull request #8016: Fix multithread CScheduler and reenable test (06master...0620160506_multithread_CScheduler) 02https://github.com/bitcoin/bitcoin/pull/8016
 70 2016-05-10 10:09:21	0|GitHub142|[13bitcoin] 15laanwj closed pull request #8005: Add a comment indicating that the btc devs don't want a warning fixed (06master...06note-that-unused-function-compiler-warning-should-not-be-fixed) 02https://github.com/bitcoin/bitcoin/pull/8005
 71 2016-05-10 10:30:18	0|paveljanik|jonasschnelli, great work on the HD wallet!
 72 2016-05-10 10:43:46	0|GitHub184|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5767e80dda7a...f7a21dae5dbf
 73 2016-05-10 10:43:47	0|GitHub184|13bitcoin/06master 14657e07e 15instagibbs: Rename ReconsiderBlock func to reflect real behavior
 74 2016-05-10 10:43:47	0|GitHub184|13bitcoin/06master 14addb9d2 15instagibbs: Remove state arg from ReconsiderBlock
 75 2016-05-10 10:43:48	0|GitHub184|13bitcoin/06master 14f7a21da 15Wladimir J. van der Laan: Merge #8019: Remove state arg from ReconsiderBlock, rename to ResetBlockFailureFlags...
 76 2016-05-10 10:43:56	0|GitHub167|[13bitcoin] 15laanwj closed pull request #8019: Remove state arg from ReconsiderBlock, rename to ResetBlockFailureFlags (06master...06reblarg) 02https://github.com/bitcoin/bitcoin/pull/8019
 77 2016-05-10 10:57:06	0|GitHub126|[13bitcoin] 15laanwj opened pull request #8036: init: Move berkeleydb version reporting to wallet (06master...062016_05_berkeleydb_report_in_wallet) 02https://github.com/bitcoin/bitcoin/pull/8036
 78 2016-05-10 13:16:29	0|GitHub58|13bitcoin/06master 143e2c946 15Wladimir J. van der Laan: init: Move berkeleydb version reporting to wallet...
 79 2016-05-10 13:16:29	0|GitHub58|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f7a21dae5dbf...41138f914d16
 80 2016-05-10 13:16:30	0|GitHub58|13bitcoin/06master 1441138f9 15Wladimir J. van der Laan: Merge #8036: init: Move berkeleydb version reporting to wallet...
 81 2016-05-10 13:16:39	0|GitHub11|[13bitcoin] 15laanwj closed pull request #8036: init: Move berkeleydb version reporting to wallet (06master...062016_05_berkeleydb_report_in_wallet) 02https://github.com/bitcoin/bitcoin/pull/8036
 82 2016-05-10 13:51:52	0|GitHub74|13bitcoin/06master 140fd5997 15Patrick Strateman: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk
 83 2016-05-10 13:51:52	0|GitHub74|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/41138f914d16...373b50debaa9
 84 2016-05-10 13:51:53	0|GitHub74|13bitcoin/06master 14373b50d 15Wladimir J. van der Laan: Merge #8028: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk...
 85 2016-05-10 13:52:02	0|GitHub54|[13bitcoin] 15laanwj closed pull request #8028: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk (06master...062016-05-09-cwalletdb-writetx) 02https://github.com/bitcoin/bitcoin/pull/8028
 86 2016-05-10 14:41:07	0|BlueMatt|gmaxwell/sipa: yea, thinking about it I'm really not a fan of the sender calculating the size in compact blocks...it is really awkward that the sender is picking a value based on their own mempool size assuming the receiver has the same size
 87 2016-05-10 14:42:16	0|gmaxwell|BlueMatt: it's harmless, because the reciever can artifically reduce their effective mempool size if the sender picked too small a value.  (and if the sender picked too large, thats harmless too, just a bit more bandwidth)
 88 2016-05-10 14:42:50	0|BlueMatt|not if, eg, the sender just was brought online, so the mempool isnt the top of the peers mempool, but a different random set
 89 2016-05-10 14:43:20	0|gmaxwell|what does that have to do with anything?
 90 2016-05-10 14:44:30	0|gmaxwell|if so, they may assume the peer's mempool is smaller than it is, send only 5 bytes when they should have sent 6 and the peer will end up having to gettxn as if they only used the top 10000 txn in their mempool.
 91 2016-05-10 14:44:55	0|BlueMatt|gmaxwell: hmm? if the sending peer just came online, then their mempool is small, but random, not the "top X" txn.
 92 2016-05-10 14:45:12	0|gmaxwell|the content of the sending peers mempool isn't important.
 93 2016-05-10 14:45:31	0|BlueMatt|no, but its size matters
 94 2016-05-10 14:45:38	0|BlueMatt|oh, i see your point though
 95 2016-05-10 14:45:55	0|gmaxwell|right.
 96 2016-05-10 14:46:27	0|gmaxwell|it just means they may go to small, but if they do, worse that happens is the reciever needs to gettxn as if the recievers mempool was also smaller.
 97 2016-05-10 14:46:44	0|gmaxwell|(though could still use the extra txn in an attempted gettxn-less reconstruction)
 98 2016-05-10 14:47:20	0|gmaxwell|e.g. use whole pool? succest? if so top. Else remove everything except the top X (based on size), and gettxn.
 99 2016-05-10 14:47:26	0|gmaxwell|er success*
100 2016-05-10 14:47:53	0|BlueMatt|still, makes me uncomfortable for the sender to pick a shortid size based on their mempool size when what actually matters is the receivers mempool, or, really, the miners mempool
101 2016-05-10 14:48:24	0|BlueMatt|like, this falls apart the second a miner picks a tx not from the top of the fee-sorted pool
102 2016-05-10 14:48:29	0|BlueMatt|or with cpfp or something
103 2016-05-10 14:48:32	0|gmaxwell|what matters is pretty much exclusively the recievers mempool.  the driving factor in the fp rate is how many txn will be compared against the short IDs.
104 2016-05-10 14:48:52	0|BlueMatt|yesyes, but you're suggesting using the "top X" from your mempool
105 2016-05-10 14:49:15	0|gmaxwell|it doesn't fall appart, just more approximate. in reality though you're talking about a corner case. 5 bytes is good for mempools significantly larger than we have typically.
106 2016-05-10 14:49:43	0|BlueMatt|hmm...lemme get more coffee and think, I may just be being tired
107 2016-05-10 14:50:16	0|gmaxwell|just means that you're going to gettxn a few extra txn when the sender goes too small; this could be further improved by making the sender do the table amount +1.
108 2016-05-10 15:56:23	0|GitHub72|[13bitcoin] 15MarcoFalke opened pull request #8038: [qa, doc] Various minor fixes (06master...06Mf1605-trivial12) 02https://github.com/bitcoin/bitcoin/pull/8038
109 2016-05-10 16:00:38	0|Chris_Stewart_5|Hmm, are the arguments for OP_PUSHDATA parsed as unsigned numbers?
110 2016-05-10 16:12:26	0|sdaftuar|MarcoFalke: hi -- i was pretty sure the bip9-softforks test would be failing for everyone, but maybe it's a local problem
111 2016-05-10 16:13:13	0|MarcoFalke|Is it failing when you try bitcoin/master?
112 2016-05-10 16:14:35	0|sdaftuar|the failure is only because the script is outputting to stderr, which is introduced in that pull
113 2016-05-10 16:14:57	0|sdaftuar|so i take it you don't get this error when you run locally? "BDB3028 /tmp/testly60vwvd/blocks.db: unable to flush: No such file or directory
114 2016-05-10 16:15:01	0|sdaftuar|"
115 2016-05-10 16:15:22	0|MarcoFalke|nope
116 2016-05-10 16:15:30	0|MarcoFalke|This happens after the nodes are shut down/
117 2016-05-10 16:15:40	0|sdaftuar|yeah at the end of the test
118 2016-05-10 16:15:58	0|sdaftuar|i think it's because the test is deleting the directory that contains the file used by the blockstore
119 2016-05-10 16:16:06	0|sdaftuar|(it does this over and over, sort of a layer violation)
120 2016-05-10 16:17:04	0|sdaftuar|but i don't know why this would only be affecting me and not you...
121 2016-05-10 16:17:32	0|sdaftuar|which python do you use?
122 2016-05-10 16:17:44	0|MarcoFalke|Shouldn't be the python version
123 2016-05-10 16:17:52	0|MarcoFalke|It fails for you on py2 and py3
124 2016-05-10 16:17:59	0|MarcoFalke|which bdb are you running?
125 2016-05-10 16:18:13	0|sdaftuar|hm, not sure how to determine that?
126 2016-05-10 16:21:16	0|MarcoFalke|Should be the default version if you don't pass opts to ./configure
127 2016-05-10 16:24:21	0|MarcoFalke|Couldn't we just get rid of bdb, so no one has to figure out how to fix those bugs?(c.f. https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+author%3AMarcoFalke+label%3AWallet )
128 2016-05-10 16:24:54	0|GitHub31|[13bitcoin] 15laanwj opened pull request #8039: bench: Add hash benchmarks (06master...062016_05_benchmark_sha256) 02https://github.com/bitcoin/bitcoin/pull/8039
129 2016-05-10 16:25:28	0|MarcoFalke|sdaftuar, if you are the only one observing this issue, I am not considering it a blocker for this pull.
130 2016-05-10 16:25:38	0|MarcoFalke|Mind to open a issue?
131 2016-05-10 16:25:48	0|sdaftuar|yep that seems fair
132 2016-05-10 16:25:50	0|sdaftuar|thanks
133 2016-05-10 16:29:09	0|GitHub51|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/373b50debaa9...423ca302a3ee
134 2016-05-10 16:29:10	0|GitHub51|13bitcoin/06master 14ccccc59 15MarcoFalke: [qa] Add option --portseed to test_framework
135 2016-05-10 16:29:10	0|GitHub51|13bitcoin/06master 14fa494de 15MarcoFalke: [qa] pull-tester: Run rpc test in parallel
136 2016-05-10 16:29:11	0|GitHub51|13bitcoin/06master 14423ca30 15MarcoFalke: Merge #7972:  [qa] pull-tester: Run rpc test in parallel...
137 2016-05-10 16:29:16	0|GitHub113|[13bitcoin] 15MarcoFalke closed pull request #7972:  [qa] pull-tester: Run rpc test in parallel  (06master...06Mf1604-qaParallel) 02https://github.com/bitcoin/bitcoin/pull/7972
138 2016-05-10 16:41:11	0|sipa|wumpus: i set my cpu to a fixed clock speed, run a microbenchmark, measure how long it takes, multiply by clock speed :)
139 2016-05-10 16:41:39	0|sipa|/etc/init.d/cpufrequtils stop && for A in $(seq 0 7); do cpufreq-set -c $A -g performance -d 2.6GHz -u 2.6GHz; done
140 2016-05-10 16:42:17	0|sipa|(where 2.6 GHz is one below the max non-turbo speed my CPU is capable of)
141 2016-05-10 20:26:27	0|warren|wumpus: regarding https://github.com/bitcoin/bitcoin/pull/8033  are we leaning toward not fixing minor problems here because of the network rewrite?
142 2016-05-10 22:30:44	0|warren|luke-jr: ping
143 2016-05-10 22:30:53	0|luke-jr|…
144 2016-05-10 22:31:42	0|warren|luke-jr: I wanted an error() that did the same thing except did not print "ERROR:" as these are not errors.
145 2016-05-10 22:31:52	0|luke-jr|oh
146 2016-05-10 22:32:02	0|warren|then I heard not to add more stuff because we're getting rid of all this with the network rewrite
147 2016-05-10 22:33:17	0|luke-jr|k