1 2016-01-05T00:19:27  *** jcorgan|torture is now known as jcorgan
  2 2016-01-05T00:30:10  *** MarcoFalke has quit IRC
  3 2016-01-05T00:31:30  *** brg444 has joined #bitcoin-core-dev
  4 2016-01-05T01:04:34  *** Ylbam has quit IRC
  5 2016-01-05T01:32:32  *** jtimon has quit IRC
  6 2016-01-05T01:42:48  *** afk11 has joined #bitcoin-core-dev
  7 2016-01-05T01:49:18  *** afk11 has quit IRC
  8 2016-01-05T02:16:13  *** afk11 has joined #bitcoin-core-dev
  9 2016-01-05T03:02:45  <morcos> wumpus: MarkoFalke: what is the intended purpose of mintxfee?  I was just looking back at the changes where Marco introduced GetRequiredFee, which was maybe a step in the right direction, but maybe not the proper fix.
 10 2016-01-05T03:03:38  <morcos> Perhaps I also changed this in my estimateSmartFee PR, but i don't think so, anyway, minTxFee is not actually a minTxFee
 11 2016-01-05T03:04:02  <morcos> it only serves as that if you are not using fee estimation or fee estimation can not return a result
 12 2016-01-05T03:06:00  <morcos> I'm asking this because I think we should change the default value that gets used if fee estimation can't give you an answer.  As rusty was pointing out in bitcoin-dev, 1000 sat/KB is just too small
 13 2016-01-05T03:06:57  <morcos> And since this number is rarely used, i think its fine if its significantly higher, say at least 10000 sat/KB.   But then I think all of the comments in the QT code are misleading, because you might often be paying a fee less than this and not depending on priority
 14 2016-01-05T03:08:19  <morcos> Anwyay, super annoying since these are probably all translation strings, so maybe we can't fix the UI confusion for 0.12.  But I still think its worth bumping the default, you don't want to fall back to 1000 sat/KB before yoru fee estimates warm up
 15 2016-01-05T03:10:33  *** Watcher2 has joined #bitcoin-core-dev
 16 2016-01-05T03:15:20  *** Watcher2 has left #bitcoin-core-dev
 17 2016-01-05T03:18:01  *** afk11 has quit IRC
 18 2016-01-05T03:32:49  *** p15 has joined #bitcoin-core-dev
 19 2016-01-05T03:44:34  *** Cory has quit IRC
 20 2016-01-05T03:46:49  *** Pasha has joined #bitcoin-core-dev
 21 2016-01-05T03:53:43  *** Pasha is now known as Cory
 22 2016-01-05T04:22:25  *** brg444 has quit IRC
 23 2016-01-05T04:32:10  *** Cory has quit IRC
 24 2016-01-05T04:34:00  *** Pasha has joined #bitcoin-core-dev
 25 2016-01-05T04:40:54  *** Pasha is now known as Cory
 26 2016-01-05T05:00:03  *** dermoth has quit IRC
 27 2016-01-05T05:00:31  *** dermoth has joined #bitcoin-core-dev
 28 2016-01-05T05:13:25  *** [2]evoskuil has joined #bitcoin-core-dev
 29 2016-01-05T05:15:06  *** evoskuil has quit IRC
 30 2016-01-05T05:15:06  *** [2]evoskuil is now known as evoskuil
 31 2016-01-05T05:21:02  *** droark has joined #bitcoin-core-dev
 32 2016-01-05T05:36:00  *** dcousens_ is now known as dcousens
 33 2016-01-05T05:40:46  *** arowser has quit IRC
 34 2016-01-05T05:41:16  *** arowser has joined #bitcoin-core-dev
 35 2016-01-05T05:52:00  *** cryptopeddler has quit IRC
 36 2016-01-05T05:53:29  *** cryptopeddler has joined #bitcoin-core-dev
 37 2016-01-05T06:20:20  *** p15_ has joined #bitcoin-core-dev
 38 2016-01-05T06:23:32  *** p15 has quit IRC
 39 2016-01-05T06:27:38  *** Ylbam has joined #bitcoin-core-dev
 40 2016-01-05T07:21:54  *** adam3us has quit IRC
 41 2016-01-05T07:45:56  *** Cory has quit IRC
 42 2016-01-05T07:47:12  *** Thireus has joined #bitcoin-core-dev
 43 2016-01-05T07:48:06  *** Pasha has joined #bitcoin-core-dev
 44 2016-01-05T07:53:38  *** Thireus has quit IRC
 45 2016-01-05T07:54:59  *** Pasha is now known as Cory
 46 2016-01-05T07:55:46  *** p15_ has quit IRC
 47 2016-01-05T08:05:54  *** p15 has joined #bitcoin-core-dev
 48 2016-01-05T08:22:48  *** adam3us has joined #bitcoin-core-dev
 49 2016-01-05T08:24:01  *** Alopex has quit IRC
 50 2016-01-05T08:25:06  *** Alopex has joined #bitcoin-core-dev
 51 2016-01-05T08:36:16  *** murch has joined #bitcoin-core-dev
 52 2016-01-05T08:37:29  *** BashCo has quit IRC
 53 2016-01-05T08:48:19  *** paveljanik has quit IRC
 54 2016-01-05T08:48:36  *** JackH has joined #bitcoin-core-dev
 55 2016-01-05T08:56:52  *** BashCo has joined #bitcoin-core-dev
 56 2016-01-05T09:32:20  *** xiangfu has quit IRC
 57 2016-01-05T09:41:34  *** jtimon has joined #bitcoin-core-dev
 58 2016-01-05T09:55:03  *** p15_ has joined #bitcoin-core-dev
 59 2016-01-05T09:57:35  *** p15 has quit IRC
 60 2016-01-05T10:03:42  *** adam3us has quit IRC
 61 2016-01-05T10:08:27  *** Thireus has joined #bitcoin-core-dev
 62 2016-01-05T10:32:53  *** zookolaptop has joined #bitcoin-core-dev
 63 2016-01-05T10:54:46  *** zookolaptop has quit IRC
 64 2016-01-05T10:58:26  *** adam3us has joined #bitcoin-core-dev
 65 2016-01-05T11:05:13  <GitHub141> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/45d13abf4ea1...a10a7920c3ac
 66 2016-01-05T11:05:14  <GitHub141> bitcoin/master 5246180 Suhas Daftuar: Mark blocks with too many sigops as failed
 67 2016-01-05T11:05:14  <GitHub141> bitcoin/master a10a792 Wladimir J. van der Laan: Merge pull request #7217...
 68 2016-01-05T11:05:23  <GitHub105> [bitcoin] laanwj closed pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
 69 2016-01-05T11:05:56  <GitHub58> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/e08b7cb33ca30e03a4fda2eb13fc101628907258
 70 2016-01-05T11:05:56  <GitHub58> bitcoin/0.12 e08b7cb Suhas Daftuar: Mark blocks with too many sigops as failed...
 71 2016-01-05T11:10:01  *** MarcoFalke has joined #bitcoin-core-dev
 72 2016-01-05T11:11:20  *** zookolaptop has joined #bitcoin-core-dev
 73 2016-01-05T11:16:36  <MarcoFalke> morcos, I agree 1000 sat/KB is too low. About your question: GetRequiredFee() returns whatever is higher: the minRelayTxFee (which is needed due to the mempool) or the mintxfee (which is what the user may have set in his settings)
 74 2016-01-05T11:18:49  <MarcoFalke> Personally I don't use fee estimates and my .conf has a hardcoded mintxfee which just fits my time-cost-tradeoff just fine.
 75 2016-01-05T11:19:41  <MarcoFalke> I was planning to writeup about the "hard" fees in the release notes but if you are planning to change the notion of mintxfee, please let me know
 76 2016-01-05T11:20:51  <MarcoFalke> wumpus, anything holding back 7193 ?
 77 2016-01-05T11:31:09  *** Guyver2 has joined #bitcoin-core-dev
 78 2016-01-05T11:37:14  <wumpus> MarcoFalke: huh, "pruning" is kind of ambigious in this context
 79 2016-01-05T11:38:38  <wumpus> test looks good to me though
 80 2016-01-05T11:38:55  <MarcoFalke> Should have been merged as part of the pull that introduced "pruning"
 81 2016-01-05T11:39:58  <wumpus> let's not call it pruning please
 82 2016-01-05T11:40:15  *** laurentmt has joined #bitcoin-core-dev
 83 2016-01-05T11:41:00  *** laurentmt has quit IRC
 84 2016-01-05T11:41:42  *** zookolaptop has quit IRC
 85 2016-01-05T11:44:23  <wumpus> so  #7193 fixes the test so that it actually tests what it purports to test
 86 2016-01-05T11:45:35  <wumpus> what do you mean with "pruning must fail on 0.12"?
 87 2016-01-05T11:45:59  <wumpus> *this test* must fail on 0.12?
 88 2016-01-05T11:46:25  <wumpus> and succeed on master?
 89 2016-01-05T11:46:59  <MarcoFalke> It must fail where trimming was not yet implemented
 90 2016-01-05T11:47:13  <MarcoFalke> It must pass when (and after) trimming was implemented
 91 2016-01-05T11:47:27  <wumpus> right - the test, not the process itself
 92 2016-01-05T11:47:31  <wumpus> ok then I understand, thanks ;)
 93 2016-01-05T11:49:36  <MarcoFalke> oops, was a typo in my comment
 94 2016-01-05T11:52:32  *** AtashiCon has quit IRC
 95 2016-01-05T11:52:36  *** Arnavion3 has joined #bitcoin-core-dev
 96 2016-01-05T11:52:40  *** Arnavion3 is now known as AtashiCon
 97 2016-01-05T11:54:02  <morcos> MarcoFalke: If you want to use a preset fee, then why do you use mintxfee and not paytxfee?
 98 2016-01-05T11:55:05  <GitHub45> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a10a7920c3ac...2078495d9c5f
 99 2016-01-05T11:55:05  <GitHub45> bitcoin/master fafd093 MarcoFalke: [wallet] Adjust pruning test
