12018-12-20T00:02:21 *** jarthur has quit IRC
22018-12-20T00:04:17 *** mileschet has joined #bitcoin-core-dev
32018-12-20T00:08:56 *** mileschet has quit IRC
42018-12-20T00:20:22 *** mileschet has joined #bitcoin-core-dev
52018-12-20T00:25:18 *** mileschet has quit IRC
62018-12-20T00:27:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
72018-12-20T00:28:19 <jnewbery> achow101: +1. I think we'd want to merge #13100 (and hence complete https://github.com/bitcoin/bitcoin/projects/2) before we enforced that
82018-12-20T00:28:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
92018-12-20T00:36:15 *** mileschet has joined #bitcoin-core-dev
102018-12-20T00:38:01 <sipa> jnewbery: (can't comment on github right now) i intentionally do not want to print private keys in error messages; they may be logged in places where they shouldn't
112018-12-20T00:41:37 *** mileschet has quit IRC
122018-12-20T00:42:09 *** checkinn has joined #bitcoin-core-dev
132018-12-20T00:47:33 *** checkinn has quit IRC
142018-12-20T00:52:02 *** mileschet has joined #bitcoin-core-dev
152018-12-20T00:53:12 *** Chris_Stewart_5 has quit IRC
162018-12-20T00:56:49 *** mileschet has quit IRC
172018-12-20T01:07:49 *** mileschet has joined #bitcoin-core-dev
182018-12-20T01:09:20 *** owowo has joined #bitcoin-core-dev
192018-12-20T01:09:38 *** jarthur has joined #bitcoin-core-dev
202018-12-20T01:11:01 *** rh0nj has quit IRC
212018-12-20T01:12:07 *** rh0nj has joined #bitcoin-core-dev
222018-12-20T01:12:38 *** mileschet has quit IRC
232018-12-20T01:15:27 *** shesek has quit IRC
242018-12-20T01:15:45 *** shesek has joined #bitcoin-core-dev
252018-12-20T01:24:00 *** mileschet has joined #bitcoin-core-dev
262018-12-20T01:28:51 *** mileschet has quit IRC
272018-12-20T01:39:44 *** mileschet has joined #bitcoin-core-dev
282018-12-20T01:42:04 *** michaelfolkson has joined #bitcoin-core-dev
292018-12-20T01:42:32 *** AaronvanW has quit IRC
302018-12-20T01:44:16 *** mileschet has quit IRC
312018-12-20T01:44:28 *** AaronvanW has joined #bitcoin-core-dev
322018-12-20T01:46:22 *** mileschet has joined #bitcoin-core-dev
332018-12-20T01:49:27 *** AaronvanW has quit IRC
342018-12-20T01:49:40 *** michaelfolkson has quit IRC
352018-12-20T01:51:07 *** mileschet has quit IRC
362018-12-20T01:55:02 *** michaelfolkson has joined #bitcoin-core-dev
372018-12-20T01:55:35 *** promag has joined #bitcoin-core-dev
382018-12-20T01:57:16 *** shesek has quit IRC
392018-12-20T01:57:34 *** shesek has joined #bitcoin-core-dev
402018-12-20T02:05:26 *** dviola has quit IRC
412018-12-20T02:05:42 *** alpalp has joined #bitcoin-core-dev
422018-12-20T02:05:42 *** alpalp has joined #bitcoin-core-dev
432018-12-20T02:06:17 *** ariard has joined #bitcoin-core-dev
442018-12-20T02:06:37 *** michaelfolkson has quit IRC
452018-12-20T02:08:29 <promag> jnewbery: #13100 branch locally has a pile of changes, maybe I should cut down to the minimum and improve on follow ups
462018-12-20T02:08:32 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
472018-12-20T02:14:37 <gwillen> I ran into an interesting wallet issue with multisig when trying to demo my offline signing work that's still ongoing
482018-12-20T02:14:44 *** e4xit has quit IRC
492018-12-20T02:15:03 <gwillen> which is that (1) there's no way to stop a wallet that I intend to use as only-watchonly from generating keys, and (2) spending from a multisig automatically sends change to those keys I didn't actually want generated
502018-12-20T02:15:37 <gwillen> I suspect that RPC users of multisig are already aware of this footgun and handle change manually, and I am planning to adopt "manual change address" as a stopgap for GUI use
512018-12-20T02:15:55 <gwillen> until we have descriptors which should hopefully solve this
522018-12-20T02:16:13 *** michaelfolkson has joined #bitcoin-core-dev
532018-12-20T02:16:17 <gwillen> but I'm going to push again for the idea that a given wallet ought to be either only-watchonly or non-watchonly
542018-12-20T02:16:40 <gwillen> and that mixing a local keypool into a transaction sending from not the local keypool is scary
552018-12-20T02:17:07 <gwillen> although I guess I asked for this kind of issue by tricking / cajoling the wallet into creating a transaction spending from a "solvable" but not "spendable" coin
562018-12-20T02:17:13 <gwillen> because what else should it do
572018-12-20T02:17:34 <sipa> gwillen: there is a recently introduced feature to make a wallet in no-private-keys mode
582018-12-20T02:18:35 <gwillen> ooh, beautiful, that sounds perfect for preventing this
592018-12-20T02:18:47 <gwillen> do you happen to know, if the wallet is called on to create change in that mode, what will it do? Just give up?
602018-12-20T02:19:13 <gwillen> (and how do I engage this mode)
612018-12-20T02:19:47 <sipa> i don't know; i'm currebtly flying, it's a bit hard to check :)
622018-12-20T02:19:54 <gwillen> (and does it make sense that I imagine descriptors will solve this, since if I'm spending from a given descriptor, that same descriptor or a related descriptor should be used to derive where change goes?)
632018-12-20T02:20:06 <gwillen> np, I'm about to head to dinner anyway, just wanted to start thinking about it
642018-12-20T02:21:38 <sipa> gwillen: no, you'll just have 2 specially designated descriptors in a wallet; one where receive addresses are drawn from, and one where change is drawn from
652018-12-20T02:22:00 <sipa> so yes, that's a solution by making change selection explicit and separate from the wallet's keys
662018-12-20T02:23:40 <gwillen> ok great, thanks for validating my hope that all my problems will be solved in the future
672018-12-20T02:24:05 <gwillen> I know I said that I didn't want to wait for descriptors, but actually the change problem means this is going to kind of suck without them
682018-12-20T02:24:22 <gwillen> it's going to have to be either manual change or address reuse
692018-12-20T02:24:50 *** promag has quit IRC
702018-12-20T02:25:30 <gwillen> do descriptors-as-envisioned have support for HD + multisig in some fashion?
712018-12-20T02:25:58 <sipa> ure
722018-12-20T02:26:00 <sipa> sure
732018-12-20T02:26:07 <gwillen> I assume it would be something like "2 of 3 of keys derived from X/Y/Z" and it automatically increments all three together, or something, when generating a new address?
742018-12-20T02:26:45 <gwillen> (the question also came up in conversation today of whether there is a good way to support multiple people generating addresses from the same keys e.g. the holders of a multisig, and not accidentally generating the same address)
752018-12-20T02:26:46 <sipa> yes... have you ever read the descriptors description (no pun intended)?
762018-12-20T02:26:54 <sipa> doc/descriptors.md in the repo
772018-12-20T02:26:55 <gwillen> (e.g. by letting them generate from different subpaths)
782018-12-20T02:27:00 <gwillen> ha, it's been awhile, I will reread, thanks
792018-12-20T02:27:51 <gwillen> ah yes, I see it specifically addresses this, cool
802018-12-20T02:28:06 <sipa> you can just say mukti(2,xpubpath/*,xpub/path/*,xpub/path/*) and it will expand to equal-last-index entries from the xpubs
812018-12-20T02:28:11 <sipa> *multi
822018-12-20T02:28:12 <gwillen> *nods*
832018-12-20T02:28:59 <gwillen> and I guess supporting multiple derivation paths would be easiest by just using multiple descriptors
842018-12-20T02:29:28 <gwillen> e.g. I have a wallet that has "my" descriptors that it uses to generate addresses, and "your" descriptors that it only uses to watch the chain, and it treats them both as "mine"
852018-12-20T02:29:39 <sipa> right
862018-12-20T02:29:44 <gwillen> (this is purely to prevent collisions if we're independently generating receive addresses to the same wallet)
872018-12-20T02:45:17 *** AaronvanW has joined #bitcoin-core-dev
882018-12-20T02:48:02 *** spinza has quit IRC
892018-12-20T02:50:08 *** AaronvanW has quit IRC
902018-12-20T02:50:25 *** alpalp has quit IRC
912018-12-20T02:59:42 *** mileschet has joined #bitcoin-core-dev
922018-12-20T03:03:17 *** spinza has joined #bitcoin-core-dev
932018-12-20T03:04:27 *** mileschet has quit IRC
942018-12-20T03:15:29 *** mileschet has joined #bitcoin-core-dev
952018-12-20T03:19:14 *** drexl has quit IRC
962018-12-20T03:20:28 *** mileschet has quit IRC
972018-12-20T03:23:40 *** mileschet has joined #bitcoin-core-dev
982018-12-20T03:26:55 <achow101> gwillen: createwallet has a disable private keys parameter so you can make a wallet without any privkeys
992018-12-20T03:28:13 *** mileschet has quit IRC
1002018-12-20T03:39:23 *** mileschet has joined #bitcoin-core-dev
1012018-12-20T03:39:31 <gwillen> achow101: thanks, I hadn't been using createwallet, I was just adding --wallet= and it created it for me
1022018-12-20T03:43:22 *** gkrizek has joined #bitcoin-core-dev
1032018-12-20T03:44:12 *** mileschet has quit IRC
1042018-12-20T03:57:23 *** michaelfolkson has quit IRC
1052018-12-20T03:59:05 *** bgibson has quit IRC
1062018-12-20T04:01:17 *** gkrizek has quit IRC
1072018-12-20T04:01:58 *** michaelfolkson has joined #bitcoin-core-dev
1082018-12-20T04:19:00 *** jimmysong has joined #bitcoin-core-dev
1092018-12-20T04:26:24 *** DougieBot5000 has quit IRC
1102018-12-20T04:37:57 *** CubicEarth has quit IRC
1112018-12-20T04:46:13 *** AaronvanW has joined #bitcoin-core-dev
1122018-12-20T04:51:31 *** AaronvanW has quit IRC
1132018-12-20T05:08:27 *** michaelfolkson has quit IRC
1142018-12-20T05:10:58 *** Cory has quit IRC
1152018-12-20T05:13:01 *** rh0nj has quit IRC
1162018-12-20T05:14:07 *** rh0nj has joined #bitcoin-core-dev
1172018-12-20T05:16:51 *** Pasha has joined #bitcoin-core-dev
1182018-12-20T05:18:49 *** gkrizek[m] has joined #bitcoin-core-dev
1192018-12-20T05:20:02 *** Pasha is now known as Cory
1202018-12-20T05:20:05 *** gkrizek has joined #bitcoin-core-dev
1212018-12-20T05:21:45 *** gkrizek[m] has left #bitcoin-core-dev
1222018-12-20T05:25:45 *** gkrizek has quit IRC
1232018-12-20T05:28:41 *** michaelfolkson has joined #bitcoin-core-dev
1242018-12-20T05:40:17 *** mileschet has joined #bitcoin-core-dev
1252018-12-20T05:44:47 *** mileschet has quit IRC
1262018-12-20T05:50:49 *** DougieBot5000 has joined #bitcoin-core-dev
1272018-12-20T05:54:30 *** michaelfolkson has quit IRC
1282018-12-20T05:56:29 *** mileschet has joined #bitcoin-core-dev
1292018-12-20T06:01:10 *** mileschet has quit IRC
1302018-12-20T06:07:18 *** aqk has quit IRC
1312018-12-20T06:07:55 *** aqk has joined #bitcoin-core-dev
1322018-12-20T06:08:06 *** gkrizek has joined #bitcoin-core-dev
1332018-12-20T06:08:11 *** danra has quit IRC
1342018-12-20T06:10:24 *** gkrizek has quit IRC
1352018-12-20T06:11:41 *** Murch has quit IRC
1362018-12-20T06:12:30 *** aqk has quit IRC
1372018-12-20T06:17:10 *** aqk has joined #bitcoin-core-dev
1382018-12-20T06:21:17 *** aqk has quit IRC
1392018-12-20T06:26:26 *** aqk has joined #bitcoin-core-dev
1402018-12-20T06:30:45 *** aqk has quit IRC
1412018-12-20T06:34:22 *** jarthur has quit IRC
1422018-12-20T06:35:38 *** aqk has joined #bitcoin-core-dev
1432018-12-20T06:41:14 *** gkrizek has joined #bitcoin-core-dev
1442018-12-20T06:45:58 *** gkrizek has quit IRC
1452018-12-20T06:48:40 *** AaronvanW has joined #bitcoin-core-dev
1462018-12-20T06:53:19 *** AaronvanW has quit IRC
1472018-12-20T06:54:37 *** Murch has joined #bitcoin-core-dev
1482018-12-20T06:57:51 *** gkrizek has joined #bitcoin-core-dev
1492018-12-20T07:00:27 *** gkrizek has quit IRC
1502018-12-20T07:03:23 *** gkrizek has joined #bitcoin-core-dev
1512018-12-20T07:06:07 *** gkrizek has quit IRC
1522018-12-20T07:06:25 *** gkrizek has joined #bitcoin-core-dev
1532018-12-20T07:22:54 *** grubles has quit IRC
1542018-12-20T07:31:43 *** promag has joined #bitcoin-core-dev
1552018-12-20T07:41:16 *** promag has quit IRC
1562018-12-20T07:47:50 *** phwalkr has joined #bitcoin-core-dev
1572018-12-20T07:56:54 *** aqk has quit IRC
1582018-12-20T07:57:21 *** mileschet has joined #bitcoin-core-dev
1592018-12-20T07:59:53 *** aqk has joined #bitcoin-core-dev
1602018-12-20T08:02:34 *** mileschet has quit IRC
1612018-12-20T08:04:07 *** aqk has quit IRC
1622018-12-20T08:09:08 *** aqk has joined #bitcoin-core-dev
1632018-12-20T08:14:24 *** mileschet has joined #bitcoin-core-dev
1642018-12-20T08:17:01 *** aqk has quit IRC
1652018-12-20T08:17:57 *** hebasto has joined #bitcoin-core-dev
1662018-12-20T08:18:57 *** mileschet has quit IRC
1672018-12-20T08:21:02 *** EagleTM has joined #bitcoin-core-dev
1682018-12-20T08:21:46 *** dviola has joined #bitcoin-core-dev
1692018-12-20T08:25:49 *** mileschet has joined #bitcoin-core-dev
1702018-12-20T08:27:44 *** aqk has joined #bitcoin-core-dev
1712018-12-20T08:30:44 *** mileschet has quit IRC
1722018-12-20T08:31:47 *** aqk has quit IRC
1732018-12-20T08:35:35 *** mileschet has joined #bitcoin-core-dev
1742018-12-20T08:40:07 *** mileschet has quit IRC
1752018-12-20T08:46:44 *** aqk has joined #bitcoin-core-dev
1762018-12-20T08:49:26 *** AaronvanW has joined #bitcoin-core-dev
1772018-12-20T08:50:47 *** aqk has quit IRC
1782018-12-20T08:51:20 *** mileschet has joined #bitcoin-core-dev
1792018-12-20T08:53:47 *** AaronvanW has quit IRC
1802018-12-20T08:56:17 *** mileschet has quit IRC
1812018-12-20T09:01:53 *** setpill has joined #bitcoin-core-dev
1822018-12-20T09:07:39 *** kabaum has quit IRC
1832018-12-20T09:14:02 *** mileschet has joined #bitcoin-core-dev
1842018-12-20T09:15:01 *** rh0nj has quit IRC
1852018-12-20T09:16:08 *** rh0nj has joined #bitcoin-core-dev
1862018-12-20T09:23:00 *** kabaum has joined #bitcoin-core-dev
1872018-12-20T09:25:47 *** ken2812221 has joined #bitcoin-core-dev
1882018-12-20T09:27:55 *** timothy has joined #bitcoin-core-dev
1892018-12-20T09:34:17 *** jungly has joined #bitcoin-core-dev
1902018-12-20T09:36:24 *** aqk has joined #bitcoin-core-dev
1912018-12-20T09:41:12 *** aqk has quit IRC
1922018-12-20T09:48:54 *** cluelessperson has quit IRC
1932018-12-20T09:52:42 *** cluelessperson has joined #bitcoin-core-dev
1942018-12-20T10:04:10 *** aqk has joined #bitcoin-core-dev
1952018-12-20T10:08:14 <meshcollider> Is there a meeting tomorrow or not due to Christmas?
1962018-12-20T10:08:28 <meshcollider> Today* for some of you in incorrect timezones
1972018-12-20T10:10:24 *** aqk has quit IRC
1982018-12-20T10:15:41 *** aqk has joined #bitcoin-core-dev
1992018-12-20T10:18:08 <sipa> meetings are cancelled for the holidays i think
2002018-12-20T10:18:36 *** cluelessperson has quit IRC
2012018-12-20T10:20:10 *** aqk has quit IRC
2022018-12-20T10:23:02 *** cluelessperson has joined #bitcoin-core-dev
2032018-12-20T10:25:38 *** danra has joined #bitcoin-core-dev
2042018-12-20T10:30:21 *** JIZHANHUANG has joined #bitcoin-core-dev
2052018-12-20T10:32:22 *** JIZHANHUANG has quit IRC
2062018-12-20T10:34:03 *** aqk has joined #bitcoin-core-dev
2072018-12-20T10:34:51 *** dviola has quit IRC
2082018-12-20T10:35:48 <meshcollider> Ok
2092018-12-20T10:37:51 *** rh0nj has quit IRC
2102018-12-20T10:38:06 *** rh0nj has joined #bitcoin-core-dev
2112018-12-20T10:38:34 *** aqk has quit IRC
2122018-12-20T10:42:58 *** Murch has quit IRC
2132018-12-20T10:46:48 *** promag has joined #bitcoin-core-dev
2142018-12-20T10:50:13 *** AaronvanW has joined #bitcoin-core-dev
2152018-12-20T10:50:50 *** spinza has quit IRC
2162018-12-20T10:52:28 <provoostenator> I still don't like that -wallet automatically creates a new wallet.
2172018-12-20T10:52:32 *** aqk has joined #bitcoin-core-dev
2182018-12-20T10:52:51 <promag> provoostenator: why?
2192018-12-20T10:53:13 <provoostenator> Because of the confusion gwillen described, but also because a typo leads to a new wallet.
2202018-12-20T10:53:25 <provoostenator> E.g. forgetting to add ".dat"
2212018-12-20T10:53:42 <promag> the same typo can happen in createwallet rpc?
2222018-12-20T10:54:08 *** spinza has joined #bitcoin-core-dev
2232018-12-20T10:54:15 <provoostenator> The problem is when you're trying to open an existing wallet and instead it creates a new one.
2242018-12-20T10:54:38 *** AaronvanW has quit IRC
2252018-12-20T10:55:06 <promag> ah
2262018-12-20T10:55:21 <provoostenator> The behavior made sense before we had dynamic wallet loading support, but I think it could be deprecated now, e.g. initially with a warning "In the future, use createwallet to create a new wallet"
2272018-12-20T10:56:14 <promag> provoostenator: we need #13100 first
2282018-12-20T10:56:17 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
2292018-12-20T10:56:46 *** aqk has quit IRC
2302018-12-20T10:56:50 <promag> but I think that's reasonable
2312018-12-20T10:57:20 <promag> provoostenator: another alternative is to create wallet if -wallet is specified on the command line
2322018-12-20T10:57:28 <promag> -wallet on the config only loads?
2332018-12-20T10:58:28 <promag> otoh, if you want to launch a container and create a wallet xxx how would you do it?
2342018-12-20T11:00:28 <promag> for instance, postgres docker image has an entrypoint that initializes the database on the first run, and in that script it waits for the server to be available to execute the init sql
2352018-12-20T11:01:48 <promag> deprecate -wallet and add both -createwallet and -loadwallet
2362018-12-20T11:05:40 <provoostenator> Getting 13100 in makes sense for the GUI, but creating new wallets is "advanced" enough in my opinion that we can ask users to use the RPC console for that. But let's just get it merged.
2372018-12-20T11:06:05 <provoostenator> Not a fan of making commandline behavior different from config file.
2382018-12-20T11:06:55 <provoostenator> Interesting point about doing things on first.
2392018-12-20T11:06:58 <provoostenator> lad
2402018-12-20T11:06:59 <provoostenator> load
2412018-12-20T11:07:25 <provoostenator> That's a genertic problem though, most RPC operations don't immediately work. We could add a "wait_for_rpc_to_wake_up" ish call.
2422018-12-20T11:08:27 <provoostenator> The last time I had to deal with that issue I just polled until it stopped throwing errors :-)
2432018-12-20T11:09:04 <gmaxwell> we have a longstanding request to only create wallets when either told to encrypt OR when asked for an address.
2442018-12-20T11:09:31 <gmaxwell> As this would fix the problem of an unencrypted wallet being created first and ending up with a bunch of unused retired keys in it when you encrypt.
2452018-12-20T11:10:09 <gmaxwell> also solves the problem where the user starts up, backs up their wallet, then encrypts .... and doesn't backup again, and their backup is no good. (solves it because there wouldn't be a wallet file to backup at that point)
2462018-12-20T11:10:16 <provoostenator> There's that issue too. It could be solved by adding a password argument to createwallet.
2472018-12-20T11:10:27 <provoostenator> However that doesn't handle the default wallet case.
2482018-12-20T11:10:38 <gmaxwell> there shouldn't be a default wallet, is what I'm saying
2492018-12-20T11:10:52 <gmaxwell> one should get created on demand.
2502018-12-20T11:11:03 *** aqk has joined #bitcoin-core-dev
2512018-12-20T11:11:15 <gmaxwell> We tried to make the change previously but prior to dynamic wallet support it wasn't easy to implement, it probably is now.
2522018-12-20T11:11:18 <provoostenator> Ah yes, then the entire problem goes away. RPC methods that expect a wallet would just throw "create wallet first", and the GUI would have to be smart enough to create a wallet just in time.
2532018-12-20T11:11:39 <gmaxwell> Right.
2542018-12-20T11:12:09 <gmaxwell> and it would also improve the problem that developers get where you end up with 50 wallet files and aren't sure which of them you can throw away. :P
2552018-12-20T11:12:42 <provoostenator> That indeed seems doable once 13100 is in. promag: when rebase? :-)
2562018-12-20T11:12:56 <sipa> december 23rd seems like a good date to get rid of openssl: https://www.openssl.org/blog/blog/2018/12/20/20years/
2572018-12-20T11:13:05 <gmaxwell> and yes, indeed, create should be able to take a passphrase so that a wallet can be born encrypted.
2582018-12-20T11:13:17 <sipa> gmaxwell: there is a PR for that
2592018-12-20T11:13:31 <sipa> #15006
2602018-12-20T11:13:32 <promag> provoostenator: it will be your xmas gift :D
2612018-12-20T11:13:33 <gribble> https://github.com/bitcoin/bitcoin/issues/15006 | Add option to create an encrypted wallet by achow101 · Pull Request #15006 · bitcoin/bitcoin · GitHub
2622018-12-20T11:14:02 <provoostenator> promag: awesome. I'm fine with the idea of splitting the prerequisite stuff out of it, but I also think the PR is small enough to review as a whole.
2632018-12-20T11:14:19 <provoostenator> However, splitting some stuff out keeps the UI bikeshedding seperate.
2642018-12-20T11:15:24 *** aqk has quit IRC
2652018-12-20T11:16:08 <gmaxwell> sipa: ack on openssl.
2662018-12-20T11:29:49 *** aqk has joined #bitcoin-core-dev
2672018-12-20T11:34:46 *** aqk has quit IRC
2682018-12-20T11:38:58 *** aqk has joined #bitcoin-core-dev
2692018-12-20T11:43:34 *** aqk has quit IRC
2702018-12-20T11:47:21 *** igitoor20 has joined #bitcoin-core-dev
2712018-12-20T11:48:18 *** aqk has joined #bitcoin-core-dev
2722018-12-20T11:51:31 *** AaronvanW has joined #bitcoin-core-dev
2732018-12-20T11:52:40 *** aqk has quit IRC
2742018-12-20T11:52:43 *** danra has quit IRC
2752018-12-20T11:53:56 *** Aaronvan_ has joined #bitcoin-core-dev
2762018-12-20T11:56:37 *** AaronvanW has quit IRC
2772018-12-20T11:56:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2782018-12-20T11:57:26 *** AaronvanW has joined #bitcoin-core-dev
2792018-12-20T11:57:32 *** aqk has joined #bitcoin-core-dev
2802018-12-20T12:00:09 *** Aaronvan_ has quit IRC
2812018-12-20T12:01:47 *** aqk has quit IRC
2822018-12-20T12:06:52 *** aqk has joined #bitcoin-core-dev
2832018-12-20T12:07:46 *** jbarcelo has joined #bitcoin-core-dev
2842018-12-20T12:11:07 *** aqk has quit IRC
2852018-12-20T12:16:08 *** jbarcelo has quit IRC
2862018-12-20T12:24:22 <promag> btw, I think all wallets commands should have the passphrase argument
2872018-12-20T12:25:17 *** aqk has joined #bitcoin-core-dev
2882018-12-20T12:25:27 <promag> i mean, why would a wallet be unencrypted for others for a short period of time?
2892018-12-20T12:28:16 <wumpus> agree
2902018-12-20T12:29:07 <wumpus> making it possible to have wallet 'born encrypted' was one of the goals of multiwallet
2912018-12-20T12:29:30 *** aqk has quit IRC
2922018-12-20T12:33:22 *** murrayn has quit IRC
2932018-12-20T12:34:44 *** aqk has joined #bitcoin-core-dev
2942018-12-20T12:38:11 <wumpus> oh, you mean actually *passing the passphrase argument* for unlocking for every command... neutral on that, I guess with named arguments it's somewhat less of a hassle now than before. I think there's something to be said for the current time-locked functionalit as well as it means not all wallet-using commands have to know the passphrase.
2952018-12-20T12:39:10 <wumpus> now it could be some separate process that unlocks periodically, or when necessary; imagine the client code having to pass through the passphrase everywhere
2962018-12-20T12:40:27 *** aqk has quit IRC
2972018-12-20T12:43:54 *** mileschet has quit IRC
2982018-12-20T12:45:59 *** aqk has joined #bitcoin-core-dev
2992018-12-20T12:50:19 *** aqk has quit IRC
3002018-12-20T12:50:59 *** Deinogalerix21 has joined #bitcoin-core-dev
3012018-12-20T12:51:15 <gmaxwell> I think it would be interesting to support, but it would not be very usable to use that way normally.
3022018-12-20T12:54:07 *** Deinogalerix21 has quit IRC
3032018-12-20T12:55:18 *** aqk has joined #bitcoin-core-dev
3042018-12-20T12:58:24 *** owowo has quit IRC
3052018-12-20T12:58:28 *** cluelessperson has quit IRC
3062018-12-20T12:59:53 *** aqk has quit IRC
3072018-12-20T13:00:00 *** Chris_Stewart_5 has quit IRC
3082018-12-20T13:01:33 <promag> wumpus: gmaxwell: I think we could support unlock per connection only
3092018-12-20T13:01:46 *** cluelessperson has joined #bitcoin-core-dev
3102018-12-20T13:01:53 *** alpalp has joined #bitcoin-core-dev
3112018-12-20T13:01:53 *** alpalp has joined #bitcoin-core-dev
3122018-12-20T13:02:44 <promag> so the connection would hold the wallet lock and so no other connections could interact with that wallet
3132018-12-20T13:03:12 <wumpus> connection specific state really breaks the http abstraction
3142018-12-20T13:03:29 <promag> meaning that the wallet could stay unencrypted
3152018-12-20T13:03:43 <wumpus> I also don't see why multiple connections wouldn't be allowed to interact with a wallet, this is something for the external software to coordinate!
3162018-12-20T13:03:47 <promag> wumpus: for rest yes, but does that hold for rpc?
3172018-12-20T13:04:28 <promag> wumpus: and then there is also batch
3182018-12-20T13:04:39 <wumpus> I know, but I don't really like it
3192018-12-20T13:04:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3202018-12-20T13:05:42 <wumpus> a) connections time out, so there'd need to be some hack to keep them open to prevent locking the wallet b) I remember convention is that a connection is closed when there is *any* http error
3212018-12-20T13:06:01 <wumpus> for another RPC protocol it might be acceptable, but http just isn't suited to what you want to do
3222018-12-20T13:06:05 *** hebasto has quit IRC
3232018-12-20T13:06:30 <wumpus> bolting it on in a bitcoin specific way seems a bad idea
3242018-12-20T13:06:41 *** owowo has joined #bitcoin-core-dev
3252018-12-20T13:07:45 <promag> I just think walletpassphrase is bad
3262018-12-20T13:07:47 <wumpus> client libraries likely won't have fine-grained control what to send over one conection
3272018-12-20T13:08:00 <promag> it's like doing sudo xxx and then everyone on the system has sudo
3282018-12-20T13:08:14 <wumpus> well RPC supports multiple users now
3292018-12-20T13:08:28 <gmaxwell> promag: being able to send a passphrase that applies to a single call, and only that call, wouldn't have that effect.
3302018-12-20T13:08:35 <wumpus> could use that if you want to restrict the scope of an unlock...
3312018-12-20T13:09:00 <wumpus> that at least is completely compatible with how authentication is used normall...
3322018-12-20T13:09:25 *** hebasto has joined #bitcoin-core-dev
3332018-12-20T13:09:44 <promag> we could send the passphrase as a query parameter (in the URL)?
3342018-12-20T13:09:53 <wumpus> though I don't really like more and more 'business rule' kind of functionality leaking into bitcoin core, it reminds me a bit of the account stuff, it's so specific on your applciation
3352018-12-20T13:09:57 <wumpus> nooOOOO
3362018-12-20T13:10:02 <wumpus> never embed passwords in URLs
3372018-12-20T13:10:04 <wumpus> never
3382018-12-20T13:10:15 *** Chris_Stewart_5 has quit IRC
3392018-12-20T13:10:50 <gmaxwell> Whats wrong with making walletpassphrase an automatic named argument to _every_ rpc, and if the rpc can make use of the passprase, they use it... without unlocking.
3402018-12-20T13:11:06 <gmaxwell> so then you can authenticate single sends without opening anything up.
3412018-12-20T13:11:21 <gmaxwell> and without any kind of crazy connection-session state.
3422018-12-20T13:11:21 <wumpus> yes
3432018-12-20T13:11:35 <promag> gmaxwell: just fine!
3442018-12-20T13:11:54 <promag> so we would add customer support to each RPC
3452018-12-20T13:11:56 <wumpus> as said I'm neutral on that
3462018-12-20T13:12:01 *** cluelessperson has quit IRC
3472018-12-20T13:12:04 <gmaxwell> I think probably I would use that... provide the phassphrase on signrawtransaction/etc. and not otherwise.
3482018-12-20T13:12:06 <promag> s/customer/custom
3492018-12-20T13:12:48 <gmaxwell> promag: well I think the way we'd do that is with a utility function for rpcs that need an unlock, that checks if its already unlocked or otherwise gets access to it via the passphrase in the argument.
3502018-12-20T13:13:02 <gmaxwell> (and otherwise fails)
3512018-12-20T13:13:15 <promag> ok
3522018-12-20T13:13:29 <promag> so concept ACK?
3532018-12-20T13:13:57 *** aqk has joined #bitcoin-core-dev
3542018-12-20T13:13:57 <gmaxwell> there are only a couple RPCs that can make use of unlocking (the send, sign, dump ones).
3552018-12-20T13:14:01 <wumpus> you should ask the wallet maintainer :)
3562018-12-20T13:14:17 *** mileschet has joined #bitcoin-core-dev
3572018-12-20T13:14:27 <promag> this way no one would be able to "steal" from a wallet in that short period of time
3582018-12-20T13:14:39 <wumpus> agree
3592018-12-20T13:14:48 <promag> meshcollider: ^
3602018-12-20T13:15:07 <gmaxwell> promag: yes, it would reduce exposure slightly... though god knows we probably have an RCE burried in some RPC. :P
3612018-12-20T13:15:19 <promag> RCE?
3622018-12-20T13:15:21 *** cluelessperson has joined #bitcoin-core-dev
3632018-12-20T13:15:30 <gmaxwell> remote code execution (bug).
3642018-12-20T13:16:01 <promag> huh, do you even consider that?
3652018-12-20T13:16:34 <gmaxwell> promag: I mean the addition of this would not change that I would recommend against letting the rpc be used by less trusted parties.
3662018-12-20T13:16:53 <wumpus> well you're afraid of local users, *with* credentials, and access to the RPC, stealing funds; then you're regarding the RPC as a hardened interface
3672018-12-20T13:17:03 <promag> oh right
3682018-12-20T13:17:12 <gmaxwell> The thing I like about the passphrase argument approach is that it's also quite compatible with cli usage... so it will be used, not just some vague enterprise feature which may or may not get used and we won't get feedback about it. :)
3692018-12-20T13:17:20 <promag> I just think walletpassphrase as a global switch is a bad concept
3702018-12-20T13:17:39 <gmaxwell> promag: also txfee is another 'global' thing which could be scoped this same way.
3712018-12-20T13:17:44 <promag> agree
3722018-12-20T13:18:01 <gmaxwell> I don't believe there are any others re wallet behavior?
3732018-12-20T13:18:19 *** aqk has quit IRC
3742018-12-20T13:18:40 <gmaxwell> FWIW, GUI will also prompt on demand and not leave things unlocked.
3752018-12-20T13:19:07 *** mileschet has quit IRC
3762018-12-20T13:19:11 <promag> good point
3772018-12-20T13:19:19 <gmaxwell> promag: the main utility of the time based unlock is this use case: You have an online hot wallet, you want if the daemon gets shut off that you have to log in and unlock it again yourself.
3782018-12-20T13:20:19 <gmaxwell> promag: it turns out that in a significant percentage of commercial system compromises we've heard reported (maybe a majority), someone gets remote access but causes a reboot in the process. (e.g. by getting into a server admin console, or convincing remote hands to change the root password).
3792018-12-20T13:20:29 <wumpus> it allows for some separateion of concerns; in any case your idea wouldn't replace it
3802018-12-20T13:20:42 <gmaxwell> So several big users have had their bacon saved by that setup.
3812018-12-20T13:21:09 <gmaxwell> but its okay we could continue to support both ways of using it.
3822018-12-20T13:21:09 <wumpus> I'm ok with the pass-a-passphrase as an option, but not deprecating the old behavior
3832018-12-20T13:21:15 <promag> I see
3842018-12-20T13:21:21 <gmaxwell> (thats why I'm explaining that usage)
3852018-12-20T13:21:44 <wumpus> it also feels like changing things just to change them, just because you don't like it, all users have to change their usage
3862018-12-20T13:22:07 <gmaxwell> In an ideal world, I think it would even be best if that usage had two stages of authorization--- a startup key and a usage key, but I think we shouldn't worry about that for now and leave improvements like that to external key handling processes.
3872018-12-20T13:22:21 <promag> one time usage key yes
3882018-12-20T13:23:07 *** aqk has joined #bitcoin-core-dev
3892018-12-20T13:23:40 <promag> I'm working on #13100 and then maybe I'll try adding the passphrase to some RPC
3902018-12-20T13:23:44 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
3912018-12-20T13:24:10 <promag> thanks guys
3922018-12-20T13:24:40 <wumpus> np
3932018-12-20T13:25:02 <gmaxwell> FWIW, the way I often recommend people use walletpassphrase is with a really dumb key (say like "password") that they could never forget... just so they can feel more confident using their wallet without worrying that they'll accidentally send funds somewhere.
3942018-12-20T13:25:53 *** promag has quit IRC
3952018-12-20T13:26:24 <wumpus> makes sense
3962018-12-20T13:27:25 *** aqk has quit IRC
3972018-12-20T13:41:45 *** aqk has joined #bitcoin-core-dev
3982018-12-20T13:46:12 *** aqk has quit IRC
3992018-12-20T13:50:56 *** aqk has joined #bitcoin-core-dev
4002018-12-20T13:52:43 *** alpalp has quit IRC
4012018-12-20T13:53:54 *** hebasto_ has joined #bitcoin-core-dev
4022018-12-20T13:53:56 *** hebasto has quit IRC
4032018-12-20T13:55:07 *** aqk has quit IRC
4042018-12-20T13:57:57 *** spinza has quit IRC
4052018-12-20T13:59:18 *** ap4lmtree- has joined #bitcoin-core-dev
4062018-12-20T13:59:34 *** ken2812221 has quit IRC
4072018-12-20T13:59:54 *** ap4lmtree- has quit IRC
4082018-12-20T14:02:17 *** ap4lmtree has quit IRC
4092018-12-20T14:08:15 *** spinza has joined #bitcoin-core-dev
4102018-12-20T14:09:37 *** aqk has joined #bitcoin-core-dev
4112018-12-20T14:14:02 *** aqk has quit IRC
4122018-12-20T14:15:17 *** mileschet has joined #bitcoin-core-dev
4132018-12-20T14:16:51 *** owowo has quit IRC
4142018-12-20T14:19:09 *** danra_ has joined #bitcoin-core-dev
4152018-12-20T14:21:13 *** owowo has joined #bitcoin-core-dev
4162018-12-20T14:27:30 *** ap4lmtree has joined #bitcoin-core-dev
4172018-12-20T14:42:03 *** Guyver2 has joined #bitcoin-core-dev
4182018-12-20T14:55:02 *** rh0nj has quit IRC
4192018-12-20T14:56:08 *** rh0nj has joined #bitcoin-core-dev
4202018-12-20T14:56:10 <jnewbery> wumpus: https://github.com/bitcoin-core/univalue/pull/17 has three ACKs. May be ready for merge?
4212018-12-20T14:58:47 *** shesek has quit IRC
4222018-12-20T14:59:36 <jnewbery> sipa: ACK not printing private keys in error messages. You're right that it's a terrible idea.
4232018-12-20T15:00:22 <jnewbery> More generally, my review comments about improving error messages were mostly meant as notes for me or anyone else who wants to do a follow-up PR to improve error messages and testing. I don't think they need to change in your PR.
4242018-12-20T15:02:15 *** setpill has quit IRC
4252018-12-20T15:20:02 *** shesek has joined #bitcoin-core-dev
4262018-12-20T15:24:09 *** shesek has quit IRC
4272018-12-20T15:24:28 *** shesek has joined #bitcoin-core-dev
4282018-12-20T15:24:28 *** shesek has joined #bitcoin-core-dev
4292018-12-20T15:36:41 *** shesek has quit IRC
4302018-12-20T15:36:52 *** drexl has joined #bitcoin-core-dev
4312018-12-20T15:37:18 *** shesek has joined #bitcoin-core-dev
4322018-12-20T15:51:00 *** mileschet has quit IRC
4332018-12-20T15:54:32 *** olo has joined #bitcoin-core-dev
4342018-12-20T15:55:25 *** olo has quit IRC
4352018-12-20T16:08:50 *** mileschet has joined #bitcoin-core-dev
4362018-12-20T16:09:33 *** jarthur has joined #bitcoin-core-dev
4372018-12-20T16:13:48 *** mileschet has quit IRC
4382018-12-20T16:20:26 *** bitcoin-git has joined #bitcoin-core-dev
4392018-12-20T16:20:27 <bitcoin-git> [bitcoin] jnewbery opened pull request #15010: [wallet] Fix getbalance with minconf (master...fix_getbalance_with_minconf) https://github.com/bitcoin/bitcoin/pull/15010
4402018-12-20T16:20:27 *** bitcoin-git has left #bitcoin-core-dev
4412018-12-20T16:27:47 *** harrymm has quit IRC
4422018-12-20T16:30:05 <provoostenator> Tangential to adding wallet password to RPC calls, I'd like a way to enter said password in a way that doesn't end up in bash history (there might already be a PR for that).
4432018-12-20T16:30:28 <provoostenator> That would be a change at the bitcoin-cli level.
4442018-12-20T16:31:48 <timothy> provoostenator: it's not a problem of bitcoin-cli, you cannot disable history in called command
4452018-12-20T16:31:54 *** grubles has joined #bitcoin-core-dev
4462018-12-20T16:32:05 <timothy> you can do: unset HISTFILE before using a command that includes the password
4472018-12-20T16:32:38 <timothy> (bitcoin-cli already have -stdin)
4482018-12-20T16:32:43 <wumpus> yes, private keys in error messages is almost as bad as private keys in the log (as the client application will most likely log them)
4492018-12-20T16:33:33 <provoostenator> timothy: bitcoin-cli could prompt for a password rather than expecting it as an argument
4502018-12-20T16:33:59 <timothy> provoostenator: you can pass it by using -stdin option
4512018-12-20T16:34:02 <gmaxwell> provoostenator: you can tell bash to not save any line that begins with a space or has certian strings in it.
4522018-12-20T16:34:08 <gmaxwell> (or use -stdin)
4532018-12-20T16:38:16 <provoostenator> I didn't know about stdin. That's useful indeed, might be worth mentioning in the walletpassphrase RPC help.
4542018-12-20T16:42:18 *** profmac has quit IRC
4552018-12-20T16:48:50 *** mileschet has joined #bitcoin-core-dev
4562018-12-20T16:52:25 *** gkrizek has quit IRC
4572018-12-20T16:52:50 *** gkrizek has joined #bitcoin-core-dev
4582018-12-20T16:53:48 *** mileschet has quit IRC
4592018-12-20T16:54:31 *** bitcoin-git has joined #bitcoin-core-dev
4602018-12-20T16:54:32 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14932: ui: Warn the user on file corruption in mempool.dat (master...Mf1812-testFileCorruption) https://github.com/bitcoin/bitcoin/pull/14932
4612018-12-20T16:54:32 *** bitcoin-git has left #bitcoin-core-dev
4622018-12-20T16:58:44 *** bitcoin-git has joined #bitcoin-core-dev
4632018-12-20T16:58:44 <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb52cee29d0d...86e0a33f5c38
4642018-12-20T16:58:45 <bitcoin-git> bitcoin/master e982f0b andrewtoth: Add all category options to wallet rpc help
4652018-12-20T16:58:45 <bitcoin-git> bitcoin/master f3f6dde andrewtoth: Test coinbase category in wallet rpcs
4662018-12-20T16:58:46 <bitcoin-git> bitcoin/master 86e0a33 MarcoFalke: Merge #14653: rpcwallet: Add missing transaction categories to rpc helptexts...
4672018-12-20T16:58:46 *** bitcoin-git has left #bitcoin-core-dev
4682018-12-20T16:59:18 *** bitcoin-git has joined #bitcoin-core-dev
4692018-12-20T16:59:18 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #14653: rpcwallet: Add missing transaction categories to rpc helptexts (master...listtransactions-help) https://github.com/bitcoin/bitcoin/pull/14653
4702018-12-20T16:59:18 *** bitcoin-git has left #bitcoin-core-dev
4712018-12-20T17:02:49 *** EagleTM has quit IRC
4722018-12-20T17:11:27 <moneyball> We have one proposed topic for today's meeting https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a
4732018-12-20T17:14:00 <gmaxwell> I thought the meetings were all canceled.
4742018-12-20T17:15:21 <gmaxwell> like every meeting everwhere. (is this why US markets are at a 52 week low? :P you'd think the end of meetings and their overheads would be a boon to the GDP...)
4752018-12-20T17:21:21 <moneyball> ah indeed, i see sipa mentioned that now.
4762018-12-20T17:23:38 *** laptop__ has joined #bitcoin-core-dev
4772018-12-20T17:23:48 <sipa> i doubt i'll be awake in 1.5h in any case
4782018-12-20T17:29:08 *** mileschet has joined #bitcoin-core-dev
4792018-12-20T17:34:10 *** mileschet has quit IRC
4802018-12-20T17:38:46 <achow101> gmaxwell: I'm not sure that creating the wallet on use is possible even with multiwallet. however getting rid of the default wallet and forcing the user to just make a wallet themselves certainly is
4812018-12-20T17:39:05 <achow101> I'm planning on implementing the latter, as the former looks to be fairly complicated and fragile
4822018-12-20T17:48:03 *** owowo has quit IRC
4832018-12-20T17:55:51 *** CodeBlue1776 has quit IRC
4842018-12-20T17:55:55 <sipa> achow101, gmaxwell: one possibility is creating a dummy CWallet object for freshly created wallets initially, without file to back it, and the only materializing it on firet use
4852018-12-20T17:56:23 *** CodeBlue1776 has joined #bitcoin-core-dev
4862018-12-20T18:18:08 *** Murch has joined #bitcoin-core-dev
4872018-12-20T18:21:12 *** CodeBlue1776 has quit IRC
4882018-12-20T18:21:30 *** CodeBlue1776 has joined #bitcoin-core-dev
4892018-12-20T18:24:00 *** dqx has joined #bitcoin-core-dev
4902018-12-20T18:26:11 *** Squidicuz has joined #bitcoin-core-dev
4912018-12-20T18:26:23 *** Squidi has quit IRC
4922018-12-20T18:33:53 *** Csus has joined #bitcoin-core-dev
4932018-12-20T18:34:53 <Csus> Hi - I'm trying to setup a full node on Raspberry pi. ./configure CPPFLAGS="-I/usr/local/BerkeleyDB.5.3/include -O2" LDFLAGS="-L/usr/local/BerkeleyDB.5.3/lib" --enable-upnp-default
4942018-12-20T18:35:23 <Csus> After inserting this command I get error - "configure: error: C++ compiler cannot create executables"
4952018-12-20T18:35:46 <Csus> Any ideas?
4962018-12-20T18:51:00 *** Bullit has quit IRC
4972018-12-20T18:53:28 *** chenpo has joined #bitcoin-core-dev
4982018-12-20T18:55:53 *** clarkmoody has joined #bitcoin-core-dev
4992018-12-20T18:57:01 *** rh0nj has quit IRC
5002018-12-20T18:58:08 *** rh0nj has joined #bitcoin-core-dev
5012018-12-20T18:59:24 <wumpus> Csus: so, can your c++ compiler create executables? does g++ work?
5022018-12-20T19:00:10 <wumpus> #startmeeting
5032018-12-20T19:00:10 <lightningbot> Meeting started Thu Dec 20 19:00:10 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
5042018-12-20T19:00:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5052018-12-20T19:00:33 <jonasschnelli> hi
5062018-12-20T19:00:34 <achow101> i thought there was no meeting?
5072018-12-20T19:00:37 <jnewbery> hi
5082018-12-20T19:00:41 <wumpus> achow101: oh?
5092018-12-20T19:01:05 <chenpo> I also thought that there is no meeting today.
5102018-12-20T19:01:17 <wumpus> short meeting then :<
5112018-12-20T19:01:23 <jonasschnelli> why?
5122018-12-20T19:01:28 <achow101> <meshcollider> Is there a meeting tomorrow or not due to Christmas?
5132018-12-20T19:01:29 <achow101> <meshcollider> Today* for some of you in incorrect timezones
5142018-12-20T19:01:29 <achow101> <sipa> meetings are cancelled for the holidays i think
5152018-12-20T19:01:38 <achow101> ^from earlier
5162018-12-20T19:02:14 <jonasschnelli> I though christmas is 24th onwards.
5172018-12-20T19:02:17 <jonasschnelli> *thought
5182018-12-20T19:02:27 <wumpus> I'm confused isn't xmas next week and on?
5192018-12-20T19:02:31 <wumpus> right-
5202018-12-20T19:02:54 <wumpus> I missed meshcollider's messages
5212018-12-20T19:03:18 <wumpus> so no meeting this week and next?
5222018-12-20T19:03:37 <achow101> i guess we can still have a meeting, just missing some people
5232018-12-20T19:04:03 <wumpus> that's not really fair if people were under the impression that there would be none
5242018-12-20T19:04:39 <jonasschnelli> agree
5252018-12-20T19:04:58 <wumpus> see you at next meeting Thu 3 2019 then
5262018-12-20T19:05:02 <wumpus> #endmeeting
5272018-12-20T19:05:02 <lightningbot> Meeting ended Thu Dec 20 19:05:02 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5282018-12-20T19:05:02 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-20-19.00.html
5292018-12-20T19:05:02 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-20-19.00.txt
5302018-12-20T19:05:02 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-12-20-19.00.log.html
5312018-12-20T19:05:30 <kanzure> womp womp
5322018-12-20T19:09:02 *** clarkmoody has quit IRC
5332018-12-20T19:24:58 *** alpalp has joined #bitcoin-core-dev
5342018-12-20T19:30:03 *** mileschet has joined #bitcoin-core-dev
5352018-12-20T19:31:12 *** lnostdal has quit IRC
5362018-12-20T19:35:09 *** mileschet has quit IRC
5372018-12-20T19:42:30 *** lnostdal has joined #bitcoin-core-dev
5382018-12-20T19:47:44 *** chenpo has quit IRC
5392018-12-20T19:49:39 *** chenpo has joined #bitcoin-core-dev
5402018-12-20T19:54:31 *** chenpo has quit IRC
5412018-12-20T19:55:27 *** davec has quit IRC
5422018-12-20T19:57:18 *** davec has joined #bitcoin-core-dev
5432018-12-20T20:11:06 *** justan0theruser has joined #bitcoin-core-dev
5442018-12-20T20:12:22 *** justanotheruser has quit IRC
5452018-12-20T20:12:25 *** timothy has quit IRC
5462018-12-20T20:15:23 *** justan0theruser has quit IRC
5472018-12-20T20:16:43 *** state_bits has quit IRC
5482018-12-20T20:16:51 *** state_bits has joined #bitcoin-core-dev
5492018-12-20T20:29:30 *** chenpo has joined #bitcoin-core-dev
5502018-12-20T20:30:10 *** drexl has quit IRC
5512018-12-20T20:30:38 *** drexl has joined #bitcoin-core-dev
5522018-12-20T20:32:03 <Csus> @wumpus Yes g++ does work..
5532018-12-20T20:33:47 *** chenpo has quit IRC
5542018-12-20T20:35:19 *** face has quit IRC
5552018-12-20T20:37:21 *** justanotheruser has joined #bitcoin-core-dev
5562018-12-20T20:39:46 *** EagleTM has joined #bitcoin-core-dev
5572018-12-20T20:42:54 *** face has joined #bitcoin-core-dev
5582018-12-20T20:44:44 *** mileschet has joined #bitcoin-core-dev
5592018-12-20T20:49:06 *** e4xit has joined #bitcoin-core-dev
5602018-12-20T20:49:34 *** mileschet has quit IRC
5612018-12-20T20:51:27 *** promag has joined #bitcoin-core-dev
5622018-12-20T20:56:33 *** promag has quit IRC
5632018-12-20T21:02:39 *** mileschet has joined #bitcoin-core-dev
5642018-12-20T21:05:45 <jonasschnelli> sipa: for the CNetMessage refactoring, instead of using polymorphism (virtual base class), would you suggest having a global pointer to a instance of something we could call CNetMessageSerializer?
5652018-12-20T21:05:53 <jonasschnelli> So move all the ser/deser code there?
5662018-12-20T21:06:45 <jonasschnelli> So there could be two serialization instance (legacy p2p and BIP151 p2p) where each node would hold a shared pointer to that instance?
5672018-12-20T21:12:01 *** shesek has quit IRC
5682018-12-20T21:13:31 *** mileschet has quit IRC
5692018-12-20T21:13:50 *** shesek has joined #bitcoin-core-dev
5702018-12-20T21:17:08 *** rex4539 has joined #bitcoin-core-dev
5712018-12-20T21:19:41 *** mileschet has joined #bitcoin-core-dev
5722018-12-20T21:22:27 <sipa> jonasschnelli: well each connection only needs one
5732018-12-20T21:22:51 <jonasschnelli> sipa: Yes. But a pointer to a global instance seems okay, right?
5742018-12-20T21:23:01 <sipa> and if there is no local state in the deserializer you don't need to instantiate it
5752018-12-20T21:23:13 <jonasschnelli> Yes
5762018-12-20T21:23:19 <sipa> so no pointers
5772018-12-20T21:23:39 <sipa> it depends
5782018-12-20T21:24:57 <jonasschnelli> but somewhere you need to keep record of the position you have read the message up to
5792018-12-20T21:25:13 <jonasschnelli> so CNetMessage gets do then still contain some minimal serialization state
5802018-12-20T21:25:47 <jonasschnelli> Where CNetMessage is more or less a serialisation helper
5812018-12-20T21:26:08 *** Victorsueca has quit IRC
5822018-12-20T21:26:14 <jonasschnelli> so I'm not yet entirely convinced of the split between CNetMessage and CNetMessageSerializer
5832018-12-20T21:26:23 *** contrapumpkin has joined #bitcoin-core-dev
5842018-12-20T21:26:29 *** Victorsueca has joined #bitcoin-core-dev
5852018-12-20T21:26:49 <sipa> i'm just saying there is no need to make each CNetMessage know what type of serialization is used
5862018-12-20T21:26:59 <sipa> it's a per node thing, not per message
5872018-12-20T21:27:12 <jonasschnelli> Yes. I agree with that
5882018-12-20T21:27:20 <sipa> it's bith a waste of memory and cpu to push it down so deep
5892018-12-20T21:27:58 <jonasschnelli> I think the initial design came from the two step BIP151 handshare where v1 protocol was required for the initial messages
5902018-12-20T21:28:00 <sipa> i also don't understand the global pointer question
5912018-12-20T21:28:05 <jonasschnelli> *handshake
5922018-12-20T21:28:23 <sipa> that still doesn't require every message to know how it was serialized
5932018-12-20T21:28:44 <sipa> either the serializer classes hold state, and you'll want one object per node
5942018-12-20T21:28:56 <sipa> or it doesn't, and there is no need fo instantiate them at all
5952018-12-20T21:29:01 *** Csus has quit IRC
5962018-12-20T21:29:10 <jonasschnelli> sipa: so each node has either v1 or v2 serialization, each CNode could have a shared pointer to v1 or v2 global serializer instance
5972018-12-20T21:29:26 <jonasschnelli> but since there is no need for instantisation, I'm unsure
5982018-12-20T21:29:27 <sipa> sure, but why?
5992018-12-20T21:29:45 *** copumpkin has quit IRC
6002018-12-20T21:30:07 *** Guyver2 has quit IRC
6012018-12-20T21:30:07 <sipa> maybe all you need is a function to serialize/deserialize that takes an enum for the type of serialization
6022018-12-20T21:30:18 <jonasschnelli> i see,.. yes
6032018-12-20T21:30:18 *** hex17or has joined #bitcoin-core-dev
6042018-12-20T21:31:17 <sipa> but if there is a concern we may need state, sure a per-node instance sounds good
6052018-12-20T21:32:01 <jonasschnelli> I guess we don't need state on that level
6062018-12-20T21:32:40 *** promag has joined #bitcoin-core-dev
6072018-12-20T21:32:46 <sipa> i don't know
6082018-12-20T21:33:05 <sipa> it can hold partial checksum data
6092018-12-20T21:34:46 *** hex17or has quit IRC
6102018-12-20T21:35:43 <jonasschnelli> sipa: you mean the SHA256 or poly1305 state?
6112018-12-20T21:36:52 <sipa> yes
6122018-12-20T21:37:18 *** promag has quit IRC
6132018-12-20T21:40:52 *** hex17or has joined #bitcoin-core-dev
6142018-12-20T21:40:55 *** Tralfaz has joined #bitcoin-core-dev
6152018-12-20T21:46:53 *** profmac has joined #bitcoin-core-dev
6162018-12-20T21:49:44 *** rh0nj has quit IRC
6172018-12-20T21:50:07 *** rh0nj has joined #bitcoin-core-dev
6182018-12-20T21:54:38 *** mileschet has quit IRC
6192018-12-20T21:56:30 <meshcollider> promag: 2:10 AM <gmaxwell> Whats wrong with making walletpassphrase an automatic named argument to _every_ rpc, and if the rpc can make use of the passprase, they use it... without unlocking.
6202018-12-20T21:56:39 <meshcollider> Concept ACK ^
6212018-12-20T21:58:32 *** spaced0ut has joined #bitcoin-core-dev
6222018-12-20T22:05:32 *** jarthur has quit IRC
6232018-12-20T22:05:45 *** mileschet has joined #bitcoin-core-dev
6242018-12-20T22:07:26 *** bitcoin-git has joined #bitcoin-core-dev
6252018-12-20T22:07:27 <bitcoin-git> [bitcoin] bitcoinhodler opened pull request #15012: Docs: Fix minor grammar error (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15012
6262018-12-20T22:07:27 *** bitcoin-git has left #bitcoin-core-dev
6272018-12-20T22:10:28 *** mileschet has quit IRC
6282018-12-20T22:11:05 *** mileschet has joined #bitcoin-core-dev
6292018-12-20T22:12:00 *** laptop__ has quit IRC
6302018-12-20T22:13:06 *** Tralfaz has quit IRC
6312018-12-20T22:14:36 *** spinza has quit IRC
6322018-12-20T22:17:57 *** spinza has joined #bitcoin-core-dev
6332018-12-20T22:19:37 *** hex17or has quit IRC
6342018-12-20T22:30:13 *** ozymandias_2 has joined #bitcoin-core-dev
6352018-12-20T22:30:28 *** ozymandias_2 has quit IRC
6362018-12-20T22:33:48 *** mileschet has quit IRC
6372018-12-20T22:45:41 *** mileschet has joined #bitcoin-core-dev
6382018-12-20T22:50:07 *** mileschet has quit IRC
6392018-12-20T22:55:45 *** mileschet has joined #bitcoin-core-dev
6402018-12-20T23:00:56 *** promag has joined #bitcoin-core-dev
6412018-12-20T23:03:58 *** mileschet has quit IRC
6422018-12-20T23:28:47 *** promag has quit IRC
6432018-12-20T23:35:45 *** chenpo has joined #bitcoin-core-dev
6442018-12-20T23:40:09 *** chenpo has quit IRC
6452018-12-20T23:53:22 *** murrayn has joined #bitcoin-core-dev
6462018-12-20T23:54:36 *** BGL has quit IRC