< 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
< GitHub59> [bitcoin] CypherGrue opened pull request #7726: Correct importaddress help reference to importpubkey (master...master) https://github.com/bitcoin/bitcoin/pull/7726
< moli> sipa and devs, and thanks for all the hard work you've done! :)
< jonasschnelli> sipa: we might want to list the datadir in the debug window...
< jonasschnelli> We could remove the "build date" for stable releases (keep it for self compiled versions).
< wumpus> jonasschnelli: +1 on removing build date and adding the datadir
< jonasschnelli> Okay. Will change that soon.
< wumpus> build date should really be removed, it's non sensical for gitian builds anyway
< GitHub112> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/29e1131c4642...7b832d286bd1
< GitHub112> bitcoin/master 3252208 João Barbosa: Improve EncodeBase58 performance
< GitHub112> bitcoin/master 7b832d2 Wladimir J. van der Laan: Merge #7656: Improve EncodeBase58 performance...
< GitHub94> [bitcoin] laanwj closed pull request #7656: Improve EncodeBase58 performance (master...enhancement/speedup-encodebase58) https://github.com/bitcoin/bitcoin/pull/7656
< 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 :)
< GitHub165> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/7b832d286bd1...ddfd79659e31
< GitHub165> bitcoin/master fab6880 MarcoFalke: [qa] Add amount tests
< GitHub165> bitcoin/master faf756a MarcoFalke: [amount] Make GetFee() monotonic...
< GitHub165> bitcoin/master fad13b1 MarcoFalke: [amount] Preempt issues with negative fee rates
< GitHub81> [bitcoin] laanwj closed pull request #7705: [amount] Add tests and make GetFee() monotonic (master...Mf1603-amountFix) https://github.com/bitcoin/bitcoin/pull/7705
< GitHub166> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ddfd79659e31...9426632cb58d
< GitHub166> bitcoin/master c90036f Patrick Strateman: Always disconnect old nodes which request filtered connections.
< GitHub166> bitcoin/master 9426632 Wladimir J. van der Laan: Merge #7708: De-neuter NODE_BLOOM...
< GitHub6> [bitcoin] laanwj closed pull request #7708: De-neuter NODE_BLOOM (master...2016-03-17-nodebloom) https://github.com/bitcoin/bitcoin/pull/7708
< wumpus> BlueMatt: can you take a look at https://github.com/bitcoin/bitcoin/pull/7713, it changes verify-commits.sh
< GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9426632cb58d...3b4324b1edd7
< GitHub129> bitcoin/master fab3890 MarcoFalke: [qa] rpc-test: Normalize assert()
< GitHub129> bitcoin/master 3b4324b Wladimir J. van der Laan: Merge #7720: [qa] rpc-test: Normalize assert()...
< GitHub82> [bitcoin] laanwj closed pull request #7720: [qa] rpc-test: Normalize assert() (master...Mf1603-qaAssertNorm) https://github.com/bitcoin/bitcoin/pull/7720
< GitHub97> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3b4324b1edd7...3c27067dd2db
< GitHub97> bitcoin/master 0f17692 João Barbosa: Improve COutPoint less operator
< GitHub97> bitcoin/master 3c27067 Wladimir J. van der Laan: Merge #7712: Improve COutPoint less operator...
< GitHub164> [bitcoin] laanwj closed pull request #7712: Improve COutPoint less operator (master...enhancement/improve-coutpoint-less-operator) https://github.com/bitcoin/bitcoin/pull/7712
< GitHub131> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3c27067dd2db...9af69fa7e7b7
< GitHub131> bitcoin/master c5825d2 Denis Lukianov: Correct importaddress help reference to importpubkey
< GitHub131> bitcoin/master 9af69fa Wladimir J. van der Laan: Merge #7726: Correct importaddress help reference to importpubkey...
< GitHub194> [bitcoin] laanwj closed pull request #7726: Correct importaddress help reference to importpubkey (master...master) https://github.com/bitcoin/bitcoin/pull/7726
< GitHub99> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/9af69fa7e7b7...29b2be6ad789
< GitHub99> bitcoin/master bbb9d1d BtcDrak: Remove p2p alert handling
< GitHub99> bitcoin/master 9206634 BtcDrak: Update alert notification and GUI
< GitHub99> bitcoin/master 01fdfef BtcDrak: Remove `-alerts` option
< GitHub62> [bitcoin] laanwj closed pull request #7692: Remove p2p alert system (master...remove_alert) https://github.com/bitcoin/bitcoin/pull/7692
< 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
< GitHub184> [bitcoin] laanwj opened pull request #7729: rpc: introduce 'label' API for wallet (master...2016_03_wallet_label_api) https://github.com/bitcoin/bitcoin/pull/7729
< GitHub174> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/29b2be6ad789...c946a15075ba
< GitHub174> bitcoin/master 9e072a6 Alex Morcos: Implement "feefilter" P2P message....
< GitHub174> bitcoin/master 5fa66e4 Alex Morcos: Create SingleNodeConnCB class for RPC tests
< GitHub174> bitcoin/master b536a6f Alex Morcos: Add p2p test for feefilter
< GitHub196> [bitcoin] laanwj closed pull request #7542: Implement "feefilter" P2P message (master...feefilter) https://github.com/bitcoin/bitcoin/pull/7542
< GitHub37> [bitcoin] jtimon closed 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
< sipa> morcos: agree on removing the estimation
< morcos> wumpus: i think you accidentally applied the feefilter to github's web server.
< wumpus> it will only accept http requests with enough fee now?
< morcos> apparently
< wumpus> angry unicorn: 402 Payment Required
< GitHub169> [bitcoin] morcos opened pull request #7730: Remove priority estimation (master...removePriEst) https://github.com/bitcoin/bitcoin/pull/7730
< 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
< BlueMatt> wumpus: will do