1 2015-12-01T00:03:40  <phantomcircuit> Luke-Jr, ha
  2 2015-12-01T00:17:25  *** zookolaptop has joined #bitcoin-core-dev
  3 2015-12-01T00:27:47  *** cocoBTC has quit IRC
  4 2015-12-01T00:49:06  *** dcousens has joined #bitcoin-core-dev
  5 2015-12-01T01:24:34  *** Ylbam has quit IRC
  6 2015-12-01T01:26:40  <morcos> jtimon: surely you don't need to make estimateSmartFee take a mempoolsize argument?  as in that branch
  7 2015-12-01T01:52:25  <jtimon> morcos: getMinFee doesn't need to be called inside policy/fee yet, but nGlobalMempoolSizeLimit can be already in policy/fee instead of main if you want (I mean, no complain on my part)
  8 2015-12-01T01:52:50  <morcos> one sec and i'll show you what i had in mind
  9 2015-12-01T01:53:35  <jtimon> yep, I will update the PR with the minimal thing and a bunch of stuff for you to discard soon as well
 10 2015-12-01T01:53:53  <jtimon> just got distracted with something else
 11 2015-12-01T01:55:41  <jtimon> morcos: updated #7115 focus on the first commit and then nack the other two if you want
 12 2015-12-01T01:55:49  <morcos> https://github.com/bitcoin/bitcoin/compare/master...morcos:trackTrimSize
 13 2015-12-01T01:56:13  <morcos> and then if you want i'd be happy for you to add a commit that has a global mempool limit variable which TrimToSize calls
 14 2015-12-01T01:56:39  <morcos> and per our recent agreement i'll stop objecting if you move GetMinFee call to inside CTxMemPool, although I will silently still disagree
 15 2015-12-01T01:57:12  <jtimon> ok, so you agree with hiding the param in getminfee, I thought that was what you disliked more for some reason and removed it
 16 2015-12-01T01:58:06  <jtimon> morcos: do you have plans for dynamic trimming beyond testing?
 17 2015-12-01T01:58:53  <jtimon> I really don't understand that or what it even has to do with our discussion
 18 2015-12-01T01:58:58  <morcos> jtimon: no i don't, we talked about using a different trim limit during IBD, but to me its really about encapsulating properly what GetMinFee cares about
 19 2015-12-01T01:59:12  <jtimon> IBD?
 20 2015-12-01T01:59:19  <morcos> i looked at your pull, i don't like adding a global argument to estimateSmartFee
 21 2015-12-01T01:59:38  <morcos> yes, during IBD you could allocate less size to the mempool and more to your cache
 22 2015-12-01T01:59:55  <morcos> or during initial sync if you're not caught up or whatever
 23 2015-12-01T02:00:00  <morcos> doesn't have to technically be IBD
 24 2015-12-01T02:00:19  <jtimon> in the future that can be fixed if getminfee moves to the estimator
 25 2015-12-01T02:00:40  <jtimon> it could be an attribute in the estimator
 26 2015-12-01T02:00:54  <morcos> what is it you don't like about the commit i just showed you.  i realize it still doesn't solve your problem, but i'm ok with you solving your problem on top of that.
 27 2015-12-01T02:01:01  <jtimon> what is IDB?
 28 2015-12-01T02:01:06  <morcos> initial block download
 29 2015-12-01T02:01:15  <jtimon> thanks
 30 2015-12-01T02:01:44  <jtimon> so, wait
 31 2015-12-01T02:02:15  <jtimon> you want to have a different limit for IBD but a constant one for the rest right?
 32 2015-12-01T02:02:25  <morcos> i don't want to do any of that right now
 33 2015-12-01T02:02:36  <morcos> i would like to fix it so GetMinFee doesn' tneed an argument
 34 2015-12-01T02:02:48  <morcos> but i don't think the proper value for it to use is your command line argument
 35 2015-12-01T02:02:58  <morcos> i think the proper value for it to use is the last size the mempool was trimmed to
 36 2015-12-01T02:02:59  <jtimon> I want to understand your long term vision, and I would like you to understand mine
 37 2015-12-01T02:04:13  <morcos> so yes, if GetMinFee moves to the estimator, then that attribute could also move to the estimator (or i mean policy code), perhaps a bit tricky since trim to size needs to set it, but perhaps trim to size should be a policy function anyway
 38 2015-12-01T02:05:05  <jtimon> morcos: ok GetMinFee doesn't need an argument, a global (a different one from argsMap I mean) can fix that problem, where do you want the global?
 39 2015-12-01T02:05:21  <morcos> jtimon: a global what?
 40 2015-12-01T02:05:26  <morcos> this is where we are miscommunicating
 41 2015-12-01T02:05:33  <jtimon> main, mempool or policy/fees?
 42 2015-12-01T02:05:59  <morcos> the value GetMinFee needs to know about isn't the command line argument, it is literally the last agrument that was given to TrimToSize
 43 2015-12-01T02:06:01  <jtimon> argsMap is the global we're currently using for this command line param
 44 2015-12-01T02:06:39  <jtimon> we should use an extern global initialized in init.cpp like everybody else
 45 2015-12-01T02:06:51  <morcos> but i think you're missing my point
 46 2015-12-01T02:07:01  <morcos> if TrimToSize still takes an argument, which I think it should
 47 2015-12-01T02:07:31  <morcos> then GetMinFee has to be aware of that argument, not the global just because we happen to call TrimToSize with the global
 48 2015-12-01T02:07:49  <jtimon> should TrimToSize use a different value 2 different times for a given comman-line call?
 49 2015-12-01T02:09:28  <morcos> lets step back for a second, what is your objection to doing it the way i'm proposing?
 50 2015-12-01T02:09:34  <jtimon> why does TrimToSize needs to be "reset" every time, why everyone else must depend on "whatever TrimToSize was called with last time" instead of just -maxmempool?
 51 2015-12-01T02:10:04  <morcos> because thats literally what the logic is, what was the mempool trimmed to
 52 2015-12-01T02:10:17  <morcos> and now how far below that number are we
 53 2015-12-01T02:10:32  <jtimon> morcos: it doesn't make any sense to me, I think you should start with why is this command line option different from all the rest
 54 2015-12-01T02:11:32  <morcos> i don't really think i have anything else to say thats not repeating myself
 55 2015-12-01T02:12:14  <jtimon> morcos: I just made the logic to be "never change once the user sets it, TrimToSize will eat whatever was set in init.cpp like anybody else" in 3 different ways
 56 2015-12-01T02:13:09  <jtimon> that can be changed as shown, why do you want ot maintain it as a parameter in TrimToSize but not int getminfee? what's the fundamental difference you see but I don't?
 57 2015-12-01T02:13:35  <morcos> well i think one evidence of what i'm saying is the fact that you had to create two TrimToSize functions
 58 2015-12-01T02:13:58  <jtimon> I could make them one if you prefer that
 59 2015-12-01T02:14:08  <jtimon> trvially I must add
 60 2015-12-01T02:14:29  <morcos> i think it would be hard to get the unit tests to work with no argument
 61 2015-12-01T02:14:37  <jtimon> the same goes for getminfee, again, what's the difference?
 62 2015-12-01T02:14:55  <morcos> I think TrimToSize should take an argument because its logic that should exist outside the mempool as to what size it should be trimmed to
 63 2015-12-01T02:15:10  <jtimon> morcos we're using other globals in the tests
 64 2015-12-01T02:15:25  <jtimon> for example argsMap
 65 2015-12-01T02:15:34  <morcos> I think GetMinFee should not take an argument, because it is constrained to have to use the value that TrimToSize was called with
 66 2015-12-01T02:15:35  <jtimon> like we're currently using
 67 2015-12-01T02:15:55  <morcos> the unit tests call TrimToSize with different arguments within the same tests  or GetMinFee or whatever
 68 2015-12-01T02:15:59  <morcos> both probably
 69 2015-12-01T02:16:01  <jtimon> calling GetArg in 11 places instead of one is just a style choice
 70 2015-12-01T02:16:22  <jtimon> would you even oppose to a macro?
 71 2015-12-01T02:16:44  <morcos> ok, well at this point we're cluttering up IRC with a ridiculous conversation.  you are the one who is trying to get something merged.
 72 2015-12-01T02:16:59  <morcos> i've tried to give you some reasonable compromises that i would support
 73 2015-12-01T02:17:31  <jtimon> "I think GetMinFee should not take an argument, because it is constrained to have to use the value that TrimToSize was called with" this doesn't make any sense, if you call TrimToSize with a value, you want GetMinFee to use that value
 74 2015-12-01T02:17:42  <morcos> if it gets merged without my support, that's also fine... but its just a bit annoying since i'm the one spending the most time coding in this area
 75 2015-12-01T02:17:45  <phantomcircuit> jtimon, theoretically we could fix GetArg but we cant if noboey uses it
 76 2015-12-01T02:18:34  <morcos> jtimon: huh?  yes, this is correct: "if you call TrimToSize with a value, you want GetMinFee to use that value"
 77 2015-12-01T02:18:36  <jtimon> morcos: whatever, I can leave it at the minimal fix-circular-dependency commit and focus on what we agree instead of what we disagree
 78 2015-12-01T02:18:48  <morcos> i have not seen any commits that i can agree with
 79 2015-12-01T02:19:05  <jtimon> phantomcircuit: ?? init.cpp uses it plenty
 80 2015-12-01T02:19:47  <phantomcircuit> jtimon, GetArg isn't thread safe, so we cant change settings outside of init.cpp
 81 2015-12-01T02:20:06  <phantomcircuit> if we aren't using GetArg it becomes a hastle to find and change settings all over the place
 82 2015-12-01T02:20:39  <jtimon> morcos: if you can't agree with https://github.com/jtimon/bitcoin/commit/3c30cea7245a2fd44bbd9cf8844c6730855f63e4 you will have to explain why we need to introduce an unecessary dependency "right now"
 83 2015-12-01T02:21:44  <jtimon> sorry https://github.com/jtimon/bitcoin/commit/3c30cea7245a2fd44bbd9cf8844c6730855f63e4
 84 2015-12-01T02:22:39  <morcos> jtimon: the part i don't like about that is passing through nMempoolSizeLimit through estimateSmartFee.  that just doesnt make sense to me.  callers want to just say estimateSmartFee, why do they need to be aware of certain global variables.  Furthermore it limits the ability to call TrimToSize with different values for no good reason.  but talk about circular dependencies, you and i have a good one going now... so let
 85 2015-12-01T02:22:55  *** calibre720 has joined #bitcoin-core-dev
 86 2015-12-01T02:22:58  <morcos> so lets just let it go.
 87 2015-12-01T02:23:23  <jtimon> "the part i don't like about that is passing through nMempoolSizeLimit through estimateSmartFee.  that just doesnt make sense to me" do you have another simple alternative beyond creating an unnecessary circular dependency?
 88 2015-12-01T02:23:54  <morcos> i pasted it to you above!!!
 89 2015-12-01T02:24:05  <jtimon> callers should call the estimator directly without calling the mempool as a facade, but that's another topic entirily
 90 2015-12-01T02:24:12  <morcos> https://github.com/bitcoin/bitcoin/compare/master...morcos:trackTrimSize
 91 2015-12-01T02:24:46  <morcos> then you can fix the circular dependency on top of that.
 92 2015-12-01T02:25:52  <jtimon> "Furthermore it limits the ability to call TrimToSize with different values for no good reason" do you expect to need to call TrimToSize with values different from -maxmempool beyond testing?
 93 2015-12-01T02:27:04  <morcos> jtimon: sorry, i have to stop discussing this.  no i don't expect to right now except for the edge case of doing so in IBD as mentioned above.
 94 2015-12-01T02:28:00  <jtimon> btw, I asked many times without anwer, do you agree that getminfee belongs in policy/fees ?
 95 2015-12-01T02:28:24  <jtimon> morcos: ok, whenever you have time to answer questions come back to me
 96 2015-12-01T02:29:44  *** zookolaptop has quit IRC
 97 2015-12-01T02:35:03  <GitHub150> [bitcoin] jtimon closed pull request #7115: Mempool: Decouple CBlockPolicyEstimator from CTxMemPool (fix #6134) (master...6134-nits) https://github.com/bitcoin/bitcoin/pull/7115
 98 2015-12-01T02:35:59  *** calibre720 has quit IRC
 99 2015-12-01T03:00:53  *** pmienk_ has quit IRC
