< meshcollider>
achow101: does the RPC console window position also need fixing?
< meshcollider>
(for 11335)
< achow101>
meshcollider: actually, probably
< achow101>
let me check
< achow101>
yup, same thing happens with the rpcconsole window
< meshcollider>
ok I'll push that and squash them all
< achow101>
it's position is not being saved for me
< meshcollider>
just for the RPC window? Or the main window too?
< achow101>
rpc window
< achow101>
meshcollider: it's only happening if I have -resetguisettings in my command
< meshcollider>
If you don't have -resetguisettings, does the RPC console window still not save position though?
< meshcollider>
Of course it will not save position if you reset the settings, because that flag calls settings.clear(); which clears all QSettings
< achow101>
meshcollider: no, it saves if -resetguisettings was not in the command
< achow101>
-resetguisettings should be a one and done thing, so after I start up, I shouldn't have a problem with saving settings
< meshcollider>
hmm actually yeah that's really weird, it definitely saves the position for me even while running with -resetguisettings
< meshcollider>
and in the code, the only time it is accessed is at app.createOptionsModel(gArgs.IsArgSet("-resetguisettings")); which is called from main()
< meshcollider>
so I have no idea how the behavior you're describing could be happening
< Machine_Ex98>
hello any idea to resolve gap_limit ??
< Machine_Ex98>
We currently offer Bitcoin withdrawals and deposits on our website. Blockchain API is used to handle all operations.
< Machine_Ex98>
Only problem is Blockchain Receive API’s 20 address gap limit
< CryptAxe>
You don't have to ask on every channel.. And that's a companies API not the API of Bitcoin itself
< Machine_Ex98>
you talk too much i dont like that
< meshcollider>
Machine_Ex98: That's offtopic in this channel, this channel is only for bitcoin core development
< CryptAxe>
There is your answer you can stop spamming every channel
< Machine_Ex98>
this not answer its explain lol
< meshcollider>
Take it to #bitcoin
< Machine_Ex98>
if 20 people no one of them pay then whats will do ??
< luke-jr>
Machine_Ex98: and most importantly, *don't* use APIs
< Machine_Ex98>
Luke-jr whats should use !!
< luke-jr>
Machine_Ex98: a full node you run yourself in a secure facility.
< Machine_Ex98>
will its possible to bypass gap limit by making one address btc ??
< luke-jr>
Machine_Ex98: you won't get any help using web APIs here, and since it is a bad practice, I would hope nowhere.
< Machine_Ex98>
i dont know whats the point to open irc's server !!
< Machine_Ex98>
300 bots here without any reason
< meshcollider>
You'd get more help if you were in the right channel -_-
< Machine_Ex98>
wtf
< luke-jr>
meshcollider: hopefully not
< luke-jr>
Machine_Ex98: what service do you run?
< Machine_Ex98>
whats this channel for ?
< meshcollider>
luke-jr: true, I mean help in general, even help running a full node himself
< Machine_Ex98>
this a shiit irc software
< meshcollider>
Machine_Ex98: I already told you that this channel is for bitcoin core development, read the channel name and description, go to #bitcoin channel
< Machine_Ex98>
irc has gone on 2007 ضall the rest (shiit)
< luke-jr>
Machine_Ex98: what service do you run?
< Machine_Ex98>
fk you all
< gmaxwell>
Another satisfied customer. Ding.
< gmaxwell>
In the future, please make it clear to people that they will get help in the right place. (e.g. by going and offering to help them yourself there, if you can). Otherwise, the OT response just sounds like a go away.
< luke-jr>
there is no right place to get help screwing people over by running an incompetent web wallet using blockchain.info's API.. :/
< gmaxwell>
indeed, but there are better places to be walked through where not to do that. (also, just giving him their support contact information would probably have answered his immediate question.
< BashCo>
0.15 is crashing here on Mac OS 10.9.5 due to segmentation fault. When I use disablewallet=1 it comes up fine. Is this a known issue?
< jl2012>
BashCo: try removing bitcoin.conf. Should be fine
< jl2012>
should be related to #11332 . See the transcript of last meeting
< gribble>
https://github.com/bitcoin/bitcoin/issues/11332 | Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) by jonasschnelli · Pull Request #11332 · bitcoin/bitcoin · GitHub
< achow101>
BashCo: can you pastebin the contents of ~/Library/Preferences/bitcoin-qt.plist (or something like that I think)
< achow101>
BashCo: then start with -resetguisettings
< luke-jr>
jl2012: nCustomFeeRadio isn't in bitcoin.conf …
< BashCo>
removing the bitcoin.conf was the first thing I tried but no luck. my mac os 10.12 system didn't have any issues at all. It's still syncing, then I'll try the older system again. Bet -resetguisettings will fix it.
< achow101>
BashCo: please provide the contents of the file I specified. It has the qsettings info and I want to make sure that that is actually the problem
< luke-jr>
BashCo: try Knots
< luke-jr>
also what achow101 said
< jl2012>
luke-jr: oh, I rarely use the gui. It has another conf?
< luke-jr>
jl2012: yes, different on every OS
< achow101>
jl2012: not another conf, it's the qt settings storage
< luke-jr>
jl2012: on Windows, it's in the registry; on Linux, another ini file somewhere; on Mac, who knows XD
< achow101>
luke-jr: supposedly on mac it is a plist file at around the location I specified earlier
< achow101>
(I actually have no idea, that's just what google said)
< * luke-jr>
plugs #11082 which can be step 1 to unifying it
< esotericnonsense>
on linux it lives in .config/Bitcoin/Bitcoin-Qt.conf for me
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< esotericnonsense>
(regardless of datadir settings)
< achow101>
luke-jr: I don't think that would help since this is a qt specific thing
< achow101>
unless you mean that we should scrap qsettings altogether and do our own settings stuff
< luke-jr>
achow101: it's a possibility
< luke-jr>
haven't given much thought to whether actually-GUI-specific options should be moved there
< BashCo>
achow101: -resetguisettings worked. Unfortunately I did that before looking for the plist file. :( I found the file though, called `org.bitcoin.Bitcoin-Qt.plist`.
< BashCo>
achow101: here's the plist file contents. I probably botched it by using resetguisettings first. https://pastebin.com/Avi6c20Z
< achow101>
BashCo: yeah, having the file after doing resetguisettings is not particularly helpful
< achow101>
but at least we know where the file on osx is
< BashCo>
my bad. sorry about that.
< BashCo>
achow101: would the crash log be helpful?
< achow101>
BashCo: yes
< achow101>
we've already figured out the most probably cause, so this is only to confirm that it's the same problem
< BashCo>
sent via DM.
< esotericnonsense>
so i'm investigating #11315 Prune undermines the dbcache
< esotericnonsense>
unless i'm misinterpreting it seems to imply that any prune event will cause a flush, unless flush just means write in this context?
< esotericnonsense>
it seems to me that you need to write (because otherwise in the case of an unclean shutdown, you've potentially deleted the blocks you would need to recover) but you don't need to drop the cache entirely
< esotericnonsense>
ah, perhaps there's only a flush and no way to simply write :)
< sipa>
yes, there is
< sipa>
*yes, there is no simple write
< sipa>
every write to the chainstate requires first writing changes to the block index, to avoid having a chainstate that contains results of blocks that aren't known anymore after restart
< esotericnonsense>
i think i understand gmax's comment now, you'd let it increase to say prunesize+buffer+dbcache and then prune down (so the interval between prunes is dbcache+buffer rather than buffer)
< esotericnonsense>
that seems kind of hacky though, it's more like adding a range to prune so that it doesn't go off too often
< sipa>
right
< esotericnonsense>
a problem i can see with using dbcache is that if a user has an extremely high value set there could be unexpected results, would need to be documented
< esotericnonsense>
e.g. prune=2000 dbcache=16000, now you can actually use 18GB prior to pruning, hm
< gmaxwell>
esotericnonsense: yes, but we can document it, there are already interactions like that: e.g. the shutdown warning is moved up by the dbcache
< esotericnonsense>
ah, hello. i was just writing a reply on the issue.
< gmaxwell>
IMO ultimately we will end up not having MB tunable pruning. It doesn't really make a lot of sense.
< esotericnonsense>
i was thinking that perhaps using a percentage of the prune as the buffer might work and not require an additional config flag
< gmaxwell>
there shouldn't be an extra setting for sure. please no more options that users can't sensibly configure.
< esotericnonsense>
right now the performance hit is the same regardless of whether you have prune=100000 or prune=1000 (once you get past the point at which it starts doing it)
< gmaxwell>
The point I was trying to make in the issue, I think, is that setting prune shouldn't effectively override your dbcache setting.
< esotericnonsense>
it might be useful for me to get some hard numbers for how much sync time increases depending on the buffer size
< esotericnonsense>
i recall it being 30% slower or more in my testing, but it wasn't very scientific, getting that down to 5% or something would be a pretty big win
< esotericnonsense>
(and that was on SSD)
< gmaxwell>
esotericnonsense: oh jesus no. The difference between a maximum dbcache and default is something like an 8 hour sync vs a 3 hour one.
< esotericnonsense>
yeah, i didn't let it run to the end before increasing the prune target :P
< esotericnonsense>
(i basically did the manual version of this by increasing prune to 50G, then down to 5G, then back up, etc)
< gmaxwell>
esotericnonsense: consider this, right now the chainstate on disk is 2.8gb adding the dbcache to the interval on syncing with defaults would end up with you needing to have 4GB free to sync bitcoin instead of 3.5.
< esotericnonsense>
gah
< esotericnonsense>
i'm forgetting that if it's in the cache it's not on disk
< esotericnonsense>
heh
< gmaxwell>
potentially at least.
< esotericnonsense>
well, during IBD and in cases where there hasn't been a lot of replacement
< esotericnonsense>
the default dbcache would still result in a lot of prune events flushing it though. hm.
< esotericnonsense>
oh wait it flushes anyway. duh
< esotericnonsense>
okay, that makes sense, i'll play around with it.
< bitcoin-git>
[bitcoin] esotericnonsense opened pull request #11359: Add a pruning 'high water mark' to reduce the frequency of pruning events (master...2017-09-add-pruning-hwm) https://github.com/bitcoin/bitcoin/pull/11359