1 2016-12-02T00:00:54  *** aalex has quit IRC
  2 2016-12-02T00:03:00  *** cysm has joined #bitcoin-core-dev
  3 2016-12-02T00:03:36  *** bsm117532 has joined #bitcoin-core-dev
  4 2016-12-02T00:04:21  *** Evel-Knievel has quit IRC
  5 2016-12-02T00:07:40  <bitcoin-git> [bitcoin] sipa pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad826b3df9f7...dc6dee41f7cf
  6 2016-12-02T00:07:41  <bitcoin-git> bitcoin/master 4a6b1f3 Matt Corallo: Expose AcceptBlockHeader through main.h
  7 2016-12-02T00:07:41  <bitcoin-git> bitcoin/master 63fd101 Matt Corallo: Split ::HEADERS processing into two separate cs_main locks...
  8 2016-12-02T00:07:42  <bitcoin-git> bitcoin/master a8b936d Matt Corallo: Use exposed ProcessNewBlockHeaders from ProcessMessages
  9 2016-12-02T00:07:51  <bitcoin-git> [bitcoin] sipa closed pull request #9183: Final Preparation for main.cpp Split (master...net_processing_5) https://github.com/bitcoin/bitcoin/pull/9183
 10 2016-12-02T00:08:50  *** jtimon has quit IRC
 11 2016-12-02T00:10:04  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9260: Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) (master...net_processing_file) https://github.com/bitcoin/bitcoin/pull/9260
 12 2016-12-02T00:10:34  *** bsm117532 has quit IRC
 13 2016-12-02T00:10:35  *** Evel-Knievel has joined #bitcoin-core-dev
 14 2016-12-02T00:11:33  <sipa> BlueMatt: haha
 15 2016-12-02T00:11:50  <BlueMatt> did you see the pr text?
 16 2016-12-02T00:12:30  <sipa> yes
 17 2016-12-02T00:12:45  *** alpalp has joined #bitcoin-core-dev
 18 2016-12-02T00:16:58  <bitcoin272> hey guys I'm curious, why was 25 chosen for the ancestor count?
 19 2016-12-02T00:18:25  <BlueMatt> ugh, git isnt smart enough to realize when you rename a file and then create a dumb #include "newfile.h" is a move :(
 20 2016-12-02T00:19:14  <Eliel> BlueMatt: it should understand it if you do the rename with git mv
 21 2016-12-02T00:19:47  <sipa> BlueMatt: where does it not realize this?
 22 2016-12-02T00:20:01  <BlueMatt> main.h -> validation.h; main.h == #include "validation.h"
 23 2016-12-02T00:20:06  <BlueMatt> because i dont want to touch literally every file
 24 2016-12-02T00:20:39  <sipa> i don't understand what the problem is
 25 2016-12-02T00:21:08  <BlueMatt> will make rebase of ~everything impossible
 26 2016-12-02T00:21:21  <BlueMatt> git is smart when rebasing/merging across moves otherwise
 27 2016-12-02T00:22:02  <BlueMatt> Eliel: no, it doesnt cache that info
 28 2016-12-02T00:22:07  <Eliel> if it won't understand it in a single commit, try first renaming and then creating the new file.
 29 2016-12-02T00:22:12  <BlueMatt> it regenerates it itself, so there is no place for it to figure it out
 30 2016-12-02T00:22:14  <Eliel> in two commits
 31 2016-12-02T00:22:16  <BlueMatt> yea
 32 2016-12-02T00:26:56  *** bsm117532 has joined #bitcoin-core-dev
 33 2016-12-02T00:36:36  *** justanotheruser is now known as Hismione
 34 2016-12-02T00:40:30  *** bitcoin272 has quit IRC
 35 2016-12-02T00:41:57  <sipa> BlueMatt: does it still do this tracking after a merge commit is introduced around the two commits?
 36 2016-12-02T00:42:02  <sipa> maybe it treats it as one then
 37 2016-12-02T00:42:16  <BlueMatt> sipa: I have no idea...
 38 2016-12-02T00:42:37  <gmaxwell> bitcoin272: measurements on the actual network, combined with the compute time created for longer chains (They're more expensive to process).
 39 2016-12-02T00:42:57  <sipa> BlueMatt: can you check? if not, it's probably not worth deviating from the "every commit needs to compile and run tests" policy
 40 2016-12-02T00:43:06  <BlueMatt> willdo
 41 2016-12-02T00:43:12  <sipa> actually, i'll check myself - i want to know
 42 2016-12-02T00:43:28  <BlueMatt> heh, ok
 43 2016-12-02T00:43:42  * BlueMatt is currently checking which files still dont compile with 1GB of memory in kvm....
 44 2016-12-02T00:44:00  <sipa> good
 45 2016-12-02T00:45:04  <BlueMatt> lots of them, it looks like :(
 46 2016-12-02T00:45:45  <sipa> BlueMatt: doesn't seem to work
 47 2016-12-02T00:45:52  <BlueMatt> across a merge?
 48 2016-12-02T00:45:55  <BlueMatt> damn git
 49 2016-12-02T00:46:21  <BlueMatt> does rebase work at all across a rename? merge does, but rebase might now
 50 2016-12-02T00:46:25  <BlueMatt> not, actually
 51 2016-12-02T00:46:27  <Eliel> maybe you can make it a symlink instead?
 52 2016-12-02T00:46:39  <BlueMatt> eww
 53 2016-12-02T00:46:48  <BlueMatt> I think i might rather sed all the files
 54 2016-12-02T00:46:51  <sipa> i tried rebasing #8580 on top of a merged 9260 (with --no-ff)
 55 2016-12-02T00:46:53  <gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
 56 2016-12-02T00:46:57  <sipa> and it conflicts in main.h
 57 2016-12-02T00:47:00  <BlueMatt> damn
 58 2016-12-02T00:47:16  <sipa> like... the whole file is a conflict block
 59 2016-12-02T00:47:20  <BlueMatt> ok, well I guess its gonna be rebase-hell either way....
 60 2016-12-02T00:47:36  <sipa> we could choose to leave one of the two named main.h/.cpp
 61 2016-12-02T00:47:42  <BlueMatt> yea...
 62 2016-12-02T00:47:53  <sipa> which at least would make rebases that touch the not-moved-out part work
 63 2016-12-02T00:48:00  <BlueMatt> i mean could leave it as main.h and change the #define in main.h to VALIDATION and add a TODO thats like "move this shits"
 64 2016-12-02T00:48:25  <BlueMatt> then do it like when we close merge window so that its easier
 65 2016-12-02T00:48:45  <Eliel> would symlink cause more trouble than it'd solve?
 66 2016-12-02T00:48:46  <BlueMatt> alternatively, I could actually go sed the entire codebase
 67 2016-12-02T00:48:59  <BlueMatt> Eliel: I dont think it'd cause trouble since we have the #define guards
 68 2016-12-02T00:49:02  <BlueMatt> but its super ugly
 69 2016-12-02T00:49:14  <BlueMatt> (and, actually, git might not track that, either?)
 70 2016-12-02T00:49:21  <Eliel> right, true
 71 2016-12-02T00:49:22  *** alpalp has quit IRC
 72 2016-12-02T00:49:41  <Eliel> but yes, I think sedding the whole codebase is best
 73 2016-12-02T00:49:43  <sipa> validation.h is much larger than net_processing.h, so i'd suggest having main.h and net_processing.h, rather than validation.h and main.h
 74 2016-12-02T00:49:58  <BlueMatt> yea
 75 2016-12-02T00:52:13  <sipa> so just remove the last two commits?
 76 2016-12-02T00:53:27  <BlueMatt> sipa: I went ahead and did as you suggested and left main.cpp moved to validation.cpp, and just added a TODO to main.h to move it
 77 2016-12-02T00:54:31  <sipa> ah, i'd just have left validation.cpp to be main.cpp
 78 2016-12-02T00:54:47  <sipa> that move can easily be do at the same time as the .h rename
 79 2016-12-02T00:55:39  <BlueMatt> welllll....i mean sed wont cuase (m)any rebase issues........
 80 2016-12-02T00:56:25  <sipa> yes, but it's a weird state to have main.h but validation.cpp
 81 2016-12-02T00:56:33  <sipa> and there is no need to that move early
 82 2016-12-02T00:56:56  <BlueMatt> there is also no need to wait on the wholesale main/validation move/sed
 83 2016-12-02T00:56:57  <BlueMatt> :p
 84 2016-12-02T00:57:16  <sipa> well, so either do the whole thing now, or not at all
 85 2016-12-02T00:57:28  <BlueMatt> I'm doing it now :)
 86 2016-12-02T01:24:51  *** randy-waterhouse has quit IRC
 87 2016-12-02T01:29:49  *** Chris_Stewart_5 has quit IRC
 88 2016-12-02T01:42:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 89 2016-12-02T01:50:37  <phantomcircuit> sipa, after looking at 8831 again i can see why you wanted to not have the ReadKeyValue logic in CWallet
 90 2016-12-02T01:50:55  <phantomcircuit> im not sure a class with virtual functions is going to be enough either though
 91 2016-12-02T01:52:23  *** mrkent has quit IRC
 92 2016-12-02T01:54:30  *** abpa has quit IRC
 93 2016-12-02T02:11:07  <phantomcircuit> sipa, i could just add a bunch of methods to CWallet like LoadName LoadPurpose etc
 94 2016-12-02T02:17:12  *** rafalcpp has quit IRC
 95 2016-12-02T02:17:58  *** rafalcpp has joined #bitcoin-core-dev
 96 2016-12-02T02:25:41  <morcos> sipa: for bitcoin272's problem, the wallet doesn't rebroadcast things that aren't in its own mempool correct? so is his node restarting (which would then maybe accept some of the later chain txs) or something else?
 97 2016-12-02T02:27:36  <sipa> morcos: uh, right
 98 2016-12-02T02:28:46  <morcos> gmaxwell: in the code that doesn't store an orphan if its parent was rejected...  are we sure that's a good idea?
 99 2016-12-02T02:29:04  <morcos> if a parent had too low fee
100 2016-12-02T02:29:21  <morcos> it is entirely possible that the parent + orphan would then stay in the mempool
101 2016-12-02T02:29:50  <gmaxwell> morcos: well we don't have the parent now and won't request it so the orphan will not get resolved. We might want to keep it around for BIP152 but right now BIP152 makes NO use of the orphan pool..
102 2016-12-02T02:30:12  <morcos> what do you mean we won't request it?
103 2016-12-02T02:30:34  <gmaxwell> while it's in the reject filter we won't request it.
104 2016-12-02T02:31:15  <gmaxwell> ('cause thats what the reject filter does)
105 2016-12-02T02:31:47  <morcos> argh, thats just kind of an accident about the way alreadyhave works though right?
106 2016-12-02T02:31:53  <gmaxwell> Am I confused? Highly likely... I have a cold.
107 2016-12-02T02:32:13  <gmaxwell> Well I thought that was the intent-- we don't want to request things we 'know' we will just reject.
108 2016-12-02T02:32:25  <morcos> i mean in the orphan processing code we're specifically requesting the parents, but you're right we "AlreadyHave" things that are recentrejects
109 2016-12-02T02:32:59  <gmaxwell> Yea, we could request it again if the orphan's fee was high for example and maybe then they both could be accepted.. would make ancestor feerate mining work better.
110 2016-12-02T02:33:08  <morcos> yeah, but i guess i'm drawing a distinction between requesting txs in response to inv's (in which case you dont' want them if you recentlyrejected)
111 2016-12-02T02:33:21  <morcos> and requesting them as a parent, in which case, maybe you want to try again
112 2016-12-02T02:34:46  <morcos> in fact, we could almost bypass the mempool minfee check altogether since most of our recent peers won't send us stuff that violates it anyway and then it would basically just work
113 2016-12-02T02:34:53  <morcos> but i guess we can't quite do that
114 2016-12-02T02:35:08  <gmaxwell> I'd like rejection to work differently, putting rejected things in a datastructure that works like the new sigcache open-hashtable where they're taged for eager eviction but kept around until actually evicted... and then BIP152 can use that pool, and orphan resolution can use it and so on.
115 2016-12-02T02:35:40  <morcos> does that work for non-POD
116 2016-12-02T02:36:10  <gmaxwell> 'works like' I don't mean the lockless aspects of it either, but just the fact that there is a generation/deleted flag.
117 2016-12-02T02:37:37  <morcos> ok.. i think i'll still PR that takes non-stored orphans with rejected parents and adds them to rejects, but just comment that we might want to remove that if we fix up the rest.  i think its strictly better than existing
118 2016-12-02T02:37:45  <gmaxwell> the principle is that we already took the cost of transfering the data, we should keep as of the most useful 'useless' stuff as we can afford... in case it turns up in a block or as a parent.
119 2016-12-02T02:38:01  <gmaxwell> But I dunno if it's better to spend time working on that or mempool sync.
120 2016-12-02T02:39:13  <morcos> gmaxwell: arghh.. you guys and your mempool sync..   i tend to like the other methods better.. but BlueMatt was trying to convince me nothing can match the privacy of mempool sync
121 2016-12-02T02:39:55  <gmaxwell> hah
122 2016-12-02T02:39:59  <BlueMatt> I'm still a fan
123 2016-12-02T02:40:55  <gmaxwell> well perhaps I'm also chasing it because in theory it's possible to get pretty close to optimal bandwidth efficiency and today we waste a lot of bandwidth on relay. (though it's gotten incrementally better in the last several releases)
124 2016-12-02T02:41:40  <gmaxwell> but it's easy to venture into overdesign.
125 2016-12-02T02:41:48  <gmaxwell> OTOH, Fibre exists and is pretty awesome.
126 2016-12-02T02:42:01  <gmaxwell> and I could have also said that it was a crazy excercise in chasing optimality.
127 2016-12-02T02:43:09  <morcos> we should set up some data-collecting nodes that see how much better our block reconstruction would be if we'd kept everything we were told about
128 2016-12-02T02:43:45  <BlueMatt> lol, by adding #include <boost/thread.hpp> to fix windows build error, net_processing.cpp ticked over the 1GB-memory-usage mark :(
129 2016-12-02T02:43:50  <BlueMatt> fucking boost
130 2016-12-02T02:44:01  <BlueMatt> gmaxwell: I'm more excited by better relay privacy
131 2016-12-02T02:44:21  <gmaxwell> morcos: I've been monitoring a bit of that on and off.
132 2016-12-02T02:44:42  <sipa> BlueMatt: i think more recent gccs have lower memory usage? :0
133 2016-12-02T02:44:45  <gmaxwell> actually I find a lot of the blocks that are almost perfectly reconstucted miss due to replacements / doublespends.
134 2016-12-02T02:45:03  <morcos> gmaxwell: how much of the gap can you close?
135 2016-12-02T02:45:05  <BlueMatt> sipa: I'm sure, this is what was in default-debian on digitalocean
136 2016-12-02T02:45:11  <morcos> replacements/doublespends that you heard about?
137 2016-12-02T02:45:15  <gmaxwell> Yes.
138 2016-12-02T02:45:27  <morcos> but weren't RBF?
139 2016-12-02T02:45:33  <BlueMatt> huh, can anyone reproduce travis' hangs on #9260
140 2016-12-02T02:45:33  <morcos> why didnt you have them?
141 2016-12-02T02:45:35  <BlueMatt> i cant...
142 2016-12-02T02:45:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9260 | Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) by TheBlueMatt · Pull Request #9260 · bitcoin/bitcoin · GitHub
143 2016-12-02T02:45:41  <gmaxwell> As in I replaced the transaction, and the block confirmed the other (presumably the miner didn't support replacement or it didn't make itt othem yet)
144 2016-12-02T02:45:55  <gmaxwell> morcos: some were RBF.
145 2016-12-02T02:46:05  <gmaxwell> Though I did see a doublespend that wasn't at least once.
146 2016-12-02T02:46:13  <BlueMatt> oh, maybe I can
147 2016-12-02T02:46:14  <morcos> yeah, so thats a good use of your eager eviction
148 2016-12-02T02:46:32  <gmaxwell> morcos: if you have debug=1 on, and the BIP152 missed by only a few txids it will log the missing txids and you can check your logs to see if you'd previously heard them.
149 2016-12-02T02:47:01  <morcos> gmaxwell: ha, even easier than i thought
150 2016-12-02T02:47:02  <BlueMatt> oops lol
151 2016-12-02T02:47:16  <gmaxwell> during the period I last looked this was the overwhelming majority of blocks that missed only a couple.  But there is a lot of variance since it depends on miner policy...
152 2016-12-02T02:47:42  <gmaxwell> morcos: I think 'few' might only be <5 so you might want to turn that up.
153 2016-12-02T02:48:05  <gmaxwell> The purpose of that logging was to explore the impacts of prefill policies, and we wouldn't ever prefill more than a couple.
154 2016-12-02T02:48:11  <sipa> yup, 5
155 2016-12-02T02:48:14  <sipa> <=5
156 2016-12-02T02:48:40  <gmaxwell> (I don't think prefill is worth working on until we eliminate all the preventable misses)
157 2016-12-02T02:49:08  <gmaxwell> (e.g. by using the orpan pool and by keeping at least replacements around in some kind of pool...)
158 2016-12-02T02:49:28  *** abpa has joined #bitcoin-core-dev
159 2016-12-02T02:49:31  *** rafalcpp has quit IRC
160 2016-12-02T02:49:49  *** rafalcpp has joined #bitcoin-core-dev
161 2016-12-02T02:50:11  <morcos> sdaftuar and i were saying that we might also want to have a super-HB peer among our 3 HB peers, as you maybe don't want 3 peers prefilling for you
162 2016-12-02T02:50:36  <morcos> for instance one kind of obvious prefill policy is if the tx is non-standard (such as >100k) prefill, but then thats big
163 2016-12-02T02:50:57  <gmaxwell> yes, though it's little enough data that it probably doesn't matter.   The spec recommends you don't prefill more than 10kb in total.
164 2016-12-02T02:53:22  <gmaxwell> morcos: of course, there is also the Fibre technique where you send FEC data... and then all the peers could usefully contribute. :P
165 2016-12-02T02:54:02  <gmaxwell> We also don't have a way to NAK a HB request-- I reasoned that this was okay because even if every peer requests HB from you... you still end up not really any worse than relaying a full block to a single peer.  Same kind of thinking applies for excessive prefill.
166 2016-12-02T02:54:44  <morcos> yeah we should probably right a new mining api first.  :)
167 2016-12-02T02:54:50  <morcos> s/right/write/
168 2016-12-02T02:54:54  <gmaxwell> Yea, no kidding.
169 2016-12-02T02:56:40  <gmaxwell> I've also thought that we should probably not be using HB mode at all unless we have inbound connections or we're mining (or we've been asked by the user).  but that kind of complexity also got answered with 'the overhead is irrelevant'.
170 2016-12-02T03:11:03  *** jtimon has joined #bitcoin-core-dev
171 2016-12-02T03:12:18  * jtimon rebased #8855 again
172 2016-12-02T03:12:20  <gribble> https://github.com/bitcoin/bitcoin/issues/8855 | Use a proper factory for creating chainparams by jtimon · Pull Request #8855 · bitcoin/bitcoin · GitHub
173 2016-12-02T03:12:43  <BlueMatt> sipa: even with gcc 6.2 net_processing ticks over 1GB (incl host)
174 2016-12-02T03:15:25  <gmaxwell> :(
175 2016-12-02T03:15:31  <gmaxwell> BlueMatt: you have failed at main splitting! :)
176 2016-12-02T03:15:48  <jtimon> intirestingly enough, with +15-22 in main.cpp, #8498 doesn't need rebase since sep1
177 2016-12-02T03:15:50  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
178 2016-12-02T03:15:58  <BlueMatt> clearly
179 2016-12-02T03:16:03  <BlueMatt> to be fair, so does init
180 2016-12-02T03:16:24  <jtimon> what did I missed?
181 2016-12-02T03:17:56  * jtimon went to the logs
182 2016-12-02T03:18:34  <bitcoin-git> [bitcoin] morcos opened pull request #9261: Add unstored orphans with rejected parents to recentRejects (master...orphanRejects) https://github.com/bitcoin/bitcoin/pull/9261
183 2016-12-02T03:26:45  <jtimon> BlueMatt: not renaming main to validation in the same PR would make it simpler to review
184 2016-12-02T03:27:00  <BlueMatt> jtimon: that pr should be easy to review
185 2016-12-02T03:27:09  <BlueMatt> the main.cpp rename is a clean rename, so that especially
186 2016-12-02T03:29:22  <jtimon> I guess I'm not enthusiastic about renaming main in general, I believe it still does a lot of things beyond consensus validation, plus it still includes most globals
187 2016-12-02T03:29:34  <jtimon> but will keep looking
188 2016-12-02T03:31:01  <jtimon> but yeah, review it's not a good argument
189 2016-12-02T03:34:31  <BlueMatt> jtimon: see scrollback, there are ~no functions which are not block/tx processing left in validation.cpp
190 2016-12-02T03:34:38  <BlueMatt> jtimon: except, yes, globals
191 2016-12-02T03:36:11  <jtimon> https://github.com/bitcoin/bitcoin/pull/9260#issuecomment-264365400
192 2016-12-02T03:36:36  <BlueMatt> jtimon: what /did/ you review?
193 2016-12-02T03:43:22  <jtimon> commit by commit, if the moveonlys are moveonlys (ie https://github.com/bitcoin/bitcoin/pull/9260/commits/84922e4bf4c38227fbbbede50e09c87fe2a5c7f0 ) and what you say in https://github.com/bitcoin/bitcoin/pull/9260/commits/87c35f584397e2309970afdcca8e03731a86639e is true, everything seems fine or it shouldn't compile, to give an utACK I would need to grep mapOrphanTransactions and mapOrphanTransactionsByPrev and verify the
194 2016-12-02T03:43:22  <jtimon> moveonlies
195 2016-12-02T03:46:59  *** Giszmo has quit IRC
196 2016-12-02T03:54:08  <jtimon> re rename right, git knows the file is renamed but you eat the include changes which I agree is not hard to review
197 2016-12-02T03:55:06  *** dermoth has quit IRC
198 2016-12-02T03:57:16  <wumpus> cfields: I thought about this global version/context parameters thing in RPC a bit, and there's several other potentially controversial solutions that are used for JSON API versioning we could consider as well: an alternative (say "v2") entry point, or using a HTTP header. An advantage would be that these are conceptually separate from normal arguments
199 2016-12-02T03:58:18  <wumpus> cfields: I'm not specifically aiming 8811 for any release but I'd sure hope it can be merged before 0.14
200 2016-12-02T03:58:46  <wumpus> cfields: as it changes all the RPC dispatch tables it's pretty annoying to keep up to date
201 2016-12-02T03:59:29  <wumpus> cfields: I just wish people would test it a bit
202 2016-12-02T04:02:18  <wumpus> cfields: regarding testing it: maybe it would make sense to port at least one of the RPC tests to fully using named arguments? currently it adds a test but that one is specifically for the named-arguments-parsing functionality
203 2016-12-02T04:05:13  <jtimon> sipa: BlueMatt: if we're doing file renames, maybe we can move ahead with some in https://github.com/bitcoin/bitcoin/pull/8328 (those people can agree on)
204 2016-12-02T04:05:14  *** dermoth has joined #bitcoin-core-dev
205 2016-12-02T04:09:50  <bitcoin-git> [bitcoin] instagibbs opened pull request #9262: Don't consider coins available if too many ancestors in mempool (master...toolong) https://github.com/bitcoin/bitcoin/pull/9262
206 2016-12-02T04:37:14  *** fanquake has joined #bitcoin-core-dev
207 2016-12-02T04:47:26  *** juscamarena has quit IRC
208 2016-12-02T04:48:59  *** CubicEarth has quit IRC
209 2016-12-02T04:49:06  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dc6dee41f7cf...c4d22f6eb216
210 2016-12-02T04:49:06  <bitcoin-git> bitcoin/master 10ae7a7 Matt Corallo: Revert "Use async name resolving to improve net thread responsiveness"...
211 2016-12-02T04:49:07  <bitcoin-git> bitcoin/master c4d22f6 Wladimir J. van der Laan: Merge #9229: Remove calls to getaddrinfo_a...
212 2016-12-02T04:49:21  <bitcoin-git> [bitcoin] laanwj closed pull request #9229: Remove calls to getaddrinfo_a (master...2016-11-gai) https://github.com/bitcoin/bitcoin/pull/9229
213 2016-12-02T04:49:31  *** CubicEarth has joined #bitcoin-core-dev
214 2016-12-02T04:49:57  <wumpus> btw flagging things as "needs backport" with "0.14" doesn't make much sense :-)
215 2016-12-02T04:51:30  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/b172377857f9b5a0b2f43e0e57be9acf82a6c50a
216 2016-12-02T04:51:30  <bitcoin-git> bitcoin/0.13 b172377 Matt Corallo: Revert "Use async name resolving to improve net thread responsiveness"...
217 2016-12-02T04:52:51  <sipa> wumpus: i merged a few things that still need backporting
218 2016-12-02T04:53:19  <wumpus> sipa: that's fine, we should probably do that in a pull grouping them together
219 2016-12-02T04:53:51  <wumpus> sipa: I just have a really bad feeling about the async resolving thing so backported that immediately
220 2016-12-02T04:54:08  *** CubicEarth has quit IRC
221 2016-12-02T04:55:03  <wumpus> sipa: I suppose they're all in this list? https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+label%3A%22Needs+backport%22+is%3Aclosed+milestone%3A0.13.2
222 2016-12-02T04:55:43  <wumpus> if not they should be labeled "Needs backport" with milestone 0.13.2
223 2016-12-02T04:56:13  <sipa> wumpus: yes
224 2016-12-02T05:00:08  <wumpus> heh this is the code in libc where it crashes: https://0bin.net/paste/V1n0GkHdlDatZrnO#N5htO2+DbXw1EtNNKz4oB-3ykuixE4KGJTLiZ56/V9L  to be specific: the if (--waitlist) line
225 2016-12-02T05:00:32  <wumpus> mind the "This is tricky.  See getaddrinfo_a.c for the reason why this works." comment :)
226 2016-12-02T05:02:23  <sipa> that does not look thread safe at all
227 2016-12-02T05:02:40  <Lightsword> wumpus, that’s not going to be externally exploitable is it for things that uses getaddrinfo?
228 2016-12-02T05:03:26  <wumpus> Lightsword: I don't *think* so, but it depends on what kind of bug this turns out to be
229 2016-12-02T05:03:35  <Lightsword> has upstream confirmed?
230 2016-12-02T05:05:29  <wumpus> it's not triggered by any specific data the remote is sending, if that's what you're worried about
231 2016-12-02T05:06:14  <wumpus> also it's not possible for P2P clients to make bitcoind do DNS lookups
232 2016-12-02T05:06:40  <wumpus> so no, I don't think this is a security issue for us, but you can't be too careful right...
233 2016-12-02T05:08:50  <wumpus> it's a confirmed use after free, not a NULL pointer dereference
234 2016-12-02T05:09:15  <fanquake> When are we planning on releasing 0.13.2 ? Looks like 5 backports left.
235 2016-12-02T05:09:36  <wumpus> it's doing "0x7ffff79b77f0 <__gai_notify+48>        subl   $0x1,(%rdx)" where rdx is, say, 0x441f0fc3c08944, then if you try to inspect that "0x441f0fc3c08944:       Cannot access memory at address 0x441f0fc3c08944" -- too bad, already unmapped
236 2016-12-02T05:09:39  <fanquake> *the first rc of 0.13.2
237 2016-12-02T05:09:55  <wumpus> Lightsword: sort of https://sourceware.org/bugzilla/show_bug.cgi?id=20874
238 2016-12-02T05:11:06  <wumpus> fanquake: well yesterday in the meeting there was agreement that all the 0.13.2 backports are labeled - so after these are backported rc1 can be released any time
239 2016-12-02T05:13:24  <fanquake> Ok. I need to start attending the meetings, but difficult with time-diff though.
240 2016-12-02T05:13:47  <wumpus> yes it's not a good time for australia/most of asia
241 2016-12-02T05:14:43  <fanquake> Also, not sure why I said 5 PRs left, there is only 9239, 9194 and 9191 (which includes multiple, mostly test-related fixes).
242 2016-12-02T05:15:13  <fanquake> It'll be right. Always have the logs, just need to make time for reading them. I think someone also posts a meeting summary to reddit or something.
243 2016-12-02T05:21:23  <wumpus> not just to reddit :) https://bitcoincore.org/en/meetings/2016/10/20/
244 2016-12-02T05:34:24  <wumpus> anyhow we could, say, alternate between two meeting times if there is a lot of demand for people from asia/australia to attend the meetings. But I've never really got that impression.
245 2016-12-02T05:36:58  <sipa> the meeting is on SHA256(days_since_1970) % 24 UTC.
246 2016-12-02T05:38:40  <gmaxwell> I ws thinking of suggesting alternating but then though that there probably isn't a good time for both asia and europe.
247 2016-12-02T05:38:42  <wumpus> sipa: theoretically that would be fair, in practice if you don't take the distribution of people over timezones into account, you may end up with a time that's only good for people who live in the middle of the atlantic ocean :-)
248 2016-12-02T05:39:50  <wumpus> gmaxwell: right I don't think there is
249 2016-12-02T05:39:55  <sipa> gmaxwell: 8 am UTC would be relatively good for both asia and europe
250 2016-12-02T05:40:27  <wumpus> 8 am UTC would be quite a good time for me
251 2016-12-02T05:41:00  <sipa> (9am in western europe, 4pm in hong kong, midnight on west coast)
252 2016-12-02T05:41:09  <sipa> 3am on east coast, however
253 2016-12-02T05:41:15  <gmaxwell> thats too late for east coast US though I don't know if we currently have any eastcoasters.
254 2016-12-02T05:41:22  <gmaxwell> oh instagibbs is duh.
255 2016-12-02T05:41:25  <sipa> morcos, suhas, instagibbs
256 2016-12-02T05:41:34  <gmaxwell> oh double duh.
257 2016-12-02T05:41:46  <wumpus> in any case every time would be bad for someone - so to motivate a (even bi-weekly) time change there has to be enough demand
258 2016-12-02T05:41:56  <gmaxwell> I just think of NY as existing in a parallel universe.
259 2016-12-02T05:42:19  <wumpus> e.g. just rebroad asking for it is not enough :p
260 2016-12-02T05:42:31  <gmaxwell> well we lose jl2012 due to this.
261 2016-12-02T05:42:50  <wumpus> yes and fanquake
262 2016-12-02T05:42:58  *** ThomasV has joined #bitcoin-core-dev
263 2016-12-02T05:43:55  <BlueMatt> lol, google has a thing where they will hook up your project to run in fuzzing on some machiens 24/7, except to do it you have to agree that they will announce the bug to the world 7 days after you release a fix
264 2016-12-02T05:44:08  <BlueMatt> who in their right mind would agree to that? thats like stupid high-risk for users
265 2016-12-02T05:45:14  <wumpus> it could make sense for software that auto-updates quickly and automatically
266 2016-12-02T05:45:18  <wumpus> but no, certainly not for bitcoin
267 2016-12-02T05:46:57  <BlueMatt> I mean they're talking about it for "critical infrastructure" (ie common libraries)
268 2016-12-02T05:47:16  <BlueMatt> like, sure, maybe google updates their libcs quickly, but the vast majority of folks do not at all
269 2016-12-02T05:47:16  <sipa> 4pm UTC: 8am westcoast, 11am eastcoast, 5pm europe, midnight hong kong
270 2016-12-02T05:48:46  <wumpus> BlueMatt: for libraries it's much harder to say, agreed, there will be tons of especially embedded platforms that never update them at all
271 2016-12-02T05:49:24  <wumpus> then again that's not google's fault - finding the vulnerabilities before the 'bad people' do is still important
272 2016-12-02T05:49:47  <BlueMatt> wumpus: sure, but that doesnt mean you announce them publicly 7 days after the first release with the fix
273 2016-12-02T05:50:23  <wumpus> (or alternatively, after the "bad people" have already used them for years to get access anwyay...)
274 2016-12-02T05:50:37  <BlueMatt> yes, you fix quickly, and then announce it much later
275 2016-12-02T05:50:38  <gmaxwell> BlueMatt: it's fine for projects that are alread well fuzzed, I suppose.
276 2016-12-02T05:51:01  <gmaxwell> NSA already found those vulns last week anyways.
277 2016-12-02T05:51:02  <BlueMatt> it might be better than /not/ doing the fuzzing, but its still a super shitty policy
278 2016-12-02T05:51:46  <wumpus> it's the old responsible disclosure discussion
279 2016-12-02T05:51:47  *** Hismione is now known as justanotheruser
280 2016-12-02T05:52:23  <BlueMatt> wumpus: responsible disclosure (usually) is a discussion about what to do when upstream tells you to fuck off, not what to do when upstream is responsive
281 2016-12-02T05:53:05  <wumpus> BlueMatt: sure, though part of it is how long to wait with public announcement
282 2016-12-02T05:53:18  <BlueMatt> suresure, but who the fuck ever suggested 7 days?
283 2016-12-02T06:01:46  <midnightmagic> responsible disclosure is using a timeline which is fair both to the public who is affected by the bug and the vendor, without unfairly prioritizing one over the other.
284 2016-12-02T06:02:31  <midnightmagic> The timelines *were once* measured in weeks, since the public good of disclosure was more important than protecting the financial interests of a corporation who wasn't remunerating the researcher.
285 2016-12-02T06:05:43  <BlueMatt> midnightmagic: yes, but one week? fuck people who just blindly update and would be protected wouldnt even get protected if you only wait 7 days
286 2016-12-02T06:06:07  <BlueMatt> midnightmagic: I mean I'm with you....fuck the vendor and their financial interests, users must be protected, but 7 days is short enough that you're harming users, too
287 2016-12-02T06:07:46  <midnightmagic> 7 days is pretty sure. At least Gobbles and/or that italian ultra-prolific guy isn't just dropping 0-days and letting the vendors scramble.
288 2016-12-02T06:07:51  <midnightmagic> *pretty short
289 2016-12-02T06:10:46  * midnightmagic tries to remember that italian guy again..
290 2016-12-02T06:12:40  *** Ylbam has quit IRC
291 2016-12-02T06:13:19  <midnightmagic> ah, here he is. I've come to appreciate the way he does things: http://aluigi.altervista.org/
292 2016-12-02T06:13:31  <midnightmagic> (not even vendor notification.)
293 2016-12-02T06:23:15  *** Ylbam has joined #bitcoin-core-dev
294 2016-12-02T06:44:57  *** cryptapus has joined #bitcoin-core-dev
295 2016-12-02T06:45:18  *** cryptapus_afk has quit IRC
296 2016-12-02T07:00:05  *** dermoth has quit IRC
297 2016-12-02T07:00:51  *** dermoth has joined #bitcoin-core-dev
298 2016-12-02T07:02:12  *** ThomasV has quit IRC
299 2016-12-02T07:03:10  <bitcoin-git> [bitcoin] luke-jr opened pull request #9263: release notes: Only free transactions are being removed, not priority. (master...relnotes_freetxn) https://github.com/bitcoin/bitcoin/pull/9263
300 2016-12-02T07:05:24  *** RoyceX has joined #bitcoin-core-dev
301 2016-12-02T07:05:28  *** RoyceX has joined #bitcoin-core-dev
302 2016-12-02T07:08:17  *** Cheeseo has quit IRC
303 2016-12-02T07:09:08  *** paveljanik has quit IRC
304 2016-12-02T07:10:55  *** aalex has joined #bitcoin-core-dev
305 2016-12-02T07:12:57  <bitcoin-git> [bitcoin] laanwj opened pull request #9264: 0.13.2 backports (0.13...2016_12_backports_0_13) https://github.com/bitcoin/bitcoin/pull/9264
306 2016-12-02T07:16:52  <jonasschnelli> What is preferable: two keypools one for change, one for external  OR  a keypool with keys flagged for internal or external use?
307 2016-12-02T07:17:15  <bitcoin-git> [bitcoin] laanwj closed pull request #9191: [qa] 0.13.2 Backports (0.13...Mf1611-q01302) https://github.com/bitcoin/bitcoin/pull/9191
308 2016-12-02T07:17:35  <wumpus> possibly the flagging approach is easier to do in a backwards compatible way - old versions can ignore the flags
309 2016-12-02T07:18:39  *** aalex has quit IRC
310 2016-12-02T07:19:07  <jonasschnelli> wumpus: good point..
311 2016-12-02T07:21:04  <jonasschnelli> for the deserialization (SerializationOp(Stream& s, ...)), if the stream is longer then the acctual READWRITE, it will be ignored? right? (for backward comp.)
312 2016-12-02T07:21:26  <jtimon> python3 ./qa/pull-tester/rpc-tests.py mempool_packages takes 31s in my computer, would it be crazy to move it from the extended test to the regular ones?
313 2016-12-02T07:21:29  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c4d22f6eb216...3fbf07926240
314 2016-12-02T07:21:30  <bitcoin-git> bitcoin/master d824ad0 Alex Morcos: Disable fee estimates for a confirm target of 1 block
315 2016-12-02T07:21:31  <bitcoin-git> bitcoin/master e878689 Alex Morcos: Make GUI incapable of setting tx confirm target of 1
316 2016-12-02T07:21:31  <bitcoin-git> bitcoin/master 3fbf079 Wladimir J. van der Laan: Merge #9239: Disable fee estimates for 1 block target...
317 2016-12-02T07:21:39  <bitcoin-git> [bitcoin] laanwj closed pull request #9239: Disable fee estimates for 1 block target (master...blockstreamtil2blocks) https://github.com/bitcoin/bitcoin/pull/9239
318 2016-12-02T07:25:01  <luke-jr> wumpus: doh, I was about to do that (more backports)
319 2016-12-02T07:26:10  <dcousens> BlueMatt: don't miners use priority for their own transactions?
320 2016-12-02T07:26:25  <fanquake> jtimon takes 51s here
321 2016-12-02T07:26:26  <dcousens> (not the coinbase, just, "other" transactions)
322 2016-12-02T07:29:02  <jonasschnelli> wumpus: I could do a BP of #8989
323 2016-12-02T07:29:04  <gribble> https://github.com/bitcoin/bitcoin/issues/8989 | [Qt] overhaul smart-fee slider, adjust default confirmation target by jonasschnelli · Pull Request #8989 · bitcoin/bitcoin · GitHub
324 2016-12-02T07:29:32  <wumpus> jonasschnelli: not sure that's what we want though?
325 2016-12-02T07:29:34  <luke-jr> dcousens: fee delta works fine for that use case
326 2016-12-02T07:29:55  <wumpus> jonasschnelli: I mean, this is a minor release, how much do we want the GUI to change?
327 2016-12-02T07:29:56  <jonasschnelli> Yes. It would be a notable change.
328 2016-12-02T07:30:15  <wumpus> maybe it's ok though in this case I'm not sure
329 2016-12-02T07:30:20  <jonasschnelli> Can we BP #9239 without the GUI changes?
330 2016-12-02T07:30:22  <gribble> https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
331 2016-12-02T07:30:24  <jtimon> fanquake: thanks, still, I don't see a consistency in times between extended and non-extended tests, I have a little commit in a long branch that I can cherry pick based only on what makes sense for my computer based only on time, introducing -skipslow that works with or without extended, but it looks a little bit too complicated
332 2016-12-02T07:30:39  <wumpus> you could reply that in the #9239 topic, probably morcos has an opinoin on it too :)
333 2016-12-02T07:30:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
334 2016-12-02T07:31:07  <jonasschnelli> wumpus: or just disabled (shorten the slider range) for target 1 in the backport
335 2016-12-02T07:31:12  * wumpus wishes gribble had rate-limiting
336 2016-12-02T07:31:16  <wumpus> jonasschnelli: yep, exactly
337 2016-12-02T07:31:56  <wumpus> jonasschnelli: although that may turn out to be a riskier/less-tested solution than #8989 which at least has been tested in master. DIfficult.
338 2016-12-02T07:31:59  <gribble> https://github.com/bitcoin/bitcoin/issues/8989 | [Qt] overhaul smart-fee slider, adjust default confirmation target by jonasschnelli · Pull Request #8989 · bitcoin/bitcoin · GitHub
339 2016-12-02T07:32:26  <jonasschnelli> Yes. IMO 8989 and 9239 is sort of one BP "package"
340 2016-12-02T07:32:43  <wumpus> jonasschnelli: in that case we should just backport both I guess
341 2016-12-02T07:32:48  <jonasschnelli> Agree
342 2016-12-02T07:33:07  <jonasschnelli> I can do that next week...
343 2016-12-02T07:33:17  <jonasschnelli> (if nobody did it in the meantime)
344 2016-12-02T07:34:13  <wumpus> luke-jr: good that you hadn't started yet, then, would have been a waste of work as some had manual conflicts to resolve (though you could check if you resolved them in the same way :)
345 2016-12-02T07:34:23  <luke-jr> wumpus: well, I had started.. but I can rebase :x
346 2016-12-02T07:34:44  <luke-jr> I went through the PRs manually, not using tags, so I probably got a few you missed
347 2016-12-02T07:34:53  <luke-jr> (well, *almost* manually.. XD)
348 2016-12-02T07:35:08  <wumpus> well I strictly backport what is tagged, not more, if not it should have been tagged
349 2016-12-02T07:37:24  <luke-jr> wumpus: erg, your backports aren't on top of Marco's? :x
350 2016-12-02T07:37:41  <wumpus> luke-jr: no, I forgot about that one, will rebase
351 2016-12-02T07:38:21  <wumpus> now they are (luckily no new conflicts)
352 2016-12-02T07:41:26  <luke-jr> woo no conflicts here either it seems
353 2016-12-02T07:42:48  *** jannes has joined #bitcoin-core-dev
354 2016-12-02T07:57:10  <bitcoin-git> [bitcoin] laanwj opened pull request #9265: bitcoin-cli: Make error message less confusing (master...2016_12_rpccli_message) https://github.com/bitcoin/bitcoin/pull/9265
355 2016-12-02T07:59:15  <luke-jr> wumpus: pushed backports-0.13 to my github; want to just pull it into yours?
356 2016-12-02T08:00:19  *** xiangfu has quit IRC
357 2016-12-02T08:00:31  <wumpus> luke-jr: will have a look in a moment
358 2016-12-02T08:00:59  *** xiangfu has joined #bitcoin-core-dev
359 2016-12-02T08:02:46  *** BashCo has quit IRC
360 2016-12-02T08:03:22  *** BashCo has joined #bitcoin-core-dev
361 2016-12-02T08:07:44  *** BashCo has quit IRC
362 2016-12-02T08:13:59  <BlueMatt> dcousens: and the "add fee" logic will continue to be maintained....but that isnt the "priority" code - this refers specifically to coin days-destroyed logic
363 2016-12-02T08:15:02  <luke-jr> the priority code will be as well.
364 2016-12-02T08:15:21  <sipa> no, it won't
365 2016-12-02T08:15:23  <wumpus> luke-jr: looks ok to me - though I'm not entirely sure about the qt memory leak commits, they are all pretty minor one-time leaks, so users shouldn't notice it
366 2016-12-02T08:15:28  <sipa> it serves no function anymore
367 2016-12-02T08:15:40  <luke-jr> sipa: yes it does, the same function it always served: anti-spam
368 2016-12-02T08:15:52  <wumpus> luke-jr: still makes sense to clean them up, but not sure whether the backport is risky
369 2016-12-02T08:16:04  <luke-jr> wumpus: I don't care strongly if you want to skip those
370 2016-12-02T08:16:25  <luke-jr> the backport may be risky, but if we have an rc or two, I'd put it in
371 2016-12-02T08:16:44  <wumpus> luke-jr: also the menu reparenting may have subtle behavior issues I hadn't considered (though none reported yet)
372 2016-12-02T08:16:53  <wumpus> yes, sure
373 2016-12-02T08:16:57  <sipa> luke-jr: so blocks with 950 kb of spam is fine, and 50kb of transactions from bitcoin old timers that doesn't really pays miners a competitive price will save anything?
374 2016-12-02T08:17:22  <sipa> the only scalable way to deal with this is economic incentives
375 2016-12-02T08:17:25  <luke-jr> sipa: it would be better than 1000 kb of spam :P
376 2016-12-02T08:17:40  <wumpus> lukanyhow I'll pull them into #9264
377 2016-12-02T08:17:41  <sipa> and face it, that is how it works in practice now
378 2016-12-02T08:17:42  <gribble> https://github.com/bitcoin/bitcoin/issues/9264 | 0.13.2 backports by laanwj · Pull Request #9264 · bitcoin/bitcoin · GitHub
379 2016-12-02T08:17:45  <luke-jr> if we go to exclusively economic incentives, we'd need to remove ALL spam filtering..
380 2016-12-02T08:18:05  <sipa> luke-jr: there are still local node dos protections
381 2016-12-02T08:18:24  <sipa> which everyone has an incentive to maintain
382 2016-12-02T08:18:36  <sipa> and don't requires miners to be gatekeepers of good and bad transactions
383 2016-12-02T08:19:10  <luke-jr> sipa: if we had a system that wasn't suffering from spam, removing priority might make sense. but we don't.
384 2016-12-02T08:19:30  <sipa> luke-jr: removing priority will have 0 impact
385 2016-12-02T08:21:14  <sipa> wallets don't use it anymore, (almost all) miners don't use it anymore - even if it was usable as a means to distinguish better from worse usage of block space, it isn't anymore
386 2016-12-02T08:21:56  <luke-jr> has someone shown that to be true?
387 2016-12-02T08:22:05  *** BashCo has joined #bitcoin-core-dev
388 2016-12-02T08:22:09  <luke-jr> last time I looked, a large % of transactions in blocks were in the priority area
389 2016-12-02T08:22:33  <luke-jr> (not majority-large, but not <5% either)
390 2016-12-02T08:22:55  <sipa> fair enough, i have no actual data on his
391 2016-12-02T08:22:59  <sipa> *this
392 2016-12-02T08:23:06  <sipa> but how do you measure that?
393 2016-12-02T08:23:56  <luke-jr> I wrote a RPC call that analyzed the sort order
394 2016-12-02T08:27:41  *** paveljanik has joined #bitcoin-core-dev
395 2016-12-02T08:27:57  * luke-jr tries porting it to 0.13
396 2016-12-02T08:28:46  *** paveljanik has quit IRC
397 2016-12-02T08:40:08  *** arowser_ has quit IRC
398 2016-12-02T08:40:22  *** arowser has joined #bitcoin-core-dev
399 2016-12-02T08:46:35  *** ThomasV has joined #bitcoin-core-dev
400 2016-12-02T08:53:46  *** jannes has quit IRC
401 2016-12-02T08:54:09  <luke-jr> ugh this thing is slooooooow
402 2016-12-02T09:00:16  *** molz has joined #bitcoin-core-dev
403 2016-12-02T09:00:17  *** abpa has quit IRC
404 2016-12-02T09:01:17  *** moli has quit IRC
405 2016-12-02T09:07:42  <jtimon> for those interested in more configurable testchains: https://github.com/bitcoin/bitcoin/pull/8994#issuecomment-264406053
406 2016-12-02T09:17:24  *** ThomasV has quit IRC
407 2016-12-02T09:17:55  *** laurentmt has joined #bitcoin-core-dev
408 2016-12-02T09:29:34  *** juscamarena has joined #bitcoin-core-dev
409 2016-12-02T09:35:47  *** e4xit_ has joined #bitcoin-core-dev
410 2016-12-02T09:37:54  *** e4xit has quit IRC
411 2016-12-02T09:37:54  *** e4xit_ is now known as e4xit
412 2016-12-02T09:50:18  *** kadoban has quit IRC
413 2016-12-02T10:02:17  <luke-jr> oh, it'd also imply removing the soft blockmaxsize, which is essential since >1 MB blocks are not safe right now. which would therefore imply segwit should be rejected. not a good hole to go down IMO.
414 2016-12-02T10:23:05  *** cannon-c has joined #bitcoin-core-dev
415 2016-12-02T10:25:21  *** laurentmt1 has joined #bitcoin-core-dev
416 2016-12-02T10:26:19  *** laurentmt has quit IRC
417 2016-12-02T10:26:19  *** laurentmt1 is now known as laurentmt
418 2016-12-02T10:35:14  *** xiangfu has quit IRC
419 2016-12-02T10:35:46  *** xiangfu has joined #bitcoin-core-dev
420 2016-12-02T10:39:34  *** moli has joined #bitcoin-core-dev
421 2016-12-02T10:42:21  *** molz has quit IRC
422 2016-12-02T11:02:28  *** cannon-c has quit IRC
423 2016-12-02T11:09:48  *** Guyver2 has joined #bitcoin-core-dev
424 2016-12-02T11:14:11  *** JackH has joined #bitcoin-core-dev
425 2016-12-02T11:17:25  *** laurentmt has quit IRC
426 2016-12-02T11:21:52  *** ThomasV has joined #bitcoin-core-dev
427 2016-12-02T12:00:57  <luke-jr> sipa: CPFP and some other weirdness I don't recognise kinda made my analyzer useless :/
428 2016-12-02T12:22:18  *** BashCo_ has joined #bitcoin-core-dev
429 2016-12-02T12:22:27  <luke-jr> jonasschnelli: is it just me, or is 0a261b63fd4f1b07431f8a65762ef9f1ef1c11c8 a bugfix that should be backported?
430 2016-12-02T12:25:41  *** BashCo has quit IRC
431 2016-12-02T12:37:03  *** ThomasV has quit IRC
432 2016-12-02T12:52:46  <gmaxwell> luke-jr: I think we should remove the softmax blocksize. I think it's harmful to the network to have some miners producing smaller blocks when there is a high fee backlog.
433 2016-12-02T12:56:07  <luke-jr> so just ignore all the much bigger problems large blocks are causing? why is fee so important? it doesn't seem likely larger blocks are going to significantly change the fee rate either.. :/
434 2016-12-02T13:00:02  <gmaxwell> luke-jr: having it set lower makes the larger block problem _worse_: vitually all miners just set it to the maximum, and then we pretend like we've done something useful there instead of actually doing something useful. (like implementing a dynamic soft cap so that when demand goes down feerates don't drob absurdly low)
435 2016-12-02T13:00:19  <gmaxwell> s/drob/drop/
436 2016-12-02T13:01:31  <luke-jr> not sure I follow; that sounds like the topic has changed to the *default* maxblocksize, but I'm talking about the option itself.
437 2016-12-02T13:01:38  <luke-jr> wouldn't the latter just be the min fee setting?
438 2016-12-02T13:05:20  <gmaxwell> luke-jr: sort of. minfee setting is really a relay setting, it gets in the way of CPFP. Should be intentionally low
439 2016-12-02T13:07:50  <luke-jr> perhaps the gradual min-feerate would be a good thing to reintroduce
440 2016-12-02T13:07:56  <gmaxwell> I think the problems of propagation are more or less solved for the moment, so the concerns are bulk blockchain growth and fee behavior predictablity.  Having a couple miners going around confirming stuff with absurdly low fees or failing to confirm stuff with decent fees doesn't help.
441 2016-12-02T13:08:22  <luke-jr> hmm, would gradual min-feerate break prediction?
442 2016-12-02T13:09:37  <gmaxwell> No. At least if constructed right it should improve it (esp if the prediction is aware of it).
443 2016-12-02T13:10:20  <morcos> gmaxwell: i'd be strongly in favor of a separate min mining feerate
444 2016-12-02T13:10:56  <morcos> do you actually want to remove blockmaxsize (and blockmaxweight?) as options?
445 2016-12-02T13:11:42  *** MykelSIlver has joined #bitcoin-core-dev
446 2016-12-02T13:11:44  <morcos> i don't feel strongly about that, but i do think we should avoid setting blockmaxsize as default. i tried to benchmark the behavior and didn't show it being a big performance hit
447 2016-12-02T13:11:49  <morcos> but thats counterintuitive
448 2016-12-02T13:12:01  <morcos> and i'd rather not risk it by default
449 2016-12-02T13:12:03  <gmaxwell> I think we should default them to maximum at a minimum. Removing them-- I don't really care probably removing them would irritate someone, so not worth doing. I don't think they're useful controls (beyond overriding our dumb maximum)
450 2016-12-02T13:12:26  <morcos> right.. so default no setting for blockmaxsize in particular (to avoid size accounting unless you set it)
451 2016-12-02T13:12:50  <gmaxwell> right.
452 2016-12-02T13:13:53  <morcos> wumpus: you can backport just the first commit of #9239. i will separately test, but that was the intent.  the only difference will be you will slide the slider to 1 but it will give you an answer for 2
453 2016-12-02T13:13:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9239 | Disable fee estimates for 1 block target by morcos · Pull Request #9239 · bitcoin/bitcoin · GitHub
454 2016-12-02T13:14:07  <morcos> which is exactly what happens most of the time now anyway.. so will look like no change in behavior
455 2016-12-02T13:14:41  <gmaxwell> Today, with BIP152 and fibre propagation has very little to do with blockmaxsize. And blockmaxweight is the wrong dimension for applying backpressure on fees: it's blind to demand, you'll still dumbly produce smaller blocks when there is a nice backlog and dumly produce blocks that are too big when there is none (at least the minfee stops the bleeding there)
456 2016-12-02T13:15:01  * luke-jr notes that >1 MB blocks are still a problem as-is; it's not like gradual mining min-fee is implemented yet
457 2016-12-02T13:16:14  <gmaxwell> luke-jr: yes, but a pointless softcap that virtually everone overrides is still not helping.
458 2016-12-02T13:16:27  <luke-jr> gmaxwell: nobody overrides it >1 MB yet AFAIK.
459 2016-12-02T13:17:08  <morcos> I think I went through this before, but can't see where I wrote it up.  I think we actually need 3 minimum rates and minrelaytxfee (a default minimum for the mempool) is not one of them
460 2016-12-02T13:17:16  <morcos> 1) min mining feerate
461 2016-12-02T13:17:33  <morcos> 2) rate used to define dust (should change rarely)
462 2016-12-02T13:17:57  <morcos> 3) rate used as the minimum increment to pay for relay bandwidth (closest analog to existing minrelaytxfee)
463 2016-12-02T13:18:30  <luke-jr> morcos: how would 3 be different from current minrelaytxfee?
464 2016-12-02T13:18:46  <morcos> I don't think 3) actually needs to a have a floor other than 0, but i don't suppose it hurts
465 2016-12-02T13:18:55  <gmaxwell> luke-jr: they all will as soon as it matters, we trained them to with an unreasonable default.  Last non-empty block that was under 990k was 217 blocks ago.
466 2016-12-02T13:19:58  <luke-jr> as soon as it matters, would still be better than immediately by default
467 2016-12-02T13:20:27  <gmaxwell> morcos: having a floor makes the system behavior more stable in any case, no real reason to go forwarding around low fee stuff that won't get mined ever just because we have nothing better to relay. :)
468 2016-12-02T13:20:33  <morcos> although i guess, having a user set minimum for your mempool might be something people want (and a good fail safe if we get something wrong) so maybe we do want all 4
469 2016-12-02T13:20:38  *** aalex has joined #bitcoin-core-dev
470 2016-12-02T13:21:40  <morcos> gmaxwell: sure, but its inherently rate limited by the mempool min fee..  but i agree. i don't know what i'm arguing that point... and separating 3 and 4 is the least important concern.
471 2016-12-02T13:21:50  <gmaxwell> luke-jr: yes it is worse because it puts everyone in the mode of just nailing it to the maximum, which would undermine doing something sensible and dynamic.
472 2016-12-02T13:22:14  <luke-jr> but we don't have anything sensible and dynamic yet.
473 2016-12-02T13:22:16  <morcos> i guess the only reason it matters is if someone wants to set their minimum higher to say 10 sat/byte, then thats not clear that they really want their increment requirement to be 10 sat/byte
474 2016-12-02T13:24:02  <gmaxwell> luke-jr: of course not, we have a nearly useless setting instead which you spend a lot of effort defending. This impedes doing something smarter.
475 2016-12-02T13:24:35  <luke-jr> it doesn't impede anything..
476 2016-12-02T13:25:27  <gmaxwell> I promise it does, touching any of this means arguing with you and few people have interest in that.
477 2016-12-02T13:25:55  <gmaxwell> and there is the polite lie that something already is there, there is a blocksize setting, you can make it larger or smaller, problem solved.
478 2016-12-02T13:26:48  <jonasschnelli> I think the HD chain splitting will not be backward compatible. Adding a flag to CKeyPool would result in possible external keys from the internal chain on older versions of core
479 2016-12-02T13:27:08  <jonasschnelli> Also, CKeyPool has no version-int.
480 2016-12-02T13:27:10  <luke-jr> [12:22:27] <luke-jr> jonasschnelli: is it just me, or is 0a261b63fd4f1b07431f8a65762ef9f1ef1c11c8 a bugfix that should be backported?
481 2016-12-02T13:27:37  *** aalex has quit IRC
482 2016-12-02T13:27:52  <gmaxwell> I said it would be incompatible a bunch of times.
483 2016-12-02T13:28:38  <jonasschnelli> I though we could make it compatible.. but yes. I guess it wont.
484 2016-12-02T13:29:39  <jonasschnelli> Then I try to add a new record type, maybe "hdkey" that stores the keypath (int / ext chain) as well as the masterkey and the according pubkey.
485 2016-12-02T13:29:48  <jonasschnelli> GetKey could derive the priv key on the fly
486 2016-12-02T13:30:15  <jonasschnelli> luke-jr: we could bp... but o
487 2016-12-02T13:30:33  <jonasschnelli> but i guess its not an important fix
488 2016-12-02T13:31:08  *** laurentmt has joined #bitcoin-core-dev
489 2016-12-02T13:32:14  <gmaxwell> what I was commenting on before was that we probably want to do several incompatible changes at once, so we don't end up having to support dozens of old versions.
490 2016-12-02T13:33:07  <jonasschnelli> gmaxwell: Yes. That would be preferable. I think the splitting should be combined with the on-thy-fly derivation and the flexible keypath.
491 2016-12-02T13:33:19  <jonasschnelli> Ideally +pub-CKD
492 2016-12-02T13:34:59  <jcorgan> i haven't kept up recently, but are there any relevant BIPS or defacto practices from other wallets we should be paying attention to in this area?
493 2016-12-02T13:35:57  <jonasschnelli>  bip44/45 maybe. But I don't think its wise to force users to do pub key derivation.
494 2016-12-02T13:36:34  <jonasschnelli> a flexible would allow to use bip44 and we could still stick to m/0'/k' by default
495 2016-12-02T13:36:41  <jonasschnelli> a flexible keypath
496 2016-12-02T13:37:21  <jcorgan> reviewing the flexpath PR is on my list this morning
497 2016-12-02T13:38:15  <jonasschnelli> thanks
498 2016-12-02T13:39:41  <jcorgan> but, i'm mostly just wondering if there are any good practices from other wallets we might benefit from understanding
499 2016-12-02T13:39:50  <jcorgan> just thinking out loud
500 2016-12-02T13:40:53  *** laurentmt has quit IRC
501 2016-12-02T13:43:35  <gmaxwell> Doing public derrivation while the software supports private key export is really extremely inadvisable.
502 2016-12-02T13:43:49  *** MarcoFalke has joined #bitcoin-core-dev
503 2016-12-02T13:44:02  <gmaxwell> I also don't think it makes sense to spend time on advanced features when basic functionality is still kinda broken.
504 2016-12-02T13:44:12  <gmaxwell> but I'm not the one working on it. :)
505 2016-12-02T13:44:46  <jcorgan> agree, but it's important to define what unbroken basic functionality should be :)
506 2016-12-02T13:45:39  <jcorgan> in other words, if there is to be breaking changes, and you only want to break it once, better get it right
507 2016-12-02T13:46:50  <jcorgan> i didn't mean to jump into the middle of your thread, just noticed it and taking an interest. carry on.
508 2016-12-02T13:47:46  <jonasschnelli> I agree with gmaxwell. We first need to solve the key-chain split.
509 2016-12-02T13:48:20  <jonasschnelli> child key derivation is an interesting feature if you want to use core together with a hardware wallet.
510 2016-12-02T13:48:27  <jonasschnelli> child pub key d.
511 2016-12-02T13:50:35  <bitcoin-git> [bitcoin] luke-jr opened pull request #9266: Qt/RPCConsole: Put column enum in the right places (master...bugfix_datarole) https://github.com/bitcoin/bitcoin/pull/9266
512 2016-12-02T13:54:15  *** Giszmo has joined #bitcoin-core-dev
513 2016-12-02T14:02:33  *** paveljanik has joined #bitcoin-core-dev
514 2016-12-02T14:02:33  *** paveljanik has joined #bitcoin-core-dev
515 2016-12-02T14:29:24  *** aalex has joined #bitcoin-core-dev
516 2016-12-02T14:34:22  *** ThomasV has joined #bitcoin-core-dev
517 2016-12-02T14:43:25  *** moli has quit IRC
518 2016-12-02T14:49:52  *** fanquake has quit IRC
519 2016-12-02T14:50:36  *** moli has joined #bitcoin-core-dev
520 2016-12-02T14:50:52  *** wasi has quit IRC
521 2016-12-02T14:51:36  *** wasi has joined #bitcoin-core-dev
522 2016-12-02T14:56:17  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fbf07926240...31bcc667863f
523 2016-12-02T14:56:17  <bitcoin-git> bitcoin/master fe37fbe Wladimir J. van der Laan: bitcoin-cli: Make error message less confusing...
524 2016-12-02T14:56:18  <bitcoin-git> bitcoin/master 31bcc66 MarcoFalke: Merge #9265: bitcoin-cli: Make error message less confusing...
525 2016-12-02T14:56:32  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9265: bitcoin-cli: Make error message less confusing (master...2016_12_rpccli_message) https://github.com/bitcoin/bitcoin/pull/9265
526 2016-12-02T14:59:44  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/31bcc667863f...5412c08c3cf1
527 2016-12-02T14:59:44  <bitcoin-git> bitcoin/master b7aa290 S. Matthew English: unification of Bloom filter representation...
528 2016-12-02T14:59:45  <bitcoin-git> bitcoin/master 5412c08 MarcoFalke: Merge #9223: unification of Bloom filter representation...
529 2016-12-02T14:59:55  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9223: unification of Bloom filter representation (master...patch-10) https://github.com/bitcoin/bitcoin/pull/9223
530 2016-12-02T15:21:16  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5412c08c3cf1...98514988a3d3
531 2016-12-02T15:21:16  <bitcoin-git> bitcoin/master 08ed8c1 Gregory Maxwell: Developer docs about existing subtrees....
532 2016-12-02T15:21:17  <bitcoin-git> bitcoin/master 9851498 MarcoFalke: Merge #9246: Developer docs about existing subtrees....
533 2016-12-02T15:21:27  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9246: Developer docs about existing subtrees. (master...devdocs_for_subtrees) https://github.com/bitcoin/bitcoin/pull/9246
534 2016-12-02T15:25:32  *** bsm117532 has quit IRC
535 2016-12-02T15:26:37  *** bsm117532 has joined #bitcoin-core-dev
536 2016-12-02T15:41:56  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/98514988a3d3...d7ba4a233bd5
537 2016-12-02T15:41:56  <bitcoin-git> bitcoin/master 0828619 Suhas Daftuar: [qa] Dump debug logs on travis failures.
538 2016-12-02T15:41:57  <bitcoin-git> bitcoin/master d7ba4a2 MarcoFalke: Merge #9257: [qa] Dump debug logs on travis failures....
539 2016-12-02T15:42:13  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9257: [qa] Dump debug logs on travis failures. (master...travis-debug-logs) https://github.com/bitcoin/bitcoin/pull/9257
540 2016-12-02T15:43:11  *** kadoban has joined #bitcoin-core-dev
541 2016-12-02T15:44:22  *** fengling has quit IRC
542 2016-12-02T15:45:02  <bitcoin-git> [bitcoin] morcos opened pull request #9267: Disable fee estimates for a confirm target of 1 block (0.13...backport9239) https://github.com/bitcoin/bitcoin/pull/9267
543 2016-12-02T15:45:18  *** fengling has joined #bitcoin-core-dev
544 2016-12-02T15:45:41  *** Magma has quit IRC
545 2016-12-02T15:45:57  *** Magma has joined #bitcoin-core-dev
546 2016-12-02T15:53:11  *** Magma has quit IRC
547 2016-12-02T15:55:31  *** abpa has joined #bitcoin-core-dev
548 2016-12-02T15:55:53  *** molz has joined #bitcoin-core-dev
549 2016-12-02T15:56:46  *** abpa has quit IRC
550 2016-12-02T15:58:05  *** moli has quit IRC
551 2016-12-02T16:06:55  *** laurentmt has joined #bitcoin-core-dev
552 2016-12-02T16:06:58  *** laurentmt has quit IRC
553 2016-12-02T16:08:48  *** fengling has quit IRC
554 2016-12-02T16:10:37  <MarcoFalke> sipa: I think this is needed to get our subtree clean again
555 2016-12-02T16:10:41  <MarcoFalke> https://github.com/bitcoin-core/ctaes/pull/5
556 2016-12-02T16:11:51  *** ThomasV has quit IRC
557 2016-12-02T16:24:43  *** laurentmt has joined #bitcoin-core-dev
558 2016-12-02T16:25:59  *** laurentmt has quit IRC
559 2016-12-02T16:26:00  <instagibbs> can anyone explain why this isn't setting the argument correctly?:
560 2016-12-02T16:26:00  <instagibbs>          self.extra_args = [['-usehd={:d}'.format(i%2==0)] for i in range(4)]
561 2016-12-02T16:26:01  <instagibbs> +        self.extra_args[0].append("-limitancestorcount=10")
562 2016-12-02T16:26:19  <instagibbs> I'm trying to set a custom limit in test, and it's not being enforced
563 2016-12-02T16:30:17  *** 44UAAAJXO has joined #bitcoin-core-dev
564 2016-12-02T16:30:17  *** fengling has joined #bitcoin-core-dev
565 2016-12-02T16:31:33  <instagibbs> ahhhh nevermind, the node is being spun down and up later in the test
566 2016-12-02T16:32:27  *** laurentmt has joined #bitcoin-core-dev
567 2016-12-02T16:35:40  *** laurentmt has quit IRC
568 2016-12-02T16:37:07  <MarcoFalke> Yeah, we should use self.extra_args as argument where possible, instead of writing out the args every time.
569 2016-12-02T16:43:35  *** Magma has joined #bitcoin-core-dev
570 2016-12-02T16:44:33  *** 44UAAAJXO has quit IRC
571 2016-12-02T16:45:04  *** abpa has joined #bitcoin-core-dev
572 2016-12-02T16:47:52  *** kadoban has quit IRC
573 2016-12-02T16:49:25  *** jtimon has quit IRC
574 2016-12-02T16:58:15  *** BashCo_ has quit IRC
575 2016-12-02T16:59:08  *** molz has quit IRC
576 2016-12-02T17:03:19  <instagibbs> sdaftuar, how does one get the cached value?
577 2016-12-02T17:03:37  <sdaftuar> instagibbs: oy, i'm thinking about it now. ancestor count is easy, but the descenadnt count is not...
578 2016-12-02T17:03:54  <instagibbs> how often will that one trigger in wallet context though?
579 2016-12-02T17:03:55  <sdaftuar> unfortunately the test we want to do is, what is the max number of descendants that any of pcoin's ancestors have?
580 2016-12-02T17:04:11  <sdaftuar> and also, i think we should compare those values to some lower thresholds (say 10 instead of 25)
581 2016-12-02T17:04:37  <instagibbs> I'm finding bugs with my implementation with non-standard values
582 2016-12-02T17:05:10  <sdaftuar> well i think your implementation would never skip over any pcoins?  except if the chain limits are violated in a reorg
583 2016-12-02T17:05:10  <instagibbs> it always only fails at the 25 threshhold, unsure why. If we have an ancestor one already cached, we might just use that
584 2016-12-02T17:05:21  <instagibbs> seems less error-prone, and should catch the common case?
585 2016-12-02T17:06:16  <instagibbs> im not sure what you mean?
586 2016-12-02T17:06:17  <sdaftuar> so to answer your first question, each mempool entry has a value nCountWithAncestors
587 2016-12-02T17:06:36  <instagibbs> how do I access that entry
588 2016-12-02T17:06:57  <instagibbs> (looking)
589 2016-12-02T17:07:39  <sdaftuar> instagibbs: might need to add some kind of accessor, but mempool.mapTx.find(txid) or something should do it.
590 2016-12-02T17:08:02  <sdaftuar> since we're already checking to see that it's in the mempool, this seems okay to me
591 2016-12-02T17:08:58  <sdaftuar> CalculateMemPoolAncestors() can be a bit expensive, fyi
592 2016-12-02T17:09:23  <sdaftuar> but in order to do the descendant calculation properly, we'd need to call CMPA on the pcoins in question, and then check the descendant count of each ancestor returned
593 2016-12-02T17:09:42  <sdaftuar> (which i guess is equivalent to calling CMPA with lower thresholds)
594 2016-12-02T17:09:52  *** moli has joined #bitcoin-core-dev
595 2016-12-02T17:10:45  <sdaftuar> i'm not sure though how reasonable it is to call CMPA inside AvailableCoins?  if somehow your wallet has a lot of in-mempool stuff, this could be slow.  not sure how to think about it.
596 2016-12-02T17:11:22  <instagibbs> I don't understand. I likely don't understand what CMPA is actually doing. I thought it was already checking for limit violations
597 2016-12-02T17:12:16  <sdaftuar> you're trying to see if a transaction that spends pcoins would be a limit violation.  you're checking to see if pcoins itself would fail to get into the mempool based on the configured limits.
598 2016-12-02T17:12:20  <sdaftuar> but you know it's already in the mempool
599 2016-12-02T17:12:38  <sdaftuar> so almost by definition, those limits won't be violated
600 2016-12-02T17:12:55  <sdaftuar> (turns out there is some weird edge case behavior where it could be, but i think that's beside the point)
601 2016-12-02T17:14:44  <sdaftuar> oh, maybe i didn't make this clear: we call CMPA when we try to accept a new tx to the mempool.  so if it's already gotten in -- a precondition of your code -- then calling it again on that tx, with the same limits, really shouldn't fail.
602 2016-12-02T17:18:46  <instagibbs> ok now I'm confused why this works in the general case then.
603 2016-12-02T17:18:51  <instagibbs> with default values
604 2016-12-02T17:18:59  <sdaftuar> hmm.  do you have a test i can look at?
605 2016-12-02T17:19:43  *** laurentmt has joined #bitcoin-core-dev
606 2016-12-02T17:19:45  <instagibbs> yes but its very easy to test the base case
607 2016-12-02T17:19:54  <instagibbs> let me push my test im working on
608 2016-12-02T17:20:02  *** laurentmt has quit IRC
609 2016-12-02T17:20:54  <instagibbs> just send all your coins to yourself in a loop 26 times
610 2016-12-02T17:21:14  <instagibbs> last time will trigger ATMP failure without these lines, with it triggers "Insufficient funds"
611 2016-12-02T17:21:30  <sdaftuar> interesting, i'll take a look
612 2016-12-02T17:25:25  <instagibbs> you're right though, this makes no sense in retrospect
613 2016-12-02T17:28:24  * sdaftuar just learned about set_trace, whoa!
614 2016-12-02T17:28:37  <instagibbs> wait... how do you write all those tests o_0
615 2016-12-02T17:28:46  <sdaftuar> slowly :)
616 2016-12-02T17:29:21  <instagibbs> i think it spawns zombies if you run in batch mode, be careful :P
617 2016-12-02T17:30:20  <instagibbs> that test has "10" as the limit, but it successfully sends 25 times
618 2016-12-02T17:30:28  <instagibbs> no matter what it's set to
619 2016-12-02T17:30:36  *** BashCo has joined #bitcoin-core-dev
620 2016-12-02T17:30:47  <instagibbs> and the error message changes to mempool entry failure if you set a different value...
621 2016-12-02T17:31:47  <sdaftuar> ah i think i see what's happening.
622 2016-12-02T17:32:02  <sdaftuar> there might be some edge case bugs in CMPA we ought to fix
623 2016-12-02T17:33:09  <sdaftuar> oh but it looks like for limit purposes, CMPA is trying to calculate whether adding the tx given would cause the limits to be exceeded.
624 2016-12-02T17:33:17  <sdaftuar> ugh, this is kind of messy
625 2016-12-02T17:34:05  <gmaxwell> sdaftuar: you're clear on the goal right? don't consider any coin we couldn't actually spend.
626 2016-12-02T17:34:31  <sdaftuar> gmaxwell: yes, understood.
627 2016-12-02T17:35:16  <gmaxwell> I wouldn't worry much about the coinselection being slow if you have many unspent inputs-- so long as slow isn't so slow as to cause rpc timeouts.
628 2016-12-02T17:36:10  <gmaxwell> The code that figured out if all the parents were confirmed or ismine used to have factorial complexity... nice natural rate limitor on building large unconfirmed chains. :)
629 2016-12-02T17:36:39  <sdaftuar> gmaxwell: instagibbs: i have two approaches to suggest, not sure which is better:
630 2016-12-02T17:37:53  <sdaftuar> 1) do basically what you do here, except using CMPA correctly (i'd need to figure out exactly how to do that, certainly you could pass in a tx that spends pcoins, or maybe there's a way to call CMPA with adjusted limit values that works, not sure)
631 2016-12-02T17:38:23  <sdaftuar> 2) don't bother calling CMPA in AvailableCoins, and instead just check to see if pcoins has more than N ancestors (a cached value) for some N much less than the default ancestor limit (maybe 5 or 10).
632 2016-12-02T17:38:45  <sdaftuar> and then find a later point in the wallet code to abort the send if the descendant count would be violated
633 2016-12-02T17:39:34  <instagibbs> I like (2) for now, just because I can't tell how CMPA is working sometimes :)
634 2016-12-02T17:39:38  <gmaxwell> for the case that people hit, really it's just the ancestor limit that actually matters: people chaining change.
635 2016-12-02T17:39:43  <instagibbs> yep
636 2016-12-02T17:39:53  <sdaftuar> yeah the problem with 1) is that you don't know the size of the tx you're generating, so it's always going to be possible for the tx to ultimately fail
637 2016-12-02T17:40:12  <sdaftuar> 2) is easy, but may result in some rare annoyances
638 2016-12-02T17:40:44  <gmaxwell> sdaftuar: this is a sign we should reconsider that relay policy... the size is cornercase enough that it shouldn't really matter.
639 2016-12-02T17:41:49  <sdaftuar> gmaxwell: we knew the descendant count/size was a theoretical problem from the start (someone else spending outputs of a tx that pays to you can prevent you from relaying new transactions until those other ones clear), but i believe it's the
640 2016-12-02T17:42:00  <sdaftuar> descendant count/size stuff that limits DoS attacks on the mempool the most
641 2016-12-02T17:42:08  <instagibbs> Ok, I'm going to learn more about CMPA, then likely do (2) instead
642 2016-12-02T17:42:38  <sdaftuar> "those other ones clear" <--- should be until the parent confirms
643 2016-12-02T17:44:52  <gmaxwell> sdaftuar: why do you suggest above going 'much less' than the ancestor limit?
644 2016-12-02T17:45:58  <sdaftuar> gmaxwell: i just think that we should steer well clear of the relay policy limits.  partly just philosophy (we didn't think there were any common use cases close the values we chose)
645 2016-12-02T17:46:02  *** bitcoin837 has joined #bitcoin-core-dev
646 2016-12-02T17:46:17  <sdaftuar> but also practically, being near the ancestor limit makes it more likely some peer will think you're violating, say, the descendant limit
647 2016-12-02T17:46:44  <bitcoin837> hey guys, before I write my own, does anyone already have a bash script that interacts with bitcoin-cli to do a sendmany split of a large chunk to your own deposit addresses?
648 2016-12-02T17:46:46  <gmaxwell> makes sense. well doing 5 less would probably provide plenty of safty there.
649 2016-12-02T17:46:46  <sdaftuar> (breaking relay)
650 2016-12-02T17:48:15  <instagibbs> bitcoin837, #bitcoin
651 2016-12-02T17:48:27  <bitcoin837> sure
652 2016-12-02T17:48:31  <instagibbs> np
653 2016-12-02T17:53:42  *** laurentmt has joined #bitcoin-core-dev
654 2016-12-02T18:07:41  <sdaftuar> instagibbs: gmaxwell: there's a problem with this approach
655 2016-12-02T18:08:07  <sdaftuar> just talked to morcos, and one thing we realized is that you might be combining lots of inputs, each with many ancestors
656 2016-12-02T18:08:18  <sdaftuar> so the resulting transaction would fail
657 2016-12-02T18:08:18  * BlueMatt sooo doesnt want to have to rebase #9260...anyone wanna review?
658 2016-12-02T18:08:20  <gribble> https://github.com/bitcoin/bitcoin/issues/9260 | Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) by TheBlueMatt · Pull Request #9260 · bitcoin/bitcoin · GitHub
659 2016-12-02T18:09:02  <sdaftuar> so the best thing we could do in AvailableCoins is eliminate any coins that are already at the ancestor limit, i guess.  but we need additional logic in SelectCoins..() i think
660 2016-12-02T18:09:21  *** bitcoin837 has quit IRC
661 2016-12-02T18:11:34  <instagibbs> wait, why is this different than what we were going to do?
662 2016-12-02T18:11:43  <instagibbs> i thought that was the definition of ancestor number
663 2016-12-02T18:11:54  <instagibbs> oh i see, right
664 2016-12-02T18:12:21  <instagibbs> I had this thought a couple minutes ago and somehow lost it. Yes, 2 inputs may have n-1 history, making 2n-2
665 2016-12-02T18:12:39  <sdaftuar> yep.  or making n-1, if they're different outputs of the same tx
666 2016-12-02T18:12:47  <sdaftuar> we have to check later on
667 2016-12-02T18:12:59  <instagibbs> Yep. glad someone else thought of it and actually communicated
668 2016-12-02T18:13:15  <gmaxwell> In the case people have actually encountered, it's just a decendant chain limit AFAIK.   Many of the other cases would be pretty hard to hit with the wallet behavior.
669 2016-12-02T18:14:02  <instagibbs> does the wallet prefer shorter unconfirmed chains vs longer?
670 2016-12-02T18:14:09  <instagibbs> I know it prefers confirmed change first, etc
671 2016-12-02T18:14:14  <gmaxwell> It is completely blind to it right now.
672 2016-12-02T18:14:24  <instagibbs> ok, so it might not be all that rare
673 2016-12-02T18:14:42  <gmaxwell> To make it prefer shorter is easy: first make it so it can reject if it's too long, and try again with a higher limit if that fails.
674 2016-12-02T18:15:21  <sdaftuar> i think one way we could do that is to make SelectCoinsMinConf do the checking against some passed in limit, and then call it twice or something
675 2016-12-02T18:15:28  <sdaftuar> we already call SelectCoinsMinConf repeatedly
676 2016-12-02T18:15:33  <gmaxwell> thats how we handled unconfirmed, yep.
677 2016-12-02T18:15:40  <instagibbs> yeah its the same idea
678 2016-12-02T18:16:10  <instagibbs> prefer deep confirmed coins from others, prefer confirmed coins, ok now try unconfirmed <-- I think today
679 2016-12-02T18:16:50  <sdaftuar> the other approach would be if there's a way to do it directly in ApproximateBestSubset?
680 2016-12-02T18:16:50  <gmaxwell> it does 6,1,0  and it could become 6,1,0+1i,0+10i,0+20i.
681 2016-12-02T18:16:53  <sdaftuar> not sure if that's a good idea
682 2016-12-02T18:17:26  <instagibbs> ABS assumes you have enough coins i believe
683 2016-12-02T18:17:37  <instagibbs> which means if you run into too long chain, that will be different and fail
684 2016-12-02T18:18:10  <gmaxwell> not a great idea to do it in ABS. Just making it a parameter to SelectCoinsMinConf would be straightforward.
685 2016-12-02T18:19:03  <instagibbs> gmaxwell, why are we using complex numbers for the arg :P
686 2016-12-02T18:19:48  <sdaftuar> ok, so if we do it in SCMC, then i think the approach would be to filter out of availableCoins the ones with >N ancestors, and testing whether the resulting set of inputs would pass CMPA before returning?
687 2016-12-02T18:19:52  <sdaftuar> does that sound right?
688 2016-12-02T18:22:56  <sdaftuar> hmm.  this doens't quite make sense -- once ABS returns coins with enough value, but that violate the chain limits, trying again isn't likely to help, is it?
689 2016-12-02T18:23:15  <instagibbs> SCMF can say "no"
690 2016-12-02T18:23:30  <instagibbs> pass failure to SC, returning Insufficent Funds
691 2016-12-02T18:23:30  <sdaftuar> right, but what is going to do differnetly when invoked with different limits?
692 2016-12-02T18:24:37  <gmaxwell> sdaftuar: you start with the most restrictive limits first.
693 2016-12-02T18:24:48  <gmaxwell> and it will only consider coins which will not violate.
694 2016-12-02T18:25:29  <instagibbs> if it fails to get enough coins under each limit, raise it, if it can never get enough, fails
695 2016-12-02T18:27:03  <gmaxwell> and if that can't find a solution, you relax the limits and try again.  The first limit is very confirmed, then confirmed, then unconfirmed but 1 deep, then unconfirmed and deeper...  The reason to try with multiple limits is so that it doesn't do something dumb like build a chain of 19 deep, then at the 20's also spend all your other unconfirmed coins... so that the next call has nothing to spe
696 2016-12-02T18:27:09  <gmaxwell> nd.
697 2016-12-02T18:29:01  <sdaftuar> gmaxwell: i'm trying to understand how ABS works now, but it's not obvious to me how effective it would be at randomly finding a set of inputs that don't violate the chain limits as the set of available coins it's given increases
698 2016-12-02T18:29:22  <instagibbs> ABS wouldnt be in charge of it, would have to be higher
699 2016-12-02T18:29:39  <instagibbs> ABS I believe just has a set of inputs, and tries to make "good" fits based on value
700 2016-12-02T18:30:04  <sdaftuar> instagibbs: right.  so let's say you have a set of inputs with at most 1 ancestors that has enough value to createa a tx, but the resulting tx has too many ancestors
701 2016-12-02T18:30:29  <sdaftuar> what are the chances that when you add some more inputs (where it is possible to find a suitable input set that passes the chain limits), that ABS will return it to you?
702 2016-12-02T18:30:44  <instagibbs> hm the issue seems to continue all the way until you create the actual transaction
703 2016-12-02T18:30:50  <gmaxwell> yes, there is nothing really we can do about the ancestor limit right now-- it even depends on future and non-local information, we can deal with the decendant limit now.
704 2016-12-02T18:31:25  <sdaftuar> gmaxwell: did you swap ancestor and descendant in that last line?
705 2016-12-02T18:31:49  <gmaxwell> yes.
706 2016-12-02T18:32:10  <gmaxwell> Oh you're also saying for ancestors. Indeed, we can only be greedy, you're right.
707 2016-12-02T18:32:32  <sdaftuar> if ABS were somehow aware of the constraint, we might get lucky and succeed
708 2016-12-02T18:32:37  <sdaftuar> but if it's not...
709 2016-12-02T18:33:01  <gmaxwell> it's not a framework that would likely do well with that kind of constraint in any case.
710 2016-12-02T18:33:43  <gmaxwell> For some reason I thought the combination rule for ancestor limit was MAX (a depth) not sum.
711 2016-12-02T18:34:02  <instagibbs> Yeah me too :/
712 2016-12-02T18:34:10  <sdaftuar> sum reflects how much recordkeeping (and pointer hopping) we do
713 2016-12-02T18:34:56  <instagibbs> So, we could still have the wallet prefer shorter inputs, and post-transaction finalization, have a CMPA check before returning?
714 2016-12-02T18:35:10  <instagibbs> shorter-chain inputs greedily*
715 2016-12-02T18:35:37  <sdaftuar> yes i still think it'd be useful to do what i wrote above: in SCMC, filter out from AvailableCoins the ones that have more than N ancestors, for different values of N
716 2016-12-02T18:35:52  <gmaxwell> sdaftuar: yes, while realizing that I was wrong from your comment it was clear enough to me why it's sum.
717 2016-12-02T18:36:32  <sdaftuar> but there are then two failures from SCMC: not enough value, in which case it's worth tryign again with a higher limit; or chain limit exceeded, in which case I'm not sure it's worth calling again with a higher limit
718 2016-12-02T18:37:35  <sdaftuar> we might fail sometimes to generate a transaction when there are coins available that would work, but this seems like the best we can do right now
719 2016-12-02T18:37:59  <sdaftuar> and certainly the most important thing is to not commit a transaction that then fails in ATMP
720 2016-12-02T18:38:26  <sdaftuar> "This must not fail." :)
721 2016-12-02T18:40:09  <instagibbs> so we'll still need a CMPA call, or something similar, to get the actual ancestor count before returning right
722 2016-12-02T18:40:21  <instagibbs> otherwise "this can fail" :)
723 2016-12-02T18:40:30  <sdaftuar> yes.  once we've put the transaction together, we can call CMPA and know whether it'll pass.
724 2016-12-02T18:40:51  <sipa> i think we should deal correctly with a failed ATMP call, like removing the tx from the wallet in that case
725 2016-12-02T18:41:17  <sipa> (in addition to doing sanity checks ahead of time)
726 2016-12-02T18:41:42  <sdaftuar> sipa: agreed
727 2016-12-02T18:41:57  <instagibbs> what's the barrier to that fix? I don't know the wallet well enough
728 2016-12-02T18:42:07  <sdaftuar> i don't think we ever delete anything now, do we?
729 2016-12-02T18:42:30  <instagibbs> removeprunedfunds :P
730 2016-12-02T18:42:36  <instagibbs> but no, not normallly
731 2016-12-02T18:43:02  <sdaftuar> oh, neat.  i didn't know that existed!
732 2016-12-02T18:43:38  <instagibbs> it's meant to be for importing/removing proofs of payment without scanning
733 2016-12-02T18:44:45  <morcos> is the reason we commit first in case the node crashes?
734 2016-12-02T18:44:52  <sdaftuar> so we can just zap tx's if we create them but ATMP fails?  that seems easy
735 2016-12-02T18:45:04  <morcos> we could alwasy have ATMP(fJustCheck)
736 2016-12-02T18:45:32  <sdaftuar> morcos: i assumed that's why we commit first
737 2016-12-02T18:45:48  *** laurentmt has quit IRC
738 2016-12-02T18:46:03  <sdaftuar> morcos: ATMP(fJustCheck) doesn't work very well with RBF and mempool eviction
739 2016-12-02T18:46:04  <instagibbs> morcos, hmm I thought there was issues with that, otherwise we'd have an easy way to check in rpc if policy is ok with it?
740 2016-12-02T18:46:16  <instagibbs> ^ ok that
741 2016-12-02T18:46:24  <morcos> ah, yes...
742 2016-12-02T18:46:38  <sdaftuar> maybe RBF isn't a big deal, not sure
743 2016-12-02T18:47:27  <gmaxwell> someone should just remove that comment, it's not true. "Must not fail perminantly" it's fine if it fails until some transactions confirm.
744 2016-12-02T18:47:32  <morcos> ok.. well we just want to be a bit careful.. b/c even things that do get rejected from ATMP, first make it into the memory pool.   so we'll want to make sure no one ever makes it so those coudl get relayed or remembered in some other way, if we're about nuke them from teh wallet
745 2016-12-02T18:47:54  <gmaxwell> right, it's important to never remove something from the wallet that could have relayed.
746 2016-12-02T18:48:16  *** moli has quit IRC
747 2016-12-02T18:48:19  <morcos> or remembered in the future opportunistic eviction rejection map
748 2016-12-02T18:48:31  <sdaftuar> morcos: oh! now i see what you mean.
749 2016-12-02T18:49:42  <gmaxwell> ::sigh::
750 2016-12-02T18:50:07  <gmaxwell> The thing I was hoping this issue would fix is the wallet needlessly maining excessively deep transactions when it could choose inputs and avoid it.
751 2016-12-02T18:51:29  <instagibbs> we can still do that, yes?
752 2016-12-02T18:51:50  <gmaxwell> Removing things from the wallet on ATMP failure might be fine (though if it'll relay after the next block ... it might have been better to just leave it), but it won't avoid needlessly creating unattractive transactions.
753 2016-12-02T18:51:54  <gmaxwell> instagibbs: sure.
754 2016-12-02T18:53:00  <morcos> gmaxwell: yeah i think we get it, we're jsut trying to fix up the edges too
755 2016-12-02T18:53:47  *** MykelSIlver has quit IRC
756 2016-12-02T18:53:49  <morcos> but as i think you mentioned the other day, as it is now it won't get relayed after the next block, b/c you don't rebroadcast whats not in your mempool and you don't try to reaccept whats in your wallet
757 2016-12-02T18:54:33  <instagibbs> is this referring to ATMP failed transactions?
758 2016-12-02T18:54:36  <morcos> but we all agree that first you try with things that in the simple case (single stranded chains) will stay well clear of the limits
759 2016-12-02T18:55:08  <sdaftuar> instagibbs: yeah there's a bug now, where the code that tries to periodically relay unconfirmed wallet transactions skips over things that aren't in the mempool
760 2016-12-02T18:55:17  <sdaftuar> instagibbs: i think it's an easy fix, just try to reaccept to the mempool first
761 2016-12-02T18:56:30  <morcos> sdaftuar: i dont know if i 100% agree thats a bug, but certainly a separate issue
762 2016-12-02T18:56:42  <gmaxwell> We we should fix rebroadcast transactions to try remempolling things. :)
763 2016-12-02T18:57:18  <sdaftuar> morcos: right, i guess reaccepting makes it harder for you to abandon a too-low-fee tx?
764 2016-12-02T18:57:29  <gmaxwell> thats a day one bug, considering reorgs/doublespends.
765 2016-12-02T18:57:29  *** MykelSIlver has joined #bitcoin-core-dev
766 2016-12-02T18:57:42  <morcos> gmaxwell: at the risk of tangents.. the danger with that is that i think we'll go into these endless work loops of trying things that have long since been double spent or whatever
767 2016-12-02T18:58:00  <morcos> sdaftuar: no its easy enough to skip abandoned, we already skip reaccepting those on startup
768 2016-12-02T18:58:19  <morcos> but yes, it makes the auto-defacto-abandoned state disappear, which is not necessarily a good thing
769 2016-12-02T18:58:48  <instagibbs> ok, I need coffee bbl
770 2016-12-02T18:58:54  *** moli has joined #bitcoin-core-dev
771 2016-12-02T18:59:01  <gmaxwell> morcos: well it's once per half an hour or whatever... and work per transaction. We also can tell when transactions are conflicted and could skip those.
772 2016-12-02T19:02:33  <morcos> gmaxwell: i guess we could just ask some users with big wallets to see how long that takes them on startup (maybe we need to put in benching for it), since we already do it then
773 2016-12-02T19:03:45  *** ThomasV has joined #bitcoin-core-dev
774 2016-12-02T19:07:15  *** MykelSIlver has quit IRC
775 2016-12-02T19:07:33  *** MykelSIlver has joined #bitcoin-core-dev
776 2016-12-02T19:08:08  *** Chris_Stewart_5 has quit IRC
777 2016-12-02T19:08:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
778 2016-12-02T19:10:06  <gmaxwell> morcos: the non-mempool part of resend wallet txn wouldn't be needed if we had mempool sync. :P
779 2016-12-02T19:10:39  <morcos> if we get it right, we can just skip blocks and PoW too.  :P :P
780 2016-12-02T19:11:43  *** moli has quit IRC
781 2016-12-02T19:17:56  *** jtimon has joined #bitcoin-core-dev
782 2016-12-02T19:17:58  *** laurentmt has joined #bitcoin-core-dev
783 2016-12-02T19:18:40  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d7ba4a233bd5...9e4bb312e695
784 2016-12-02T19:18:40  <bitcoin-git> bitcoin/master facbfa5 MarcoFalke: [qa] Get rid of duplicate code
785 2016-12-02T19:18:41  <bitcoin-git> bitcoin/master 9e4bb31 MarcoFalke: Merge #9221: [qa] Get rid of duplicate code...
786 2016-12-02T19:18:53  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9221: [qa] Get rid of duplicate code (master...Mf1611-qaMaxUploadDuplCode) https://github.com/bitcoin/bitcoin/pull/9221
787 2016-12-02T19:18:59  *** moli has joined #bitcoin-core-dev
788 2016-12-02T19:19:31  *** LeMiner has quit IRC
789 2016-12-02T19:19:31  *** LeMiner has joined #bitcoin-core-dev
790 2016-12-02T19:22:49  *** laurentmt has quit IRC
791 2016-12-02T19:34:02  *** pindarhk has quit IRC
792 2016-12-02T19:34:02  *** aspect_ has quit IRC
793 2016-12-02T19:34:02  *** btcdrak has quit IRC
794 2016-12-02T19:34:02  *** mappum has quit IRC
795 2016-12-02T19:34:02  *** eragmus has quit IRC
796 2016-12-02T19:34:54  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e4bb312e695...c36229b0b2e9
797 2016-12-02T19:34:54  <bitcoin-git> bitcoin/master 8a70a9d wodry: Improvement of documentation of command line parameter 'whitelist'
798 2016-12-02T19:34:55  <bitcoin-git> bitcoin/master c36229b MarcoFalke: Merge #9251: Improvement of documentation of command line parameter 'whitelist'...
799 2016-12-02T19:35:04  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9251: Improvement of documentation of command line parameter 'whitelist' (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9251
800 2016-12-02T19:54:58  *** mappum has joined #bitcoin-core-dev
801 2016-12-02T19:59:36  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9064: unify capitalization of "bitcoin address" (master...changeCaps) https://github.com/bitcoin/bitcoin/pull/9064
802 2016-12-02T20:08:53  *** pindarhk has joined #bitcoin-core-dev
803 2016-12-02T20:10:58  *** mrkent has joined #bitcoin-core-dev
804 2016-12-02T20:11:40  *** eragmus has joined #bitcoin-core-dev
805 2016-12-02T20:15:09  *** aspect_ has joined #bitcoin-core-dev
806 2016-12-02T20:19:18  *** btcdrak has joined #bitcoin-core-dev
807 2016-12-02T20:22:17  *** moli has quit IRC
808 2016-12-02T20:25:35  *** Guyver2 has quit IRC
809 2016-12-02T20:28:33  <sdaftuar> BlueMatt: i was trying to verify that the second commit in #9260 is move only.  first, do you have any clever ways to suggest that i could use to do that?
810 2016-12-02T20:28:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9260 | Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) by TheBlueMatt · Pull Request #9260 · bitcoin/bitcoin · GitHub
811 2016-12-02T20:28:52  <sdaftuar> second -- i tried to use git blame -C on the net_processing.cpp file, to verify that you didn't introduce any changes
812 2016-12-02T20:29:16  <sdaftuar> that almost works, though for some reason i can't figure out, it assigns blame to you for a handful of lines around the Misbehaving() function
813 2016-12-02T20:29:52  <sdaftuar> i can't see any change in that code, but i'm puzzled as to why git thinks a change was introduced
814 2016-12-02T20:30:14  <sipa> sdaftuar: git diff --patience COMMIT~:oldfile COMMIT:newfile
815 2016-12-02T20:31:25  *** CubicEarth has joined #bitcoin-core-dev
816 2016-12-02T20:31:51  *** moli has joined #bitcoin-core-dev
817 2016-12-02T20:33:53  <sdaftuar> sipa: thanks, i'll try that
818 2016-12-02T20:35:49  *** afk11 has quit IRC
819 2016-12-02T20:37:39  *** moli has quit IRC
820 2016-12-02T20:40:20  <morcos> sdaftuar: its not ENTIRELY move only
821 2016-12-02T20:40:48  <sdaftuar> yeah i know... just trying to figure out what the real diff is
822 2016-12-02T20:41:06  <sipa> the only diff i saw was some header changes, and the snippet i pasted in a comment
823 2016-12-02T20:41:48  *** afk11 has joined #bitcoin-core-dev
824 2016-12-02T20:41:48  *** afk11 has quit IRC
825 2016-12-02T20:41:48  *** afk11 has joined #bitcoin-core-dev
826 2016-12-02T20:43:24  <sdaftuar> sipa: i think there's a one-line change about feeFilterRounder too?
827 2016-12-02T20:44:03  <sipa> sdaftuar: ah, he squashed in some changes
828 2016-12-02T20:44:10  <sipa> i reviewed an earlier version
829 2016-12-02T20:44:12  <sdaftuar> ah ok
830 2016-12-02T20:44:20  <sipa>  84922e4
831 2016-12-02T20:46:43  *** Atomicat has quit IRC
832 2016-12-02T20:48:18  <morcos> btw..  that "almost bug" with saferModifyNewCoins, i forgot i had a node running with my new coinsviewcache patches.  it lost consensus a couple days ago..
833 2016-12-02T20:48:45  <morcos> investigating now, but i bet it hit that bug... whew.   dodged a bullet
834 2016-12-02T20:48:48  <sdaftuar> nice.  lets not PR that one. :)
835 2016-12-02T20:51:26  *** Atomicat has joined #bitcoin-core-dev
836 2016-12-02T20:55:30  *** owowo has quit IRC
837 2016-12-02T20:55:48  *** ThomasV has quit IRC
838 2016-12-02T20:56:12  *** moli has joined #bitcoin-core-dev
839 2016-12-02T21:00:10  *** aalex_ has joined #bitcoin-core-dev
840 2016-12-02T21:03:14  <instagibbs> sdaftuar, ok updated my PR, thanks for the help
841 2016-12-02T21:03:23  *** aalex has quit IRC
842 2016-12-02T21:05:29  <jonasschnelli> Isn't this a bug: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/keypool.py#L40
843 2016-12-02T21:05:36  <sdaftuar> instagibbs: cool, i'll take a look
844 2016-12-02T21:05:41  <jonasschnelli> We fill the keypool with a new target size of 3
845 2016-12-02T21:05:52  <jonasschnelli> then we manage to reserve 4 keys: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/keypool.py#L45
846 2016-12-02T21:08:08  *** k0ng has quit IRC
847 2016-12-02T21:11:20  *** owowo has joined #bitcoin-core-dev
848 2016-12-02T21:13:09  <cfields> jonasschnelli: seems to always reserve target + 1
849 2016-12-02T21:14:01  <cfields> ./bitcoin-cli -testnet keypoolrefill 104
850 2016-12-02T21:14:05  <cfields> 2016-12-02 21:13:24 keypool added key 108, size=105
851 2016-12-02T21:19:19  <sipa> i think that may be the vchDefaultKey...
852 2016-12-02T21:25:04  *** MykelSIlver has quit IRC
853 2016-12-02T21:52:55  *** paveljanik has quit IRC
854 2016-12-02T21:53:24  *** paveljanik has joined #bitcoin-core-dev
855 2016-12-02T21:59:17  *** moli has quit IRC
856 2016-12-02T22:02:30  *** Chris_Stewart_5 has quit IRC
857 2016-12-02T22:02:36  *** moli has joined #bitcoin-core-dev
858 2016-12-02T22:02:58  <MarcoFalke> no, don't think this is vchDefaultKey
859 2016-12-02T22:03:54  <MarcoFalke> the target+1 comes from a time when the function was only used by one caller (Maybe getnewaddress or something, where you first call keypoolrefill and then grab one key)
860 2016-12-02T22:04:21  <MarcoFalke> Now if you call it from another place which does not grab the key, you end up with off-by-one
861 2016-12-02T22:08:31  *** cheese_ has joined #bitcoin-core-dev
862 2016-12-02T22:08:31  *** cheese_ has joined #bitcoin-core-dev
863 2016-12-02T22:12:02  *** RoyceX has quit IRC
864 2016-12-02T22:18:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
865 2016-12-02T22:34:35  <instagibbs> sdaftuar: hmm the in mempool check done in AvailableCoins doesn't cover that case?
866 2016-12-02T22:34:58  <instagibbs> Oh I see confirmation plus not mempool
867 2016-12-02T22:38:19  *** moli has quit IRC
868 2016-12-02T22:38:32  *** aalex__ has joined #bitcoin-core-dev
869 2016-12-02T22:42:13  *** aalex_ has quit IRC
870 2016-12-02T22:48:21  *** MarcoFalke has left #bitcoin-core-dev
871 2016-12-02T22:50:41  *** moli has joined #bitcoin-core-dev
872 2016-12-02T22:55:53  *** owowo has quit IRC
873 2016-12-02T23:00:31  *** owowo has joined #bitcoin-core-dev
874 2016-12-02T23:05:32  *** kadoban has joined #bitcoin-core-dev
875 2016-12-02T23:11:29  *** JackH has quit IRC
876 2016-12-02T23:20:47  <BlueMatt> wumpus: re: compilation memusage, validation.cpp takes ~1.19G, init ~1.1G, net_processing ~0.95G, rpcrawtx ~0.95G, rpcdump ~0.99G, rpcwallet ~1.0G, wallet ~1.2G, walletdb ~0.82G...main took ~1.46G
877 2016-12-02T23:21:17  <BlueMatt> so while splitting main didnt cut out worst-case memusage by a /ton/, it did potentially make it possible to compile with 1.5G again, whereas it previously wasnt once you include the host
878 2016-12-02T23:21:32  <sipa> but validation + net_processing together now take 2.14G!
879 2016-12-02T23:21:44  <sipa> bad job!
880 2016-12-02T23:21:56  <BlueMatt> lol
881 2016-12-02T23:22:41  <luke-jr> need to do -flto with under 1 GB RAM use ‼‼‼‼! :p
882 2016-12-02T23:22:54  <BlueMatt> luke-jr: I cant get lto to build anymore
883 2016-12-02T23:25:02  *** bsm117532 has quit IRC
884 2016-12-02T23:26:25  <gmaxwell> BlueMatt: build time is greater for me too.
885 2016-12-02T23:26:45  <BlueMatt> greater like slower or faster?
886 2016-12-02T23:26:49  <luke-jr> it would be nice if you could compile "split LTO data" for libraries, so one can just use non-LTO for their system but have the ability to do LTO on demand
887 2016-12-02T23:27:08  <gmaxwell> BlueMatt: slower. takes more time.
888 2016-12-02T23:27:30  <BlueMatt> gmaxwell: yea, not surprising given how much shit we have in headers (and how much boost has in headers!)
889 2016-12-02T23:27:34  <gmaxwell> bad except when napping is required. presumably its faster on things other than my laptop.
890 2016-12-02T23:27:40  <gmaxwell> yea, need to get rid of boost.
891 2016-12-02T23:27:47  <sipa> gmaxwell: are you using parallel lto linking?
892 2016-12-02T23:28:04  <gmaxwell> sipa: no just the seperate files require more time in total.
893 2016-12-02T23:28:14  <gmaxwell> due to all the garbage in headers.
894 2016-12-02T23:28:17  <BlueMatt> gmaxwell: well even if it is slower, at least you dont have to wait for net_processing if you only want to touch validation or vica versa :p
895 2016-12-02T23:28:32  <gmaxwell> I'm not complaining, its the right thing to do.
896 2016-12-02T23:29:04  <gmaxwell> though the recompile benefit is mixed, it isn't all that often that I don't end up editing a header that causes everything to get recompiled. P
897 2016-12-02T23:29:09  <gmaxwell> :P
898 2016-12-02T23:29:16  <BlueMatt> i know, but I am complaining about headers in bitcoin core (and boost)
899 2016-12-02T23:29:20  <sipa> gmaxwell: which gcc version? earlier gccs compiled both to object code and gimple in lto mode; in later ones the default is generating only gimple, which is faster
900 2016-12-02T23:29:39  <BlueMatt> sipa: I dont think we're talking about lto
901 2016-12-02T23:30:03  <sipa> ah.
902 2016-12-02T23:36:23  *** bsm117532 has joined #bitcoin-core-dev
903 2016-12-02T23:37:08  <BlueMatt> sdaftuar: ok with not fixing your comments in #9260?
904 2016-12-02T23:37:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9260 | Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) by TheBlueMatt · Pull Request #9260 · bitcoin/bitcoin · GitHub
905 2016-12-02T23:37:12  <gmaxwell> I'm not talking about LTO.
906 2016-12-02T23:39:09  *** bsm117532 has quit IRC
907 2016-12-02T23:41:38  <BlueMatt> paveljanik: you got a minute to ack 9260, since you already looked over it?
908 2016-12-02T23:41:51  * BlueMatt is still hoping it can be merged prior to any other main.cpp changes :p
909 2016-12-02T23:50:27  *** justanotheruser has quit IRC
910 2016-12-02T23:50:34  *** justan0theruser has joined #bitcoin-core-dev
911 2016-12-02T23:58:01  *** abpa has quit IRC