< 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)
< gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/10148 | [WIP] Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
< phantomcircuit> iirc what i ended up doing was randomly selecting sections to flush or something
< phantomcircuit> regardless of whether they just needed to be written or not
< phantomcircuit> and kept a list of things which needed to be written
< phantomcircuit> which of course increased memory usage because i did it poorly
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/35da2aeed7d4...e9274839bf31
< bitcoin-git> bitcoin/master 965a124 John Newbery: [tests] Fix abandonconflict.py intermittency
< bitcoin-git> bitcoin/master e927483 MarcoFalke: Merge #10344: [tests] Fix abandonconflict.py intermittency...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10344: [tests] Fix abandonconflict.py intermittency (master...fix_abandon_conflict) https://github.com/bitcoin/bitcoin/pull/10344
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e9274839bf31...314ebdfcb38d
< bitcoin-git> bitcoin/master f19abd9 Suhas Daftuar: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled...
< bitcoin-git> bitcoin/master 314ebdf MarcoFalke: Merge #10134: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10134: [qa] Fixes segwit block relay test after inv-direct-fetch was disabled (master...2017-03-fix-segwit-relay-test) https://github.com/bitcoin/bitcoin/pull/10134
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/314ebdfcb38d...170bc2c381f8
< bitcoin-git> bitcoin/master 3e3c22f John Newbery: [tests] fix wait_for_inv()
< bitcoin-git> bitcoin/master 170bc2c MarcoFalke: Merge #10318: [tests] fix wait_for_inv()...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10318: [tests] fix wait_for_inv() (master...fix_wait_for_inv) https://github.com/bitcoin/bitcoin/pull/10318
< 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 :)