< achow101>
was there any agreement on whether there would be a 0.15.0.1 with BlueMatt's fix for the customfeeradio thing?
< gmaxwell>
No soap radio.
< * luke-jr>
thinks it'd be better to do 0.15.1 with a few more fixes
< gmaxwell>
achow101: I think the plan right now is that we will fix things and get them into the 0.15 branch ASAP, then wladimir will decide to do a release or not.
< achow101>
ok
< achow101>
I'm working on the permanent fix right now
< luke-jr>
ie removing the radio entirely?
< gmaxwell>
luke-jr: what other moderately important things are there that we know of now
< achow101>
luke-jr: yes
< luke-jr>
gmaxwell: if it was important, it'd have blocked 0.15.0; is there a reason *not* to backport the GUI positioning fix & similar stuff, if we're doing another RC cycle?
< * luke-jr>
wonders what changed with PPA stuff to break the build there.
< gmaxwell>
oh did we make a post 0.15 positioning fix too
< achow101>
I thought that was determined to not be a problem by jonasschnelli
< achow101>
I believe the problem was I was testing on either an old version or with custom something that gave me the error
< achow101>
s/error/issue
< jonasschnelli>
achow101: it may be a problem for the PPA.
< jonasschnelli>
From what I knew so far was that the offscreen issue only affected windows
< luke-jr>
gitian binaries are not the only supported (or even preferred) deployment..
< gmaxwell>
I believe there are still problems. Go position the window as far down and left as you can, then restart... But perhaps for 0.15.0.1 we would just disable remembered position rather than twiddling around with it.
< jonasschnelli>
Offscreen situations are usually handled by the OS
< jonasschnelli>
stop remembering position would be reducing a feature for a few having problem with it.
< gmaxwell>
Yes, but the feature is minor (the software already takes a very long time to start) and the issue is very severe.
< gmaxwell>
I'm not saying that I think it should go away forever.
< jonasschnelli>
Some users arrange windows pixel by pixel.. :)
< gmaxwell>
But if we want to make a quick release it would be an easy way to prevent it from being a problem for sure.
< meshcollider>
11208 checks for full window inclusion on the screen, and uses available screen geometry not full screen so that whatever taskbars or things dont get in the way either
< meshcollider>
so I think its still an improvement even if the original issue is gone
< gmaxwell>
meshcollider: that sounds like the right thing to do. But also sounds like it deserves non-trivial testing with weird setups.
< bitcoin-git>
[bitcoin] achow101 opened pull request #11334: Remove custom fee radio group and remove nCustomFeeRadio setting (master...rm-nCustomFeeRadio) https://github.com/bitcoin/bitcoin/pull/11334
< jonasschnelli>
gmaxwell: I just moved the windows as far down as possible and it reopened there... is that a problem?
< jonasschnelli>
Same happends to notepad.exe
< jonasschnelli>
*happens
< jonasschnelli>
(Windows 8.1)
< gmaxwell>
can you get it back out of that position again
< jonasschnelli>
Yes.
< jonasschnelli>
(Testing 0.15)
< luke-jr>
what if you use the keyboard to move it such that the titlebar isn't visible?
< bane5000>
so i've enabled pruning on my core wallet (by creating bitcoin.conf in ~/.bitcoin/) and adding pruning=10000
< bane5000>
i've restarted the bitcoin-qt, however, the old blocks do not seem to be disappearing, as my harddrive space has not been reduced
< luke-jr>
bane5000: you mean prune=10000 ? note that user issues should be in #bitcoin though
< gmaxwell>
e.g. if your screen is 1920x1080, what happens if the location is 1919,1079
< bane5000>
luke-jr: Whoopsy :)
< bane5000>
luke-jr: Would you recommend keeping a certain amount of blocks? Perhaps 20 gigs?
< luke-jr>
bane5000: #bitcoin please
< bane5000>
ugh :(
< bane5000>
You probably give a better opinion though, but fine
< luke-jr>
I'm there too
< jonasschnelli>
gmaxwell: I guess you can only position to right-bottom -1,-1 with rededit.exe
< bane5000>
okay :)
< jonasschnelli>
IMO it reacts as expected and identical to any other window based windows application
< gmaxwell>
jonasschnelli: I think you could do so pretty easily like this: increase your resolution, position it to the right bottom of your lower resolution, decrease resolution.
< gmaxwell>
Though there may be other ways to end up there.
< meshcollider>
but its not practical if it appears mostly offscreen, having to manually move it, even if thats what other windows do
< jonasschnelli>
gmaxwell: I did change the screen size and it relocates to center at a certain point.
< jonasschnelli>
Maybe (like in a flexible screen size vm like I test in) you can end up by only showing a single pixel of the window... but I guess the OS makes sure you always see the left-top icon
< jonasschnelli>
However, I think this is not a problem anymore in 0.15 gitian binaries...
< gmaxwell>
if the OS does then thats probably sufficient, but then I don't understand how we ended up completely off the screen.
< jonasschnelli>
I'm unsure about compiling it manually ... though I'm not sure how you would do this on windows
< gmaxwell>
jonasschnelli: we still support QT4 and earlier QT5 too.. it's not fixed unless we have a workaround or refuse to build with incompatible versions.
< jonasschnelli>
gmaxwell: completely off the screen with 0.15 gitian binaries on Windows seems very unlikely (I could not reproduce it and I tried for 1-2 h)
< jonasschnelli>
gmaxwell: I agree about Qt4. But I don't think anyone builds a Windows binary without our depends system. It would be a nightmare
< gmaxwell>
maybe for windows you could argue to ignore anything but gitian but we could end up off screen on linux too.. can't we
< achow101>
is qt4 supported only for the ppa?
< jonasschnelli>
I have testes offscreen on Ubuntu 14, 16 and could also not reproduce it (by fiddling with the QSettings to set if offscreen). But possible for Qt5.
< jonasschnelli>
Qt4, I meant
< jonasschnelli>
achow101: I think BlueMatt has a reason to build it against Qt4... some KDE or something
< luke-jr>
jonasschnelli: testing merely Ubuntu is not meaningful.. there are many WMs, and Ubuntu only uses one or two
< jonasschnelli>
luke-jr: Yes. I agree. But IMO this is why we use Qt. Offscreen is either a OS thing or a QT thing.
< luke-jr>
I suppose testing without a WM (X11 and Wayland?) might be a good approach
< jonasschnelli>
If we are going to add patch for every WM, we will have a horrific cross-platform source code base
< jonasschnelli>
*add patches
< luke-jr>
I don't see why that'd be necessary
< luke-jr>
fixing it for the dumb-WM-with-no-protection should fix it for all
< jonasschnelli>
Offscreen seems very upstreamish... we (or someone else) need to fix it there (if its really an issue)
< luke-jr>
that assumes we're using upstream correctly
< gmaxwell>
saving location _at all_ seems upstreamish, but we have an implementation of that-- it seems to me that if we're implementing it, we're probably stuck implementing it completely.
< jonasschnelli>
I'm happy to review a patch... but quick-cross-platform fixed did turn out to be much more complicated then often initially intended
< achow101>
jonasschnelli: can we not just do that then to support the fix for qt4 and 5?
< jonasschnelli>
achow101: do what?
< meshcollider>
Should I modify 11208 to just call restoreGeometry
< luke-jr>
we should investigate if Qt actually implements it sanely
< achow101>
jonasschnelli: whatever those pages say to restore geometry
< meshcollider>
Those pages suggest either using restoreGeometry OR doing it how 11208 does it I believe
< luke-jr>
"The restore function also checks if the restored geometry is outside the available screen geometry, and modifies it as appropriate if it is:" sounds hopeful
< jonasschnelli>
achow101: Yes. We should update to restoreGeometry... maybe this does internally check the bounds.
< jonasschnelli>
Seems the much better approach then fiddling with the position (which is what Qt is supposed to do)
< jonasschnelli>
luke-jr: +1
< jonasschnelli>
Yes should replace our own saveWindowGeometry/restoreWindowGeometry with the Qt ones (not directly possible for the save)
< gmaxwell>
I wonder how this stuff interacts with -geometry
< achow101>
jonasschnelli: I tried with gmaxwell's suggestion of 1919,1079 and the window is definitely not visible on screen
< jonasschnelli>
achow101: via regedit.exe?
< achow101>
yeah
< jonasschnelli>
0.15.0 gitian binaries?
< achow101>
yes, from bitcoin.org
< jonasschnelli>
What happens if you place then +2 px?
< jonasschnelli>
achow101: Maybe this is the expected behavior: if you place the window in screen (manually with RedEdit.exe), you want to reopen there? To hit this by accident seems very unlikely
< gmaxwell>
jonasschnelli: I explained before. If you increase your resolution, position there. Shut down bitcoin. Reduce resolution. You will be in this state.
< jonasschnelli>
gmaxwell: That's a different issue.. that is solved.
< luke-jr>
…
< gmaxwell>
It's a hard state to get into, but then "my bitcoins are gone!" -- a typical user will not be able to recover without a tech guru friend at least.
< jonasschnelli>
achow101: placed it in-screen (-1,-1)
< luke-jr>
jonasschnelli: you can get (1919,1079) the way gmaxwell describes
< jonasschnelli>
luke-jr: how?
< luke-jr>
jonasschnelli: try to position it on the second monitor without snapping
< achow101>
jonasschnelli: anything that is technically on screen like 1919,1079 will not be fixed. but the user can't get to it
< jonasschnelli>
luke-jr: Thats indeed a viable argument
< jonasschnelli>
But wait...
< gmaxwell>
jonasschnelli: with a higher resolution you can easily drag to 1919,1079 (for example).
< achow101>
jonasschnelli: I increased the position so that I could see it. most of the window is off screen, but the corner that matters is
< achow101>
it can easily be covered up by the taskbar too so users can't get to it
< jonasschnelli>
I wonder how other applicationes (test Notepad.exe) would react in this case
< luke-jr>
stupidly IIRC
< gmaxwell>
(and there is probably a few pixel radius which is totally inaccessible but technically on the screen where the current behavior is not sufficient. But meshcollider's or hopefully QT's would be.
< gmaxwell>
Even if notepad is wrong (would be interesting to find out!) that still doesn't excuse bitcoin-- losing notepad is less serious then your wallet. :)
< achow101>
jonasschnelli: it does exactly the same thing; so long as the top left corner is technically on screen, it stays there
< luke-jr>
we can actually continue saving as we do now, but after restoring, call restoreWindowGeometry(saveWindowGeometry())…
< jonasschnelli>
I think we should update our codebase to use the Qt designated functions for restoring geometry (also available on Qt4) and see if this is better,.. then decide to patch this edge-case explicit in our codebase
< meshcollider>
havent tested yet though
< jonasschnelli>
achow101: you mean with Notepad.exe?
< gmaxwell>
yea, well I think we have a target edge case to test now. Hopefully QT does the right thing.
< achow101>
jonasschnelli: yes
< jonasschnelli>
I'm still convinced that this issue needs to be fixed in the cross-platform layer (Qt) rather then in the application GUI logic
< jonasschnelli>
I saw many cross-platform projects struggle after adding to much cross-platform UI patches and glitch-foixes
< jonasschnelli>
*fixes
< achow101>
jonasschnelli: it shouldn't be a problem if we use the Qt sanctioned method, no?
< meshcollider>
Oh that looks a lot better if it also checks for maximised and minimised right?
< meshcollider>
luke-jr: is that from Qt 4
< gmaxwell>
this code looks like it'll handle it.
< meshcollider>
or 5
< luke-jr>
meshcollider: 5.7
< gmaxwell>
might want to take a quick look at 4.x just to see if it still looks sufficient there.
< luke-jr>
so long as the current version works, IMO it's not our problem if older ones are broken
< achow101>
luke-jr: well qt4 is still used and supported, so we want to make sure that works too
< luke-jr>
(so long as we're outsourcing to Qt)
< gmaxwell>
luke-jr: meh, if we build with it, it should work. at least against serious issues (and I think the program being totally inoperable is serious)
< meshcollider>
speaking of Qt issues, does 5.9 fix any of the segfault crashes like #9683? (cf 10505)
< luke-jr>
gmaxwell: disable restoring position on Qt4? :p
< achow101>
luke-jr: qt4 has the same functions, we should check their behavior
< gmaxwell>
luke-jr: maybe you could argue that it was sufficient if the latest QT4 had it, in any case I expect it does have similar code. This stuff seems like GUI101.
< meshcollider>
I'd imagine 4 would still have decent restoring function anyway lol
< luke-jr>
gmaxwell: the Qt5 code there suggests it changed around 5.3
< gmaxwell>
thou shall not restore the window to a location which is completely inaccessible to the user.
< jonasschnelli>
Can we just get rid of Qt4 support? Qt 4.8 seems unmaintaned since a couple of years... very bad for a cross-platform layer
< luke-jr>
no objection from me anymore
< luke-jr>
fwiw
< gmaxwell>
I dont even understand why this is coming up here.
< gmaxwell>
Roughly the same code is in QT4. so it should be fine too.
< jonasschnelli>
Unrelated to the offscreen bug, yes.
< jonasschnelli>
Switching to Qt5 would allow to remove legacy code and use Qt5 features like lambdas, etc.
< jonasschnelli>
Simpler signal bindings
< gmaxwell>
Well, on all my machines Qt4 is the only version installed I think. I think it's still the default even in debian testing (though QT5 is available there).
< luke-jr>
oh :/
< luke-jr>
Now that you mention it, I do recall seeing Qt4 on Devuan
< gmaxwell>
I'm no expert and perhaps a fresh install would change some default. And maybe we could just address by providing more install instructions.
< achow101>
gmaxwell: perhaps you need a new laptop :p
< gmaxwell>
your inside jokes might confuse people. :P fwiw, on an up to date debian testing system, which was QT4 only, you can parallel install QT5, but it seems bitcoin-qt still builds using QT4 even with QT5 'installed'.
< meshcollider>
hmmm it seems that its working, but if you move it right to the very very edge of the screen you literally cant see it, you can grab it again with the mouse but theres no way you'd be able to find it again lol
< meshcollider>
that'd be a rare case though I'd imaging
< meshcollider>
s/imaging/imagine/
< achow101>
meshcollider: that's exactly the case that gmaxwell and I were testing earlier
< achow101>
and that case is kind of the worst case scenario, not off screen, but not on screen enough to be usable
< meshcollider>
mhm but if we rely on Qt restore and save, its not really fixable by us. I'd say its a non-issue if its exactly how other OS programs behave like notepad?
< meshcollider>
As long as its possible to get it back on screen with just the mouse, which it is, as long as you can find it lol
< gmaxwell>
bleh, I suppose. why do other things find that behavior tolerable.
< sipa>
there is some key shortcut to move a window
< cfields_>
ctrl+space gives you the min/max/move context-menu
< cfields_>
er, alt+space
< meshcollider>
yeah or you can shift+rightclick on the icon in the taskbar
< * cfields_>
just can't seem to leave his windows days behind him
< cfields_>
and fwiw, i only know that because programs would end up out-of-view now and then
< gmaxwell>
things really can get out of view and then save and restore it across restarts... how the heck have they not fixed that.
< meshcollider>
huh I figured out an even easier way to get it back on screen, windows key + arrow
< cfields_>
gmaxwell: well i haven't messed with it since xp, I assume they've made some progress :)
< midnightmagic>
meh. it's qt. they only fix stuff for corps that have an upper-tier support contract.
< cfields_>
midnightmagic: regardless of qt, the window manager is ultimately in charge of positioning
< cfields_>
which i assume was gmaxwell's point
< meshcollider>
^ use a tiling window manager and all your problems disappear ;)
< midnightmagic>
cfields_: no, memory of a window position is not something dwm does, and I use dwm-- "we" had issues with qt windows doing stupid things, fixing it was a pointless chore.
< midnightmagic>
xterm positioning for a new window is similar-- you pass in X geometry, and/or dwm guesses a top-left position for it, that's pretty much it
< midnightmagic>
eh, I might be misremembering. we had a lot of qt problems. a lot. lotta lot..
< bitcoin-git>
bitcoin/master cdaf3a1 Matt Corallo: Fix Qt 0.14.2->0.15.0 segfault if "total at least" is selected...
< bitcoin-git>
bitcoin/master 09627b1 Wladimir J. van der Laan: Merge #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt)...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) (master...2017/09/qsettings_1) https://github.com/bitcoin/bitcoin/pull/11332
< wumpus>
meshcollider: "mhm but if we rely on Qt restore and save, its not really fixable by us" <- well, as we never managed t oget it right in years of trying, please don't be angry at me for thinking maybe the qt devs know more about handling this and can do this better? :)
< meshcollider>
wumpus: yeah im not saying we should do it, I'm just saying its their problem now :)
< wumpus>
we can try this, give it one try, if it's flaky as well, I'd say we remove the functionality
< meshcollider>
their restore and save function have a lot more benefits than ours anyway, like the maximisation issue I mentioned in my PR
< wumpus>
it's not worth spending too much cycles on
< wumpus>
but I'd bet quite a lot that their function received significantly more testing than us
< wumpus>
ours*
< wumpus>
I don't understand why this triggers yet another qt 4 discussion though, the function has existed for about forever
< wumpus>
or is there some subtlety there?
< promag>
what does the "n" prefix means in nRPCConsoleWindow ?
< wumpus>
"number" I guess
< wumpus>
all of the qt settings have weird names, AFAIK it's based on satoshi's naming scheme for settings when they were still in the wallet
< wumpus>
anyhow it doesn't really matter what the names are, as long as the names are unique within bitcoin-qt
< wumpus>
for new settings I'd say use a plainer scheme
< meshcollider>
its a perfect time to change the nRPCConsoleWindow and nWindow ones if you want to because theyre both new to this PR
< meshcollider>
nRPCConsoleWindowGeometry and nWindowGeometry
< wumpus>
but I don't care, no one is supposed to see them
< wumpus>
right
< promag>
yeah, I would rename since they hold a different value/type
< promag>
the suffix "Geometry" sounds enough
< wumpus>
yes, it's enough
< meshcollider>
so just get rid of the 'n' at the front?
< meshcollider>
RPCConsoleWindowGeometry and WindowGeometry ?
< wumpus>
sounds good to me
< wumpus>
maybe MainWindowGeometry
< promag>
was going to say the same
< meshcollider>
sweet done 👍
< promag>
so the old settings will stay?
< meshcollider>
the old settings weren't called Geometry anyway, they saved position and size seperately in nWindowPos and nWindowSize
< meshcollider>
But yeah those Pos and Size will stay in there unused
< wumpus>
adding upgrade handling code just to remove them sounds like overkill
< promag>
and for some reason the user can keep 2 versions installed
< wumpus>
right, or some sinister altcoin that uses the same settings directory :-)
< bitcoin-git>
[bitcoin] laanwj opened pull request #11338: qt: Backup former GUI settings on `-resetguisettings` (master...2017_10_backup_resetguisettings) https://github.com/bitcoin/bitcoin/pull/11338
< meshcollider>
Are there any other goals for 0.15.1 other than the segwit wallet support sipa is working on?
< supay>
i was wondering if it would be possible to create a contact system where individuals grant access to another individuals contact information on top of the blockchain
< supay>
i believe a peer-to-peer ledger recording the level of access granted or revoked could enable an open social graph
< supay>
once there is a clean method to grant and update contact information across users, there is also now a social graph with information tiering, allowing a user-controlled and defined connection level between individuals.
< aj>
wumpus: hey, now 0.15 is out, should i ping back about #10996 (network.conf) ? we were worrying about qt/bitcoind initialisation diverging and generally making that stuff harder to understand, and potentially tests and such
< achow101>
promag: no, that's required to make that row grayed out if checkBoxMinimumFee is checked
< achow101>
I think
< wumpus>
yes the proper fix needs more review, which is why we went with the minimal fix that avoids the crash in 0.15.0.1
< wumpus>
* [new tag] v0.15.0.1 -> v0.15.0.1
< promag>
wumpus: do you think Copy/BackupSettings should be in src/qt/guiutil.cpp since they are "general function"
< wumpus>
not as long as they're only used in one place IMO
< wumpus>
guiutil is a grab-bag for common shared stuff
< wumpus>
if something is used in only one compilation unit, better to have it static and local
< wumpus>
can always be moved later
< wumpus>
let's not try to overdesign this anyhow
< wumpus>
another case of both choices being valid, it doesn't really matter
< meshcollider>
sipa: why didn't you choose a 2 character HRP for bech32 regtest addresses if testnet and mainnet are both 2 characters? 'rb' or something?
< wumpus>
probably because he didn't want to 'burn' a 2 character code on regtest, which is only meant for local testing
< wumpus>
unlike testnet3 and mainnet it's not an 'official' network
< morcos>
achow101: while you're playing around in the QT code, i think we want to eliminate the checkbox for "Pay only the required fee ..."
< morcos>
maybe separate PR in case we want to back port 11334
< achow101>
why?
< morcos>
sorry, why what?
< achow101>
morcos: why remove that checkbox? It just means that you will be paying the minrelayfee
< achow101>
(although the wording on it probably needs to be changed)
< morcos>
achow101: because you can just select the minrelayfee in the custom box if you want to pay that
< morcos>
it doesn't seem like selecting it as a stand alone option really sends the right message
< achow101>
morcos: the user may not know what the minrelayfee is
< achow101>
also, doesn't it change if the mempool is full?
< morcos>
that number does not change
< morcos>
but regardless of getting rid of that checkbox
< morcos>
i am realizing that it's a bit annoying that you don't know what the minimum is you need to put on your transaction if you are selecting current fee
< morcos>
perhaps we want to output a : minimum to currently be accepted in the mempool fee
< morcos>
but i would suggest people be forced to type that into the box
< morcos>
making it too easy to select that implies it could could be a good idea
< morcos>
unless you're seeing that returned in fee estimation
< morcos>
it's proably not a good idea
< achow101>
we could change it to update the custom fee box with the fee rate that it would be using
< morcos>
not sure i follow
< morcos>
it uses the fee rate you give it
< morcos>
if you're using custom fee (as opposed to recommended)
< morcos>
even if such fee would not get you accepted to the mempool
< achow101>
I meant that if you check the box to use minrelayfee, it can display the fee rate that it is using in the custom fee rate box right above it
< morcos>
i just don't think we should give users an option to use the minimum
< morcos>
it has very limited benefit... the options should be.. recommended (for a given target) or you specify
< morcos>
we discussed in SF, and i thought there was other agreement with this idea
< achow101>
I'm afraid that if someone wants to use the minimum that they will accidentally enter 1 sat/kB (not 1000 sat/kB) in the box if they don't have the option to use the minimum
< morcos>
well, in that case it'll be changed to 1000 for them
< achow101>
although I suppose that can be fixed by lower bounding the box to the minrelayfee
< morcos>
it already lower bounds.. but it doesn't really tell you it's going to
< morcos>
in any case, i suppose there are a lot of options for how to improve this area... so maybe its not critical right now
< gmaxwell>
you could also put 0 in the custom box and get clamped to min relay fee. no
< gmaxwell>
oh nevermind
< luke-jr>
another reason I thought of, that people might want to keep it: this way you can check the min fee checkbox, while retaining the current saved value for the manual fee
< luke-jr>
but that use case might be better served by allowing users to define pre-set values
< morcos>
gmaxwell: yes that does work
< gmaxwell>
the nevermind was because on the line before mine you pointe dthat out. :)
< morcos>
i'm not sure of the QT mojo to do this easily, but seems like the best outcome might be to replace the checkbox with a display of what the mempool min fee is, and have a way to click that and have it populated into the custom box
< morcos>
then we're missing informing people of what the min relay fee is in case they actually wanted to do a tx that wouldn't yet be accepted into the mempool, but that seems pretty advanced, and maybe people will know that if they want to do it
< morcos>
submitting these super low fee txs does have the use case for manually managed rbf bumping
< warren>
Yikes. I had been using my wallet as a symbolic link for years now.
< sipa>
i wasn't even aware that could work...
< warren>
It worked just fine.
< luke-jr>
it shouldn't..?
< warren>
It worked for me for years. #10885 sounds like it got more complicated with the possibility of the same wallet being opened multiple times after multi wallet was added
< warren>
was there concern about single wallet being broken with a symlink? that worked for me for years
< luke-jr>
warren: the concern is situations like your own: it doesn't work in a way that is useful
< gmaxwell>
wallets being on different media than the /database directory will result in corruption.
< luke-jr>
warren: wallet.dat being on an encrypted fs doesn't provide you any security
< * BlueMatt>
also got someone on IRC asking why the PPA broke his wallet-symlink
< BlueMatt>
I was like "oh, please dont do that...I mean will usually work, but if your system crashes, you may get fucked"
< warren>
OK, maybe I was lucky to never run into problems.
< BlueMatt>
well we have a loop that compacts wallet like every 100ms, and (usually) if you crash post-compact pre-writing-new-stuff you're ok, but bdb makes no guarantees there, and certainly you can get screwed if you miss the time window there
< luke-jr>
and I'd expect the wallet data to be written to the unencrypted database/ dir before getting into wallet.dat
< BlueMatt>
i believe it does, yes
< BlueMatt>
or the .log file
< gmaxwell>
everything written to wallet.dat first goes through the database/ dir. IIRC
< delinquentme>
running bitcoind w the option --assumevalid=<blah> but Im not seeing an update in the "verificationprogress" ... If i've given it a block that is only hours old ... shouldnt that verification shoot up?
< gmaxwell>
Nope.
< gmaxwell>
assume valid means skipping script processing, it doesn't (and cannot) avoid having to process blocks.
< gmaxwell>
also, setting an assumevalid right now won't do much, as the default is a fairly recent.
< delinquentme>
so if I've got a low compute node that I want this on, my best option for speeding up the verification is side loading it?
< gmaxwell>
delinquentme: yes, or just be patient, if your system is fast enough to keep up it will catch up.
< BlueMatt>
also -dbcache
< gmaxwell>
BlueMatt: I didn't suggest that because most cpu starved things don't have ram.
< BlueMatt>
ah, well sure, just saying crank it if possible
< delinquentme>
yeah I've got that specd at 8 gigs on the machine doing the sideloading
< delinquentme>
I've got a total of 16 ... any reason I shouldn't make it 12g?
< sipa>
it won't use that much
< sipa>
i believe it maxes out at around dbcache=6000
< gmaxwell>
you can make the logs have microsecond precision too.
< achow101>
StopAndDecrypt_: Look at the debug.log file and check the timestamps for when you start the sync and when IsInitialBlockDownload is finished
< StopAndDecrypt_>
makes sense, just curious if that info would be useful.
< bitcoin-git>
[bitcoin] jnewbery opened pull request #11345: [tests] Check connectivity before sending in assumevalid.py (master...assume_valid_improvement) https://github.com/bitcoin/bitcoin/pull/11345
< BlueMatt>
jonasschnelli: do you believe the latest qt only fixed the offscreen issue, or did you also intend to imply that it also fixed the setSortingEnabled thing?
< jonasschnelli>
BlueMatt: I don't think setSortingEnabled is fixed in newer Qt versions