< bitcoin-git>
bitcoin/master b266b3e Russell Yanofsky: refactor: Create interfaces earlier during initialization
< bitcoin-git>
bitcoin/master e4f4350 Russell Yanofsky: refactor: Move wallet methods out of chain.h and node.h
< bitcoin-git>
bitcoin/master 24bf176 Russell Yanofsky: gui refactor: Inline SplashScreen::ConnectWallet
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19099: refactor: Move wallet methods out of chain.h and node.h (master...pr/wclient) https://github.com/bitcoin/bitcoin/pull/19099
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #19842: Update the vcpkg checkout commit ID in appveyor config (master...appveyor-vcpkg-update) https://github.com/bitcoin/bitcoin/pull/19842
< bitcoin-git>
[bitcoin] vasild opened pull request #19845: net: CNetAddr: add support to (un)serialize as ADDRv2 (master...ser_addrv2_cnetaddr) https://github.com/bitcoin/bitcoin/pull/19845
< vasild>
I added a new file, but travis complains that the file is missing: https://travis-ci.org/github/bitcoin/bitcoin/jobs/722729138#L3366. I have no idea what's going on. I ran this via my "private" travis and it complained the same. I sneaked a "find ./ ..." in travis scripts and the file is not present indeed. But the file is present when I do a fresh git clone locally.
< instagibbs>
who is actively contributing that knows the fee estimation guts the best?
< aj>
instagibbs: got a particular question?
< instagibbs>
if a user manually set their min mempool feerate to X, the estimator shouldn't be attempting to give estimates below those rates, yes? Excluding previously generated historical data
< instagibbs>
which should decay over time IIRC
< aj>
not sure it couldn't get results slightly below that due to bucketing (couldn't make it bug that way when i tried, but didn't try that hard), otherwise i think so
< instagibbs>
user was getting 10x "upcharges" between estimated fee calls and wallet calls, seemingly over weeks, was curious how that persisted
< instagibbs>
due to them setting a higher min relay fee*
< bitcoin-git>
[bitcoin] Zero-1729 opened pull request #19846: build: enable unused member function diagnostic (master...enable-unused-member-function-diagnostic) https://github.com/bitcoin/bitcoin/pull/19846
< aj>
instagibbs: probably takes a while for old data to go away; if it was getting the estimate from the long_decay estimator, could be ~100 days for the old data to stop being worth considering?
< aj>
instagibbs: maybe two weeks for medium estimator
< aj>
instagibbs: (or maybe my maths is wrong; suhas/morcos/jnewbery might have a better idea)
< hebasto>
aj: mind looking into #19668 ?
< instagibbs>
aj, right i only know roughly when it'll give estimates, not when it stops
< instagibbs>
users probably should be taking max(estimatesmartfee, minrelay) when doing their calculations but that's a bit unexpected
< aj>
instagibbs: probably the fee estimator should be ignoring anything below minrelayfee, since that's guaranteed to be unusable and baded on old data at best?
< luke-jr>
aj: or new data
< luke-jr>
aj: or perhaps your minrelayfee just isn't what others are using
< aj>
luke-jr: the fee estimator won't see any transactions below your min relay fee, whatever others are using
< bitcoin-git>
bitcoin/master a104cae Aaron Clauson: Update the vcpkg checkout commit ID in appveyor config.
< bitcoin-git>
bitcoin/master 068bc21 MarcoFalke: Merge #19842: Update the vcpkg checkout commit ID in appveyor config
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19842: Update the vcpkg checkout commit ID in appveyor config (master...appveyor-vcpkg-update) https://github.com/bitcoin/bitcoin/pull/19842
< sdaftuar>
gleb: i've modified the sync-tips-with-feelers idea some, i have two approaches that i implemented
< sdaftuar>
gleb: one problem i saw with the sync-tips-with-feelers idea was that feelers are chosen from the new table exclusively, in order to move things to the tried table
< sdaftuar>
for ensuring that your tip isn't behind, i think you want to try peers in general, including from the tried table
< sdaftuar>
so my first approach was to create a new kind of connection -- i think i called it "chain-sync" in my code, though maybe not a great name -- that is similar to feelers (in that we try every few minutes, on average, and when successfully connected to one we stay connected for about a minute to give headers-sync a chance to happen, and then we always disconnect
< sdaftuar>
my alternate approach is a bit different: rather than create a new peer-type, just make a new block-relay-only connection (like feelers, try this once every few minutes), and again give the peer a chance to sync tips by waiting about a minute so that headers sync can occur
< sdaftuar>
then, in choosing which block-relay peer to evict, evict either the new connection if it didn't teach you any new blocks, OR if it did, evict your next youngest block-relay peer
< sdaftuar>
so this ends up being a block-relay-peer rotation algorithm, in the event that you're learning things from these connections
< sdaftuar>
(credit to gmaxwell for suggesting that second approach btw)
< sdaftuar>
i think the second approach is probably better, because it lets us actually escape a scenario where we've been partitioned off the honest network
< sdaftuar>
the main concern i had was whether we might skew the network graph as a whole to encourage block-relay connections to the fastest (eg mining) nodes, which will be more likely at random to occasionally give us a new block first even when we're not under attack
< sdaftuar>
but i've been running that patch for a couple weeks now and haven't yet triggered a scenario where i've evicted an older block-relay peer, so this might be fine
< bitcoin-git>
bitcoin/master fa93bc1 MarcoFalke: rpc: Remove unused return type from appendCommand
< bitcoin-git>
bitcoin/master faaa46d MarcoFalke: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining)
< bitcoin-git>
bitcoin/master fa32c1d MarcoFalke: rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq)
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump) (master...2008-rpcMisc) https://github.com/bitcoin/bitcoin/pull/19717
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19849: Assert that RPCArg names are equal to CRPCCommand ones (blockchain,rawtransaction) (master...2008-rpcAssertNames) https://github.com/bitcoin/bitcoin/pull/19849
< hebasto>
aj: thanks for your attention!
< pinheadmz>
does the bitcoind wallet ever spend coins that are `untrusted_pending` ?
< achow101>
pinheadmz: no
< bitcoin-git>
[bitcoin] promag opened pull request #19851: refactor: Extract ParseOpCode from ParseScript (master...2020-08-parseopcode) https://github.com/bitcoin/bitcoin/pull/19851
< sdaftuar>
fjahr: i have notied that as well but don't know what to do about it
< sdaftuar>
it had failed on one of my PRs, but restarting fixed it. i just restarted that same job on #19724 for the second time, trying to get a passing run
< sdaftuar>
if it is failing on a widespread basis we should probably remove the job until we come up with a way for it to be more robust.
< fjahr>
sdaftuar: thanks, I agree. Not sure how widespread the persistent failures are though. I made a report on the community page but I don't have high hopes something is going to come out of it in the short term: https://travis-ci.community/t/arm64-failing-without-message/9775
< sdaftuar>
thanks for trying that!
< bitcoin-git>
[bitcoin] promag opened pull request #19852: refactor: Avoid duplicate map lookup in ScriptToAsmStr (master...2020-08-scripttoasmstr) https://github.com/bitcoin/bitcoin/pull/19852
< gmaxwell>
https://github.com/bitcoin-core/secp256k1/pull/558 looks ready-ish to merge, so if anyone wanted to review ack this updated version that reflects the latest BIP340 changes (even R), it's time!