12016-01-05T00:19:27 *** jcorgan|torture is now known as jcorgan
22016-01-05T00:30:10 *** MarcoFalke has quit IRC
32016-01-05T00:31:30 *** brg444 has joined #bitcoin-core-dev
42016-01-05T01:04:34 *** Ylbam has quit IRC
52016-01-05T01:32:32 *** jtimon has quit IRC
62016-01-05T01:42:48 *** afk11 has joined #bitcoin-core-dev
72016-01-05T01:49:18 *** afk11 has quit IRC
82016-01-05T02:16:13 *** afk11 has joined #bitcoin-core-dev
92016-01-05T03:02:45 <morcos> wumpus: MarkoFalke: what is the intended purpose of mintxfee? I was just looking back at the changes where Marco introduced GetRequiredFee, which was maybe a step in the right direction, but maybe not the proper fix.
102016-01-05T03:03:38 <morcos> Perhaps I also changed this in my estimateSmartFee PR, but i don't think so, anyway, minTxFee is not actually a minTxFee
112016-01-05T03:04:02 <morcos> it only serves as that if you are not using fee estimation or fee estimation can not return a result
122016-01-05T03:06:00 <morcos> I'm asking this because I think we should change the default value that gets used if fee estimation can't give you an answer. As rusty was pointing out in bitcoin-dev, 1000 sat/KB is just too small
132016-01-05T03:06:57 <morcos> And since this number is rarely used, i think its fine if its significantly higher, say at least 10000 sat/KB. But then I think all of the comments in the QT code are misleading, because you might often be paying a fee less than this and not depending on priority
142016-01-05T03:08:19 <morcos> Anwyay, super annoying since these are probably all translation strings, so maybe we can't fix the UI confusion for 0.12. But I still think its worth bumping the default, you don't want to fall back to 1000 sat/KB before yoru fee estimates warm up
152016-01-05T03:10:33 *** Watcher2 has joined #bitcoin-core-dev
162016-01-05T03:15:20 *** Watcher2 has left #bitcoin-core-dev
172016-01-05T03:18:01 *** afk11 has quit IRC
182016-01-05T03:32:49 *** p15 has joined #bitcoin-core-dev
192016-01-05T03:44:34 *** Cory has quit IRC
202016-01-05T03:46:49 *** Pasha has joined #bitcoin-core-dev
212016-01-05T03:53:43 *** Pasha is now known as Cory
222016-01-05T04:22:25 *** brg444 has quit IRC
232016-01-05T04:32:10 *** Cory has quit IRC
242016-01-05T04:34:00 *** Pasha has joined #bitcoin-core-dev
252016-01-05T04:40:54 *** Pasha is now known as Cory
262016-01-05T05:00:03 *** dermoth has quit IRC
272016-01-05T05:00:31 *** dermoth has joined #bitcoin-core-dev
282016-01-05T05:13:25 *** [2]evoskuil has joined #bitcoin-core-dev
292016-01-05T05:15:06 *** evoskuil has quit IRC
302016-01-05T05:15:06 *** [2]evoskuil is now known as evoskuil
312016-01-05T05:21:02 *** droark has joined #bitcoin-core-dev
322016-01-05T05:36:00 *** dcousens_ is now known as dcousens
332016-01-05T05:40:46 *** arowser has quit IRC
342016-01-05T05:41:16 *** arowser has joined #bitcoin-core-dev
352016-01-05T05:52:00 *** cryptopeddler has quit IRC
362016-01-05T05:53:29 *** cryptopeddler has joined #bitcoin-core-dev
372016-01-05T06:20:20 *** p15_ has joined #bitcoin-core-dev
382016-01-05T06:23:32 *** p15 has quit IRC
392016-01-05T06:27:38 *** Ylbam has joined #bitcoin-core-dev
402016-01-05T07:21:54 *** adam3us has quit IRC
412016-01-05T07:45:56 *** Cory has quit IRC
422016-01-05T07:47:12 *** Thireus has joined #bitcoin-core-dev
432016-01-05T07:48:06 *** Pasha has joined #bitcoin-core-dev
442016-01-05T07:53:38 *** Thireus has quit IRC
452016-01-05T07:54:59 *** Pasha is now known as Cory
462016-01-05T07:55:46 *** p15_ has quit IRC
472016-01-05T08:05:54 *** p15 has joined #bitcoin-core-dev
482016-01-05T08:22:48 *** adam3us has joined #bitcoin-core-dev
492016-01-05T08:24:01 *** Alopex has quit IRC
502016-01-05T08:25:06 *** Alopex has joined #bitcoin-core-dev
512016-01-05T08:36:16 *** murch has joined #bitcoin-core-dev
522016-01-05T08:37:29 *** BashCo has quit IRC
532016-01-05T08:48:19 *** paveljanik has quit IRC
542016-01-05T08:48:36 *** JackH has joined #bitcoin-core-dev
552016-01-05T08:56:52 *** BashCo has joined #bitcoin-core-dev
562016-01-05T09:32:20 *** xiangfu has quit IRC
572016-01-05T09:41:34 *** jtimon has joined #bitcoin-core-dev
582016-01-05T09:55:03 *** p15_ has joined #bitcoin-core-dev
592016-01-05T09:57:35 *** p15 has quit IRC
602016-01-05T10:03:42 *** adam3us has quit IRC
612016-01-05T10:08:27 *** Thireus has joined #bitcoin-core-dev
622016-01-05T10:32:53 *** zookolaptop has joined #bitcoin-core-dev
632016-01-05T10:54:46 *** zookolaptop has quit IRC
642016-01-05T10:58:26 *** adam3us has joined #bitcoin-core-dev
652016-01-05T11:05:13 <GitHub141> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/45d13abf4ea1...a10a7920c3ac
662016-01-05T11:05:14 <GitHub141> bitcoin/master 5246180 Suhas Daftuar: Mark blocks with too many sigops as failed
672016-01-05T11:05:14 <GitHub141> bitcoin/master a10a792 Wladimir J. van der Laan: Merge pull request #7217...
682016-01-05T11:05:23 <GitHub105> [bitcoin] laanwj closed pull request #7217: Mark blocks with too many sigops as failed (master...fix-sigops-rejection) https://github.com/bitcoin/bitcoin/pull/7217
692016-01-05T11:05:56 <GitHub58> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/e08b7cb33ca30e03a4fda2eb13fc101628907258
702016-01-05T11:05:56 <GitHub58> bitcoin/0.12 e08b7cb Suhas Daftuar: Mark blocks with too many sigops as failed...
712016-01-05T11:10:01 *** MarcoFalke has joined #bitcoin-core-dev
722016-01-05T11:11:20 *** zookolaptop has joined #bitcoin-core-dev
732016-01-05T11:16:36 <MarcoFalke> morcos, I agree 1000 sat/KB is too low. About your question: GetRequiredFee() returns whatever is higher: the minRelayTxFee (which is needed due to the mempool) or the mintxfee (which is what the user may have set in his settings)
742016-01-05T11:18:49 <MarcoFalke> Personally I don't use fee estimates and my .conf has a hardcoded mintxfee which just fits my time-cost-tradeoff just fine.
752016-01-05T11:19:41 <MarcoFalke> I was planning to writeup about the "hard" fees in the release notes but if you are planning to change the notion of mintxfee, please let me know
762016-01-05T11:20:51 <MarcoFalke> wumpus, anything holding back 7193 ?
772016-01-05T11:31:09 *** Guyver2 has joined #bitcoin-core-dev
782016-01-05T11:37:14 <wumpus> MarcoFalke: huh, "pruning" is kind of ambigious in this context
792016-01-05T11:38:38 <wumpus> test looks good to me though
802016-01-05T11:38:55 <MarcoFalke> Should have been merged as part of the pull that introduced "pruning"
812016-01-05T11:39:58 <wumpus> let's not call it pruning please
822016-01-05T11:40:15 *** laurentmt has joined #bitcoin-core-dev
832016-01-05T11:41:00 *** laurentmt has quit IRC
842016-01-05T11:41:42 *** zookolaptop has quit IRC
852016-01-05T11:44:23 <wumpus> so #7193 fixes the test so that it actually tests what it purports to test
862016-01-05T11:45:35 <wumpus> what do you mean with "pruning must fail on 0.12"?
872016-01-05T11:45:59 <wumpus> *this test* must fail on 0.12?
882016-01-05T11:46:25 <wumpus> and succeed on master?
892016-01-05T11:46:59 <MarcoFalke> It must fail where trimming was not yet implemented
902016-01-05T11:47:13 <MarcoFalke> It must pass when (and after) trimming was implemented
912016-01-05T11:47:27 <wumpus> right - the test, not the process itself
922016-01-05T11:47:31 <wumpus> ok then I understand, thanks ;)
932016-01-05T11:49:36 <MarcoFalke> oops, was a typo in my comment
942016-01-05T11:52:32 *** AtashiCon has quit IRC
952016-01-05T11:52:36 *** Arnavion3 has joined #bitcoin-core-dev
962016-01-05T11:52:40 *** Arnavion3 is now known as AtashiCon
972016-01-05T11:54:02 <morcos> MarcoFalke: If you want to use a preset fee, then why do you use mintxfee and not paytxfee?
982016-01-05T11:55:05 <GitHub45> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a10a7920c3ac...2078495d9c5f
992016-01-05T11:55:05 <GitHub45> bitcoin/master fafd093 MarcoFalke: [wallet] Adjust pruning test
1002016-01-05T11:55:06 <GitHub45> bitcoin/master 2078495 Wladimir J. van der Laan: Merge pull request #7193...
1012016-01-05T11:55:11 <GitHub159> [bitcoin] laanwj closed pull request #7193: [wallet] Cleanup tests (master...MarcoFalke-2015-WalletTests) https://github.com/bitcoin/bitcoin/pull/7193
1022016-01-05T11:55:53 <morcos> I guess my point was what is the intended use of mintxfee? it seems to function now mostly as the fall back default. it does not appear to serve as a min otherwise? but i'm not sure i'd fully thought through all the different fee configurations
1032016-01-05T11:56:06 <wumpus> I'm not entirely sure either
1042016-01-05T11:56:40 <btcdrak> oh finally some life
1052016-01-05T11:56:47 <btcdrak> was really quiet here this morning :)
1062016-01-05T11:56:48 <MarcoFalke> morcos, paytxfee can be set via settxfee
1072016-01-05T11:57:01 <MarcoFalke> If you happen to settxfee too low, you might want a fall back
1082016-01-05T11:57:17 <MarcoFalke> That's what I was guessing why it was there, but your concern is valid
1092016-01-05T11:58:21 <MarcoFalke> so mintxfee is the "hardcoded" minimum whereas paytxfee is your "dynamic choice"
1102016-01-05T11:58:34 <morcos> MarcoFalke: yeah ok , so thats a bit what i was afraid of
1112016-01-05T11:58:53 <morcos> for someone like you, you would not want mintxfee to be set to say 20000 satoshis
1122016-01-05T11:59:10 <morcos> because you would want the freedom to choose below that sometimes
1132016-01-05T11:59:22 <GitHub162> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/bfdaa3c87f6054b0b1e617031d6a8f02cdfc99dd
1142016-01-05T11:59:22 <GitHub162> bitcoin/0.12 bfdaa3c MarcoFalke: [wallet] Adjust pruning test...
1152016-01-05T11:59:50 <morcos> but for someone using fee estimation, they'd probably rather it fall back to something that pays a bit too much rather than the other way aroud. as it only gets used very rarely
1162016-01-05T12:01:01 <morcos> I mean luckily it is command line settable also
1172016-01-05T12:02:11 <morcos> so no reason to obsesses on it now, and just pick something that is more sensible than 1000
1182016-01-05T12:02:17 <GitHub107> [bitcoin] jonasschnelli pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/aa413687de45ef9add61f97447532a87bd2b2bb7
1192016-01-05T12:02:18 <GitHub107> bitcoin/master aa41368 Jonas Schnelli: Merge pull request #7282...
1202016-01-05T12:02:26 <GitHub75> [bitcoin] jonasschnelli closed pull request #7282: [Qt] fix coincontrol update issue when deleting a send coins entry (master...2016/01/qt_cc_fee) https://github.com/bitcoin/bitcoin/pull/7282
1212016-01-05T12:05:54 <MarcoFalke> jonas, is this a backport as well?
1222016-01-05T12:08:54 <GitHub51> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/5cadf3eb60ddc630d9e749f7a92e51d07d2e614a
1232016-01-05T12:08:54 <GitHub51> bitcoin/0.12 5cadf3e Jonas Schnelli: [Qt] fix coincontrol update issue when deleting a send coin entry...
1242016-01-05T12:37:02 <MarcoFalke> jonasschnelli, how can I trigger the welcome dialog of qt?
1252016-01-05T12:37:09 <MarcoFalke> firts-start dialog
1262016-01-05T12:40:06 <wumpus> -choosedatadir
1272016-01-05T12:43:32 *** p15_ has quit IRC
1282016-01-05T13:11:55 <GitHub66> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/aa413687de45...605c17844ea3
1292016-01-05T13:11:56 <GitHub66> bitcoin/master fa6ad85 MarcoFalke: [devtools] Rewrite fix-copyright-headers.py
1302016-01-05T13:11:57 <GitHub66> bitcoin/master fa24439 MarcoFalke: Bump copyright headers to 2015
1312016-01-05T13:11:57 <GitHub66> bitcoin/master fa71669 MarcoFalke: [devtools] Use git pretty-format for year parsing
1322016-01-05T13:12:00 <GitHub122> [bitcoin] laanwj closed pull request #7205: Update copyright headers to 2015 (master...MarcoFalke-2015-BumpHeaders-0.12) https://github.com/bitcoin/bitcoin/pull/7205
1332016-01-05T13:14:20 <GitHub179> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/333e1eaeea80344e5a28db6efbce2691c85e2b25
1342016-01-05T13:14:20 <GitHub179> bitcoin/0.12 333e1ea MarcoFalke: Bump copyright headers to 2015...
1352016-01-05T13:17:42 *** arowser has quit IRC
1362016-01-05T13:18:14 *** arowser has joined #bitcoin-core-dev
1372016-01-05T13:45:20 <jtimon> wumpus I'm still on vacation and kind of waiting on #7091 before continuing with the "document-with-words-and-pictures" I promised to some people, but...what is the "right time for refactors and moveonlies"? I really don't want to miss it for the consensus encapsulation moveonly again
1382016-01-05T13:46:25 <jtimon> I mean something like this https://github.com/jtimon/bitcoin/commit/f8c34f27d4020880647cbdbafad70793882cef79 (after #7287 )
1392016-01-05T13:49:38 <jtimon> it was supposed to be after major version forks, right? or is it after the major released is actually done (to avoid interfering with backports)?
1402016-01-05T13:53:33 *** Quent1 has joined #bitcoin-core-dev
1412016-01-05T13:56:26 *** Quent has quit IRC
1422016-01-05T14:21:30 <morcos> wumpus: are you completely opposed to adding a new command line argument for 0.12. -defaulttxfeeifnoestimate (or something)
1432016-01-05T14:21:44 <morcos> I think it makes a lot of sense for this to be a different value than -mintxfee
1442016-01-05T14:22:12 <morcos> and then we can actually make fee estimate generated fees respect -mintxfee (which they currently don't)
1452016-01-05T14:22:56 <morcos> I would then advocate that there is no need to change -mintxfee right now, we can leave it at 1000, but should someone desire to never ever send fees that low, they can bump that number
1462016-01-05T14:23:07 <morcos> and it'll prevent them from doing so, regardless of how they pick their fees
1472016-01-05T14:23:32 <morcos> -defaulttxfeeifnoestimate will only come into play if you're trying to use estimates and you can't
1482016-01-05T14:23:59 <morcos> (uh not exactly, if you're trying to use estimates and you can't get an estimate for the value you are asking for, it'll make sure you pay at least that much)
1492016-01-05T14:24:16 <maaku> we shouldn't be pulling numbers out of a hat for fees, mintxfee or defaulttxfeeifnoestimate or otherwise
1502016-01-05T14:24:33 <morcos> so if for example you try to estimatefee 1, and it can only give you an answer for 2 and says its 25000 satoshis, but the default is 40000, then it'll make you pay 40000 in that case
1512016-01-05T14:24:43 <morcos> but if you asked for 2, and got 25000 at 2, then thats fine
1522016-01-05T14:24:55 <morcos> maaku: if you have no estimates (on startup) you have to pull numbers from a hat
1532016-01-05T14:25:27 <maaku> morcos: or you can disable transaction creation until the fee estimator is primed
1542016-01-05T14:25:34 <MarcoFalke> morcos, I'd be fine with setting mintxfee to 5000 or 10000 and mention in the release notes that ppl can change it.
1552016-01-05T14:25:35 <morcos> my point is this is a relatively rare occurence, but makes much more sense to have it do something sane, than ridiculous (right now it defaults to mintxfee in all the cases i mentioned)
1562016-01-05T14:25:46 <maaku> although hopefully soon we will have the consensus changes needed to prime estimation on startup
1572016-01-05T14:26:11 <morcos> MarcoFalke: I think what I proposed makes a lot more sense, because it seems to me peole might say, you know what, i odn't care what fee estimation says i always want to pay at least X
1582016-01-05T14:26:12 <MarcoFalke> And also adjust the GUI to show the GetRequiredFee() for estimates, in case it does not yet do this
1592016-01-05T14:26:13 <aj> morcos: it'd seem more user-friendly to actually say "i don't know what fee you need to get into the next block" in that case
1602016-01-05T14:26:21 <morcos> so giving them a way to do that with -mintxfee is valuable
1612016-01-05T14:26:30 <maaku> morcos: defaulttxfeeifnoestimate seems just as crazy
1622016-01-05T14:27:13 <morcos> aj: its not just gui, if you just do sendtoaddress() from RPC, you don't get a chance for feedback, what does it default to
1632016-01-05T14:27:21 <morcos> and even in the gui, what should it default to if it doesn't know
1642016-01-05T14:27:29 <morcos> maaku: why is that crazy
1652016-01-05T14:27:40 <aj> morcos: RPC can give an error back :)
1662016-01-05T14:27:58 <maaku> morcos: it's another number that could be just as wrong, with either too high a fee (users get angry) or too low a fee (users get stuck)
1672016-01-05T14:28:23 <morcos> what we've done is moved from a regime where we always hard code a default fee to a regime where we use a fee by fee estimation the vast majority of the time, except when its impossible to
1682016-01-05T14:28:30 <morcos> and then we should have a sane default
1692016-01-05T14:28:30 <maaku> better to just give an error, or in the GUI a window to enter a manual fee
1702016-01-05T14:28:44 <morcos> you guys, fee estimation is not that perfect
1712016-01-05T14:29:13 <morcos> you can't just depend on it always giving you the right answer, bitcoind/-qt needs to be workable if feeestimation isn't working
1722016-01-05T14:30:02 <morcos> for instance what you are describing would be impossible on regtest or testnet which often don't have any estimates
1732016-01-05T14:30:45 <aj> morcos: it would make sense being able to explicitly set a fee for the transaction (whether GUI or RPC/cmdline), but otherwise having fee estimation always working would be a better goal...
1742016-01-05T14:31:03 <morcos> its a much bigger change to eliminate fall back to default (and a worse change). i'm just trying to make it fall back to a more sane default. and i think its better to do that with a new variable, rather than misuse mintxfee
1752016-01-05T14:31:25 <morcos> aj: that is the goal
1762016-01-05T14:31:48 <morcos> but if its not working some small % of the time, then what should you do?
1772016-01-05T14:32:26 <MarcoFalke> morcos, can you elaborate again what the difference in UX is in regard to defaulttxfeeifnoestimate vs mintxfee
1782016-01-05T14:32:30 <MarcoFalke> What is "misuse"?
1792016-01-05T14:33:27 <MarcoFalke> The default is: "Estimate the fee to get into <n> blocks, where <n> is user set."
1802016-01-05T14:33:34 <morcos> MarcoFalke: So in the case of a user trying to use fee estimation. Right now mintxfee does not apply if fee estimation returns an answer, but if fee estimation can not return an answer for the target you are asking about, it gives you the max(any answer it did get, mintxfee).
1812016-01-05T14:33:34 <aj> morcos: if i expect something to be working 100% of the time, then i want an error when it's not, not silently different behaviour. (ymmv)
1822016-01-05T14:34:35 <morcos> MarcoFalke: I think the correct behavior for a user trying to use fee estimation is . If you cna't get a proper answer fee = max(answer you got, defaultfeeifnoestimate). And in all cases, the fee is maxed with mintxfee.
1832016-01-05T14:35:02 <morcos> MarcoFalke: So there are 2 effective changes. It'll fall back to a more sane default and if you want to set a floor for feeestimation generated txs, you can do so now.
1842016-01-05T14:36:42 <morcos> aj: So what would you like fee estimation to do if you say "estimatefee 1" and it can only give you an answer for "estimatefee 25". Silently let you send a tx expected to be confirmed in 25 blocks.
1852016-01-05T14:37:06 <aj> morcos: i would like an error saying "best estimate is for 25 blocks"
1862016-01-05T14:38:08 <aj> morcos: ie an error -- no transaction sent. "manual" intervention required. (well, if it's RPC it could be automated by some other script, whatever)
1872016-01-05T14:38:45 <morcos> aj: there is currently no way to set the txconfirmtarget via rpc, so then you would get stuck in a position where you can't send any txs period
1882016-01-05T14:39:51 <MarcoFalke> agree that the rpc error is no solution
1892016-01-05T14:40:12 <morcos> sendtoaddress() is meant to just send the damn tx and do something smart for me
1902016-01-05T14:40:14 <aj> morcos: (i'd rather have txconfirmtarget set as an optional parameter to sendtoaddress)
1912016-01-05T14:40:51 <morcos> aj: i'm trying to patch up 0.12. we can't rework the entire way fee estimation and wallet txs work for that
1922016-01-05T14:41:10 <MarcoFalke> morcos, You were right that GetRequiredFee() is ignored. (I somehow had it differently in mind)
1932016-01-05T14:41:19 <morcos> i'm just trying to avoid a situation where people routinely send txs of too low fee when they just start their nodes up
1942016-01-05T14:41:20 <MarcoFalke> So you'd disagree to move nFeeNeeded = std::max(nFeeNeeded, GetRequiredFee(nTxBytes)); furher down
1952016-01-05T14:41:54 <MarcoFalke> (right in the line before return?)
1962016-01-05T14:41:59 <morcos> MarcoFalke: I do think we should do that as long as we're not also trying to make mintxfee a sane default. as long as its a min, then we should do that. but we need a saner default
1972016-01-05T14:42:07 <aj> morcos: well, i'm talking about what i /want/, not necessarily what's easy/possible :)
1982016-01-05T14:42:27 <morcos> aj: well can you help us try and figure out what we should do for 0.12 instead
1992016-01-05T14:45:43 <morcos> MarcoFalke: I don't think it ever respect mintxfee in the event an estimate was given. (and technically it doesn't need to respect minrelaytxfee b/c its not possible to have an estimate less than that). But yes, lets make it respect both via GetRequiredFee, but then give people a way to have a sane default, which doesn't require that all their fees be at least that default
2002016-01-05T14:46:44 <morcos> These will be very minor changes. Move the GetRequiredFee and add a new commandline argument. It almost doesn't really matter if its not communicated very well b/c translations are closed or whatever. It's a default that only applies rarely.
2012016-01-05T14:50:18 <GitHub110> [bitcoin] MarcoFalke opened pull request #7295: [WIP] Obey mintxfee on txconfirmtarget, Bump mintxfee (master...Mf1601-wallet-mintxfee) https://github.com/bitcoin/bitcoin/pull/7295
2022016-01-05T14:50:22 <MarcoFalke> this is what I thought.
2032016-01-05T14:50:50 <MarcoFalke> Haven't reviewed that closely, so it may be fatally wrong or not even compile
2042016-01-05T14:51:14 <morcos> MarcoFalke: yeah but thats not what i think we shoudl do
2052016-01-05T14:51:39 <morcos> THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly
2062016-01-05T14:51:49 <morcos> I think the minimum should literally be the minimyum you ever want to send
2072016-01-05T14:51:57 <morcos> I would recommend not raising the default of that
2082016-01-05T14:52:12 <morcos> But the fallback value if you can't get an estimate should be larger
2092016-01-05T14:53:46 <morcos> so your change to wallet.cpp stays, but we change line 2213 to nFeeNeeded = std::max(nFeeNeeded, GetArg("-fallbackfee", DEFAULT_FALLBACK_FEE)); or -defaultfeeifnoestimate or whatever you want to call it
2102016-01-05T14:54:14 <morcos> line 2213 only gets execute if fee estimation is indicating to you its answer is unreliable
2112016-01-05T14:54:37 <morcos> but your addition at 2221 should stay, to respect the desired minimum
2122016-01-05T14:56:41 <MarcoFalke> I don't really like yet another fee arg, but what you say makes sense
2132016-01-05T14:56:53 <MarcoFalke> There would be no translations for 0.12 though
2142016-01-05T14:57:08 <morcos> In order to solve the pulling numbers out of a hat concern we could even just have a formula for the -fallbackfee at every release. -fallbackfee = estimatefee(2) which a 1 month decay instead of a 2.5 day decay calculated shortly before release
2152016-01-05T14:57:58 <morcos> MarcoFalke: yeah, but i think the translation thing is ok, b/c users shouldn't really need to worry about setting that.
2162016-01-05T14:58:33 <Luke-Jr> Frankly, we should probably replace the fee options with a %s so the same translation can be used..
2172016-01-05T14:58:43 <morcos> or maybe makes more sense -fallbackfee = estimatefee(10) with a 99% threshold and a 1 month decay
2182016-01-05T14:58:45 <Luke-Jr> (I might have a PR to do that, not sure)
2192016-01-05T14:59:14 <Luke-Jr> morcos: 10? What is that, blocks? Way too aggressive for a fallback..
2202016-01-05T14:59:22 <morcos> too fast you mean?
2212016-01-05T14:59:26 <Luke-Jr> yes
2222016-01-05T14:59:32 <Luke-Jr> the worst case scenario should allow for up to a month time
2232016-01-05T14:59:46 <morcos> its not a minimum, its what gets used if fee estimation is broken
2242016-01-05T14:59:57 <morcos> s/broken/not ready yet/
2252016-01-05T15:00:00 <MarcoFalke> not a month
2262016-01-05T15:00:02 <Luke-Jr> if the fee estimation is broken, it can't be block-based..
2272016-01-05T15:00:06 <MarcoFalke> a day at most
2282016-01-05T15:00:12 <Luke-Jr> MarcoFalke: a week at least
2292016-01-05T15:00:12 <morcos> but more importantly cant' give you an estimate for the # youre asking for
2302016-01-05T15:00:22 <morcos> Luke-Jr: anything more than 3 days doesnt' exist right now
2312016-01-05T15:00:26 <jtimon> morcos how is defaulting to -mintxfee something ridiculous?
2322016-01-05T15:00:39 <morcos> but i 100% agree we should be able to predict longer term fees
2332016-01-05T15:00:41 <aj> MarcoFalke: limiting below at GetRequiredFee should be before limiting above at maxTxFee -- if you typo and set the RequiredFee crazy high, better to have it capped than not
2342016-01-05T15:00:49 <Luke-Jr> morcos: but you're talking about a scenario where we *don't have estimates at all*, right?
2352016-01-05T15:00:51 <morcos> i have code to push fee estimation out to a week but i never PR'ed
2362016-01-05T15:01:02 <Luke-Jr> morcos: oooh, sounds useful
2372016-01-05T15:01:03 <morcos> Luke-Jr: unfortunately i'm talking about both
2382016-01-05T15:01:07 <MarcoFalke> jtimon, mintxfee=5000. THat will prevent you from sending for instance 3000 sat/KB fee txs even if fee estimation is telling you those will confirm quickly per morcos
2392016-01-05T15:01:13 <Luke-Jr> morcos: does it by chance work with non-24/7 nodes? :D
2402016-01-05T15:01:31 <morcos> Luke-Jr: We can distinguish between them though if we want to do different things in those cases
2412016-01-05T15:01:49 <morcos> jtimon: because -mintxfee is often too low to be of any use whatsoever = stuck tx
2422016-01-05T15:01:55 <Luke-Jr> gotta run..
2432016-01-05T15:02:01 <morcos> the default if you can't get an estimate should not be stuck tx
2442016-01-05T15:06:37 <jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of min(-mintxfee, estimatedFee) to solve your concern?
2452016-01-05T15:06:44 <jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of max(-mintxfee, estimatedFee) to solve your concern?
2462016-01-05T15:07:12 <jtimon> morcos: but -mintxfee is configurable
2472016-01-05T15:08:09 <morcos> jtimon: min implies its the lowest you ever want to send regardless of what fee estimates tell you or what you accidentally choose with settxfee
2482016-01-05T15:08:26 <morcos> not what you want the fall back value to be
2492016-01-05T15:08:35 <morcos> it doesnt make sense to fall back to the lowest possible
2502016-01-05T15:09:01 <morcos> anyway, i have to run now, now that i've gotten some of the bickering out of the way on irc, i'll submit a PR later this afternoon
2512016-01-05T15:09:25 <jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, max(-defaulttxfeeifnoestimate, estimatedFee)) ?
2522016-01-05T15:09:34 <jtimon> sorry, again
2532016-01-05T15:09:46 <jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ?
2542016-01-05T15:11:00 <jtimon> I still think min(-mintxfee, estimatedFee) should is good enough though
2552016-01-05T15:11:59 <MarcoFalke> good enough for 0.12.
2562016-01-05T15:12:24 <MarcoFalke> We may want to do the other suggestion for 0.13 if it can't get into 12
2572016-01-05T15:12:56 <jtimon> yep, we can move to max(-newoption, min(-mintxfee, estimatedFee)) later
2582016-01-05T15:14:23 <jtimon> I mean, I just wanted to understand, I surredered on relay policy/acceptToMemoryPool already...
2592016-01-05T15:53:50 <morcos> jtimon: what i want is max(estimatefee, -mintxfee) where estimatefee = (if tgt found: estimatefee , else: max(estimatefee, newoption))
2602016-01-05T15:54:31 <morcos> currently the fee = (if tgt found: estimatefee, else: max(estimatefee, -mintxfee))
2612016-01-05T15:54:40 <morcos> i will submit PR as soon as i get a chance
2622016-01-05T15:55:46 <jtimon> well if estimatefee = found ? estimatedfee : maxint, then my "max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee))" description is equivalent
2632016-01-05T15:56:16 <jtimon> but thank you for confirming that I understood you
2642016-01-05T15:58:35 <morcos> your min is not correct though, there is never a min
2652016-01-05T15:58:56 <jtimon> min(1, 2) == 1 ?
2662016-01-05T15:59:22 <morcos> why don't you just let me write it first. :)
2672016-01-05T15:59:37 <jtimon> min(-defaulttxfeeifnoestimate, maxint) == -defaulttxfeeifnoestimate
2682016-01-05T16:00:40 <morcos> oh, i understand what you meant now
2692016-01-05T16:01:06 <morcos> no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target
2702016-01-05T16:01:54 <jtimon> morcos: I just wanted to understand what you were saying, thanks. I don't plan to code, review or otherwise collaborate in anything related to relay policy/mempool acceptance in the near future, I'll just restore my previous work on jt-0.12
2712016-01-05T16:02:37 <jtimon> "no if estimatefee does not work, it will return either 0 (if it didnt' work at all) or an estimate for a lower confirm target" the 0 can be changed to maxint, of course, but anyway it was just a way to say it
2722016-01-05T16:12:11 *** Cory has quit IRC
2732016-01-05T16:14:22 *** Pasha has joined #bitcoin-core-dev
2742016-01-05T16:21:15 *** Pasha is now known as Cory
2752016-01-05T16:25:36 *** cryptopeddler has quit IRC
2762016-01-05T16:27:40 *** Cory has quit IRC
2772016-01-05T16:29:34 *** Pasha has joined #bitcoin-core-dev
2782016-01-05T16:30:09 *** cryptopeddler has joined #bitcoin-core-dev
2792016-01-05T16:36:28 *** Pasha is now known as Cory
2802016-01-05T16:39:26 *** Yoghur114 has joined #bitcoin-core-dev
2812016-01-05T16:54:14 *** laurentmt has joined #bitcoin-core-dev
2822016-01-05T16:58:15 *** Cory has quit IRC
2832016-01-05T16:58:56 *** BashCo has quit IRC
2842016-01-05T17:06:26 <GitHub115> [bitcoin] morcos opened pull request #7296: Add sane fallback for fee estimation (master...fallbackfee) https://github.com/bitcoin/bitcoin/pull/7296
2852016-01-05T17:07:33 <morcos> MarcoFalke: OK I created my PR. I actually changed the logic a little from what I suggested. This will not use the fallback fee if fee estimation has given you an estimate for a slightly longer confirm target. It only uses the fallback fee if it can't give you any estimates at all.
2862016-01-05T17:07:57 <morcos> I think this is safest, and runs least risk of having the fallbackfee accidentally screw people by being too high
2872016-01-05T17:09:03 <morcos> wumpus: I know you HATE defaults, especially ones that have to be changed over time. But I see no way around this if you want to allow txs before fee estimates are warned up. I suppose as aj suggests we could come up with a way to prevent that, but its a more invasive change.
2882016-01-05T17:10:42 <morcos> I think we should come up with a rule of thumb using historical fee estimates for adjusting this default per major release. I think 20000 satoshis/KB is about what you would get for estimatefee(4) over a longer time horizon. But honestly I don't care what we use there, as long as it makes more sense than 1000. Anything between 5K-50K would be ok by me.
2892016-01-05T17:11:41 <morcos> rusty: result of our discussion last night ^^^ Thanks for bringing it up!
2902016-01-05T17:14:38 <GitHub180> [bitcoin] MarcoFalke closed pull request #7295: [WIP] Obey mintxfee on txconfirmtarget, Bump mintxfee (master...Mf1601-wallet-mintxfee) https://github.com/bitcoin/bitcoin/pull/7295
2912016-01-05T17:16:10 *** BashCo has joined #bitcoin-core-dev
2922016-01-05T17:18:19 *** Cory has joined #bitcoin-core-dev
2932016-01-05T17:19:06 *** laurentmt has quit IRC
2942016-01-05T17:30:41 *** Quent1 has quit IRC
2952016-01-05T17:31:09 *** Quent1 has joined #bitcoin-core-dev
2962016-01-05T17:40:40 <jtimon> morcos, so now that you have changed the estimation to give an estimation or 0, what's wrong with chaning the zero to maxint and doing min(estimatefee, -mintxfee) without introducing any new parameter or default instead of max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ? (not proposing that, again, just want to understand the need for a new runtime option)
2972016-01-05T17:42:42 <jtimon> (apart from maybe having to update the documentation for -mintxfee)
2982016-01-05T17:44:31 <morcos> i agree it could work fine with maxint, that seems unrelated to this change, gavinandresen chose the 0 error value. but i don't want to use -mintxfee because i want the fallback value to be a higher number. if you dont' have estimates you shouldn't fall back to the lowest possible value
2992016-01-05T17:44:47 <jtimon> or more in words, if there's no estimate, you're doing max(-mintxfee, -defaulttxfeeifnoestimate)), why not just -mintxfee?
3002016-01-05T17:45:28 <jtimon> "because i want the fallback value to be a higher number" but people can do -mintxfee=higher_number, can't they?
3012016-01-05T17:46:15 <jtimon> "the lowest possible value" well, that's just part of the documentation of -mintxfee (assuming it is)
3022016-01-05T17:46:41 <jtimon> documentation is easy to change
3032016-01-05T17:46:59 *** treehug88 has joined #bitcoin-core-dev
3042016-01-05T17:47:07 <morcos> jtimon: yes they can, and that was originally what i wanted to do, but then it occurred to me that it makes sense to have 2 values. one of which is the minimum fee you ever want to pay, regardless of what you set with settxfee and regardless of what fee estimates tells you
3052016-01-05T17:47:09 <jtimon> I guess what you don't want is being able to produce that are lower than -mintxfee, even if the estimator says it will be fine
3062016-01-05T17:47:25 <morcos> and the other is what you want to pay by default if there are no fee estimates and you're trying to reduce them
3072016-01-05T17:47:57 <jtimon> I guess then my question is, why is that "mininmum fee regardless of what the estimator says" necessary?
3082016-01-05T17:48:17 *** brg444 has joined #bitcoin-core-dev
3092016-01-05T17:48:20 <jtimon> isn't a default for when the estimator doesn't work enough?
3102016-01-05T17:48:20 <morcos> it's probably not, but people may already use it
3112016-01-05T17:48:32 <morcos> they also may use it if they are not using the estimator
3122016-01-05T17:48:51 <morcos> it just seemed to big a change to completely remove what people think mintxfee does
3132016-01-05T17:49:07 <jtimon> to the second point, if they don't use the estimator they would just use the single default
3142016-01-05T17:49:46 <morcos> imagine someone has some external program that does their own fee estimation. And they use settxfee to tell bitcoin core what fee to pay based on that
3152016-01-05T17:50:01 <morcos> they might want to be able to set a minimum, sure they could implement the minimum logic themselves
3162016-01-05T17:50:11 <morcos> but it might be a change from how they are currently using it
3172016-01-05T17:50:26 <jtimon> that's what I meant by adapting the documentation, right now it says "Fees (in %s/kB) smaller than this are considered zero fee for transaction creation (default: %s)"
3182016-01-05T17:50:36 <morcos> yeah, well thats just completely wrong
3192016-01-05T17:50:46 <morcos> but i'm not messing around with any priority related stuff, its too annoying
3202016-01-05T17:51:06 <jtimon> if people think that what it does is "the minimum fee regardless of what the estimator says" we should change it one way or another
3212016-01-05T17:51:27 <jtimon> who's talking about priority?
3222016-01-05T17:51:39 <morcos> That's what "considered zero fee" means
3232016-01-05T17:51:43 <morcos> evaluated based on priority
3242016-01-05T17:52:28 <morcos> There is one more reason to keep a distinct mintxfee
3252016-01-05T17:52:30 <jtimon> I see, I actually believe that was just copied from minrelaytxfee...
3262016-01-05T17:52:55 *** Cory has quit IRC
3272016-01-05T17:53:03 <jtimon> but -mintxfee has nothing to do with priority (I may be wrong here)
3282016-01-05T17:53:11 <morcos> In the future minrelaytxfee makes more sense as the relay cost. So if you want to RBF or evict, thats the increment you need to pay
3292016-01-05T17:53:44 <morcos> But its not obvious that you want to be able to first place a tx for only relay cost, there may be a different mintxfee that is required
3302016-01-05T17:54:25 <morcos> Anyway, i'm just trying not to get caught up in the whole mess of how people want to use mintxfee. I don't know what peole use if for, I know Marco said he used it as a safety mechanism
3312016-01-05T17:54:29 <jtimon> I still don't see why two command line options (not counting minrelaytxfee) are needed
3322016-01-05T17:54:39 <morcos> look at it as 3
3332016-01-05T17:54:43 <morcos> min, default, max
3342016-01-05T17:55:10 <jtimon> well, if we want to "fix mintxfee", maybe knowing more about "how people use it" would be interesting
3352016-01-05T17:55:34 <morcos> i don't wnat to fix mintxfee. i'm not changning it. i want to give fee estimation a sane fall back value
3362016-01-05T17:55:49 <morcos> an mintxfee does not seem to fit the bill, unless i change it
3372016-01-05T17:56:06 <jtimon> "unless i change it" that's entirely my point
3382016-01-05T17:56:42 <jtimon> but I didn't got your point about "min, default, max" either
3392016-01-05T17:56:51 <jtimon> each parameter has its own default
3402016-01-05T17:57:16 <jtimon> and I don't see where you are using the max
3412016-01-05T17:57:52 <jtimon> anyway, never mind, I guess I will understand it in time
3422016-01-05T17:58:36 <jtimon> you guys do whatever you want with this
3432016-01-05T17:58:37 <morcos> i'm saying the user already has options to set: the min possible fee they want to send, the fee they will send if fee estimation doesn't work, the max possible fee they will send
3442016-01-05T17:58:48 <morcos> s/has/will have/
3452016-01-05T17:59:35 <jtimon> oh, ok, when you talk about "will have things" as if they were already in, it is very confusing to me
3462016-01-05T18:00:13 <jtimon> oh, I guess the max is the absurd fee
3472016-01-05T18:01:11 <jtimon> still, I don't see the point with the default, if you don't have estimation just use the min the user has set
3482016-01-05T18:02:46 <jtimon> to me this strongly smells to "users are stupid so let's have more obscure runtime options with 'reasonable defaults" to make it harder for them to do stupid things"
3492016-01-05T18:03:18 <jtimon> but is just a personal feeling, again you guys do whatever you want
3502016-01-05T18:15:09 <GitHub152> [bitcoin] MarcoFalke opened pull request #7298: [qt] Intro: Display required space (master...Mf1601-qtDataDir) https://github.com/bitcoin/bitcoin/pull/7298
3512016-01-05T18:15:17 <jtimon> wumpus I'm probably leaving soon, please don't answer my previous question while I'm gone, I don't have a bouncer yet
3522016-01-05T18:31:02 <MarcoFalke> botbot.me
3532016-01-05T18:31:31 <MarcoFalke> will archive this channel at least
3542016-01-05T18:33:58 <jtimon> MarcoFalke: yes, but it's simpler to me to just ask again than to look through the logs, at some point during the 0.13.99 I will get the "now it's the right time" answer I'm waiting for, or I'll stop asking
3552016-01-05T18:37:52 *** laurentmt has joined #bitcoin-core-dev
3562016-01-05T18:38:01 *** laurentmt has quit IRC
3572016-01-05T18:45:39 <morcos> sipa: i wasn't around when the work on handling evicted txs for 0.12 went in. but what did we decide to do if you have a tx that gets evicted b/c of too low fee.
3582016-01-05T18:45:45 <morcos> are those outputs then just stuck forever?
3592016-01-05T19:18:48 *** jtimon has quit IRC
3602016-01-05T19:26:01 <morcos> wumpus: sipa: i think we still need another fix for evicted txs
3612016-01-05T19:26:18 <morcos> for 0.12
3622016-01-05T19:26:44 <morcos> sipa's change made it so that if a tx is evicted you will not automatically respend the inputs, thats all fine and good
3632016-01-05T19:26:51 <morcos> but there has to be SOME way to respend them
3642016-01-05T19:27:13 <morcos> prior to this change, if you had a permanently stuck tx (say you just relayed it with way too low a fee or it got lost and its only in your mempool or whatever)
3652016-01-05T19:27:44 <morcos> if you restarted your node with a higher min relay fee, then it wouldn't make it in your mempool and by the prior logic would have been conflicted and respendable
3662016-01-05T19:27:54 <morcos> now its just permanently unspendable
3672016-01-05T19:29:01 <morcos> ideally we'd eventually RBF these txs or soemthing, but i dont' even know what that means if its not in your mempool
3682016-01-05T19:29:19 <morcos> but i think we need a way to manually be able to respend these inputs
3692016-01-05T19:29:36 <morcos> we had talked back in November about adding a "forget" option, i guess that never happened?
3702016-01-05T19:32:44 <sipa> morcos: they're considered respendable if there is a conflict in the chaim
3712016-01-05T19:32:47 <sipa> *chain
3722016-01-05T19:37:41 *** trippysalmon has joined #bitcoin-core-dev
3732016-01-05T19:41:54 <morcos> sipa: ? but how would there be a conflict in the chain
3742016-01-05T19:45:12 <sipa> right, we also need a way to mark an old non-confirming transaction as respendable
3752016-01-05T19:47:25 <morcos> yep, its possible to manually construct and submit a double spend with createrawtransaction and that'll be accepted b/c the original is no longer in the mempool
3762016-01-05T19:47:34 <morcos> but thats fairly tedious
3772016-01-05T19:48:51 <sipa> agree
3782016-01-05T19:50:35 *** jannes has joined #bitcoin-core-dev
3792016-01-05T19:51:04 <morcos> should i start by taking a look at adding a forgettransaction or something rpc call and then we can worry later about the gui implementation. i'll have to dive into the code to figure out how to represent its respendableness, unless you already know how you'd like it done
3802016-01-05T19:51:53 <morcos> maybe marktransactionrespendable (which can only apply to wallet txs that arent' in your memory pool)
3812016-01-05T19:52:26 <sipa> i think we can just mark a tx as conflicting with the genesis block or something :)
3822016-01-05T20:04:45 *** belcher has joined #bitcoin-core-dev
3832016-01-05T20:05:07 *** trippysalmon has quit IRC
3842016-01-05T20:07:10 <gijensen> morcos, please removing wallet transactions that aren't in the mempool is on my to-do list
3852016-01-05T20:10:28 *** Cory has joined #bitcoin-core-dev
3862016-01-05T20:37:48 <GitHub152> [bitcoin] MarcoFalke opened pull request #7300: [trivial] Add missing copyright headers (master...Mf1601-copyrightheaders) https://github.com/bitcoin/bitcoin/pull/7300
3872016-01-05T20:44:28 *** Squidicuz has quit IRC
3882016-01-05T20:45:43 *** Squidicuz has joined #bitcoin-core-dev
3892016-01-05T21:11:09 *** MarcoFalke has quit IRC
3902016-01-05T21:29:16 *** randy-waterhouse has joined #bitcoin-core-dev
3912016-01-05T21:30:25 *** MarcoFalke has joined #bitcoin-core-dev
3922016-01-05T21:46:32 *** Guest62894 has joined #bitcoin-core-dev
3932016-01-05T21:47:47 *** jannes has quit IRC
3942016-01-05T22:08:29 *** MarcoFalke has quit IRC
3952016-01-05T22:09:33 *** MarcoFalke has joined #bitcoin-core-dev
3962016-01-05T22:10:24 *** treehug88 has quit IRC
3972016-01-05T22:22:57 <GitHub106> [bitcoin] theuni opened pull request #7302: C++11 build/runtime fixes (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7302
3982016-01-05T22:28:52 *** murch has quit IRC
3992016-01-05T22:49:01 *** brg444 has quit IRC
4002016-01-05T22:58:54 *** MarcoFalke has quit IRC
4012016-01-05T23:03:13 *** MarcoFalke has joined #bitcoin-core-dev
4022016-01-05T23:04:39 *** Guyver2 has quit IRC
4032016-01-05T23:37:37 <morcos> sipa: I noticed an order of magnitude slow down in running smartfees.py . I tracked it down to your tricklenode->poisson change. I guess its not unexpected that it would cause a big slowdown on any rpc tests that require mempools to be synced?
4042016-01-05T23:39:25 <morcos> I'm not sure if its really a problem. presumably its only in regtests that you would care about something like this. but smartfees.py went from 40sec to 250sec
4052016-01-05T23:53:39 *** arowser has quit IRC
4062016-01-05T23:54:12 *** arowser has joined #bitcoin-core-dev