< morcos>
mine is in ~/.config/Bitcoin/Bitcoin-Qt.conf
< morcos>
I assume you are asking a different question, but settings in that file have bit me a few times
< Luke-Jr>
morcos: on Windows, it's in the registry; on Mac, somewhere else
< Luke-Jr>
the only reliable way to check is probably to use Qt
< sipa>
morcos: it's for answering a question on Stackexchange
< sipa>
additional information: windows
< morcos>
sipa: yeah the data directory is listed in the QT settings
< moli>
sipa, i'm not sure if you're looking for bitcoin-conf, but on windows by default it's in: C:\Users\UserName\AppData\Roaming\Bitcoin\bitcoin-conf
< moli>
oops, i meant bitcoin.conf
< sipa>
moli: i'm aware of that; but i'm not looking for the default datadir, i'm looking for how to find the datadir if it's been configured to be not the default
< moli>
sipa, i don't use the default, so my datadir is something like this: C:\bitcoin-0.12.0\bin\bitcoin-qt.exe -datadir=C:\Bitcoin
< moli>
so in the folder Bitcoin it has wallet.dat, bitcoin.conf, etc
< moli>
and to find a file in windows, i use "Search"
< moli>
and bitcoin.conf doesn't come with the download package, i have to create it and then put it in Bitcoin folder
< sipa>
moli: Bitcoi-Qt allows you to configure the datadir on first use, and stores it in the registry
< sipa>
if you put the datadir on the command line, it's wasy of course :)
< moli>
yes, i guess i like to do it my way so i can remember where i put it, and i notice you have bitcoin.conf.5 in your bitcoin-segwit, i wish we could have bitcoin.conf in windows download package
< MarcoFalke>
wumpus, to be consistent, I'd have to add the future import for every .py file in /qa ?!
< wumpus>
MarcoFalke: yes
< wumpus>
any that uses print as a function, at least
< wumpus>
it *enforces* using print as a function
< wumpus>
so it's better to do it for all I guess
< wumpus>
that's why I started with the files used directly by the build system in #7723 - we can require python2.7 for the qa tests for now, but it's more annoying if `make check` needs a special dependency
< MarcoFalke>
You are planning to support py2 and py3 for the build system?
< wumpus>
yes
< MarcoFalke>
Sounds reasonable, but I don't think we can do it for the rpc tests
< wumpus>
it's only a few files, anyway
< wumpus>
I agree
< wumpus>
but please do the print_functions properly, that's all I ask :p
< wumpus>
unicode literal is more annoying, in general
< MarcoFalke>
Ok, will do; but don't complain about the huge diff
< wumpus>
I never complained about a huge diff in the test code
< MarcoFalke>
fine :)
< wumpus>
and I mean if everyone is okay with dropping python2 support I'm fine with that, but I predict it's going to be another thing people feel very strongly about, and I'm saving that energy for arguing for c++11 for now :)
< sipa>
wumpus: i was thinking of writing an alert replacement based on theymos's proposal, using schnorr multisig once that's stable in libsecp256k1 (that would allow the entire message, including signature(s), to fit in an op_return)
< wumpus>
sipa: sgtm
< GitHub114>
[bitcoin] jtimon opened pull request #7727: Travis test (not to merge): Introduce silent bug in CFeeRate (master...0.12.99-feerate-test-bug) https://github.com/bitcoin/bitcoin/pull/7727
< morcos>
Luke-Jr and any one else: I'd like to improve fee estimation for 0.13. I think it'll be a lot easier if I can start from cleaner code by ripping out priority estimation. I believe no one cares much about that?
< morcos>
It looks to me like you don't get a valid priority estimate until 66 blocks (hacked up with longer block estimates)
< morcos>
So the effect of the priority estimation cdoe now is to do basically only 1 thing, not let you send a free transaction if your mempool is limited, otherwise it gets an answer of -1 for priority estimation and defaults to AllowFree
< morcos>
That seems like pretty bad behavior, but its also only available from a debug option now anyway after #7686
< morcos>
Are there any objections to removing priority estimation?
< GitHub50>
[bitcoin] jtimon opened pull request #7728: Fees: Tests: Check CFeeRate internal precision in mempool_tests.cpp (master...0.12.99-feerate-precision-test) https://github.com/bitcoin/bitcoin/pull/7728
< GitHub31>
[bitcoin] jtimon opened pull request #7731: Discussion: By "more precision", I don't mean using rational numbers in CFeeRate (master...0.12.99-feerate) https://github.com/bitcoin/bitcoin/pull/7731
< jtimon>
morcos: wumpus: MarcoFalke this is what I meant the other day, I'm sorry it took me days to have something that could potentially make some sense: https://github.com/bitcoin/bitcoin/pull/7731
< jtimon>
could we need more precision in practice in the foreseable future? it is the first time that I consider this from the "we may actually need this at some point" and not just purely from "reusable style is generally better unless tradeoffs" standpoint
< jtimon>
anyway, just food for thought (and 1 test I wasn't expecting), should go do some actual work, this was too much of a distraction