--- Day changed Tue Dec 01 2015 00:00 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 00:03 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has joined #bitcoin-core-dev 00:03 < GitHub104> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c143c499c85b...1b5118bfa0d9 00:03 < GitHub104> bitcoin/master 5029698 kazcw: prevent peer flooding request queue for an inv... 00:03 < GitHub104> bitcoin/master ebb25f4 Gregory Maxwell: Limit setAskFor and retire requested entries only when a getdata returns.... 00:03 < GitHub104> bitcoin/master 1b5118b Wladimir J. van der Laan: Merge pull request #7079... 00:03 < GitHub11> [bitcoin] laanwj closed pull request #7079: Prevent peer flooding inv request queue (redux) (redux) (master...setAskFor) https://github.com/bitcoin/bitcoin/pull/7079 00:22 < GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b5118bfa0d9...30c2d8c635c4 00:22 < GitHub170> bitcoin/master 9ac63d6 Pieter Wuille: Keep track of explicit wallet conflicts instead of using mempool 00:22 < GitHub170> bitcoin/master 30c2d8c Wladimir J. van der Laan: Merge pull request #7105... 00:22 < 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 00:38 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 260 seconds] 00:40 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 00:40 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:42 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 00:43 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 00:49 < 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 00:50 < 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 00:56 < GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30c2d8c635c4...eb3d1b348773 00:56 < GitHub101> bitcoin/master fa3a38a MarcoFalke: [qa] pull-tester: Cleanup (run keypool, tidy stdout)... 00:56 < GitHub101> bitcoin/master eb3d1b3 Wladimir J. van der Laan: Merge pull request #7135... 00:56 < 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 00:59 < GitHub129> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb3d1b348773...9490bd71bdb4 00:59 < GitHub129> bitcoin/master ecc7c82 Pieter Wuille: Move fPayAtLeastCustomFee function to CC 00:59 < GitHub129> bitcoin/master 80462dd Jonas Schnelli: [Qt] use ASYMP_UTF8 (≈) whenever we show a fee that is not absolute 00:59 < GitHub129> bitcoin/master 31b508a Jonas Schnelli: [Qt] make use of the nMinimumTotalFee (absolute) in coincontrols fee calculation 00:59 < 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 01:01 < gmaxwell> wumpus: what do you need me working on for 0.12? 01:05 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:16 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 01:22 < GitHub104> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9490bd71bdb4...327291af02d0 01:22 < GitHub104> bitcoin/master 114b581 Pieter Wuille: Prevector type 01:22 < GitHub104> bitcoin/master 327291a Wladimir J. van der Laan: Merge pull request #6914... 01:22 < 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 01:23 < GitHub24> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/327291af02d0...8f761e87c3fd 01:23 < GitHub24> bitcoin/master fad3035 MarcoFalke: [doc] Minor markdown fixes 01:23 < GitHub24> bitcoin/master fa22a10 MarcoFalke: contrib: Del. gitian downloader config and update gitian README 01:23 < GitHub24> bitcoin/master 9999cb0 MarcoFalke: Fix url in .travis.yml 01:23 < 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 01:24 < 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. 01:25 < wumpus> hehehehe certainly feels that way 01:28 < wumpus> gmaxwell: final ack on https://github.com/bitcoin/bitcoin/pull/6915 would be nice 01:28 < wumpus> https://github.com/bitcoin/bitcoin/pull/6898 has no ACKs at all, not even untested or concept 01:29 < wumpus> https://github.com/bitcoin/bitcoin/pull/6872 needs rebase, and BlueMatt has no time to do it until tomorrow 01:30 < wumpus> those are the three left with milestone set to 0.12 01:32 < BlueMatt> i mean if it needs to happen now i could 01:32 < BlueMatt> was just in the middle of other things 01:33 < gmaxwell> BlueMatt: this is wumpus closing the 0.12 window; so, not great to wait. 01:34 < BlueMatt> argh 01:34 < BlueMatt> ok....will do in the next hour or so 01:36 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev 01:43 < 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 01:44 < BlueMatt> yea, working on it now 01:44 < BlueMatt> fixing whitespace errors and shits 01:44 < BlueMatt> (and actually reviewing my code...) 01:48 < Luke-Jr> anything for me to rebase? 01:49 < wumpus> Luke-Jr: you could help testing https://github.com/bitcoin/bitcoin/pull/6898 :) 01:50 < BlueMatt> wumpus: it seems a bit late to be pushing 6898 in? 01:50 < BlueMatt> though I would really very much like to see it 01:51 < Luke-Jr> wumpus: I'm still mid-code review on that one, and also NACK it without 6357 :/ 01:52 < wumpus> BlueMatt: that's also my opinion 01:53 < 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 01:54 < Luke-Jr> might make more sense as a "beta" boolean parameter to getblocktemplate? 01:54 < Luke-Jr> no need to duplicate the RPC side 01:54 * wumpus hates adding parameters 01:55 < Luke-Jr> wumpus: GBT is explicitly designed to be nice about parameters 01:55 < Luke-Jr> there's an Object parameter for every GBT call, that can have any variety of keys 01:55 < wumpus> Luke-Jr: true, you're passing it as an object? right 01:56 < BlueMatt> wumpus: if we want to do a fix for gbt for 0.12, i think its https://github.com/bitcoin/bitcoin/pull/7104 01:56 < BlueMatt> phantomcircuit: ^ ? 01:56 < Luke-Jr> oh! I missed that one somehow 01:58 < gmaxwell> wumpus: make it a config option not another RPC. The reason is that it's burdensome to have to change your other software. 01:58 < gmaxwell> and I don't see much use to switching them on the fly. 01:58 < phantomcircuit> huh what 01:58 < phantomcircuit> oh yeah 01:58 < 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" 01:58 < Luke-Jr> gmaxwell: switching on the fly can be automatic degrading 01:58 < wumpus> gmaxwell: right... 01:58 < phantomcircuit> wumpus, i've actually tested it and it does what it's supposed to do 01:58 < BlueMatt> wumpus: well i dunno if it'll break existing pool software, maybe it should be optional 01:58 < Luke-Jr> phantomcircuit: does it, with multiple poolservers connected? 01:59 < gmaxwell> Luke-Jr: yea it could but I think it's not worth the other costs. 01:59 < Luke-Jr> phantomcircuit: seems like it might be better to just do the empty block on longpoll connections 01:59 < phantomcircuit> Luke-Jr, gbt takes 500-3000ms 01:59 < Luke-Jr> gmaxwell: a GBT parameter with a config default would be pretty trivial 01:59 < phantomcircuit> returning an empty block reduces that significantly 01:59 < 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 01:59 < BlueMatt> wumpus: but its definitely the smallest thing we can do that'll fix a bunch of the latency issues for gbt 01:59 < gmaxwell> wumpus: heh. I laughed at that too, but we shouldn't punish patches for being super frank. :) 01:59 < Luke-Jr> phantomcircuit: obviously; I don't see how that's related to my suggestion :p 02:00 < phantomcircuit> Luke-Jr, oh with multiple pool servers no it doesn't 02:00 < 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. :) 02:00 < 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 02:00 < phantomcircuit> Luke-Jr, i couldn't figure out any way to support that without adding a full round trip though 02:01 < phantomcircuit> BlueMatt, no it's not because that would only work if you already knew there was a new block 02:01 < Luke-Jr> gmaxwell: it's strictly better to have param-with-config-default rather than config-only :p 02:01 < phantomcircuit> and most often you dont 02:01 < BlueMatt> phantomcircuit: huh? dont most pools know this because p2p told them? 02:01 < Luke-Jr> BlueMatt: that does sound ideal actually. 02:01 < BlueMatt> did we merge the pull-up? 02:01 < BlueMatt> no, we'd need https://github.com/bitcoin/bitcoin/pull/7037 too 02:01 < Luke-Jr> phantomcircuit: GBT is longpolled.. 02:01 < phantomcircuit> BlueMatt, i dont think we should make that the default setup... 02:01 < BlueMatt> so https://github.com/bitcoin/bitcoin/pull/7037 plus a "I want no txn" option would be my vote 02:02 < BlueMatt> its a small patch and fixes the issues (mostly) 02:02 < Luke-Jr> "I want no txn" option can be set on longpoll requests too 02:02 < phantomcircuit> Luke-Jr, so what? 02:02 < Luke-Jr> phantomcircuit: so whether you use blocknotify or longpolling for new block notification, you can use "I want no txn" 02:02 < phantomcircuit> Luke-Jr, i guess if it was "i want to wait for a new block and then i want it to be zero" 02:02 < Luke-Jr> that's what longpolling is. 02:03 < 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??" 02:03 < Luke-Jr> (right now, longpoll will return with changed txn data too, but obviously you'd skip that when this flag is set) 02:03 < phantomcircuit> it actually does reduce latency btw 02:03 < Luke-Jr> phantomcircuit: that's stupid; you need those CPU cycles for the rest of the mining system 02:03 < BlueMatt> Luke-Jr: you dont have a multi-core processor?! 02:04 < Luke-Jr> BlueMatt: … yes, and all 16 cores are running poolservers (I think) :P 02:04 < BlueMatt> wtf 02:04 < BlueMatt> how did you manage to do that? 02:04 < 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. 02:04 < gmaxwell> BlueMatt: python. 02:04 < Luke-Jr> BlueMatt: multiple instances with iptables load balancing 02:05 < Luke-Jr> oh, yeah, Python too 02:05 < BlueMatt> gmaxwell: fair point 02:05 * Luke-Jr stabs Python 02:05 < GitHub69> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/8f761e87c3fd...6abf6eb7bb77 02:05 < GitHub69> bitcoin/master 6e8b07f Suhas Daftuar: Add rounding helper function to util.py 02:05 < GitHub69> bitcoin/master 2b31ab9 Suhas Daftuar: Add rpc test for prioritisetransaction 02:05 < GitHub69> bitcoin/master 6abf6eb Wladimir J. van der Laan: Merge pull request #7063... 02:05 < 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 02:06 < phantomcircuit> and then it would only work for people using long poll 02:06 < phantomcircuit> which clealry has the potential to foot gun 02:06 < phantomcircuit> and also why the hell do you have multiple pool servers talking to a single bitcoind instance? 02:07 < Luke-Jr> phantomcircuit: they all talk to multipel bitcoind instances :P 02:08 < phantomcircuit> Luke-Jr, so you've got like 8 pool servers which each talk to the same set of 8 bitcoind instances 02:08 < phantomcircuit> ? 02:09 < Luke-Jr> phantomcircuit: I don't know the exact setup details; I am speaking hypothetically from a vague understanding. 02:09 < 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 02:10 < Luke-Jr> phantomcircuit: … 02:11 < BlueMatt> lol, so all previous tests of #6872 are insane 02:11 < Luke-Jr> probably should close https://github.com/bitcoin/bitcoin/pull/6451 since it's past Nov 11 02:11 < gmaxwell> Luke-Jr: I specifically decided to not do that because the date could be simply adjusted at any time. 02:11 < gmaxwell> Though it should probably be rebased and adjusted to feburary. 02:12 < Luke-Jr> if he makes it the upcoming subsidy halving point, I'd probably concept-ACK it. <.< 02:12 < 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. 02:17 < phantomcircuit> Luke-Jr, ok i'll switch it such that only long poll responses will have empty blocks 02:17 < phantomcircuit> and all other responses will be normal 02:19 < Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7128 has a bunch of utACKs, so I just rebased it 02:21 < wumpus> Luke-Jr: I had to laugh at "BaseParams(CBaseChainParams::MAIN).RPCPort(), BaseParams(CBaseChainParams::TESTNET).RPCPort())" - ut yes it makes sense 02:24 < wumpus> maybe break off the line for somewhat easier human parsing 02:24 < gmaxwell> FWIW, github lies, I think everything needs rebasing now, but github reports that for nothing. 02:25 < Luke-Jr> :/ 02:26 < Luke-Jr> oh. master doesn't build. :| 02:26 < gmaxwell> oh maybe my rebasing kung fu is less bad than I thought. 02:27 < BlueMatt> LOL 02:28 < wumpus> let's first get master into a working/building state again then 02:28 < wumpus> hm it builds fine here 02:29 < BlueMatt> yea, builds fine here, too 02:29 < BlueMatt> tests also pass fine here...running build-in-crazy-confs-with-all-tests script 02:29 < BlueMatt> wumpus: https://github.com/bitcoin/bitcoin/pull/6872 <-- review away 02:31 < 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 02:32 < wumpus> BlueMatt: I agree but have you seen the section about running with no networking? 02:32 < Luke-Jr> http://codepad.org/BQ5Z2TPq 02:32 < wumpus> I don't want to force people through that for no good reason! 02:33 < Luke-Jr> Q_EMIT clientmodel->numBlocksChanged(pIndex->nHeight, QDateTime::fromTime_t(pIndex->GetBlockTime()), clientmodel->getVerificationProgress(pIndex)); 02:33 < BlueMatt> wumpus: well we shouldnt tell people to use apt-cacher and should just have instructions to disable the auto-update 02:33 < Luke-Jr> this emits a signal for a different object? 02:33 < 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 02:34 < wumpus> Luke-Jr: eh huh 02:34 < BlueMatt> wumpus: hmm? if you just remove the gitian auto-update-apt step it should just work (tm) ? 02:35 < Luke-Jr> apparently Qt5 allows this, but not Qt4 02:35 < 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 02:35 < wumpus> BlueMatt: it's too late to redesign gitian for 0.12 02:35 < BlueMatt> argh, ok 02:35 < phantomcircuit> Luke-Jr, would you be opposed to making longpoll return only when there's a new block? 02:36 < BlueMatt> we should do this for 0.13, though 02:36 < wumpus> Luke-Jr: still very uncivil to raise a signal on another object :) 02:36 < Luke-Jr> phantomcircuit: yes, that would result in only ever mining empty blocks :x 02:36 < wumpus> BlueMatt: for the further future I'd prefer deterministic building without any VMs at all, just a 'blessed' deterministic toolchain 02:36 < 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 02:36 < BlueMatt> wumpus: oh, we need #7022, too 02:37 < Luke-Jr> wumpus: so how shall we fix this? a dummy "raise the signal please" method? :p 02:37 < wumpus> Luke-Jr: I'll take a look at it.. 02:37 < Luke-Jr> phantomcircuit: there is literally no reason to ever do a non-longpoll GBT 02:37 < wumpus> seems this is https://github.com/bitcoin/bitcoin/issues/7138 02:37 < Luke-Jr> phantomcircuit: and BFGMiner will in fact not do so, I think 02:37 < gmaxwell> builds fine for me on a guiless system. 02:37 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-core-dev 02:37 < wumpus> gmaxwell: yes, only qt4 buildsfail 02:37 < Luke-Jr> gmaxwell: lol, of course it builds guiless :P 02:38 < wumpus> qt5 or guiless works fine 02:38 < wumpus> that's why I don't notice it either, I haven't used qt4 for more than a year 02:38 * Luke-Jr waits for a usable Qt5 DE :/ 02:38 < midnightmagic> gonna be waiting a while. 02:39 < wumpus> Luke-Jr: qt creator is not qt5? 02:39 < phantomcircuit> Luke-Jr, well there is though 02:39 < wumpus> oh, what's DE? 02:39 < phantomcircuit> Luke-Jr, even with this you need at least two bitcoind instances to get absolute best latency 02:39 < Luke-Jr> wumpus: Desktop Environment 02:39 < phantomcircuit> one that's long polling and another that's calling gbt in a loop 02:40 < phantomcircuit> ie one that returns transaction 02:41 < phantomcircuit> otherwise the cs_main lock will add on average 500ms+ of latency to the long poll result 02:41 < 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. 02:41 < wumpus> oof he's using Q_EMIT cross-thread 02:41 < Luke-Jr> wumpus: that sounds scary. :| 02:41 < wumpus> I had no idea that even worked, used QMetaObject::invokeMethod to manually queue messages 02:41 < wumpus> which apparently works in qt4, so going to do that here too 02:42 < phantomcircuit> Luke-Jr, that's actually the same thing thanks to random distribution of blocks 02:43 < phantomcircuit> i guess really it doesn't much matter since you need cs_main for both empty blocks and filling the template 02:43 < phantomcircuit> so either way there will be some latency from it 02:44 < Luke-Jr> wumpus: in the meantime, I'll work on getting Travis to test Qt4 02:47 < wumpus> Luke-Jr: makes sense for as long we still support it 02:47 < 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 02:47 < wumpus> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7143 02:47 < 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 02:48 < Luke-Jr> hm, I guess I should rebase mine off that XD 02:48 < wumpus> please test it too, I haven't yet :) 02:49 < Luke-Jr> yes, of course 02:49 < Luke-Jr> phantomcircuit: you active mining testnet? ;) 02:49 * Luke-Jr wonders what he needs to look for to change in the UI to test this properly 02:50 < phantomcircuit> Luke-Jr, i believe that im currently 100% of testnet actually 02:51 < Luke-Jr> phantomcircuit: as long as there's new blocks.. 02:51 < Luke-Jr> wumpus: qt/clientmodel.cpp:257:56: error: macro "Q_ARG" requires 2 arguments, but only 1 given 02:55 < wumpus> ninja-edit fail, try again 02:58 < wumpus> --with-incompatible-bdb-and-just-shut-up 03:01 -!- calibre720 [~calibre72@triband-mum-120.62.161.163.mtnl.net.in] has joined #bitcoin-core-dev 03:02 < Luke-Jr> apparently the one node my client found is not giving me blocks. anyone have a working testnet node I can peer with? 03:03 < Luke-Jr> hmm, 7 peers now and no syncing :/ 03:07 < phantomcircuit> Luke-Jr, huh my nodes all have 125 connections... 03:08 < Luke-Jr> looks like syncing is just broken :| 03:08 < phantomcircuit> Luke-Jr, i dont think so 03:08 < phantomcircuit> Luke-Jr, pm'd you one 03:09 < Luke-Jr> phantomcircuit: it didn't work to add yours. I had to restart my node and add you first :\ 03:09 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev 03:09 < phantomcircuit> Luke-Jr, yeah you have to wait for the other requests to timeout 03:09 < phantomcircuit> iirc it's approximately forever 03:09 < Luke-Jr> I waited a while 03:09 < phantomcircuit> it's like ten minutes or something 03:10 < Luke-Jr> ew 03:10 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds] 03:10 < phantomcircuit> there's someone running bitcoinseeder and sybil attacking testnet 03:10 < phantomcircuit> seems to be doing a pretty decent job too 03:11 < phantomcircuit> shrug 03:14 < Luke-Jr> wumpus: looks good 03:16 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 03:24 < Luke-Jr> going to bed, I'll finish up in 8 hours, night 03:27 < wumpus> night 03:34 -!- calibre720 [~calibre72@triband-mum-120.62.161.163.mtnl.net.in] has quit [Ping timeout: 250 seconds] 03:35 < BlueMatt> wumpus: we need #7022, too 03:35 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Read error: Connection reset by peer] 03:35 < BlueMatt> oh, and #6872 is ready 03:35 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev 03:35 -!- jgarzik [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host] 03:35 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev 03:40 < GitHub47> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6abf6eb7bb77...9afbd96919af 03:40 < GitHub47> bitcoin/master 50947ef Alex Morcos: Change default block priority size to 0... 03:40 < GitHub47> bitcoin/master 9afbd96 Wladimir J. van der Laan: Merge pull request #7022... 03:40 < GitHub77> [bitcoin] laanwj closed pull request #7022: Change default block priority size to 0 (master...defaultPrioritySize) https://github.com/bitcoin/bitcoin/pull/7022 03:40 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 260 seconds] 03:47 -!- jgarzik_ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev 03:48 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 245 seconds] 03:53 -!- fkhan [weechat@gateway/vpn/mullvad/x-piweyypfowtzcnjv] has joined #bitcoin-core-dev 04:03 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds] 04:04 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 04:07 -!- MarcoFalke [8af6026b@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.107] has joined #bitcoin-core-dev 04:09 -!- fkhan [weechat@gateway/vpn/mullvad/x-piweyypfowtzcnjv] has quit [Ping timeout: 250 seconds] 04:14 -!- calibre720 [~calibre72@triband-mum-120.62.161.163.mtnl.net.in] has joined #bitcoin-core-dev 04:18 < GitHub85> [bitcoin] laanwj pushed 9 new commits to master: https://github.com/bitcoin/bitcoin/compare/9afbd96919af...2ef5ffa59afa 04:18 < GitHub85> bitcoin/master 0c9959a Matt Corallo: Add failing test checking timelocked-txn removal during reorg 04:18 < GitHub85> bitcoin/master 9b060e5 Matt Corallo: Fix removal of time-locked transactions during reorg 04:18 < GitHub85> bitcoin/master b0a064c Matt Corallo: Fix comment in removeForReorg 04:18 < 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 04:18 -!- MarcoFalke [8af6026b@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.107] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 04:19 -!- MarcoFalke [8af6026b@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.107] has joined #bitcoin-core-dev 04:20 < GitHub117> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2ef5ffa59afa...a60538bc456c 04:20 < GitHub117> bitcoin/master 6da12df Wladimir J. van der Laan: qt: use QMetaObject::invokeMethod for cross-thread signaling in clientmodel... 04:20 < GitHub117> bitcoin/master a60538b Wladimir J. van der Laan: Merge pull request #7143... 04:21 < 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 04:21 < GitHub161> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a60538bc456c...c0c08c7c68d0 04:21 < GitHub161> bitcoin/master aabc897 Wladimir J. van der Laan: rpc: Don't translate warning messages... 04:21 < GitHub161> bitcoin/master c0c08c7 Wladimir J. van der Laan: Merge pull request #7141... 04:21 < 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 04:22 -!- fkhan [weechat@gateway/vpn/mullvad/x-jknejhzccddmajjp] has joined #bitcoin-core-dev 04:28 < GitHub159> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/bc1f4275705a6aae03ce439cd317ec4166075c08 04:28 < GitHub159> bitcoin/master bc1f427 Wladimir J. van der Laan: qt: periodic translations update 04:32 < GitHub167> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bc1f4275705a...16f4a6e0fe26 04:32 < GitHub167> bitcoin/master cfdc662 Suhas Daftuar: Explicitly set chain limits in replace-by-fee test 04:32 < GitHub167> bitcoin/master 16f4a6e Wladimir J. van der Laan: Merge pull request #7137... 04:32 < 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 04:35 < 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 04:36 < MarcoFalke> wumpus try $ for i in {1..100}; do src/test/test_bitcoin --log_level=ALL --run_test=scheduler_tests;done 04:36 < MarcoFalke> Does this run fine? 04:37 < 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 04:37 < jonasschnelli> would it make sense to auto-choose a higher nDefaultDbCache in case bitcoind/qt detects more available ram? 04:37 < wumpus> (if so many people can reproduce them it doesn't mean much whether I can or not anyway...) 04:38 < wumpus> jonasschnelli: *up to a limit* 04:38 < jonasschnelli> I think for most modern server systems 100MB (current default) is very low. 04:38 < 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. 04:39 < jonasschnelli> Hmm... right... maybe its fine if the user just tweaks the -dbache manually. 04:39 < jonasschnelli> sipa asked about adding a option in Qt ("provide X MB of ram for bitcoin-qt")... 04:40 < 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 04:40 < jonasschnelli> hah. right. 04:41 < 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) 04:41 < wumpus> jonasschnelli: it could auto-select one based on some information gathered from the system 04:42 < jonasschnelli> Yes. That would be nice... 04:42 < wumpus> just make clear what the compromise is: sync is somewhat slower, but less RAM usage, sync is faster, but lots of RAM waste 04:43 < jonasschnelli> Is changing the cache size during runtime possible? (CCoinsViewDB), flushing, deleting pcoinsdbview and recreating it? 04:43 < wumpus> hm or maybe an option to reduce the dbcache after the initial sync? 04:43 < jonasschnelli> wumpus: this is a very good point. A big cache size mainly helps for IBD performance... 04:45 < 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 04:45 < wumpus> (dbcache is divided up between some caches, I don't know if they're all easy to resize/reconfigure) 04:46 < sipa> the leveldb cache may be harder to change 04:48 < jonasschnelli> sipa, LOCK, flush CCoinsViewDB, delete CCoinsViewDB, new CCoinsViewDB, UNLOCK? 04:48 < sipa> hell no 04:48 < wumpus> you don't need to delte it, you could just add a method to change the limit? 04:48 < jonasschnelli> :-) 04:49 < sipa> don't delete the cache! 04:49 < sipa> but you'll need to recalculate how much to assign to leveldb etc 04:49 < 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 04:50 < wumpus> yes, you need to recompute those 04:53 < wumpus> for leveldb it does seem you have to close and reopen the database to change the cache size 04:54 < GitHub180> [bitcoin] laanwj closed pull request #7063: [Tests] Add prioritisetransaction RPC test (master...add-prioritisetransaction-rpctest) https://github.com/bitcoin/bitcoin/pull/7063 04:54 < sipa> now it would be useful if someone would benchmark how much leveldb cache is optimal :) 04:55 < wumpus> right, it's very possible for there to be diminishing returns there sooner than for ccoinsviewcache 04:55 < sipa> the numbers that are in there now are only based on very simple (and outdated) benchmarks 05:02 < phantomcircuit> sipa, im guessing "more" 05:18 < wumpus> I would be surprised if it makes much of a difference at all 05:18 < tulip> I'm having a quick shot at testing it now. 05:19 < wumpus> ccoinsview cache is somewhat wasteful in memory but it's so much more effective, I don't think increasing leveldb cache can compete 05:20 < wumpus> (if it competes for the same bytes of memory) 05:21 < wumpus> and I'm even more in doubt about nBlockTreeDBCache's effectiveness 05:21 < wumpus> from the viewpoint of runtime, the block tree db is a write-only database 05:22 < wumpus> oh we take care of that // block tree db cache shouldn't be larger than 2 MiB 05:27 -!- rook520 [~rook520@c-71-194-206-169.hsd1.in.comcast.net] has quit [] 05:34 -!- MarcoFalke [8af6026b@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.107] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 05:41 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 05:55 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 245 seconds] 05:57 < GitHub68> [bitcoin] laanwj opened pull request #7144: test: Disable scheduler test manythreads (master...2015_12_disable_schedulertest) https://github.com/bitcoin/bitcoin/pull/7144 06:00 -!- jgarzik_ [~jgarzik@104-178-201-106.lightspeed.tukrga.sbcglobal.net] has quit [Changing host] 06:00 -!- jgarzik_ [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev 06:00 -!- jgarzik_ is now known as jgarzik 06:01 < jgarzik> What are the hurdles blocking relay of new blocks in pruned mode? 06:03 < tulip> would almost be nice to have a short, but intense "bench" chain of a few hundred blocks for testing configuration changes. 06:03 < phantomcircuit> jgarzik, not having NODE_NETWORK set is iirc the only one really 06:03 < tulip> problem with the main chain is that there's a bunch of empty which doesn't really represent the current load. 06:04 < jgarzik> My VPS has reached its space limit, and I want to continue contributing usefully to the network ;p 06:07 < 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) 06:08 < phantomcircuit> gettxoutsetinfo seems to walk but avoid the cache layer 06:13 < GitHub54> [bitcoin] jtimon opened pull request #7145: Mempool: Improve mempool's concurrency (master...mempool-estimator) https://github.com/bitcoin/bitcoin/pull/7145 06:14 < 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 06:16 < 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. 06:16 < jgarzik> phantomcircuit, older nodes that don't getheaders might get stuck in IBD? 06:17 < 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 06:17 < phantomcircuit> jgarzik, older peers would definitely get stuck 06:21 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds] 06:22 < phantomcircuit> hmm it seems the only way to "prime" the cache view is to reindex... 06:22 < 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 06:27 -!- tulip [~tulip@unaffiliated/tulip] has quit [] 06:28 < jgarzik> hmmm. !NODE_NETWORK should have no problem relaying blocks... they just won't get asked for them. 06:28 * jgarzik goes to test 06:29 < phantomcircuit> jgarzik, correct 06:29 < phantomcircuit> (probably) 06:32 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Ping timeout: 250 seconds] 06:34 < sdaftuar> jgarzik: the headers announcements PR should mean that pruned nodes can relay blocks just fine now 06:35 < sdaftuar> including if there's a reorg that isn't more than 8 blocks 06:36 < jgarzik> sdaftuar, for keeping !node_network you mean? Because otherwise that doesn't fix older nodes that would get stuck 06:36 < jgarzik> I wonder if we need NODE_RELAY 06:36 < sdaftuar> i'm specifically talking about relaying new blocks, not helping other nodes sync 06:36 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 06:37 < sdaftuar> ah are you asking what it would take to let pruned nodes serve up historical blocks? 06:38 < jgarzik> No just looking at all the angles of pruning with fresh eyes 06:39 < 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 06:39 < sipa> yes, locators are built from the block index 06:39 < sipa> they don't need the actual blocks 06:39 < sdaftuar> so i think 0.9 and earlier nodes will download blocks in a reorg from a pruned peer fine via their getblocks mechanism 06:39 < sdaftuar> we patched the getblocks response so that it won't return inv's for blocks that aren't on disk 06:40 < sdaftuar> 0.10 and 0.11 nodes will indeed not be able to download reorgs from pruned peers 06:40 < sdaftuar> 0.12 and later nodes should work fine for downloading reorgs from pruned peers, via the direct-fetch mechanism on headers messages 06:40 < sipa> will 0.10 and 0.11 get disconnected if they try? 06:40 < sdaftuar> they won't even try 06:41 < jgarzik> Sounds like pruned nodes should only announce blocks to >= 0.12 peers 06:41 < sipa> we still need granulatiy in the service flags 06:41 < sdaftuar> well there's not much harm in inv'ing the tip to 0.11 and earlier peers is there? 06:42 < sipa> as even 0.12 just won't connect to non-network nodes 06:42 < sipa> sdaftuar: it may hide problems, i wouldn't 06:42 -!- ParadoxSpiral [~ParadoxSp@p508B80ED.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 06:42 < jgarzik> thus the proposed NODE_RELAY 06:42 < sipa> sdaftuar: people may think that it works fine, until it doesn't due to reorg 06:43 < sdaftuar> hmm... we merged that change a long time ago (to relay the tip) 06:43 < sipa> oh well 06:44 < jgarzik> pruning defaults to off so nearly nobody uses it 06:44 < jgarzik> plenty of freedom to change 06:44 -!- CodeShark_ [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 260 seconds] 06:44 < 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? 06:44 < sipa> sdaftuar: that does seem reasonable 06:44 < sdaftuar> 0.11 didn't have relay on for pruning at all, so no expectations yet about how it should work i'd guess 06:45 < jgarzik> nod 06:45 < sdaftuar> it does needlessly harm 0.9 and 0.8 nodes... but probably not many of those left 06:46 < sipa> sdaftuar: what if there is a +8 deep reorg? 06:46 < sdaftuar> then we revert to inv 07:05 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection] 07:12 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 07:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 07:22 < phantomcircuit> Luke-Jr, fyi switching to longpoll significantly increased my latency 07:22 < phantomcircuit> by like 4 seconds 07:56 < sipa> in the test framework is there anything i need to do to call a new RPC? 07:57 < sipa> JSONRPC error: Method not found 07:57 < sipa> sounds like bitcoind actually doesn't have it? 07:57 < sipa> (this is for getblockheader) 07:58 -!- MarcoFalke [50edea04@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.4] has joined #bitcoin-core-dev 08:04 < GitHub55> [bitcoin] jtimon reopened pull request #7115: Mempool: Decouple CBlockPolicyEstimator from CTxMemPool (fix #6134) (master...6134-nits) https://github.com/bitcoin/bitcoin/pull/7115 08:12 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds] 08:22 < wumpus> sipa: no, should be nothing you have to do 08:23 < sipa> wumpus: i used a wrong variable name 08:23 < wumpus> okay 08:54 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 08:57 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has joined #bitcoin-core-dev 08:58 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Quit: leaving] 09:02 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 09:06 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev 09:10 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds] 09:38 -!- wangchun_ [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving] 09:39 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev 09:41 -!- Dyanisus [~Dyanisus@unaffiliated/dyanisus] has left #bitcoin-core-dev ["Leaving"] 09:46 -!- ParadoxSpiral_ [~ParadoxSp@p508B8A82.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 09:49 -!- ParadoxSpiral [~ParadoxSp@p508B80ED.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 09:53 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:07 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Remote host closed the connection] 10:09 -!- calibre720 [~calibre72@triband-mum-120.62.161.163.mtnl.net.in] has quit [Ping timeout: 245 seconds] 10:15 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 10:17 < GitHub38> [bitcoin] MarcoFalke opened pull request #7147: Univalue: Pull subtree (master...MarcoFalke-2015-univalueSync) https://github.com/bitcoin/bitcoin/pull/7147 10:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:23 < 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. 10:24 < jgarzik> Ideal goal is a lightweight router mode that contributes usefully to the network (subjective definition, I know) 10:28 < 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. 10:28 < GitHub29> [bitcoin] jtimon closed pull request #7115: Mempool: Decouple CBlockPolicyEstimator from CTxMemPool (fix #6134) (master...6134-nits) https://github.com/bitcoin/bitcoin/pull/7115 10:35 < GitHub119> [bitcoin] jtimon closed pull request #7145: Mempool: Improve mempool's concurrency (master...mempool-estimator) https://github.com/bitcoin/bitcoin/pull/7145 10:39 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 245 seconds] 10:39 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 10:51 < GitHub13> [bitcoin] MarcoFalke opened pull request #7148: [WIP] Run extended nightly builds in travis (master...travis/nightly) https://github.com/bitcoin/bitcoin/pull/7148 11:30 < 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 11:31 < GitHub90> [bitcoin] sipa pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/16f4a6e0fe26...4077ad20d03f 11:31 < GitHub90> bitcoin/master c49d5bc Alex Morcos: Store the total sig op count of a tx.... 11:31 < GitHub90> bitcoin/master f3fe836 Alex Morcos: Add a score index to the mempool.... 11:31 < GitHub90> bitcoin/master 7230187 Alex Morcos: Add TxPriority class and comparator 11:31 < GitHub194> [bitcoin] sipa closed pull request #6898: Rewrite CreateNewBlock (master...fasterCNB) https://github.com/bitcoin/bitcoin/pull/6898 11:31 < 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 11:42 -!- raedah [~raedah@mac0536d0.tmodns.net] has joined #bitcoin-core-dev 11:49 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 12:10 < morcos> sipa: woohoo thanks! now i can start changing it again. :) 12:11 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 12:17 < Luke-Jr> sigh, so I guess I'm going to need to strongly recommend miners not upgrade to 0.12? 12:18 < 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? 12:19 < morcos> For instance if you are not sending chains of txs, then there is no difference 12:20 < 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 12:20 < morcos> (or course assuming its not evicted before that) 12:20 < Luke-Jr> morcos: hm, that's a point.. and I guess the bad policy default (priority size = 0) can be overridden still 12:20 < Luke-Jr> 6357 appears to have been auto-closed by bad GitHub logic.. are you able to reopen it? 12:20 < morcos> yes i really don't think its that bad 12:22 < 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 12:22 < Luke-Jr> 7022 is pretty bad :/ 12: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. 12:23 < sipa> Luke-Jr: i really don't believe the existing priority system is worth maintaining; it is a burden on performance and maintainance 12:23 < Luke-Jr> in practice, it's more complexity in LOC/maintenance to have it NOT in master 12:23 < sipa> that's your view 12:24 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 12:24 < morcos> Luke-Jr: the complexity i'm concerned with is complexity of correctness 12:24 < sipa> i have no problem with creating a mechanism that takes coins value/age into account for prioritization, however 12:24 < Luke-Jr> sipa: that's my view, as the guy maintaining the mining stuff.. 12:24 < sipa> Luke-Jr: i know that's your view; i respectfully disagree, and i'm not alone 12:24 < morcos> sipa: i love it how even you have your irrational pet projects. :) 12:25 < sipa> morcos: if everything in bitcoin was rational, nobody would have started using it 12:26 < Luke-Jr> sipa: your disagreement appears to be about a cost that I bear specifically. 12:27 < 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 :) 12:28 < Luke-Jr> unless I have misunderstood that, I ask that my evaluation of my own costs be respected with a slightly higher weight :/ 12:28 < Luke-Jr> jgarzik: majority of miners have no business dictating what minority of miners do. and lots of miners *do* use the priority space. 12:28 < morcos> Luke-Jr: priority is irrepairably broken with 0.12 and limited mempools that don't respect it 12:28 < Luke-Jr> the miners who have disabled it, have done so because of the performance issues that are now fixed 12:28 < morcos> when we somehow decided to not address that or failed to decide to address it 12:29 < morcos> i think we put ourselves clearly on the path to removing priority 12:29 < Luke-Jr> morcos: I thought we had decided to address it, but nothing got done :p 12:29 < Luke-Jr> morcos: but if that's a serious issue, then it puts us back to "miners should not upgrade to 0.12" :/ 12:29 < 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 :) 12:30 < sipa> 0.12 will work with priority fine as a miner, if you have a sufficiently large mempool 12:30 < Luke-Jr> after what? 12:30 < jgarzik> heh 12:30 < Luke-Jr> sipa: that seems like a reasonable expectation of miners IMO 12:30 < morcos> Luke-Jr: working with the rest of the mempool/mining code will be much easier when priority is gone 12:31 < 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 12:31 < Luke-Jr> morcos: priority will never be gone 12:32 < morcos> it could theoretically be implemented by a quite complex companion program which just selectively applied feeDeltas i suppose 12:32 < Luke-Jr> morcos: it shouldn't need to be 12:33 < Luke-Jr> it should be as simple as it is now, or simpler. 12:33 < Luke-Jr> anything else is harmful to Bitcoin 12:34 < jgarzik> hyperbole 12:36 < 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? 12:36 < jgarzik> with the goal of #2 being avoiding all the current complexity that the consensus of devs agrees is there 12:37 < Luke-Jr> do I need to go make a big deal about this on reddit etc to prove (1)? 12:39 < Luke-Jr> (most people right now don't know anything about this discussion and won't understand it without explaining the details.) 12:39 < jgarzik> a CNB consumer = a CNB user = a miner 12:40 < jgarzik> It sounds like the ideal solution is a post-pass filter for applying some site local policy 12:40 < jgarzik> maybe a pre-pass filter for spam filtering 12:40 < jgarzik> (though 99% of that happens via IsStandard) 12:40 < sipa> jgarzik: so the scoring for CNB is just a single sort function now, that could be overridden to be anything 12:40 -!- MarcoFalke [50edea04@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.4] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 12:41 < sipa> jgarzik: priority is more complicated because it needs re-evaluation 12:41 < sipa> so anything that doesn't need re-evaluation would be trivial to do 12:41 < jgarzik> nod - post-pass - picks up stragglers fee didnt' 12:48 < 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 12:49 < morcos> but the main thing i keep coming back to is non fee based metrics are broken for other purposes 12:49 < morcos> relay 12:49 < morcos> mempool limiting 12:50 < 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 12:50 < morcos> and by fee based, i mean including feeDelta 12:51 -!- MarcoFalke [50edea04@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.4] has joined #bitcoin-core-dev 12:51 < Luke-Jr> morcos: you can't ensure anything with propagate ever 12:51 < 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 12:51 < morcos> also sdaftuar just pointed out feeDelta for trimming hasn't been merged yet, that should be tagged for 0.12 12:52 < 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 12:54 < morcos> but that would mean relaying based of feeDelta too 12:54 < sipa> i think that's reasonable 12:57 < sdaftuar> i can add a commit to 7062 to address that 13:05 -!- raedah [~raedah@mac0536d0.tmodns.net] has quit [Ping timeout: 250 seconds] 13:22 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev 13:26 -!- raedah [~raedah@mac0536d0.tmodns.net] has joined #bitcoin-core-dev 13:26 -!- raedah [~raedah@mac0536d0.tmodns.net] has quit [Remote host closed the connection] 13:42 < 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 13:42 < Luke-Jr> morcos: ^ 13:44 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Quit: Leaving] 13:49 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 13:56 -!- tulip [~tulip@unaffiliated/tulip] has quit [] 13:57 < 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..? 13:58 < 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 13:58 < sipa> Luke-Jr: by conflicting i mean conflicting with the chain 13:58 < Luke-Jr> sipa: I'm aware.. 13:58 < sipa> earlier, conflicting with the mempool was enough to get -1 confirms 13:58 < Luke-Jr> ah 13:59 < Luke-Jr> was that actually possible? O.o 13:59 < sipa> maybe it was very hard to reach that 14:00 < sipa> as the wallet tried to get its transactions in the mempool at startup 14:00 < Luke-Jr> I wonder if this should be considerd a bugfix and backported 14:00 < sipa> i agree the explanation there is confusing 14:01 < Luke-Jr> maybe with a min(-1) on the count 14:01 < sipa> it's mostly needed because of mempool eviction 14:01 -!- ParadoxSpiral_ [~ParadoxSp@p508B8A82.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 14:02 < sipa> so i wouldn't consider it a bugfix pre-0.12 14:03 < Luke-Jr> k 14:05 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 245 seconds] 14:05 < Luke-Jr> 7096 has me confused about whether it is a fix, part fix, or what :| 14:05 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev 14:11 -!- tulip [~tulip@unaffiliated/tulip] has joined #bitcoin-core-dev 14:13 < jtimon> ping #6625 14:15 -!- lecusemb1e [~lecusembl@f9beb4d9.violates.me] has quit [Ping timeout: 244 seconds] 14:16 -!- lecusemble [~lecusembl@f9beb4d9.violates.me] has joined #bitcoin-core-dev 14:21 < 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 14:22 -!- instagibbs [~instagibb@pool-108-31-210-40.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds] 14:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] 14:25 -!- instagibbs [~instagibb@pool-108-31-210-40.washdc.fios.verizon.net] has joined #bitcoin-core-dev 14:33 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 276 seconds] 14:39 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 14:44 < 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? 14:44 < gmaxwell> Luke-Jr: then that gets policy beyond the basic behavior out of bitcoind, and probably fixes all the performance concerns too. 14:44 < Luke-Jr> gmaxwell: that makes policy unnecessarily and gratuitously complicated to implement. 14:45 < Luke-Jr> and doesn't address the mempool side 14:45 < gmaxwell> But it's good because it makes it infinitely configurable without turning everyone into a bitcoind hacker. 14:45 < Luke-Jr> gmaxwell: I'm already working on an infinitely-configurable change that doesn't gratuitously complicate things.. but it takes time :/ 14:45 < gmaxwell> The eviction uses the modified score (feerate), no? so it's only ingress thats not addressed. 14:46 < 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. 14:46 < gmaxwell> And can't do things like so anti-spam analysis or what not because its in the critical path. 14:48 < Luke-Jr> gmaxwell: none of this is possible for 0.12 14:48 -!- arubi_ [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev 14:49 < gmaxwell> an external daemon would work with git master right now. 14:50 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 250 seconds] 14:52 -!- MarcoFalke [50edea04@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.4] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 15:02 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 15:22 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds] 15:40 -!- cocoBTC [~cocoBTC__@c-233a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Quit: Leaving] 15:41 -!- amiller_ [~socrates1@li175-104.members.linode.com] has quit [Ping timeout: 260 seconds] 15:42 -!- amiller [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev 15:42 -!- amiller is now known as Guest46010 15:50 < jgarzik> for ingress, pass firstseen rejected TXs to external as well 16:06 < GitHub81> [bitcoin] gmaxwell closed pull request #7100: Replace setInventoryKnown with a rolling bloom filter. (master...known_bloom) https://github.com/bitcoin/bitcoin/pull/7100 16:31 -!- Guest46010 is now known as amiller 16:31 -!- amiller [~socrates1@li175-104.members.linode.com] has quit [Changing host] 16:31 -!- amiller [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev 17:27 -!- JackH [~Jack@host-80-43-143-143.as13285.net] has quit [Quit: Leaving] 17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lmpkubwdmeoftnbu] has quit [Quit: Connection closed for inactivity] 17:49 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 17:51 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 18:37 -!- calibre720 [~calibre72@triband-mum-120.62.216.42.mtnl.net.in] has joined #bitcoin-core-dev 18:56 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:58 -!- calibre720 [~calibre72@triband-mum-120.62.216.42.mtnl.net.in] has quit [Ping timeout: 260 seconds] 19:03 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 19:04 < GitHub159> [bitcoin] gmaxwell closed pull request #7037: Move the blocknotify callback ahead of peer announcement. (master...notify_early) https://github.com/bitcoin/bitcoin/pull/7037 19:40 -!- calibre720 [~calibre72@triband-mum-120.62.211.218.mtnl.net.in] has joined #bitcoin-core-dev 19:57 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 245 seconds] 20:52 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds] 21:00 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev 21:11 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 260 seconds] 21:32 < Luke-Jr> dcousens: there is no consensus, when reasonable dissent remains. 21:32 < dcousens> Luke-Jr: well, this is a policy based thing isn't it? 21:33 < Luke-Jr> dcousens: yes, it doesn't strictly *need* consensus. Just saying. 21:33 < dcousens> and my point was, at least the impression from those IRC logs, was, that reasonable dissent didn't exist beyond your concerns 21:33 < gmaxwell> Luke-Jr: lets try to be productive and figure out something that works for everyone. 21:33 < dcousens> (not to down play your concerns at all, fwiw) 21:33 < Luke-Jr> dcousens: "reasonable dissent didn't exist beyond reasonable dissent" does not make sense. 21:34 < Luke-Jr> gmaxwell: I see no benefit whatsoever to changing the default policy in a way that is clearly harmful to Bitcoin. 21:34 < gmaxwell> Luke-Jr: right now with the mempool behavior, inserting priority back into the process has an astronomical performance hit that directly drives people shortcutting validation. That fact remains, as does the fact that priority is useful too. 21:34 < dcousens> well, I'm not in the position to say whether it was reasonable or not, 21:34 < gmaxwell> Luke-Jr: slow block generation is clearly harmful to Bitcoin, in a way which I think is worse than loss of priority. 21:35 < Luke-Jr> gmaxwell: that fact does not remain. The CNB rewrite fixed it. 21:35 < Luke-Jr> gmaxwell: priority no longer has any significant performance penalty 21:35 < gmaxwell> Luke-Jr: I thought you were also trying to undo the only compute priority at mempool entry change too? 21:36 < Luke-Jr> gmaxwell: that also is insignificant, but less concerning (other than the fact that it requires miners to apply code patches to fix) 21:36 < Luke-Jr> (I mean, fixing that also would not have a notable performance penalty) 21:37 < gmaxwell> Luke-Jr: 'accurate' priority requires traversing every free transaction in the mempool to build the block, even if only a few are included. 21:38 < gmaxwell> Luke-Jr: what is your view of the argument that priority is effectively only available to very few users; because most people don't have a stack of year old txouts stiting around? 21:40 < Luke-Jr> gmaxwell: specifically, https://github.com/bitcoin/bitcoin/pull/7149 fixes the priority calculation without adding any such loop to CNB 21:40 < jgarzik> how many tx per day get confirmed solely due to priority - measure field use 21:40 < Luke-Jr> gmaxwell: "Bitcoin only works for users with lots of bitcoins during spam attacks" is much better than "Bitcoin doesn't work during spam attacks period" 21:41 < gmaxwell> Luke-Jr: okay, I hadn't seen that PR. it might change my opinion. I think if we can prevent there from being bad performance or memory usage effects we should preserve it. 21:42 < Luke-Jr> it adds a dobule + unsigned int per mempooltx 21:42 < Luke-Jr> double* 21:42 < gmaxwell> Luke-Jr: Thus far, spending one or two _cents_ for an ordinary sized transaction has been more than enough to get it past all the spam attacks that I've looked at. 21:42 < gmaxwell> so I think the "doesn't work" is hyperbole, especially with the belief that most users simply don't have access to priority in the way that you or I do. 21:43 < dcousens> Luke-Jr: "doesn't work"? just add a higher fee? 21:43 < Luke-Jr> jgarzik: gmaxwell: that is the same kind of argument for skipping validation. the rate of attempted bogus blocks is zero, so why check them? 21:44 < Luke-Jr> dcousens: many people cannot add higher fees yet 21:44 < dcousens> Luke-Jr: why not? 21:44 < Luke-Jr> maybe in some post-RBF-wallet world, priority can safely be removed 21:44 < gmaxwell> Luke-Jr: I don't think it is; because the kind of harm caused is different. If there is no priority than no one has a strong assumption that there will be priority. 21:45 < dcousens> Luke-Jr: isn't that we're moving towards? 21:45 < Luke-Jr> dcousens: yes, but we're not there. 21:45 < gmaxwell> Luke-Jr: good argument. So you would point out that priority can rescue transactions which would otherwise be massively delayed absent the ability to revise their fees. 21:46 < gmaxwell> This sounds like something we could actually check. like how many transactions in blocks now (even ones cherry picked to be not-spam) would have been priority eligible at all; or would become eligible within 24-36 hours. 21:46 < dcousens> gmaxwell: indeed 21:46 < dcousens> morcos: ? :P 21:46 < gmaxwell> pfft; morcos is not our stats monkey. :) 21:46 < dcousens> haha 21:47 < Luke-Jr> we have a stats monkey? :o 21:47 < gmaxwell> (except for his own PRs :) ) 21:47 < gmaxwell> No, but perhaps we should. 21:47 < gmaxwell> but where will we get the suit? 21:48 < gmaxwell> in any case, I think if we can make an objective case that it has a use for people other than me and you, and we can prefer a performance hit.. then great. It would considerable extra work to maintain the functionality. (though this is my view; and wumpus is not around to kick my ass for it right now) 21:49 < gmaxwell> But if either of these things are not true; then we might have to swallow the pill. 21:53 < Luke-Jr> gmaxwell: I was not able to fully parse your longest line. 21:54 < gmaxwell> it would be worth performing extra work to maintain priority if the above two conditions (can do it without breaking performance; can show that it would be helpful for existing users under hypothetical attack conditions) 21:57 < tulip> I'm not sure I've seen any wallet software which actually takes priority into account when making a transaction. 21:58 -!- calibre720 [~calibre72@triband-mum-120.62.211.218.mtnl.net.in] has quit [Ping timeout: 250 seconds] 22:00 < Luke-Jr> tulip: it doesn't need to 22:01 < Luke-Jr> and at least my Bitcoin LJR wallet does (although I understand 0.12 won't) 22:02 < dcousens> Luke-Jr: I think tulip's point is, if the wallet doesn't account for it, then, likely, it'll probably just assume it needs to pay a higher fee under attack conditions anyway 22:02 < Luke-Jr> dcousens: there are no wallets that correctly figure the right fee :/ 22:02 < dcousens> Luke-Jr: what is the "right" fee? 22:02 < dcousens> its just something high enough, right? 22:04 < Luke-Jr> dcousens: more or less 22:04 < dcousens> well, the wallets I use usually have a 4c fee 22:04 < Luke-Jr> dcousens: most wallets just assume it's some fixed rate per kB, and can't take spam conditions into account at all 22:04 < dcousens> and I've never had an issue 22:05 < dcousens> Luke-Jr: eh, the ones I use `estimatefee` 22:05 < Luke-Jr> dcousens: this is tangent 22:05 < dcousens> agreed 22:05 * Luke-Jr ponders if there's any way to parallelize git bisect 22:11 -!- guest234234 [~guest2342@223.207.206.176] has joined #bitcoin-core-dev 22:12 < tulip> Luke-Jr: I think at least one popular wallet has a proxy for Bitcoin Cores estimatefee built in. 22:13 < Luke-Jr> estimatefee is not accurate during spam attacks 22:16 < tulip> then I suppose no wallet estimates fees correctly. 22:20 < gmaxwell> If an attack begins, the estimate may have been too low (though you need to overestimate if you are unable to replace); and then maybe priority saves you. 22:21 < dcousens> gmaxwell: so maybe we need a mempool reactive estimatefee? 22:22 < Luke-Jr> dcousens: that won't work if the spam starts after you send 22:22 < Luke-Jr> RBF is the only way to really fix this 22:23 < gmaxwell> estimatefee is mempool reactive, but it can't predict the future. 22:23 < dcousens> seems we were answering two different questions, I'm talking about: "what should my fee be right now" 22:24 < dcousens> you're talking about "what should my fee be to ensure no matter what happens, I get in the next block" 22:24 < dcousens> the latter isn't possible in market, so, the most you can do is "right now" + RBF 22:24 < Luke-Jr> dcousens: s/next block/next day/ or even next week 22:24 < Luke-Jr> "what should my fee be right now" makes no sense alone 22:25 < dcousens> "given the mempool" 22:25 < Luke-Jr> still 22:25 < dcousens> obviously your mempool is also subjective 22:25 < Luke-Jr> you need a *goal* 22:25 < dcousens> why? 22:25 < Luke-Jr> because without a goal, there is no "should be" at all 22:25 < Luke-Jr> might as well just do no fee, and wait for some generous miner to pick it up 22:25 -!- calibre720 [~calibre72@triband-mum-120.62.204.56.mtnl.net.in] has joined #bitcoin-core-dev 22:26 < dcousens> Luke-Jr: but you can't really reason about anything other than competing with other txs for the current block 22:26 < dcousens> if you say my goal is "within 3 blocks", its irrelevant 22:26 < Luke-Jr> … 22:27 < dcousens> its still always going to be within "the next block" 22:27 < Luke-Jr> sounds like you just defined your goal as "next block" 22:27 < dcousens> IMHO, that can be the only role of a fee 22:27 < Luke-Jr> … 22:28 -!- guest234234 [~guest2342@223.207.206.176] has quit [Ping timeout: 245 seconds] 22:28 < aj> dcousens: "one of the next dozen blocks" is perfectly reasonable. if you want to parse that as "the next block, or else the next block, or else the next block, ..." i guess that's equivalent... 22:28 < dcousens> "one of the next dozen blocks", but thats implying you can predict the future 22:28 < dcousens> which is to say, at some point, if not the next, the market is going to be less competetive 22:29 < gmaxwell> dcousens: the point is that you could target 6 blocks, then twelve blocks of higher paying spam suddenly show up. 22:29 < dcousens> gmaxwell: thats my point, saying I target 6 blocks makes no sense IMHO 22:29 < aj> dcousens: if a block is found in 2 minutes, there'll be less competition than for a block that's found after 1h30m 22:29 < dcousens> because, all that really matters is whats competeting for a block right now 22:29 < gmaxwell> dcousens: even if you target _now_ the next second 12 blocks worth of spam shows up. 22:29 < dcousens> gmaxwell: exactly 22:29 < gmaxwell> The estimator measures that competition retrospectively. 22:30 < dcousens> gmaxwell: which is why "right now" + RBF is the only solution 22:30 < dcousens> having a target other than "right now" is implying you can predict the future 22:30 < gmaxwell> it doesn't just say "how do I get N blocks into the pool" it says "transactions paying this much too how long?" 22:30 < gmaxwell> s/too/took/ 22:30 < gmaxwell> You can predict the future if the future is like the past; which is usually true. 22:30 -!- calibre720 [~calibre72@triband-mum-120.62.204.56.mtnl.net.in] has quit [Ping timeout: 260 seconds] 22:30 < gmaxwell> But you can't predict the black swans. 22:31 < dcousens> gmaxwell: until something like a spam attack happens 22:31 < dcousens> which is exactly why we're talking about this 22:31 < dcousens> and hence, if we're talking about how to 'correctly' estimate a fee, then, "right now" + RBF is your only true best chance 22:31 < gmaxwell> In any case, luke believes that priority is actually a useful backstop. It's certantly something that is hard for attacks to abuse, at least. 22:32 < gmaxwell> dcousens: even N blocks + RBF is fine. N blocks, assuming nothing changes; and RBF for those times when it does. 22:33 < gmaxwell> (keep in mind that mining is a posson process; as is new transaction entry. N blocks really does make sense statistically) 22:33 < dcousens> gmaxwell: only if transaction priority/age matters 22:33 < gmaxwell> No. 22:34 < gmaxwell> Paying for block N, N>0 is making a bet on the rate of block finding and/or the rate of new transactions showing up. 22:34 < dcousens> if 6 blocks have even competition, aka, the mempool is consistently full, they'll just continually skim the top of the pile, if you fail to make it over that threshold, no matter what your prediction was originally, you won't make it in? 22:35 < dcousens> N blocks only makes sense if the system wasn't changing after your entry? 22:35 < gmaxwell> Thats why the estimator is based on past performance. 22:36 < dcousens> gmaxwell: which is why its a prediction, and not necessarily a 'correct' estimate :) 22:36 < gmaxwell> You can look at it as the question, because of variance in tx entry and block findinging; mining goes deeper into the mempool with declining probablity the deeper it goes. 22:37 < Luke-Jr> dcousens: right now, to get the next block, you need a fee like 0.88 mBTC; but if you're okay with up to 25 blocks, 0.01 mBTC is probably fine 22:37 < gmaxwell> Yes, and thats where the RBF and CPFP come in. They let you use a prediction without grave outcomes. 22:37 < Luke-Jr> and these are just small numbers 22:37 < Luke-Jr> it makes a lot more sense to target 1, 144 (24 hours), or 1008 (1 week) blocks 22:38 < Luke-Jr> IMO 22:38 < Luke-Jr> the difference is fees needed for those is likely to be even more pronounced 22:38 < gmaxwell> well 1008 is unfortunately incompatible with current mempool policy but I hope we improve that in the future. (e.g. be being able to save the mempool to disk) 22:38 < Luke-Jr> yes, I'm just saying ideally 22:38 < gmaxwell> (and by changing the 72 hour timeout to 1week for RBF transactions) 22:39 < Luke-Jr> also once there's RBF for continually re-estimating fees needed, estimates can be a lot less accurate 22:39 < Luke-Jr> can afford to be* 22:39 < gmaxwell> As I've pointed out before, if the load has a cycle with period Q, then you cannot make efficient use of the system without at least Q worth of storage... and there clearly is a weekly cycle in load. 22:40 < Luke-Jr> 1 GB of storage just for the mempool, with 1 MB blocks.. :x 22:40 < Luke-Jr> maybe I should be trying to solve this in my mempool work 22:41 < Luke-Jr> s/solve/make this reasonably possible without RAM/ 22:41 < gmaxwell> well I think thats not really a big deal; mempool shouldn't be in ram. 22:41 < Luke-Jr> right.. that's what I mean 22:41 < dcousens> gmaxwell: the rational miner algorithm is just: mempoolTxs.sort(byFee).takeAtMost(marketDerivedN) (with size in there somewhere), therefore, if you want to get in the blockchain, you just need to be in that cut, why would a miner care about how long a transaction has been waiting for? 22:41 < Luke-Jr> maybe I should restart my mempool changes, and this time move it to disk in the proces 22:42 < gmaxwell> dcousens: it doesn't. But reality cares. More time means greater odds that there were a number of fast blocks that cleared out the backlog. 22:42 < gmaxwell> (faster than new high fee tx arrived) 22:43 -!- calibre720 [~calibre72@triband-mum-120.62.243.235.mtnl.net.in] has joined #bitcoin-core-dev 22:43 < dcousens> gmaxwell: assuming a constant tx rate 22:44 < gmaxwell> e.g. you want to get in within 25 blocks, what you end up paying would put you (say) 4 blocks deep in the mempool, but given new tx coming in, it was 12 blocks out before miners got lucky enough that you were in the top $blocksize. 22:44 < dcousens> which still puts it as a prediction, versus just persistently watching the pool and instead competeting the entire time (no guarantee still, obv, but, its probably the most 'correct') 22:44 < gmaxwell> or 12 blocks out before the rate of tx coming in hit a slump, or a mixture of the two. 22:44 < gmaxwell> yes, indeed. well replacements have a cost with RBF... as you must increment by at least the entry amount. 22:44 < gmaxwell> and you lose privacy when you use it. 22:45 < gmaxwell> (it identifies your change) 22:45 < dcousens> what's the privacy lost? 22:45 < dcousens> nvm 22:46 < gmaxwell> so I think being somewhat forward looking still make sense even with RBF. 22:47 < dcousens> gmaxwell: indeed, its probably your best bet 22:47 < dcousens> uh, a good bet* 22:47 < dcousens> but you're best bet would be alternative 22:47 < dcousens> but obviously it'll probably cost you more etc 22:48 < gmaxwell> I mean, many things are possible including the possiblity of having an totally different unconfirmed transaction market mechenism. Like some server over tor that people connect to and do a great big auction to agree on fees and make a great big coinjoin to subit to the miners as a unit. :P 22:49 < dcousens> haha, that'll be the day 22:49 < dcousens> and yeah, the coinjoin would subvert the orthogonal issue of privacy loss during RBF 22:49 < dcousens> at least, the loss of privacy to the network 22:49 < gmaxwell> also the fact that you'd agree on .. right. 22:49 < gmaxwell> I mean, this is effectively what joinmarket is... well joinmarket is the MVP version of that. 22:50 < aj> gmaxwell: oh, wow, a bitcoin user's union putting the screws into the Big Business of corporate mining! 22:50 < gmaxwell> aj: the word is "buyers cartel" 22:50 < dcousens> haha 22:50 < aj> gmaxwell: maybe in the literature, but that's not how you market it man! 22:51 < gmaxwell> my earliest posts on bitcoin talk were worrying about mining cartels driving up fee prices, then I realized buyers cartels were possible too and worried less about that. :P 22:52 < gmaxwell> an interesting thing you can do is do the bidding for fees and then round robin distribute them to transactions, so that the miners just see N transactions which each page the average feerate, and can't cherrypick the higer paying bidders. 22:53 < GitHub195> [bitcoin] posita opened pull request #7152: Add missing automake package to deb-based UNIX install instructions. (master...posita/fix-doc-build-unix) https://github.com/bitcoin/bitcoin/pull/7152 22:55 < GitHub77> [bitcoin] jonasschnelli closed pull request #6997: Don't use hard-coded AllowFree, as this is usually far too low. (master...no-default-free-priority) https://github.com/bitcoin/bitcoin/pull/6997 23:20 -!- MarcoFalke [50edea04@gateway/web/cgi-irc/kiwiirc.com/ip.80.237.234.4] has joined #bitcoin-core-dev 23:27 -!- calibre720 [~calibre72@triband-mum-120.62.243.235.mtnl.net.in] has quit [Ping timeout: 260 seconds] 23:32 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 245 seconds] 23:34 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 23:37 < GitHub128> [bitcoin] jonasschnelli opened pull request #7153: [Tests] Add mempool_limit.py test (master...2015/12/mempool-test) https://github.com/bitcoin/bitcoin/pull/7153 23:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ikoglgjuqhnknwbd] has joined #bitcoin-core-dev 23:40 < GitHub61> [bitcoin] jonasschnelli opened pull request #7154: [Qt] add InMempool() info to transaction details (master...2015/12/qt_conflicts) https://github.com/bitcoin/bitcoin/pull/7154 23:41 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]