100 2015-12-01T03:23:14  *** afk11 has joined #bitcoin-core-dev
101 2015-12-01T03:50:57  *** jgarzik_ has quit IRC
102 2015-12-01T03:57:49  *** guest234234 has joined #bitcoin-core-dev
103 2015-12-01T04:12:00  *** afk11 has quit IRC
104 2015-12-01T04:16:46  *** dcousens has quit IRC
105 2015-12-01T04:29:02  *** Dyanisus has quit IRC
106 2015-12-01T04:34:28  *** mempool has joined #bitcoin-core-dev
107 2015-12-01T04:42:38  *** jgarzik has joined #bitcoin-core-dev
108 2015-12-01T04:42:38  *** jgarzik has joined #bitcoin-core-dev
109 2015-12-01T05:25:41  *** mempool has quit IRC
110 2015-12-01T06:04:50  *** Madars has quit IRC
111 2015-12-01T06:05:40  *** Madars has joined #bitcoin-core-dev
112 2015-12-01T06:30:50  *** CodeShark_ has joined #bitcoin-core-dev
113 2015-12-01T06:36:58  *** randy-waterhouse has quit IRC
114 2015-12-01T06:42:23  *** tulip has quit IRC
115 2015-12-01T06:59:09  <GitHub18> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/438ee59839ad...c143c499c85b
116 2015-12-01T06:59:10  <GitHub18> bitcoin/master 996d311 Nick: [RPC] Add transaction size to JSON output...
117 2015-12-01T06:59:10  <GitHub18> bitcoin/master c143c49 Gregory Maxwell: Merge pull request #7072...
118 2015-12-01T06:59:18  <GitHub134> [bitcoin] gmaxwell closed pull request #7072: [RPC] Add transaction size to JSON output (master...master) https://github.com/bitcoin/bitcoin/pull/7072
119 2015-12-01T07:04:16  *** randy-waterhouse has joined #bitcoin-core-dev
120 2015-12-01T07:34:11  *** paveljanik has joined #bitcoin-core-dev
121 2015-12-01T07:34:11  *** paveljanik has joined #bitcoin-core-dev
122 2015-12-01T07:53:20  *** PaulCapestany has quit IRC
123 2015-12-01T07:54:54  *** PaulCapestany has joined #bitcoin-core-dev
124 2015-12-01T07:58:45  *** Ylbam has joined #bitcoin-core-dev
125 2015-12-01T08:00:07  *** pmienk has joined #bitcoin-core-dev
126 2015-12-01T08:03:04  *** Dyanisus has joined #bitcoin-core-dev
127 2015-12-01T08:03:22  <GitHub104> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c143c499c85b...1b5118bfa0d9
128 2015-12-01T08:03:23  <GitHub104> bitcoin/master 5029698 kazcw: prevent peer flooding request queue for an inv...
129 2015-12-01T08:03:23  <GitHub104> bitcoin/master ebb25f4 Gregory Maxwell: Limit setAskFor and retire requested entries only when a getdata returns....
130 2015-12-01T08:03:23  <GitHub104> bitcoin/master 1b5118b Wladimir J. van der Laan: Merge pull request #7079...
131 2015-12-01T08:03:27  <GitHub11> [bitcoin] laanwj closed pull request #7079: Prevent peer flooding inv request queue (redux) (redux) (master...setAskFor) https://github.com/bitcoin/bitcoin/pull/7079
132 2015-12-01T08:22:29  <GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b5118bfa0d9...30c2d8c635c4
133 2015-12-01T08:22:30  <GitHub170> bitcoin/master 9ac63d6 Pieter Wuille: Keep track of explicit wallet conflicts instead of using mempool
134 2015-12-01T08:22:30  <GitHub170> bitcoin/master 30c2d8c Wladimir J. van der Laan: Merge pull request #7105...
135 2015-12-01T08:22:39  <GitHub98> [bitcoin] laanwj closed pull request #7105: Keep track of explicit wallet conflicts instead of using mempool (master...realconflicts) https://github.com/bitcoin/bitcoin/pull/7105
136 2015-12-01T08:38:07  *** ghtdak has quit IRC
137 2015-12-01T08:40:01  *** ghtdak has joined #bitcoin-core-dev
138 2015-12-01T08:40:16  *** BashCo has quit IRC
139 2015-12-01T08:42:55  *** arowser has quit IRC
140 2015-12-01T08:43:20  *** arowser has joined #bitcoin-core-dev
141 2015-12-01T08:49:50  <GitHub130> [bitcoin] laanwj opened pull request #7141: rpc: Don't translate warning messages (master...2015_12_warnings_translations) https://github.com/bitcoin/bitcoin/pull/7141
142 2015-12-01T08:50:10  <GitHub34> [bitcoin] laanwj closed pull request #7134: [Qt] Don't translate warning messages (master...2015/11/qt_getwarnings) https://github.com/bitcoin/bitcoin/pull/7134
143 2015-12-01T08:56:29  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30c2d8c635c4...eb3d1b348773
144 2015-12-01T08:56:29  <GitHub101> bitcoin/master fa3a38a MarcoFalke: [qa] pull-tester: Cleanup (run keypool, tidy stdout)...
145 2015-12-01T08:56:29  <GitHub101> bitcoin/master eb3d1b3 Wladimir J. van der Laan: Merge pull request #7135...
146 2015-12-01T08:56:39  <GitHub146> [bitcoin] laanwj closed pull request #7135: [trivial] pull-tester cleanup: Run keypool, Tidy stdout (master...MarcoFalke-2015-pullTester) https://github.com/bitcoin/bitcoin/pull/7135
147 2015-12-01T08:59:20  <GitHub129> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb3d1b348773...9490bd71bdb4
148 2015-12-01T08:59:21  <GitHub129> bitcoin/master ecc7c82 Pieter Wuille: Move fPayAtLeastCustomFee function to CC
149 2015-12-01T08:59:22  <GitHub129> bitcoin/master 80462dd Jonas Schnelli: [Qt] use ASYMP_UTF8 (≈) whenever we show a fee that is not absolute
150 2015-12-01T08:59:22  <GitHub129> bitcoin/master 31b508a Jonas Schnelli: [Qt] make use of the nMinimumTotalFee (absolute) in coincontrols fee calculation
151 2015-12-01T08:59:30  <GitHub99> [bitcoin] laanwj closed pull request #7096: [Wallet] Improve minimum absolute fee GUI options (master...2015/11/feefix) https://github.com/bitcoin/bitcoin/pull/7096
152 2015-12-01T09:01:45  <gmaxwell> wumpus: what do you need me working on for 0.12?
153 2015-12-01T09:05:20  *** BashCo has joined #bitcoin-core-dev
154 2015-12-01T09:16:31  *** paveljanik has quit IRC
155 2015-12-01T09:22:37  <GitHub104> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9490bd71bdb4...327291af02d0
156 2015-12-01T09:22:38  <GitHub104> bitcoin/master 114b581 Pieter Wuille: Prevector type
157 2015-12-01T09:22:38  <GitHub104> bitcoin/master 327291a Wladimir J. van der Laan: Merge pull request #6914...
158 2015-12-01T09:22:45  <GitHub22> [bitcoin] laanwj closed pull request #6914: Add pre-allocated vector type and use it for CScript (master...prevector) https://github.com/bitcoin/bitcoin/pull/6914
159 2015-12-01T09:23:37  <GitHub24> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/327291af02d0...8f761e87c3fd
160 2015-12-01T09:23:38  <GitHub24> bitcoin/master fad3035 MarcoFalke: [doc] Minor markdown fixes
161 2015-12-01T09:23:39  <GitHub24> bitcoin/master fa22a10 MarcoFalke: contrib: Del. gitian downloader config and update gitian README
162 2015-12-01T09:23:39  <GitHub24> bitcoin/master 9999cb0 MarcoFalke: Fix url in .travis.yml
163 2015-12-01T09:23:45  <GitHub11> [bitcoin] laanwj closed pull request #7136: [trivial] Fix markdown, links and help messages (master...MarcoFalke-2015-trivial5) https://github.com/bitcoin/bitcoin/pull/7136
164 2015-12-01T09:24:54  <gmaxwell> I am imagining wumpus all PullBo,  a muscled, tanned warrior, with ammo belts around his shoulders, firing automatic weapons bursts into the forrest of pull requests in front of him.
165 2015-12-01T09:25:19  <wumpus> hehehehe certainly feels that way
166 2015-12-01T09:28:04  <wumpus> gmaxwell: final ack on https://github.com/bitcoin/bitcoin/pull/6915 would be nice
167 2015-12-01T09:28:33  <wumpus> https://github.com/bitcoin/bitcoin/pull/6898 has no ACKs at all, not even untested or concept
168 2015-12-01T09:29:40  <wumpus> https://github.com/bitcoin/bitcoin/pull/6872 needs rebase, and BlueMatt has no time to do it until tomorrow
169 2015-12-01T09:30:19  <wumpus> those are the three left with milestone set to 0.12
170 2015-12-01T09:32:09  <BlueMatt> i mean if it needs to happen now i could
171 2015-12-01T09:32:15  <BlueMatt> was just in the middle of other things
172 2015-12-01T09:33:15  <gmaxwell> BlueMatt: this is wumpus closing the 0.12 window; so, not great to wait.
173 2015-12-01T09:34:24  <BlueMatt> argh
174 2015-12-01T09:34:30  <BlueMatt> ok....will do in the next hour or so
175 2015-12-01T09:36:07  *** tulip has joined #bitcoin-core-dev
176 2015-12-01T09:43:01  <wumpus> if it is technically a bugfix it can go in after the branch split-off, but it saves everyone work to merge it now
177 2015-12-01T09:44:09  <BlueMatt> yea, working on it now
178 2015-12-01T09:44:16  <BlueMatt> fixing whitespace errors and shits
179 2015-12-01T09:44:30  <BlueMatt> (and actually reviewing my code...)
180 2015-12-01T09:48:59  <Luke-Jr> anything for me to rebase?
181 2015-12-01T09:49:48  <wumpus> Luke-Jr: you could help testing https://github.com/bitcoin/bitcoin/pull/6898 :)
182 2015-12-01T09:50:36  <BlueMatt> wumpus: it seems a bit late to be pushing 6898 in?
183 2015-12-01T09:50:46  <BlueMatt> though I would really very much like to see it
184 2015-12-01T09:51:56  <Luke-Jr> wumpus: I'm still mid-code review on that one, and also NACK it without 6357 :/
185 2015-12-01T09:52:56  <wumpus> BlueMatt: that's also my opinion
186 2015-12-01T09:53:58  <wumpus> BlueMatt: one idea was to add it as a 'getblocktemplatebeta' call, so that it is already as beta in 0.12 but if it turns out to have bugs, people can still use the old version
187 2015-12-01T09:54:33  <Luke-Jr> might make more sense as a "beta" boolean parameter to getblocktemplate?
188 2015-12-01T09:54:42  <Luke-Jr> no need to duplicate the RPC side
189 2015-12-01T09:54:58  * wumpus hates adding parameters
190 2015-12-01T09:55:17  <Luke-Jr> wumpus: GBT is explicitly designed to be nice about parameters
191 2015-12-01T09:55:32  <Luke-Jr> there's an Object parameter for every GBT call, that can have any variety of keys
192 2015-12-01T09:55:36  <wumpus> Luke-Jr: true, you're passing it as an object? right
193 2015-12-01T09:56:19  <BlueMatt> wumpus: if we want to do a fix for gbt for 0.12, i think its https://github.com/bitcoin/bitcoin/pull/7104
194 2015-12-01T09:56:55  <BlueMatt> phantomcircuit: ^ ?
195 2015-12-01T09:56:59  <Luke-Jr> oh! I missed that one somehow
196 2015-12-01T09:58:01  <gmaxwell> wumpus: make it a config option not another RPC.  The reason is that it's burdensome to have to change your other software.
197 2015-12-01T09:58:10  <gmaxwell> and I don't see much use to switching them on the fly.
198 2015-12-01T09:58:13  <phantomcircuit> huh what
199 2015-12-01T09:58:20  <phantomcircuit> oh yeah
200 2015-12-01T09:58:24  <wumpus> "Reduce latency of switching to new block. I'm not really sure this is a good idea." hehe, that sounds even more unconvincing than "not tested on mainnet at all"
201 2015-12-01T09:58:31  <Luke-Jr> gmaxwell: switching on the fly can be automatic degrading
202 2015-12-01T09:58:44  <wumpus> gmaxwell: right...
203 2015-12-01T09:58:44  <phantomcircuit> wumpus, i've actually tested it and it does what it's supposed to do
204 2015-12-01T09:58:56  <BlueMatt> wumpus: well i dunno if it'll break existing pool software, maybe it should be optional
205 2015-12-01T09:58:57  <Luke-Jr> phantomcircuit: does it, with multiple poolservers connected?
206 2015-12-01T09:59:08  <gmaxwell> Luke-Jr: yea it could but I think it's not worth the other costs.
207 2015-12-01T09:59:15  <Luke-Jr> phantomcircuit: seems like it might be better to just do the empty block on longpoll connections
208 2015-12-01T09:59:33  <phantomcircuit> Luke-Jr, gbt takes 500-3000ms
209 2015-12-01T09:59:41  <Luke-Jr> gmaxwell: a GBT parameter with a config default would be pretty trivial
210 2015-12-01T09:59:44  <phantomcircuit> returning an empty block reduces that significantly
211 2015-12-01T09:59:45  <wumpus> gmaxwell: yes an option makes more sense, only for e.g. comparison testing you'd want to be able to call both, and in that case you could run two bitcoinds
212 2015-12-01T09:59:47  <BlueMatt> wumpus: but its definitely the smallest thing we can do that'll fix a bunch of the latency issues for gbt
213 2015-12-01T09:59:48  <gmaxwell> wumpus: heh. I laughed at that too, but we shouldn't punish patches for being super frank. :)
214 2015-12-01T09:59:58  <Luke-Jr> phantomcircuit: obviously; I don't see how that's related to my suggestion :p
215 2015-12-01T10:00:21  <phantomcircuit> Luke-Jr, oh with multiple pool servers no it doesn't
216 2015-12-01T10:00:23  <gmaxwell> Luke-Jr: would still require updating software. Come one, for BIP66 I recall having to pull teeth to get a new libblkmaker from you. :)
217 2015-12-01T10:00:36  <BlueMatt> just a gbt option that says "I want no txn, DO AS I SAY" would probably be sufficient if we got pool software updated
218 2015-12-01T10:00:39  <phantomcircuit> Luke-Jr, i couldn't figure out any way to support that without adding a full round trip though
219 2015-12-01T10:01:03  <phantomcircuit> BlueMatt, no it's not because that would only work if you already knew there was a new block
220 2015-12-01T10:01:05  <Luke-Jr> gmaxwell: it's strictly better to have param-with-config-default rather than config-only :p
221 2015-12-01T10:01:07  <phantomcircuit> and most often you dont
222 2015-12-01T10:01:19  <BlueMatt> phantomcircuit: huh? dont most pools know this because p2p told them?
223 2015-12-01T10:01:25  <Luke-Jr> BlueMatt: that does sound ideal actually.
224 2015-12-01T10:01:29  <BlueMatt> did we merge the pull-up?
225 2015-12-01T10:01:43  <BlueMatt> no, we'd need https://github.com/bitcoin/bitcoin/pull/7037 too
226 2015-12-01T10:01:44  <Luke-Jr> phantomcircuit: GBT is longpolled..
227 2015-12-01T10:01:53  <phantomcircuit> BlueMatt, i dont think we should make that the default setup...
228 2015-12-01T10:01:59  <BlueMatt> so https://github.com/bitcoin/bitcoin/pull/7037 plus a "I want no txn" option would be my vote
229 2015-12-01T10:02:12  <BlueMatt> its a small patch and fixes the issues (mostly)
230 2015-12-01T10:02:16  <Luke-Jr> "I want no txn" option can be set on longpoll requests too
231 2015-12-01T10:02:16  <phantomcircuit> Luke-Jr, so what?
232 2015-12-01T10:02:41  <Luke-Jr> phantomcircuit: so whether you use blocknotify or longpolling for new block notification, you can use "I want no txn"
233 2015-12-01T10:02:44  <phantomcircuit> Luke-Jr, i guess if it was "i want to wait for a new block and then i want it to be zero"
234 2015-12-01T10:02:56  <Luke-Jr> that's what longpolling is.
235 2015-12-01T10:03:14  <phantomcircuit> Luke-Jr, tbh my suggested setup at the moment is "run gbt calls in an infinite loop, you've got cpu cycles to spare right??"
236 2015-12-01T10:03:17  <Luke-Jr> (right now, longpoll will return with changed txn data too, but obviously you'd skip that when this flag is set)
237 2015-12-01T10:03:21  <phantomcircuit> it actually does reduce latency btw
238 2015-12-01T10:03:35  <Luke-Jr> phantomcircuit: that's stupid; you need those CPU cycles for the rest of the mining system
239 2015-12-01T10:03:55  <BlueMatt> Luke-Jr: you dont have a multi-core processor?!
240 2015-12-01T10:04:27  <Luke-Jr> BlueMatt: … yes, and all 16 cores are running poolservers (I think) :P
241 2015-12-01T10:04:36  <BlueMatt> wtf
242 2015-12-01T10:04:39  <BlueMatt> how did you manage to do that?
243 2015-12-01T10:04:48  <gmaxwell> I think an "you can give me no txn" or "I want no txn" option on gbt would be ducky, it's already got lots of flags.
244 2015-12-01T10:04:52  <gmaxwell> BlueMatt: python.
245 2015-12-01T10:04:55  <Luke-Jr> BlueMatt: multiple instances with iptables load balancing
246 2015-12-01T10:05:03  <Luke-Jr> oh, yeah, Python too
247 2015-12-01T10:05:04  <BlueMatt> gmaxwell: fair point
248 2015-12-01T10:05:05  * Luke-Jr stabs Python
249 2015-12-01T10:05:20  <GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/8f761e87c3fd...6abf6eb7bb77
250 2015-12-01T10:05:21  <GitHub69> bitcoin/master 6e8b07f Suhas Daftuar: Add rounding helper function to util.py
251 2015-12-01T10:05:22  <GitHub69> bitcoin/master 2b31ab9 Suhas Daftuar: Add rpc test for prioritisetransaction
252 2015-12-01T10:05:22  <GitHub69> bitcoin/master 6abf6eb Wladimir J. van der Laan: Merge pull request #7063...
253 2015-12-01T10:05:59  <phantomcircuit> Luke-Jr, the only way i can see making it optional is if long poll is also modified to not return when the mempool changes
254 2015-12-01T10:06:09  <phantomcircuit> and then it would only work for people using long poll
255 2015-12-01T10:06:19  <phantomcircuit> which clealry has the potential to foot gun
256 2015-12-01T10:06:34  <phantomcircuit> and also why the hell do you have multiple pool servers talking to a single bitcoind instance?
257 2015-12-01T10:07:24  <Luke-Jr> phantomcircuit: they all talk to multipel bitcoind instances :P
258 2015-12-01T10:08:45  <phantomcircuit> Luke-Jr, so you've got like 8 pool servers which each talk to the same set of 8 bitcoind instances
259 2015-12-01T10:08:57  <phantomcircuit> ?
260 2015-12-01T10:09:17  <Luke-Jr> phantomcircuit: I don't know the exact setup details; I am speaking hypothetically from a vague understanding.
261 2015-12-01T10:09:45  <phantomcircuit> Luke-Jr, yeah ok it doesn't support that, but im not sure i really much care since that sounds like a bad idea
262 2015-12-01T10:10:01  <Luke-Jr> phantomcircuit: …
263 2015-12-01T10:11:00  <BlueMatt> lol, so all previous tests of #6872 are insane
264 2015-12-01T10:11:19  <Luke-Jr> probably should close https://github.com/bitcoin/bitcoin/pull/6451 since it's past Nov 11
265 2015-12-01T10:11:41  <gmaxwell> Luke-Jr: I specifically decided to not do that because the date could be simply adjusted at any time.
266 2015-12-01T10:11:57  <gmaxwell> Though it should probably be rebased and adjusted to feburary.
267 2015-12-01T10:12:39  <Luke-Jr> if he makes it the upcoming subsidy halving point, I'd probably concept-ACK it. <.<
268 2015-12-01T10:12:50  <gmaxwell> Not that we're going to merge it, but for people who are confused and think there is likely to be some grave emergency, it's not unreasonable to be able to _show_ that we have an emergency thing.
269 2015-12-01T10:17:35  <phantomcircuit> Luke-Jr, ok i'll switch it such that only long poll responses will have empty blocks
270 2015-12-01T10:17:41  <phantomcircuit> and all other responses will be normal
271 2015-12-01T10:19:04  <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7128 has a bunch of utACKs, so I just rebased it
272 2015-12-01T10:21:50  <wumpus> Luke-Jr: I had to laugh at "BaseParams(CBaseChainParams::MAIN).RPCPort(), BaseParams(CBaseChainParams::TESTNET).RPCPort())"  - ut yes it makes sense
273 2015-12-01T10:24:33  <wumpus> maybe break off the line for somewhat easier human parsing
274 2015-12-01T10:24:40  <gmaxwell> FWIW, github lies, I think everything needs rebasing now, but github reports that for nothing.
275 2015-12-01T10:25:06  <Luke-Jr> :/
276 2015-12-01T10:26:35  <Luke-Jr> oh. master doesn't build. :|
277 2015-12-01T10:26:54  <gmaxwell> oh maybe my rebasing kung fu is less bad than I thought.
278 2015-12-01T10:27:05  <BlueMatt> LOL
279 2015-12-01T10:28:01  <wumpus> let's first get master into a working/building state again then
280 2015-12-01T10:28:58  <wumpus> hm it builds fine here
281 2015-12-01T10:29:36  <BlueMatt> yea, builds fine here, too
282 2015-12-01T10:29:51  <BlueMatt> tests also pass fine here...running build-in-crazy-confs-with-all-tests script
283 2015-12-01T10:29:52  <BlueMatt> wumpus: https://github.com/bitcoin/bitcoin/pull/6872 <-- review away
284 2015-12-01T10:31:19  <BlueMatt> wumpus: re: networking in gitian builder doc: I'd REALLY, REALLY prefer to remove all mention of how to get networking to work in the vm and just have a description of how to do it with no networking
285 2015-12-01T10:32:07  <wumpus> BlueMatt: I agree but have you seen the section about running with no networking?
286 2015-12-01T10:32:15  <Luke-Jr> http://codepad.org/BQ5Z2TPq
287 2015-12-01T10:32:21  <wumpus> I don't want to force people through that for no good reason!
288 2015-12-01T10:33:29  <Luke-Jr>         Q_EMIT clientmodel->numBlocksChanged(pIndex->nHeight, QDateTime::fromTime_t(pIndex->GetBlockTime()), clientmodel->getVerificationProgress(pIndex));
289 2015-12-01T10:33:34  <BlueMatt> wumpus: well we shouldnt tell people to use apt-cacher and should just have instructions to disable the auto-update
290 2015-12-01T10:33:35  <Luke-Jr> this emits a signal for a different object?
291 2015-12-01T10:33:51  <wumpus> with networking it just works, that's enough to build executables, maybe it's somehow cleaner or what to not require it, but I don't want to get it to work
292 2015-12-01T10:34:22  <wumpus> Luke-Jr: eh huh
293 2015-12-01T10:34:35  <BlueMatt> wumpus: hmm? if you just remove the gitian auto-update-apt step it should just work (tm) ?
294 2015-12-01T10:35:02  <Luke-Jr> apparently Qt5 allows this, but not Qt4
295 2015-12-01T10:35:27  <wumpus> if you remove apt-cacher then it will download and redownload the packages time after time from the miror, not very nice. Remember that it's not just the base system, the descriptors themselves also have package requirements
296 2015-12-01T10:35:33  <wumpus> BlueMatt: it's too late to redesign gitian for 0.12
297 2015-12-01T10:35:56  <BlueMatt> argh, ok
298 2015-12-01T10:35:59  <phantomcircuit> Luke-Jr, would you be opposed to making longpoll return only when there's a new block?
299 2015-12-01T10:36:01  <BlueMatt> we should do this for 0.13, though
300 2015-12-01T10:36:04  <wumpus> Luke-Jr: still very uncivil to raise a signal on another object :)
301 2015-12-01T10:36:23  <Luke-Jr> phantomcircuit: yes, that would result in only ever mining empty blocks :x
302 2015-12-01T10:36:49  <wumpus> BlueMatt:  for the further future I'd prefer deterministic building without any VMs at all, just a 'blessed' deterministic toolchain
303 2015-12-01T10:36:54  <phantomcircuit> Luke-Jr, well no you would be calling gbt in parallel to the long poll but at a much reduced frequency from my current "lol infinite loop" version
304 2015-12-01T10:37:00  <BlueMatt> wumpus: oh, we need #7022, too
305 2015-12-01T10:37:04  <Luke-Jr> wumpus: so how shall we fix this? a dummy "raise the signal please" method? :p
306 2015-12-01T10:37:08  <wumpus> Luke-Jr: I'll take a look at it..
307 2015-12-01T10:37:33  <Luke-Jr> phantomcircuit: there is literally no reason to ever do a non-longpoll GBT
308 2015-12-01T10:37:36  <wumpus> seems this is https://github.com/bitcoin/bitcoin/issues/7138
309 2015-12-01T10:37:45  <Luke-Jr> phantomcircuit: and BFGMiner will in fact not do so, I think
310 2015-12-01T10:37:45  <gmaxwell> builds fine for me on a guiless system.
311 2015-12-01T10:37:49  *** JackH has joined #bitcoin-core-dev
312 2015-12-01T10:37:55  <wumpus> gmaxwell: yes, only qt4 buildsfail
313 2015-12-01T10:37:58  <Luke-Jr> gmaxwell: lol, of course it builds guiless :P
314 2015-12-01T10:38:00  <wumpus> qt5 or guiless works fine
315 2015-12-01T10:38:20  <wumpus> that's why I don't notice it either, I haven't used qt4 for more than a year
316 2015-12-01T10:38:42  * Luke-Jr waits for a usable Qt5 DE :/
317 2015-12-01T10:38:56  <midnightmagic> gonna be waiting a while.
318 2015-12-01T10:39:01  <wumpus> Luke-Jr: qt creator is not qt5?
319 2015-12-01T10:39:18  <phantomcircuit> Luke-Jr, well there is though
320 2015-12-01T10:39:20  <wumpus> oh, what's DE?
321 2015-12-01T10:39:35  <phantomcircuit> Luke-Jr, even with this you need at least two bitcoind instances to get absolute best latency
322 2015-12-01T10:39:38  <Luke-Jr> wumpus: Desktop Environment
323 2015-12-01T10:39:52  <phantomcircuit> one that's long polling and another that's calling gbt in a loop
324 2015-12-01T10:40:03  <phantomcircuit> ie one that returns transaction
325 2015-12-01T10:40:28  <phantomcircuit> otherwise the cs_main lock will add on average 500ms+ of latency to the long poll result
326 2015-12-01T10:40:59  <Luke-Jr> phantomcircuit: when longpollid is a previous block, return an empty one with a longpollid that then gets returned with a full block immediately.
327 2015-12-01T10:41:00  <wumpus> oof he's using Q_EMIT cross-thread
328 2015-12-01T10:41:13  <Luke-Jr> wumpus: that sounds scary. :|
329 2015-12-01T10:41:28  <wumpus> I had no idea that even worked, used QMetaObject::invokeMethod to manually queue messages
330 2015-12-01T10:41:55  <wumpus> which apparently works in qt4, so going to do that here too
331 2015-12-01T10:42:18  <phantomcircuit> Luke-Jr, that's actually the same thing thanks to random distribution of blocks
332 2015-12-01T10:43:04  <phantomcircuit> i guess really it doesn't much matter since you need cs_main for both empty blocks and filling the template
333 2015-12-01T10:43:17  <phantomcircuit> so either way there will be some latency from it
334 2015-12-01T10:44:36  <Luke-Jr> wumpus: in the meantime, I'll work on getting Travis to test Qt4
335 2015-12-01T10:45:02  <wumpus> Luke-Jr: makes sense for as long we still support it
336 2015-12-01T10:47:03  <GitHub93> [bitcoin] luke-jr opened pull request #7142: [WIP] Travis: Test build against system Qt4 (master...travis_qt4) https://github.com/bitcoin/bitcoin/pull/7142
337 2015-12-01T10:47:40  <wumpus> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7143
338 2015-12-01T10:47:48  <GitHub181> [bitcoin] laanwj opened pull request #7143: qt: use QMetaObject::invokeMethod for cross-thread signaling in clientmodel (master...2015_12_qt4_build) https://github.com/bitcoin/bitcoin/pull/7143
339 2015-12-01T10:48:24  <Luke-Jr> hm, I guess I should rebase mine off that XD
340 2015-12-01T10:48:43  <wumpus> please test it too, I haven't yet :)
341 2015-12-01T10:49:12  <Luke-Jr> yes, of course
342 2015-12-01T10:49:27  <Luke-Jr> phantomcircuit: you active mining testnet? ;)
343 2015-12-01T10:49:48  * Luke-Jr wonders what he needs to look for to change in the UI to test this properly
344 2015-12-01T10:50:55  <phantomcircuit> Luke-Jr, i believe that im currently 100% of testnet actually
345 2015-12-01T10:51:32  <Luke-Jr> phantomcircuit: as long as there's new blocks..
346 2015-12-01T10:51:40  <Luke-Jr> wumpus: qt/clientmodel.cpp:257:56: error: macro "Q_ARG" requires 2 arguments, but only 1 given
347 2015-12-01T10:55:19  <wumpus> ninja-edit fail, try again
348 2015-12-01T10:58:59  <wumpus> --with-incompatible-bdb-and-just-shut-up
349 2015-12-01T11:01:09  *** calibre720 has joined #bitcoin-core-dev
350 2015-12-01T11:02:03  <Luke-Jr> apparently the one node my client found is not giving me blocks. anyone have a working testnet node I can peer with?
351 2015-12-01T11:03:51  <Luke-Jr> hmm, 7 peers now and no syncing :/
352 2015-12-01T11:07:53  <phantomcircuit> Luke-Jr, huh my nodes all have 125 connections...
353 2015-12-01T11:08:04  <Luke-Jr> looks like syncing is just broken :|
354 2015-12-01T11:08:12  <phantomcircuit> Luke-Jr, i dont think so
355 2015-12-01T11:08:43  <phantomcircuit> Luke-Jr, pm'd you one
356 2015-12-01T11:09:05  <Luke-Jr> phantomcircuit: it didn't work to add yours. I had to restart my node and add you first :\
357 2015-12-01T11:09:22  *** PaulCape_ has joined #bitcoin-core-dev
358 2015-12-01T11:09:35  <phantomcircuit> Luke-Jr, yeah you have to wait for the other requests to timeout
359 2015-12-01T11:09:41  <phantomcircuit> iirc it's approximately forever
360 2015-12-01T11:09:44  <Luke-Jr> I waited a while
361 2015-12-01T11:09:54  <phantomcircuit> it's like ten minutes or something
362 2015-12-01T11:10:38  <Luke-Jr> ew
363 2015-12-01T11:10:42  *** PaulCapestany has quit IRC
364 2015-12-01T11:10:48  <phantomcircuit> there's someone running bitcoinseeder and sybil attacking testnet
365 2015-12-01T11:10:54  <phantomcircuit> seems to be doing a pretty decent job too
366 2015-12-01T11:11:20  <phantomcircuit> shrug
367 2015-12-01T11:14:35  <Luke-Jr> wumpus: looks good
368 2015-12-01T11:16:33  *** randy-waterhouse has quit IRC
369 2015-12-01T11:24:01  <Luke-Jr> going to bed, I'll finish up in 8 hours, night
370 2015-12-01T11:27:10  <wumpus> night
371 2015-12-01T11:34:26  *** calibre720 has quit IRC
372 2015-12-01T11:35:24  <BlueMatt> wumpus: we need #7022, too
373 2015-12-01T11:35:28  *** jgarzik has quit IRC
374 2015-12-01T11:35:43  <BlueMatt> oh, and #6872 is ready
375 2015-12-01T11:35:56  *** jgarzik has joined #bitcoin-core-dev
376 2015-12-01T11:35:57  *** jgarzik has quit IRC
377 2015-12-01T11:35:57  *** jgarzik has joined #bitcoin-core-dev
378 2015-12-01T11:40:01  <GitHub47> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6abf6eb7bb77...9afbd96919af
379 2015-12-01T11:40:01  <GitHub47> bitcoin/master 50947ef Alex Morcos: Change default block priority size to 0...
380 2015-12-01T11:40:02  <GitHub47> bitcoin/master 9afbd96 Wladimir J. van der Laan: Merge pull request #7022...
381 2015-12-01T11:40:06  <GitHub77> [bitcoin] laanwj closed pull request #7022: Change default block priority size to 0 (master...defaultPrioritySize) https://github.com/bitcoin/bitcoin/pull/7022
382 2015-12-01T11:40:06  *** fkhan has quit IRC
383 2015-12-01T11:47:57  *** jgarzik_ has joined #bitcoin-core-dev
384 2015-12-01T11:48:54  *** jgarzik has quit IRC
385 2015-12-01T11:53:26  *** fkhan has joined #bitcoin-core-dev
386 2015-12-01T12:03:28  *** CodeShark_ has quit IRC
387 2015-12-01T12:04:06  *** CodeShark_ has joined #bitcoin-core-dev
388 2015-12-01T12:07:31  *** MarcoFalke has joined #bitcoin-core-dev
389 2015-12-01T12:09:32  *** fkhan has quit IRC
390 2015-12-01T12:14:31  *** calibre720 has joined #bitcoin-core-dev
391 2015-12-01T12:18:28  <GitHub85> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/9afbd96919af...2ef5ffa59afa
392 2015-12-01T12:18:29  <GitHub85> bitcoin/master 0c9959a Matt Corallo: Add failing test checking timelocked-txn removal during reorg
393 2015-12-01T12:18:30  <GitHub85> bitcoin/master 9b060e5 Matt Corallo: Fix removal of time-locked transactions during reorg
394 2015-12-01T12:18:30  <GitHub85> bitcoin/master b0a064c Matt Corallo: Fix comment in removeForReorg
395 2015-12-01T12:18:33  <GitHub180> [bitcoin] laanwj closed pull request #6915: [Mempool] Improve removal of invalid transactions after reorgs (master...fix-reorg-handling) https://github.com/bitcoin/bitcoin/pull/6915
396 2015-12-01T12:18:55  *** MarcoFalke has quit IRC
397 2015-12-01T12:19:05  *** MarcoFalke has joined #bitcoin-core-dev
398 2015-12-01T12:20:52  <GitHub117> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ef5ffa59afa...a60538bc456c
399 2015-12-01T12:20:53  <GitHub117> bitcoin/master 6da12df Wladimir J. van der Laan: qt: use QMetaObject::invokeMethod for cross-thread signaling in clientmodel...
400 2015-12-01T12:20:53  <GitHub117> bitcoin/master a60538b Wladimir J. van der Laan: Merge pull request #7143...
401 2015-12-01T12:21:02  <GitHub146> [bitcoin] laanwj closed pull request #7143: qt: use QMetaObject::invokeMethod for cross-thread signaling in clientmodel (master...2015_12_qt4_build) https://github.com/bitcoin/bitcoin/pull/7143
402 2015-12-01T12:21:37  <GitHub161> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a60538bc456c...c0c08c7c68d0
403 2015-12-01T12:21:38  <GitHub161> bitcoin/master aabc897 Wladimir J. van der Laan: rpc: Don't translate warning messages...
404 2015-12-01T12:21:38  <GitHub161> bitcoin/master c0c08c7 Wladimir J. van der Laan: Merge pull request #7141...
405 2015-12-01T12:21:42  <GitHub63> [bitcoin] laanwj closed pull request #7141: rpc: Don't translate warning messages (master...2015_12_warnings_translations) https://github.com/bitcoin/bitcoin/pull/7141
406 2015-12-01T12:22:28  *** fkhan has joined #bitcoin-core-dev
407 2015-12-01T12:28:02  <GitHub159> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/bc1f4275705a6aae03ce439cd317ec4166075c08
408 2015-12-01T12:28:03  <GitHub159> bitcoin/master bc1f427 Wladimir J. van der Laan: qt: periodic translations update
409 2015-12-01T12:32:40  <GitHub167> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bc1f4275705a...16f4a6e0fe26
410 2015-12-01T12:32:41  <GitHub167> bitcoin/master cfdc662 Suhas Daftuar: Explicitly set chain limits in replace-by-fee test
411 2015-12-01T12:32:41  <GitHub167> bitcoin/master 16f4a6e Wladimir J. van der Laan: Merge pull request #7137...
412 2015-12-01T12:32:47  <GitHub145> [bitcoin] laanwj closed pull request #7137: Tests: Explicitly set chain limits in replace-by-fee test (master...fix-rbf-test) https://github.com/bitcoin/bitcoin/pull/7137
413 2015-12-01T12:35:48  <wumpus> #6898 and #6872 need rebasing again, sorry for that, but this is what is bound to happen if so many merges wait until the last day
414 2015-12-01T12:36:47  <MarcoFalke> wumpus try $ for i in {1..100}; do src/test/test_bitcoin --log_level=ALL --run_test=scheduler_tests;done
415 2015-12-01T12:36:53  <MarcoFalke> Does this run fine?
416 2015-12-01T12:37:24  <wumpus> MarcoFalke: no time to check at the moment, but I'm ok with disabling the scheduler tests if people are experiencing issues with them
417 2015-12-01T12:37:48  <jonasschnelli> would it make sense to auto-choose a higher nDefaultDbCache in case bitcoind/qt detects more available ram?
418 2015-12-01T12:37:51  <wumpus> (if so many people can reproduce them it doesn't mean much whether I can or not anyway...)
419 2015-12-01T12:38:17  <wumpus> jonasschnelli: *up to a limit*
420 2015-12-01T12:38:37  <jonasschnelli> I think for most modern server systems 100MB (current default) is very low.
421 2015-12-01T12:38:53  <wumpus> jonasschnelli: e.g. scale down for small systems, scale up a bit for large systems, but please don't make an application use X% of ram indiscriminately.That's awful and rude.
422 2015-12-01T12:39:27  <jonasschnelli> Hmm... right... maybe its fine if the user just tweaks the -dbache manually.
423 2015-12-01T12:39:56  <jonasschnelli> sipa asked about adding a option in Qt ("provide X MB of ram for bitcoin-qt")...
424 2015-12-01T12:40:20  <wumpus> e.g. say you buy more ram because your system is slow/runs out of memory, next boot some background applications start claiming it all, and it's like nothing changed
425 2015-12-01T12:40:39  <jonasschnelli> hah. right.
426 2015-12-01T12:41:45  <wumpus> jonasschnelli: usually such a thing is done by having multiple system profiles, and allowing the user to choose between them (and having a custom option for advanced users)
427 2015-12-01T12:41:58  <wumpus> jonasschnelli: it could auto-select one based on some information gathered from the system
428 2015-12-01T12:42:27  <jonasschnelli> Yes. That would be nice...
429 2015-12-01T12:42:35  <wumpus> just make clear what the compromise is: sync is somewhat slower, but less RAM usage, sync is faster, but lots of RAM waste
430 2015-12-01T12:43:11  <jonasschnelli> Is changing the cache size during runtime possible? (CCoinsViewDB), flushing, deleting pcoinsdbview and recreating it?
431 2015-12-01T12:43:12  <wumpus> hm or maybe an option to reduce the dbcache after the initial sync?
432 2015-12-01T12:43:58  <jonasschnelli> wumpus: this is a very good point. A big cache size mainly helps for IBD performance...
433 2015-12-01T12:45:26  <wumpus> right now it's not possible to change the dbcache size during run time. I don't think it would be very hard to add if necesary, at least for the coinsviewcache
434 2015-12-01T12:45:44  <wumpus> (dbcache is divided up between some caches, I don't know if they're all easy to resize/reconfigure)
435 2015-12-01T12:46:58  <sipa> the leveldb cache may be harder to change
436 2015-12-01T12:48:44  <jonasschnelli> sipa, LOCK, flush CCoinsViewDB, delete CCoinsViewDB, new CCoinsViewDB, UNLOCK?
437 2015-12-01T12:48:55  <sipa> hell no
438 2015-12-01T12:48:58  <wumpus> you don't need to delte it, you could just add a method to change the limit?
439 2015-12-01T12:48:58  <jonasschnelli> :-)
440 2015-12-01T12:49:02  <sipa> don't delete the cache!
441 2015-12-01T12:49:29  <sipa> but you'll need to recalculate how much to assign to leveldb etc
442 2015-12-01T12:49:47  <wumpus> which flushes if the new size is smaller thant he current size, if it is a strict increase then even that is not needed
443 2015-12-01T12:50:09  <wumpus> yes, you need to recompute those
444 2015-12-01T12:53:29  <wumpus> for leveldb it does seem you have to close and reopen the database to change the cache size
445 2015-12-01T12:54:10  <GitHub180> [bitcoin] laanwj closed pull request #7063: [Tests] Add prioritisetransaction RPC test (master...add-prioritisetransaction-rpctest) https://github.com/bitcoin/bitcoin/pull/7063
446 2015-12-01T12:54:25  <sipa> now it would be useful if someone would benchmark how much leveldb cache is optimal :)
447 2015-12-01T12:55:10  <wumpus> right, it's very possible for there to be diminishing returns there sooner than for ccoinsviewcache
448 2015-12-01T12:55:43  <sipa> the numbers that are in there now are only based on very simple (and outdated) benchmarks
449 2015-12-01T13:02:36  <phantomcircuit> sipa, im guessing "more"
450 2015-12-01T13:18:38  <wumpus> I would be surprised if it makes much of a difference at all
451 2015-12-01T13:18:59  <tulip> I'm having a quick shot at testing it now.
452 2015-12-01T13:19:39  <wumpus> ccoinsview cache is somewhat wasteful in memory but it's so much more effective, I don't think increasing leveldb cache can compete
453 2015-12-01T13:20:02  <wumpus> (if it competes for the same bytes of memory)
454 2015-12-01T13:21:10  <wumpus> and I'm even more in doubt about nBlockTreeDBCache's effectiveness
455 2015-12-01T13:21:36  <wumpus> from the viewpoint of runtime, the block tree db is a write-only database
456 2015-12-01T13:22:23  <wumpus> oh we take care of that // block tree db cache shouldn't be larger than 2 MiB
457 2015-12-01T13:27:39  *** rook520 has quit IRC
458 2015-12-01T13:34:28  *** MarcoFalke has quit IRC
459 2015-12-01T13:41:08  *** Guyver2 has joined #bitcoin-core-dev
460 2015-12-01T13:55:34  *** guest234234 has quit IRC
461 2015-12-01T13:57:46  <GitHub68> [bitcoin] laanwj opened pull request #7144: test: Disable scheduler test manythreads (master...2015_12_disable_schedulertest) https://github.com/bitcoin/bitcoin/pull/7144
462 2015-12-01T14:00:49  *** jgarzik_ has quit IRC
463 2015-12-01T14:00:49  *** jgarzik_ has joined #bitcoin-core-dev
464 2015-12-01T14:00:52  *** jgarzik_ is now known as jgarzik
465 2015-12-01T14:01:09  <jgarzik> What are the hurdles blocking relay of new blocks in pruned mode?
466 2015-12-01T14:03:14  <tulip> would almost be nice to have a short, but intense "bench" chain of a few hundred blocks for testing configuration changes.
467 2015-12-01T14:03:14  <phantomcircuit> jgarzik, not having NODE_NETWORK set is iirc the only one really
468 2015-12-01T14:03:56  <tulip> problem with the main chain is that there's a bunch of empty which doesn't really represent the current load.
469 2015-12-01T14:04:25  <jgarzik> My VPS has reached its space limit, and I want to continue contributing usefully to the network ;p
470 2015-12-01T14:07:15  <phantomcircuit> do we have an rpc call that will essentially walk the entire utxo and pull it into cache? (yes i have all the memory)
471 2015-12-01T14:08:24  <phantomcircuit> gettxoutsetinfo seems to walk but avoid the cache layer
472 2015-12-01T14:13:01  <GitHub54> [bitcoin] jtimon opened pull request #7145: Mempool: Improve mempool's concurrency (master...mempool-estimator) https://github.com/bitcoin/bitcoin/pull/7145
473 2015-12-01T14:14:51  <jtimon> morcos: sipa BlueMatt I hope that if we can't agree on https://github.com/jtimon/bitcoin/commit/3c30cea7245a2fd44bbd9cf8844c6730855f63e4 , at least we can agree on #7145
474 2015-12-01T14:16:04  <jgarzik> phantomcircuit, I think it's more there's a grey area about how nodes will behave if a remote peer only has a subset of the full chain - sometimes they can respond to block requests, sometimes not.
475 2015-12-01T14:16:39  <jgarzik> phantomcircuit, older nodes that don't getheaders might get stuck in IBD?
476 2015-12-01T14:17:24  <jtimon> and if #7145 cannot be accepted for some reason, there's probably no point in me participating on any mempool/policy encapsulation anymore, and I will be able to stop distracting other devs and myself with it
477 2015-12-01T14:17:46  <phantomcircuit> jgarzik, older peers would definitely get stuck
478 2015-12-01T14:21:07  *** pmienk has quit IRC
479 2015-12-01T14:22:56  <phantomcircuit> hmm it seems the only way to "prime" the cache view is to reindex...
480 2015-12-01T14:22:56  <GitHub54> [bitcoin] paveljanik opened pull request #7146: Name union to prevent compiler warning (master...20151201_prevector_name_union) https://github.com/bitcoin/bitcoin/pull/7146
481 2015-12-01T14:27:38  *** tulip has quit IRC
482 2015-12-01T14:28:09  <jgarzik> hmmm.   !NODE_NETWORK should have no problem relaying blocks...  they just won't get asked for them.
483 2015-12-01T14:28:33  * jgarzik goes to test
484 2015-12-01T14:29:36  <phantomcircuit> jgarzik, correct
485 2015-12-01T14:29:40  <phantomcircuit> (probably)
486 2015-12-01T14:32:06  *** JackH has quit IRC
487 2015-12-01T14:34:25  <sdaftuar> jgarzik: the headers announcements PR should mean that pruned nodes can relay blocks just fine now
488 2015-12-01T14:35:22  <sdaftuar> including if there's a reorg that isn't more than 8 blocks
489 2015-12-01T14:36:16  <jgarzik> sdaftuar, for keeping !node_network you mean?   Because otherwise that doesn't fix older nodes that would get stuck
490 2015-12-01T14:36:32  <jgarzik> I wonder if we need NODE_RELAY
491 2015-12-01T14:36:32  <sdaftuar> i'm specifically talking about relaying new blocks, not helping other nodes sync
492 2015-12-01T14:36:38  *** pmienk has joined #bitcoin-core-dev
493 2015-12-01T14:37:33  <sdaftuar> ah are you asking what it would take to let pruned nodes serve up historical blocks?
494 2015-12-01T14:38:04  <jgarzik> No just looking at all the angles of pruning with fresh eyes
495 2015-12-01T14:39:01  <jgarzik> even with !node_network and just relaying new blocks, I presume a block locator can still be returned at a pruned boundary-and-beyond
496 2015-12-01T14:39:21  <sipa> yes, locators are built from the block index
497 2015-12-01T14:39:27  <sipa> they don't need the actual blocks
498 2015-12-01T14:39:41  <sdaftuar> so i think 0.9 and earlier nodes will download blocks in a reorg from a pruned peer fine via their getblocks mechanism
499 2015-12-01T14:39:52  <sdaftuar> we patched the getblocks response so that it won't return inv's for blocks that aren't on disk
500 2015-12-01T14:40:08  <sdaftuar> 0.10 and 0.11 nodes will indeed not be able to download reorgs from pruned peers
501 2015-12-01T14:40:26  <sdaftuar> 0.12 and later nodes should work fine for downloading reorgs from pruned peers, via the direct-fetch mechanism on headers messages
502 2015-12-01T14:40:53  <sipa> will 0.10 and 0.11 get disconnected if they try?
503 2015-12-01T14:40:58  <sdaftuar> they won't even try
504 2015-12-01T14:41:16  <jgarzik> Sounds like pruned nodes should only announce blocks to >= 0.12 peers
505 2015-12-01T14:41:49  <sipa> we still need granulatiy in the service flags
506 2015-12-01T14:41:59  <sdaftuar> well there's not much harm in inv'ing the tip to 0.11 and earlier peers is there?
507 2015-12-01T14:42:02  <sipa> as even 0.12 just won't connect to non-network nodes
508 2015-12-01T14:42:19  <sipa> sdaftuar: it may hide problems, i wouldn't
509 2015-12-01T14:42:19  *** ParadoxSpiral has joined #bitcoin-core-dev
510 2015-12-01T14:42:28  <jgarzik> thus the proposed NODE_RELAY
511 2015-12-01T14:42:35  <sipa> sdaftuar: people may think that it works fine, until it doesn't due to reorg
512 2015-12-01T14:43:13  <sdaftuar> hmm...  we merged that change a long time ago (to relay the tip)
513 2015-12-01T14:43:24  <sipa> oh well
514 2015-12-01T14:44:20  <jgarzik> pruning defaults to off so nearly nobody uses it
515 2015-12-01T14:44:27  <jgarzik> plenty of freedom to change
516 2015-12-01T14:44:27  *** CodeShark_ has quit IRC
517 2015-12-01T14:44:39  <sdaftuar> it's not too late i suppose to change it so that in 0.12, pruning nodes only relay if headers announcements are on?
518 2015-12-01T14:44:55  <sipa> sdaftuar: that does seem reasonable
519 2015-12-01T14:44:56  <sdaftuar> 0.11 didn't have relay on for pruning at all, so no expectations yet about how it should work i'd guess
520 2015-12-01T14:45:28  <jgarzik> nod
521 2015-12-01T14:45:37  <sdaftuar> it does needlessly harm 0.9 and 0.8 nodes... but probably not many of those left
522 2015-12-01T14:46:38  <sipa> sdaftuar: what if there is a +8 deep reorg?
523 2015-12-01T14:46:45  <sdaftuar> then we revert to inv
524 2015-12-01T15:05:29  *** [b__b] has quit IRC
525 2015-12-01T15:12:02  *** [b__b] has joined #bitcoin-core-dev
526 2015-12-01T15:17:26  *** Guyver2 has quit IRC
527 2015-12-01T15:22:53  <phantomcircuit> Luke-Jr, fyi switching to longpoll significantly increased my latency
528 2015-12-01T15:22:58  <phantomcircuit> by like 4 seconds
529 2015-12-01T15:56:44  <sipa> in the test framework is there anything i need to do to call a new RPC?
530 2015-12-01T15:57:03  <sipa> JSONRPC error: Method not found
531 2015-12-01T15:57:11  <sipa> sounds like bitcoind actually doesn't have it?
532 2015-12-01T15:57:15  <sipa> (this is for getblockheader)
533 2015-12-01T15:58:38  *** MarcoFalke has joined #bitcoin-core-dev
534 2015-12-01T16:04:55  <GitHub55> [bitcoin] jtimon reopened pull request #7115: Mempool: Decouple CBlockPolicyEstimator from CTxMemPool (fix #6134) (master...6134-nits) https://github.com/bitcoin/bitcoin/pull/7115
535 2015-12-01T16:12:38  *** [b__b] has quit IRC
536 2015-12-01T16:22:16  <wumpus> sipa: no, should be nothing you have to do
537 2015-12-01T16:23:17  <sipa> wumpus: i used a wrong variable name
538 2015-12-01T16:23:39  <wumpus> okay
539 2015-12-01T16:54:34  *** [b__b] has joined #bitcoin-core-dev
540 2015-12-01T16:57:28  *** JackH has joined #bitcoin-core-dev
541 2015-12-01T16:58:03  *** crescendo has quit IRC
542 2015-12-01T17:02:14  *** afk11 has joined #bitcoin-core-dev
543 2015-12-01T17:06:01  *** crescendo has joined #bitcoin-core-dev
544 2015-12-01T17:10:58  *** [b__b] has quit IRC
545 2015-12-01T17:38:46  *** wangchun_ has quit IRC
546 2015-12-01T17:39:15  *** wangchun has joined #bitcoin-core-dev
547 2015-12-01T17:41:39  *** Dyanisus has left #bitcoin-core-dev
548 2015-12-01T17:46:29  *** ParadoxSpiral_ has joined #bitcoin-core-dev
549 2015-12-01T17:49:43  *** ParadoxSpiral has quit IRC
550 2015-12-01T17:53:31  *** BashCo has quit IRC
551 2015-12-01T18:07:32  *** afk11 has quit IRC
552 2015-12-01T18:09:44  *** calibre720 has quit IRC
553 2015-12-01T18:15:15  *** [b__b] has joined #bitcoin-core-dev
554 2015-12-01T18:17:41  <GitHub38> [bitcoin] MarcoFalke opened pull request #7147: Univalue: Pull subtree (master...MarcoFalke-2015-univalueSync) https://github.com/bitcoin/bitcoin/pull/7147
555 2015-12-01T18:18:57  *** BashCo has joined #bitcoin-core-dev
556 2015-12-01T18:23:40  <gmaxwell> jgarzik: pruned nodes have relayed fine at the tip in master, though if there are reorgs they won't advertise them; with later changes they should also handle reorgs but I don't know if anyone has really tried that. I kept a node behind a pruned node for a while a month or so ago until moving on to test other things.
557 2015-12-01T18:24:45  <jgarzik> Ideal goal is a lightweight router mode that contributes usefully to the network (subjective definition, I know)
558 2015-12-01T18:28:09  <gmaxwell> well we have that now, fortunately (I think), we can't yet signal it explicitly-- though for blocks at the top we don't have to-- it'll just work; though I think it's probably good to finish hammering out what a pruned node is before we define a service flag as signifying the minimum it must be willing to do.
559 2015-12-01T18:28:35  <GitHub29> [bitcoin] jtimon closed pull request #7115: Mempool: Decouple CBlockPolicyEstimator from CTxMemPool (fix #6134) (master...6134-nits) https://github.com/bitcoin/bitcoin/pull/7115
560 2015-12-01T18:35:33  <GitHub119> [bitcoin] jtimon closed pull request #7145: Mempool: Improve mempool's concurrency (master...mempool-estimator) https://github.com/bitcoin/bitcoin/pull/7145
561 2015-12-01T18:39:44  *** da2ce7 has quit IRC
562 2015-12-01T18:39:59  *** da2ce7 has joined #bitcoin-core-dev
563 2015-12-01T18:51:10  <GitHub13> [bitcoin] MarcoFalke opened pull request #7148: [WIP] Run extended nightly builds in travis (master...travis/nightly) https://github.com/bitcoin/bitcoin/pull/7148
564 2015-12-01T19:30:25  <GitHub22> [bitcoin] MarcoFalke closed pull request #7084: mempool: Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee (master...MarcoFalke-2015-mempoolMaxTxFee) https://github.com/bitcoin/bitcoin/pull/7084
565 2015-12-01T19:31:16  <GitHub90> [bitcoin] sipa pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/16f4a6e0fe26...4077ad20d03f
566 2015-12-01T19:31:17  <GitHub90> bitcoin/master c49d5bc Alex Morcos: Store the total sig op count of a tx....
567 2015-12-01T19:31:18  <GitHub90> bitcoin/master f3fe836 Alex Morcos: Add a score index to the mempool....
568 2015-12-01T19:31:18  <GitHub90> bitcoin/master 7230187 Alex Morcos: Add TxPriority class and comparator
569 2015-12-01T19:31:21  <GitHub194> [bitcoin] sipa closed pull request #6898: Rewrite CreateNewBlock (master...fasterCNB) https://github.com/bitcoin/bitcoin/pull/6898
570 2015-12-01T19:31:46  <GitHub151> [bitcoin] MarcoFalke reopened pull request #7084: mempool: Replace maxFeeRate of 10000*minRelayTxFee with maxTxFee (master...MarcoFalke-2015-mempoolMaxTxFee) https://github.com/bitcoin/bitcoin/pull/7084
571 2015-12-01T19:42:58  *** raedah has joined #bitcoin-core-dev
572 2015-12-01T19:49:08  *** Guyver2 has joined #bitcoin-core-dev
573 2015-12-01T20:10:19  <morcos> sipa: woohoo thanks!  now i can start changing it again. :)
574 2015-12-01T20:11:37  *** cocoBTC has joined #bitcoin-core-dev
575 2015-12-01T20:17:52  <Luke-Jr> sigh, so I guess I'm going to need to strongly recommend miners not upgrade to 0.12?
576 2015-12-01T20:18:55  <morcos> Luke-Jr: or you could still advocate for 6357 to be merged...  but honestly i don't think it makes much difference, have you looked how different it is to only use original in-chain inputs?
577 2015-12-01T20:19:39  <morcos> For instance if you are not sending chains of txs, then there is no difference
578 2015-12-01T20:20:04  <morcos> if your tx has at least a significant part of its inputs already in the chain, then it'll still increase in priority and eventually get mined
579 2015-12-01T20:20:19  <morcos> (or course assuming its not evicted before that)
580 2015-12-01T20:20:22  <Luke-Jr> morcos: hm, that's a point.. and I guess the bad policy default (priority size = 0) can be overridden still
581 2015-12-01T20:20:47  <Luke-Jr> 6357 appears to have been auto-closed by bad GitHub logic.. are you able to reopen it?
582 2015-12-01T20:20:52  <morcos> yes i really don't think its that bad
583 2015-12-01T20:22:34  <morcos> i assume i could, it might need rebasing, but if you really want it, why don't you just take the commits.   i'd prefer to have you come around to the view that 7008 (lower bound priority) is really good enogh especially with the tradeoff with complexity
584 2015-12-01T20:22:36  <Luke-Jr> 7022 is pretty bad :/
585 2015-12-01T20:23:23  <Luke-Jr> morcos: "complexity" as in CPU time is a consideration, but not "complexity" as in a few more lines of code since I'm going to need to maintain that code regardless of whether it's in Core or not.
586 2015-12-01T20:23:34  <sipa> Luke-Jr: i really don't believe the existing priority system is worth maintaining; it is a burden on performance and maintainance
587 2015-12-01T20:23:50  <Luke-Jr> in practice, it's more complexity in LOC/maintenance to have it NOT in master
588 2015-12-01T20:23:57  <sipa> that's your view
589 2015-12-01T20:24:12  *** belcher has joined #bitcoin-core-dev
590 2015-12-01T20:24:16  <morcos> Luke-Jr: the complexity i'm concerned with is complexity of correctness
591 2015-12-01T20:24:17  <sipa> i have no problem with creating a mechanism that takes coins value/age into account for prioritization, however
592 2015-12-01T20:24:17  <Luke-Jr> sipa: that's my view, as the guy maintaining the mining stuff..
593 2015-12-01T20:24:33  <sipa> Luke-Jr: i know that's your view; i respectfully disagree, and i'm not alone
594 2015-12-01T20:24:44  <morcos> sipa: i love it how even you have your irrational pet projects. :)
595 2015-12-01T20:25:15  <sipa> morcos: if everything in bitcoin was rational, nobody would have started using it
596 2015-12-01T20:26:13  <Luke-Jr> sipa: your disagreement appears to be about a cost that I bear specifically.
597 2015-12-01T20:27:57  <jgarzik> It's a feature specifically -for- miners.  What do -most- miners want?   Can't make a specifically-for-mining feature that miners don't use :)
598 2015-12-01T20:28:09  <Luke-Jr> unless I have misunderstood that, I ask that my evaluation of my own costs be respected with a slightly higher weight :/
599 2015-12-01T20:28:39  <Luke-Jr> jgarzik: majority of miners have no business dictating what minority of miners do. and lots of miners *do* use the priority space.
600 2015-12-01T20:28:42  <morcos> Luke-Jr: priority is irrepairably broken with 0.12 and limited mempools that don't respect it
601 2015-12-01T20:28:52  <Luke-Jr> the miners who have disabled it, have done so because of the performance issues that are now fixed
602 2015-12-01T20:28:58  <morcos> when we somehow decided to not address that or failed to decide to address it
603 2015-12-01T20:29:09  <morcos> i think we put ourselves clearly on the path to removing priority
604 2015-12-01T20:29:12  <Luke-Jr> morcos: I thought we had decided to address it, but nothing got done :p
605 2015-12-01T20:29:41  <Luke-Jr> morcos: but if that's a serious issue, then it puts us back to "miners should not upgrade to 0.12" :/
606 2015-12-01T20:29:54  <morcos> that will be my first pull for 0.13, because its going to make so much easier to do everythign after.  and i'll get to steal a bunch of deleted code lines that otherwise jgarzik woudl have gotten credit for :)
607 2015-12-01T20:30:26  <sipa> 0.12 will work with priority fine as a miner, if you have a sufficiently large mempool
608 2015-12-01T20:30:29  <Luke-Jr> after what?
609 2015-12-01T20:30:31  <jgarzik> heh
610 2015-12-01T20:30:51  <Luke-Jr> sipa: that seems like a reasonable expectation of miners IMO
611 2015-12-01T20:30:55  <morcos> Luke-Jr: working with the rest of the mempool/mining code will be much easier when priority is gone
612 2015-12-01T20:31:19  <sipa> but yes, it is my view (and i think of most other developers) that the priority as a separate sorting criterion will go away
613 2015-12-01T20:31:29  <Luke-Jr> morcos: priority will never be gone
614 2015-12-01T20:32:45  <morcos> it could theoretically be implemented by a quite complex companion program which just selectively applied feeDeltas i suppose
615 2015-12-01T20:32:56  <Luke-Jr> morcos: it shouldn't need to be
616 2015-12-01T20:33:30  <Luke-Jr> it should be as simple as it is now, or simpler.
617 2015-12-01T20:33:44  <Luke-Jr> anything else is harmful to Bitcoin
618 2015-12-01T20:34:10  <jgarzik> hyperbole
619 2015-12-01T20:36:20  <jgarzik> Operative questions to me:  (1) Do most CNB consumers care about this or just luke?   (2) Is there a way to have cake & eat it too - perform a second pass for priority exclusively in the mining code for any stragglers that failed the first pass, applying some local map filter?
620 2015-12-01T20:36:58  <jgarzik> with the goal of #2 being avoiding all the current complexity that the consensus of devs agrees is there
621 2015-12-01T20:37:58  <Luke-Jr> do I need to go make a big deal about this on reddit etc to prove (1)?
622 2015-12-01T20:39:10  <Luke-Jr> (most people right now don't know anything about this discussion and won't understand it without explaining the details.)
623 2015-12-01T20:39:29  <jgarzik> a CNB consumer =  a CNB user = a miner
624 2015-12-01T20:40:06  <jgarzik> It sounds like the ideal solution is a post-pass filter for applying some site local policy
625 2015-12-01T20:40:17  <jgarzik> maybe a pre-pass filter for spam filtering
626 2015-12-01T20:40:39  <jgarzik> (though 99% of that happens via IsStandard)
627 2015-12-01T20:40:49  <sipa> jgarzik: so the scoring for CNB is just a single sort function now, that could be overridden to be anything
628 2015-12-01T20:40:56  *** MarcoFalke has quit IRC
629 2015-12-01T20:41:06  <sipa> jgarzik: priority is more complicated because it needs re-evaluation
630 2015-12-01T20:41:26  <sipa> so anything that doesn't need re-evaluation would be trivial to do
631 2015-12-01T20:41:31  <jgarzik> nod - post-pass - picks up stragglers fee didnt'
632 2015-12-01T20:48:37  <morcos> sdaftuar and i have been sitting here trying to figure out if there would be a nice way to add back (for 0.13) a way to fill a portion of the block with an alternate metric
633 2015-12-01T20:49:35  <morcos> but the main thing i keep coming back to is non fee based metrics are broken for other purposes
634 2015-12-01T20:49:38  <morcos> relay
635 2015-12-01T20:49:40  <morcos> mempool limiting
636 2015-12-01T20:50:16  <morcos> so how much benefit is there to be able to mine based on a metric if you can't ensure that txs with a high score will even propogate
637 2015-12-01T20:50:35  <morcos> and by fee based, i mean including feeDelta
638 2015-12-01T20:51:04  *** MarcoFalke has joined #bitcoin-core-dev
639 2015-12-01T20:51:18  <Luke-Jr> morcos: you can't ensure anything with propagate ever
640 2015-12-01T20:51:26  <morcos> we've certainly worked to make that still work, although to tell you the truth, i don't think we fixed pre-existing bugs for feeDelta not influencing ATMP
641 2015-12-01T20:51:50  <morcos> also sdaftuar just pointed out feeDelta for trimming hasn't been merged yet, that should be tagged for 0.12
642 2015-12-01T20:52:46  <morcos> should we also fix it so feeDelta applies for ATMP?  seems like yes.   that'll make it easier for people to experiment with whether using feeDeltas can get them close enough to achieving the policy they want
643 2015-12-01T20:54:36  <morcos> but that would mean relaying based of feeDelta too
644 2015-12-01T20:54:55  <sipa> i think that's reasonable
645 2015-12-01T20:57:18  <sdaftuar> i can add a commit to 7062 to address that
646 2015-12-01T21:05:34  *** raedah has quit IRC
647 2015-12-01T21:22:17  *** tulip has joined #bitcoin-core-dev
648 2015-12-01T21:26:07  *** raedah has joined #bitcoin-core-dev
649 2015-12-01T21:42:20  <GitHub68> [bitcoin] luke-jr opened pull request #7149: Bugfix: Correctly calculate priority when inputs are mined after dependent transactions enter the memory pool (master...bugfix_priority) https://github.com/bitcoin/bitcoin/pull/7149
650 2015-12-01T21:42:23  <Luke-Jr> morcos: ^
651 2015-12-01T21:44:17  *** pmienk has quit IRC
652 2015-12-01T21:49:12  *** pmienk has joined #bitcoin-core-dev
653 2015-12-01T21:56:37  *** tulip has quit IRC
654 2015-12-01T21:57:22  <Luke-Jr> sipa: re release notes "Unlike earlier versions, unconfirmed but non-conflicting transactions will never get a negative confirmation count." afaik that never could happen in earlier versions..?
655 2015-12-01T21:58:01  <GitHub39> [bitcoin] pstratem opened pull request #7150: Print size of pcoinsTip cache in AcceptToMemoryPool (master...2015-12-1-printcachesize) https://github.com/bitcoin/bitcoin/pull/7150
656 2015-12-01T21:58:40  <sipa> Luke-Jr: by conflicting i mean conflicting with the chain
657 2015-12-01T21:58:51  <Luke-Jr> sipa: I'm aware..
658 2015-12-01T21:58:54  <sipa> earlier, conflicting with the mempool was enough to get -1 confirms
659 2015-12-01T21:58:59  <Luke-Jr> ah
660 2015-12-01T21:59:09  <Luke-Jr> was that actually possible? O.o
661 2015-12-01T21:59:43  <sipa> maybe it was very hard to reach that
662 2015-12-01T22:00:02  <sipa> as the wallet tried to get its transactions in the mempool at startup
663 2015-12-01T22:00:57  <Luke-Jr> I wonder if this should be considerd a bugfix and backported
664 2015-12-01T22:00:57  <sipa> i agree the explanation there is confusing
665 2015-12-01T22:01:09  <Luke-Jr> maybe with a min(-1) on the count
666 2015-12-01T22:01:12  <sipa> it's mostly needed because of mempool eviction
667 2015-12-01T22:01:22  *** ParadoxSpiral_ has quit IRC
668 2015-12-01T22:02:00  <sipa> so i wouldn't consider it a bugfix pre-0.12
669 2015-12-01T22:03:29  <Luke-Jr> k
670 2015-12-01T22:05:34  *** bsm117532 has quit IRC
671 2015-12-01T22:05:44  <Luke-Jr> 7096 has me confused about whether it is a fix, part fix, or what :|
672 2015-12-01T22:05:59  *** zookolaptop has joined #bitcoin-core-dev
673 2015-12-01T22:11:27  *** tulip has joined #bitcoin-core-dev
674 2015-12-01T22:13:33  <jtimon> ping #6625
675 2015-12-01T22:15:57  *** lecusemb1e has quit IRC
676 2015-12-01T22:16:05  *** lecusemble has joined #bitcoin-core-dev
677 2015-12-01T22:21:26  <GitHub150> [bitcoin] luke-jr opened pull request #7151: Revert default block priority size to 50k (master...revert_priodef) https://github.com/bitcoin/bitcoin/pull/7151
678 2015-12-01T22:22:39  *** instagibbs has quit IRC
679 2015-12-01T22:24:22  *** Guyver2 has quit IRC
680 2015-12-01T22:25:33  *** instagibbs has joined #bitcoin-core-dev
681 2015-12-01T22:33:29  *** arubi has quit IRC
682 2015-12-01T22:39:49  *** arubi has joined #bitcoin-core-dev
683 2015-12-01T22:44:22  <gmaxwell> Luke-Jr: On the priority stuff, why not make it work so that it can run using an external policy server that adjusts the transaction score (feerate) using the rpc?
684 2015-12-01T22:44:45  <gmaxwell> Luke-Jr: then that gets policy beyond the basic behavior out of bitcoind, and probably fixes all the performance concerns too.
685 2015-12-01T22:44:53  <Luke-Jr> gmaxwell: that makes policy unnecessarily and gratuitously complicated to implement.
686 2015-12-01T22:45:12  <Luke-Jr> and doesn't address the mempool side
687 2015-12-01T22:45:22  <gmaxwell> But it's good because it makes it infinitely configurable without turning everyone into a bitcoind hacker.
688 2015-12-01T22:45:45  <Luke-Jr> gmaxwell: I'm already working on an infinitely-configurable change that doesn't gratuitously complicate things.. but it takes time :/
689 2015-12-01T22:45:49  <gmaxwell> The eviction uses the modified score (feerate), no? so it's only ingress thats not addressed.
690 2015-12-01T22:46:22  <gmaxwell> also the process I described is inherently safe, inside bitcoind if a miner configures things  (esp by hacking code) they risk making their daemon crash.
691 2015-12-01T22:46:40  <gmaxwell> And can't do things like so anti-spam analysis or what not because its in the critical path.
692 2015-12-01T22:48:24  <Luke-Jr> gmaxwell: none of this is possible for 0.12
693 2015-12-01T22:48:47  *** arubi_ has joined #bitcoin-core-dev
694 2015-12-01T22:49:09  <gmaxwell> an external daemon would work with git master right now.
695 2015-12-01T22:50:00  *** arubi has quit IRC
696 2015-12-01T22:52:18  *** MarcoFalke has quit IRC
697 2015-12-01T23:02:37  *** bsm117532 has joined #bitcoin-core-dev
698 2015-12-01T23:22:30  *** zookolaptop has quit IRC
699 2015-12-01T23:40:47  *** cocoBTC has quit IRC
700 2015-12-01T23:41:35  *** amiller_ has quit IRC
701 2015-12-01T23:42:12  *** amiller has joined #bitcoin-core-dev
702 2015-12-01T23:42:19  *** amiller is now known as Guest46010
703 2015-12-01T23:50:32  <jgarzik> for ingress, pass firstseen rejected TXs to external as well