< bitcoin-git> [bitcoin] JeremyRubin opened pull request #11523: [Refactor] CValidation State (master...dos-cleanup) https://github.com/bitcoin/bitcoin/pull/11523
< bitcoin-git> [bitcoin] tjps opened pull request #11524: [net] De-duplicate connection eviction logic (master...tjps_eviction) https://github.com/bitcoin/bitcoin/pull/11524
< darthJarjar> hi to all
< bitcoin-git> [bitcoin] pierreN opened pull request #11525: Utils and libraries: fix warning -Wsign-compare in ConsumeDecimalNumber (master...fix_sign_compare_lvldb_logging) https://github.com/bitcoin/bitcoin/pull/11525
< bitcoin-git> [bitcoin] fanquake closed pull request #11525: Utils and libraries: fix warning -Wsign-compare in ConsumeDecimalNumber (master...fix_sign_compare_lvldb_logging) https://github.com/bitcoin/bitcoin/pull/11525
< wallet42> Would it be a lot of change to have an -option so that when spending coins in the chainstate db instead of deleting the key, it will be renamed from c[txid][nout] to s[txid][nout] ? basically have it ever growing coins db?
< wallet42> it would ease some of my analysis tools
< bitcoin-git> [bitcoin] sipsorcery opened pull request #11526: Visual Studio build configuration for Bitcoin Core. (master...build_msvc) https://github.com/bitcoin/bitcoin/pull/11526
< bitcoin-git> [bitcoin] schildbach opened pull request #11527: Remove my testnet DNS seed as I currently don't have the capacity to … (master...remove-seed) https://github.com/bitcoin/bitcoin/pull/11527
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/02ac8c892b1f...b9e1299f048d
< bitcoin-git> bitcoin/master a86e81b Cory Fields: travis: move back to the minimal image...
< bitcoin-git> bitcoin/master 3d1c311 Cory Fields: Revert "travis: filter out pyenv"...
< bitcoin-git> bitcoin/master b9e1299 Wladimir J. van der Laan: Merge #11521: travis: move back to the minimal image...
< bitcoin-git> [bitcoin] laanwj closed pull request #11521: travis: move back to the minimal image (master...travis-minimal) https://github.com/bitcoin/bitcoin/pull/11521
< wumpus> cfields: ok, applied
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.15: https://github.com/bitcoin/bitcoin/compare/1646f9c76036...ca0f3f734c46
< bitcoin-git> bitcoin/0.15 b28415b Cory Fields: travis: move back to the minimal image...
< bitcoin-git> bitcoin/0.15 ca0f3f7 Cory Fields: Revert "travis: filter out pyenv"...
< wumpus> there are so many unmerged PRs tagged for 0.15.0.2, anything ready to merge?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b9e1299f048d...13f53b750dc0
< bitcoin-git> bitcoin/master 132d322 Andreas Schildbach: Remove my testnet DNS seed as I currently don't have the capacity to keep it up to date.
< bitcoin-git> bitcoin/master 13f53b7 Wladimir J. van der Laan: Merge #11527: Remove my testnet DNS seed as I currently don't have the capacity to …...
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/a2bd86a5ff1d75d85089e4ba6c908ece83451c5c
< bitcoin-git> bitcoin/0.15 a2bd86a Andreas Schildbach: Remove my testnet DNS seed as I currently don't have the capacity to keep it up to date....
< wumpus> #11476 seems to be ready
< gribble> https://github.com/bitcoin/bitcoin/issues/11476 | Avoid opening copied wallet databases simultaneously by ryanofsky · Pull Request #11476 · bitcoin/bitcoin · GitHub
< sipa> ack
< bitcoin-git> [bitcoin] sipsorcery opened pull request #11528: Minimal code changes to allow msvc compilation (master...code_msvc) https://github.com/bitcoin/bitcoin/pull/11528
< bitcoin-git> [bitcoin] promag opened pull request #11529: Avoid slow transaction search with txindex enabled (master...2017-10-txindex-get-transaction) https://github.com/bitcoin/bitcoin/pull/11529
< wumpus> huh didn't we already have that one
< promag> I can make it one line too, just one "return false;" if txindex
< promag> the thing is, there is no point in doing the slow search if txindex is enabled and doesn't have the given txid
< sipa> i prefer promag's approach slightly more
< promag> also, I would like to discuss what locks are required in each case
< promag> for instance, cs_main is not required to mempool.get right?
< promag> dunno about pblocktree
< sipa> pblocktree requires cs_main
< sipa> mempool has its own lock
< promag> and pcoinsTip?
< wumpus> I prefer the smaller change, especially as it already had so many utACKS, the rationale for re-doing it in another way now is unclear to me
< sipa> promag: cs_main
< wumpus> feel free to explain it though if there's cases that it covers and the other one doesn't, but the PR isn't very clear
< sipa> wumpus: there's no difference afaik - but it's cleaner that the dependency on txindex in localized in one place
< sipa> but really no strong opinion
< wumpus> I mean the change is more complex and more ways to mess it up
< wumpus> it adds so much code!
< sipa> oh, the change is much bigger than i expected - i just knew the concept
< promag> wumpus: do you prefer this:
< sipa> promag showed a much smaller change earlier
< wumpus> ow diffing with w=1 makes it better
< wumpus> still I don't see why so much logic needs to be changed for this
< sipa> still, what i saw earlier was 1 line
< sipa> but inside GetTransaction rather than in the caller
< promag> see last link
< wumpus> sounds good to me
< sipa> ^ that
< promag> done
< promag> although I think we can only lock cs_main after mempool lookup
< sipa> you can hold both
< sipa> but you need to grab main first, if you need both
< promag> really?
< sipa> yes
< sipa> there exists a lock order
< promag> ah got it, so the other commit was wrong
< sipa> which means that if there is one place in the code where A is being held while B is being taken, you can't have another place where A is being taken while B is held
< promag> ok
< sipa> the opposite is called lock order inversion, and is a risk for deadlocking
< sipa> -DDEBUG_LOCKORDER automatically detects lock order inversions
< promag> thanks for the explanation
< wumpus> is there something wrong with travis again or is everyone just submitting PRs that break it? :)
< Chris_Stewart_5> Is there numbers any where of how long it takes to validate/verify a block w/ 0.15.0
< wumpus> -debug=bench
< bitcoin-git> [bitcoin] laanwj closed pull request #11507: [RPC] Don't do slow transaction lookup when txindex is enabled (master...getrawtx-txindex) https://github.com/bitcoin/bitcoin/pull/11507
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/13f53b750dc0...99e93de6f8ab
< bitcoin-git> bitcoin/master 478a89c Russell Yanofsky: Avoid opening copied wallet databases simultaneously...
< bitcoin-git> bitcoin/master 99e93de Wladimir J. van der Laan: Merge #11476: Avoid opening copied wallet databases simultaneously...
< bitcoin-git> [bitcoin] laanwj closed pull request #11476: Avoid opening copied wallet databases simultaneously (master...pr/wid) https://github.com/bitcoin/bitcoin/pull/11476
< promag> in travis, what's the point in running functional tests if make check fails?
< cfields> heh, all 0.15.0.2 issues are pretty closely intertwined.
< cfields> #topicsuggestion ^^ :)
< wumpus> promag: the functional tests also don't work like that, if one test fails it continues with the rest. I guess it's useful to see exactly what tests fail.
< wumpus> if it stops at the first failed test you need to re-run time after time after fixing a single test
< ossifrage> That copy paste problem I reported earlier is an actual QT bug: "GUI: QXcbClipboard::setMimeData: Cannot set X11 selection owner"
< ossifrage> It seems to have been triggered by running a second instance of firefox as another user.
< ossifrage> It is possible that using the QClipboard wrapper instead of the QXcb* stuff will address some of these edge cases...
< wumpus> yea X has some interesting clipboard issues sometimes, especially combined with 'remote' windows, or with some software that tries to keep up to date with the clipboard and querying it all the time
< ossifrage> This one was a bit of a usability issue and I ended up having to use bitcoin-cli to copy and paste addresses without screwing up
< wumpus> I'm sure we don't use QXcb clipboard stuff directly in our code
< wumpus> it's possible to build bitcoin-qt w/ wayland, for example, and the clipboard works
< ossifrage> firefox, chrome, xfce-terminal where all un-effected, but gnome-terminal and bitcoin-qt where
< wumpus> xclip is a useful tool to probe around with X clipboards, did you know it actually has three of them?
< ossifrage> wumpus, the clipboard worked fine, I use it extensively with bitcoin-qt, until I launched a 'lazy sandboxed' firefox as another user
< ossifrage> wumpus, yeah I tried to use xclip to clear all 3 hoping that would magically reset whatever permissions it was confused about, with no love
< wumpus> lol it's such a mess
< ossifrage> Restarting gnome-terminal fixed the problem for it, but I didn't want to restart bitcoin-qt
< wumpus> but hey windows has to be better at something :)
< ossifrage> (I have some sort of uptime/connection count fetish)
< ossifrage> I used to run X stuff over ssh tunnels for years and never remember having a problem like this...
< wumpus> I've had more clipboard issues with X than I can even remember
< ossifrage> Weirdness yes, but complete failure to work, not so much...
< wumpus> it's most fun VNC or xpra and remote windows get involved, sometimes they get into a loop updating
< cfields> ossifrage: huh, very interesting. my Konsole copy/paste quit working yesterday.
< wumpus> or sometimes you suddenly get old clipboard contents back
< ossifrage> wumpus, yeah I've seen that before and I think clipboard managers make the problem even worse
< wumpus> and copy some password into something that aboslutely shouldn't have it
< wumpus> ossifrage: yup like the one that KDE comes with
< ossifrage> wumpus, I have a shell alias for clearing the clipboard after pasting a password :p
< wumpus> cfields: interesting, maybe it's some recent update that made it worse
< cfields> sounds reasonable
< cfields> I didn't investigate much because i use vim's yank for the most part. I just chalked it up to a Konsole bug.
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/99e93de6f8ab...ff92fbf24739
< bitcoin-git> bitcoin/master 7a5f930 João Barbosa: Avoid slow transaction search with txindex enabled
< bitcoin-git> bitcoin/master ff92fbf Wladimir J. van der Laan: Merge #11529: Avoid slow transaction search with txindex enabled...
< wumpus> heh if you use one of the -x11 variants of vim, yank will also copy to the X clipboard
< cfields> ah, neat
< bitcoin-git> [bitcoin] laanwj closed pull request #11529: Avoid slow transaction search with txindex enabled (master...2017-10-txindex-get-transaction) https://github.com/bitcoin/bitcoin/pull/11529
< wumpus> well at least the clipboard becomes one of the yank registers, not the default one
< cfields> dammit, I've squashed/force-pushed this pr like 5 times now, I keep missing little things I forgot to address. I hope that's not blowing up anybody's mailbox?
< wumpus> oh wait, even two of them, + and *, for two differnt clipboards, of course
< wumpus> cfields: well not mine at least
< cfields> k. wasn't sure if you could subscribe to new commits, even if they're just a rebase
< wumpus> thinking of it, I don't get mails for pushes at all, just for comments
< wumpus> not that I know of
< cfields> I got them for pushes at some point. Can't remember if i turned it off for being to spammy, or if Github disabled that
< cfields> *too spammy
< achow101> I definitely get emails for new commits
< wumpus> you can enable mails for pushes to your repository https://help.github.com/articles/choosing-the-types-of-notifications-you-receive/
< wumpus> achow101: but also for PRs you're subscribed to?
< MarcoFalke> I get for pushes, but not for force pushes
< achow101> but there's a delay between pushing a commit or making a comment and then getting the email. I think github is smart enough to not send out too many mails if you make multiple pushes within a minute or two of each other
< achow101> wumpus: this is for PRs
< wumpus> ok, strange, well I don't really mind not getting them, I already get way too much mail
< cfields> achow101: ok. for future reference, did you just get about 5 from me for 11512? Or it skipped them all because they were force-pushes?
< cfields> er, 11457
< achow101> cfields: I did not get any emails about those force pushes
< cfields> great, thanks
< ryanofsky> i think github doesn't send "pushed commits" messages for prs when the new commits have the same subject lines as the old commits
< cfields> ryanofsky: well about 3 of my force-pushes right now were squashing "temp" and "fixup" commits that I accidentally left in. So it apparently doesn't notify on new ones, at least
< cfields> or, maybe only after some delay like achow101 said
< wumpus> it probably only mails when a new commit (or more) was added on top of the last known one
< cfields> ah, that would make sense
< wumpus> meeting time?
< jonasschnelli> jup
< meshcollider> Hi
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Oct 19 19:00:32 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.
< achow101> hi
< 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> mildly present
< kanzure> hi.
< wumpus> primary topic I suppose is 0.15.0.2
< wumpus> anything that is close to merging, or that needs further discussion?
< cfields> BlueMatt: are you around to fill in some of the cb interactions with those PRs? They're hard to review because of subtleties I assume I'm not fully accounting for.
< achow101> I wasn't able to do as much as I wanted to this week because of exams. I'll fix up #11446 later today hopefully
< gribble> https://github.com/bitcoin/bitcoin/issues/11446 | Disconnect Peers for Duplicate Invalid blocks. by achow101 · Pull Request #11446 · bitcoin/bitcoin · GitHub
< BlueMatt> sdaftuar: (and somewhat I) worked out a replacement for #11487, that I need to rewrite and close the original
< gribble> https://github.com/bitcoin/bitcoin/issues/11487 | Check that new headers are not a descendant of an invalid block by TheBlueMatt · Pull Request #11487 · bitcoin/bitcoin · GitHub
< BlueMatt> so I'll do that a bit later
< wumpus> ok
< sdaftuar> i updated #11490 with some bug fixes and addressed feedback. i also added a unit test that passes locally but fails in travis :( workin gon it...
< gribble> https://github.com/bitcoin/bitcoin/issues/11490 | Disconnect from outbound peers with bad headers chains by sdaftuar · Pull Request #11490 · bitcoin/bitcoin · GitHub
< wumpus> great!
< wumpus> travis has been having some issues the last few days, be sure it's related to your pull and not some intermittent problem
< wumpus> any other topics?
< achow101> any updates on segwit wallet stuff?
< wumpus> I doubt anyone has been working on that w/ the .2 release rushed before
< sipa> i've been distracted the past week
< achow101> ok
< wumpus> will get back to that when sanity has returned
< jnewbery> topic suggestion: Chaincode Residency (sorry for the shameless plug)
< sipa> next week i'll have more time (i'm in europe until the end of the month)
< wumpus> #topic Chaincode Residency
< jnewbery> Thanks!
< jnewbery> We're hosting another residency program in Jan/Feb 2018: http://hackerresidency.com/ https://medium.com/@ChaincodeLabs/chaincode-residency-2018-26cd8a65d5f7
< jnewbery> If you know anyone who might be suitable, please refer them to the website
< jnewbery> end topic
< wumpus> ok!
< cfields> woohoo! We'll be expecting at least 1 new jnewbery and 1 new ryanofsky.
< jnewbery> 1 jnewbery is quite enough
< wumpus> hehe
< jonasschnelli> ;-.)
< sipa> jnewbery: how do you know? have you ever met one?
< cfields> heh
< wumpus> doppelganger
< wumpus> okay, anyone else have anything to discuss?
< jnewbery> sipa: I've been informed that 1 is at the upper range of most people's tolerance
< meshcollider> Hmm might be good to briefly discuss what the plan is for #7729 and #11497
< gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11497 | Hide accounts system behind deprecation switch by achow101 · Pull Request #11497 · bitcoin/bitcoin · GitHub
< wumpus> well as long as they keep the great patches coming :)
< wumpus> needs to be rebased and merged :p
< achow101> meshcollider: I'm thinking they should probably be done simultaneously. 11947 should probably be part of 7729
< jonasschnelli> Plans to rebase 7729 or waiting until someone picks it up?
< wumpus> sorry, yes, I really need to push it the last bit
< jnewbery> I'm not convinced on the approach for 11497 (using -deprecatedprc)
< jonasschnelli> wumpus: thanks!
< wumpus> jnewbery: what is your concern with it?
< jnewbery> Seems to me that the account/label switch is conceptually on the level of the wallet, not on the level of the node
< sipa> today again a user on SE who was confused about accounts
< jonasschnelli> lables / account are completely on the wallet level... yes.
< wumpus> yes, they're at the wallet level, I agree
< jnewbery> I don't think 11497 addresses the problem of migrating from an account system to a label system, although I may not have fully understood what the plan is
< achow101> yeah, I agree with that. 11497 was really just done in a fit of anger after I got too fed up with handling account things
< wumpus> though from the perspective of the database there's no difference, accounts and labels use the same underlying strucures
< meshcollider> Agreed but there were concerns bumping the wallet version because of HD wallets right
< sipa> meshcollider: has nothing to do with accounts
< wumpus> it doesn't need a new wallet version
< jnewbery> meshcollider: yes. Is now a good time to raise the topic of feature flags on wallets?
< meshcollider> Oh I thought that was discussed in 7729
< wumpus> accounts do not introduce any new wallet features , at least this first incarnation simply does what the GUI does
< achow101> meshcollider: it's the same database structures, so that shouldn't matter
< meshcollider> Yeah I thought 7729 comments were discussing using the version number as a flag for the label/account switch
< wumpus> people are requesting things like allowing multiple labels for one address, which would need extensions to functionality, but the current one is simply what is already done by the GUI
< jonasschnelli> (another topic, but): we can bump the wallet version because all new wallets now must be HD, right?
< wumpus> seems unnecessary
< sipa> i think using -deprecatedrpc is fine for accounts - it's literally just removing some functionality
< wumpus> sipa: yeah, it removes functionaltiy from the RPC interface
< sipa> but we may first need to add label-based RPCs
< wumpus> it's an RPC interface thing
< wumpus> sipa: yes, 7729 needs to go in first
< sipa> okay
< wumpus> then the flag can select between the old account based interface and the new label based one
< wumpus> at least for 0.16, in 0.17 I suppose the old interface will simply go away
< achow101> maybe we should use a different flag than -deprecatedrpc
< meshcollider> So yeah jnewbery topic suggestion of wallet feature flags?
< wumpus> this won't lose compatiblity with old wallets
< wumpus> it just will lose access to any account info in them
< sipa> right, it's not a wallet feature
< wumpus> so it's not really a wallet versioning thing
< jonasschnelli> meshcollider: no flags required for the label/account switch (only changes on functional level)
< sipa> it's a sofrware feature that can be turned on or off
< jnewbery> ok, so it sounds like it's not necessary for accounts/labels. I'll go back and look at 7729 again.
< * achow101> is confused now
< wumpus> #action implement and merge the label api finally
< wumpus> ok, next topic?
< sipa> achow101: the big idea is that all accounts functionality remains under the name "label", except the concept of an acount balance
< achow101> sipa: so it is a node thing and not wallet based?
< sipa> achow101: wut?
< sipa> achow101: no, it's an RPC thing
< sipa> the wallet or node are unaffected
< wumpus> right
< achow101> s/node thing/rpc thing/
< sipa> right
< jonasschnelli> the wallet structure is unaffected although the wallet code is
< sipa> is it?
< jonasschnelli> if we consider rpcwallet as wallet code
< sipa> i wouldn't expect it to (until it is deleted entirely)
< wumpus> some small changes are necessary
< sipa> ok
< sipa> anyway, details
< sipa> i'm going off soo
< jonasschnelli> meshcollider: in case you want to work on wallet flags (there is already a closed PR) #8369
< wumpus> there's some functionaltiy that would be in the label API but the GUI doesn't use at the moment, from what I remember, but anyhow yeah it's minimal
< gribble> https://github.com/bitcoin/bitcoin/issues/8369 | [FOR LATER USE][WIP][Wallet] add support for a flexible "set of features" by jonasschnelli · Pull Request #8369 · bitcoin/bitcoin · GitHub
< jnewbery> Last comment from wumpus in 7729 included "Either label or account RPCs could be usable based on the wallet version." I think we probably need to look at that PR again to refresh our memories (I certainly do)
< meshcollider> jonasschnelli: Oh right, I'll have a look
< sipa> okay
< wumpus> jnewbery: what a dumb comment!
< wumpus> going to remove it immediately :-)
< jnewbery> I think it was in response to me, more as a 'this is how it could possibly work'
< sipa> pffft, fact based analysis, how boring
< meshcollider> Yeah that comments probably what I was thinking of
< wumpus> back then I probably thought using the wallet version was a useful way of doing that flagging, but I reconsider
< achow101> well now we have -deprecatedrpc
< sipa> right
< wumpus> yes
< sipa> no more topics?
< wumpus> nope
< sipa> #halfameeting
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Oct 19 19:31:27 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< achow101> review/merge beg on #11415 #10583 #10579 (rpc split things for removing #ifdef enable wallet)
< gribble> https://github.com/bitcoin/bitcoin/issues/11415 | [RPC] Disallow using addresses in createmultisig by achow101 · Pull Request #11415 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10583 | [RPC] Split part of validateaddress into getaddressinfo by achow101 · Pull Request #10583 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/10579 | [RPC] Split signrawtransaction into wallet and non-wallet RPC command by achow101 · Pull Request #10579 · bitcoin/bitcoin · GitHub
< wumpus> or alternatively, everyone should be reviewing 0.15.0.2 PRs
< achow101> that too
< wumpus> we have kind of a strict deadline there
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #11530: Add share/rpcuser to dist. source code archive (master...Mf1710-distShare) https://github.com/bitcoin/bitcoin/pull/11530
< earlz> In GetTime(), it uses time(NULL)'s result directly. The returned value doesn't appear to be standard guaranteed to be UTC/unix time though. Shouldn't GetTime use gmtime or something similar to correct ofr this?
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11531: Check that new headers are not a descendant of an invalid block (more effeciently) (master...2017-10-cache-invalid-indexes) https://github.com/bitcoin/bitcoin/pull/11531
< meshcollider> That should be added to 0.15.0.2 milestone ^
< Alkhara> Anyone local to the Boston area?