< wumpus>
jnewbery: performance improvements are a bit of a grey area, agreed, but I think in general we've taken "feature freeze" as "no more user-facing features" and did still merge other non-bugfix changes such as optimizations and refactors
< jnewbery>
wumpus: is that formalised/documented anywhere? I'd argue we probably shouldn't be doing performance/refactors during a feature freeze
< wumpus>
ok, yes, some people disagree on that, it has alwys been a fairly good time to do, for example, code moves, because there was no pressure for something else to get in
< wumpus>
a feature freeze is really about features, don't know about extending it to other things too, it was usually after the first rc that only bugfixes make it in
< wumpus>
I don't particularly have any optinion about this one way or the other, btw
< wumpus>
it's always been more a heuristic about not merging large risk things last minute
< wumpus>
no matter waht kind of change it is
< jnewbery>
yeah, I don't have a strong opinion either. Mostly trying to understand the process/rationale
< wumpus>
AFAIK the reason features are treated specialy here is because they usually involve extra translation strings, and tend to be trickier to test (might involve manual testing in some cases, even for pure API features someone needs to try it out whether it is usable)
< wumpus>
so it's better to have it longer in before a release
< stevenroose>
So I'm trying to automate a test of an RPC client library for Core, but I can't seem to get regtest to provide a fee estimate. No matter how many blocks I create, I keep getting "Insufficient data or no feerate found"
< stevenroose>
I create a few txs with non-zero fees before. Should I make more of those.
< sipa>
stevenroose: do you submit the transactions individually too?
< stevenroose>
Yeah, in other test methods.
< stevenroose>
It's a total of 10 maybe, though
< stevenroose>
Do I need more of them?
< aj>
stevenroose: do any of them sit in the mempool, or do they all get confirmed immediately in the next block? i think you need some to sit in the mempool?
< sipa>
i suspect you need many more, but i don't know for sure
< sipa>
yeah they have to sit in the mempool, and then confirm
< stevenroose>
Ah I do mine blocks before, so there's never any in the mempool.
< sipa>
then there is jo way to measure how quickly they confirm :)
< stevenroose>
Heh? What does the "and then confirm" mean?
< stevenroose>
Was afk for a bit. So I tried to generate 2 empty blocks, invalidate them, create a bunch of txs, reconsider the 2 empty blocks, then mine a tx. So purely from the mempool, that should look as if it took 2 blocks to confirm those txs.
< stevenroose>
I do that 10 times in a row with 10 transactions.
< stevenroose>
I'm trying to find a pure RPC way to do this, but it seems like it's not possible. Go and mine a block in pure code (like Python does it) is a bit more annoying, wanted to avoid that.
< sipa>
stevenroose: i would not be surprised if the fee estimation code ignores transactions that get reorged
< stevenroose>
they don't get reorged
< stevenroose>
In the scenario I detailed above, no txs get confirmed and then unconfirmed.
< stevenroose>
There are just 2 empty blocks reconsidered whle they are in the mempool.
< stevenroose>
Perhaps the fee estimation logic doesn't count reconsidered blocks as "a new block is mined"
< aj>
stevenroose: i think it compares the height of the tip when the tx was first seen, and the height of the block it was mined in
< aj>
stevenroose: so i think that should be plausible
< stevenroose>
and invalidated blocks count as tip?
< stevenroose>
hmmm
< stevenroose>
I'm going to bed, gonna think about this more tomorrow probably. About copying the dat file, how version-compatible is that?
< stevenroose>
I'm a bit reluctant to do that, but it's a possibility.
< stevenroose>
Alternative is implementing mining in Rust..
< aj>
stevenroose: it got an upgrade in 0.15.0, anything since then has been the same
< stevenroose>
aj hmm, k thanks
< stevenroose>
that's good, I don't think we'll be supporting anything before 0.18.0
< aj>
stevenroose: you might need the chain you're using to have a similar height as the one you got the fee estimates from
< aj>
stevenroose: (there's functional tests that test estimates though, so just copy one of those)
< sipa>
stevenroose: i think the easiest approach is just mining blocks directly from python
< sipa>
as all infrastructure is already there
< stevenroose>
but I'm not using python..
< sipa>
wait, what are we talking about then?
< sipa>
ah, rpc client library
< sipa>
if you just want to test what rpcs work and give syntactically correct answers, and not want to test the fee estimation logic itself, you can probably just create enough transactions that don't fit in a block, and use the generate RPCs
< sipa>
the more you deviate using things like reorgs or block invalidation, the less representative the test will be
< sipa>
have a look at what test/functional/feature_fee_estimation.py does