< bitcoin-git>
[bitcoin] fanquake opened pull request #19558: build: split pthread flags out of ldflags and dont use when building libconsensus (master...split_out_pthread_flags) https://github.com/bitcoin/bitcoin/pull/19558
< elichai2>
fanquake: about bitcoin#19559 and secp #768, will I be able to reproduce this in a OpenBSD 6.7 VM with clang 8.0.1 installed and that's it?
< gribble>
https://github.com/bitcoin/bitcoin/issues/768 | Update seednodes, pick long-uptime nodes with version >= 0.4.0 by nanotube · Pull Request #768 · bitcoin/bitcoin · GitHub
< fanquake>
elichai2 yes
< elichai2>
kk, will try probing it later
< fanquake>
Not really expecting anything to change in libsecp, as the underlying problem is the macro and the fact that OpenBSD still bundles an ancient GCC
< fanquake>
Likely we'll just end up updating out OpenBSD build doc
< jeremyrubin>
jonatack: is your preference for me to fix these style changes and you'll re-ack?
< jeremyrubin>
Or prefer an add-on commit fixing whitespace?
< bitcoin-git>
[bitcoin] laanwj closed pull request #19542: Revert "refactor: replace CConnman pointers by references in net_processing.cpp" (master...2020_07_revert_19174) https://github.com/bitcoin/bitcoin/pull/19542
< jeremyrubin>
Ok I just added some refactor only commits to fix the spacing and make some variables 'modernized'
< jonatack>
jeremyrubin: fix and re-ack :)
< jonatack>
jeremyrubin: i do try to re-ack quickly when authors take feedback
< jonatack>
(nice work on that pr btw)
< CubicEarth>
Is the Bicoin Core fee estimator more or less broken? There isn't any change in estimated fee regardless of the timeframe selected, with the exception of 'within 2 blocks', which is currently showing about 70x the fee as everything else
< CubicEarth>
at least on my machine
< sipa>
how long has your node been running?
< CubicEarth>
Oh, and I'm running 19.0.1 ... so perhaps it's fixed on 20!
< jeremyrubin>
CubicEarth: You should try upgrading to the latest minor release instead of major
< jeremyrubin>
Can double check if any fee estimation fixes are in that one
< CubicEarth>
sipa: I was synced as of yesterday, and then off overnight. Then I fired it up just 15 minutes ago to make a transaction. Does it actually need to be live for some period of time (like many hours?) before the estimator works well?
< jeremyrubin>
(that's 19.1)
< sipa>
iirc there haven't been any changes to fee estimation for a long time
< jeremyrubin>
yeah I don't see any in either release notes
< sipa>
CubicEarth: rulw of thumb is that to get reliable N-block estimates, your node needs to be up for at least the past 2N blocms
< CubicEarth>
sipa: I see. Is that because it's comparing its own mempool observations with what ends up on chain?
< sipa>
yes
< jeremyrubin>
sipa: is that derived from nyquist???
< sipa>
jeremyrubin: no
< jeremyrubin>
;)
< CubicEarth>
It's a tempting for there to be a way to instruct your node to request fee data from somewhere else, to bootstrap the estimator. Understood that introduces an element of trust... but perhaps there could be safeguards?
< sipa>
CubicEarth: no need for a node in that case, just use a website
< sipa>
if you're happy to trust someone else to gether the information, just ask them directly
< CubicEarth>
sipa: I was just thinking of a way to not be typing in more numbers or manually copying and pasting, which I worry about the fat finger
< sipa>
well bitcoin core isn't going to contact a trusted third party
< sipa>
at least not by default
< CubicEarth>
sipa: definitely not by default!
< gwillen>
CubicEarth: I'm curious, does it seem like the fees it's showing were reasonable as of the block you were synced to, or were they crazier than that?
< CubicEarth>
A few minutes (5?) after turning on my node, it was suggesting a fee of 0.01252 mBTC/kB for all time frames, which at the moment is much too low. It seems like as it gets more data, it progressively recalibrates for the longer / less urgent time frames. But for sure it jumped from recommending 0.0125 up to 0.719 for the 4 block window once it got more current data
< CubicEarth>
* much too low for anything to happen in the next few hours
< gwillen>
mostly what I'm wondering is, does Core always seem to present estimates that are reasonable based on what it knows, or does it sometimes present estimates that are disastrously bad for which it clearly should know better
< sipa>
it probably should give an error for time frames too long for it to have data on
< gwillen>
(e.g. it seems like probably any estimate should come with a warning if you can see a header chain that is way past where you can see the blocks)
< gwillen>
yeah
< CubicEarth>
exactly
< CubicEarth>
The longer times seem like they could function somewhat reliably even if the node was only on intermittently during a similar period extending into the past. And reliable estimates for getting a tx into the next few blocks should be able to be build quickly :)
< CubicEarth>
I know I would rather have no estimate than a very bad estimate... and then I can look elsewhere or wait
< sipa>
CubicEarth: of course
< CubicEarth>
on a related note... I tried to used the RBF mechanism ;) And I was surprised that there was only one option presented as to how much of an increased fee to pay. again, NVM is this has been changed in 0.20.