12015-12-01T00:03:40  <phantomcircuit> Luke-Jr, ha
  22015-12-01T00:17:25  *** zookolaptop has joined #bitcoin-core-dev
  32015-12-01T00:27:47  *** cocoBTC has quit IRC
  42015-12-01T00:49:06  *** dcousens has joined #bitcoin-core-dev
  52015-12-01T01:24:34  *** Ylbam has quit IRC
  62015-12-01T01:26:40  <morcos> jtimon: surely you don't need to make estimateSmartFee take a mempoolsize argument?  as in that branch
  72015-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)
  82015-12-01T01:52:50  <morcos> one sec and i'll show you what i had in mind
  92015-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
 102015-12-01T01:53:53  <jtimon> just got distracted with something else
 112015-12-01T01:55:41  <jtimon> morcos: updated #7115 focus on the first commit and then nack the other two if you want
 122015-12-01T01:55:49  <morcos> https://github.com/bitcoin/bitcoin/compare/master...morcos:trackTrimSize
 132015-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
 142015-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
 152015-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
 162015-12-01T01:58:06  <jtimon> morcos: do you have plans for dynamic trimming beyond testing?
 172015-12-01T01:58:53  <jtimon> I really don't understand that or what it even has to do with our discussion
 182015-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
 192015-12-01T01:59:12  <jtimon> IBD?
 202015-12-01T01:59:19  <morcos> i looked at your pull, i don't like adding a global argument to estimateSmartFee
 212015-12-01T01:59:38  <morcos> yes, during IBD you could allocate less size to the mempool and more to your cache
 222015-12-01T01:59:55  <morcos> or during initial sync if you're not caught up or whatever
 232015-12-01T02:00:00  <morcos> doesn't have to technically be IBD
 242015-12-01T02:00:19  <jtimon> in the future that can be fixed if getminfee moves to the estimator
 252015-12-01T02:00:40  <jtimon> it could be an attribute in the estimator
 262015-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.
 272015-12-01T02:01:01  <jtimon> what is IDB?
 282015-12-01T02:01:06  <morcos> initial block download
 292015-12-01T02:01:15  <jtimon> thanks
 302015-12-01T02:01:44  <jtimon> so, wait
 312015-12-01T02:02:15  <jtimon> you want to have a different limit for IBD but a constant one for the rest right?
 322015-12-01T02:02:25  <morcos> i don't want to do any of that right now
 332015-12-01T02:02:36  <morcos> i would like to fix it so GetMinFee doesn' tneed an argument
 342015-12-01T02:02:48  <morcos> but i don't think the proper value for it to use is your command line argument
 352015-12-01T02:02:58  <morcos> i think the proper value for it to use is the last size the mempool was trimmed to
 362015-12-01T02:02:59  <jtimon> I want to understand your long term vision, and I would like you to understand mine
 372015-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
 382015-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?
 392015-12-01T02:05:21  <morcos> jtimon: a global what?
 402015-12-01T02:05:26  <morcos> this is where we are miscommunicating
 412015-12-01T02:05:33  <jtimon> main, mempool or policy/fees?
 422015-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
 432015-12-01T02:06:01  <jtimon> argsMap is the global we're currently using for this command line param
 442015-12-01T02:06:39  <jtimon> we should use an extern global initialized in init.cpp like everybody else
 452015-12-01T02:06:51  <morcos> but i think you're missing my point
 462015-12-01T02:07:01  <morcos> if TrimToSize still takes an argument, which I think it should
 472015-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
 482015-12-01T02:07:49  <jtimon> should TrimToSize use a different value 2 different times for a given comman-line call?
 492015-12-01T02:09:28  <morcos> lets step back for a second, what is your objection to doing it the way i'm proposing?
 502015-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?
 512015-12-01T02:10:04  <morcos> because thats literally what the logic is, what was the mempool trimmed to
 522015-12-01T02:10:17  <morcos> and now how far below that number are we
 532015-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
 542015-12-01T02:11:32  <morcos> i don't really think i have anything else to say thats not repeating myself
 552015-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
 562015-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?
 572015-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
 582015-12-01T02:13:58  <jtimon> I could make them one if you prefer that
 592015-12-01T02:14:08  <jtimon> trvially I must add
 602015-12-01T02:14:29  <morcos> i think it would be hard to get the unit tests to work with no argument
 612015-12-01T02:14:37  <jtimon> the same goes for getminfee, again, what's the difference?
 622015-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
 632015-12-01T02:15:10  <jtimon> morcos we're using other globals in the tests
 642015-12-01T02:15:25  <jtimon> for example argsMap
 652015-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
 662015-12-01T02:15:35  <jtimon> like we're currently using
 672015-12-01T02:15:55  <morcos> the unit tests call TrimToSize with different arguments within the same tests  or GetMinFee or whatever
 682015-12-01T02:15:59  <morcos> both probably
 692015-12-01T02:16:01  <jtimon> calling GetArg in 11 places instead of one is just a style choice
 702015-12-01T02:16:22  <jtimon> would you even oppose to a macro?
 712015-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.
 722015-12-01T02:16:59  <morcos> i've tried to give you some reasonable compromises that i would support
 732015-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
 742015-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
 752015-12-01T02:17:45  <phantomcircuit> jtimon, theoretically we could fix GetArg but we cant if noboey uses it
 762015-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"
 772015-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
 782015-12-01T02:18:48  <morcos> i have not seen any commits that i can agree with
 792015-12-01T02:19:05  <jtimon> phantomcircuit: ?? init.cpp uses it plenty
 802015-12-01T02:19:47  <phantomcircuit> jtimon, GetArg isn't thread safe, so we cant change settings outside of init.cpp
 812015-12-01T02:20:06  <phantomcircuit> if we aren't using GetArg it becomes a hastle to find and change settings all over the place
 822015-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"
 832015-12-01T02:21:44  <jtimon> sorry https://github.com/jtimon/bitcoin/commit/3c30cea7245a2fd44bbd9cf8844c6730855f63e4
 842015-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
 852015-12-01T02:22:55  *** calibre720 has joined #bitcoin-core-dev
 862015-12-01T02:22:58  <morcos> so lets just let it go.
 872015-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?
 882015-12-01T02:23:54  <morcos> i pasted it to you above!!!
 892015-12-01T02:24:05  <jtimon> callers should call the estimator directly without calling the mempool as a facade, but that's another topic entirily
 902015-12-01T02:24:12  <morcos> https://github.com/bitcoin/bitcoin/compare/master...morcos:trackTrimSize
 912015-12-01T02:24:46  <morcos> then you can fix the circular dependency on top of that.
 922015-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?
 932015-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.
 942015-12-01T02:28:00  <jtimon> btw, I asked many times without anwer, do you agree that getminfee belongs in policy/fees ?
 952015-12-01T02:28:24  <jtimon> morcos: ok, whenever you have time to answer questions come back to me
 962015-12-01T02:29:44  *** zookolaptop has quit IRC
 972015-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
 982015-12-01T02:35:59  *** calibre720 has quit IRC
 992015-12-01T03:00:53  *** pmienk_ has quit IRC
