< jtimon>
luke-jr: I isolated the new error in 9494, but I still don't understand it, did s/argsGlobal/gArgs/ accross the history but working on doing it more scripted as suggested by BlueMatt , so don't hurry up to ack until I say something in the PR (but never too early to nit)
< achow101>
where can I find the description of the fee estimation stuff?
< praxeology>
Does the fee estimator take CPFP into account?
< gmaxwell>
praxeology: it takes it into account by not being confused by it.
< praxeology>
gmaxwell: that is a pretty evasive answer. I would guess it would take it into account by grouping all transactions that depend on each other in a block into one transaction, so long as children are higher fee/byte than parents
< gmaxwell>
praxeology: IIRC it just ignores things with dependencies in its estimation, there are few enough that it doesn't matter.
< praxeology>
I guess so. CPFP parents would probably be statistical outliers
< phantomcircuit>
gmaxwell, that reminds me the cache shouldn't flush entries entirely like that
< sipa>
phantomcircuit: working on it
< phantomcircuit>
sipa, iirc i did this but couldn't get the change to pass tests...
< sipa>
(but it is much harder than you may think)
< phantomcircuit>
which was
< phantomcircuit>
uh
< phantomcircuit>
suspicious
< sipa>
i've made it work fine, it just ended up being slower
< phantomcircuit>
yeah but why is it harder
< sipa>
due to more frequent flushing
< phantomcircuit>
yeah it makes the flushing logic significantly harder
< sipa>
i'm planning on a background thread flushing now, after #10148
< SopaXorzTaker>
guys, will including an invalid public key in a tx, such as (0, 0), which obviously doesn't follow the y^2=x^3+7 rule, ever invalidate a multisig script
< SopaXorzTaker>
This is about core development, as this approach is currently valid but may stop being so in the future
< SopaXorzTaker>
my vanity P2SH address generator relies on that
< sipa>
SopaXorzTaker: there is currently no consensus rule that forbids that
< sipa>
though it is a bit complicated since bip66
< luke-jr>
there's no reason to assume there won't be a consensus rule in the future that does forbid it, although IMO such a rule shouldn't affect existing UTXOs, and it's hard to see how it could prevent new ones
< luke-jr>
either way though, it's not something that should be done ;)
< SopaXorzTaker>
luke-jr, I'll resort to using compressed dummy keys then
< luke-jr>
SopaXorzTaker: that's probably worse
< SopaXorzTaker>
hwy?
< SopaXorzTaker>
why?
< luke-jr>
if you must do one or the other, use the one that uses less space
< luke-jr>
SopaXorzTaker: because the only reason not to do it, is the abusive nature of adding unnecessary data; and compressed dummy keys is just as abusive
< SopaXorzTaker>
why?
< SopaXorzTaker>
because they have to be chacked
< SopaXorzTaker>
checked?
< luke-jr>
or at least downloaded by every node
< SopaXorzTaker>
wait
< SopaXorzTaker>
what that has to do with compressed keys
< SopaXorzTaker>
also, little offtopic: thanks for spending that puzzle P2SH address, I really appreciate my freedom :)