--- Day changed Wed Jul 19 2017
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
00:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:13 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
00:22 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
00:22 < eck> what's the recommended way for me to test a change before submitting a PR? is "make check" sufficient?
00:23 < gmaxwell> eck: no, read test/README.md
00:24 < eck> thanks
00:24 < gmaxwell> test/functional/test_runner.py
00:24 < gmaxwell> is what you want to run in addition to a make check.
00:25 < gmaxwell> of course it depends on what you're doing, for some things make check is sufficient... or just a particular one of the functional tests.
00:25 < gmaxwell> but if you don't know, better to run them all.
00:25 < gmaxwell> Our CI setup will run them on whatever you submit, but if it fails you'll still need to be able to run them locally to figure out what happened, so its best to get in the habbit of it.
00:41 < bitcoin-git> [bitcoin] eklitzke opened pull request #10881: trivial: fix various pyflakes/vulture warnings (master...vulture) https://github.com/bitcoin/bitcoin/pull/10881
00:48 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 248 seconds]     
01:07 -!- ADheaume [9902f721@gateway/web/freenode/ip.153.2.247.33] has joined #bitcoin-core-dev     
01:08 -!- ADheaume [9902f721@gateway/web/freenode/ip.153.2.247.33] has quit [Client Quit]     
01:12 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
01:13 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
01:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
01:42 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev     
01:47 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has joined #bitcoin-core-dev     
01:50 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:52 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
02:01 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
02:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
02:17 -!- darawk [~textual@cpe-104-175-210-12.socal.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:29 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
02:46 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
02:46 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit]     
02:54 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9e8d6a3fb43a...a6ec5802b0a9
02:54 < bitcoin-git> bitcoin/master e0d4592 practicalswift: Avoid redundant redeclaration of GetWarnings(const string&)...
02:54 < bitcoin-git> bitcoin/master a6ec580 Jonas Schnelli: Merge #10864: Avoid redundant redeclaration of GetWarnings(const string&)...
02:54 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #10864: Avoid redundant redeclaration of GetWarnings(const string&) (master...GetWarnings-in-warnings.h) https://github.com/bitcoin/bitcoin/pull/10864
02:54 < jonasschnelli> Oh. I guess I should not have merged this because of the freeze.
02:54 < jonasschnelli> Sry     
03:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:03 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
03:04 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
04:00 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]     
04:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
04:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
04:13 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
04:36 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
04:39 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds]     
04:40 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
04:53 -!- JackH [~laptop@46.231.18.66] has joined #bitcoin-core-dev     
05:57 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 260 seconds]     
06:07 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has joined #bitcoin-core-dev     
06:11 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev     
06:12 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Ping timeout: 255 seconds]     
06:17 -!- goatpig [56f75436@gateway/web/freenode/ip.86.247.84.54] has quit [Ping timeout: 260 seconds]     
06:20 -!- Giszmo [~leo@ip-142-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
06:21 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
06:25 -!- arowser [~quassel@45.32.248.113] has quit [Ping timeout: 255 seconds]     
06:31 -!- arowser [~quassel@45.32.248.113] has joined #bitcoin-core-dev     
06:31 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:32 -!- Giszmo [~leo@ip-142-233.219.201.nextelmovil.cl] has quit [Ping timeout: 240 seconds]     
06:44 -!- ayy1337|2 [~kvirc@110.140.15.24] has joined #bitcoin-core-dev     
06:46 -!- Giszmo [~leo@ip-54-233.219.201.nextelmovil.cl] has joined #bitcoin-core-dev     
06:54 < jonasschnelli> I can't reproduce the following travis issue locally (by using Ubuntu 14.04 and the same build configuration): https://travis-ci.org/bitcoin/bitcoin/jobs/254826520#L2299
06:54 < jonasschnelli> Maybe someone has an idea why I get a "/usr/include/c++/4.8/debug/safe_iterator.h:279:error: attempt to dereference a singular iterator."
06:55 -!- Giszmo [~leo@ip-54-233.219.201.nextelmovil.cl] has quit [Ping timeout: 258 seconds]     
06:59 -!- talmai [~T@c-76-24-28-74.hsd1.ma.comcast.net] has quit [Max SendQ exceeded]     
07:02 -!- Guest32541 [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 240 seconds]     
07:05 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
07:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
07:10 < cfields> jonasschnelli: that one uses everything built with extra debugging defines
07:10 < jonasschnelli> cfields: D_GLIBCXX_DEBUG, right?
07:10 < cfields> jonasschnelli: -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
07:11 < cfields> make -C depends DEBUG=1
07:11 < jonasschnelli> Ah.. the dependencies... 
07:11 < jonasschnelli> cfields: Just passing -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC into ./configure won't be "enought"?
07:12 < cfields> jonasschnelli: iirc all the deps have to be built with those flags otherwise wonky things happen
07:12 < cfields> but i could be misremembering
07:12 < jonasschnelli> okay. Let me try that...
07:12 < jonasschnelli> (via depends)
07:13 < cfields> jonasschnelli: those errors are almost always foo.empty() && foo[0]
07:13 < jonasschnelli> cfields: accessing an index that is not available?
07:15 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
07:15 < cfields> jonasschnelli: ah, looks like a "singular" iterator is one that can't be reached. 
07:15 < cfields> so probably more like *foo.end()
07:15 -!- Aaronvan_ is now known as AaronvanW     
07:16 < jonasschnelli> cfields: Thanks... I'll check the code.
07:18 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
07:25 < wumpus> re: #10873 we really need to add a comment, this isn't the first time someone has tried to replace the signal handling with a mutex
07:25 < gribble> https://github.com/bitcoin/bitcoin/issues/10873 | Use a condition variable for shutdown notifications by eklitzke · Pull Request #10873 · bitcoin/bitcoin · GitHub
07:25 < wumpus> this won't work for handling UNIX signals, certainly not in a portable way
07:26 < jonasschnelli> wumpus: Yes. How long was it ago since I tried it. :)
07:26 < jonasschnelli> I didn't commented because I tried with a boost signal rather then a mutex
07:26 < jonasschnelli> Wasn't sure if this is portable or not
07:27 < cfields> jonasschnelli: the list of things you're actually allowed to use is remarkably small
07:27 < jonasschnelli> cfields: Yes. I once checked... atomics should be fine... but I guess conditional vars aren't
07:27 < wumpus> yes, setting a flag is fine
07:28 < wumpus> I think you are allowed to read/write pipes as well
07:29 < wumpus> there are some tricks that could be taken over from other daemons, but it might not be worth the trouble
07:30 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev     
07:30 -!- sdfgsdfg [~sdfgsdfg@unaffiliated/sdfgsdfg] has quit [Remote host closed the connection]     
07:37 < wumpus> maybe there's even some obscure trick with sigwait() that would work
07:45 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:47 -!- promag [~joao@2001:8a0:fe30:de01:cd37:894c:3b11:d3e8] has joined #bitcoin-core-dev     
07:47 -!- promag [~joao@2001:8a0:fe30:de01:cd37:894c:3b11:d3e8] has left #bitcoin-core-dev []     
07:47 -!- promag [~joao@2001:8a0:fe30:de01:cd37:894c:3b11:d3e8] has joined #bitcoin-core-dev     
07:47 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a6ec5802b0a9...9022aa37226b
07:47 < bitcoin-git> bitcoin/master b138585 Alex Morcos: Remove factor of 3 from definition of dust....
07:47 < bitcoin-git> bitcoin/master f4d00e6 Alex Morcos: Add a discard_rate...
07:47 < bitcoin-git> bitcoin/master 9022aa3 Wladimir J. van der Laan: Merge #10817: Redefine Dust and add a discard_rate...
07:47 < bitcoin-git> [bitcoin] laanwj closed pull request #10817: Redefine Dust and add a discard_rate (master...discardmore) https://github.com/bitcoin/bitcoin/pull/10817
07:47 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving]     
07:48 < promag> is practicalswift around?
07:50 < jonasschnelli> jnewbery, ryanofsky: continue the discussion about -wallet vs -usewallet here?
07:50 < jonasschnelli> I can't follow the argument of having -wallet for both use-cases (define which wallet to use and for adding a wallet to the daemon).
07:51 < jonasschnelli> Why would you want the use same argument for two different things?
07:51 < jonasschnelli> In the daemon case, you define a wallet to add to the sync process. For cli, you want to define which of those availavle wallets you want to use (1:n)
07:52 < ryanofsky> jonasschnelli, maybe you can give a practical example of why having different argument names is useful
07:53 < ryanofsky> obviously command line arguments can have different meanings on different commands. if you add --help or --verbose to a unix command it will do different things depending on the command
07:53 < jonasschnelli> ryanofsky: a) because its to different things (and users should learn that from the beginning), b) -usewallet could be reused for bitcoin-Qt (until there is a GUI way to select the wallet)
07:53 < jonasschnelli> "two
07:54 < jnewbery> jonasschnelli, for the reasons I gave in https://github.com/bitcoin/bitcoin/pull/10868#issuecomment-316409725 - I think the name usewallet is meaningless and confusing
07:54 < ryanofsky> can you explain qt use case a little more? qt runs a full node & wallet
07:55 < jonasschnelli> Users now need to learn that they can run multiple wallets by providing multiple of the same -wallet arguments (it's already kind of confusing, most users would expect a comma separator argument)
07:55 < jonasschnelli> ryanofsky; Right now, Qt always uses the wallet at index 0
07:56 < jonasschnelli> I think having then -wallet for CLI, they would need to learn that in one case they specify multiple wallets while in the other case they specify a single wallet... seems confusing to me
07:56 < ryanofsky> right, so what do you need a -usewallet option for in context of qt?
07:56 < jonasschnelli> ryanofsky: Qt: until we have a wallet selection via GUI, you could define which of those wallets is accessible over Qt.
07:57 < ryanofsky> jonasschnelli, right now with qt, you already have it serve multiple wallets, and you can choose which wallet will be shown in the display by putting the wallet first. there is no need for -usewallet
07:58 < ryanofsky> adding -usewallet for qt would again just be adding confusion & complexity for no reason
07:58 < jonasschnelli> Yes. Agree that this would work, though do we really want to depend on orders of arguments?
07:58 < ryanofsky> no, we want to add a dropdown or tab
07:58 < jonasschnelli> Yes. Indeed.
07:59 < ryanofsky> i'm saying adding "usewallet" is not clarifying, it is just throwing in more complexity
07:59 < jonasschnelli> Yes. I'm not sure if the -usewallet case for Qt is valid... though I think it is for cli
07:59 < jonasschnelli> It is already complex.
07:59 < ryanofsky> -wallet=filename everywhere should just work
08:00 < jonasschnelli> So users need to know that in one case (daemon) it's the key to "have multiple" while in the other case (cli) is the key to reduce it from multiple to one?
08:00 < ryanofsky> nobody objects that "cp" and "mv" both take "--help" or "--verbose" arguments because verbose output is different in both cases, it's just a weird argument
08:01 < jonasschnelli> --help is always help. Not once setting the -help information and once reading it
08:01 < ryanofsky> users do need to know that daemon accepts multiple -wallet= arguments to load multiple wallets. i'm not sure why that is a problem
08:01 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9022aa37226b...d445a2c2eaa1
08:01 < bitcoin-git> bitcoin/master 1c9b818 Andrew Chow: getinfo deprecation warning
08:02 < bitcoin-git> bitcoin/master d445a2c Wladimir J. van der Laan: Merge #10857: [RPC] Add a deprecation warning to getinfo's output...
08:02 < ryanofsky> users should just be shown an error if they are expecting bitcoin-cli to send an single rpc command to multiple wallets
08:02 < bitcoin-git> [bitcoin] laanwj closed pull request #10857: [RPC] Add a deprecation warning to getinfo's output (master...deprecate-getinfo) https://github.com/bitcoin/bitcoin/pull/10857
08:02 < jonasschnelli> It's just my opinion. I can live with the pure -wallet for everything approach.
08:03 < ryanofsky> sounds good to me
08:03 < jnewbery> I think the error message in my PR can be improved, but russ is correct - the error should inform the user that they need to specify -wallet on the command line
08:03 < jonasschnelli> I wonder what other developers think... 
08:04 < jonasschnelli> jnewbery: but that is how it currently works (just with -usewallet), right?
08:04 < ryanofsky> pr needs reviews, so i also want other developers to chime in :)
08:04 < jonasschnelli> I just can't follow why you would want to add code to differenciate -wallet in bitcoin conf to -wallet passed into bitcoin-cli
08:06 < ryanofsky> that is a drawback. if you want bitcoin-cli to be able to use wallet filename from a config file, you have to call the option something other than -wallet
08:07 < jnewbery> but how -usewallet is interpreted is differentiated as well - acted on by bitcoin-cli, ignored by bitcoind, and you haven't decided on whether it should be ignored or not by bitcoin-qt
08:07 < ryanofsky> reason i think tradeoff is worth is is that -wallet=filename means our tools do not silently ignore bad wallet filenames, and there is weirdness and option interactions to have to think about
08:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
08:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
08:15 < jonasschnelli> Maybe something we should discuss at this weeks IRC meeting
08:21 < ryanofsky> i'd prefer pr reviews & acks but ok :)
08:25 < jnewbery> I agree. I think Russ is the only one who's reviewed/tested the code so far. But happy to discuss further at the meeting
08:32 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
08:34 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
08:38 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
08:39 < sipa> jonasschnelli: i though the same way
08:39 -!- mmgen [~mmgen@178-175-130-19.ip.as43289.net] has joined #bitcoin-core-dev     
08:40 < sipa> jonasschnelli: but it's not so different from how -rpcport for bitcoind means "the port to listen on" nd for bitcoin-cli means "the port to connect to"
08:40 < sipa> the ignoring of arguments in the config file is weird... but it is (almost) just an implementation detail... in practice you always get the expected behaviour
08:41 < sipa> evwn if it were implemwnted differentlt
08:50 -!- mmgen [~mmgen@178-175-130-19.ip.as43289.net] has quit [Ping timeout: 255 seconds]     
08:53 -!- promag [~joao@2001:8a0:fe30:de01:cd37:894c:3b11:d3e8] has quit [Quit: Leaving.]     
08:54 < wumpus> I don't think re-using -wallet for bitcoin-cli is a good idea
08:55 < wumpus> re-using rpcport is clever because the setting on client and server side happens to match up w/ the interface in between
08:56 < wumpus> if it'd be possible to specify multiple rpcports in the server config, we'd have the same problem there
08:56 < wumpus> -rpcbind is allowed to be used multiple times, but isn't used by the client at all
08:57 < wumpus> e.g. a multi-option on the server side shouldn't be a single option on the client side, given we parse the same configuration file
08:59 < wumpus> <ryanofsky> nobody objects that "cp" and "mv" both take "--help" or "--verbose" arguments because verbose output is different in both cases, it's just a weird argument <- yes, but cp and mv don't read their arguments from a configuration file
08:59 < wumpus> e.g. you might want to set a default wallet for bitcoin-cli to use in the configuration file, you can't use -wallet for that
08:59 < wumpus> if bitconi-cli read a different configuration file I'd have agreed there was no conflict
09:00 < wumpus> but that's not where we're coming from, or even where we're going
09:00 < ryanofsky> wumpus, yes, the tradeoff for having bitcoin-cli accept a wallet argument is having to ignore wallet values from the config file
09:00 < wumpus> that sounds stupid
09:00 < wumpus> why would you be so insistent in using -wallet for the option to special case it in config file reading?
09:00 < wumpus> just use a different argument name and be done with it
09:01 < ryanofsky> ok, well that's the tradeoff, we've discussed what i think are better options for allowing default wallets
09:01 < ryanofsky> i'm not insistent on anything
09:01 < wumpus> what is the trade-off? why would you insist on using -wallet at all?
09:01 < wumpus> it causes a conflict so imo the option should not be named that
09:01 < ryanofsky> i'm just saying what i think, which is that using different arguments is confusing, and being able to read wallet from config file is not actually useful compared to better options
09:01 < wumpus> making a special workarounds just to be able to call it -wallet is strange
09:02 < wumpus> if bitcoin-cli would not read the config file at all, or a different config file, I'd be ok with it
09:02 < ryanofsky> ok, well that's my strange argument :)
09:02 < wumpus> but we can't just do that, certainly not for 0.15
09:02 < ryanofsky> if you object, then go with usewallet and wallet
09:02 < wumpus> special-casing just seems weird
09:02 < wumpus> I really dislike it
09:02 < wumpus> 'why would all options be read from the config file except for X?' that's just drunk
09:03 < jnewbery> having a `useargument` argument that is used by bitcoin-cli but is not used by bitcoind seems strange to me
09:03 < wumpus> why owuld that be strange? bitcoin-cli has lots of arguments that are not used by bitcoind
09:03 < wumpus> why would they need to overlap?
09:03 < ryanofsky> yeah, i just think this wallet config file thing is a strange corner case compared to everyday usage
09:04 < wumpus> what would bitcoind want to do with it ta all?
09:04 < jnewbery> Because of the arguments I give here: https://github.com/bitcoin/bitcoin/pull/10868#issuecomment-316409725
09:04 < wumpus> it'd be the default wallet for the *client*
09:04 < sipa> if the '-use' sounds liie meaningless, use -rpcwallet maybe
09:04 < wumpus> sipa: yes! sounds good to me
09:04 < ryanofsky> i'd be fine with rpcwallet, that's what i suggested when the arg was first added
09:04 < instagibbs> rpcwallet is nicer
09:04 < wumpus> I don't really care what name, it should just not be -wallet
09:05 < wumpus> though I guess rpcwallet would be more consistent with some other rpc options
09:05 < jnewbery> I still think ryanofksy's point about protecting against users putting in bad -wallet arguments is valid, but -rpcwallet is definitely a step up from -usewallet
09:06 < ryanofsky> maybe also consider making it an error for user to specify -wallet on bitcoin-cli command line if it will be ignored
09:06 < wumpus> multiple -rpcwallet should also be an error
09:06 < sipa> ryanofsky: ?
09:06 < wumpus> ryanofsky: that'd result in an error as well  when it's specified in the config file
09:07 < ryanofsky> yes that's why i said "on bitcoin-cli command line"
09:07 < jnewbery> wumpus: depends where you put the check
09:07 < wumpus> then again, when bitcoind runs in multiwallet mode, it won't accept missing wallet
09:07 < ryanofsky> or don't, anyway i was just suggesting that because i think -wallet -rpcwallet are easy to confuse
09:07 < wumpus> so you *have* to run -cli with rpcwallet
09:07 < wumpus> right?
09:08 < ryanofsky> you wouldn't need -rpcwallet if you are making a non-wallet rpc call or your node only has one wallet loaded
09:08 < wumpus> yes, and that's fine
09:08 < jnewbery> I think Russ is thinking about the case where someone starts bitcoind with -wallet=mybusinesswallet.dat in the conf file, then calls `bitcoin-cli -wallet=mypersonalwallet.dat send ...` and is confused that money is sent from their business wallet even though they specified a different wallet
09:09 < ryanofsky> yes, i'm just said that in response to "so you *have* to run -cli with rpcwallet
09:09 < wumpus> we don't distinguish command line and config options, and imo that should stay that way
09:10 < jnewbery> not true - rpcport is an example
09:10 < wumpus> how?
09:10 < sipa> it has a different meaning for client and server, sure
09:11 < sipa> but we don't complain in bitcoin-cli that -dbcache is specfied, right?
09:11 < jnewbery> oh sorry - yes you're right
09:13 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has left #bitcoin-core-dev []     
09:16 < sipa> i guess there is one example of an option that is treated differently between cmdline and configfile... -conf
09:16 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
09:18 < jnewbery> and I'd expect #10267 to be treated differently on command-line versus .conf file, but again I may be in the minority
09:18 < gribble> https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
09:18 < jnewbery> >we don't complain in bitcoin-cli that -dbcache is specfied
09:18 < jnewbery> but specifying the wrong -dbcache on the command line for bitcoin-cli cannot lead to loss of funds
09:21 < sipa> i think that's unlikely here
09:21 < gmaxwell> Wrong testnet parameter can, in the same way wallet parameters can. (much worse, in fact)
09:21 < gmaxwell> I've been saved multiple times from doing something phenominally dumb re testnet vs mainnet through using wallet encryption as an authorization step.
09:23 < wumpus> yes, having separate configuration files per network would make a lot of sense too
09:24 < gmaxwell> (I like sharing them for most parameters, in fact...)
09:24 < sipa> wumpus: oh tes
09:24 < sipa> yes     
09:24 < wumpus> jnewbery: yes, -conf is somewhat of an exception too, it's not explicitly treated differently but in effect it is because -conf in a configuration file does nothing, it's parsed before
09:25 < wumpus> gmaxwell: yes, keeping a shared one is ok too
09:25 < wumpus> doesn't have to be either or
09:25 < wumpus> as long as the precedence order is well-defined
09:26 -!- JackH [~laptop@46.231.18.66] has quit [Quit: Leaving]     
09:32 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:34 -!- jamesob_ [~james@tempo-automation.static.monkeybrains.net] has joined #bitcoin-core-dev     
09:42 < wumpus> especially for things like network configuration it's almost essential have different config files per network, e.g. as soon as you specify rpcbind or bind with explicit port you'll run into port conflicts otherwise
10:10 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:38 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds]     
10:39 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
10:39 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 255 seconds]     
10:51 -!- THoVer [4e3a800f@gateway/web/freenode/ip.78.58.128.15] has joined #bitcoin-core-dev     
10:56 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
10:56 -!- CubicEarth [~cubiceart@206.54.118.113] has joined #bitcoin-core-dev     
11:00 -!- newbie-- [~irc@mirk.info] has joined #bitcoin-core-dev     
11:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:05 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:06 -!- darawk [~textual@76.79.73.19] has joined #bitcoin-core-dev     
11:11 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
11:15 -!- owowo [ovovo@gateway/vpn/mullvad/x-txfbzykjfrwtqgph] has quit [Ping timeout: 268 seconds]     
11:17 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
11:20 < bitcoin-git> [bitcoin] jnewbery opened pull request #10882: [WIP] Keypool topup (master...keypool_topup) https://github.com/bitcoin/bitcoin/pull/10882
11:22 < jnewbery> 10882 is the cut-down version of #10830 which sipa and gmaxwell were asking for in the last meeting. I'm still fixing the testcase, but I'd appreciate some code review if possible
11:22 < gribble> https://github.com/bitcoin/bitcoin/issues/10830 | [WIP] [wallet] keypool restore by jnewbery · Pull Request #10830 · bitcoin/bitcoin · GitHub
11:22 < jnewbery> I think people wanted this in 0.15 as a bugfix
11:24 -!- u_nuSLASHkm8 [~111111111@77.234.42.172] has joined #bitcoin-core-dev     
11:25 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:25 -!- Guyver2_ [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:27 -!- u_nuSLASHkm8 [~111111111@77.234.42.172] has left #bitcoin-core-dev []     
11:27 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
11:27 -!- Guyver2_ is now known as Guyver2     
11:34 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
11:34 < instagibbs> jnewbery, will review
11:35 < jnewbery> thanks instagibbs
11:37 < bitcoin-git> [bitcoin] jnewbery closed pull request #10830: [WIP] [wallet] keypool restore (master...pr10240) https://github.com/bitcoin/bitcoin/pull/10830
11:38 < jonasschnelli> I just did a quick scrollback read. Is -rpcwallet still in talk?
11:38 < jonasschnelli> I'd prefere to keep rpc out of the naming... 
11:39 < jonasschnelli> isn't bitcoin-cli transport agnostic?
11:39 < jonasschnelli> (from the users interface perspective)
11:40 < sipa> what do you mean transport agnostic/
11:42 < jonasschnelli> I probably over-engineer. But what if we once change bitcoin-cli's transport layer?
11:43 < jonasschnelli> the rpc layer is hidden from the user
11:43 < jonasschnelli> -rpcwallet includes the used transport layer in the naming scheme.
11:43 < sipa> so?     
11:43 < sipa> so does -wallet
11:43 < jonasschnelli> ?     
11:44 < sipa> i may misunderstand what you're saying
11:44 < jonasschnelli> -(rpc)wallet 
11:44 < sipa> bitcoin-cli is an rpc client
11:44 < sipa> the transport layer may change from TCP to Unix sockets or something
11:44 < sipa> but it'll still be an RPC client
11:44 < jonasschnelli> What if we change to a different IPC protocol?
11:45 < jonasschnelli> I probably over-enginee. Nm.
11:45 < sipa> then everything needs to change; including rpcport, rpcserver, ...
11:45 < jonasschnelli> I just though until now, I could not see any "rpc" in bitcoin-cli (from the users perspetive)
11:45 < jonasschnelli> Yeah. That.. so yes. nm then.
11:46 < jonasschnelli> Okay. I take back my argument. With -rpcserver, etc. -rpcwallet may make sense.
11:47 < gmaxwell> what is -rpcwallet precisely
11:47 < jonasschnelli> gmaxwell: I guess it would be the substitute for -usewallet
11:47 < gmaxwell> is it the setting that tells bitcoin-cli what wallet to talk to
11:47 < sipa> gmaxwell: suggested new name for -usewallet
11:47 < gmaxwell> okay
11:47 < sipa> yes     
11:47 < jonasschnelli> What was the issue with -usewallet?
11:47 < sipa> people think use is a weasel word
11:48 < sipa> (i really don't care anymore)
11:48 < jonasschnelli> Yeah, I don't care. But please not -wallet
11:49 < gmaxwell> gowallet=foo :P
11:50 < sipa> ./bitcoin-cli -thethingimean=foo
11:51 < gmaxwell> enablewallet=bob
11:51 < gmaxwell> walletify=bob
11:51 < sipa> ok...
11:52 < gmaxwell> openwallet=info
11:52 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
11:56 < jonasschnelli> Among those options, I would still prefere "usewallet"
11:56 -!- CubicEarth [~cubiceart@206.54.118.113] has quit [Ping timeout: 240 seconds]     
12:08 -!- THoVer [4e3a800f@gateway/web/freenode/ip.78.58.128.15] has quit [Quit: Page closed]     
12:08 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
12:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
12:11 -!- CubicEarth [~cubiceart@206.54.118.113] has joined #bitcoin-core-dev     
12:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:24 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
12:25 < morcos> wumpus: I don't care too much what we call the argument name, and I think we should just decide so we can make the behavior nice around it (my vote would be wallet, rpcwallet, usewallet in that order, but I don't care)
12:25 < morcos> I would say though that I think we should break the conf file and command line option thing being treated equally no matter what
12:26 < morcos> If we use wallet as the -cli option, then we break it as per jnewbery's pull.  If we use rpcwallet or usewallet, then i think it makes sense to flag an error if -wallet is given on the command line.  
12:26 < morcos> I agree with ryanofsky that it is possible people will make that mistake, and I don't think we should let them semi-reasonably think they are specifying one wallet and have things happen to another
12:28 < wumpus> if it wasn't for the authentication options we could stop parsing bitcoin.conf completely for the -cli
12:28 < wumpus> that would be fine with me, I don't want to parse one option from .conf but not another though, exceptions like that always result in confusion and wtf in the longer run
12:28 < morcos> We should also let it be an error if there are multiple instances of (rpc/use)wallet which begs the question of what do we do if you put (rpc/use)wallet in the conf file because clearly you need to be able to override from the command line
12:29 < wumpus> I'm not convinced it should be treated otherwise than other options
12:29 < morcos> Meaning the last value controls?
12:29 < wumpus> yes     
12:29 < wumpus> if you use -rpcport you don't expect it to connect to all ports at once, do you?
12:29 < wumpus> not sure why -rpcwallet would be different
12:30 < morcos> no but i expect someone to tell me i'm an idiot
12:30 < wumpus> if so,the whole command line/config parsing should be refactored, whih should probably happen at some time, including errors if you provide an unrecognized option
12:30 < wumpus> however we're not there, and we're not going to be there for 0.15
12:31 < wumpus> I think any special-casing we introduce now for rpcwallet is a bad idea, especially as the whole API is still supposed to be experimental in the first place
12:31 < morcos> hmm, is the code to figure out whether something is a multiarg vs a single arg shared btwn bitcoind and -cli
12:31 < morcos> i guess it must not be?
12:31 < morcos> oh     
12:31 < morcos> never mind
12:32 < morcos> if its different names it doesnt matter
12:32 < wumpus> all the argument parsing code is shared
12:32 < wumpus> itis' in util.cpp
12:32 < morcos> (rpc/use)wallet is a single arg, wallet ais a multi arg
12:32 < wumpus> but just use a different name so it doesn't matter
12:32 < wumpus> right.
12:32 < ryanofsky> i mostly like john's pr because i think it gets rid of all the ways to shoot yourself in the foot. and i don't think the special casing is a big deal. but if it is, then obvs different approach is needed
12:32 < wumpus> I do think the special casing is a big deal
12:32 < wumpus> but I have to maintain the code over a long time
12:32 < morcos> well lets just pick and be done with it, any will be fine..
12:33 < wumpus> and I'm sick of all kind of weird special casing
12:33 < morcos> rpcwallet it is..  although i admit i'm hesitant about specifying multiple rpcwallets and having the last one control..  but i don't know an easy solution to that
12:33 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]     
12:33 < wumpus> it might seem easier on the short term but on the long time, arbitrariness is going to confuse
12:33 < wumpus> both developers and users
12:34 < wumpus> but it's always 'hey, why not add another special case'
12:34 < jnewbery> I don't even consider it special casing. Command line overrides conf file, just as for other arguments
12:34 < wumpus> noo of course not
12:34 < morcos> but you're right a later clean up could allow for all rpc options, you can only have a second single arg if its the command line overriding the conf file
12:34 < jnewbery> it's implemented differently because it's not possible to fully override mapmultiargs
12:34 < wumpus> if you do it it's not a special case
12:34 < jnewbery> but that's the functional outcome
12:34 < ryanofsky> wumpus, these arguments just seem pretty abstract to me, and i wish you'd bring them down to concrete examples of how the actual code in the pr could cause problems
12:35 < wumpus> I don't feel like repeating myself
12:35 < wumpus> I already argued against reusing -wallet forbitcoin-cli specifically
12:35 < ryanofsky> happy to defer
12:36 < wumpus> it's strange to have a same argument name as single-option for one utility then for multi-option for another utility
12:36 -!- tinyurl_comSLASH [~ycpm5ry3@199.189.106.247] has joined #bitcoin-core-dev     
12:36 < morcos> so arguably the only thing to change from the merged code is s/usewallet/rpcwallet/ if that would overall be preferred?
12:36 < wumpus> *if* htey parse the same configuration file
12:36 < wumpus> yes     
12:36 < wumpus> rpcwallet is a better name
12:36 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:37 < jonasschnelli> Should we still revoke (halt bitcoin-cli) if one provides multiple -rpc/-usewallet arguments?
12:37 < wumpus> and I'm ok with making providing -wallet on the command line for -cli an error, though I think it's overthinking it
12:37 < wumpus> jonasschnelli: no, I don't think so
12:38 < jonasschnelli> So just use the last one?
12:38 < wumpus> jonasschnelli: just like multiple -rpcport is not an error
12:38 -!- tinyurl_comSLASH [~ycpm5ry3@199.189.106.247] has left #bitcoin-core-dev []     
12:38 < wumpus> unless we change that behavior on a global level
12:38 < jonasschnelli> wumpus: Okay. Fine by me
12:38 < wumpus> so if multiple of any non-multi argument is an error, it should be an error, obviously
12:38 < wumpus> but there's no need to suddenly do all kinds of crazy stuff for rpcwallet
12:38 < jonasschnelli> Yes. No special case for every argument type
12:39 < jonasschnelli> But I guess what we should merge for 0.15 is the Qt console support: https://github.com/bitcoin/bitcoin/pull/10870
12:39 < jonasschnelli> Right now, Qt console is useless in multiwallet
12:39 < wumpus> yes     
12:40 < wumpus> I certainly think making the functionality work in the first place is important :)
12:40 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:41 -!- treebeardd [~treebeard@216.110.193.68] has joined #bitcoin-core-dev     
12:41 < wumpus> tagged it
12:42 < jonasschnelli> thanks
12:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
12:44 < wumpus> from what I see "if an argument is specified multiple times, the last value holds" seems to be pretty standard behavior, I don't know of many command line utilities that reject if you specify a flag multiple times
12:45 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
12:45 < eck> I am trying to understand the BIP process, and I'm confused how I can tell which BIPs were actually deployed
12:45 < eck> e.g. is BIP 62 deployed?
12:46 < wumpus> it can even be useful in scripts etc, to be able to override something that is set before
12:46 < ryanofsky> GetArg implement first value holds, right?
12:46 < wumpus> ryanofsky: ugh, okay
12:46 < instagibbs> eck, #bitcoin (can answer there)
12:46 < jonasschnelli> eck: look at the overview. Bip62 is "Withdrawn"
12:46 < wumpus> ryanofsky: are you sure?
12:46 < ryanofsky> no     
12:46 < ryanofsky> which is why i like these things to be errors :)
12:47 < wumpus> but every other comamnd line utiltiy I know uses 'last setting holds'
12:47 < jonasschnelli> But then it should be globally? 
12:47 < wumpus> gcc, ld, ls, etc
12:47 < bitcoin-git> [bitcoin] morcos opened pull request #10883: Rename -usewallet to -rpcwallet (master...rpcwallet) https://github.com/bitcoin/bitcoin/pull/10883
12:50 < morcos> wumpus: sigh.. it chooses the first option given in the conf file unless you give it on the command line and then its the last one from the command line
12:50 < jonasschnelli> :/     
12:50 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #10867: Allow only a single -usewallet argument (master...2017/07/multiwallet_bitcoincli) https://github.com/bitcoin/bitcoin/pull/10867
12:51 < wumpus> yes, it seems to correctly chose the latest from the command line
12:51 < wumpus> .conf semantics are strange
12:51 < jonasschnelli> but why the first from the conf?
12:51 < jonasschnelli> that makes no sense..
12:51 < wumpus> no, it doesn't
12:51 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
12:51 < wumpus> it should be the other way aorund
12:52 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
12:52 < wumpus> for all options, not special casing one :)
12:52 < jonasschnelli> yes.
12:52 < jonasschnelli> Though changing it now could have unexpected consequences. :/
12:53 < morcos> that behavior is what preseves command line overriding right?
12:53 < wumpus> morcos: yes, indeed, in the silly way it works currently
12:53 < jonasschnelli> morcos: IMO the command line overriding is good. But the last config value should be takend before we go to the optional command line overriding
12:54 < jonasschnelli> however, we should not change that.
12:55 < wumpus> in any case there are probably a zillion things broken in command line / config file handling, nothing we should do about that for 0.15, but for later on it makes sense to actually think about it
12:56 < wumpus> especially with things like includeconf=..., people are going to expect later config options are overriding previous ones
12:56 < wumpus> like it is for any other config file parser in the world
12:56 < jonasschnelli> heh. Indeed
12:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
12:57 -!- Guest24650 [~schmidty@c-98-212-53-76.hsd1.il.comcast.net] has joined #bitcoin-core-dev     
12:58 < wumpus> how do other programs handle multi-args? I think our way is strange, in that we can never clear something that has been set, things are only added
12:59 < wumpus> so if the config file sets bind=127.0.0.1:1234, the command line can never override that, only add to it
13:00 < jonasschnelli> I'm not sure, but isn't comma separation a thing? -wallet=w1.dat,w2.dat?
13:00 < wumpus> yeah
13:00 < wumpus> though that always leaves 'what if we have a comma in our value'
13:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
13:01 < jonasschnelli> Use ;
13:01 < wumpus> but that conflicts with the shell :-)
13:01 < jonasschnelli> heh.. yes. use -wallet="a;b;c"?
13:01 < jonasschnelli> But meh
13:01 < wumpus> hehe
13:01 < wumpus> I was just illustrating a point, I know it's hard to work around
13:02 < wumpus> json syntax config file would work
13:02 < wumpus> for command line it's harder
13:02 < jonasschnelli> Yes     
13:03 < wumpus> I must say it wouldn't be the first time I typed -debug=tor,bench though, comma-separated is kind of natural, when it works
13:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:05 < jonasschnelli> Yes. For the wallet it would feel more natural and there is no need for a comma in the filename, though there could be other use cases where you may want/need it
13:06 < wumpus> cool, it warns at least now: Warning: Unsupported logging category -debug=rpc,net,tor.
13:06 < wumpus> suppose that is since the debug categories are an enum
13:06 < wumpus> it used to be silent about it
13:09 < jnewbery> quick question about -rpcwallet in .conf: does that mean that server RPCs are also sent to the /wallet/<rpcwallet> endpoint? That's allowed in the current implementation, but it'll break when we do wallet process separation
13:09 < jonasschnelli> BTW: github recommends to add a COC to the bitcoin core project: https://opensource.guide/code-of-conduct/
13:11 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
13:11 < wumpus> jnewbery: I'd expect -rpcwallet  would mean commands are sent to a wallet endpoint, yes, -cli doesn't have the knowledge whether something is a wallet call or not
13:11 < jnewbery> I suppose we'll generally need to give bitcoin-cli more smarts if we do wallet process separation
13:12 < wumpus> well ... we'll worry about that, then
13:12 < sipa> well my view is that the 'wallet process' would still be a full bitcoind-like thing communicating over SPV... so it would still have P2P connections (typically just one), etc
13:13 < wumpus> there's no way to specify an alternative endpoint at all at the moment
13:13 < sipa> so there's not much reason why you couldn't send a getpeerinfo to a wallet endpoint
13:13 < sipa> which is exactly what it does now
13:13 < sipa> for a few things, like mempool or fee estimation something else may be needed
13:13 < sipa> but that's a worry for later indeed
13:13 < wumpus> heh yes if a wallet endpoints getpeerinfo you can send getpeerinfo to it
13:14 < wumpus> if it doesn't, you'll get an error that it's not implemented
13:14 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
13:15 < jonasschnelli> sipa: Curious, could you think that – if we have p2p enc/auth – mempool and fee est would be something to serve over p2p to auth. peers?
13:15 < jonasschnelli> Or do you see a different channel (RPC, etc,) for that?
13:15 < sipa> jonasschnelli: maybe... that may be controversial
13:16 < sipa> but i don't see much problem in having private extensions available only for known peers
13:16 < jonasschnelli> I'd say that would simplify connection management massively. But I'd also say some people would dislike that.
13:17 < jonasschnelli> Yes. me two
13:17 < sipa> actually, i think that was one of the uses for -whitelist when i suggested :)
13:17 < jonasschnelli> *too
13:17 < jonasschnelli> But thats far in future (net refactor, Bip151, Bip150 and maybe then).
13:17 < sipa> yah     
13:18 < wumpus> I agree authenticated extensions could make sense, please don't overload -whitelist with more things
13:18 < sipa> wumpus: oh, absolutely - i agree with that now
13:21 < sipa> just giving some historical background
13:23 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:25 < wumpus> oh sure, it's one kind of whitelisting option
13:26 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
13:27 -!- roidster is now known as Guest86981     
13:28 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
13:30 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has quit [Ping timeout: 248 seconds]     
13:37 < bitcoin-git> [bitcoin] eliahuhorwitz opened pull request #10884: Update build-windows.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10884
13:47 -!- treebeardd [~treebeard@216.110.193.68] has quit [Remote host closed the connection]     
13:48 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d445a2c2eaa1...df0793f324e3
13:48 < bitcoin-git> bitcoin/master 7ec3343 Gregory Sanders: add gdb attach process to test README
13:48 < bitcoin-git> bitcoin/master df0793f MarcoFalke: Merge #10681: add gdb attach process to test README...
13:48 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10681: add gdb attach process to test README (master...gdbattach) https://github.com/bitcoin/bitcoin/pull/10681
13:57 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:57 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
14:02 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
14:13 -!- CubicEarth [~cubiceart@206.54.118.113] has quit [Remote host closed the connection]     
14:18 < promag> is this correct bitcoin-qt -wallet=foo.dat -wallet=wallet.dat -regtest ?
14:18 < promag> to run multiwallet in qt?
14:28 < sipa> yes     
14:30 -!- CubicEarth [~cubiceart@206.54.118.113] has joined #bitcoin-core-dev     
14:40 -!- CubicEarth [~cubiceart@206.54.118.113] has quit []     
14:49 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
14:53 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
15:08 < promag> sipa: what should be the load order when -wallet=foo -wallet=bar -wallet=foo
15:10 < sipa> ha, no clue
15:10 < sipa> does that even work?
15:11 < promag> yeah
15:11 < promag> :P     
15:11 < promag> I'm submitting a PR to handle that
15:11 < sipa>  cool
15:13 < promag> anyway, I have 2 ideas: 1st add second argumento unique = false to ArgsManager::GetArgs
15:13 < promag> the other is to add GetUniqueArgs
15:14 < promag> which preserves order (first takes effect)
15:14 < cfields> i think the arg manager itself should just sort that out
15:14 < cfields> would we ever care about dupes post-init?
15:15 < promag> however ParseParameters explicit says that the last takes effect when one only wants the arg as a single value
15:15 < cfields> promag: yes, that's the common convention. so that you can add things later in the line to disable earlier ones
15:16 < cfields> s/disable/override/
15:16 < promag> cfields: right so it's config < arg[n] < arg[m] where m > n
15:17 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
15:18 < promag> but in the case of multi value then the order is? config[0], config[1], arg[0], arg[1] right?
15:18 < cfields> that's what i'd expect, yes
15:18 < promag> would we ever care about dupes post-init? -> dunno, wdyt?
15:19 < sipa> i thinkit should just error if you soecify the same one twice
15:19 < sipa> sorry, ohone typing
15:19 < promag> sipa: and if you config[1] = arg[0] ?
15:20 < promag> I mean, if you pass a value in the command line which happens to be in config?
15:20 < promag> is that a error?
15:20 < cfields> right, i would expect it to just quietly drop the dupe
15:20 < promag> the error/warn should be just for the command line args right?
15:20 < promag> so it's just a matter of fixing ParseParameters
15:21 < sipa> ok, merging them is also a reasonable thing to fo
15:21 < sipa> is it *always* the right thing?
15:21 < cfields> sipa: you mean for all args? or for wallet in particular?
15:21 < promag> dunno, didn't go that far
15:21 < sipa> cfields: for all args
15:21 < sipa> if you're talking about changing ParseParameters
15:22 < promag> for instance, -connect
15:22 < cfields> sipa: well at minimum, i think we always want to be able to override the config
15:22 < cfields> and i think that always implies merging?
15:23 < sipa> cfields: multiargs don't get merged, they get appended
15:23 < promag> if it's multiarg then imo it's unique stable merge
15:24 -!- Guest86981 [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has quit [Ping timeout: 260 seconds]     
15:24 < sipa> i'm not convinced that for all options uniquifying is the right thing to do
15:24 < cfields> yea, ok...
15:24 < cfields> -addnode=127.0.0.1 -addnode=127.0.0.1
15:25 < cfields> i want 2 connections there
15:25 < promag> does that make sense?
15:25 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:25 < promag> if that's the case, GetUniqueArgs is the way to go?
15:26 < sipa> or just unique it in the wallet loading code
15:26 < sipa> at least if you're talking about 0.15
15:27 < promag> it's in 3 different places
15:29 < promag> the PR adds GetUniqueArgs and changes 3 occurencies of gArgs.GetArgs("-wallet")
15:29 < promag> and adds tests for GetUniqueArgs
16:00 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 248 seconds]     
16:04 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev     
16:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
16:12 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
16:30 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
16:31 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
16:38 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
16:38 < promag> sipa, cfields: what should GetArg("-foo") give when -foo=a -foo=b -foo=a? (for me last "a" takes effect even though it's duplicate)
16:38 < sipa> yes, that's intentional
16:39 < sipa> last option takes effect
16:39 < promag> but GetUniqueArgs("-foo") gives {"a", "b"} sgty?
16:42 < sipa> sure
17:05 -!- ayy1337|2 [~kvirc@110.140.15.24] has quit [Ping timeout: 255 seconds]     
17:06 < bitcoin-git> [bitcoin] promag opened pull request #10885: Prevent duplicate wallets (master...2017-07-prevent-duplicate-wallets) https://github.com/bitcoin/bitcoin/pull/10885
17:09 < promag> sipa: there you go
17:29 < Chris_Stewart_5> The CScript constructor in the python testing framework will add push ops for constants right? Or do I need to add them manually
17:44 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
17:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rwtshwbnjafkqstt] has quit [Quit: Connection closed for inactivity]     
17:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
17:49 -!- Orion3k [~Orion3k@47-51-33-228.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev     
17:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:51 < Chris_Stewart_5> nvm, dynamic typing got me.. 
17:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
17:57 -!- promag [~joao@bl22-247-244.dsl.telepac.pt] has quit [Quit: Leaving.]     
18:02 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]     
18:04 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
18:14 -!- roidster [~chatzilla@71-92-221-248.static.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.40/20160120202951]]     
18:14 -!- jamesob_ [~james@tempo-automation.static.monkeybrains.net] has quit [Ping timeout: 255 seconds]     
18:33 < bitcoin-git> [bitcoin] MeshCollider opened pull request #10886: Remove unused #define in sync.h (master...remove-unused-define) https://github.com/bitcoin/bitcoin/pull/10886
18:33 < bitcoin-git> [bitcoin] MeshCollider closed pull request #10886: Remove unused #define in sync.h (master...remove-unused-define) https://github.com/bitcoin/bitcoin/pull/10886
18:44 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:45 -!- _flow_ [flow@star.geekplace.eu] has quit [Ping timeout: 240 seconds]     
18:50 -!- rjak [~rjak@gateway/vpn/privateinternetaccess/rjak] has joined #bitcoin-core-dev     
18:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
18:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
19:12 -!- darawk [~textual@76.79.73.19] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
19:14 -!- _flow_ [flow@star.geekplace.eu] has joined #bitcoin-core-dev     
19:15 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
19:21 -!- arowser [~quassel@45.32.248.113] has quit [Remote host closed the connection]     
19:24 -!- jamesob_ [~james@73.241.180.136] has joined #bitcoin-core-dev     
20:01 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds]     
20:08 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds]     
20:08 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev     
20:10 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
20:10 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
20:49 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
20:52 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
20:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
20:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
21:17 -!- ayy1337|2 [~kvirc@110.140.15.24] has joined #bitcoin-core-dev     
21:53 -!- jtimon [~quassel@102.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
22:23 -!- proxyyy [b515532b@gateway/web/freenode/ip.181.21.83.43] has joined #bitcoin-core-dev     
22:23 -!- proxyyy [b515532b@gateway/web/freenode/ip.181.21.83.43] has quit [Client Quit]     
22:27 -!- darawk [~textual@2605:e000:1303:91:30ff:485:da03:d796] has joined #bitcoin-core-dev     
22:42 -!- jamesob_ [~james@73.241.180.136] has quit [Ping timeout: 255 seconds]     
23:13 -!- dev__ [~dev@120.6.105.139] has joined #bitcoin-core-dev     
23:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
23:24 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds]     
23:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nwxrfyssmvxpgriw] has joined #bitcoin-core-dev