1002015-12-01T03:23:14  *** afk11 has joined #bitcoin-core-dev
1012015-12-01T03:50:57  *** jgarzik_ has quit IRC
1022015-12-01T03:57:49  *** guest234234 has joined #bitcoin-core-dev
1032015-12-01T04:12:00  *** afk11 has quit IRC
1042015-12-01T04:16:46  *** dcousens has quit IRC
1052015-12-01T04:29:02  *** Dyanisus has quit IRC
1062015-12-01T04:34:28  *** mempool has joined #bitcoin-core-dev
1072015-12-01T04:42:38  *** jgarzik has joined #bitcoin-core-dev
1082015-12-01T04:42:38  *** jgarzik has joined #bitcoin-core-dev
1092015-12-01T05:25:41  *** mempool has quit IRC
1102015-12-01T06:04:50  *** Madars has quit IRC
1112015-12-01T06:05:40  *** Madars has joined #bitcoin-core-dev
1122015-12-01T06:30:50  *** CodeShark_ has joined #bitcoin-core-dev
1132015-12-01T06:36:58  *** randy-waterhouse has quit IRC
1142015-12-01T06:42:23  *** tulip has quit IRC
1152015-12-01T06:59:09  <GitHub18> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/438ee59839ad...c143c499c85b
1162015-12-01T06:59:10  <GitHub18> bitcoin/master 996d311 Nick: [RPC] Add transaction size to JSON output...
1172015-12-01T06:59:10  <GitHub18> bitcoin/master c143c49 Gregory Maxwell: Merge pull request #7072...
1182015-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
1192015-12-01T07:04:16  *** randy-waterhouse has joined #bitcoin-core-dev
1202015-12-01T07:34:11  *** paveljanik has joined #bitcoin-core-dev
1212015-12-01T07:34:11  *** paveljanik has joined #bitcoin-core-dev
1222015-12-01T07:53:20  *** PaulCapestany has quit IRC
1232015-12-01T07:54:54  *** PaulCapestany has joined #bitcoin-core-dev
1242015-12-01T07:58:45  *** Ylbam has joined #bitcoin-core-dev
1252015-12-01T08:00:07  *** pmienk has joined #bitcoin-core-dev
1262015-12-01T08:03:04  *** Dyanisus has joined #bitcoin-core-dev
1272015-12-01T08:03:22  <GitHub104> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c143c499c85b...1b5118bfa0d9
1282015-12-01T08:03:23  <GitHub104> bitcoin/master 5029698 kazcw: prevent peer flooding request queue for an inv...
1292015-12-01T08:03:23  <GitHub104> bitcoin/master ebb25f4 Gregory Maxwell: Limit setAskFor and retire requested entries only when a getdata returns....
1302015-12-01T08:03:23  <GitHub104> bitcoin/master 1b5118b Wladimir J. van der Laan: Merge pull request #7079...
1312015-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
1322015-12-01T08:22:29  <GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b5118bfa0d9...30c2d8c635c4
1332015-12-01T08:22:30  <GitHub170> bitcoin/master 9ac63d6 Pieter Wuille: Keep track of explicit wallet conflicts instead of using mempool
1342015-12-01T08:22:30  <GitHub170> bitcoin/master 30c2d8c Wladimir J. van der Laan: Merge pull request #7105...
1352015-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
1362015-12-01T08:38:07  *** ghtdak has quit IRC
1372015-12-01T08:40:01  *** ghtdak has joined #bitcoin-core-dev
1382015-12-01T08:40:16  *** BashCo has quit IRC
1392015-12-01T08:42:55  *** arowser has quit IRC
1402015-12-01T08:43:20  *** arowser has joined #bitcoin-core-dev
1412015-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
1422015-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
1432015-12-01T08:56:29  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30c2d8c635c4...eb3d1b348773
1442015-12-01T08:56:29  <GitHub101> bitcoin/master fa3a38a MarcoFalke: [qa] pull-tester: Cleanup (run keypool, tidy stdout)...
1452015-12-01T08:56:29  <GitHub101> bitcoin/master eb3d1b3 Wladimir J. van der Laan: Merge pull request #7135...
1462015-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
1472015-12-01T08:59:20  <GitHub129> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb3d1b348773...9490bd71bdb4
1482015-12-01T08:59:21  <GitHub129> bitcoin/master ecc7c82 Pieter Wuille: Move fPayAtLeastCustomFee function to CC
1492015-12-01T08:59:22  <GitHub129> bitcoin/master 80462dd Jonas Schnelli: [Qt] use ASYMP_UTF8 (≈) whenever we show a fee that is not absolute
1502015-12-01T08:59:22  <GitHub129> bitcoin/master 31b508a Jonas Schnelli: [Qt] make use of the nMinimumTotalFee (absolute) in coincontrols fee calculation
1512015-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
1522015-12-01T09:01:45  <gmaxwell> wumpus: what do you need me working on for 0.12?
1532015-12-01T09:05:20  *** BashCo has joined #bitcoin-core-dev
1542015-12-01T09:16:31  *** paveljanik has quit IRC
1552015-12-01T09:22:37  <GitHub104> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9490bd71bdb4...327291af02d0
1562015-12-01T09:22:38  <GitHub104> bitcoin/master 114b581 Pieter Wuille: Prevector type
1572015-12-01T09:22:38  <GitHub104> bitcoin/master 327291a Wladimir J. van der Laan: Merge pull request #6914...
1582015-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
1592015-12-01T09:23:37  <GitHub24> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/327291af02d0...8f761e87c3fd
1602015-12-01T09:23:38  <GitHub24> bitcoin/master fad3035 MarcoFalke: [doc] Minor markdown fixes
1612015-12-01T09:23:39  <GitHub24> bitcoin/master fa22a10 MarcoFalke: contrib: Del. gitian downloader config and update gitian README
1622015-12-01T09:23:39  <GitHub24> bitcoin/master 9999cb0 MarcoFalke: Fix url in .travis.yml
1632015-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
1642015-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.
1652015-12-01T09:25:19  <wumpus> hehehehe certainly feels that way
1662015-12-01T09:28:04  <wumpus> gmaxwell: final ack on https://github.com/bitcoin/bitcoin/pull/6915 would be nice
1672015-12-01T09:28:33  <wumpus> https://github.com/bitcoin/bitcoin/pull/6898 has no ACKs at all, not even untested or concept
1682015-12-01T09:29:40  <wumpus> https://github.com/bitcoin/bitcoin/pull/6872 needs rebase, and BlueMatt has no time to do it until tomorrow
1692015-12-01T09:30:19  <wumpus> those are the three left with milestone set to 0.12
1702015-12-01T09:32:09  <BlueMatt> i mean if it needs to happen now i could
1712015-12-01T09:32:15  <BlueMatt> was just in the middle of other things
1722015-12-01T09:33:15  <gmaxwell> BlueMatt: this is wumpus closing the 0.12 window; so, not great to wait.
1732015-12-01T09:34:24  <BlueMatt> argh
1742015-12-01T09:34:30  <BlueMatt> ok....will do in the next hour or so
1752015-12-01T09:36:07  *** tulip has joined #bitcoin-core-dev
1762015-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
1772015-12-01T09:44:09  <BlueMatt> yea, working on it now
1782015-12-01T09:44:16  <BlueMatt> fixing whitespace errors and shits
1792015-12-01T09:44:30  <BlueMatt> (and actually reviewing my code...)
1802015-12-01T09:48:59  <Luke-Jr> anything for me to rebase?
1812015-12-01T09:49:48  <wumpus> Luke-Jr: you could help testing https://github.com/bitcoin/bitcoin/pull/6898 :)
1822015-12-01T09:50:36  <BlueMatt> wumpus: it seems a bit late to be pushing 6898 in?
1832015-12-01T09:50:46  <BlueMatt> though I would really very much like to see it
1842015-12-01T09:51:56  <Luke-Jr> wumpus: I'm still mid-code review on that one, and also NACK it without 6357 :/
1852015-12-01T09:52:56  <wumpus> BlueMatt: that's also my opinion
1862015-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
1872015-12-01T09:54:33  <Luke-Jr> might make more sense as a "beta" boolean parameter to getblocktemplate?
1882015-12-01T09:54:42  <Luke-Jr> no need to duplicate the RPC side
1892015-12-01T09:54:58  * wumpus hates adding parameters
1902015-12-01T09:55:17  <Luke-Jr> wumpus: GBT is explicitly designed to be nice about parameters
1912015-12-01T09:55:32  <Luke-Jr> there's an Object parameter for every GBT call, that can have any variety of keys
1922015-12-01T09:55:36  <wumpus> Luke-Jr: true, you're passing it as an object? right
1932015-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
1942015-12-01T09:56:55  <BlueMatt> phantomcircuit: ^ ?
1952015-12-01T09:56:59  <Luke-Jr> oh! I missed that one somehow
1962015-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.
1972015-12-01T09:58:10  <gmaxwell> and I don't see much use to switching them on the fly.
1982015-12-01T09:58:13  <phantomcircuit> huh what
1992015-12-01T09:58:20  <phantomcircuit> oh yeah
2002015-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"
2012015-12-01T09:58:31  <Luke-Jr> gmaxwell: switching on the fly can be automatic degrading
2022015-12-01T09:58:44  <wumpus> gmaxwell: right...
2032015-12-01T09:58:44  <phantomcircuit> wumpus, i've actually tested it and it does what it's supposed to do
2042015-12-01T09:58:56  <BlueMatt> wumpus: well i dunno if it'll break existing pool software, maybe it should be optional
2052015-12-01T09:58:57  <Luke-Jr> phantomcircuit: does it, with multiple poolservers connected?
2062015-12-01T09:59:08  <gmaxwell> Luke-Jr: yea it could but I think it's not worth the other costs.
2072015-12-01T09:59:15  <Luke-Jr> phantomcircuit: seems like it might be better to just do the empty block on longpoll connections
2082015-12-01T09:59:33  <phantomcircuit> Luke-Jr, gbt takes 500-3000ms
2092015-12-01T09:59:41  <Luke-Jr> gmaxwell: a GBT parameter with a config default would be pretty trivial
2102015-12-01T09:59:44  <phantomcircuit> returning an empty block reduces that significantly
2112015-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
2122015-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
2132015-12-01T09:59:48  <gmaxwell> wumpus: heh. I laughed at that too, but we shouldn't punish patches for being super frank. :)
2142015-12-01T09:59:58  <Luke-Jr> phantomcircuit: obviously; I don't see how that's related to my suggestion :p
2152015-12-01T10:00:21  <phantomcircuit> Luke-Jr, oh with multiple pool servers no it doesn't
2162015-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. :)
2172015-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
2182015-12-01T10:00:39  <phantomcircuit> Luke-Jr, i couldn't figure out any way to support that without adding a full round trip though
2192015-12-01T10:01:03  <phantomcircuit> BlueMatt, no it's not because that would only work if you already knew there was a new block
2202015-12-01T10:01:05  <Luke-Jr> gmaxwell: it's strictly better to have param-with-config-default rather than config-only :p
2212015-12-01T10:01:07  <phantomcircuit> and most often you dont
2222015-12-01T10:01:19  <BlueMatt> phantomcircuit: huh? dont most pools know this because p2p told them?
2232015-12-01T10:01:25  <Luke-Jr> BlueMatt: that does sound ideal actually.
2242015-12-01T10:01:29  <BlueMatt> did we merge the pull-up?
2252015-12-01T10:01:43  <BlueMatt> no, we'd need https://github.com/bitcoin/bitcoin/pull/7037 too
2262015-12-01T10:01:44  <Luke-Jr> phantomcircuit: GBT is longpolled..
2272015-12-01T10:01:53  <phantomcircuit> BlueMatt, i dont think we should make that the default setup...
2282015-12-01T10:01:59  <BlueMatt> so https://github.com/bitcoin/bitcoin/pull/7037 plus a "I want no txn" option would be my vote
2292015-12-01T10:02:12  <BlueMatt> its a small patch and fixes the issues (mostly)
2302015-12-01T10:02:16  <Luke-Jr> "I want no txn" option can be set on longpoll requests too
2312015-12-01T10:02:16  <phantomcircuit> Luke-Jr, so what?
2322015-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"
2332015-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"
2342015-12-01T10:02:56  <Luke-Jr> that's what longpolling is.
2352015-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??"
2362015-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)
2372015-12-01T10:03:21  <phantomcircuit> it actually does reduce latency btw
2382015-12-01T10:03:35  <Luke-Jr> phantomcircuit: that's stupid; you need those CPU cycles for the rest of the mining system
2392015-12-01T10:03:55  <BlueMatt> Luke-Jr: you dont have a multi-core processor?!
2402015-12-01T10:04:27  <Luke-Jr> BlueMatt: … yes, and all 16 cores are running poolservers (I think) :P
2412015-12-01T10:04:36  <BlueMatt> wtf
2422015-12-01T10:04:39  <BlueMatt> how did you manage to do that?
2432015-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.
2442015-12-01T10:04:52  <gmaxwell> BlueMatt: python.
2452015-12-01T10:04:55  <Luke-Jr> BlueMatt: multiple instances with iptables load balancing
2462015-12-01T10:05:03  <Luke-Jr> oh, yeah, Python too
2472015-12-01T10:05:04  <BlueMatt> gmaxwell: fair point
2482015-12-01T10:05:05  * Luke-Jr stabs Python
2492015-12-01T10:05:20  <GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/8f761e87c3fd...6abf6eb7bb77
2502015-12-01T10:05:21  <GitHub69> bitcoin/master 6e8b07f Suhas Daftuar: Add rounding helper function to util.py
2512015-12-01T10:05:22  <GitHub69> bitcoin/master 2b31ab9 Suhas Daftuar: Add rpc test for prioritisetransaction
2522015-12-01T10:05:22  <GitHub69> bitcoin/master 6abf6eb Wladimir J. van der Laan: Merge pull request #7063...
2532015-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
2542015-12-01T10:06:09  <phantomcircuit> and then it would only work for people using long poll
2552015-12-01T10:06:19  <phantomcircuit> which clealry has the potential to foot gun
2562015-12-01T10:06:34  <phantomcircuit> and also why the hell do you have multiple pool servers talking to a single bitcoind instance?
2572015-12-01T10:07:24  <Luke-Jr> phantomcircuit: they all talk to multipel bitcoind instances :P
2582015-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
2592015-12-01T10:08:57  <phantomcircuit> ?
2602015-12-01T10:09:17  <Luke-Jr> phantomcircuit: I don't know the exact setup details; I am speaking hypothetically from a vague understanding.
2612015-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
2622015-12-01T10:10:01  <Luke-Jr> phantomcircuit: …
2632015-12-01T10:11:00  <BlueMatt> lol, so all previous tests of #6872 are insane
2642015-12-01T10:11:19  <Luke-Jr> probably should close https://github.com/bitcoin/bitcoin/pull/6451 since it's past Nov 11
2652015-12-01T10:11:41  <gmaxwell> Luke-Jr: I specifically decided to not do that because the date could be simply adjusted at any time.
2662015-12-01T10:11:57  <gmaxwell> Though it should probably be rebased and adjusted to feburary.
2672015-12-01T10:12:39  <Luke-Jr> if he makes it the upcoming subsidy halving point, I'd probably concept-ACK it. <.<
2682015-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.
2692015-12-01T10:17:35  <phantomcircuit> Luke-Jr, ok i'll switch it such that only long poll responses will have empty blocks
2702015-12-01T10:17:41  <phantomcircuit> and all other responses will be normal
2712015-12-01T10:19:04  <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7128 has a bunch of utACKs, so I just rebased it
2722015-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
2732015-12-01T10:24:33  <wumpus> maybe break off the line for somewhat easier human parsing
2742015-12-01T10:24:40  <gmaxwell> FWIW, github lies, I think everything needs rebasing now, but github reports that for nothing.
2752015-12-01T10:25:06  <Luke-Jr> :/
2762015-12-01T10:26:35  <Luke-Jr> oh. master doesn't build. :|
2772015-12-01T10:26:54  <gmaxwell> oh maybe my rebasing kung fu is less bad than I thought.
2782015-12-01T10:27:05  <BlueMatt> LOL
2792015-12-01T10:28:01  <wumpus> let's first get master into a working/building state again then
2802015-12-01T10:28:58  <wumpus> hm it builds fine here
2812015-12-01T10:29:36  <BlueMatt> yea, builds fine here, too
2822015-12-01T10:29:51  <BlueMatt> tests also pass fine here...running build-in-crazy-confs-with-all-tests script
2832015-12-01T10:29:52  <BlueMatt> wumpus: https://github.com/bitcoin/bitcoin/pull/6872 <-- review away
2842015-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
2852015-12-01T10:32:07  <wumpus> BlueMatt: I agree but have you seen the section about running with no networking?
2862015-12-01T10:32:15  <Luke-Jr> http://codepad.org/BQ5Z2TPq
2872015-12-01T10:32:21  <wumpus> I don't want to force people through that for no good reason!
2882015-12-01T10:33:29  <Luke-Jr>         Q_EMIT clientmodel->numBlocksChanged(pIndex->nHeight, QDateTime::fromTime_t(pIndex->GetBlockTime()), clientmodel->getVerificationProgress(pIndex));
2892015-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
2902015-12-01T10:33:35  <Luke-Jr> this emits a signal for a different object?
2912015-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
2922015-12-01T10:34:22  <wumpus> Luke-Jr: eh huh
2932015-12-01T10:34:35  <BlueMatt> wumpus: hmm? if you just remove the gitian auto-update-apt step it should just work (tm) ?
2942015-12-01T10:35:02  <Luke-Jr> apparently Qt5 allows this, but not Qt4
2952015-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
2962015-12-01T10:35:33  <wumpus> BlueMatt: it's too late to redesign gitian for 0.12
2972015-12-01T10:35:56  <BlueMatt> argh, ok
2982015-12-01T10:35:59  <phantomcircuit> Luke-Jr, would you be opposed to making longpoll return only when there's a new block?
2992015-12-01T10:36:01  <BlueMatt> we should do this for 0.13, though
3002015-12-01T10:36:04  <wumpus> Luke-Jr: still very uncivil to raise a signal on another object :)
3012015-12-01T10:36:23  <Luke-Jr> phantomcircuit: yes, that would result in only ever mining empty blocks :x
3022015-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
3032015-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
3042015-12-01T10:37:00  <BlueMatt> wumpus: oh, we need #7022, too
3052015-12-01T10:37:04  <Luke-Jr> wumpus: so how shall we fix this? a dummy "raise the signal please" method? :p
3062015-12-01T10:37:08  <wumpus> Luke-Jr: I'll take a look at it..
3072015-12-01T10:37:33  <Luke-Jr> phantomcircuit: there is literally no reason to ever do a non-longpoll GBT
3082015-12-01T10:37:36  <wumpus> seems this is https://github.com/bitcoin/bitcoin/issues/7138
3092015-12-01T10:37:45  <Luke-Jr> phantomcircuit: and BFGMiner will in fact not do so, I think
3102015-12-01T10:37:45  <gmaxwell> builds fine for me on a guiless system.
3112015-12-01T10:37:49  *** JackH has joined #bitcoin-core-dev
3122015-12-01T10:37:55  <wumpus> gmaxwell: yes, only qt4 buildsfail
3132015-12-01T10:37:58  <Luke-Jr> gmaxwell: lol, of course it builds guiless :P
3142015-12-01T10:38:00  <wumpus> qt5 or guiless works fine
3152015-12-01T10:38:20  <wumpus> that's why I don't notice it either, I haven't used qt4 for more than a year
3162015-12-01T10:38:42  * Luke-Jr waits for a usable Qt5 DE :/
3172015-12-01T10:38:56  <midnightmagic> gonna be waiting a while.
3182015-12-01T10:39:01  <wumpus> Luke-Jr: qt creator is not qt5?
3192015-12-01T10:39:18  <phantomcircuit> Luke-Jr, well there is though
3202015-12-01T10:39:20  <wumpus> oh, what's DE?
3212015-12-01T10:39:35  <phantomcircuit> Luke-Jr, even with this you need at least two bitcoind instances to get absolute best latency
3222015-12-01T10:39:38  <Luke-Jr> wumpus: Desktop Environment
3232015-12-01T10:39:52  <phantomcircuit> one that's long polling and another that's calling gbt in a loop
3242015-12-01T10:40:03  <phantomcircuit> ie one that returns transaction
3252015-12-01T10:40:28  <phantomcircuit> otherwise the cs_main lock will add on average 500ms+ of latency to the long poll result
3262015-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.
3272015-12-01T10:41:00  <wumpus> oof he's using Q_EMIT cross-thread
3282015-12-01T10:41:13  <Luke-Jr> wumpus: that sounds scary. :|
3292015-12-01T10:41:28  <wumpus> I had no idea that even worked, used QMetaObject::invokeMethod to manually queue messages
3302015-12-01T10:41:55  <wumpus> which apparently works in qt4, so going to do that here too
3312015-12-01T10:42:18  <phantomcircuit> Luke-Jr, that's actually the same thing thanks to random distribution of blocks
3322015-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
3332015-12-01T10:43:17  <phantomcircuit> so either way there will be some latency from it
3342015-12-01T10:44:36  <Luke-Jr> wumpus: in the meantime, I'll work on getting Travis to test Qt4
3352015-12-01T10:45:02  <wumpus> Luke-Jr: makes sense for as long we still support it
3362015-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
3372015-12-01T10:47:40  <wumpus> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7143
3382015-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
3392015-12-01T10:48:24  <Luke-Jr> hm, I guess I should rebase mine off that XD
3402015-12-01T10:48:43  <wumpus> please test it too, I haven't yet :)
3412015-12-01T10:49:12  <Luke-Jr> yes, of course
3422015-12-01T10:49:27  <Luke-Jr> phantomcircuit: you active mining testnet? ;)
3432015-12-01T10:49:48  * Luke-Jr wonders what he needs to look for to change in the UI to test this properly
3442015-12-01T10:50:55  <phantomcircuit> Luke-Jr, i believe that im currently 100% of testnet actually
3452015-12-01T10:51:32  <Luke-Jr> phantomcircuit: as long as there's new blocks..
3462015-12-01T10:51:40  <Luke-Jr> wumpus: qt/clientmodel.cpp:257:56: error: macro "Q_ARG" requires 2 arguments, but only 1 given
3472015-12-01T10:55:19  <wumpus> ninja-edit fail, try again
3482015-12-01T10:58:59  <wumpus> --with-incompatible-bdb-and-just-shut-up
3492015-12-01T11:01:09  *** calibre720 has joined #bitcoin-core-dev
3502015-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?
3512015-12-01T11:03:51  <Luke-Jr> hmm, 7 peers now and no syncing :/
3522015-12-01T11:07:53  <phantomcircuit> Luke-Jr, huh my nodes all have 125 connections...
3532015-12-01T11:08:04  <Luke-Jr> looks like syncing is just broken :|
3542015-12-01T11:08:12  <phantomcircuit> Luke-Jr, i dont think so
3552015-12-01T11:08:43  <phantomcircuit> Luke-Jr, pm'd you one
3562015-12-01T11:09:05  <Luke-Jr> phantomcircuit: it didn't work to add yours. I had to restart my node and add you first :\
3572015-12-01T11:09:22  *** PaulCape_ has joined #bitcoin-core-dev
3582015-12-01T11:09:35  <phantomcircuit> Luke-Jr, yeah you have to wait for the other requests to timeout
3592015-12-01T11:09:41  <phantomcircuit> iirc it's approximately forever
3602015-12-01T11:09:44  <Luke-Jr> I waited a while
3612015-12-01T11:09:54  <phantomcircuit> it's like ten minutes or something
3622015-12-01T11:10:38  <Luke-Jr> ew
3632015-12-01T11:10:42  *** PaulCapestany has quit IRC
3642015-12-01T11:10:48  <phantomcircuit> there's someone running bitcoinseeder and sybil attacking testnet
3652015-12-01T11:10:54  <phantomcircuit> seems to be doing a pretty decent job too
3662015-12-01T11:11:20  <phantomcircuit> shrug
3672015-12-01T11:14:35  <Luke-Jr> wumpus: looks good
3682015-12-01T11:16:33  *** randy-waterhouse has quit IRC
3692015-12-01T11:24:01  <Luke-Jr> going to bed, I'll finish up in 8 hours, night
3702015-12-01T11:27:10  <wumpus> night
3712015-12-01T11:34:26  *** calibre720 has quit IRC
3722015-12-01T11:35:24  <BlueMatt> wumpus: we need #7022, too
3732015-12-01T11:35:28  *** jgarzik has quit IRC
3742015-12-01T11:35:43  <BlueMatt> oh, and #6872 is ready
3752015-12-01T11:35:56  *** jgarzik has joined #bitcoin-core-dev
3762015-12-01T11:35:57  *** jgarzik has quit IRC
3772015-12-01T11:35:57  *** jgarzik has joined #bitcoin-core-dev
3782015-12-01T11:40:01  <GitHub47> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6abf6eb7bb77...9afbd96919af
3792015-12-01T11:40:01  <GitHub47> bitcoin/master 50947ef Alex Morcos: Change default block priority size to 0...
3802015-12-01T11:40:02  <GitHub47> bitcoin/master 9afbd96 Wladimir J. van der Laan: Merge pull request #7022...
3812015-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
3822015-12-01T11:40:06  *** fkhan has quit IRC
3832015-12-01T11:47:57  *** jgarzik_ has joined #bitcoin-core-dev
3842015-12-01T11:48:54  *** jgarzik has quit IRC
3852015-12-01T11:53:26  *** fkhan has joined #bitcoin-core-dev
3862015-12-01T12:03:28  *** CodeShark_ has quit IRC
3872015-12-01T12:04:06  *** CodeShark_ has joined #bitcoin-core-dev
3882015-12-01T12:07:31  *** MarcoFalke has joined #bitcoin-core-dev
3892015-12-01T12:09:32  *** fkhan has quit IRC
3902015-12-01T12:14:31  *** calibre720 has joined #bitcoin-core-dev
3912015-12-01T12:18:28  <GitHub85> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/9afbd96919af...2ef5ffa59afa
3922015-12-01T12:18:29  <GitHub85> bitcoin/master 0c9959a Matt Corallo: Add failing test checking timelocked-txn removal during reorg
3932015-12-01T12:18:30  <GitHub85> bitcoin/master 9b060e5 Matt Corallo: Fix removal of time-locked transactions during reorg
3942015-12-01T12:18:30  <GitHub85> bitcoin/master b0a064c Matt Corallo: Fix comment in removeForReorg
3952015-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
3962015-12-01T12:18:55  *** MarcoFalke has quit IRC
3972015-12-01T12:19:05  *** MarcoFalke has joined #bitcoin-core-dev
3982015-12-01T12:20:52  <GitHub117> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ef5ffa59afa...a60538bc456c
3992015-12-01T12:20:53  <GitHub117> bitcoin/master 6da12df Wladimir J. van der Laan: qt: use QMetaObject::invokeMethod for cross-thread signaling in clientmodel...
4002015-12-01T12:20:53  <GitHub117> bitcoin/master a60538b Wladimir J. van der Laan: Merge pull request #7143...
4012015-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
4022015-12-01T12:21:37  <GitHub161> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a60538bc456c...c0c08c7c68d0
4032015-12-01T12:21:38  <GitHub161> bitcoin/master aabc897 Wladimir J. van der Laan: rpc: Don't translate warning messages...
4042015-12-01T12:21:38  <GitHub161> bitcoin/master c0c08c7 Wladimir J. van der Laan: Merge pull request #7141...
4052015-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
4062015-12-01T12:22:28  *** fkhan has joined #bitcoin-core-dev
4072015-12-01T12:28:02  <GitHub159> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/bc1f4275705a6aae03ce439cd317ec4166075c08
4082015-12-01T12:28:03  <GitHub159> bitcoin/master bc1f427 Wladimir J. van der Laan: qt: periodic translations update
4092015-12-01T12:32:40  <GitHub167> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bc1f4275705a...16f4a6e0fe26
4102015-12-01T12:32:41  <GitHub167> bitcoin/master cfdc662 Suhas Daftuar: Explicitly set chain limits in replace-by-fee test
4112015-12-01T12:32:41  <GitHub167> bitcoin/master 16f4a6e Wladimir J. van der Laan: Merge pull request #7137...
4122015-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
4132015-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
4142015-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
4152015-12-01T12:36:53  <MarcoFalke> Does this run fine?
4162015-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
4172015-12-01T12:37:48  <jonasschnelli> would it make sense to auto-choose a higher nDefaultDbCache in case bitcoind/qt detects more available ram?
4182015-12-01T12:37:51  <wumpus> (if so many people can reproduce them it doesn't mean much whether I can or not anyway...)
4192015-12-01T12:38:17  <wumpus> jonasschnelli: *up to a limit*
4202015-12-01T12:38:37  <jonasschnelli> I think for most modern server systems 100MB (current default) is very low.
4212015-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.
4222015-12-01T12:39:27  <jonasschnelli> Hmm... right... maybe its fine if the user just tweaks the -dbache manually.
4232015-12-01T12:39:56  <jonasschnelli> sipa asked about adding a option in Qt ("provide X MB of ram for bitcoin-qt")...
4242015-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
4252015-12-01T12:40:39  <jonasschnelli> hah. right.
4262015-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)
4272015-12-01T12:41:58  <wumpus> jonasschnelli: it could auto-select one based on some information gathered from the system
4282015-12-01T12:42:27  <jonasschnelli> Yes. That would be nice...
4292015-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
4302015-12-01T12:43:11  <jonasschnelli> Is changing the cache size during runtime possible? (CCoinsViewDB), flushing, deleting pcoinsdbview and recreating it?
4312015-12-01T12:43:12  <wumpus> hm or maybe an option to reduce the dbcache after the initial sync?
4322015-12-01T12:43:58  <jonasschnelli> wumpus: this is a very good point. A big cache size mainly helps for IBD performance...
4332015-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
4342015-12-01T12:45:44  <wumpus> (dbcache is divided up between some caches, I don't know if they're all easy to resize/reconfigure)
4352015-12-01T12:46:58  <sipa> the leveldb cache may be harder to change
4362015-12-01T12:48:44  <jonasschnelli> sipa, LOCK, flush CCoinsViewDB, delete CCoinsViewDB, new CCoinsViewDB, UNLOCK?
4372015-12-01T12:48:55  <sipa> hell no
4382015-12-01T12:48:58  <wumpus> you don't need to delte it, you could just add a method to change the limit?
4392015-12-01T12:48:58  <jonasschnelli> :-)
4402015-12-01T12:49:02  <sipa> don't delete the cache!
4412015-12-01T12:49:29  <sipa> but you'll need to recalculate how much to assign to leveldb etc
4422015-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
4432015-12-01T12:50:09  <wumpus> yes, you need to recompute those
4442015-12-01T12:53:29  <wumpus> for leveldb it does seem you have to close and reopen the database to change the cache size
4452015-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
4462015-12-01T12:54:25  <sipa> now it would be useful if someone would benchmark how much leveldb cache is optimal :)
4472015-12-01T12:55:10  <wumpus> right, it's very possible for there to be diminishing returns there sooner than for ccoinsviewcache
4482015-12-01T12:55:43  <sipa> the numbers that are in there now are only based on very simple (and outdated) benchmarks
4492015-12-01T13:02:36  <phantomcircuit> sipa, im guessing "more"
4502015-12-01T13:18:38  <wumpus> I would be surprised if it makes much of a difference at all
4512015-12-01T13:18:59  <tulip> I'm having a quick shot at testing it now.
4522015-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
4532015-12-01T13:20:02  <wumpus> (if it competes for the same bytes of memory)
4542015-12-01T13:21:10  <wumpus> and I'm even more in doubt about nBlockTreeDBCache's effectiveness
4552015-12-01T13:21:36  <wumpus> from the viewpoint of runtime, the block tree db is a write-only database
4562015-12-01T13:22:23  <wumpus> oh we take care of that // block tree db cache shouldn't be larger than 2 MiB
4572015-12-01T13:27:39  *** rook520 has quit IRC
4582015-12-01T13:34:28  *** MarcoFalke has quit IRC
4592015-12-01T13:41:08  *** Guyver2 has joined #bitcoin-core-dev
4602015-12-01T13:55:34  *** guest234234 has quit IRC
4612015-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
4622015-12-01T14:00:49  *** jgarzik_ has quit IRC
4632015-12-01T14:00:49  *** jgarzik_ has joined #bitcoin-core-dev
4642015-12-01T14:00:52  *** jgarzik_ is now known as jgarzik
4652015-12-01T14:01:09  <jgarzik> What are the hurdles blocking relay of new blocks in pruned mode?
4662015-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.
4672015-12-01T14:03:14  <phantomcircuit> jgarzik, not having NODE_NETWORK set is iirc the only one really
4682015-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.
4692015-12-01T14:04:25  <jgarzik> My VPS has reached its space limit, and I want to continue contributing usefully to the network ;p
4702015-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)
4712015-12-01T14:08:24  <phantomcircuit> gettxoutsetinfo seems to walk but avoid the cache layer
4722015-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
4732015-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
4742015-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.
4752015-12-01T14:16:39  <jgarzik> phantomcircuit, older nodes that don't getheaders might get stuck in IBD?
4762015-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
4772015-12-01T14:17:46  <phantomcircuit> jgarzik, older peers would definitely get stuck
4782015-12-01T14:21:07  *** pmienk has quit IRC
4792015-12-01T14:22:56  <phantomcircuit> hmm it seems the only way to "prime" the cache view is to reindex...
4802015-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
4812015-12-01T14:27:38  *** tulip has quit IRC
4822015-12-01T14:28:09  <jgarzik> hmmm.   !NODE_NETWORK should have no problem relaying blocks...  they just won't get asked for them.
4832015-12-01T14:28:33  * jgarzik goes to test
4842015-12-01T14:29:36  <phantomcircuit> jgarzik, correct
4852015-12-01T14:29:40  <phantomcircuit> (probably)
4862015-12-01T14:32:06  *** JackH has quit IRC
4872015-12-01T14:34:25  <sdaftuar> jgarzik: the headers announcements PR should mean that pruned nodes can relay blocks just fine now
4882015-12-01T14:35:22  <sdaftuar> including if there's a reorg that isn't more than 8 blocks
4892015-12-01T14:36:16  <jgarzik> sdaftuar, for keeping !node_network you mean?   Because otherwise that doesn't fix older nodes that would get stuck
4902015-12-01T14:36:32  <jgarzik> I wonder if we need NODE_RELAY
4912015-12-01T14:36:32  <sdaftuar> i'm specifically talking about relaying new blocks, not helping other nodes sync
4922015-12-01T14:36:38  *** pmienk has joined #bitcoin-core-dev
4932015-12-01T14:37:33  <sdaftuar> ah are you asking what it would take to let pruned nodes serve up historical blocks?
4942015-12-01T14:38:04  <jgarzik> No just looking at all the angles of pruning with fresh eyes
4952015-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
4962015-12-01T14:39:21  <sipa> yes, locators are built from the block index
4972015-12-01T14:39:27  <sipa> they don't need the actual blocks
4982015-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
4992015-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
5002015-12-01T14:40:08  <sdaftuar> 0.10 and 0.11 nodes will indeed not be able to download reorgs from pruned peers
5012015-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
5022015-12-01T14:40:53  <sipa> will 0.10 and 0.11 get disconnected if they try?
5032015-12-01T14:40:58  <sdaftuar> they won't even try
5042015-12-01T14:41:16  <jgarzik> Sounds like pruned nodes should only announce blocks to >= 0.12 peers
5052015-12-01T14:41:49  <sipa> we still need granulatiy in the service flags
5062015-12-01T14:41:59  <sdaftuar> well there's not much harm in inv'ing the tip to 0.11 and earlier peers is there?
5072015-12-01T14:42:02  <sipa> as even 0.12 just won't connect to non-network nodes
5082015-12-01T14:42:19  <sipa> sdaftuar: it may hide problems, i wouldn't
5092015-12-01T14:42:19  *** ParadoxSpiral has joined #bitcoin-core-dev
5102015-12-01T14:42:28  <jgarzik> thus the proposed NODE_RELAY
5112015-12-01T14:42:35  <sipa> sdaftuar: people may think that it works fine, until it doesn't due to reorg
5122015-12-01T14:43:13  <sdaftuar> hmm...  we merged that change a long time ago (to relay the tip)
5132015-12-01T14:43:24  <sipa> oh well
5142015-12-01T14:44:20  <jgarzik> pruning defaults to off so nearly nobody uses it
5152015-12-01T14:44:27  <jgarzik> plenty of freedom to change
5162015-12-01T14:44:27  *** CodeShark_ has quit IRC
5172015-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?
5182015-12-01T14:44:55  <sipa> sdaftuar: that does seem reasonable
5192015-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
5202015-12-01T14:45:28  <jgarzik> nod
5212015-12-01T14:45:37  <sdaftuar> it does needlessly harm 0.9 and 0.8 nodes... but probably not many of those left
5222015-12-01T14:46:38  <sipa> sdaftuar: what if there is a +8 deep reorg?
5232015-12-01T14:46:45  <sdaftuar> then we revert to inv
5242015-12-01T15:05:29  *** [b__b] has quit IRC
5252015-12-01T15:12:02  *** [b__b] has joined #bitcoin-core-dev
5262015-12-01T15:17:26  *** Guyver2 has quit IRC
5272015-12-01T15:22:53  <phantomcircuit> Luke-Jr, fyi switching to longpoll significantly increased my latency
5282015-12-01T15:22:58  <phantomcircuit> by like 4 seconds
5292015-12-01T15:56:44  <sipa> in the test framework is there anything i need to do to call a new RPC?
5302015-12-01T15:57:03  <sipa> JSONRPC error: Method not found
5312015-12-01T15:57:11  <sipa> sounds like bitcoind actually doesn't have it?
5322015-12-01T15:57:15  <sipa> (this is for getblockheader)
5332015-12-01T15:58:38  *** MarcoFalke has joined #bitcoin-core-dev
5342015-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
5352015-12-01T16:12:38  *** [b__b] has quit IRC
5362015-12-01T16:22:16  <wumpus> sipa: no, should be nothing you have to do
5372015-12-01T16:23:17  <sipa> wumpus: i used a wrong variable name
5382015-12-01T16:23:39  <wumpus> okay
5392015-12-01T16:54:34  *** [b__b] has joined #bitcoin-core-dev
5402015-12-01T16:57:28  *** JackH has joined #bitcoin-core-dev
5412015-12-01T16:58:03  *** crescendo has quit IRC
5422015-12-01T17:02:14  *** afk11 has joined #bitcoin-core-dev
5432015-12-01T17:06:01  *** crescendo has joined #bitcoin-core-dev
5442015-12-01T17:10:58  *** [b__b] has quit IRC
5452015-12-01T17:38:46  *** wangchun_ has quit IRC
5462015-12-01T17:39:15  *** wangchun has joined #bitcoin-core-dev
5472015-12-01T17:41:39  *** Dyanisus has left #bitcoin-core-dev
5482015-12-01T17:46:29  *** ParadoxSpiral_ has joined #bitcoin-core-dev
5492015-12-01T17:49:43  *** ParadoxSpiral has quit IRC
5502015-12-01T17:53:31  *** BashCo has quit IRC
5512015-12-01T18:07:32  *** afk11 has quit IRC
5522015-12-01T18:09:44  *** calibre720 has quit IRC
5532015-12-01T18:15:15  *** [b__b] has joined #bitcoin-core-dev
5542015-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
5552015-12-01T18:18:57  *** BashCo has joined #bitcoin-core-dev
5562015-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.
5572015-12-01T18:24:45  <jgarzik> Ideal goal is a lightweight router mode that contributes usefully to the network (subjective definition, I know)
5582015-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.
5592015-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
5602015-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
5612015-12-01T18:39:44  *** da2ce7 has quit IRC
5622015-12-01T18:39:59  *** da2ce7 has joined #bitcoin-core-dev
5632015-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
5642015-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
5652015-12-01T19:31:16  <GitHub90> [bitcoin] sipa pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/16f4a6e0fe26...4077ad20d03f
5662015-12-01T19:31:17  <GitHub90> bitcoin/master c49d5bc Alex Morcos: Store the total sig op count of a tx....
5672015-12-01T19:31:18  <GitHub90> bitcoin/master f3fe836 Alex Morcos: Add a score index to the mempool....
5682015-12-01T19:31:18  <GitHub90> bitcoin/master 7230187 Alex Morcos: Add TxPriority class and comparator
5692015-12-01T19:31:21  <GitHub194> [bitcoin] sipa closed pull request #6898: Rewrite CreateNewBlock (master...fasterCNB) https://github.com/bitcoin/bitcoin/pull/6898
5702015-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
5712015-12-01T19:42:58  *** raedah has joined #bitcoin-core-dev
5722015-12-01T19:49:08  *** Guyver2 has joined #bitcoin-core-dev
5732015-12-01T20:10:19  <morcos> sipa: woohoo thanks!  now i can start changing it again. :)
5742015-12-01T20:11:37  *** cocoBTC has joined #bitcoin-core-dev
5752015-12-01T20:17:52  <Luke-Jr> sigh, so I guess I'm going to need to strongly recommend miners not upgrade to 0.12?
5762015-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?
5772015-12-01T20:19:39  <morcos> For instance if you are not sending chains of txs, then there is no difference
5782015-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
5792015-12-01T20:20:19  <morcos> (or course assuming its not evicted before that)
5802015-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
5812015-12-01T20:20:47  <Luke-Jr> 6357 appears to have been auto-closed by bad GitHub logic.. are you able to reopen it?
5822015-12-01T20:20:52  <morcos> yes i really don't think its that bad
5832015-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
5842015-12-01T20:22:36  <Luke-Jr> 7022 is pretty bad :/
5852015-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.
5862015-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
5872015-12-01T20:23:50  <Luke-Jr> in practice, it's more complexity in LOC/maintenance to have it NOT in master
5882015-12-01T20:23:57  <sipa> that's your view
5892015-12-01T20:24:12  *** belcher has joined #bitcoin-core-dev
5902015-12-01T20:24:16  <morcos> Luke-Jr: the complexity i'm concerned with is complexity of correctness
5912015-12-01T20:24:17  <sipa> i have no problem with creating a mechanism that takes coins value/age into account for prioritization, however
5922015-12-01T20:24:17  <Luke-Jr> sipa: that's my view, as the guy maintaining the mining stuff..
5932015-12-01T20:24:33  <sipa> Luke-Jr: i know that's your view; i respectfully disagree, and i'm not alone
5942015-12-01T20:24:44  <morcos> sipa: i love it how even you have your irrational pet projects. :)
5952015-12-01T20:25:15  <sipa> morcos: if everything in bitcoin was rational, nobody would have started using it
5962015-12-01T20:26:13  <Luke-Jr> sipa: your disagreement appears to be about a cost that I bear specifically.
5972015-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 :)
5982015-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 :/
5992015-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.
6002015-12-01T20:28:42  <morcos> Luke-Jr: priority is irrepairably broken with 0.12 and limited mempools that don't respect it
6012015-12-01T20:28:52  <Luke-Jr> the miners who have disabled it, have done so because of the performance issues that are now fixed
6022015-12-01T20:28:58  <morcos> when we somehow decided to not address that or failed to decide to address it
6032015-12-01T20:29:09  <morcos> i think we put ourselves clearly on the path to removing priority
6042015-12-01T20:29:12  <Luke-Jr> morcos: I thought we had decided to address it, but nothing got done :p
6052015-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" :/
6062015-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 :)
6072015-12-01T20:30:26  <sipa> 0.12 will work with priority fine as a miner, if you have a sufficiently large mempool
6082015-12-01T20:30:29  <Luke-Jr> after what?
6092015-12-01T20:30:31  <jgarzik> heh
6102015-12-01T20:30:51  <Luke-Jr> sipa: that seems like a reasonable expectation of miners IMO
6112015-12-01T20:30:55  <morcos> Luke-Jr: working with the rest of the mempool/mining code will be much easier when priority is gone
6122015-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
6132015-12-01T20:31:29  <Luke-Jr> morcos: priority will never be gone
6142015-12-01T20:32:45  <morcos> it could theoretically be implemented by a quite complex companion program which just selectively applied feeDeltas i suppose
6152015-12-01T20:32:56  <Luke-Jr> morcos: it shouldn't need to be
6162015-12-01T20:33:30  <Luke-Jr> it should be as simple as it is now, or simpler.
6172015-12-01T20:33:44  <Luke-Jr> anything else is harmful to Bitcoin
6182015-12-01T20:34:10  <jgarzik> hyperbole
6192015-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?
6202015-12-01T20:36:58  <jgarzik> with the goal of #2 being avoiding all the current complexity that the consensus of devs agrees is there
6212015-12-01T20:37:58  <Luke-Jr> do I need to go make a big deal about this on reddit etc to prove (1)?
6222015-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.)
6232015-12-01T20:39:29  <jgarzik> a CNB consumer =  a CNB user = a miner
6242015-12-01T20:40:06  <jgarzik> It sounds like the ideal solution is a post-pass filter for applying some site local policy
6252015-12-01T20:40:17  <jgarzik> maybe a pre-pass filter for spam filtering
6262015-12-01T20:40:39  <jgarzik> (though 99% of that happens via IsStandard)
6272015-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
6282015-12-01T20:40:56  *** MarcoFalke has quit IRC
6292015-12-01T20:41:06  <sipa> jgarzik: priority is more complicated because it needs re-evaluation
6302015-12-01T20:41:26  <sipa> so anything that doesn't need re-evaluation would be trivial to do
6312015-12-01T20:41:31  <jgarzik> nod - post-pass - picks up stragglers fee didnt'
6322015-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
6332015-12-01T20:49:35  <morcos> but the main thing i keep coming back to is non fee based metrics are broken for other purposes
6342015-12-01T20:49:38  <morcos> relay
6352015-12-01T20:49:40  <morcos> mempool limiting
6362015-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
6372015-12-01T20:50:35  <morcos> and by fee based, i mean including feeDelta
6382015-12-01T20:51:04  *** MarcoFalke has joined #bitcoin-core-dev
6392015-12-01T20:51:18  <Luke-Jr> morcos: you can't ensure anything with propagate ever
6402015-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
6412015-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
6422015-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
6432015-12-01T20:54:36  <morcos> but that would mean relaying based of feeDelta too
6442015-12-01T20:54:55  <sipa> i think that's reasonable
6452015-12-01T20:57:18  <sdaftuar> i can add a commit to 7062 to address that
6462015-12-01T21:05:34  *** raedah has quit IRC
6472015-12-01T21:22:17  *** tulip has joined #bitcoin-core-dev
6482015-12-01T21:26:07  *** raedah has joined #bitcoin-core-dev
6492015-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
6502015-12-01T21:42:23  <Luke-Jr> morcos: ^
6512015-12-01T21:44:17  *** pmienk has quit IRC
6522015-12-01T21:49:12  *** pmienk has joined #bitcoin-core-dev
6532015-12-01T21:56:37  *** tulip has quit IRC
6542015-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..?
6552015-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
6562015-12-01T21:58:40  <sipa> Luke-Jr: by conflicting i mean conflicting with the chain
6572015-12-01T21:58:51  <Luke-Jr> sipa: I'm aware..
6582015-12-01T21:58:54  <sipa> earlier, conflicting with the mempool was enough to get -1 confirms
6592015-12-01T21:58:59  <Luke-Jr> ah
6602015-12-01T21:59:09  <Luke-Jr> was that actually possible? O.o
6612015-12-01T21:59:43  <sipa> maybe it was very hard to reach that
6622015-12-01T22:00:02  <sipa> as the wallet tried to get its transactions in the mempool at startup
6632015-12-01T22:00:57  <Luke-Jr> I wonder if this should be considerd a bugfix and backported
6642015-12-01T22:00:57  <sipa> i agree the explanation there is confusing
6652015-12-01T22:01:09  <Luke-Jr> maybe with a min(-1) on the count
6662015-12-01T22:01:12  <sipa> it's mostly needed because of mempool eviction
6672015-12-01T22:01:22  *** ParadoxSpiral_ has quit IRC
6682015-12-01T22:02:00  <sipa> so i wouldn't consider it a bugfix pre-0.12
6692015-12-01T22:03:29  <Luke-Jr> k
6702015-12-01T22:05:34  *** bsm117532 has quit IRC
6712015-12-01T22:05:44  <Luke-Jr> 7096 has me confused about whether it is a fix, part fix, or what :|
6722015-12-01T22:05:59  *** zookolaptop has joined #bitcoin-core-dev
6732015-12-01T22:11:27  *** tulip has joined #bitcoin-core-dev
6742015-12-01T22:13:33  <jtimon> ping #6625
6752015-12-01T22:15:57  *** lecusemb1e has quit IRC
6762015-12-01T22:16:05  *** lecusemble has joined #bitcoin-core-dev
6772015-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
6782015-12-01T22:22:39  *** instagibbs has quit IRC
6792015-12-01T22:24:22  *** Guyver2 has quit IRC
6802015-12-01T22:25:33  *** instagibbs has joined #bitcoin-core-dev
6812015-12-01T22:33:29  *** arubi has quit IRC
6822015-12-01T22:39:49  *** arubi has joined #bitcoin-core-dev
6832015-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?
6842015-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.
6852015-12-01T22:44:53  <Luke-Jr> gmaxwell: that makes policy unnecessarily and gratuitously complicated to implement.
6862015-12-01T22:45:12  <Luke-Jr> and doesn't address the mempool side
6872015-12-01T22:45:22  <gmaxwell> But it's good because it makes it infinitely configurable without turning everyone into a bitcoind hacker.
6882015-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 :/
6892015-12-01T22:45:49  <gmaxwell> The eviction uses the modified score (feerate), no? so it's only ingress thats not addressed.
6902015-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.
6912015-12-01T22:46:40  <gmaxwell> And can't do things like so anti-spam analysis or what not because its in the critical path.
6922015-12-01T22:48:24  <Luke-Jr> gmaxwell: none of this is possible for 0.12
6932015-12-01T22:48:47  *** arubi_ has joined #bitcoin-core-dev
6942015-12-01T22:49:09  <gmaxwell> an external daemon would work with git master right now.
6952015-12-01T22:50:00  *** arubi has quit IRC
6962015-12-01T22:52:18  *** MarcoFalke has quit IRC
6972015-12-01T23:02:37  *** bsm117532 has joined #bitcoin-core-dev
6982015-12-01T23:22:30  *** zookolaptop has quit IRC
6992015-12-01T23:40:47  *** cocoBTC has quit IRC
7002015-12-01T23:41:35  *** amiller_ has quit IRC
7012015-12-01T23:42:12  *** amiller has joined #bitcoin-core-dev
7022015-12-01T23:42:19  *** amiller is now known as Guest46010
7032015-12-01T23:50:32  <jgarzik> for ingress, pass firstseen rejected TXs to external as well