1 2018-05-15 00:02:28 0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13234: Break circular dependency: chain -> pow -> chain (06master...06chain-pow-chain) 02https://github.com/bitcoin/bitcoin/pull/13234
2 2018-05-15 00:13:00 0|gmaxwell|re: 13191 is there no gain from making a 64-byte specalized sha256^2 that is 1-way SSE4?
3 2018-05-15 00:16:19 0|sipa|gmaxwell: there is a pure C++ one
4 2018-05-15 00:17:03 0|sipa|there is probably a way to combine the advantages of the 1-way SSE4 code and the fixed-64-byte input one
5 2018-05-15 00:17:34 0|sipa|but since that SSE4 code is transpiled intel asm code, it's not trivial
6 2018-05-15 01:21:10 0|gmaxwell|sipa: IIRC the 64-byte specialized non-asm code was a fair bit slower than the sse4 non-64-byte-specialized code when tested before.
7 2018-05-15 01:30:07 0|sipa|gmaxwell: correct, which is why the sse4 1-way non-64 code is used on sse systems when there are no hashes simultaneously
8 2018-05-15 01:30:26 0|sipa|but a combined sse4-1way-64byte should presumably be even faster
9 2018-05-15 01:39:44 0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13235: Break circular dependency: init -> * -> init by extracting shutdown.h (06master...06init-circ-init) 02https://github.com/bitcoin/bitcoin/pull/13235
10 2018-05-15 04:13:48 0|savantgarde|Thanks promag ðŸâ¢â
11 2018-05-15 06:23:50 0|wumpus|the board running my IRC client died yesterday, so I was gone for a while and have no logs. Currently using a temporary workaround hosting elsewhere. Did I miss anything?
12 2018-05-15 06:25:56 0|aj|wumpus: bluematt pinged you and fanquake mentioned #13093 at you i think
13 2018-05-15 06:25:58 0|gribble|https://github.com/bitcoin/bitcoin/issues/13093 | [0.15] backport: depends qt patches by fanquake ÷ Pull Request #13093 ÷ bitcoin/bitcoin ÷ GitHub
14 2018-05-15 06:32:40 0|wumpus|aj: thanks!
15 2018-05-15 06:43:46 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 060.15: 02https://github.com/bitcoin/bitcoin/compare/cb7ef312ff34...1618c63095db
16 2018-05-15 06:43:47 0|bitcoin-git|13bitcoin/060.15 1493b9a61 15fanquake: depends: Fix Qt build with XCode 9.3...
17 2018-05-15 06:43:47 0|bitcoin-git|13bitcoin/060.15 149bb1a16 15fanquake: [Depends] Fix Qt build with Xcode 9.2...
18 2018-05-15 06:43:48 0|bitcoin-git|13bitcoin/060.15 141618c63 15Wladimir J. van der Laan: Merge #13093: [0.15] backport: depends qt patches...
19 2018-05-15 07:28:08 0|fanquake|thanks aj
20 2018-05-15 07:28:28 0|fanquake|wumpus I just assumed you'd finally started to ignore me :p
21 2018-05-15 07:29:10 0|wumpus|fanquake: you were talking to a ghost :)
22 2018-05-15 07:30:25 0|fanquake|:o well if the real wumpus is back, I think #13234 can go in
23 2018-05-15 07:30:27 0|gribble|https://github.com/bitcoin/bitcoin/issues/13234 | Break circular dependency: chain -> pow -> chain by Empact ÷ Pull Request #13234 ÷ bitcoin/bitcoin ÷ GitHub
24 2018-05-15 07:35:15 0|wumpus|fanquake: the real wumpus, or at least a newly-checked out clone. But I'll take a look.
25 2018-05-15 07:39:51 0|bitcoin-git|13bitcoin/06master 143b84ebb 15Wladimir J. van der Laan: Merge #13234: Break circular dependency: chain -> pow -> chain...
26 2018-05-15 07:39:51 0|bitcoin-git|13bitcoin/06master 145b35b92 15Ben Woosley: Break circular dependency: chain -> pow -> chain...
27 2018-05-15 07:39:51 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/81c533c6f481...3b84ebb5bc0d
28 2018-05-15 07:40:33 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13234: Break circular dependency: chain -> pow -> chain (06master...06chain-pow-chain) 02https://github.com/bitcoin/bitcoin/pull/13234
29 2018-05-15 08:40:08 0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #12966: [WIP] Mempool optimized feerate (06master...06mempool-optimized-feerate) 02https://github.com/bitcoin/bitcoin/pull/12966
30 2018-05-15 08:42:34 0|kallewoof|wumpus: Is it possible to add #12634 to the high priority list? It would be very helpful in trimming down the output group (bundle address reuse UTXO) PR.
31 2018-05-15 08:42:39 0|gribble|https://github.com/bitcoin/bitcoin/issues/12634 | [refactor] Make TransactionWithinChainLimit more flexible by kallewoof ÷ Pull Request #12634 ÷ bitcoin/bitcoin ÷ GitHub
32 2018-05-15 08:57:45 0|harding|jonasschnelli, wumpus: for the website, the GitHub is setup so that I can't merge my own PRs unless they have an "Approve" review from someone else with commit access. The following PR numbers there have ACKs from known contributors and so are just waiting for someone besides me with commit access to Approve them: 546, 547, 550, 551, 552, and 553.
33 2018-05-15 09:01:45 0|fanquake|kallewoof I've added it
34 2018-05-15 09:13:10 0|kallewoof|fanquake: Thanks
35 2018-05-15 09:16:15 0|murrayn|any chance
36 2018-05-15 09:16:26 0|murrayn|of getting some feedback on 12881?
37 2018-05-15 09:17:11 0|promag|murrayn: i think it's mergeable
38 2018-05-15 09:18:01 0|murrayn|yes i saw your utACK, thanks
39 2018-05-15 09:20:18 0|promag|murrayn: np, you can pay me by reviewing #13193 x)
40 2018-05-15 09:20:20 0|gribble|https://github.com/bitcoin/bitcoin/issues/13193 | Avoid 2nd mapTx lookup in CTxMemPool::UpdateTransactionsFromBlock by promag ÷ Pull Request #13193 ÷ bitcoin/bitcoin ÷ GitHub
41 2018-05-15 09:20:43 0|wumpus|kallewoof: sure - I think it's usually most helpful to discuss the high priority list during the meeting, but we can do it in-between if you're in a hurry. Oh I see someone already added it anyway :)
42 2018-05-15 09:21:05 0|wumpus|harding: yes I'm extremely behind on website review, will take a look!
43 2018-05-15 09:21:39 0|kallewoof|wumpus: Yeah, I just tend to not be awake 4 am. I am trying to pull it off though. Maybe this week...
44 2018-05-15 09:22:13 0|wumpus|kallewoof: yes that's a crazy time, if you can't make it, no problem
45 2018-05-15 09:23:59 0|kallewoof|wumpus: It should be doable, but I tend to wake up late. 4 am is usually a few hours after I fall asleep :)
46 2018-05-15 09:25:20 0|wumpus|murrayn: I haven't looked at it since my comment about locale-specific functions, will re-review
47 2018-05-15 09:35:38 0|wumpus|murrayn: what was your motivation for optimizing bech32::Decode? is this on any critical path?
48 2018-05-15 09:36:06 0|bitcoin-git|[13bitcoin] 15ken2812221 opened pull request #13236: break circular dependency: random -> util -> random (06master...06random_util) 02https://github.com/bitcoin/bitcoin/pull/13236
49 2018-05-15 09:40:50 0|wumpus|harding: looks like the problem is also that people are using ACKs, not the approval system
50 2018-05-15 09:41:39 0|wumpus|should probably become routine in that repository that people who utACK/ACK also 'approve' the PR
51 2018-05-15 09:41:54 0|wumpus|unfortunately github doesn't count in-text ACKs
52 2018-05-15 09:42:21 0|murrayn|promag, i have reviewed 13193
53 2018-05-15 09:43:14 0|murrayn|wumpus, the original motivation was just something that caught my eye as an optimization.
54 2018-05-15 09:46:55 0|wumpus|murrayn: right, I see your point, but at some point I wonder about the cognitive load of reviewing that a change is correct versus the reason to make it
55 2018-05-15 09:52:05 0|wumpus|murrayn: so your conclusion in https://github.com/bitcoin/bitcoin/pull/12881#issuecomment-383039089 is pretty much "it doesn't matter if compiler optimizations are enabled"
56 2018-05-15 09:59:01 0|murrayn|wumpus, yes i see your point re: the cognitive load. in this case the change and its effect is very localized.
57 2018-05-15 10:01:03 0|wumpus|there's certainly a place for micro-optimizations, but I'm not sure this is it
58 2018-05-15 10:01:14 0|wumpus|I agree it's a very localized change, sure
59 2018-05-15 10:02:14 0|harding|wumpus: true about ACKs versus Approvals, although I think most of the ACKs on those PRs are from people without commit access, so GitHub doesn't wouldn't count their Approves towards unlocking mergability. That's a bit unfortunate to my mind, as I think it somewhat discourages people who don't alreday have commit access from reviewing.
60 2018-05-15 10:03:05 0|wumpus|murrayn: anyhow I'm going to ACK it - but please next time if you optimize, try to find something that is on the critical path (e.g. validation) and can clearly demonstrate improvement
61 2018-05-15 10:03:54 0|wumpus|murrayn: and this makes the code somewhat easier to read, that's good
62 2018-05-15 10:05:06 0|wumpus|harding: oh, I didn't know only approvals of repo members counted. Maybe we should remove this github-side requirement and leave it up to the committer to count the ACKs?
63 2018-05-15 10:08:20 0|murrayn|wumpus, ACK. as sipa pointed out, it's not an important function to optimize, so it does come down to readability.
64 2018-05-15 10:08:57 0|wumpus|murrayn: apart from validation there's some other things that would benefit from optimization: for example some GUI things with regard to handling lots of transactions/addresses, network code, RPC/web server latency
65 2018-05-15 10:09:17 0|wumpus|handling of large wallets
66 2018-05-15 10:09:54 0|murrayn|wumpus, i'm working on it, getting my feet wet :-)
67 2018-05-15 10:10:34 0|harding|given the impact of the PR'.
68 2018-05-15 10:10:34 0|harding|wumpus: I'm in favor of that. I initially thought it was a security requirement, and it makes sense to me that you'd want to prevent any person from unilaterally pushing to the master branch for a live-deployed website. But then I realzed how easy it would be to circumvent by creating a secondary account to open PRs from, so I'd prefer to indeed just do the usual 'count PRs from known contributors and ensure there are enough
69 2018-05-15 10:10:39 0|bitcoin-git|13bitcoin/06master 1460f61f9 15murrayn: Tighten up bech32::Decode(); add tests.
70 2018-05-15 10:10:39 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3b84ebb5bc0d...1d4662f5dcf6
71 2018-05-15 10:10:40 0|bitcoin-git|13bitcoin/06master 141d4662f 15Wladimir J. van der Laan: Merge #12881: Minor optimizations to bech32::Decode(); add tests....
72 2018-05-15 10:11:14 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12881: Minor optimizations to bech32::Decode(); add tests. (06master...06bech32_decode) 02https://github.com/bitcoin/bitcoin/pull/12881
73 2018-05-15 10:21:48 0|wumpus|harding: yes from a security point of view it makes some sense, espeically if only repo members are counted
74 2018-05-15 10:29:14 0|wumpus|harding: so are you sure only people with *write access* count, or everyone who is part of the repository team, also read-only members? if the latter we could just add everyone from the bitcoincore organization in it
75 2018-05-15 10:39:23 0|harding|wumpus: good question. The GitHub UI says, "At least 1 approving review is required by reviewers with write access." Looking deeper at the documentation, it seems to confirm that, and I think that's what I observed for one of MarcoFalke's Approves (that the UI still said I needed a review by someone with write access).
76 2018-05-15 10:40:51 0|harding|wumpus: in any case, thanks for all your reviews this morning!
77 2018-05-15 11:02:14 0|wumpus|harding: np, feel free to poke me when you need review for the website again
78 2018-05-15 11:05:48 0|mess110|hi, can I please get some reviews on https://github.com/bitcoin/bitcoin/pull/11491 ?
79 2018-05-15 11:09:25 0|wumpus|mess110: yes
80 2018-05-15 11:17:05 0|provoostenator|Two PRs with baby steps towards making RBF easier to use: #12096, #12818
81 2018-05-15 11:17:08 0|gribble|https://github.com/bitcoin/bitcoin/issues/12096 | [rpc] [wallet] Allow specifying the output index when using bumpfee by kallewoof ÷ Pull Request #12096 ÷ bitcoin/bitcoin ÷ GitHub
82 2018-05-15 11:17:10 0|gribble|https://github.com/bitcoin/bitcoin/issues/12818 | [qt] TransactionView: highlight replacement tx after fee bump by Sjors ÷ Pull Request #12818 ÷ bitcoin/bitcoin ÷ GitHub
83 2018-05-15 11:20:22 0|bitcoin-git|[13bitcoin] 15Sjors closed pull request #12565: [qt] bumpfee: offer user to reduce output for transactions without change (06master...062018/02/qt-bumpfee-reduce-output) 02https://github.com/bitcoin/bitcoin/pull/12565
84 2018-05-15 12:44:52 0|bitcoin-git|13bitcoin/06master 14244f4ba 15practicalswift: scheduler: Add Clang thread safety annotations for variables guarded by m_cs_callbacks_pending
85 2018-05-15 12:44:52 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1d4662f5dcf6...13da2899ae42
86 2018-05-15 12:44:53 0|bitcoin-git|13bitcoin/06master 1413da289 15MarcoFalke: Merge #13125: scheduler: Add Clang thread safety annotations for variables guarded by m_cs_callbacks_pending...
87 2018-05-15 12:45:41 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13125: scheduler: Add Clang thread safety annotations for variables guarded by m_cs_callbacks_pending (06master...06m_cs_callbacks_pending) 02https://github.com/bitcoin/bitcoin/pull/13125
88 2018-05-15 13:22:03 0|promag|I guess could be merged #10757
89 2018-05-15 13:22:10 0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon ÷ Pull Request #10757 ÷ bitcoin/bitcoin ÷ GitHub
90 2018-05-15 13:22:58 0|promag|jnewbery: ping
91 2018-05-15 13:56:24 0|jnewbery|promag: I'm here
92 2018-05-15 14:45:48 0|promag|jnewbery: I see you are already checking out #10740
93 2018-05-15 14:45:54 0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] `loadwallet` RPC - load wallet at runtime by jnewbery ÷ Pull Request #10740 ÷ bitcoin/bitcoin ÷ GitHub
94 2018-05-15 16:49:17 0|provoostenator|I have two nodes on master and a v0.16.0 which all seem to refuse to relay 1 sat / byte transactions, despite "minrelaytxfee": 0.00010000 ...
95 2018-05-15 16:50:57 0|provoostenator|The nodes on master don't throw any errors when you use the GUI or sendrawtransaction. The 0.16.0 node however compalins that the minimum relay fee isn't met.
96 2018-05-15 16:53:53 0|sipa|provoostenator: 0.0001 is 10sat/byte, no?
97 2018-05-15 16:54:36 0|sipa|so not relaying 1sat/byte seems expected
98 2018-05-15 16:58:21 0|provoostenator|I set maxmempool to something really large, but on the 0.16 node I forgot to remove minrelaytxfee, which indeed set it to 10.
99 2018-05-15 17:05:48 0|provoostenator|The other two nodes have 0.000010000, but once I fixed the 0.16.0 node transactions get relayed as expected, so nvm...
100 2018-05-15 17:13:22 0|provoostenator|Different issue: I'm comparing #12404 with master on a node with 1 GB ram. I didn't confiugre dbcache, yet it OOM'd at cache=568 MiB (on master as well as my PR)
101 2018-05-15 17:13:23 0|gribble|https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors ÷ Pull Request #12404 ÷ bitcoin/bitcoin ÷ GitHub
102 2018-05-15 17:13:55 0|provoostenator|Is there room wiggle room above the default 450 MB or could this be a bug?
103 2018-05-15 17:22:00 0|sipa|there's a couple hundred MB in other things, yes
104 2018-05-15 17:38:56 0|provoostenator|Wouldn't it be better for dbache to be inclusive of these "other things"? So it would flush when the total hits 450, rather than some unpredicatable(?) point?
105 2018-05-15 17:52:53 0|provoostenator|It flushed at 716 MB (April 2013), so I'll try dbcache=200 on the 1 GB machine which leave 100 MB margin of error. This is useful too: https://gist.github.com/laanwj/efe29c7661ce9b6620a7
106 2018-05-15 17:53:43 0|provoostenator|(that last number was on a machine with more RAM, I'll keep it running to see where the other peaks are)
107 2018-05-15 18:06:24 0|sipa|provoostenator: it's very hard to account for all memory
108 2018-05-15 18:06:39 0|sipa|we could include a few easily-accountable things like block headers
109 2018-05-15 18:07:00 0|sipa|and i'm generally in favor of ways of making total memory more predictable
110 2018-05-15 18:07:41 0|provoostenator|But the log entries say "cache=223.1MiB" so at least that number is known and could be kept below dbcache, right?
111 2018-05-15 18:07:54 0|sipa|yes it should be
112 2018-05-15 18:07:56 0|provoostenator|(except during the flush itself)
113 2018-05-15 18:08:11 0|sipa|below dbcache+mempoolsize
114 2018-05-15 18:08:58 0|provoostenator|Ah, so setting maxmempool would also make it more predicatable?
115 2018-05-15 18:09:52 0|sipa|mempoolsize + dbcache should always be below -maxmempool + -dbcache
116 2018-05-15 18:10:18 0|provoostenator|Isn't the mempool empty during IBD?
117 2018-05-15 18:10:38 0|sipa|yes, that's the point
118 2018-05-15 18:10:50 0|sipa|dbcache can "borrow" the unused mempool memory
119 2018-05-15 18:13:42 0|sipa|because during IBD we have mempool memory to spare, and more dbcache helps a lot
120 2018-05-15 18:17:10 0|provoostenator|That makes sense. Would be useful to mention that in the -dbcache command documentation.
121 2018-05-15 18:18:08 0|provoostenator|Though the "reducing bitcoind memory usage" doc does mention this.
122 2018-05-15 18:29:37 0|sipa|sounds good
123 2018-05-15 18:29:47 0|sipa|I wasn't aware it wasn't mentioned
124 2018-05-15 19:49:37 0|BlueMatt|sipa (or whoever): you wanna re-ack-and-merge #13023? then we can tag 16.1rc1 =D
125 2018-05-15 19:49:41 0|gribble|https://github.com/bitcoin/bitcoin/issues/13023 | Fix some concurrency issues in ActivateBestChain() by skeees ÷ Pull Request #13023 ÷ bitcoin/bitcoin ÷ GitHub
126 2018-05-15 19:50:09 0|BlueMatt|(the fd things I dont think make sense to wait for, they haven't made much progress that I see, unless cfields wants to object)
127 2018-05-15 19:50:44 0|skeees|=)
128 2018-05-15 19:58:39 0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13239: [moveonly] Fix CConnman template methods to be fully-defined in net.h (06master...06net-template-methods) 02https://github.com/bitcoin/bitcoin/pull/13239
129 2018-05-15 21:24:35 0|cfields|BlueMatt: whoops, never ended up getting back to that
130 2018-05-15 21:25:42 0|cfields|I'm not too worried though
131 2018-05-15 22:18:56 0|BlueMatt|cfields: yea, I'm not either
132 2018-05-15 23:21:59 0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13241: scripted-diff: Avoid temporary copies when looping over std::map (06master...06pair-const-key) 02https://github.com/bitcoin/bitcoin/pull/13241