< bitcoin-git> [bitcoin] OrfanMiner opened pull request #11325: Corrected year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11325
< bitcoin-git> [bitcoin] fanquake closed pull request #11325: Corrected year (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11325
< mryandao> heya, while running bitcoind in docker, i tried to symlink debug.log to /dev/stderr and bitcoind crashed when a boost function tried to read the path, is that expected behaviour?
< NicolasDorier> Running bitcoin-core-0.15.0/test.rc3 on one of my server, getting "2017-09-14 06:55:48 socket send error The operation completed successfully. (0)" in logs _without_ debug=net. Then the connection drop to the peer. My peer is a NBitcoin peer, and I could not reproduce the error on the same 0.15.0/test.rc3 running on my machine.
< NicolasDorier> "socket send error The operation completed successfully. (0)", interesting message at least...
< promag> Can I have some feedback here #11316?
< gribble> https://github.com/bitcoin/bitcoin/issues/11316 | [qt] Add use available balance in send coins dialog by promag · Pull Request #11316 · bitcoin/bitcoin · GitHub
< NicolasDorier> mmh I doubt the bug comes from bitcoin core actually
< bitcoin-git> [bitcoin] MeshCollider opened pull request #11326: Fix crash on shutdown with invalid wallet (master...201709_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11326
< meshcollider> thats such a small fix it doesn't even feel right to make a whole PR lol
< earlz> How exactly do you debug the bitcoin-qt on 64bit windows? I know the gitian builds produce both the binaries and debug symbols, but not sure what the best way to debug a crash is
< wumpus> earlz: the debug symbols can be used in combination with the stack trace and a memory map to find out what symbol was involved. I don't know of any way to do debugging *on* windows sanely, there's a mingw gdb but I don't think it works very well
< promag> wdyt return txid in signrawtransaction? (at least if complete)
< promag> there is this pattern decoderaw(signraw().hex).txid
< promag> could be simplified to signraw().txid
< wumpus> could be, though I always run decoderaw after signraw anyhow, to check the transaction one last time before broadcasting it
< wumpus> so it wouldn't help me at least - but if you think many would be helped by having txid on signrawtransaction output object why not open a PR
< wumpus> also, sendrawtransaction(hex) returns the txid - so you really need the txid before broadcasting the transaction?
< wumpus> or is this useful if you use an alternative way to broadcast transactions
< promag> there is no need to decoderawtransaction
< wumpus> indeed, it could take the result from sendrawtransaction instead
< wumpus> this way of working makes sense though if it's testing decoderawtransaction
< promag> don't think so, if it's testing decoderawtransaction then it's incomplete
< wumpus> in any case, I don't think we should fix test inconsistencies by changing the API :)
< promag> no, that's why I asked before opening the PR
< promag> but having the txid back and forward doesn't sound too bad
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/7fcd61b2613c...f4ed44ab4a8f
< bitcoin-git> bitcoin/master dd36561 Evan Klitzke: Add a lint check for trailing whitespace....
< bitcoin-git> bitcoin/master 1f379b1 MeshCollider: Add tab char lint check and exclude imported dependencies
< bitcoin-git> bitcoin/master f4ed44a MarcoFalke: Merge #11300: Tests: Add a lint check for trailing whitespace...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11300: Tests: Add a lint check for trailing whitespace (master...201709_whitespace_lint) https://github.com/bitcoin/bitcoin/pull/11300
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/86700d3d056caf54b091a6673dd6dabb65fac1f2
< bitcoin-git> bitcoin/master 86700d3 Wladimir J. van der Laan: doc: add release-notes for 0.15.0 to master...
< bitcoin-git> [bitcoin] laanwj closed pull request #11280: [0.15] Final to-do's for 0.15.0 release notes (0.15...201709_release_note_015_todo) https://github.com/bitcoin/bitcoin/pull/11280
< NicolasDorier> using 0.15rc3
< NicolasDorier> my node can't even start again after restarting it
< NicolasDorier> it is doing that every time it starts
< wumpus> afaik that one (if it's during init) is fixed on master
< NicolasDorier> yep during init
< NicolasDorier> cool
< NicolasDorier> thanks I try that now
< wumpus> doesn't affect the release executables as they're not built with DEBUG_LOCKORDER
< wumpus> (and it's not an actual possible deadlock - will be backported to 0.15.1 though)
< NicolasDorier> wumpus: no luck, this is unrelated to this PR
< wumpus> ok
< NicolasDorier> this is indeed not a real deadlock though
< NicolasDorier> will just deactivate debug for now and find out what happen
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/7c53587101eaf206a6a6a11a9398d43f139eadcf
< bitcoin-git> bitcoin/0.15 7c53587 Wladimir J. van der Laan: doc: Clean out release notes on 0.15 branch...
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/96d91b79bdfe1c0a58bd645f0f1d657caba16deb
< bitcoin-git> bitcoin/master 96d91b7 Wladimir J. van der Laan: contrib: Ignore historical release notes for whitespace check...
< NicolasDorier> how to remove DEBUG_LOCKORDER ? I tried to compile withount --enable-debug, but no luck it see;s
< NicolasDorier> meh I must have screwed up somewhere... will redeploy
< wumpus> it's --enable-debug that adds it, so rebuilding without it (you'd need to 'make clean' too) will get rid of it
< NicolasDorier> yeah sorry, I messed up by replacing the wrong bitcoind on my server :/
< NicolasDorier> so actually I did not tried https://github.com/bitcoin/bitcoin/pull/11126 yet. But the path of the locks is different from the PR so I guess this is different error.
< NicolasDorier> filed an issue
< MarcoFalke> 15000 commits. This thing explodes 🎉
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/96d91b79bdfe...0f399a9ff227
< bitcoin-git> bitcoin/master 77939f2 MeshCollider: Fix uninitialized g_connman crash in Shutdown()
< bitcoin-git> bitcoin/master 0f399a9 MarcoFalke: Merge #11326: Fix crash on shutdown with invalid wallet...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #11326: Fix crash on shutdown with invalid wallet (master...201709_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11326
< bitcoin-git> [bitcoin] danra opened pull request #11328: Move comment about transaction/block weight calculation (master...fix/weight-comment) https://github.com/bitcoin/bitcoin/pull/11328
< bitcoin-git> [bitcoin] jnewbery closed pull request #10044: [tests] [build] Run functional tests in `make check` (master...reorg_makefiles) https://github.com/bitcoin/bitcoin/pull/10044
< mryandao> has anyone here using tmux experience extreme lag when they `git clone` the bitcoin repo for the first time?
< wumpus> never noticed - though i guess git does a lot of terminal updates during the progress update so maybe that is slowed by running in tmux?
< wumpus> MarcoFalke: heh yes also noticed, 15000, wow that's a milestone in itself I guess
< mryandao> it was particularly bad after i did a git pull on my fork that was 1000+ commits behind.
< mryandao> i had to remove the whole repo and clone with depth=1
< wumpus> well better to run git outside tmux then?
< wumpus> at least initial clones
< wumpus> if you think cloning bitcoin is bad, try cloning the linux kernel
< mryandao> heh
< mryandao> ah actually, it might be tmux-airline that was tracking the 1000+ commit that's pending
< wumpus> ok
< luke-jr> wumpus: mryandao: interesting, usually GNU Screen (similar to tmux) reduces screen update lag O.o
< bitcoin-git> [bitcoin] mess110 opened pull request #11329: [test] Test abortrescan command (master...kallewoof/test-abort-rescan-2) https://github.com/bitcoin/bitcoin/pull/11329
< wumpus> interesting, it probably does some update coalescing on the background. I've personally never noticed tmux making things slower, but I don't have any fancy plugins iether
< luke-jr> right
< bitcoin-git> [bitcoin] danra opened pull request #11330: Trivial: Fix comments for DEFAULT_WHITELIST[FORCE]RELAY (master...patch-10) https://github.com/bitcoin/bitcoin/pull/11330
< achow101> if anyone sees any issue remotely like #11171, please get the GUI settings (from windows registry or from ~/.config/Bitcoin/Bitcoin-Qt.conf) before doing -resetguisettings
< gribble> https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
< achow101> I would like to see what the gui settings are before they are reset as that should give a clue as to how that crash is happening
< wumpus> yes that would be very useful to know
< wumpus> will you ask in the issue too?
< achow101> yep, asked
< achow101> I didn't realize someone else was experiencing the same problem. otherwise I would have asked them for their gui settings earlier, but they already reset them
< gmaxwell> Has anyone encountered this on Linux?
< achow101> gmaxwell: I don't think so
< ryanofsky> BlueMatt got a report from someone yesterday using linux
< wumpus> so from achow101's analysis it looks like something to do with the proxy configuration? that could be the case ,proxy can be set from the gui settings
< BlueMatt> yea, someone complaining that 0.15 on the ppa was busted
< BlueMatt> his response to me claimed he assumed it was proxy
< BlueMatt> i asked for more details but havent heard back yet (to try to confirm it if possible)
< achow101> I think it has to do with the proxy setting although I couldn't think of a proxy string that would replicate the problem
< wumpus> if that is true, though, it should be possible to trigger it from the command line too, as the proxy simply gets passed in in a similar way
< wumpus> yes exactly then it will be some string that crashes it
< wumpus> apparently starting with 0.15 branch
< achow101> well I tried a lot of weird strings and couldn't get anything to crash it :/
< achow101> I got it to crash after it all loaded and I tried to modify the settings though. There's an open issue for that
< wumpus> I don't remember if there were any proxy handling changes for 0.15
< gmaxwell> thats it's a crash limits the number of possibiltty.
< gmaxwell> er possibilities.
< gmaxwell> Merge #9774: Enable host lookups for -proxy and -onion parameters
< gribble> https://github.com/bitcoin/bitcoin/issues/9774 | Enable host lookups for -proxy and -onion parameters by jmcorgan · Pull Request #9774 · bitcoin/bitcoin · GitHub
< gmaxwell> looks like it was in 0.15
< wumpus> yes, that one would certainly be a possibility
< bitcoin-git> [bitcoin] jnewbery closed pull request #10748: [config] Help text cleanup (master...helptextcleanup) https://github.com/bitcoin/bitcoin/pull/10748
< wumpus> I don't see how though
< wumpus> if it's something in paymentserver crashing, it's not the lookup itself that crashes it, but something in the transfer of the proxy address to a qt structure
< gmaxwell> well for example, I wonder if Lookup would crash with a e.g. 0xff input. otherwise I don't see how the lookup change could be it
< gmaxwell> (or maybe a truncated multibyte character)
< wumpus> it happens after the argument parsing though
< wumpus> in the log in 11171 it's even handling peers already
< gmaxwell> the obvious way to try to repro is to get these things set in the registry, then edit the registry manually to set the keys to empty strings.
< achow101> gmaxwell: been there done that. A lot of invalid things are caught that makes it fail to start entirely (throws initerror)
< wumpus> yes, it help so much to have an example of a failing config
< harrymm> i got matt's ppa to my ubuntu 17.04 system when it was available. i had the gui crash you're talking about and got it working with -resetguisettings.
< harrymm> i still have the processed core dump if that helps ya.
< gmaxwell> you have a core dump!
< achow101> harding: it would be better to have your gui config
< harrymm> it actually said the seg was SIGSEGV at QAbstractButton:setChecked(bool) from libQtGui.so.4.
< gmaxwell> achow101: not harding, harrymm
< bitcoin-git> [bitcoin] danra opened pull request #11331: Trivial: Update outdated comment in validation.h (master...patch-11) https://github.com/bitcoin/bitcoin/pull/11331
< achow101> oops
< harrymm> yep. i'm not sure how to analyse it. it's a whoopsie thing.
< harrymm> gdb doesn't do the job. sorry i'm not too skillful at this :)
< harrymm> it was produced when i allowed it to send the bug info to launchpad trackers (I thought)
< BlueMatt> harrymm: I mean what settings do you recall having? custom datadir, encrypted wallet, selected different buttons for fees in the send tab.....?
< BlueMatt> minimize to tray?
< harrymm> yes to all of those iirc
< harrymm> i had a backup i made during this process but cleaned it out today when the thing finally worked. :(
< gmaxwell> harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< harrymm> i'll have a shot...
< harrymm> no. that gives me the same result i got before. it doesn't recognize the apport/whoopsie processed file
< gmaxwell> okay I don't know what that does it it.
< wumpus> it's possible to extract a gdb core dump from the processed file, don't remember the steps though
< harrymm> i couldn't find out how to load it locally either. but the file info was sent off to a bug tracker at the time (severl times in fact). launchpad should have it.
< harrymm> tho. this file is 100MB. i'm sure not that much was in the bug report :)
< wumpus> apport-unpack apparently https://wiki.ubuntu.com/Apport#I.27m_a_developer._How_do_I_use_these_crash_reports.3F
< wumpus> yes, these are steps for examining it locally, not sure what parts are uploaded
< BlueMatt> i see no bugs anywhere...no idea what reporting it did
< BlueMatt> unless you're the "john" who emailed previously
< harrymm> not me. tho i did see a comment with this same fault. someone suggested a new report be opened but afaik it was not done.
< BlueMatt> a comment? where?
< harrymm> that was in github iirc
< BlueMatt> ohoh, yea, github
< BlueMatt> i dont know what blackhole the launchpad reports went into
< harrymm> i tried to find it too .. failed
< harrymm> so shall i try to unpack this thing?
< BlueMatt> yes, please
< harrymm> k. i didn't have much luck with apport options yesterday but i didn't try this particular one.
< wumpus> yes, the core dump inside it can hopefully give us a useful backtrace
< harrymm> wow. that worked and it was quick. i now have a whole bunch of separate files
< harrymm> the segvanalysis file says: Segfault happened at: 0x7fd6466e033d <_ZN15QAbstractButton10setCheckedEb+13>: mov 0x8(%rdi),%rbx
< harrymm> PC (0x7fd6466e033d) ok
< harrymm> source "0x8(%rdi)" (0x00000008) not located in a known VMA region (needed readable region)!
< harrymm> destination "%rbx" ok
< wumpus> can you pastebin the output of: <gmaxwell> harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< harrymm> segvreason: reading NULL VMA
< harrymm> i can't make gdb process this thing
< wumpus> I guess something called setChecked on a NULL pointer
< wumpus> there should be a corefile between those unpacked files, that works with gdb in that way
< harrymm> oh. wait..
< harrymm> haha. i missed that CoreDump file. Ok. I've got gdb opened.
< wumpus> these are all uses of setChecked in the code base: https://0bin.net/paste/CMyf3KukY-4bWwpS#MpZG+6rLJIl-1gwTfsKUe4baTOHnCmPDtVpJcLMpos2
< BlueMatt> wumpus: where do you think my list of possible settings in use came from :p
< harrymm> how do i get a file out containg the backtrace?
< BlueMatt> just copy/paste the output of the above command into a site like 0bin or pastebin
< harrymm> no symbols of course, but i can prolly get it up to pastebin
< wumpus> to make gdb log, "set logging file <filename>" "set logging on"
< BlueMatt> or that
< wumpus> no symbols in the ppa?
< wumpus> we don't have separate debug info for that one either :/
< BlueMatt> you can get symbols from ppa
< BlueMatt> but you have to manually download that
< BlueMatt> sec
< BlueMatt> what ubuntu version?
< harrymm> 17.04
< harrymm> i got a log file. i'll wait to see oif i can get symbols tho
< BlueMatt> i assume you ended up with 0.15.0-zesty6
< harrymm> sounds right.
< harrymm> not sure about that 6 but iirc it was :)
< BlueMatt> i dont actually know how to turn that into debugsyms in gdb, but I believe dpkg -i will let you install the ddeb file
< BlueMatt> harrymm: I think it might magic....if you download the ddeb file there, dpkg -i it (or otherwise install it like a normal package) and then re-open gdb, it may know to search usr/lib/debug
< harrymm> double-click worked. lol. gdb is showing symbols now.
< achow101> harrymm: got the gdb output yet?
< harrymm> but it frustratingly seems to not have the symbols dammit. it loaded them ok ...
< harrymm> aww. should i have told gdb to load symbols from the symbols downloaded? it says it's reading them from bitcoin-qt (which doesn't have them)
< achow101> harrymm: I believe so. I don't remember the gdb commands/params for that though
< harrymm> i see a -s <file> but dunno what file i got
< harrymm> i apologize for my naivety :)
< BlueMatt> your file is /usr/lib/debug/usr/bin/bitcoind
< harrymm> ahh
< harrymm> wait. bitcoind or bitcoin-qt?
< BlueMatt> oh, no, bitcoin-qt, sorry
< BlueMatt> oh, wait, lol wrong file
< BlueMatt> sec
< harrymm> ok
< BlueMatt> yea, obviously you want the -qt dbgsym ddeb instead
< gmaxwell> 30 seconds till meeting.
< harrymm> lol. i see it now too.
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Sep 14 19:00:07 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< sipa> present
< instagibbs> hi
< gmaxwell> sipa: you're late
< jonasschnelli> Hy
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
< cfields_> hi
< sipa> short topic: congrats for 0.15.0!
< Chris_Stewart_5> yay!
< cfields_> woohoo
< wumpus> congrats and thanks everyone
< instagibbs> \o/
< jonasschnelli> !
< harrymm> :)
< wumpus> #topic high priority for review
< instagibbs> beatings will continue until 0.15.1 is out the door
< wumpus> we managed to merge quite a lot during the coredev meet, so there's some place for new things in https://github.com/bitcoin/bitcoin/projects/8
< wumpus> so any suggestions?
< achow101> hi
< * BlueMatt> is keeping hi
< BlueMatt> s
< * sipa> also
< BlueMatt> sipa: you dont have one
< wumpus> anything for 0.15.1 maybe?
< sipa> #11167 then
< gribble> https://github.com/bitcoin/bitcoin/issues/11167 | Full BIP173 (Bech32) support by sipa · Pull Request #11167 · bitcoin/bitcoin · GitHub
< instagibbs> #11089
< gribble> https://github.com/bitcoin/bitcoin/issues/11089 | Enable various p2sh-p2wpkh functionality by luke-jr · Pull Request #11089 · bitcoin/bitcoin · GitHub
< wumpus> added 11167
< BlueMatt> where are we on 0.15.1?
< cfields_> i have a pretty long stream of stuff to prep for libevent, but i don't want to burn everyone out by nagging too much. would you all prefer a few prs, all of which build on each-other, and a final one that incorporates everything?
< sipa> i'll work on the segwit-by-default stuff for 0.15.1
< wumpus> added 11089
< cfields_> (#10663 is the first of those. It's by no means high priority, other than it's necessary for the rest)
< wumpus> cfields_: that depends; if some part stands on itself, it might make sense to PR it first then give it as a blocker
< gribble> https://github.com/bitcoin/bitcoin/issues/10663 | net: split resolve out of connect by theuni · Pull Request #10663 · bitcoin/bitcoin · GitHub
< wumpus> that says enough, added 10663
< jonasschnelli> cfields_ I Prefer a single one to get the overall pictures
< cfields_> wumpus: thanks
< wumpus> but if it's a single one there's just so damn much to review
< instagibbs> jonasschnelli, or all of them, chained, with backpointers to first one to review
< gmaxwell> this gui crash issues should be considered a 0.15.1 blocker, but we still aren't sure of the precise cause.
< BlueMatt> jonasschnelli: sure, but you cant merge that...opening one which will be final eventually and then breaking it into chunks is also ok
< wumpus> gmaxwell: agree
< BlueMatt> gmaxwell: yup :(
< cfields_> jonasschnelli: ok, i can break them up into nice chunks, and have a tracking PR with them all rebased on top of eachother
< gmaxwell> considering the flood of reports I am really no longer able to believe we didn't recently introduce it.
< cfields_> i think that's pretty common these days
< wumpus> cfields_: sounds good to me
< gmaxwell> (maybe via a dep upgrade)
< michagogo> o/
< jonasschnelli> one for conceptual overview and multiple for real merge
< wumpus> gmaxwell: agreed
< cfields_> gmaxwell: possible that other clients are dinking with config files?
< jonasschnelli> (sorry phone typping)
< gmaxwell> that was a theory I had too but have seen no evidence of it.
< gmaxwell> harrymm: have you run bitcoin unlimited or bitcoin cash or likewise on that system you crashed on?
< morcos> Wouldn't we see 0.14 reports in that case
< wumpus> we really need a config or regtest dump from someone that has the issue
< BlueMatt> harrymm: how are those -qt debug symbols coming?
< wumpus> before they run -resetguisettings
< wumpus> in retrospect we should have made resetguisettings dump the settings to a backup file
< jonasschnelli> cfields_ : perfect
< cfields_> gmaxwell: iirc we didn't bump qt for 0.15. so deps seem unlikely
< achow101> wumpus: we should start doing that now
< wumpus> I mean you only run it when something is wrong
< wumpus> achow101: yes
< wumpus> #action Make -resetguisettings dump settings to troubleshooting file in datadir
< gmaxwell> cfields_: well I'm not completely sure that the issue is 0.15.x specific based on report load it could have been, say, 0.14.2 too ... and just a lot of people are upgrading.
< sipa> "oh, it's faster, i'll try running a full node again"
< cfields_> gmaxwell: what's the OS diversity?
< wumpus> but it was *never* reported for 0.14.x
< sipa> wumpus: fair point...
< wumpus> it would explain more reports, sure
< gmaxwell> we have a linux report now. so far mostly windows reports.
< achow101> gmaxwell: I suspect that's because more people use windows than linux
< gmaxwell> I don't think we've had a mac report. maybe there are just no mac users. :P
< cfields_> ah damn, i was thinking it could be a windows update
< sipa> did we update qt in between 0.14.2 and 0.15.0?
< harrymm> gmaxwell: not those you mentioned. i did try some other bitcoin python stuff at various times tho
< cfields_> hmm. I can run on osx and plug/unplug monitors like a madman.
< gmaxwell> harrymm: thanks.
< achow101> cfields_: it's not a monitor problem
< gmaxwell> So thats counter evidence to the theory that bch or bu is corrupting it.
< wumpus> the monitor problem just disappears the window
< wumpus> I think this is unrelated
< achow101> This is definitely unrelated
< cfields_> ok
< jonasschnelli> is that still the offscreen issue?
< gmaxwell> There may be two issues fixed with the same thing or two manifestiations of the same issue.
< harrymm> BlueMatt: i got the right symbols down and loaded into gdb, but there's still many symbols i don't have. i was checking if the relevant ones were there but not sure i have the right skills anyway so i will pastebin what i have
< achow101> jonasschnelli: it's the #11171 issue
< gribble> https://github.com/bitcoin/bitcoin/issues/11171 | RC2 Exits After Initialization · Issue #11171 · bitcoin/bitcoin · GitHub
< achow101> which is not an offscreen issue although we initially thought it was
< jonasschnelli> again: GUI: TransactionTablePriv::refreshWallet
< wumpus> jonasschnelli: was that the same problem?
< * BlueMatt> gets the impression there are at least 2 distinct issues here (+ the offscreen one which is not a segfault, right?)
< wumpus> jonasschnelli: I don'tremember that one was fixed by clearing gui settings
< wumpus> the offscreen issue is not a segfault, ever
< jonasschnelli> no... not possible IMO
< jonasschnelli> 11171 seems totally unrelated to the offscreen issue
< wumpus> the refreshWallet crash was intermittent, very hard to reproduce
< * BlueMatt> also doesnt believe this exists on 0.14.2...so far 2 reports from ppa folks, and they tend to be a rather well-upgraded bunch
< wumpus> this one is 100% reproducible
< wumpus> unless you clear the settings
< jonasschnelli> Okay. I'll track down 11171
< BlueMatt> harrymm: yea, pastebin what you have would be great
< achow101> jonasschnelli: that's what we're doing now with harrymm :)
< jonasschnelli> xyzzy099 == harrymm?
< gmaxwell> BlueMatt: offscreen gets the same report from users though: window doesn't appear, resetting the gui settings fixes it.
< jonasschnelli> gmaxwell: I have tracked this down and it's no longer present in 0.15
< achow101> jonasschnelli: no, different people, same symptoms, possibly same problem
< jonasschnelli> (official builds)
< jonasschnelli> It may happen if you self compile with <Qt5.6
< achow101> (symptoms being crash after splash screen)
< wumpus> yes the offscreen one has unclear status on the release binaries, jonasschnelli's testing points at it being fixed
< BlueMatt> jonasschnelli: which issue is that?
< BlueMatt> ah, offscreen
< achow101> wumpus: I believe the offscreen issue should be fixed in 0.15
< wumpus> achow101: yes
< BlueMatt> it'd be nice to fix the qt5 issues so that ppa can upgrade to it instead of being stuck on qt4......
< jonasschnelli> It's fixed in 0.15.0 (I have tested with Win7,8.1/10)
< wumpus> BlueMatt: just wait for unity to die
< gmaxwell> jonasschnelli: how does <Qt5.6 come into it?
< wumpus> wasn't the most serious qt5 problem on ubuntu the tray icon thing? no such issue on GNOME
< jonasschnelli> gmaxwell: I'm not sure if Qt is related. I could not find if the bug was fixed upstream (I think we had a Qt depdendency upgrade from 0.14 to 0.15) or if its fixed in out sources.
< BlueMatt> wumpus: heh, I mean there was discussion of killing the tray icon
< BlueMatt> wumpus: yes, I believe the tray icon was ~the only blocker
< gmaxwell> jonasschnelli: the problem is that we've had users reporting all through the rcs something that sounds like that, and now in releases. So just saying its fixed isn't helpful, since there is clearly something that isn't fixed.
< wumpus> anyhow that's yet another different issue
< BlueMatt> wumpus: there was some minimize issue that was also there, but I believe it was related...just kill the tray icon and its fixed, I think
< achow101> gmaxwell: jonasschnelli: I think you're talking about different issues
< jonasschnelli> gmaxwell: IMO its an upstream bug.
< harrymm> BlueMatt: best backtrace I have: https://pastebin.com/ZEZUhEDW
< wumpus> it's almost as if we have a lot of GUI issues and not many people working on the GUI :)
< sipa> jonasschnelli: i don't understand
< sipa> jonasschnelli: is it fixed, or is it an upstream bug?
< wumpus> both - upstream bug that is fixed
< jonasschnelli> the offscreen issue was present in our official 0.14.x bninaries while it's gone in our 0.15.0 binary
< gmaxwell> or "is it fixed" or "can't reproduce"?
< sipa> we're not talking about the offscreen issue...
< wumpus> let's discuss one issue at a time
< jonasschnelli> sipa: it is fixed,.. very likely in an upstream fix (could not track down the commit)
< wumpus> this is getting crazy
< sipa> jonasschnelli: then why are we getting reports?
< gmaxwell> jonasschnelli: what patch fixed it in 0.15?
< jonasschnelli> sipa: offscreen bug: could be because people compile with an Qt version below qt5.6?
< wumpus> we really need a test for the offscreen issue, right now we have *no* way to evaluate any fix
< wumpus> we could merge another PR that claims to fix it
< wumpus> but I'm kind of sick of that
< sipa> wait, i thought we were talking about the crash-at-startup issue?
< jonasschnelli> gmaxwell: I need to track it down. I just tested 0.14.1 and 0.15.0 on win7,8.1,10 and verfied that it is fixed in 0.15
< BlueMatt> ok, but lets be clear there are multiple bugs here
< achow101> BlueMatt: yay!
< jonasschnelli> sipa: sorry,... we slipped to the offscreen issue.
< sipa> okay, ignore me
< BlueMatt> the offscreen issue, which jonasschnelli believes to be fixed
< gmaxwell> jonasschnelli: what does verified that it's fixed in 0.15 mean? Does that just mean you were unable to reproduce it at all?
< BlueMatt> also the settings issue, which is L131 as above based on harrymm's backtrace
< wumpus> gmaxwell: yes, that means it
< jonasschnelli> gmaxwell: I set the window position by RegEdit to 3000,3000, 0.14 has the issue, 0.15 doens't
< achow101> BlueMatt: I don't see how there's a bug there
< wumpus> jonasschnelli: thanks for doing a sane, reproducible test :)
< jonasschnelli> 11171 is far more important
< gmaxwell> jonasschnelli: okay, but if the issue users are hitting is that the use positions the window in the bottom left of the screen (below task bar) then they'd still be hitting it... since the reproduction was synthetic.
< wumpus> I agree
< wumpus> crash bugs are more important, and this happens for a lot more users
< gmaxwell> I know that at least one of the users I helped during the RCs wasn't crashing (Because they had to kill bitcoin-qt in their task manager)
< jtimon> oops, I'm late
< jonasschnelli> gmaxwell: I can investigate again and report
< jtimon> yay 0.15!
< sipa> gmaxwell: sure, but there's only so much we can do
< gmaxwell> sipa: we could stop saving the position.
< wumpus> yes, ideally we should test all 8 areas outside the screen, something for an automated test
< wumpus> or just nuke the remember-position functionality
< jonasschnelli> my observation is that Qt handles offscreen situation pretty well... if a certain area of the window is offscreen, it re-centers.
< wumpus> the longer this remains an issue the more I'm tempted to the latter
< sipa> does -resetguisettings change anything but the remembered window coordinates?
< gmaxwell> jonasschnelli: QT5 but perhaps not QT4? (which, for example, the ppa uses, I believe)
< wumpus> sipa: yes, it clears all settings set through the gui optioins dialog
< jonasschnelli> It may kill your dbcache / proxy settings
< sipa> oh!
< jonasschnelli> Oh. PPA / QT4
< achow101> Oh, I think I found harrymm's bug
< jonasschnelli> Yes. The issue is very likely present there...
< wumpus> as well as all other things the GUI remembers (there might be something in the send dialog with fee, I vaguely remember)
< gmaxwell> sipa: you missed earlier discussion, based on debuglog traffic achow has suggested its actually the proxy that is implicated in the crash.,
< jonasschnelli> I don't see a reason to do the PPA with Qt4?
< BlueMatt> achow101: yea, there's only one button in that group
< gmaxwell> sipa: I pointed out that 0.15 did change proxy handling (name lookup) but a cause of a crash isn't obvious there.
< sipa> gmaxwell: ah
< achow101> BlueMatt: I mean how different settings for nCustomFeeRadio cause a segfault
< jonasschnelli> Maybe we just add a failsafe: if offscreen then re-center... (but sounds simpler then it is)
< gmaxwell> the user in here with the crash on linux knows the function where the segfault happens for him (inside a qt button setting function)
< wumpus> achow101: interesting, so it might be the custom fee setting?
< BlueMatt> achow101: yes
< wumpus> achow101: I forgot about that one completely as it's not in the options dialog
< BlueMatt> wumpus: it appears to be a what-button-had-you-clicked-on-in-14.2 issue
< achow101> wumpus: yes
< achow101> I set nCustomFeeRadio=1 and that causes a segfault
< gmaxwell> oh we also changed the options for fees at some point in recent memory, could people have settings that made sense in 0.14 but not now?
< wumpus> gmaxwell: ouch
< sipa> achow101: nice catch
< gmaxwell> sounds like it.
< BlueMatt> we deleted a button
< jonasschnelli> could it happend by https://github.com/bitcoin/bitcoin/pull/10769?
< BlueMatt> there is only one button in that group
< gmaxwell> consistent with the segfault location that harrymm reported too
< BlueMatt> so it obviously segfaults
< morcos> well that was a productive first half of the meeting
< wumpus> so nCustomFeeRadio should be removed completely? or are there other settitngs?
< harrymm> good work :)
< gmaxwell> 0.15.1 next week? :P
< wumpus> debugging an issue during the meeting is kinda cool
< jonasschnelli> heh...
< sipa> bughunting-by-committee
< dgenr8> my money was on sinister alt clients
< gmaxwell> oh had nothing to do with sinister, just incompatible.
< sipa> where everyone forgets it's really achow101 who found it
< wumpus> sinister alt clients could have more custom fee settings, we should be robust against corrupt configuration in any case :)
< gmaxwell> thats the advantages of committess, one guy does all the work and everyone gets the credit!
< achow101> lol
< wumpus> haha good old USSR-style
< achow101> I found a way to reliably reproduce it
< gmaxwell> committees*
< achow101> which is the ncustomefeeradio thing, but I'm not sure what to do going forward
< sipa> achow101: i'm pretty sure that's the root cause
< wumpus> so how do we solve it?
< sipa> do we have to figure that out now?
< sipa> if there are no other topics, why not, i guess
< gmaxwell> achow101 will figure it out. our work here is done.
< wumpus> no, not really, I just wonder what is the use of a radio button with one option
< jonasschnelli> I'll can tackle the groupCustomFee segfault today
< wumpus> anyhow, any other topics?
< gmaxwell> wumpus: so you have the freedom to choose the Correct option, of course.
< instagibbs> any color car as long as it is black
< wumpus> gmaxwell: lol!
< gmaxwell> time to ford ahead.
< BlueMatt> ok, fix is easy, I'll get it fixed right after meeting
< achow101> jonasschnelli: great!
< wumpus> anything to discuss for 0.15.1?
< sipa> if there's nothing else; i have some open questions about segwit-by-default support in 0.15.1
< wumpus> #topic segwit-by-default support in 0.15.1
< BlueMatt> oh, wait, hmm
< sipa> my idea was to have a cmdline option to select a default address style, which could be p2pkh, p2sh-p2wpkh, or p2wpkh
< BlueMatt> or jonasschnelli can do it
< sipa> (where the middle one is default)
< sipa> and have an optional argument to getnewaddress to override it
< BlueMatt> sipa: seems reasonable?
< sipa> open question: separate option for change?
< instagibbs> imo yes
< BlueMatt> imo yes
< achow101> sipa: yes
< sipa> open question: do we want to return both p2wpkh and p2sh-p2wpkh (for now), as there is an efficiency gain when you want to give both to a peer
< sipa> downside: may not want we want to support longer term with split chains
< achow101> no, I think that will confuse people
< sipa> upside: more efficient to rescan
< instagibbs> I'd say no
< jonasschnelli> may confuse
< instagibbs> users who care will crank the option surely
< gmaxwell> we can't do that by default, interface breaking change. If you want to call getnewaddress with style=gangnam and it returns both, that would be fine.
< achow101> style=gangnam <-- lol
< morcos> yep, i tested, running 0.14, setting the at least button, 0.15 crashes
< sipa> but style=gangnam would be pre-deprecated, and scheduled for removal in a future version
< morcos> oops was backlogged
< achow101> morcos: good to know that
< wumpus> hahahahaa
< BlueMatt> achow101: morcos also tested the 6ba2...fix from above, which fixed it, though the real fix isnt something that stupidly hacky
< sipa> ok, end of my topic
< cfields_> let's just let users decide with a 1-option combo-box :p
< gmaxwell> I'd say we could make the GUI show both too, except the URI/qr code can't really do that.
< cfields_> er, radio
< sipa> cfields_: unary encoding, i like it
< morcos> wait, i'm confused
< morcos> are you serious about giving both addresses
< morcos> no, why would we do that
< BlueMatt> lets not do that
< BlueMatt> you could also just call getnewaddress twice
< BlueMatt> who cares
< gmaxwell> morcos: as an option. The reason is so you can say "here is the bech32 one if you can pay to it, otherwise use X"
< morcos> you should have a way of selecting which type of address you want for change or for getnewaddress
< morcos> then give them 2 different keys
< morcos> that's how it'll work in 0.16
< morcos> lets not try to be cheap and save a couple of keys and start teaching people that you can use one or the other
< sipa> BlueMatt: my wallet.dat barely fits on a 3.5" floppy disk anymore...
< cfields_> morcos: +1
< instagibbs> will there be an argument to getnewaddress to override?
< instagibbs> id hope so
< morcos> i agree that's a downside, but its more important to set the precedent that these thigns are NOT interoperable
< morcos> yes
< sipa> instagibbs: i hope so, yes
< instagibbs> ok, then that's fine
< gmaxwell> okay... when I talked to sipa about it my objection was that we couldn't support it in the future. his counter was that we don't have to offer it in the future.
< instagibbs> i prefer
< BlueMatt> somehow I doubt bdb is useable on floppy-latency disks anyway :p
< gmaxwell> instagibbs: yes, there would be an option, setting would just set the default.
< instagibbs> then I see no reason to return both
< wumpus> yes,we need to make it very clear they're not interoperable, that you can't, in general just convert the one to the othe and have it work
< BlueMatt> then require two getnewaddress calls
< sipa> sounds good, you need to call getnewaddress twice
< sipa> ack
< achow101> +1
< sipa> no gangnam
< morcos> also in the scheme of things, each 0.15.1 wallet is wasting 2000 + N * (# getnewaddress calls) + (# changes) keys.... where N is 2 if you do what I want (only in the cases where you give out both) or 1 if you do what you want
< morcos> it makes no difference relatively speaking for almost all users
< jtimon> wumpus: ack on removing remember position functionality until we can test it automatically
< gmaxwell> jtimon has the gribble disease.
< wumpus> jtimon: that'd make sense, I guess
< gmaxwell> (20 minutes behind. :) )
< wumpus> seems the segwit-by-default topic is conclded, anything else?
< gmaxwell> I think we need to announce a workaround for this issue we all collectively figured out through our joint effort where no one person did all the work during the meeting.
< wumpus> haha yes gribble's behavior seemed very curious and random, before I realized it was just backlogged (or rather, github was?)
< BlueMatt> yes, do we have a mechanism for release errata?
< wumpus> or make a
< BlueMatt> given the ppa is still not up (cause arm qt...) I'll probably ship that with the hacky workaround patch posted above
< BlueMatt> unless there are objections
< wumpus> did you manage to debug the ARM qt issue? I'm curious
< wumpus> no objections, if you can patch it in your distro, do so
< wumpus> it's zero risk...
< BlueMatt> there appear to now be at least two separate issues, a miscompile, and I now have a stacktrace for another test_bitcoin-qt fail that I'm looking at now
< achow101> BlueMatt: I believe (not tested yet) that you can just remove L131 entirely
< sipa> let's fix the things at least in the 0.15 branch
< gmaxwell> I won't ack because I do none of the required work for it but it might be nice.
< sipa> then depending on progress we can see whether it goes in 0.15.1, or if a may be needed (at release manager's discretion...)
< wumpus> achow101: possibly, but BlueMatt's fix is obviosuly correct, a better fix is to just remove the setting completely
< BlueMatt> achow101: well the commit linked above works, so whatever
< wumpus> achow101: and the single-choice radio button
< gmaxwell> what sipa said
< wumpus> but for a quick hack that change is good
< morcos> in master can we please fix properly, remove the whole group
< wumpus> yes
< sipa> yes
< achow101> yes
< gmaxwell> yes
< gmaxwell> someone will need to contemplate how to prevent this kind of issue in the future.
< wumpus> well yes let's fix it on the branch then decide whether to do
< wumpus> better testing of the gui is the only answer
< achow101> gmaxwell: fuzz the qsettings options :)
< instagibbs> remove all features until qt is a single button
< jonasschnelli> Better GUI tests... but more important, "upgrade tests"
< gmaxwell> "moon"
< wumpus> hah
< jonasschnelli> Non of our test do cover upgrade of wallets, etc.
< gmaxwell> (responding to instagibbs)
< instagibbs> jonasschnelli, hmm good point
< jonasschnelli> Upgrade tests would probably require static data files from older versions....
< wumpus> well at least the reduced one radio buttons group to one button, that's a start...
< morcos> was fuzz qsettings a joke? i did that with the fee estimation changes manually, i think thats a good idea
< wumpus> s/the/we/
< achow101> morcos: not really
< wumpus> no, it's not a joke, it'd help with robustness against corrupt configs a lot
< morcos> ok, the smiley threw me
< wumpus> but as we're not even fuzzing bitcoin.conf settings yet
< achow101> but it would mean a lot more changes since weird shit in qsettings totally screws up qt
< morcos> ha ha, fuzzing bitcoin.conf DEFINITELY breaks things
< achow101> we would need better bad-setting rejection
< wumpus> gui testing is always at least 3 times as much work
< jtimon> sipa: yeah, both formats seems like un ugly optimization. Doesn't look like it's worth it
< gmaxwell> sipa: I think he's still 20min behind.
< jonasschnelli> Not sure if fuzzing qt-settings (QSettings) make sense. It's not a file edited by users
< morcos> is jtimon working on-site on the blockstream Mars project
< BlueMatt> jtimon: is stuck on moon
< jtimon> gmaxwell: well, I arrived 30 mins late
< jonasschnelli> Fuzzing peers.dat or similar would also make little sense I guess
< wumpus> jonasschnelli: but it can get corrupt, like anything
< wumpus> though I agree there's a limit
< instagibbs> that would at least test it handles corrupted files right
< instagibbs> recently ran into a case where we werent
< jonasschnelli> Corrupt files should be handled by Qt IMO
< morcos> usually with bitcoin.conf we don't change the meaning of the options (cough cough sipa)
< jonasschnelli> The file itself is hidden on our application layer
< jonasschnelli> We just deal with QSettings
< morcos> we could be better about making sure we rename options in QT if we are goign to change their meaning
< wumpus> yes
< wumpus> much, much better to lose the setting than crash
< jonasschnelli> morcos: yes!
< wumpus> unless it's soomething like the proxy
< wumpus> but a nicety like remembering the fee setting? nah
< jtimon> ? why not 15.0.1 directly and we stop writing the 0. prefix now? /me hides
< jonasschnelli> I don't understand why the crash does not happen on OSX (could only reproduce on Linux)
< wumpus> likely the implementation of radio button group is different there
< wumpus> making it return e.g. a dummy object instead of corruption or null when reading out of range
< wumpus> macosx users just got lucky
< sipa> wumpus: we have occasionally had x.x.x.1 released for bugfixes that affect just some platforms
< sipa> *releases
< instagibbs> 2 minutes
< morcos> one could argue they were silently forced to lose their at least setting which made them erroneously pay the wrong fees
< wumpus> sipa: yes, I wouldn't like to burn 0.15.1 on this mainly
< sipa> wumpus: agreed
< jtimon> finally catched up...to late to suggest a topic, but perhaps we can talk about it after the meeting
< jtimon> is about an index for scriptPubKeys
< wumpus> yes, we're done for today
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Sep 14 19:59:45 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101> ok bye. laptop is about to die
< wumpus> jtimon: you mean of the utxo set?
< jtimon> how acceptable would be to maintain a scriptPubKey -> [list of outpoints using it] index ?
< jtimon> wumpus: well, spent outputs could be removed from the index or not
< wumpus> nack on a global index, concept ack on such an index over the UTXO set, would make it so easy to query any balance
< jtimon> perhaps with an option, or perhaps it's only acceptable for the utxo
< sipa> yeah, please no indexes that require the full chain
< wumpus> exactly
< adiabat> address index over utxo would be fun, I'd enable & use that
< jonasschnelli> ui->groupCustomFee->button((int)std::max(0, std::min(1, settings.value("nCustomFeeRadio").toInt())))->setChecked(true); <--- pretty fragile
< jonasschnelli> button() can return a nullptr
< adiabat> probably not too huge either
< jtimon> well, my thought was give an option -deletespent or something of the short, if you start using the index, it starts with an utxo at a given height, if you select the option, it conserves spent outputs but won't go to the past: if you want it full you need to reorg
< jonasschnelli> calling setChecked() on a nullptr won't crash OSX but does segfault (correctly) on linux
< BlueMatt> jonasschnelli: uhhhhhhh
< BlueMatt> I hope not?
< jtimon> but perhaps that's not acceptable either, anyway, thanks wumpus sipa that's useful to know
< jonasschnelli> Yeah.. seems strage... maybe a local issue.. it should crash
< wumpus> does it really return null when out of range though on osx?
< wumpus> or some softly padded dummy object
< cfields_> jonasschnelli: huh, i just saw something related to that in a recent qt changelog
< cfields_> jonasschnelli: no clue if related. not as relevant as i was thinking: https://bugreports.qt.io/browse/QTBUG-59391
< jonasschnelli> cfields_: thanks... will check later (on the run)
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (master...2017/09/qsettings_1) https://github.com/bitcoin/bitcoin/pull/11332
< BlueMatt> jonasschnelli: I really dont think thats the right fix...groupCustomFee literally only contains one button now
< BlueMatt> jonasschnelli: better to just literally remove groupCustomFee and the button wholesale
< BlueMatt> as well as delete the nCustomFeeRadio setting
< gmaxwell> there are a half dozen places in the code where we ->button()->foo
< gmaxwell> fwiw
< achow101> Report of possibly same bug on osx: https://bitcointalk.org/index.php?topic=2132893.msg21842556#msg21842556 from droark
< jonasschnelli> BlueMatt: yes. Agree. I just created the minimal possble fix (for backports).
< BlueMatt> jonasschnelli: see my above patch which I think is maybe cleaner if we're looking at backports
< BlueMatt> s/maybe//
< BlueMatt> but whats the harm in fixing it right for 0.15.1?
< jonasschnelli> BlueMatt: sorry,... where is your patch?
< wumpus> bluematt's is the minimum possible - just make it always use button(0)
< jonasschnelli> BlueMatt: wumpus: okay. Makes more sense!... BlueMatt: do you pr?
< jonasschnelli> Or should I update my PR?
< sipa> minimal patch is "std::min(1, " -> "std::min(0, "
< sipa> :p
< jonasschnelli> heh
< wumpus> hah... yes, good point
< wumpus> that would have been the obvious correct fix too if the number of buttons was reduced to something else than 1
< BlueMatt> jonasschnelli: can we please just delete the buttons?
< BlueMatt> jonasschnelli: I see absolutely no harm in simply removing the group/button for 0.15.1
< achow101> I think removing the group is the right way to go here
< BlueMatt> (this is why i did not open my pr)
< wumpus> removing the whole group is a riskier change, though, it could potenitally introduce new issues
< wumpus> which is the right thing for master
< wumpus> but maybe not for or w/e
< BlueMatt> hmm, alright up to you
< BlueMatt> i can pr mine against 15 if you like
< jonasschnelli> BlueMatt: remove for 0.16 is okay... but for a backport?
< BlueMatt> i figured it was fine, but...up to y'all
< achow101> Removing it could be backported to 0.15.1. for, BlueMatt's hack should be fine
< BlueMatt> wait, are we doing an
< achow101> Are we?
< jonasschnelli> okay,... overhauled #11332
< gribble> https://github.com/bitcoin/bitcoin/issues/11332 | Fix possible crash with invalid nCustomFeeRadio in QSettings by jonasschnelli · Pull Request #11332 · bitcoin/bitcoin · GitHub
< jonasschnelli> BlueMatt: I'm trying to cherry-pick your https://github.com/bitcoin/bitcoin/commit/6ba2214e0fe57ecb9271819d2422ec44a9020a8d to keep you as author
< sipa> jonasschnelli: you can use git commit --author="..."
< sipa> if cherry picking is too hard, but you still want to retain author
< jonasschnelli> sipa: Oh... didn't knew you can.
< jonasschnelli> I guess the signature does not matter
< sipa> if you're cherry picking, the gpg signature is removed anyway
< sipa> (as it would be invalid)
< jonasschnelli> Oh. Right
< jonasschnelli> hash will change
< MarcoFalke> You can still sign the cherry-pick with your key, if you prefer that
< BlueMatt> heh, for that fix I dont really care
< BlueMatt> we all figured out the bug live during meeting anyway
< BlueMatt> group effort :)
< jonasschnelli> Okay. Retained authorship: https://github.com/bitcoin/bitcoin/pull/11332/commits
< achow101> I'm not sure if that solves 11171. The op tells me that he doesn't remember having that option set
< meshcollider> 11171 was a segfault in QTableView::setSortingEnabled
< meshcollider> This sounds unrelated to that?
< meshcollider> #11262 has 2 separate issues in it, one in the OP and one in the comments, I think they're different
< gribble> https://github.com/bitcoin/bitcoin/issues/11262 | bitcoin-qt segmentation fault · Issue #11262 · bitcoin/bitcoin · GitHub
< meshcollider> Or at least probably a separate issue to 9683 and 9883
< achow101> Meshcollder: I think you are talking about 11262
< achow101> Not 11171
< luke-jr> setSortingEnabled is a distraction: the crash is "free(): invalid next size (fast)" which indicates corrupt memory before it got there
< luke-jr> it could very well be 11332-related
< luke-jr> the only way to confirm is valgrind
< luke-jr> (on an affected system)
< jnewbery> jonasschnelli: (slightly delayed) you can also `get commit -C <hash>` if you want to retain the entire commit message including author - and there's no risk of mistyping the author's name
< jnewbery> s/get/git
< * luke-jr> learns uppercase -C skips the editor.
< achow101> Git has a lot of fun options that most people don't know about
< luke-jr> I'm probably the only one in the world who uses git write-tree <.<
< achow101> What's that?
< luke-jr> git-write-tree - Create a tree object from the current index
< luke-jr> typically followed by git commit-tree
< luke-jr> in my case, I do this sequence to produce commits with more than 2 parents
< ShaunR> Has anybody ever proposed making bitcoind's blocknotify and walletnotify options support a URL? So you could set -blocknotify="https://domain.com/bitcoind/notify/block.php" and have it POST %s? I'm thinking about attempting to write that functionallity into bitcoind but unsure if anyone else would find it useful or if the devs would even consider adding it.
< luke-jr> ShaunR: -blocknotify='curl https://domain.com/bitcoind/notify/block.php?hash=%s';
< luke-jr> probably a trivial way to make it POST too
< ShaunR> luke-jr: thats true, you could do something like that i guess.
< ShaunR> I was thinking about making it a bit more elaborate, like if the POST failed to queue the notification or something.
< luke-jr> could make blocknotify retry if the exit code is non-zero?
< ShaunR> but your solution may be the simplist right now.
< luke-jr> but tbh, retry logic could be outside too
< ShaunR> I wanted to avoid the requirement of a outside script/binary too
< esotericnonsense> yes, you could create an external script that queues notifications to do stuff with
< luke-jr> ShaunR: avoiding that requirement, is not a design goal IMO
< esotericnonsense> it'd probably be easier to use the zmq notification for that, just listen on it, add new entries to a queue, periodically try and flush the queue into this post mechanism
< luke-jr> ShaunR: better to run as little code in the security-critical process as possible
< esotericnonsense> indeed, it's not really bitcoind's responsibility
< luke-jr> esotericnonsense: ZMQ is good at losing notifications
< esotericnonsense> luke-jr: using IPC? tcp over seperate machines, perhaps
< esotericnonsense> regardless of whether you use zmq or not it's similarly easy though :)
< achow101> harrymm: do you have a debug.log file from the time of the crash?
< esotericnonsense> from #bitcoin: dingus | TYPO at the very top of https://bitcoin.org/en/release/v0.15.0 "14 October 2017" <- It's not October, yet, I hope
< luke-jr> ‎[21:11:33] ‎<‎dingus‎>‎ TYPO at the very top of https://bitcoin.org/en/release/v0.15.0 "14 October 2017" <- It's not October, yet, I hope
< luke-jr> yeah
< achow101> Lol
< kakobrekla> does `addwitnessaddress` work with watch-only addresses?
< sipa> yes
< kakobrekla> cool!
< sipa> kakobrekla: however, if it isn't, you can still use importaddress on the result
< sdaftuar> sipa: only if its solvable, right? isn't it possible to have a watch-only address that is not solvable?
< sipa> right
< BlueMatt> 11326 likely needs 0.15 backport, no?
< wbnns> @esotericnonsense @lukejr Submitted #1803 to fix the typo.
< gribble> https://github.com/bitcoin/bitcoin/issues/1803 | Apply MIT license to md2k7 art by luke-jr · Pull Request #1803 · bitcoin/bitcoin · GitHub
< esotericnonsense> actual url (wrong repo): https://github.com/bitcoin-dot-org/bitcoin.org/pull/1803
< wbnns> @esotericnonsense Thanks.
< esotericnonsense> you too :)
< wbnns> :)
< bitcoin-git> [bitcoin] danra opened pull request #11333: Use `std::nth_element` instead of `std::sort` to calculate median time past (master...improve/median-time-past) https://github.com/bitcoin/bitcoin/pull/11333
< tloriato> Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< sipa> you can't
< tloriato> So I have to derive each desired path using another lib and import it with WIF?
< sipa> for now, yes
< tloriato> thank you, sipa
< tloriato> oh, one more thing, sorry! bitcoin core uses m/0'/0'/k' for derivation path
< tloriato> is there a way I could request a new address from an arbitrary path from the rpc?
< tloriato> or at least associate one i ( m/0'/i'/k' ) for one account?
< sipa> no, new addresses come from the keypool, which is preloaded with keys from one chain
< sipa> in 0.15, there are two chains (one for normal addresses, one for change)
< sipa> and no, you can't configure the path - especially not for accounts, which are deprecated
< tloriato> Well, I think I have the information that I need now.
< tloriato> Thanks sipa, it was really helpful
< sipa> yw
< tloriato> sipa in which cases does the bitcoin wallet changes the i from the path?
< tloriato> ( for reference m/0'/i'/k' )
< sipa> i=0 for normal addresses, i=1 for change
< tloriato> oh, ok! thanks