--- Day changed Tue Jan 05 2016
00:05 -!- p15 [~p15@109.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
00:22 -!- adam3us [~Adium@195.138.228.8] has joined #bitcoin-core-dev
00:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:36 -!- murch [~murch@p4FE38DDE.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
00:48 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
00:48 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
00:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:32 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 272 seconds]
01:41 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has joined #bitcoin-core-dev
01:55 -!- p15_ [~p15@42.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
01:57 -!- p15 [~p15@109.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 240 seconds]
02:03 -!- adam3us [~Adium@195.138.228.8] has quit [Quit: Leaving.]
02:08 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
02:32 -!- zookolaptop [~user@ip5b406106.dynamic.kabel-deutschland.de] has joined #bitcoin-core-dev
02:54 -!- zookolaptop [~user@ip5b406106.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
02:58 -!- adam3us [~Adium@195.138.228.8] has joined #bitcoin-core-dev
03:05 < GitHub141> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/45d13abf4ea1...a10a7920c3ac
03:05 < GitHub141> bitcoin/master 5246180 Suhas Daftuar: Mark blocks with too many sigops as failed
03:05 < GitHub141> bitcoin/master a10a792 Wladimir J. van der Laan: Merge pull request #7217...
03:05 < 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
03:05 < GitHub58> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/e08b7cb33ca30e03a4fda2eb13fc101628907258
03:05 < GitHub58> bitcoin/0.12 e08b7cb Suhas Daftuar: Mark blocks with too many sigops as failed...
03:10 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
03:11 -!- zookolaptop [~user@static.118.89.4.46.clients.your-server.de] has joined #bitcoin-core-dev
03:16 < 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)
03:18 < MarcoFalke> Personally I don't use fee estimates and my .conf has a hardcoded mintxfee which just fits my time-cost-tradeoff just fine.
03:19 < 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
03:20 < MarcoFalke> wumpus, anything holding back 7193 ?
03:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:37 < wumpus> MarcoFalke: huh, "pruning" is kind of ambigious in this context
03:38 < wumpus> test looks good to me though
03:38 < MarcoFalke> Should have been merged as part of the pull that introduced "pruning"
03:39 < wumpus> let's not call it pruning please
03:40 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:41 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:41 -!- zookolaptop [~user@static.118.89.4.46.clients.your-server.de] has quit [Ping timeout: 256 seconds]
03:44 < wumpus> so  #7193 fixes the test so that it actually tests what it purports to test
03:45 < wumpus> what do you mean with "pruning must fail on 0.12"?
03:45 < wumpus> *this test* must fail on 0.12?
03:46 < wumpus> and succeed on master?
03:46 < MarcoFalke> It must fail where trimming was not yet implemented
03:47 < MarcoFalke> It must pass when (and after) trimming was implemented
03:47 < wumpus> right - the test, not the process itself
03:47 < wumpus> ok then I understand, thanks ;)
03:49 < MarcoFalke> oops, was a typo in my comment
03:52 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
03:52 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
03:52 -!- Arnavion3 is now known as AtashiCon
03:54 < morcos> MarcoFalke: If you want to use a preset fee, then why do you use mintxfee and not paytxfee?
03:55 < GitHub45> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a10a7920c3ac...2078495d9c5f
03:55 < GitHub45> bitcoin/master fafd093 MarcoFalke: [wallet] Adjust pruning test
03:55 < GitHub45> bitcoin/master 2078495 Wladimir J. van der Laan: Merge pull request #7193...
03:55 < GitHub159> [bitcoin] laanwj closed pull request #7193: [wallet] Cleanup tests (master...MarcoFalke-2015-WalletTests) https://github.com/bitcoin/bitcoin/pull/7193
03:55 < 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
03:56 < wumpus> I'm not entirely sure either
03:56 < btcdrak> oh finally some life
03:56 < btcdrak> was really quiet here  this morning :)
03:56 < MarcoFalke> morcos, paytxfee can be set via settxfee
03:57 < MarcoFalke> If you happen to settxfee too low, you might want a fall back
03:57 < MarcoFalke> That's what I was guessing why it was there, but your concern is valid
03:58 < MarcoFalke> so mintxfee is the "hardcoded" minimum whereas paytxfee is your "dynamic choice"
03:58 < morcos> MarcoFalke: yeah ok , so thats a bit what i was afraid of
03:58 < morcos> for someone like you, you would not want mintxfee to be set to say 20000 satoshis
03:59 < morcos> because you would want the freedom to choose below that sometimes 
03:59 < GitHub162> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/bfdaa3c87f6054b0b1e617031d6a8f02cdfc99dd
03:59 < GitHub162> bitcoin/0.12 bfdaa3c MarcoFalke: [wallet] Adjust pruning test...
03:59 < 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
04:01 < morcos> I mean luckily it is command line settable also
04:02 < morcos> so no reason to obsesses on it now, and just pick something that is more sensible than 1000
04:02 < GitHub107> [bitcoin] jonasschnelli pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/aa413687de45ef9add61f97447532a87bd2b2bb7
04:02 < GitHub107> bitcoin/master aa41368 Jonas Schnelli: Merge pull request #7282...
04:02 < 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
04:05 < MarcoFalke> jonas, is this a backport as well?
04:08 < GitHub51> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/5cadf3eb60ddc630d9e749f7a92e51d07d2e614a
04:08 < GitHub51> bitcoin/0.12 5cadf3e Jonas Schnelli: [Qt] fix coincontrol update issue when deleting a send coin entry...
04:37 < MarcoFalke> jonasschnelli, how can I trigger the welcome dialog of qt?
04:37 < MarcoFalke> firts-start dialog
04:40 < wumpus> -choosedatadir
04:43 -!- p15_ [~p15@42.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 246 seconds]
05:11 < GitHub66> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/aa413687de45...605c17844ea3
05:11 < GitHub66> bitcoin/master fa6ad85 MarcoFalke: [devtools] Rewrite fix-copyright-headers.py
05:11 < GitHub66> bitcoin/master fa24439 MarcoFalke: Bump copyright headers to 2015
05:11 < GitHub66> bitcoin/master fa71669 MarcoFalke: [devtools] Use git pretty-format for year parsing
05:12 < 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
05:14 < GitHub179> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/333e1eaeea80344e5a28db6efbce2691c85e2b25
05:14 < GitHub179> bitcoin/0.12 333e1ea MarcoFalke: Bump copyright headers to 2015...
05:17 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
05:18 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
05:45 < 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
05:46 < jtimon> I mean something like this https://github.com/jtimon/bitcoin/commit/f8c34f27d4020880647cbdbafad70793882cef79 (after #7287 )
05:49 < 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)?
05:53 -!- Quent1 [~Quent@unaffiliated/quent] has joined #bitcoin-core-dev
05:56 -!- Quent [~Quent@unaffiliated/quent] has quit [Ping timeout: 276 seconds]
06:21 < morcos> wumpus: are you completely opposed to adding a new command line argument for 0.12.  -defaulttxfeeifnoestimate (or something)
06:21 < morcos> I think it makes a lot of sense for this to be a different value than -mintxfee
06:22 < morcos> and then we can actually make fee estimate generated fees respect -mintxfee (which they currently don't)
06:22 < 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
06:23 < morcos> and it'll prevent them from doing so, regardless of how they pick their fees
06:23 < morcos> -defaulttxfeeifnoestimate will only come into play if you're trying to use estimates and you can't
06:23 < 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)
06:24 < maaku> we shouldn't be pulling numbers out of a hat for fees, mintxfee or defaulttxfeeifnoestimate or otherwise
06:24 < 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
06:24 < morcos> but if you asked for 2, and got 25000 at 2, then thats fine
06:24 < morcos> maaku: if you have no estimates (on startup) you have to pull numbers from a hat
06:25 < maaku> morcos: or you can disable transaction creation until the fee estimator is primed
06:25 < MarcoFalke> morcos, I'd be fine with setting mintxfee to 5000 or 10000 and mention in the release notes that ppl can change it.
06:25 < 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)
06:25 < maaku> although hopefully soon we will have the consensus changes needed to prime estimation on startup
06:26 < 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
06:26 < MarcoFalke> And also adjust the GUI to show the GetRequiredFee() for estimates, in case it does not yet do this
06:26 < 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
06:26 < morcos> so giving them a way to do that with -mintxfee is valuable
06:26 < maaku> morcos: defaulttxfeeifnoestimate seems just as crazy
06:27 < 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
06:27 < morcos> and even in the gui, what should it default to if it doesn't know
06:27 < morcos> maaku: why is that crazy
06:27 < aj> morcos: RPC can give an error back :)
06:27 < 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)
06:28 < 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
06:28 < morcos> and then we should have a sane default
06:28 < maaku> better to just give an error, or in the GUI a window to enter a manual fee
06:28 < morcos> you guys, fee estimation is not that perfect
06:29 < 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
06:30 < morcos> for instance what you are describing would be impossible on regtest or testnet which often don't have any estimates
06:30 < 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...
06:31 < 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 
06:31 < morcos> aj: that is the goal
06:31 < morcos> but if its not working some small % of the time, then what should you do?
06:32 < MarcoFalke> morcos, can you elaborate again what the difference in UX is in regard to defaulttxfeeifnoestimate vs mintxfee
06:32 < MarcoFalke> What is "misuse"?
06:33 < MarcoFalke> The default is: "Estimate the fee to get into <n> blocks, where <n> is user set."
06:33 < 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).
06:33 < 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)
06:34 < 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.  
06:35 < 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.
06:36 < 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. 
06:37 < aj> morcos: i would like an error saying "best estimate is for 25 blocks"
06:38 < 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)
06:38 < 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
06:39 < MarcoFalke> agree that the rpc error is no solution
06:40 < morcos> sendtoaddress() is meant to just send the damn tx and do something smart for me
06:40 < aj> morcos: (i'd rather have txconfirmtarget set as an optional parameter to sendtoaddress)
06:40 < 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
06:41 < MarcoFalke> morcos, You were right that GetRequiredFee() is ignored. (I somehow had it differently in mind)
06:41 < 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
06:41 < MarcoFalke> So you'd disagree to move nFeeNeeded = std::max(nFeeNeeded, GetRequiredFee(nTxBytes)); furher down
06:41 < MarcoFalke> (right in the line before return?)
06:41 < 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
06:42 < aj> morcos: well, i'm talking about what i /want/, not necessarily what's easy/possible :)
06:42 < morcos> aj: well can you help us try and figure out what we should do for 0.12 instead
06:45 < 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
06:46 < 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.  
06:50 < 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
06:50 < MarcoFalke> this is what I thought.
06:50 < MarcoFalke> Haven't reviewed that closely, so it may be fatally wrong or not even compile
06:51 < morcos> MarcoFalke: yeah but thats not what i think we shoudl do
06:51 < 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
06:51 < morcos> I think the minimum should literally be the minimyum you ever want to send
06:51 < morcos> I would recommend not raising the default of that
06:52 < morcos> But the fallback value if you can't get an estimate should be larger
06:53 < 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
06:54 < morcos> line 2213 only gets execute if fee estimation is indicating to you its answer is unreliable
06:54 < morcos> but your addition at 2221 should stay, to respect the desired minimum
06:56 < MarcoFalke> I don't really like yet another fee arg, but what you say makes sense
06:56 < MarcoFalke> There would be no translations for 0.12 though
06:57 < 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
06:57 < morcos> MarcoFalke: yeah, but i think the translation thing is ok, b/c users shouldn't really need to worry about setting that.
06:58 < Luke-Jr> Frankly, we should probably replace the fee options with a %s so the same translation can be used..
06:58 < morcos> or maybe makes more sense -fallbackfee = estimatefee(10) with a 99% threshold and a 1 month decay 
06:58 < Luke-Jr> (I might have a PR to do that, not sure)
06:59 < Luke-Jr> morcos: 10? What is that, blocks? Way too aggressive for a fallback..
06:59 < morcos> too fast you mean?
06:59 < Luke-Jr> yes
06:59 < Luke-Jr> the worst case scenario should allow for up to a month time
06:59 < morcos> its not a minimum, its what gets used if fee estimation is broken
06:59 < morcos> s/broken/not ready yet/
07:00 < MarcoFalke> not a month
07:00 < Luke-Jr> if the fee estimation is broken, it can't be block-based..
07:00 < MarcoFalke> a day at most
07:00 < morcos> but more importantly cant' give you an estimate for the # youre asking for
07:00 < Luke-Jr> MarcoFalke: a week at least
07:00 < morcos> Luke-Jr: anything more than 3 days doesnt' exist right now
07:00 < jtimon> morcos how is defaulting to -mintxfee something ridiculous?
07:00 < morcos> but i 100% agree we should be able to predict longer term fees
07:00 < 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
07:00 < Luke-Jr> morcos: but you're talking about a scenario where we *don't have estimates at all*, right?
07:00 < morcos> i have code to push fee estimation out to a week but i never PR'ed
07:01 < Luke-Jr> morcos: oooh, sounds useful
07:01 < morcos> Luke-Jr: unfortunately i'm talking about both
07:01 < 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
07:01 < Luke-Jr> morcos: does it by chance work with non-24/7 nodes? :D
07:01 < morcos> Luke-Jr: We can distinguish between them though if we want to do different things in those cases
07:01 < morcos> jtimon: because -mintxfee is often too low to be of any use whatsoever = stuck tx
07:01 < Luke-Jr> gotta run..
07:02 < morcos> the default if you can't get an estimate should not be stuck tx
07:06 < jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of min(-mintxfee, estimatedFee) to solve your concern?
07:06 < jtimon> MarcoFalke: mhmm, why doesn't the code decide with min(-mintxfee, estimatedFee) instead of max(-mintxfee, estimatedFee) to solve your concern?
07:07 < jtimon> morcos: but -mintxfee is configurable
07:08 < 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
07:08 < morcos> not what you want the fall back value to be
07:08 < morcos> it doesnt make sense to fall back to the lowest possible
07:09 < 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
07:09 < jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, max(-defaulttxfeeifnoestimate, estimatedFee)) ?
07:09 < jtimon> sorry, again
07:09 < jtimon> morcos ok, I think I get it, so what you want is max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee)) ?
07:11 < jtimon> I still think min(-mintxfee, estimatedFee) should is good enough though
07:11 < MarcoFalke> good enough for 0.12.
07:12 < MarcoFalke> We may want to do the other suggestion for 0.13 if it can't get into 12
07:12 < jtimon> yep, we can move to max(-newoption, min(-mintxfee, estimatedFee)) later
07:14 < jtimon> I mean, I just wanted to understand, I surredered on relay policy/acceptToMemoryPool already...
07:53 < morcos> jtimon: what i want is max(estimatefee, -mintxfee)   where estimatefee = (if tgt found: estimatefee , else: max(estimatefee, newoption))
07:54 < morcos> currently the fee = (if tgt found: estimatefee, else: max(estimatefee, -mintxfee))
07:54 < morcos> i will submit PR as soon as i get a chance
07:55 < jtimon> well if estimatefee = found ? estimatedfee : maxint, then my "max(-mintxfee, min(-defaulttxfeeifnoestimate, estimatedFee))" description is equivalent
07:56 < jtimon> but thank you for confirming that I understood you
07:58 < morcos> your min is not correct though, there is never a min
07:58 < jtimon> min(1, 2) == 1 ?
07:59 < morcos> why don't you just let me write it first. :)
07:59 < jtimon> min(-defaulttxfeeifnoestimate, maxint) == -defaulttxfeeifnoestimate
08:00 < morcos> oh, i understand what you meant now
08:01 < 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
08:01 < 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
08:02 < 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
08:12 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 260 seconds]
08:14 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
08:21 -!- Pasha is now known as Cory
08:25 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-pglrtkmfohbcjosy] has quit [Read error: Connection reset by peer]
08:27 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 245 seconds]
08:29 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
08:30 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-zogjcexigbawpler] has joined #bitcoin-core-dev
08:36 -!- Pasha is now known as Cory
08:39 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has joined #bitcoin-core-dev
08:54 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:58 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 265 seconds]
08:58 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:06 < GitHub115> [bitcoin] morcos opened pull request #7296: Add sane fallback for fee estimation (master...fallbackfee) https://github.com/bitcoin/bitcoin/pull/7296
09:07 < 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.
09:07 < morcos> I think this is safest, and runs least risk of having the fallbackfee accidentally screw people by being too high
09:09 < 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.
09:10 < 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.
09:11 < morcos> rusty: result of our discussion last night  ^^^   Thanks for bringing it up!
09:14 < 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
09:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:18 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
09:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
09:30 -!- Quent1 [~Quent@unaffiliated/quent] has quit [Read error: Connection reset by peer]
09:31 -!- Quent1 [~Quent@unaffiliated/quent] has joined #bitcoin-core-dev
09: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)
09:42 < jtimon> (apart from maybe having to update the documentation for -mintxfee)
09:44 < 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
09:44 < jtimon> or more in words, if there's no estimate, you're doing max(-mintxfee, -defaulttxfeeifnoestimate)), why not just -mintxfee?
09:45 < jtimon> "because i want the fallback value to be a higher number" but people can do -mintxfee=higher_number, can't they?
09:46 < jtimon> "the lowest possible value" well, that's just part of the documentation of -mintxfee (assuming it is)
09:46 < jtimon> documentation is easy to change
09:46 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
09:47 < 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
09:47 < 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
09:47 < 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
09:47 < jtimon> I guess then my question is, why is that "mininmum fee regardless of what the estimator says" necessary?
09:48 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-core-dev
09:48 < jtimon> isn't a default for when the estimator doesn't work enough?
09:48 < morcos> it's probably not, but people may already use it
09:48 < morcos> they also may use it if they are not using the estimator
09:48 < morcos> it just seemed to big a change to completely remove what people think mintxfee does
09:49 < jtimon> to the second point, if they don't use the estimator they would just use the single default
09:49 < 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
09:50 < morcos> they might want to be able to set a minimum, sure they could implement the minimum logic themselves
09:50 < morcos> but it might be a change from how they are currently using it
09:50 < 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)"
09:50 < morcos> yeah, well thats just completely wrong
09:50 < morcos> but i'm not messing around with any priority related stuff, its too annoying
09:51 < 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
09:51 < jtimon> who's talking about priority?
09:51 < morcos> That's what "considered zero fee" means
09:51 < morcos> evaluated based on priority
09:52 < morcos> There is one more reason to keep a distinct mintxfee
09:52 < jtimon> I see, I actually believe that was just copied from minrelaytxfee...
09:52 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 240 seconds]
09:53 < jtimon> but -mintxfee has nothing to do with priority (I may be wrong here)
09:53 < 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
09:53 < 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
09:54 < 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
09:54 < jtimon> I still don't see why two command line options (not counting minrelaytxfee) are needed
09:54 < morcos> look at it as 3
09:54 < morcos> min, default, max
09:55 < jtimon> well, if we want to "fix mintxfee", maybe knowing more about "how people use it" would be interesting
09:55 < morcos> i don't wnat to fix mintxfee.  i'm not changning it.  i want to give fee estimation a sane fall back value
09:55 < morcos> an mintxfee does not seem to fit the bill, unless i change it
09:56 < jtimon> "unless i change it" that's entirely my point
09:56 < jtimon> but I didn't got your point about "min, default, max" either
09:56 < jtimon> each parameter has its own default
09:57 < jtimon> and I don't see where you are using the max
09:57 < jtimon> anyway, never mind, I guess I will understand it in time
09:58 < jtimon> you guys do whatever you want with this
09:58 < 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
09:58 < morcos> s/has/will have/
09:59 < jtimon> oh, ok, when you talk about "will have things" as if they were already in, it is very confusing to me
10:00 < jtimon> oh, I guess the max is the absurd fee
10:01 < 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
10:02 < 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"
10:03 < jtimon> but is just a personal feeling, again you guys do whatever you want
10:15 < GitHub152> [bitcoin] MarcoFalke opened pull request #7298: [qt] Intro: Display required space (master...Mf1601-qtDataDir) https://github.com/bitcoin/bitcoin/pull/7298
10:15 < 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
10:31 < MarcoFalke> botbot.me
10:31 < MarcoFalke> will archive this channel at least
10:33 < 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
10:37 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
10:38 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
10:45 < 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.
10:45 < morcos> are those outputs then just stuck forever?
11:18 -!- jtimon [~quassel@103.red-80-26-235.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 264 seconds]
11:26 < morcos> wumpus: sipa: i think we still need another fix for evicted txs
11:26 < morcos> for 0.12
11:26 < 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
11:26 < morcos> but there has to be SOME way to respend them
11:27 < 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)
11:27 < 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
11:27 < morcos> now its just permanently unspendable
11:29 < morcos> ideally we'd eventually RBF these txs or soemthing, but i dont' even know what that means if its not in your mempool
11:29 < morcos> but i think we need a way to manually be able to respend these inputs
11:29 < morcos> we had talked back in November about adding a "forget" option, i guess that never happened?
11:32 < sipa> morcos: they're considered respendable if there is a conflict in the chaim
11:32 < sipa> *chain
11:37 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has joined #bitcoin-core-dev
11:41 < morcos> sipa: ?  but how would there be a conflict in the chain
11:45 < sipa> right, we also need a way to mark an old non-confirming transaction as respendable
11:47 < 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
11:47 < morcos> but thats fairly tedious
11:48 < sipa> agree
11:50 -!- jannes [~jannes@092-111-146-044.static.chello.nl] has joined #bitcoin-core-dev
11:51 < 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
11:51 < morcos> maybe marktransactionrespendable  (which can only apply to wallet txs that arent' in your memory pool)
11:52 < sipa> i think we can just mark a tx as conflicting with the genesis block or something :)
12:04 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:05 -!- trippysalmon [rob@2001:984:6466:0:51d:b5ab:ab61:bed8] has quit [Ping timeout: 250 seconds]
12:07 < gijensen> morcos, please removing wallet transactions that aren't in the mempool is on my to-do list
12:10 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
12:37 < GitHub152> [bitcoin] MarcoFalke opened pull request #7300: [trivial] Add missing copyright headers (master...Mf1601-copyrightheaders) https://github.com/bitcoin/bitcoin/pull/7300
12:44 -!- Squidicuz [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has quit [Ping timeout: 250 seconds]
12:45 -!- Squidicuz [~squid@pool-173-48-117-206.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
13:11 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
13:29 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
13:30 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
13:46 -!- Guest62894 [~graham@87.254.74.170] has joined #bitcoin-core-dev
13:46 -!- Guest62894 [~graham@87.254.74.170] has quit [Client Quit]
13:47 -!- jannes [~jannes@092-111-146-044.static.chello.nl] has quit [Ping timeout: 246 seconds]
14:08 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
14:09 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
14:10 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:22 < GitHub106> [bitcoin] theuni opened pull request #7302: C++11 build/runtime fixes (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7302
14:28 -!- murch [~murch@p4FE38DDE.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
14:49 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds]
14:58 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
15:03 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
15:04 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]
15: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?
15:39 < 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
15:53 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
15:54 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
16:03 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:25 < Luke-Jr> MarcoFalke: fwiw, I am no longer rebasing and in fact discouraging rebasing
16:26 < Luke-Jr> I'll do a merge when someone is ready to push it
16:26 < MarcoFalke> Here you could change the lines a bit to avoid a rebase: https://github.com/bitcoin/bitcoin/pull/7192/files#r48915192
16:26 < MarcoFalke> Would this make sense?
16:28 < Luke-Jr> the point is to avoid ever changing a commit once it has been published
16:53 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
17:07 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has left #bitcoin-core-dev []
17:24 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jrpevwvieicboxpm] has quit [Quit: Connection closed for inactivity]
17:30 < maaku> Luke-Jr what do you propose instead?
17:35 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-zogjcexigbawpler] has quit [Ping timeout: 246 seconds]
17:37 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-alinsvdndjxpdgde] has joined #bitcoin-core-dev
17:48 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-alinsvdndjxpdgde] has quit [Ping timeout: 260 seconds]
17:50 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-wnoitmataivnwqqo] has joined #bitcoin-core-dev
17:54 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-wnoitmataivnwqqo] has quit [Read error: Connection reset by peer]
17:56 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-iqgoesoxcocqgtnv] has joined #bitcoin-core-dev
18:00 -!- d_t [~textual@c-24-4-96-213.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:00 -!- d_t [~textual@c-24-4-96-213.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
18:00 -!- d_t [~textual@c-24-4-96-213.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
18:15 < morcos> Luke-Jr: yes can you please explain how that would work?  i agree rebasing can introduce errors, but if we all have a chance to see the rebased commit and the merge is clean it seems there is less likely to be problems compared to only one person ever seeing the resolution of merge conflicts
18:15 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
18:15 < morcos> or are you proposing that we would then separately review the merge commit before its actually merged?
18:16 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
18:16 < morcos> For testing purposes, if you rebase then everyone will be testing the same thing that is going to be merged.  Otherwise how will we know what the final code is going to look like.
18:19 -!- d_t [~textual@c-24-4-96-213.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:22 < Luke-Jr> maaku: merges were designed for this purpose
18:22 < Luke-Jr> morcos: rebasing/revising is anti-decentralised development
18:23 < Luke-Jr> morcos: when the merge substantially changes the code, I agree the changes need review again, just as if it had been rebased
18:24 < morcos> Luke-Jr: any change, not just substantial
18:24 < morcos> if someone is going to test, they need to be able to test the code thats going to exist
18:24 < Luke-Jr> any change does not need re-review. for example, the gitian timestamp thing
18:25 < morcos> i mean any merge conflict, might appear trivial but 2 people might resolve it in different ways
18:25 < morcos> if i want to test 7192 now, how do i know i'm testing the same thing that you are going to end up merging
18:25 < morcos> i don't 
18:26 < morcos> but if you rebase it so its a clean merge.  the anyone that merges it into master will be testing the exact same code
18:26 < morcos> which sure may contain a rebase or merge error, but at least we'll be testing it
18:26 < Luke-Jr> rebase errors are not the problem with rebasing.
18:26 < morcos> what is the problem then?
18:27 < Luke-Jr> morcos: git merge <pre-rebase> conflicts with git merge <post-rebase>
18:28 < Luke-Jr> because rebasing is not intentional workflow in git
18:28 < morcos> sorry, i didn't follow...  what do you mean conflicts with?
18:32 < Luke-Jr> morcos: for an example using real-world terms, say I merge the "Unify name" PR into Bitcoin LJR yesterday; and now I rebase it for Core master. Trying to merge this rebased branch into Bitcoin LJR will not work, even after I merge Core master into LJR, because the rebased branch conflicts with the pre-rebase branch
18:36 < morcos> hmm.. ok I see what you mean.  I guess it's not clear to me how that situation shows up in our work flow very often.
18:36 < Luke-Jr> perhaps worth reading: https://lwn.net/Articles/328436/
18:37 < Luke-Jr> morcos: it doesn't, because we have a very centralised workflow so far
18:37 < Luke-Jr> morcos: which has rightly been criticised and should change
18:38 < Luke-Jr> (LWN article is based on original post by Linus at http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html )
18:39 -!- bsm117532 is now known as Guest65074
18:39 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:52 -!- p15 [~p15@86.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
18:53 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-iqgoesoxcocqgtnv] has quit [Ping timeout: 276 seconds]
18:54 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-obizypjecserqkgv] has joined #bitcoin-core-dev
19:05 < maaku> We use got like it is svn, this is true.
19:12 < Luke-Jr> Actually, svn is even better than git-rebase in this regard :/
19:24 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev
19:44 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-obizypjecserqkgv] has quit [Ping timeout: 246 seconds]
19:46 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-dfzfelxerfzxeefu] has joined #bitcoin-core-dev
19:47 -!- d_t [~textual@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
19:59 -!- p15 [~p15@86.91.145.64.client.static.strong-tk2.bringover.net] has quit [Read error: Connection reset by peer]
20:04 -!- p15 [~p15@64.145.91.101] has joined #bitcoin-core-dev
20:18 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-dfzfelxerfzxeefu] has quit [Ping timeout: 246 seconds]
20:20 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-ydwzqpupbykxzfim] has joined #bitcoin-core-dev
20:25 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-ydwzqpupbykxzfim] has quit [Ping timeout: 264 seconds]
20:27 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-xecjbjhmlbdgypbj] has joined #bitcoin-core-dev
20:42 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-xecjbjhmlbdgypbj] has quit [Ping timeout: 264 seconds]
20:43 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-hzarwsfwtvowmloh] has joined #bitcoin-core-dev
20:48 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-hzarwsfwtvowmloh] has quit [Ping timeout: 240 seconds]
20:50 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-netngnumnlmjbacy] has joined #bitcoin-core-dev
20:57 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-netngnumnlmjbacy] has quit [Ping timeout: 255 seconds]
20:59 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-hviorgyxrvdnxpso] has joined #bitcoin-core-dev
21:06 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-hviorgyxrvdnxpso] has quit [Ping timeout: 256 seconds]
21:07 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-ymlouonkozdxtcls] has joined #bitcoin-core-dev
21:20 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-ymlouonkozdxtcls] has quit [Ping timeout: 276 seconds]
21:21 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-qledwtybvvstrbtu] has joined #bitcoin-core-dev
21:29 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-qledwtybvvstrbtu] has quit [Ping timeout: 265 seconds]
21:30 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-otfeawrxqzivqfxr] has joined #bitcoin-core-dev
22:21 < btcdrak> merging in pull-requests is ugly to the extreme and makes the main tree disgusting to look at. Just take a gander at Counterparty's source repositiories to see. It's a nightmare to determine what is going on. a PR branch can and should be rebased to make the patch clear and concise.
22:23 < btcdrak> it is wrong to rebase the main tree (i.e. the working master branch and maintenance branches) of course, because that screws up history for everyone, but for patches before they are merged it absolutely makes sense.
22:24 < btcdrak> most of the arguments I've read do not make the clear distinction between PR patches and the upstream repository, which is essential.
23:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-spiamdwqmbewlcmt] has joined #bitcoin-core-dev
23:34 -!- d_t [~textual@c-98-234-64-218.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:36 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Ping timeout: 256 seconds]
23:38 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
23:46 -!- d_t [~textual@c-98-234-64-218.hsd1.ca.comcast.net] has joined #bitcoin-core-dev