100 2016-01-05T11:55:06  <GitHub45> bitcoin/master 2078495 Wladimir J. van der Laan: Merge pull request #7193...
101 2016-01-05T11:55:11  <GitHub159> [bitcoin] laanwj closed pull request #7193: [wallet] Cleanup tests (master...MarcoFalke-2015-WalletTests) https://github.com/bitcoin/bitcoin/pull/7193
102 2016-01-05T11:55:53  <morcos> I guess my point was what is the intended use of mintxfee?  it seems to function now mostly as the fall back default.  it does not appear to serve as a min otherwise?  but i'm not sure i'd fully thought through all the different fee configurations
103 2016-01-05T11:56:06  <wumpus> I'm not entirely sure either
104 2016-01-05T11:56:40  <btcdrak> oh finally some life
105 2016-01-05T11:56:47  <btcdrak> was really quiet here  this morning :)
106 2016-01-05T11:56:48  <MarcoFalke> morcos, paytxfee can be set via settxfee
107 2016-01-05T11:57:01  <MarcoFalke> If you happen to settxfee too low, you might want a fall back
108 2016-01-05T11:57:17  <MarcoFalke> That's what I was guessing why it was there, but your concern is valid
109 2016-01-05T11:58:21  <MarcoFalke> so mintxfee is the "hardcoded" minimum whereas paytxfee is your "dynamic choice"
110 2016-01-05T11:58:34  <morcos> MarcoFalke: yeah ok , so thats a bit what i was afraid of
111 2016-01-05T11:58:53  <morcos> for someone like you, you would not want mintxfee to be set to say 20000 satoshis
112 2016-01-05T11:59:10  <morcos> because you would want the freedom to choose below that sometimes
113 2016-01-05T11:59:22  <GitHub162> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/bfdaa3c87f6054b0b1e617031d6a8f02cdfc99dd
114 2016-01-05T11:59:22  <GitHub162> bitcoin/0.12 bfdaa3c MarcoFalke: [wallet] Adjust pruning test...
115 2016-01-05T11:59:50  <morcos> but for someone using fee estimation, they'd probably rather it fall back to something that pays a bit too much rather than the other way aroud.  as it only gets used very rarely
116 2016-01-05T12:01:01  <morcos> I mean luckily it is command line settable also
117 2016-01-05T12:02:11  <morcos> so no reason to obsesses on it now, and just pick something that is more sensible than 1000
118 2016-01-05T12:02:17  <GitHub107> [bitcoin] jonasschnelli pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/aa413687de45ef9add61f97447532a87bd2b2bb7
119 2016-01-05T12:02:18  <GitHub107> bitcoin/master aa41368 Jonas Schnelli: Merge pull request #7282...
120 2016-01-05T12:02:26  <GitHub75> [bitcoin] jonasschnelli closed pull request #7282: [Qt] fix coincontrol update issue when deleting a send coins entry (master...2016/01/qt_cc_fee) https://github.com/bitcoin/bitcoin/pull/7282
121 2016-01-05T12:05:54  <MarcoFalke> jonas, is this a backport as well?
122 2016-01-05T12:08:54  <GitHub51> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/5cadf3eb60ddc630d9e749f7a92e51d07d2e614a
123 2016-01-05T12:08:54  <GitHub51> bitcoin/0.12 5cadf3e Jonas Schnelli: [Qt] fix coincontrol update issue when deleting a send coin entry...
124 2016-01-05T12:37:02  <MarcoFalke> jonasschnelli, how can I trigger the welcome dialog of qt?
125 2016-01-05T12:37:09  <MarcoFalke> firts-start dialog
126 2016-01-05T12:40:06  <wumpus> -choosedatadir
127 2016-01-05T12:43:32  *** p15_ has quit IRC
128 2016-01-05T13:11:55  <GitHub66> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/aa413687de45...605c17844ea3
129 2016-01-05T13:11:56  <GitHub66> bitcoin/master fa6ad85 MarcoFalke: [devtools] Rewrite fix-copyright-headers.py
130 2016-01-05T13:11:57  <GitHub66> bitcoin/master fa24439 MarcoFalke: Bump copyright headers to 2015
131 2016-01-05T13:11:57  <GitHub66> bitcoin/master fa71669 MarcoFalke: [devtools] Use git pretty-format for year parsing
132 2016-01-05T13:12:00  <GitHub122> [bitcoin] laanwj closed pull request #7205: Update copyright headers to 2015 (master...MarcoFalke-2015-BumpHeaders-0.12) https://github.com/bitcoin/bitcoin/pull/7205
133 2016-01-05T13:14:20  <GitHub179> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/333e1eaeea80344e5a28db6efbce2691c85e2b25
134 2016-01-05T13:14:20  <GitHub179> bitcoin/0.12 333e1ea MarcoFalke: Bump copyright headers to 2015...
135 2016-01-05T13:17:42  *** arowser has quit IRC
136 2016-01-05T13:18:14  *** arowser has joined #bitcoin-core-dev
137 2016-01-05T13:45:20  <jtimon> wumpus I'm still on vacation and kind of waiting on #7091 before continuing with the "document-with-words-and-pictures" I promised to some people, but...what is the "right time for refactors and moveonlies"? I really don't want to miss it for the consensus encapsulation moveonly again
138 2016-01-05T13:46:25  <jtimon> I mean something like this https://github.com/jtimon/bitcoin/commit/f8c34f27d4020880647cbdbafad70793882cef79 (after #7287 )
139 2016-01-05T13:49:38  <jtimon> it was supposed to be after major version forks, right? or is it after the major released is actually done (to avoid interfering with backports)?
140 2016-01-05T13:53:33  *** Quent1 has joined #bitcoin-core-dev
141 2016-01-05T13:56:26  *** Quent has quit IRC
142 2016-01-05T14:21:30  <morcos> wumpus: are you completely opposed to adding a new command line argument for 0.12.  -defaulttxfeeifnoestimate (or something)
143 2016-01-05T14:21:44  <morcos> I think it makes a lot of sense for this to be a different value than -mintxfee
144 2016-01-05T14:22:12  <morcos> and then we can actually make fee estimate generated fees respect -mintxfee (which they currently don't)
145 2016-01-05T14:22:56  <morcos> I would then advocate that there is no need to change -mintxfee right now, we can leave it at 1000, but should someone desire to never ever send fees that low, they can bump that number
146 2016-01-05T14:23:07  <morcos> and it'll prevent them from doing so, regardless of how they pick their fees
147 2016-01-05T14:23:32  <morcos> -defaulttxfeeifnoestimate will only come into play if you're trying to use estimates and you can't
148 2016-01-05T14:23:59  <morcos> (uh not exactly, if you're trying to use estimates and you can't get an estimate for the value you are asking for, it'll make sure you pay at least that much)
149 2016-01-05T14:24:16  <maaku> we shouldn't be pulling numbers out of a hat for fees, mintxfee or defaulttxfeeifnoestimate or otherwise
150 2016-01-05T14:24:33  <morcos> so if for example you try to estimatefee 1, and it can only give you an answer for 2 and says its 25000 satoshis, but the default is 40000, then it'll make you pay 40000 in that case
151 2016-01-05T14:24:43  <morcos> but if you asked for 2, and got 25000 at 2, then thats fine
152 2016-01-05T14:24:55  <morcos> maaku: if you have no estimates (on startup) you have to pull numbers from a hat
153 2016-01-05T14:25:27  <maaku> morcos: or you can disable transaction creation until the fee estimator is primed
154 2016-01-05T14:25:34  <MarcoFalke> morcos, I'd be fine with setting mintxfee to 5000 or 10000 and mention in the release notes that ppl can change it.
155 2016-01-05T14:25:35  <morcos> my point is this is a relatively rare occurence, but makes much more sense to have it do something sane, than ridiculous (right now it defaults to mintxfee in all the cases i mentioned)
156 2016-01-05T14:25:46  <maaku> although hopefully soon we will have the consensus changes needed to prime estimation on startup
157 2016-01-05T14:26:11  <morcos> MarcoFalke: I think what I proposed makes a lot more sense, because it seems to me peole might say, you know what, i odn't care what fee estimation says i always want to pay at least X
158 2016-01-05T14:26:12  <MarcoFalke> And also adjust the GUI to show the GetRequiredFee() for estimates, in case it does not yet do this
159 2016-01-05T14:26:13  <aj> morcos: it'd seem more user-friendly to actually say "i don't know what fee you need to get into the next block" in that case
160 2016-01-05T14:26:21  <morcos> so giving them a way to do that with -mintxfee is valuable
161 2016-01-05T14:26:30  <maaku> morcos: defaulttxfeeifnoestimate seems just as crazy
162 2016-01-05T14:27:13  <morcos> aj: its not just gui, if you just do sendtoaddress() from RPC, you don't get a chance for feedback, what does it default to
163 2016-01-05T14:27:21  <morcos> and even in the gui, what should it default to if it doesn't know
164 2016-01-05T14:27:29  <morcos> maaku: why is that crazy
165 2016-01-05T14:27:40  <aj> morcos: RPC can give an error back :)
166 2016-01-05T14:27:58  <maaku> morcos: it's another number that could be just as wrong, with either too high a fee (users get angry) or too low a fee (users get stuck)
167 2016-01-05T14:28:23  <morcos> what we've done is moved from a regime where we always hard code a default fee to a regime where we use a fee by fee estimation the vast majority of the time, except when its impossible to
168 2016-01-05T14:28:30  <morcos> and then we should have a sane default
169 2016-01-05T14:28:30  <maaku> better to just give an error, or in the GUI a window to enter a manual fee
170 2016-01-05T14:28:44  <morcos> you guys, fee estimation is not that perfect
171 2016-01-05T14:29:13  <morcos> you can't just depend on it always giving you the right answer, bitcoind/-qt needs to be workable if feeestimation isn't working
172 2016-01-05T14:30:02  <morcos> for instance what you are describing would be impossible on regtest or testnet which often don't have any estimates
173 2016-01-05T14:30:45  <aj> morcos: it would make sense being able to explicitly set a fee for the transaction (whether GUI or RPC/cmdline), but otherwise having fee estimation always working would be a better goal...
174 2016-01-05T14:31:03  <morcos> its a much bigger change to eliminate fall back to default (and a worse change).  i'm just trying to make it fall back to a more sane default.  and i think its better to do that with a new variable, rather than misuse mintxfee
175 2016-01-05T14:31:25  <morcos> aj: that is the goal
176 2016-01-05T14:31:48  <morcos> but if its not working some small % of the time, then what should you do?
177 2016-01-05T14:32:26  <MarcoFalke> morcos, can you elaborate again what the difference in UX is in regard to defaulttxfeeifnoestimate vs mintxfee
178 2016-01-05T14:32:30  <MarcoFalke> What is "misuse"?
179 2016-01-05T14:33:27  <MarcoFalke> The default is: "Estimate the fee to get into <n> blocks, where <n> is user set."
180 2016-01-05T14:33:34  <morcos> MarcoFalke: So in the case of a user trying to use fee estimation.  Right now mintxfee does not apply if fee estimation returns an answer, but if fee estimation can not return an answer for the target you are asking about, it gives you the max(any answer it did get, mintxfee).
181 2016-01-05T14:33:34  <aj> morcos: if i expect something to be working 100% of the time, then i want an error when it's not, not silently different behaviour. (ymmv)
182 2016-01-05T14:34:35  <morcos> MarcoFalke: I think the correct behavior for a user trying to use fee estimation is .  If you cna't get a proper answer fee = max(answer you got, defaultfeeifnoestimate).   And in all cases, the fee is maxed with mintxfee.
183 2016-01-05T14:35:02  <morcos> MarcoFalke: So there are 2 effective changes.  It'll fall back to a more sane default and if you want to set a floor for feeestimation generated txs, you can do so now.
184 2016-01-05T14:36:42  <morcos> aj: So what would you like fee estimation to do if you say "estimatefee 1" and it can only give you an answer for "estimatefee 25".  Silently let you send a tx expected to be confirmed in 25 blocks.
185 2016-01-05T14:37:06  <aj> morcos: i would like an error saying "best estimate is for 25 blocks"
186 2016-01-05T14:38:08  <aj> morcos: ie an error -- no transaction sent. "manual" intervention required. (well, if it's RPC it could be automated by some other script, whatever)
187 2016-01-05T14:38:45  <morcos> aj: there is currently no way to set the txconfirmtarget via rpc, so then you would get stuck in a position where you can't send any txs period
188 2016-01-05T14:39:51  <MarcoFalke> agree that the rpc error is no solution
189 2016-01-05T14:40:12  <morcos> sendtoaddress() is meant to just send the damn tx and do something smart for me
190 2016-01-05T14:40:14  <aj> morcos: (i'd rather have txconfirmtarget set as an optional parameter to sendtoaddress)
191 2016-01-05T14:40:51  <morcos> aj: i'm trying to patch up 0.12.  we can't rework the entire way fee estimation and wallet txs work for that
192 2016-01-05T14:41:10  <MarcoFalke> morcos, You were right that GetRequiredFee() is ignored. (I somehow had it differently in mind)
193 2016-01-05T14:41:19  <morcos> i'm just trying to avoid a situation where people routinely send txs of too low fee when they just start their nodes up
194 2016-01-05T14:41:20  <MarcoFalke> So you'd disagree to move nFeeNeeded = std::max(nFeeNeeded, GetRequiredFee(nTxBytes)); furher down
195 2016-01-05T14:41:54  <MarcoFalke> (right in the line before return?)
196 2016-01-05T14:41:59  <morcos> MarcoFalke: I do think we should do that as long as we're not also trying to make mintxfee a sane default.  as long as its a min, then we should do that.  but we need a saner default
197 2016-01-05T14:42:07  <aj> morcos: well, i'm talking about what i /want/, not necessarily what's easy/possible :)
198 2016-01-05T14:42:27  <morcos> aj: well can you help us try and figure out what we should do for 0.12 instead
199 2016-01-05T14:45:43  <morcos> MarcoFalke: I don't think it ever respect mintxfee in the event an estimate was given.  (and technically it doesn't need to respect minrelaytxfee b/c its not possible to have an estimate less than that).   But yes, lets make it respect both via GetRequiredFee, but then give people a way to have a sane default, which doesn't require that all their fees be at least that default
200 2016-01-05T14:46:44  <morcos> These will be very minor changes.  Move the GetRequiredFee and add a new commandline argument.  It almost doesn't really matter if its not communicated very well b/c translations are closed or whatever.  It's a default that only applies rarely.
201 2016-01-05T14:50:18  <GitHub110> [bitcoin] MarcoFalke opened pull request #7295: [WIP] Obey mintxfee on txconfirmtarget, Bump mintxfee (master...Mf1601-wallet-mintxfee) https://github.com/bitcoin/bitcoin/pull/7295
202 2016-01-05T14:50:22  <MarcoFalke> this is what I thought.
203 2016-01-05T14:50:50  <MarcoFalke> Haven't reviewed that closely, so it may be fatally wrong or not even compile
204 2016-01-05T14:51:14  <morcos> MarcoFalke: yeah but thats not what i think we shoudl do
205 2016-01-05T14:51:39  <morcos> THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly
206 2016-01-05T14:51:49  <morcos> I think the minimum should literally be the minimyum you ever want to send
207 2016-01-05T14:51:57  <morcos> I would recommend not raising the default of that
208 2016-01-05T14:52:12  <morcos> But the fallback value if you can't get an estimate should be larger
209 2016-01-05T14:53:46  <morcos> so your change to wallet.cpp stays, but we change line 2213 to nFeeNeeded = std::max(nFeeNeeded, GetArg("-fallbackfee", DEFAULT_FALLBACK_FEE));   or -defaultfeeifnoestimate or whatever you want to call it
210 2016-01-05T14:54:14  <morcos> line 2213 only gets execute if fee estimation is indicating to you its answer is unreliable
211 2016-01-05T14:54:37  <morcos> but your addition at 2221 should stay, to respect the desired minimum
212 2016-01-05T14:56:41  <MarcoFalke> I don't really like yet another fee arg, but what you say makes sense
213 2016-01-05T14:56:53  <MarcoFalke> There would be no translations for 0.12 though
214 2016-01-05T14:57:08  <morcos> In order to solve the pulling numbers out of a hat concern we could even just have a formula for the -fallbackfee at every release.  -fallbackfee = estimatefee(2) which a 1 month decay instead of a 2.5 day decay calculated shortly before release
215 2016-01-05T14:57:58  <morcos> MarcoFalke: yeah, but i think the translation thing is ok, b/c users shouldn't really need to worry about setting that.
216 2016-01-05T14:58:33  <Luke-Jr> Frankly, we should probably replace the fee options with a %s so the same translation can be used..
217 2016-01-05T14:58:43  <morcos> or maybe makes more sense -fallbackfee = estimatefee(10) with a 99% threshold and a 1 month decay
218 2016-01-05T14:58:45  <Luke-Jr> (I might have a PR to do that, not sure)
219 2016-01-05T14:59:14  <Luke-Jr> morcos: 10? What is that, blocks? Way too aggressive for a fallback..
220 2016-01-05T14:59:22  <morcos> too fast you mean?
221 2016-01-05T14:59:26  <Luke-Jr> yes
222 2016-01-05T14:59:32  <Luke-Jr> the worst case scenario should allow for up to a month time
223 2016-01-05T14:59:46  <morcos> its not a minimum, its what gets used if fee estimation is broken
224 2016-01-05T14:59:57  <morcos> s/broken/not ready yet/
225 2016-01-05T15:00:00  <MarcoFalke> not a month
226 2016-01-05T15:00:02  <Luke-Jr> if the fee estimation is broken, it can't be block-based..
227 2016-01-05T15:00:06  <MarcoFalke> a day at most
228 2016-01-05T15:00:12  <Luke-Jr> MarcoFalke: a week at least
229 2016-01-05T15:00:12  <morcos> but more importantly cant' give you an estimate for the # youre asking for
230 2016-01-05T15:00:22  <morcos> Luke-Jr: anything more than 3 days doesnt' exist right now
231 2016-01-05T15:00:26  <jtimon> morcos how is defaulting to -mintxfee something ridiculous?
232 2016-01-05T15:00:39  <morcos> but i 100% agree we should be able to predict longer term fees
233 2016-01-05T15:00:41  <aj> MarcoFalke: limiting below at GetRequiredFee should be before limiting above at maxTxFee -- if you typo and set the RequiredFee crazy high, better to have it capped than not
234 2016-01-05T15:00:49  <Luke-Jr> morcos: but you're talking about a scenario where we *don't have estimates at all*, right?
235 2016-01-05T15:00:51  <morcos> i have code to push fee estimation out to a week but i never PR'ed
236 2016-01-05T15:01:02  <Luke-Jr> morcos: oooh, sounds useful
237 2016-01-05T15:01:03  <morcos> Luke-Jr: unfortunately i'm talking about both
238 2016-01-05T15:01:07  <MarcoFalke> jtimon, mintxfee=5000. THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly per morcos
239 2016-01-05T15:01:13  <Luke-Jr> morcos: does it by chance work with non-24/7 nodes? :D
240 2016-01-05T15:01:31  <morcos> Luke-Jr: We can distinguish between them though if we want to do different things in those cases
241 2016-01-05T15:01:49  <morcos> jtimon: because -mintxfee is often too low to be of any use whatsoever = stuck tx
242 2016-01-05T15:01:55  <Luke-Jr> gotta run..
243 2016-01-05T15:02:01  <morcos> the default if you can't get an estimate should not be stuck tx
244 2016-01-05T15:06:37  <jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of min(-mintxfee, estimatedFee) to solve your concern?
245 2016-01-05T15:06:44  <jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of max(-mintxfee, estimatedFee) to solve your concern?
246 2016-01-05T15:07:12  <jtimon> morcos: but -mintxfee is configurable
247 2016-01-05T15:08:09  <morcos> jtimon: min implies its the lowest you ever want to send regardless of what fee estimates tell you or what you accidentally choose with settxfee
248 2016-01-05T15:08:26  <morcos> not what you want the fall back value to be
249 2016-01-05T15:08:35  <morcos> it doesnt make sense to fall back to the lowest possible
250 2016-01-05T15:09:01  <morcos> anyway, i have to run now, now that i've gotten some of the bickering out of the way on irc, i'll submit a PR later this afternoon
251 2016-01-05T15:09:25  <jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, max(-defaulttxfeeifnoestimate, estimatedFee)) ?
252 2016-01-05T15:09:34  <jtimon> sorry, again
253 2016-01-05T15:09:46  <jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ?
254 2016-01-05T15:11:00  <jtimon> I still think min(-mintxfee, estimatedFee) should is good enough though
255 2016-01-05T15:11:59  <MarcoFalke> good enough for 0.12.
256 2016-01-05T15:12:24  <MarcoFalke> We may want to do the other suggestion for 0.13 if it can't get into 12
257 2016-01-05T15:12:56  <jtimon> yep, we can move to max(-newoption, min(-mintxfee, estimatedFee)) later
258 2016-01-05T15:14:23  <jtimon> I mean, I just wanted to understand, I surredered on relay policy/acceptToMemoryPool already...
259 2016-01-05T15:53:50  <morcos> jtimon: what i want is max(estimatefee, -mintxfee)   where estimatefee = (if tgt found: estimatefee , else: max(estimatefee, newoption))
260 2016-01-05T15:54:31  <morcos> currently the fee = (if tgt found: estimatefee, else: max(estimatefee, -mintxfee))
261 2016-01-05T15:54:40  <morcos> i will submit PR as soon as i get a chance
262 2016-01-05T15:55:46  <jtimon> well if estimatefee = found ? estimatedfee : maxint, then my "max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee))" description is equivalent
263 2016-01-05T15:56:16  <jtimon> but thank you for confirming that I understood you
264 2016-01-05T15:58:35  <morcos> your min is not correct though, there is never a min
265 2016-01-05T15:58:56  <jtimon> min(1, 2) == 1 ?
266 2016-01-05T15:59:22  <morcos> why don't you just let me write it first. :)
267 2016-01-05T15:59:37  <jtimon> min(-defaulttxfeeifnoestimate, maxint) == -defaulttxfeeifnoestimate
268 2016-01-05T16:00:40  <morcos> oh, i understand what you meant now
269 2016-01-05T16:01:06  <morcos> no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target
270 2016-01-05T16:01:54  <jtimon> morcos: I just wanted to understand what you were saying, thanks. I don't plan to code, review or otherwise collaborate in anything related to relay policy/mempool acceptance in the near future, I'll just restore my previous work on jt-0.12
271 2016-01-05T16:02:37  <jtimon> "no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target" the 0 can be changed to maxint, of course, but anyway it was just a way to say it
272 2016-01-05T16:12:11  *** Cory has quit IRC
273 2016-01-05T16:14:22  *** Pasha has joined #bitcoin-core-dev
274 2016-01-05T16:21:15  *** Pasha is now known as Cory
275 2016-01-05T16:25:36  *** cryptopeddler has quit IRC
276 2016-01-05T16:27:40  *** Cory has quit IRC
277 2016-01-05T16:29:34  *** Pasha has joined #bitcoin-core-dev
278 2016-01-05T16:30:09  *** cryptopeddler has joined #bitcoin-core-dev
279 2016-01-05T16:36:28  *** Pasha is now known as Cory
280 2016-01-05T16:39:26  *** Yoghur114 has joined #bitcoin-core-dev
281 2016-01-05T16:54:14  *** laurentmt has joined #bitcoin-core-dev
282 2016-01-05T16:58:15  *** Cory has quit IRC
283 2016-01-05T16:58:56  *** BashCo has quit IRC
284 2016-01-05T17:06:26  <GitHub115> [bitcoin] morcos opened pull request #7296: Add sane fallback for fee estimation (master...fallbackfee) https://github.com/bitcoin/bitcoin/pull/7296
285 2016-01-05T17:07:33  <morcos> MarcoFalke:  OK I created my PR.  I actually changed the logic a little from what I suggested.  This will not use the fallback fee if fee estimation has given you an estimate for a slightly longer confirm target.  It only uses the fallback fee if it can't give you any estimates at all.
286 2016-01-05T17:07:57  <morcos> I think this is safest, and runs least risk of having the fallbackfee accidentally screw people by being too high
287 2016-01-05T17:09:03  <morcos> wumpus:  I know you HATE defaults, especially ones that have to be changed over time.  But I see no way around this if you want to allow txs before fee estimates are warned up.  I suppose as aj suggests we could come up with a way to prevent that, but its a more invasive change.
288 2016-01-05T17:10:42  <morcos> I think we should come up with a rule of thumb using historical fee estimates for adjusting this default per major release.  I think 20000 satoshis/KB is about what you would get for estimatefee(4) over a longer time horizon.  But honestly I don't care what we use there, as long as it makes more sense than 1000.   Anything between 5K-50K would be ok by me.
289 2016-01-05T17:11:41  <morcos> rusty: result of our discussion last night  ^^^   Thanks for bringing it up!
290 2016-01-05T17:14:38  <GitHub180> [bitcoin] MarcoFalke closed pull request #7295: [WIP] Obey mintxfee on txconfirmtarget, Bump mintxfee (master...Mf1601-wallet-mintxfee) https://github.com/bitcoin/bitcoin/pull/7295
291 2016-01-05T17:16:10  *** BashCo has joined #bitcoin-core-dev
292 2016-01-05T17:18:19  *** Cory has joined #bitcoin-core-dev
293 2016-01-05T17:19:06  *** laurentmt has quit IRC
294 2016-01-05T17:30:41  *** Quent1 has quit IRC
295 2016-01-05T17:31:09  *** Quent1 has joined #bitcoin-core-dev
296 2016-01-05T17:40:40  <jtimon> morcos, so now that you have changed the estimation to give an estimation or 0, what's wrong with chaning the zero to maxint and doing min(estimatefee, -mintxfee) without introducing any new parameter or default instead of max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ? (not proposing that, again, just want to understand the need for a new runtime option)
297 2016-01-05T17:42:42  <jtimon> (apart from maybe having to update the documentation for -mintxfee)
298 2016-01-05T17:44:31  <morcos> i agree it could work fine with maxint, that seems unrelated to this change, gavinandresen chose the 0 error value.  but i don't want to use -mintxfee because i want the fallback value to be a higher number.  if you dont' have estimates you shouldn't fall back to the lowest possible value
299 2016-01-05T17:44:47  <jtimon> or more in words, if there's no estimate, you're doing max(-mintxfee, -defaulttxfeeifnoestimate)), why not just -mintxfee?
300 2016-01-05T17:45:28  <jtimon> "because i want the fallback value to be a higher number" but people can do -mintxfee=higher_number, can't they?
301 2016-01-05T17:46:15  <jtimon> "the lowest possible value" well, that's just part of the documentation of -mintxfee (assuming it is)
302 2016-01-05T17:46:41  <jtimon> documentation is easy to change
303 2016-01-05T17:46:59  *** treehug88 has joined #bitcoin-core-dev
304 2016-01-05T17:47:07  <morcos> jtimon: yes they can, and that was originally what i wanted to do, but then it occurred to me that it makes sense to have 2 values.  one of which is the minimum fee you ever want to pay, regardless of what you set with settxfee and regardless of what fee estimates tells you
305 2016-01-05T17:47:09  <jtimon> I guess what you don't want is being able to produce that are lower than -mintxfee, even if the estimator says it will be fine
306 2016-01-05T17:47:25  <morcos> and the other is what you want to pay by default if there are no fee estimates and you're trying to reduce them
307 2016-01-05T17:47:57  <jtimon> I guess then my question is, why is that "mininmum fee regardless of what the estimator says" necessary?
308 2016-01-05T17:48:17  *** brg444 has joined #bitcoin-core-dev
309 2016-01-05T17:48:20  <jtimon> isn't a default for when the estimator doesn't work enough?
310 2016-01-05T17:48:20  <morcos> it's probably not, but people may already use it
311 2016-01-05T17:48:32  <morcos> they also may use it if they are not using the estimator
312 2016-01-05T17:48:51  <morcos> it just seemed to big a change to completely remove what people think mintxfee does
313 2016-01-05T17:49:07  <jtimon> to the second point, if they don't use the estimator they would just use the single default
314 2016-01-05T17:49:46  <morcos> imagine someone has some external program that does their own fee estimation.  And they use settxfee to tell bitcoin core what fee to pay based on that
315 2016-01-05T17:50:01  <morcos> they might want to be able to set a minimum, sure they could implement the minimum logic themselves
316 2016-01-05T17:50:11  <morcos> but it might be a change from how they are currently using it
317 2016-01-05T17:50:26  <jtimon> that's what I meant by adapting the documentation, right now it says "Fees (in %s/kB) smaller than this are considered zero fee for transaction creation (default: %s)"
318 2016-01-05T17:50:36  <morcos> yeah, well thats just completely wrong
319 2016-01-05T17:50:46  <morcos> but i'm not messing around with any priority related stuff, its too annoying
320 2016-01-05T17:51:06  <jtimon> if people think that what it does is "the minimum fee regardless of what the estimator says" we should change it one way or another
321 2016-01-05T17:51:27  <jtimon> who's talking about priority?
322 2016-01-05T17:51:39  <morcos> That's what "considered zero fee" means
323 2016-01-05T17:51:43  <morcos> evaluated based on priority
324 2016-01-05T17:52:28  <morcos> There is one more reason to keep a distinct mintxfee
325 2016-01-05T17:52:30  <jtimon> I see, I actually believe that was just copied from minrelaytxfee...
326 2016-01-05T17:52:55  *** Cory has quit IRC
327 2016-01-05T17:53:03  <jtimon> but -mintxfee has nothing to do with priority (I may be wrong here)
328 2016-01-05T17:53:11  <morcos> In the future minrelaytxfee makes more sense as the relay cost.  So if you want to RBF or evict, thats the increment you need to pay
329 2016-01-05T17:53:44  <morcos> But its not obvious that you want to be able to first place a tx for only relay cost, there may be a different mintxfee that is required
330 2016-01-05T17:54:25  <morcos> Anyway, i'm just trying not to get caught up in the whole mess of how people want to use mintxfee.  I don't know what peole use if for, I know Marco said he used it as a safety mechanism
331 2016-01-05T17:54:29  <jtimon> I still don't see why two command line options (not counting minrelaytxfee) are needed
332 2016-01-05T17:54:39  <morcos> look at it as 3
333 2016-01-05T17:54:43  <morcos> min, default, max
334 2016-01-05T17:55:10  <jtimon> well, if we want to "fix mintxfee", maybe knowing more about "how people use it" would be interesting
335 2016-01-05T17:55:34  <morcos> i don't wnat to fix mintxfee.  i'm not changning it.  i want to give fee estimation a sane fall back value
336 2016-01-05T17:55:49  <morcos> an mintxfee does not seem to fit the bill, unless i change it
337 2016-01-05T17:56:06  <jtimon> "unless i change it" that's entirely my point
338 2016-01-05T17:56:42  <jtimon> but I didn't got your point about "min, default, max" either
339 2016-01-05T17:56:51  <jtimon> each parameter has its own default
340 2016-01-05T17:57:16  <jtimon> and I don't see where you are using the max
341 2016-01-05T17:57:52  <jtimon> anyway, never mind, I guess I will understand it in time
342 2016-01-05T17:58:36  <jtimon> you guys do whatever you want with this
343 2016-01-05T17:58:37  <morcos> i'm saying the user already has options to set: the min possible fee they want to send,  the fee they will send if fee estimation doesn't work,   the max possible fee they will send
344 2016-01-05T17:58:48  <morcos> s/has/will have/
345 2016-01-05T17:59:35  <jtimon> oh, ok, when you talk about "will have things" as if they were already in, it is very confusing to me
346 2016-01-05T18:00:13  <jtimon> oh, I guess the max is the absurd fee
347 2016-01-05T18:01:11  <jtimon> still, I don't see the point with the default, if you don't have estimation just use the min the user has set
348 2016-01-05T18:02:46  <jtimon> to me this strongly smells to "users are stupid so let's have more obscure runtime options with 'reasonable defaults" to make it harder for them to do stupid things"
349 2016-01-05T18:03:18  <jtimon> but is just a personal feeling, again you guys do whatever you want
350 2016-01-05T18:15:09  <GitHub152> [bitcoin] MarcoFalke opened pull request #7298: [qt] Intro: Display required space (master...Mf1601-qtDataDir) https://github.com/bitcoin/bitcoin/pull/7298
351 2016-01-05T18:15:17  <jtimon> wumpus I'm probably leaving soon, please don't answer my previous question while I'm gone, I don't have a bouncer yet
352 2016-01-05T18:31:02  <MarcoFalke> botbot.me
353 2016-01-05T18:31:31  <MarcoFalke> will archive this channel at least
354 2016-01-05T18:33:58  <jtimon> MarcoFalke: yes, but it's simpler to me to just ask again than to look through the logs, at some point during the 0.13.99 I will get the "now it's the right time" answer I'm waiting for, or I'll stop asking
355 2016-01-05T18:37:52  *** laurentmt has joined #bitcoin-core-dev
356 2016-01-05T18:38:01  *** laurentmt has quit IRC
357 2016-01-05T18:45:39  <morcos> sipa: i wasn't around when the work on handling evicted txs for 0.12 went in.  but what did we decide to do if you have a tx that gets evicted b/c of too low fee.
358 2016-01-05T18:45:45  <morcos> are those outputs then just stuck forever?
359 2016-01-05T19:18:48  *** jtimon has quit IRC
360 2016-01-05T19:26:01  <morcos> wumpus: sipa: i think we still need another fix for evicted txs
361 2016-01-05T19:26:18  <morcos> for 0.12
362 2016-01-05T19:26:44  <morcos> sipa's change made it so that if a tx is evicted you will not automatically respend the inputs, thats all fine and good
363 2016-01-05T19:26:51  <morcos> but there has to be SOME way to respend them
364 2016-01-05T19:27:13  <morcos> prior to this change, if you had a permanently stuck tx (say you just relayed it with way too low a fee or it got lost and its only in your mempool or whatever)
365 2016-01-05T19:27:44  <morcos> if you restarted your node with a higher min relay fee, then it wouldn't make it in your mempool and by the prior logic would have been conflicted and respendable
366 2016-01-05T19:27:54  <morcos> now its just permanently unspendable
367 2016-01-05T19:29:01  <morcos> ideally we'd eventually RBF these txs or soemthing, but i dont' even know what that means if its not in your mempool
368 2016-01-05T19:29:19  <morcos> but i think we need a way to manually be able to respend these inputs
369 2016-01-05T19:29:36  <morcos> we had talked back in November about adding a "forget" option, i guess that never happened?
370 2016-01-05T19:32:44  <sipa> morcos: they're considered respendable if there is a conflict in the chaim
371 2016-01-05T19:32:47  <sipa> *chain
372 2016-01-05T19:37:41  *** trippysalmon has joined #bitcoin-core-dev
373 2016-01-05T19:41:54  <morcos> sipa: ?  but how would there be a conflict in the chain
374 2016-01-05T19:45:12  <sipa> right, we also need a way to mark an old non-confirming transaction as respendable
375 2016-01-05T19:47:25  <morcos> yep, its possible to manually construct and submit a double spend with createrawtransaction and that'll be accepted b/c the original is no longer in the mempool
376 2016-01-05T19:47:34  <morcos> but thats fairly tedious
377 2016-01-05T19:48:51  <sipa> agree
378 2016-01-05T19:50:35  *** jannes has joined #bitcoin-core-dev
379 2016-01-05T19:51:04  <morcos> should i start by taking a look at adding a forgettransaction or something rpc call and then we can worry later about the gui implementation.  i'll have to dive into the code to figure out how to represent its respendableness, unless you already know how you'd like it done
380 2016-01-05T19:51:53  <morcos> maybe marktransactionrespendable  (which can only apply to wallet txs that arent' in your memory pool)
381 2016-01-05T19:52:26  <sipa> i think we can just mark a tx as conflicting with the genesis block or something :)
382 2016-01-05T20:04:45  *** belcher has joined #bitcoin-core-dev
383 2016-01-05T20:05:07  *** trippysalmon has quit IRC
384 2016-01-05T20:07:10  <gijensen> morcos, please removing wallet transactions that aren't in the mempool is on my to-do list
385 2016-01-05T20:10:28  *** Cory has joined #bitcoin-core-dev
386 2016-01-05T20:37:48  <GitHub152> [bitcoin] MarcoFalke opened pull request #7300: [trivial] Add missing copyright headers (master...Mf1601-copyrightheaders) https://github.com/bitcoin/bitcoin/pull/7300
387 2016-01-05T20:44:28  *** Squidicuz has quit IRC
388 2016-01-05T20:45:43  *** Squidicuz has joined #bitcoin-core-dev
389 2016-01-05T21:11:09  *** MarcoFalke has quit IRC
390 2016-01-05T21:29:16  *** randy-waterhouse has joined #bitcoin-core-dev
391 2016-01-05T21:30:25  *** MarcoFalke has joined #bitcoin-core-dev
392 2016-01-05T21:46:32  *** Guest62894 has joined #bitcoin-core-dev
393 2016-01-05T21:47:47  *** jannes has quit IRC
394 2016-01-05T22:08:29  *** MarcoFalke has quit IRC
395 2016-01-05T22:09:33  *** MarcoFalke has joined #bitcoin-core-dev
396 2016-01-05T22:10:24  *** treehug88 has quit IRC
397 2016-01-05T22:22:57  <GitHub106> [bitcoin] theuni opened pull request #7302: C++11 build/runtime fixes (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7302
398 2016-01-05T22:28:52  *** murch has quit IRC
399 2016-01-05T22:49:01  *** brg444 has quit IRC
400 2016-01-05T22:58:54  *** MarcoFalke has quit IRC
401 2016-01-05T23:03:13  *** MarcoFalke has joined #bitcoin-core-dev
402 2016-01-05T23:04:39  *** Guyver2 has quit IRC
403 2016-01-05T23:37:37  <morcos> sipa: I noticed an order of magnitude slow down in running smartfees.py .  I tracked it down to your tricklenode->poisson change.  I guess its not unexpected that it would cause a big slowdown on any rpc tests that require mempools to be synced?
404 2016-01-05T23:39:25  <morcos> I'm not sure if its really a problem.  presumably its only in regtests that you would care about something like this.  but smartfees.py went from 40sec to 250sec
405 2016-01-05T23:53:39  *** arowser has quit IRC
406 2016-01-05T23:54:12  *** arowser has joined #bitcoin-core-dev