< fanquake> meshcollider: can you look at #17889 when available
< gribble> https://github.com/bitcoin/bitcoin/issues/17889 | wallet: Improve CWallet:MarkDestinationsDirty by promag . Pull Request #17889 . bitcoin/bitcoin . GitHub
< meshcollider> Yep :)
< fanquake> ?
< promag> meshcollider: i can fix the typo
< meshcollider> alright I'll wait :)
< meshcollider> thanks!
< bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/95ca6aeec7b8...7fb94c0ed418
< bitcoin-git> bitcoin/master 2b16414 Joao Barbosa: wallet: Improve CWallet:MarkDestinationsDirty
< bitcoin-git> bitcoin/master 7fb94c0 Samuel Dobson: Merge #17889: wallet: Improve CWallet:MarkDestinationsDirty
< bitcoin-git> [bitcoin] meshcollider merged pull request #17889: wallet: Improve CWallet:MarkDestinationsDirty (master...2020-01-wallettx-iscacheempty) https://github.com/bitcoin/bitcoin/pull/17889
< meshcollider> ah sorry achow101, another rebase on the boxes :'(
< meshcollider> its one of my priorities this week to try and get that in though
< promag> meshcollider: I believe a rebase was already necessary, https://github.com/bitcoin/bitcoin/pull/17261/commits/b92575c5a838709e00f90d49bc377e68b5683e9a is already in master :/
< achow101> how'd that commit sneak in? I guess my last rebase got screwed up somewhere
< achow101> meshcollider: rebased it. hurry up and merge it please :)
< bitcoin-git> [bitcoin] Empact opened pull request #17945: doc: Fix doxygen errors (master...2020-01-wdocumentation) https://github.com/bitcoin/bitcoin/pull/17945
< luke-jr> ugh, GBT is broken in 0.19?
< * luke-jr> facepalms putting such a bug in release notes rather than just fixing it
< aj> luke-jr: ?
< luke-jr> aj: "rules" with csv & segwit is absolutely needed
< luke-jr> without it, miners have no way to know what rules are being used and might produce invalid blocks
< luke-jr> the BIP is perfectly clear :/
< luke-jr> aj: I don't think I saw it
< aj> yeah, you replied on that first thread, but doesn't look like you looked in any detail
< bitcoin-git> [bitcoin] luke-jr opened pull request #17946: Fix GBT: Restore "!segwit" and "csv" to "rules" key (master...fix_gbt_buried) https://github.com/bitcoin/bitcoin/pull/17946
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7fb94c0ed418...2ddf041a8d5e
< bitcoin-git> bitcoin/master 22c5a98 Peter Bushnell: depends: Consistent use of package variable
< bitcoin-git> bitcoin/master 2ddf041 fanquake: Merge #17928: depends: Consistent use of package variable
< bitcoin-git> [bitcoin] fanquake merged pull request #17928: depends: Consistent use of package variable (master...patch-4) https://github.com/bitcoin/bitcoin/pull/17928
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2ddf041a8d5e...c20fbb7be864
< bitcoin-git> bitcoin/master c279a81 Joao Barbosa: gui: Remove warning "unused variable 'wallet_model'"
< bitcoin-git> bitcoin/master c20fbb7 fanquake: Merge #17939: gui: Remove warning "unused variable 'wallet_model'"
< bitcoin-git> [bitcoin] fanquake merged pull request #17939: gui: Remove warning "unused variable 'wallet_model'" (master...2020/01/disable-wallet-unused-variable) https://github.com/bitcoin/bitcoin/pull/17939
< bitcoin-git> [bitcoin] theStack opened pull request #17947: test: add unit test for non-standard txs with too large tx size (master...20200116-test-check-for-non-standard-txs-with-too-large-tx-size) https://github.com/bitcoin/bitcoin/pull/17947
< bitcoin-git> [bitcoin] fanquake closed pull request #17570: test: add unit test for non-standard txs w/ too large tx size (master...test_unit_IsStandardTx_tx-size) https://github.com/bitcoin/bitcoin/pull/17570
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c20fbb7be864...0deba680646f
< bitcoin-git> bitcoin/master 7d0a8f4 Hennadii Stepanov: refactor: Remove never used default parameter
< bitcoin-git> bitcoin/master 1a53b0d Hennadii Stepanov: refactor: Simplify connection syntax
< bitcoin-git> bitcoin/master 0deba68 fanquake: Merge #17943: qt, refactor: Remove never used default parameter
< bitcoin-git> [bitcoin] fanquake merged pull request #17943: qt, refactor: Remove never used default parameter (master...20200116-message-parameter) https://github.com/bitcoin/bitcoin/pull/17943
< bitcoin-git> [bitcoin] fanquake opened pull request #17948: build: pass -fno-ident to prevent compilers emitting ident directives (master...pass_fno_ident) https://github.com/bitcoin/bitcoin/pull/17948
< bitcoin-git> [bitcoin] emilengler opened pull request #17949: doc: Remove double space in README_windows.txt (master...2020-01-remove-double-space-in-readme-win) https://github.com/bitcoin/bitcoin/pull/17949
< bitcoin-git> [bitcoin] emilengler closed pull request #17949: doc: Remove double space in README_windows.txt (master...2020-01-remove-double-space-in-readme-win) https://github.com/bitcoin/bitcoin/pull/17949
< bitcoin-git> [bitcoin] emilengler opened pull request #17950: gui: Check the strength of an encryption password (master...2020-01-password-strength-checker) https://github.com/bitcoin/bitcoin/pull/17950
< bitcoin-git> [bitcoin] sdaftuar opened pull request #17951: Use rolling bloom filter of recent block txs for AlreadyHave() check (master...2020-01-improve-alreadyhave) https://github.com/bitcoin/bitcoin/pull/17951
< bitcoin-git> [bitcoin] elichai opened pull request #17953: refactor: Abstract boost::variant out (master...2020-01-variant) https://github.com/bitcoin/bitcoin/pull/17953
< elichai2> What's the easiest way to locally reproduce weird configuration failures on travis? (ie run CentOS and/or the TSan case) MarcoFalke
< meshcollider> #startmeeting
< lightningbot> Meeting started Fri Jan 17 19:00:26 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< meshcollider> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball
< kanzure> hi
< jnewbery> hi
< meshcollider> Welcome to the first wallet meeting for 2020 :)
< jonatack> hi
< sipa> hi
< achow101> hi
< wumpus> hi
< meshcollider> Does anyone have topic proposals? I'd like to quickly just have a discussion about wallet goals for the longer term since are are getting close to merging #17261
< gribble> https://github.com/bitcoin/bitcoin/issues/17261 | Make ScriptPubKeyMan an actual interface and the wallet to have multiple by achow101 . Pull Request #17261 . bitcoin/bitcoin . GitHub
< meshcollider> So wallet boxes are really a shorter term goal now \o/
< fjahr> hi
< achow101> finally
< jonatack> I'd propose the topic of multilabels
< jonatack> (after wallet boxes)
< achow101> meshcollider: so what are the long term goals?
< jnewbery> meshcollider: are you polling for long-term goals or were you going to tell us what your long-term goals are for the wallet?
< meshcollider> jnewbery's contributor survey asks everyone what their goals for core are, so if people have been thinking about it, does anyone want to discuss anything they'd like to see in the wallet
< meshcollider> Polling :)
< achow101> I'd like hardware wallet support :)
< achow101> but, in general, I think wallet boxes will let us do a lot more things
< jnewbery> clean up the node-wallet interface and make progress towards multiprocess
< achow101> and I guess semi-related would be miniscript and generic signing code
< meshcollider> yeah I think there will be lots of opportunities for really good cleanups after the boxes are all merged
< meshcollider> sipa: anything you envision?
< sipa> nothing specifically
< meshcollider> Alright awesome, so we do still have some clear longer term goals to continue with +1
< meshcollider> #topic Multilabels (jonatack)
< achow101> also descriptor wallets as a mid-term goal
< wumpus> would also like hardware wallet support
< achow101> jonatack: can you explain what you mean by mulitlabels>
< jonatack> Multilabels: looking for concept acks on enabling passing an array of labels to
< jonatack> RPCs setlabel, getnewaddress, importaddress, etc
< jonatack> and for listransactions to output an array of labels
< jonatack> and for listreceivedbylabels to filter on said array
< jonatack> and possibly rm the purpose field in the getaddressesbylabel response
< meshcollider> Have you thought about whether the GUI display would all labels for each address?
< meshcollider> Would display*
< achow101> I think purpose is separate from labels
< jonatack> and possibly add a case insensitive arg option for the label filtering in getaddressesbylabel and listtransactions
< jonatack> meshcollider: i'll admit that i've thought only about the rpc interface so far, if concept ack, would add gui to my thoughts :)
< jonatack> achow101: agreed
< achow101> concept ack multiple labels on things
< meshcollider> Yep supporting multiple labels makes logical sense to me
< jonatack> also possibly setlabel could receive an array of addresses as well as an array of labels
< achow101> keep in mind api compatibility though
< achow101> every place we take a label will need to be able to tae both a string and array of strings otherwise we lose compatibility
< achow101> same with output. that could be problematic
< meshcollider> Is "purpose" able to be set by the user currently or does it just default to "receive" automatically
< jonatack> *etc above also including the importmulti, addmultisigaddress, importprivkey, importpubkey
< achow101> meshcollider: I don't think it's user accesible
< jonatack> meshcollider: set to receive or send automatically
< meshcollider> Sweet
< achow101> it's "receive", "send", or "". "" is how we determine change
< jonatack> achow101: api compat -- agreed
< jonatack> good point
< meshcollider> Alright any other topics?
< jonatack> achow101: output hmmmmm
< jonatack> thanks. any other thoughts hit me up.
< meshcollider> Alright I guess that's it for today then
< meshcollider> #endmeeting
< lightningbot> Meeting ended Fri Jan 17 19:26:00 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< meshcollider> And remember to send (wallet or otherwise) topic discussion ideas for coredev to John or kanzure or someone
< kanzure> thank you meshcollider
< kanzure> and remember, if you don't send topics, then i will randomly assign them to you
< instagibbs> slept through the meeting oops. For me it's Descriptor-wallets->{HWW/Miniscript} and also more flexible fee-bumping, just *assuming* someday we'll have real fees again
< jonatack> instagibbs: sgtm
< instagibbs> achow101 did some related prep work which should make auto-CPFP doable
< instagibbs> RBF is pretty ok now(anything better is way more complicated), so having CPFP as another tool in the box would be super
< instagibbs> #17331 is the PR I mentioned, makes effective value everywhere, kills off stupid CreateTransaction loop that has plagued us for years
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 . Pull Request #17331 . bitcoin/bitcoin . GitHub
< achow101> unforunately no one wants to review coin selection
< elichai2> I would love to see Descriptor wallets. I hate a PR kinda ready for taproot descriptors so with descriptor wallets I should be able to integrate taproot into the wallet pretty easily
< instagibbs> Well, boxing wallet is sucking the air out for now, chill :)
< elichai2> (not saying it's anytime soon :P)
< instagibbs> achow101, also it doesn't appear you have to rebase yet so not very painful
< achow101> instagibbs: on the bright side, no one touches coin selection so it doesn't need rebasing :)
< kanzure> i'd rather review a coin selection simulator before i'd view an individual coin selection implementation?
< kanzure> e.g. test against variety of circumstances and fee markets
< instagibbs> kanzure, well I don't particularly care about the algorithms now, see the above PR
< instagibbs> it's mostly structuring txn creation code to be less dumb
< achow101> it has a minor impact on the selection algo though
< jonatack> achow101: i think coin control is interesting :) am just constrained by amount of free time i can spend on bitcoin core
< instagibbs> If you're ok with being a UTXO cop, I think Core selection is fine. It's when people are dusting you it costs.
< instagibbs> Verbose and too complicated, but fine :)
< elichai2> I'll try again :) Any tips on how to recreate failed travis enviroments locally? I have two weird failures in travis I want to test locally (CentOS one and `x86_64 Linux [GOAL: install] [xenial] [no depends, only system libs, sanitizers: thread (TSan), no wallet]`)
< jonatack> elichai2: the failing travis logs are unhelpful?
< elichai2> jonatack: basically compile errors. now I need to figure out why it compiles on some machines and other not
< achow101> elichai2: what pr?
< achow101> or travis job
< elichai2> the 2 Mac ones I know, my problem is with the other 2
< bitcoin-git> [bitcoin] ryanofsky opened pull request #17954: wallet: Remove calls to Chain::Lock methods in wallet (master...pr/unlock) https://github.com/bitcoin/bitcoin/pull/17954
< elichai2> jonatack: especially when travis doesn't print the exact commands being run :/
< achow101> elichai2: all of the commands travis runs are in .travis.yml
< achow101> it calls a bunch of scripts in ci/
< achow101> those'll have all of the configure commands so you can replicate the config
< elichai2> achow101: well you need to chase enviroment variables to figure out the exact commands, that what I'm doing now, launched a docker and trying to recreate the env, I think I was able to recreate the TSan error
< elichai2> hopes there's a ./run_ci_locally lol
< jonatack> elichai2: i avoid docker like the plague but yeah was thinking test those build environments with it
< elichai2> jonatack: well easier to have the right g++ version with dockers
< jonatack> yes. and maybe push on a different branch running travis locally for the final checks
< elichai2> jonatack: right. that's usually what I do after I think i've fixed it
< jonatack> with just the problematic builds. right. sorry not more helpful
< elichai2> hmm the Tsan one seems to be either an error in boost or the fact that it's g++5.4 :( I guess I need to include the whole module because of that, why distros why :(
< achow101> elichai2: you can make a new private repo and setup travis debug builds
< elichai2> achow101: good idea, i'll add `set -x`
< achow101> then you can ssh into the travis vm and do things there
< elichai2> you can ssh into travis?!
< achow101> private repos only
< jonatack> til. cool
< elichai2> :D Thanks
< achow101> one thing though, the vms tend to crash when you try to do too much or take too long. happens to me quite a bit
< luke-jr> it's annoying tho
< luke-jr> if a step fails, it kills the session still
< achow101> also private repos are low priority so builds run one at a time and take forever
< luke-jr> and there's a time limit
< achow101> I only use it when I can't figure out the problem from logs or replicate it locally
< luke-jr> travis logs have been super annoying lately IMO - sometimes I enter debug mode simply because I can't figure out *what* failed
< fanquake> kanzure what do you mean by randomly assign topics?
< kanzure> fanquake: just joking :-)
< kanzure> fanquake: usually i write down topics that i think certain people should talk about
< kanzure> fanquake: but usually it's not so random and instead based on what people have been working on that i happen to know about
< fanquake> ?