< Murch>
morcos: I was just looking at fee rate estimation. I'm surprised that the Bitcoin Core estimate is still on 170 for second block target when the network has been clearing the mempool of <40 for four days.
< Murch>
morcos: A few minutes ago, the block would have cleared down to below 5 satoshis per byte, but now there is one MB waiting at 160+
< Murch>
morcos: Maybe the estimation is a bit of o self-fulfilling prophecy?
< sipa>
Murch: fee estimation does not look at what fees would be required to confirm given the current mempool
< sipa>
but at what fees *are* confirming
< Murch>
I know
< sipa>
so yes, i guess it's by definition a self-fullfilling prophecy
< sipa>
if people keep overpaying, fee estimation will keep telling them to overpay
< Murch>
however, the fee estimation may be sustaining a higher fee level by jumping in at a too high level and generating enough send queue at that level
< Murch>
I was considering that Morcos' algorithm may not be decreasing fees aggressively enough after such a great fee spike as we had.
< sipa>
right
< morcos>
Murch: I'm not sure what you mean about clearing the mempool of <40 for 4 days
< morcos>
sipa: thats HOPEFU?LLy not true. the design is such that if at least some poeple aren't overpaying, and are also being confirmed, then fee esitmation will let you know that
< morcos>
even if most poeple are still overpaying
< sipa>
morcos: right
< sipa>
morcos: but to an extent, there is a self-sustaining property in it
< morcos>
the short term estimate has a half-life of only 18 blocks... so anything that happened more than say 12 hours ago is pretty meaningless
< morcos>
yeah, there used to be more though. now some people do place lower fees b/c they are willing to wait and so they use a longer target, so that helps the estimates for the shorter targets come down
< morcos>
that's a big part of why i wanted to increase the range to 1008. incentivise people to try for those lower numbers
< morcos>
but yea, i think there is definitely room to improve fee estimation, i just thinkthere is not much low hanging fruit. it's going to be pretty complicated to make it significantly better
< Murch>
well, the estimate does fit, as the fee level is now at ~170, but only 1.5MB over 30, and 1MB over 160 seems a bit unnatural
< morcos>
Murch, looking at the last couple hours, there are several blocks that haven't cleared down below 100
< Murch>
yeah, the next one won't either
< morcos>
so then if you want to get confirmed in 2 blocks, you shouldn't pay something that low
< morcos>
ask it for 12 and you'll get a much lower answer
< Murch>
yeah, was just curious if anyone else was watching this and had thoughts on it
< morcos>
Fee estimates for target of 6 have gone up recently actually
< morcos>
but yeah its a good idea to keep an eye on it, especially since its' relatively new
< Murch>
morcos: I was wondering, why is the fee estimate jumping at 45?
< Murch>
Are you switching the confidence curve?
< Murch>
sorry, 42
< Murch>
Or, if you don't know what I'm talking about, that may be custom to our estimate.
< morcos>
the time horizons break at 12 and 48, so there are often jumps around 6 , 12, 24, 48
< morcos>
i don't know why that would happen at 42
< Murch>
"23": 22152,
< Murch>
"25": 20083,
< Murch>
"42": 135327,
< Murch>
"49": 128408,
< morcos>
huh???
< morcos>
that's broken
< morcos>
it should never increase
< Murch>
Maybe it's just a modification in our algorithm, maybe we're not using Vanilla-Core after all
< Murch>
yeah, exactly
< morcos>
i see 19201 for 42
< Murch>
thanks
< morcos>
maybe you stopped asking for ECONOMICAL estimates?
< Murch>
We don't have RBF, so we don't do economical estimates
< morcos>
i think you are for 23/25
< Murch>
ah, that might be it
< morcos>
my conservative estimates for those are higher
< Murch>
Alright, well, I guess I was mistaken in my thinking that our fee estimation is vanilla Core :)
< morcos>
oh.. forgot where you work, yeah i don't think it is
< Murch>
alright, thanks for your insights
< JeffSlentz>
Hey, as a recent grad with not much experience with the Bitcoin Core project, are there any suggestions for contributing?
< Randolf>
JeffSlentz: Probably one of the best things you can do is to become familiar with the source code.
< Randolf>
JeffSlentz: From there, you may find an area that can be improved and then raise discussions about it.
< Randolf>
JeffSlentz: ...and suggestions on how to improve it, including source code if you feel inclined to write some.
< JeffSlentz>
Randolf: Thanks! Is there a best practices way to learn the source code? I'm overwhelmed with the sheer amount
< Randolf>
JeffSlentz: Are you familiar with the programming language(s) that said source code is written in?
< Randolf>
JeffSlentz: If not, then there may be other options for you, but you'll probably need to ask about those possibilities in the #bitcoin channel.
< fanquake>
JeffSlentz Trying to jump in and more generally "learn the source code" wont be the best place to start. Instead, pick an issue, familiarise yourself with the code concerned, submit a PR to fix it. Rinse & repeat.
< JeffSlentz>
Randolf: I've written some C++ but it's not my preferred language, I suppose.
< JeffSlentz>
fanquake: Thanks, I think that's a good approach
< bitcoin-git>
bitcoin/master d9340ce Matt Corallo: Fix sendrawtransaction hang when sending a tx already in mempool
< bitcoin-git>
bitcoin/master d4267a3 Wladimir J. van der Laan: Merge #11738: Fix sendrawtransaction hang when sending a tx already in mempool...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11738: Fix sendrawtransaction hang when sending a tx already in mempool (master...2017-11-fix-sendraw-block) https://github.com/bitcoin/bitcoin/pull/11738
< fanquake>
wumpus exposed :p
< wumpus>
fanquake: yep :p
< geezas>
anyone know if network-adjusted time as described in the wiki on block timestamps is used as described there
< geezas>
?
< geezas>
"A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you."
< wumpus>
see GetMedianTimePast
< Sentineo>
wumpus: the timespamt from node is just the timestamp in the blocks my node receives, right? Checking getMedianTimePast(), it referencis the blockchain. I have a feeling geezas tends to think it is a message that is exchanged between nodes. Can you shed some light, which view is correct?
< wumpus>
the text he quotes talks about the median timestamp of the previous 11 blocks, that's implemented in GetMedianTimePast
< wumpus>
there is also a median filter get relative node times at connection, in src/timedata.h, but that is a wholly separate thing
< sipa>
it also talks about network-adjusted time, which is indeed there is a message exchanged between nodes
< Sentineo>
ah ok, that is what I wanted to know
< Sentineo>
tried doing an experiment, but can not force my system to change its time
< Sentineo>
so if I set my time to 2015 would I invalidate blocks? It sounds like bitcoin-core would take the blockchain (and other nodes) as the source of time
< wumpus>
there's an option to override that logic IIRC
< Sentineo>
need to look into timedata.h, that might answer it
< sipa>
it also never adjusts more than 1 hour iirc
< wumpus>
(for the node time, not for the consensus logic obviously)
< wumpus>
-maxtimeadjustment=0
< Sentineo>
yeah turned off ntp on my laptop, but will see. I will perhaps use regtest and disconnect from the internet for that time :)
< wumpus>
also if you just want to test w/ bitcoin and times there's setmocktime
< Sentineo>
ah ok, it must be in the unit tests than ... will look it up
< Sentineo>
ty!
< wumpus>
there's also the 'faketime' command that allows time machine experiments without changing time on your computer globally
< Sentineo>
ah wow
< Sentineo>
did not know that one
< wumpus>
"faketime - manipulate the system time for a given command" we use or at least used that for the gitian build to force a deterministic time
< Sentineo>
ah this is cool
< wumpus>
from my experience it doesn't work with very far future dates due to 32-bit timestamps, but YMMV
< Sentineo>
hm not getting peers when in future :)
< Varunram>
Hey guys, have a small question - Can anyone suggest an easy way to view the nSequence bit for rbf signalling? Thanks!
< Varunram>
well, nvm, I just parsed the json from getrawtransaction :)
< wumpus>
promag: I think it'd help a lot in changes that we're making that effectively set configuration for a single network
< promag>
+
< promag>
+1
< promag>
I don't think we should allow overwriting logs different networks
< promag>
*of different networks
< wumpus>
we could allow some settings to only appear in per-network configuration or command line
< wumpus>
we have no way of handling multiple daemons writing to the same log file so we really want to avoid that
< promag>
right
< promag>
maybe GetArg and friends could automatically handle options like `-(<network>-)?<arg>`?
< wumpus>
also it'd make no sense, we'd have to distinguish which daemon is logging for each line - if you really want to dump all your bitcoin logging to one place, you can already use -printtoconsole w/ some log aggregation like systemd
< promag>
right, proper logging
< wumpus>
yea that'd be another option
< wumpus>
to make it possible to prefix options with -regtest- and -testnet- or -mainnet-, that would (afaik) work just as well as per-network configuration files...
< promag>
wumpus: the only difference is that you must launch with the network argument
< promag>
so that it can read from the correct config file
< promag>
with a single file, GetArg could 1st check -(<network>-)?<arg> and then -<arg>
< aj>
hmm, does "-testnet-logfile=BLAH" make more sense than "-logfile=blah-$NETWORK-log" ?
< promag>
aj: IMO it does, with $NETWORK you are stick to that replacement
< promag>
anyway, something to discuss thrusday
< aj>
promag: you could still use different conf files (-conffile or network specific) to have different names, but yeah, i think i agree
< aj>
promag: i think setting -logfile=blah should be treated as -mainnet-logfile=blah, so if you run -regtest or -testnet you get an error, though...
< hkjn0>
hey, I noticed that getrawtransaction says "Use gettransaction for wallet transactions" when it doesn't have a transaction.. but the gettransaction RPC doesn't seem to exist on my node, presumably because I compiled it with --disable-wallet?
< aj>
promag: (or it uses the default location, rather than erroring probably)
< hkjn0>
if that's what's going on, might it make sense to still have all the wallet RPCs stubbed out with a helpful message, even when wallet support is not compiled in?
< wumpus>
hkjn0: would be better to change the getrawtransaction message to not mention the wallet if wallet support is not built in
< achow101>
hkjn0: gettransaction is a wallet rpc, so if you did --disable-wallet, it won't exist
< hkjn0>
ok wumpus, that also would make sense to me, but we agree current messages are somewhat confusing?
< wumpus>
stubbing out the methods would add some code, and would make the wallet method names exist in yet another place, I prefer for nothing wallet-related to be in the client at all if built without
< wumpus>
--disable-build is very much an advanced option, we don't ship binaries with that, and assume people that use it know what they're doing
< wumpus>
disable-wallet lol
< hkjn0>
clearly a risky assumption, in my case! :)
< hkjn0>
ok, if the change is to just modify the getrawtransaction message if wallet isn't enabled, what's the best way to do that? should I file an issue?
< wumpus>
make a patch and file a PR
< wumpus>
if you create an issue for something non-critical without providing code, it's unlikely it's ever picked up
< hkjn0>
I'm just asking for advice for best processes here, change might be simple enough that I can give it a whirl.. but the change is so small an issue is unnecessary here?
< hkjn0>
or is it preferred to have issue + patch, even for small changes?
< wumpus>
we always handle code changes through github PRs, even small ones
< wumpus>
they still need review
< aj>
jnewbery: btw, are you going to revive #11047 ?
< hkjn0>
wumpus: sorry if I was unclear, I realize all changes go through PRs, but my question was whether it was encouraged to have PR + GH issue even for small changes, or if PR alone would suffice
< wumpus>
PR alone is fine
< hkjn0>
cool
< wumpus>
sorry, was also confused by terminology, as github regards a PR also as a kind of issue
< instagibbs>
hkjn0: please at least describe if it fixes something though
< hkjn0>
instagibbs: could you elaborate? are you saying "use good descriptions in commits / PRs", or something else?
< instagibbs>
hkjn0: right, as appropriate. At a minimum in the PR, so I can git blame and backtrace
< instagibbs>
certain contributors aren't that great at it :P
< hkjn0>
kk, for sure.. I'm pretty used to commit messages many times longer than actual code diff :)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11744: net: Add missing locks in net.{cpp,h} (master...missing-net-locks) https://github.com/bitcoin/bitcoin/pull/11744
< instagibbs>
hkjn0: perfect :)
< jnewbery>
aj: it's not near the top of my list. If you want it, it's yours!
< aj>
jnewbery: does it need anything other than regular rebases and nit fixes?
< ChuckSupport>
Good day! I've been saving up since 2015 to buy my own antminer and finally mine on core and not GPU mine. I'm a QA first developer second and would like to contribute but I'm still new to github practices. Can someone suggest how I could go about this? Start with github practices, then how can I pull test code and test ,etc. Thanks for everything you've done and sacrificed for this!
< andytoshi>
Chris_Stewart_5: #bitcoin-mining will probably be more helpful, or #bitcoin. this channel is specifically about software development of Bitcoin Core
< andytoshi>
sorry Chris_Stewart_5 i meant to highlight that guy who left
< meshcollider>
aj: are you here atm?
< aj>
meshcollider: hey
< meshcollider>
aj: re #10996, I'm just a little confused now
< meshcollider>
-netconf is just -conf but relative to net-specific datadir?
< aj>
meshcollider: yeah: patch makes bitcoind load two config files, .bitcoin/bitcoin.conf and .bitcoin/testnet3/network.conf; -conf lets you choose a different name for the first one, -netconf a different name for the second one
< meshcollider>
I like the default reading of the network specific config file but I'm worried the parameter interaction between conf and netconf will confuse users
< aj>
meshcollider: i worry about that too. current behaviour is that bitcoin.conf is loaded first and network.conf second (so bitcoin.conf can specify the network), and any setting in bitcoin.conf overrides any setting in network.conf
< aj>
meshcollider: (ie, GetArg returns the first value seen, GetArgs returns all of them from both files)
< meshcollider>
aj: Perhaps instead of -netconf parameter, just rely on -conf for specifying a config file if they want (because they can specify one in a net-specific directory explicitly if they want) and then only load the network.conf if -conf is not specified?
< aj>
meshcollider: hmm.. the choice i'm seeing is between having a param to let you choose a different name for the file, or no param at all and just always checking for datadir/network.conf
< meshcollider>
I think if people are explicitly specifying a different config with -conf parameter, we can assume they want to use it on the network they've specified right?
< meshcollider>
So if they use -conf, we only load that, but if they don't then we load the network specific file by default too?
< meshcollider>
aj: But perhaps I haven't fully understood the use case so it's your call
< jnewbery>
aj: sorry for long delay. Yes, just rebase and nits. Rebase should be easy - it's just a case of re-running the script
< aj>
jnewbery: no worries about the delay, that's why the i in irc doesn't stand for instant :) sounds good, i guess i'll check with MarcoFalke that there's not more reason to close it than inactivity
< aj>
meshcollider: i'm not sure if there's a use case... atm, you could have standard settings in bitcoin.conf and special settings in network.conf (mainnet addnode's say), and switch either independently via command line options. that just seems a bit more flexible and maybe natural to me?
< meshcollider>
aj: Or, what if both the net specific file and the root datadir one had the same name, and -conf specified them both?
< meshcollider>
Or would having them both called bitcoin.conf be confusing
< aj>
meshcollider: mainnet bitcoin.conf and network.conf live in the same directory :(
< meshcollider>
Ah true lol
< meshcollider>
aj: Hmm perhaps someone else will give feedback on the approach too, I think I'd still prefer not having the netconf command and just using conf if it's specified but yeah no massive leaning either way
< aj>
meshcollider: i might see if i can code up your way and match the tests, see what it looks liek
< meshcollider>
aj: sounds good, thank you! :)
< meshcollider>
Sorry for being difficult :)
< aj>
meshcollider: i don't expect to like it, but i've been wrong before :)
< aj>
meshcollider: hmm, question is, if i respond in less than two weeks, will the difficulty increase...