12017-11-23T00:02:02  *** justanotheruser has joined #bitcoin-core-dev
  22017-11-23T00:08:44  *** fanquake has joined #bitcoin-core-dev
  32017-11-23T00:37:35  *** booyah has quit IRC
  42017-11-23T00:44:05  *** Randolf has joined #bitcoin-core-dev
  52017-11-23T00:55:08  *** meshcollider has quit IRC
  62017-11-23T00:57:05  *** Randolf has quit IRC
  72017-11-23T01:02:18  *** wumpus has quit IRC
  82017-11-23T01:05:21  *** booyah has joined #bitcoin-core-dev
  92017-11-23T01:05:41  *** meshcollider has joined #bitcoin-core-dev
 102017-11-23T01:10:23  *** jb55 has quit IRC
 112017-11-23T01:11:49  *** Aaronvan_ has joined #bitcoin-core-dev
 122017-11-23T01:12:28  *** wumpus has joined #bitcoin-core-dev
 132017-11-23T01:14:25  *** wunpunch has quit IRC
 142017-11-23T01:15:21  *** AaronvanW has quit IRC
 152017-11-23T01:17:05  *** Aaronvan_ has quit IRC
 162017-11-23T01:19:59  *** owowo has quit IRC
 172017-11-23T01:22:13  *** justanotheruser has quit IRC
 182017-11-23T01:26:25  *** owowo has joined #bitcoin-core-dev
 192017-11-23T01:27:29  *** quantbot has quit IRC
 202017-11-23T01:27:46  *** goatpig has quit IRC
 212017-11-23T01:28:03  *** quantbot has joined #bitcoin-core-dev
 222017-11-23T01:32:15  *** quantbot has quit IRC
 232017-11-23T01:55:23  *** TrufflePig has joined #bitcoin-core-dev
 242017-11-23T02:13:22  *** Ylbam has quit IRC
 252017-11-23T02:16:29  *** bule has joined #bitcoin-core-dev
 262017-11-23T02:21:06  *** Timothy has joined #bitcoin-core-dev
 272017-11-23T02:21:28  *** Timothy is now known as Guest55400
 282017-11-23T02:22:04  *** bule has quit IRC
 292017-11-23T02:23:42  *** Guest55400 has quit IRC
 302017-11-23T02:26:39  *** Randolf has joined #bitcoin-core-dev
 312017-11-23T02:30:41  *** twistedline has quit IRC
 322017-11-23T02:32:41  *** twistedline has joined #bitcoin-core-dev
 332017-11-23T02:44:00  *** twistedline_ has joined #bitcoin-core-dev
 342017-11-23T02:44:08  *** twistedline has quit IRC
 352017-11-23T02:47:20  *** roadcrap has quit IRC
 362017-11-23T02:49:15  *** roadcrap has joined #bitcoin-core-dev
 372017-11-23T03:19:34  *** quantbot has joined #bitcoin-core-dev
 382017-11-23T03:26:30  *** TrufflePig has quit IRC
 392017-11-23T03:36:09  *** satwo has quit IRC
 402017-11-23T03:41:16  *** StopAndDecrypt is now known as StopAndDecrypt|L
 412017-11-23T03:41:46  *** StopAndDecrypt|L is now known as StopAndDecrypt
 422017-11-23T03:55:11  *** Randolf has quit IRC
 432017-11-23T03:58:56  *** guest__ has joined #bitcoin-core-dev
 442017-11-23T04:05:50  *** justanotheruser has joined #bitcoin-core-dev
 452017-11-23T04:40:44  *** jb55 has joined #bitcoin-core-dev
 462017-11-23T04:42:43  *** digifis has joined #bitcoin-core-dev
 472017-11-23T04:43:14  *** DigitalDank has joined #bitcoin-core-dev
 482017-11-23T04:44:11  *** Randolf has joined #bitcoin-core-dev
 492017-11-23T04:45:27  *** sin_ has quit IRC
 502017-11-23T04:49:21  *** DigitalDank has quit IRC
 512017-11-23T04:50:22  *** DigitalDank has joined #bitcoin-core-dev
 522017-11-23T05:36:27  *** lex11 has joined #bitcoin-core-dev
 532017-11-23T05:40:30  *** lex11 has quit IRC
 542017-11-23T05:41:53  *** lex11 has joined #bitcoin-core-dev
 552017-11-23T05:44:05  *** jb55 has quit IRC
 562017-11-23T05:59:34  *** challisto has joined #bitcoin-core-dev
 572017-11-23T05:59:35  *** challisto has joined #bitcoin-core-dev
 582017-11-23T06:04:06  *** challisto has left #bitcoin-core-dev
 592017-11-23T06:05:14  *** lex11 has quit IRC
 602017-11-23T06:08:17  *** SopaXorzTaker has quit IRC
 612017-11-23T06:09:00  *** SopaXorzTaker has joined #bitcoin-core-dev
 622017-11-23T06:13:00  *** arubi has quit IRC
 632017-11-23T06:17:57  *** arubi has joined #bitcoin-core-dev
 642017-11-23T06:40:36  *** justan0theruser has joined #bitcoin-core-dev
 652017-11-23T06:42:12  *** justanotheruser has quit IRC
 662017-11-23T07:05:43  *** Ylbam has joined #bitcoin-core-dev
 672017-11-23T07:27:11  *** btcdrak has quit IRC
 682017-11-23T07:31:51  <fanquake> wumpus I'll have a look into adding configure checks for 4.8+
 692017-11-23T07:38:53  *** fanquake has left #bitcoin-core-dev
 702017-11-23T07:43:05  *** fanquake has joined #bitcoin-core-dev
 712017-11-23T07:43:45  <wumpus> fanquake: thanks! I looked around a bit and checking the type and version of the c++ compiler is harder than one'd expect, it's pretty much entirely unsupported
 722017-11-23T07:47:40  <wumpus> fanquake: might be most straightforward to just add a "check you compiler version, only gcc 4.8 and higher is supported" message when AX_CXX_COMPILE_STDCXX  fails
 732017-11-23T07:47:49  <wumpus> (and also add the minimum clang version then)
 742017-11-23T07:48:36  <wumpus> as that macro will already fail on gcc 4.7 apparently
 752017-11-23T07:48:54  <wumpus> and pass on 4.8
 762017-11-23T07:50:24  <fanquake> wumpus yep, I was having a bit of a look as well. Didn't seem that straight forward. Especially since Clang also defines __GNUC__ etc
 772017-11-23T07:50:33  <fanquake> No double cfields would have some black magic to get it done..
 782017-11-23T07:50:53  <fanquake> wumpus I think you suggestion is good though. I'll put together a PR.
 792017-11-23T07:52:17  <wumpus> yeah... what they suggest you really want to check is certain features, not the version number of the compiler, because different compilers have different version number schemes. But checking every single c++11 feature is going to be tiring
 802017-11-23T07:52:46  <wumpus> what we realy want to check is "c++11 support at the level of gcc 4.8"
 812017-11-23T07:54:16  <fanquake> wumpus Pretty certain GCC 4.8.1 is feature complete for c++11. So I think warning if AX_CXX_COMPILE_STDCXX fails should be enough?
 822017-11-23T07:54:39  <fanquake> https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
 832017-11-23T07:55:09  <sipa> we could just try to compile something with a thread_local variable
 842017-11-23T07:56:14  <wumpus> fanquake: yes, I think so... so we now require "full c++11" which is what that macro checks for
 852017-11-23T07:56:33  <wumpus> so adding a better message should be enough
 862017-11-23T07:59:21  <wumpus> sipa: yes, that would be another option
 872017-11-23T08:01:21  *** BashCo has quit IRC
 882017-11-23T08:39:19  *** Guyver2 has joined #bitcoin-core-dev
 892017-11-23T08:43:35  *** BashCo has joined #bitcoin-core-dev
 902017-11-23T08:55:08  *** meshcollider has quit IRC
 912017-11-23T08:56:27  *** laurentmt has joined #bitcoin-core-dev
 922017-11-23T09:16:21  *** timothy has joined #bitcoin-core-dev
 932017-11-23T09:21:50  *** promag has joined #bitcoin-core-dev
 942017-11-23T09:40:35  *** numz has joined #bitcoin-core-dev
 952017-11-23T09:40:40  *** numz has left #bitcoin-core-dev
 962017-11-23T09:49:01  *** d_t has quit IRC
 972017-11-23T09:54:03  *** Ylbam has quit IRC
 982017-11-23T09:57:09  *** lio17 has left #bitcoin-core-dev
 992017-11-23T10:18:36  <promag> jonasschnelli: ping
1002017-11-23T10:29:38  *** BGL has quit IRC
1012017-11-23T10:32:42  *** promag has quit IRC
1022017-11-23T10:33:39  *** AaronvanW has joined #bitcoin-core-dev
1032017-11-23T10:40:03  *** meshcollider has joined #bitcoin-core-dev
1042017-11-23T10:52:28  *** user__ is now known as wxss
1052017-11-23T10:54:05  *** AaronvanW has quit IRC
1062017-11-23T10:54:43  *** AaronvanW has joined #bitcoin-core-dev
1072017-11-23T11:02:34  *** limpkin_irc has quit IRC
1082017-11-23T11:32:58  *** lio17 has joined #bitcoin-core-dev
1092017-11-23T11:33:12  *** promag has joined #bitcoin-core-dev
1102017-11-23T11:40:58  *** promag has quit IRC
1112017-11-23T11:41:12  *** promag has joined #bitcoin-core-dev
1122017-11-23T11:53:34  *** ZodiaCfd has quit IRC
1132017-11-23T11:57:57  *** StopAndDecrypt has quit IRC
1142017-11-23T11:58:41  *** StopAndDecrypt has joined #bitcoin-core-dev
1152017-11-23T11:59:25  *** nelruk has joined #bitcoin-core-dev
1162017-11-23T12:09:52  *** Soligor has quit IRC
1172017-11-23T12:13:10  *** Soligor has joined #bitcoin-core-dev
1182017-11-23T12:17:40  <cluelessperson> I will be putting together some aggregated CSV data regarding block times, fees, transactions, etc.  Let me know if you want a link
1192017-11-23T12:17:46  *** StopAndDecrypt has quit IRC
1202017-11-23T12:17:48  *** StopAndDecrypt_ has joined #bitcoin-core-dev
1212017-11-23T12:18:14  <promag> +1
1222017-11-23T12:22:43  *** fronti has joined #bitcoin-core-dev
1232017-11-23T12:30:28  <promag> sipa: should there be support for P2WPKH in signmessage?
1242017-11-23T12:30:45  <promag> verifymessage as well
1252017-11-23T12:39:42  *** wxss has quit IRC
1262017-11-23T12:42:19  <promag> sipa: nevermind, already noted in #11403 description.
1272017-11-23T12:42:22  <gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
1282017-11-23T12:46:48  *** wxss_ has joined #bitcoin-core-dev
1292017-11-23T12:49:40  *** meshcollider has quit IRC
1302017-11-23T12:55:27  *** SopaXorzTaker has quit IRC
1312017-11-23T13:04:50  *** SopaXorzTaker has joined #bitcoin-core-dev
1322017-11-23T13:09:42  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
1332017-11-23T13:14:46  *** Giszmo has quit IRC
1342017-11-23T13:17:44  *** nelruk has quit IRC
1352017-11-23T13:26:07  *** promag has quit IRC
1362017-11-23T13:52:07  *** promag has joined #bitcoin-core-dev
1372017-11-23T14:01:42  *** promag has quit IRC
1382017-11-23T14:03:32  *** promag has joined #bitcoin-core-dev
1392017-11-23T14:03:36  *** booyah_ has joined #bitcoin-core-dev
1402017-11-23T14:03:42  *** booyah has quit IRC
1412017-11-23T14:10:07  *** dgenr8 has quit IRC
1422017-11-23T14:11:27  *** dgenr8 has joined #bitcoin-core-dev
1432017-11-23T14:13:48  *** laurentmt has quit IRC
1442017-11-23T14:22:07  *** laurentmt has joined #bitcoin-core-dev
1452017-11-23T14:23:16  *** fanquake has quit IRC
1462017-11-23T14:28:12  *** Guyver2_ has joined #bitcoin-core-dev
1472017-11-23T14:31:07  *** Guyver2 has quit IRC
1482017-11-23T14:36:07  *** goatpig has joined #bitcoin-core-dev
1492017-11-23T15:01:34  *** promag has quit IRC
1502017-11-23T15:10:30  *** rafalcpp has joined #bitcoin-core-dev
1512017-11-23T15:15:09  *** rafalcpp has quit IRC
1522017-11-23T15:19:32  *** Emcy has quit IRC
1532017-11-23T15:19:37  *** rafalcpp has joined #bitcoin-core-dev
1542017-11-23T15:21:59  *** Giszmo has joined #bitcoin-core-dev
1552017-11-23T15:23:16  *** Emcy has joined #bitcoin-core-dev
1562017-11-23T15:25:30  *** d_t has joined #bitcoin-core-dev
1572017-11-23T15:35:10  *** Cogito_Ergo_Sum has quit IRC
1582017-11-23T15:39:45  *** SopaXorzTaker has quit IRC
1592017-11-23T15:40:38  *** SopaXorzTaker has joined #bitcoin-core-dev
1602017-11-23T15:42:55  <wumpus> should we cancel today's meeting because of thanksgiving?
1612017-11-23T15:43:44  *** valerioleo has joined #bitcoin-core-dev
1622017-11-23T15:45:33  <luke-jr> I won't be able to make it, at leat
1632017-11-23T15:45:36  <luke-jr> least*
1642017-11-23T15:48:15  *** Emcy_ has joined #bitcoin-core-dev
1652017-11-23T15:49:21  *** Emcy has quit IRC
1662017-11-23T15:50:56  <wumpus> that's probably true for most people from the US
1672017-11-23T15:53:36  *** jack___ has joined #bitcoin-core-dev
1682017-11-23T15:59:20  *** booyah_ has quit IRC
1692017-11-23T15:59:38  *** booyah_ has joined #bitcoin-core-dev
1702017-11-23T16:00:15  <instagibbs> still may be a critical mass, though I will not be around
1712017-11-23T16:00:57  *** d_t has quit IRC
1722017-11-23T16:01:32  *** booyah_ has quit IRC
1732017-11-23T16:01:50  *** booyah_ has joined #bitcoin-core-dev
1742017-11-23T16:02:30  <cluelessperson> wumpus: if there is a meeting, may I be present?
1752017-11-23T16:02:56  *** Emcy has joined #bitcoin-core-dev
1762017-11-23T16:03:08  <wumpus> cluelessperson: there's no need to ask that
1772017-11-23T16:03:45  *** booyah_ has quit IRC
1782017-11-23T16:04:02  *** booyah_ has joined #bitcoin-core-dev
1792017-11-23T16:04:15  *** Emcy_ has quit IRC
1802017-11-23T16:04:26  <wumpus> the meeting is here every week 19:00 UTC, everyone is welcome
1812017-11-23T16:14:41  <cluelessperson> sweet, sorry, I've been hanging in channel, but I've been avoiding speaking here as I feel I lack skill sets to be of much help
1822017-11-23T16:16:01  <wumpus> every week thursday*
1832017-11-23T16:16:03  *** jb55 has joined #bitcoin-core-dev
1842017-11-23T16:17:24  <luke-jr> if you don't have something helpful to say, don't say it; if you do, say it XD
1852017-11-23T16:19:24  *** ghost43 has quit IRC
1862017-11-23T16:19:42  *** whphhg has quit IRC
1872017-11-23T16:24:17  *** jack___ has quit IRC
1882017-11-23T16:24:59  *** ghost43 has joined #bitcoin-core-dev
1892017-11-23T16:26:07  <cluelessperson> luke-jr: but my name is accurate!
1902017-11-23T16:27:47  *** booyah has joined #bitcoin-core-dev
1912017-11-23T16:29:04  *** booyah_ has quit IRC
1922017-11-23T16:29:45  *** booyah has quit IRC
1932017-11-23T16:29:51  *** d_t has joined #bitcoin-core-dev
1942017-11-23T16:30:04  *** booyah has joined #bitcoin-core-dev
1952017-11-23T16:32:05  *** booyah has quit IRC
1962017-11-23T16:32:08  *** booyah_ has joined #bitcoin-core-dev
1972017-11-23T16:32:31  *** jb55 has quit IRC
1982017-11-23T16:35:03  *** booyah_ has quit IRC
1992017-11-23T16:35:32  *** booyah_ has joined #bitcoin-core-dev
2002017-11-23T16:37:15  *** whphhg has joined #bitcoin-core-dev
2012017-11-23T16:47:27  *** Randolf has quit IRC
2022017-11-23T16:48:18  *** promag has joined #bitcoin-core-dev
2032017-11-23T16:50:29  *** promag has quit IRC
2042017-11-23T16:59:18  *** jeffrade has joined #bitcoin-core-dev
2052017-11-23T17:02:17  *** jeffrade has quit IRC
2062017-11-23T17:05:32  *** booyah_ has quit IRC
2072017-11-23T17:05:33  *** booyah has joined #bitcoin-core-dev
2082017-11-23T17:05:45  *** Guest66377 has joined #bitcoin-core-dev
2092017-11-23T17:07:56  *** justan0theruser has quit IRC
2102017-11-23T17:08:38  *** Guyver2_ has quit IRC
2112017-11-23T17:10:51  *** Guest66377 has quit IRC
2122017-11-23T17:12:26  *** booyah_ has joined #bitcoin-core-dev
2132017-11-23T17:12:34  *** booyah has quit IRC
2142017-11-23T17:21:44  *** justan0theruser has joined #bitcoin-core-dev
2152017-11-23T17:25:21  *** jb55 has joined #bitcoin-core-dev
2162017-11-23T17:25:55  *** JackH has joined #bitcoin-core-dev
2172017-11-23T17:29:51  *** timothy has quit IRC
2182017-11-23T17:33:18  <mlz> no meeting today though?
2192017-11-23T17:33:29  <sipa> i may be able to attend
2202017-11-23T17:34:16  <mlz> Happy Thanksgiving to all Core devs! Thank you for your hard work and dedication!  :)
2212017-11-23T17:34:40  <Eliel> how much memory does the UTXO set require per txout currently and what's the theoretical minimum it can be pushed down to?
2222017-11-23T17:35:45  *** meshcollider has joined #bitcoin-core-dev
2232017-11-23T17:39:57  *** StopAndDecrypt_ has quit IRC
2242017-11-23T17:40:20  <Eliel> according to statoshi info, the current serialized UTXO set has ~55500000 transactions and that takes 2.9GB of space. So, that comes out to something like 53 bytes per utxo
2252017-11-23T17:40:40  *** StopAndDecrypt has joined #bitcoin-core-dev
2262017-11-23T17:40:42  <Eliel> I suppose I'll go with that.
2272017-11-23T17:49:01  *** BashCo has quit IRC
2282017-11-23T17:59:36  *** laurentmt has quit IRC
2292017-11-23T18:04:09  <wumpus> mlz: thanks!
2302017-11-23T18:13:49  *** BashCo has joined #bitcoin-core-dev
2312017-11-23T18:14:13  *** Provoostenator has joined #bitcoin-core-dev
2322017-11-23T18:16:50  <wumpus> Eliel: it also needs to be in an efficient format to make updates, otherwise you end up rewriting the whole thing for every block
2332017-11-23T18:18:07  <Eliel> wumpus: would that be more than 53 bytes per txout?
2342017-11-23T18:18:37  <wumpus> I mean you can probably save some space by just concatenating the whole thing then putting it through a compressor with a large block size, but except as a snapshot it'd not be useful
2352017-11-23T18:19:31  <wumpus> I don't know.
2362017-11-23T18:20:12  <wumpus> it will still be of the same order anyhow
2372017-11-23T18:20:33  <Eliel> I'm trying to estimate the amount amount of RAM required on full nodes per user for LN users and non-LN users, so I guess the accuracy of the number is not a big issue. As long as it's not off by an order of magnitude :)
2382017-11-23T18:22:10  *** Randolf has joined #bitcoin-core-dev
2392017-11-23T18:28:57  *** Randolf has quit IRC
2402017-11-23T18:29:35  *** cl0uding has quit IRC
2412017-11-23T18:30:26  *** Randolf has joined #bitcoin-core-dev
2422017-11-23T18:37:01  *** Randolf has quit IRC
2432017-11-23T18:38:53  <jonasschnelli> Oh. It's thanks giving... I would be around for the meeting.
2442017-11-23T18:39:58  *** justan0theruser has quit IRC
2452017-11-23T18:42:26  *** cl0uding has joined #bitcoin-core-dev
2462017-11-23T18:42:31  *** dejarp has joined #bitcoin-core-dev
2472017-11-23T18:43:33  <wxss_> clear
2482017-11-23T18:44:59  *** Randolf has joined #bitcoin-core-dev
2492017-11-23T18:47:38  <meshcollider> I'm flying to Sydney in half an hour or so so I'll only be here for the first part of the meeting if it's on
2502017-11-23T18:48:50  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2512017-11-23T18:49:37  *** laurentmt has joined #bitcoin-core-dev
2522017-11-23T18:53:04  *** justan0theruser has joined #bitcoin-core-dev
2532017-11-23T18:58:50  *** Khunbish has joined #bitcoin-core-dev
2542017-11-23T18:59:08  *** justan0theruser has quit IRC
2552017-11-23T19:00:32  <achow101> Meeting?
2562017-11-23T19:01:53  <Provoostenator> Suggested topic: onboarding
2572017-11-23T19:02:13  <sipa> present
2582017-11-23T19:02:22  <jonasschnelli> here
2592017-11-23T19:02:43  <wumpus> #startmeeting
2602017-11-23T19:02:43  <lightningbot> Meeting started Thu Nov 23 19:02:43 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2612017-11-23T19:02:43  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2622017-11-23T19:03:06  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
2632017-11-23T19:04:11  <wumpus> Provoostenator: onboarding?
2642017-11-23T19:04:15  <wumpus> #topic high priority for review
2652017-11-23T19:04:24  <jonasschnelli> Should we discuss https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2 (sipas wallet design)?
2662017-11-23T19:04:26  <wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
2672017-11-23T19:04:31  <jonasschnelli> ack
2682017-11-23T19:04:32  <Provoostenator> I'd like to propose adding a project Onboarding to this list: https://github.com/bitcoin/bitcoin/projects
2692017-11-23T19:04:43  <BlueMatt> wumpus: lol uhhhhhh its a holiday in .us
2702017-11-23T19:04:45  * BlueMatt expected meeting was cancelled today
2712017-11-23T19:04:59  <wumpus> Provoostenator: I don't understand what you mean with onboarding
2722017-11-23T19:05:10  <sipa> wumpus: bringing new people on board, i assume
2732017-11-23T19:05:10  <Provoostenator> That project would contain the first PR of any new contributor.
2742017-11-23T19:05:10  <jonasschnelli> m2
2752017-11-23T19:05:20  <wumpus> BlueMatt: yes, I asked whether to cancel the meeting earlier today
2762017-11-23T19:05:30  <sipa> we
2772017-11-23T19:05:42  <wumpus> BlueMatt: but only luke-jr was for it
2782017-11-23T19:05:47  <sipa> we're clearly at lower attendance, so let's avoid committing to anything
2792017-11-23T19:06:00  <sipa> doesn't mean things can't be discussed
2802017-11-23T19:06:02  <wumpus> I'm fine with cancelling the meeting
2812017-11-23T19:06:11  *** promag has joined #bitcoin-core-dev
2822017-11-23T19:06:14  <BlueMatt> wumpus: heh, well everyone who would have suggested cancelling was already gone for vacation :p
2832017-11-23T19:06:23  <wumpus> ok
2842017-11-23T19:06:31  <wumpus> meeting is cancelled today
2852017-11-23T19:06:31  <jonasschnelli> Lets keep the meeting running...
2862017-11-23T19:06:32  <wumpus> #endmeeting
2872017-11-23T19:06:32  <lightningbot> Meeting ended Thu Nov 23 19:06:32 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
2882017-11-23T19:06:32  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.html
2892017-11-23T19:06:32  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.txt
2902017-11-23T19:06:32  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-23-19.02.log.html
2912017-11-23T19:06:37  <promag> nice
2922017-11-23T19:06:37  <jonasschnelli> ;-)
2932017-11-23T19:06:40  <achow101> we could still talk about things though
2942017-11-23T19:06:46  <jonasschnelli> Sure.
2952017-11-23T19:06:54  <promag> topic suggestion, network conf etc
2962017-11-23T19:07:04  <jonasschnelli> Provoostenator: what would be the benefit behind that (first PR) project ?
2972017-11-23T19:07:10  <Provoostenator> New PR's always get a lot of attention, but after a while they lose attention. That's fine for experienced devs, but I think it discourages new contribuors.
2982017-11-23T19:07:12  * BlueMatt -> vacation, see y'all next week
2992017-11-23T19:07:25  <promag> o/
3002017-11-23T19:07:40  <wumpus> Provoostenator: I think it's okay to go into this room and shout at people to review your PR
3012017-11-23T19:07:42  <jonasschnelli> Provoostenator: Yes. One needs endurance. :)
3022017-11-23T19:07:44  <Provoostenator> Once they get their first PR in, they're probably much more likely to keep contributing and be more assertive / patient.
3032017-11-23T19:08:14  <jonasschnelli> If it looses attention, then it's probably not priority or the dev did not shout loud enough
3042017-11-23T19:08:28  <jonasschnelli> The main bottleneck is still serious reviews
3052017-11-23T19:08:33  <kanzure> hi.
3062017-11-23T19:08:35  <achow101> jonasschnelli: sometimes people don't know that they should shout
3072017-11-23T19:08:43  <wumpus> I mean it's sometimes sad how PRs go ignored, but it's kind of how open source works, you need to bring attention to your PRs somehow
3082017-11-23T19:08:47  <kanzure> i missed the meeting :(
3092017-11-23T19:08:48  <Provoostenator> Yes, that's why this Project would only apply to the first PR. After that they can be encouraged to shout more.
3102017-11-23T19:09:09  <sipa> or people aren't aware that some things take a long time - and this doesn't mean they're not going to happen
3112017-11-23T19:09:14  <wumpus> e.g. if it fixes a issue, then reply to people posting issues to test your patch
3122017-11-23T19:09:16  <achow101> kanzure: we decided during the meeting that we wouldn't have a meeting :)
3132017-11-23T19:09:21  <jonasschnelli> sipa: indeed
3142017-11-23T19:09:29  <jonasschnelli> I think we should maybe add a beginners guide...
3152017-11-23T19:09:37  <jonasschnelli> Some people expect merges in 1-2 days.
3162017-11-23T19:09:41  <wumpus> add it to CONTRIBUTING.md
3172017-11-23T19:09:47  <jonasschnelli> yeah
3182017-11-23T19:10:15  <Provoostenator> Yeah, I've seen PR's by very experienced people open for over a year, so indeed peoples should have realistic expectations.
3192017-11-23T19:10:19  <jonasschnelli> Adding new PRs to the project would be another thing maintainers have to care about
3202017-11-23T19:10:29  <promag> there is also the case that a review sits there for a long time
3212017-11-23T19:10:38  <wumpus> bitcoin isn't really a good project for first time open source contributors in that regard, some projects just merge everything effectively instantly, but we cannot have a policy like that, not for first contributors ither
3222017-11-23T19:10:45  <jonasschnelli> Provoostenator: recently a 2yr old PR of mine got merged...
3232017-11-23T19:11:02  <sipa> my first PR took half a year, and that was in 2011 :)
3242017-11-23T19:11:05  <wumpus> promag: oh yes, indeed, some PRs get lots of review then the author pretty much just ignores it
3252017-11-23T19:11:18  <wumpus> promag: and they get closed after half a year or longer
3262017-11-23T19:11:26  <Provoostenator> @wumpus good point that it's not a good first open source project. Although the quality of reviews is really great for learning.
3272017-11-23T19:11:28  <jonasschnelli> Provoostenator: I think you could add a part in CONTRIBUTING.md
3282017-11-23T19:11:40  <jonasschnelli> that would be helpful for new contributors
3292017-11-23T19:11:41  <promag> right, it's also a bit weird to submit a PR, have reviews, and then it's ignored by the author
3302017-11-23T19:12:05  <BlueMatt> CBlockStore is still WIP from 2012 :p
3312017-11-23T19:12:10  <wumpus> authors can also get more attention by helping review other patches
3322017-11-23T19:12:26  <Provoostenator> I think contributing.md already says it takes a long time and you shoudl go on IRC.
3332017-11-23T19:12:39  <promag> true, some authors ignore other PR's, but that's more acceptable IMO
3342017-11-23T19:12:47  <wumpus> in any case of a PR really fixes a bug or issue, it won't usually take that long before it's merged unless something is wrong and not being fixed
3352017-11-23T19:12:51  <achow101> unfortunately people don't really read the documentation that explains what they should do
3362017-11-23T19:13:07  <Provoostenator> Yeah, so maybe something we could add to that doc is to encourage people to find a painful issue.
3372017-11-23T19:13:16  <wumpus> fix issues that affect peopel
3382017-11-23T19:13:20  <wumpus> yep
3392017-11-23T19:13:29  *** justan0theruser has joined #bitcoin-core-dev
3402017-11-23T19:13:42  <Provoostenator> E.g. https://github.com/bitcoin/bitcoin/labels/good%20first%20issue
3412017-11-23T19:13:43  <achow101> easiest way to find issues is to read bitcointalk and wait for people to do stupid things
3422017-11-23T19:13:48  <wumpus> we mention that in the CONTRIBUTING a bit afaik, that a refactor or style change is a bad idea for first contributors
3432017-11-23T19:13:55  <Provoostenator> Though in that case we should make sure that that label is correctly applied.
3442017-11-23T19:14:01  <wumpus> maybe that could be extendded
3452017-11-23T19:14:25  <wumpus> Provoostenator: if you have suggestions on issues that should be labeled just highlight me or fanquake here
3462017-11-23T19:14:45  <promag> Provoostenator: there is also around 200 TODO in the code
3472017-11-23T19:14:50  <achow101> if we're actually going to use "good first issue" for this, we should probably remove the release schedule from that tag
3482017-11-23T19:14:55  <Provoostenator> I'm still not sure which issues are both easy enough for a first time contributor AND important enough to get attention in review.
3492017-11-23T19:15:07  <wumpus> achow101: yeah...
3502017-11-23T19:15:10  <achow101> it's funny and all, but has confused a few people too
3512017-11-23T19:15:18  <wumpus> achow101: makes it easy to find it though
3522017-11-23T19:15:28  <wumpus> achow101: really?
3532017-11-23T19:15:31  <achow101> make a release schedule tag
3542017-11-23T19:16:17  <wumpus> I think it's quite useful that the release schedule appears as one of the first issues people see
3552017-11-23T19:16:30  <Provoostenator> Has Google Summer of Code ever done Bitcoin Core projects? https://developers.google.com/open-source/gsoc/
3562017-11-23T19:16:32  <wumpus> can't really think of a way that would confuse anyone
3572017-11-23T19:16:48  <achow101> wumpus: it was mostly confusion as to why that was there
3582017-11-23T19:16:50  <Provoostenator> I participated in that in 2008 and it was a great experience. I haven't followed the program since though.
3592017-11-23T19:17:44  <wumpus> we've never done that AFAIK
3602017-11-23T19:17:45  <Provoostenator> And they require a mentor from the project. I'm open to volunteer as a mentor.
3612017-11-23T19:18:16  <wumpus> if anyone has a proposal for a project that would be a good fit for it we could try, but I'm not sure
3622017-11-23T19:18:28  <achow101> redo the wallet
3632017-11-23T19:18:34  <sipa> achow101: lol
3642017-11-23T19:18:35  <achow101> ;)
3652017-11-23T19:18:37  <promag> ah
3662017-11-23T19:18:38  <jonasschnelli> heh...
3672017-11-23T19:18:52  <jonasschnelli> that's actually the topic i'd like to talk about
3682017-11-23T19:18:55  <jonasschnelli> (serious)
3692017-11-23T19:18:58  <aj> (integrated qt blockchain explorer?)
3702017-11-23T19:19:43  <Provoostenator> I don't know if we'd need to propose a project, or whether the student proposes a project (in coordination with a mentor).
3712017-11-23T19:19:47  <Provoostenator> I'll read up on it.
3722017-11-23T19:19:52  <jonasschnelli> sipa: your design documents states that there are a lot of changes that have to be made to the wallet,.. and...
3732017-11-23T19:20:12  <jonasschnelli> since we have multiwallet, would it not be simpler to add a 2nd wallet implementation that could be selective used for new wallets?
3742017-11-23T19:20:14  <wumpus> here, a PR by first-time contributor that gets a lot of review instantly: https://github.com/bitcoin/bitcoin/pull/11747
3752017-11-23T19:20:18  <sipa> jonasschnelli: i'm very happy to talk about that
3762017-11-23T19:20:29  <sipa> jonasschnelli: i really don't think so
3772017-11-23T19:20:39  <sipa> i've considered making a second wallet too, but it
3782017-11-23T19:20:48  <sipa> 's a pointless exercise i think
3792017-11-23T19:20:55  <wumpus> that was discussed so many times over the years
3802017-11-23T19:20:59  <achow101> jonasschnelli: I think it would be better to just make a new wallet format entirely and make it completely backwards incompatible
3812017-11-23T19:21:01  <Provoostenator> @wumpus new tickets always get tons of attention. It's the stale ones that worry me.
3822017-11-23T19:21:10  <sipa> achow101: indeed
3832017-11-23T19:21:16  <sipa> achow101: seen my writeup? :)
3842017-11-23T19:21:20  <achow101> sipa: yeah
3852017-11-23T19:21:20  <Provoostenator> And a new contributor might just pick the wrong topic (like making RBF a default :-)
3862017-11-23T19:21:31  <promag> sipa: >  pointless exercise i think - why?
3872017-11-23T19:21:37  <wumpus> Provoostenator: I don't think it's about newness in this case - the person explained clearly what the issue was, then fixed it, with a straightforward patch
3882017-11-23T19:21:46  <sipa> promag: those who don't know history are doomed to repeat it
3892017-11-23T19:21:52  <jonasschnelli> achow101, sipa: but wouldn't this end up in have a large amount of code handling the back. compatibilizt?
3902017-11-23T19:22:08  <wumpus> Provoostenator: it's also about communication and doing something people care about :)
3912017-11-23T19:22:18  <promag> sipa: and those that know history?
3922017-11-23T19:22:26  <jonasschnelli> I don't mean rewrite the wallet, I mean copy the wallet souces, remove accounts, remove pools, remove all the upgrade migrations, add new SW stuff
3932017-11-23T19:22:43  <jonasschnelli> same same but different
3942017-11-23T19:22:49  <sipa> promag: will have much more impact working on existing code, rather than starting over and hoping it will attract review attention
3952017-11-23T19:22:49  <wumpus> yeah...
3962017-11-23T19:23:10  <jonasschnelli> that's a point
3972017-11-23T19:23:20  <wumpus> jonasschnelli: well accounts should be removed out from the current source, not a copy
3982017-11-23T19:23:26  <sipa> ack
3992017-11-23T19:23:28  <wumpus> jonasschnelli: same for some of those other things
4002017-11-23T19:23:52  <jonasschnelli> I just fear the migration at statup thing...
4012017-11-23T19:24:06  <jonasschnelli> also,... that we keep BDB4.8 until core 0.25
4022017-11-23T19:24:28  <sipa> heh, swapping out the storage format seems orthogonal
4032017-11-23T19:24:44  <wumpus> changing the storage format to another database is pretty easy
4042017-11-23T19:24:46  <achow101> jonasschnelli: does it need to migrate at startup?
4052017-11-23T19:24:57  <wumpus> I changed it locally to leveldb a while ago
4062017-11-23T19:25:02  <sipa> jonasschnelli: for the storage format, it think it should be done independently from everything else
4072017-11-23T19:25:25  <sipa> so that it is a straight translation from one db to another, and none of the key/values inside change meaning
4082017-11-23T19:25:33  <sipa> which means upgrade and downgrade are trivial
4092017-11-23T19:25:40  <wumpus> (because I didn't want to port berkeleydb to that environment)
4102017-11-23T19:25:44  <wumpus> exactly sipa
4112017-11-23T19:25:56  <jonasschnelli> Yes. Right
4122017-11-23T19:26:29  <sipa> _independently_ we should think about a new semantic layer (see my writeup, for part of that), which will be an incompatible upgrade at some point i expect
4132017-11-23T19:26:46  <sipa> but it doesn't need to happen at the same time as the storage layer change
4142017-11-23T19:26:55  *** promag has quit IRC
4152017-11-23T19:27:10  <jonasschnelli> sipa: you mean the record type schemantics?
4162017-11-23T19:27:17  <sipa> yes
4172017-11-23T19:27:30  <achow101> sipa: it seems like a storage layer change would be the easiest way to guarantee incompatibility
4182017-11-23T19:27:44  <wumpus> my biggest annoyance about the current wallet is that it reads everything into memory, it's a database ffs
4192017-11-23T19:27:48  <sipa> achow101: version numbers work pretty well :)
4202017-11-23T19:28:02  <jonasschnelli> sipa: you wrote "Conversion of old wallet to new ones will probably be the trickiest part. It will involve a one-time operation at startup"....
4212017-11-23T19:28:09  <sipa> jonasschnelli: yes
4222017-11-23T19:28:09  <achow101> sipa: but then you have two incompatible upgrades, versus one
4232017-11-23T19:28:11  <wumpus> there's no need to have all transactions and crap going back years in memory
4242017-11-23T19:28:21  <sipa> achow101: storage layer wouldn't be incompatible
4252017-11-23T19:29:10  <achow101> why would they be compatible? Older software wouldn't be able to read a new storage format
4262017-11-23T19:29:14  *** laurentmt has quit IRC
4272017-11-23T19:29:16  <jonasschnelli> I gust questioning the endless backward compatibility. If we don't do us a favor and set a point (version X) where the wallet crated with version X will no longer be backware comp.
4282017-11-23T19:29:20  *** promag has joined #bitcoin-core-dev
4292017-11-23T19:29:24  <sipa> sure, but both upgrade and downgrade would be trivial
4302017-11-23T19:30:07  <sipa> both things can happen in the same release, and that would certainly be more convenient
4312017-11-23T19:30:13  <wumpus> jonasschnelli: backwards compatibility is extremely important, though it'd be fine with me if that's a one-time upgrade at some point
4322017-11-23T19:30:14  <achow101> right, but then you need something that can downgrade it. if you just downgrade the software, it would be incompatible
4332017-11-23T19:30:24  <sipa> but i don't think discussions about changing the storage format should get in the way of semantic changes
4342017-11-23T19:30:26  <wumpus> jonasschnelli: but people with old wallets shouldn't be stuck!
4352017-11-23T19:30:28  <sipa> and the other way around
4362017-11-23T19:30:42  <wumpus> but downgrading seems completely unimportant to me
4372017-11-23T19:30:49  <jonasschnelli> wumpus: Yes. This is why I though keeping the legcy stuff but not mixing the code.
4382017-11-23T19:31:20  <achow101> ooh we could make CWallet, CDB, CWalletDB, etc. actually make sense then!
4392017-11-23T19:31:28  <sipa> hehe
4402017-11-23T19:31:34  <Provoostenator> There's also the possibility of importing old wallet from backups rather than old database files. Obviously not a good experience at all.
4412017-11-23T19:32:00  <wumpus> achow101: some of the classes need renaming, that's orthogonal :)
4422017-11-23T19:32:19  <jonasschnelli> achow101: and there are still some layer violations...
4432017-11-23T19:32:27  <sipa> Provoostenator: ?
4442017-11-23T19:32:36  <sipa> backups are database files
4452017-11-23T19:32:45  <Provoostenator> Oh, it's not using the dump format?
4462017-11-23T19:32:56  <sipa> the dump format is just for keys
4472017-11-23T19:32:58  <wumpus> no, not if you use walletbackup
4482017-11-23T19:33:06  <achow101> Provoostenator: no, it just copies the wallet.dat file to somewhere lese
4492017-11-23T19:33:12  <wumpus> dumpwallet/importwallet is separate
4502017-11-23T19:33:49  <Provoostenator> I see. Having a backup format that's not a database file would be useful then?
4512017-11-23T19:34:12  <sipa> it's complicated
4522017-11-23T19:34:21  <wumpus> what do you want to backup?
4532017-11-23T19:34:28  <wumpus> if it's just the keys, dumpwallet is what you want
4542017-11-23T19:34:28  <sipa> we have two axes really... secret or not, and mutable or not
4552017-11-23T19:34:28  <Provoostenator> Keys and metadata.
4562017-11-23T19:34:42  <wumpus> if you also want transactions and transaction metadata it's kind of difficult
4572017-11-23T19:34:54  <sipa> for example address labels really require a dump after every new address created
4582017-11-23T19:35:13  <sipa> stored transactions (especially unconfirmed ones) need a dump after every transaction
4592017-11-23T19:35:19  * jonasschnelli vanity generated lables!
4602017-11-23T19:35:45  <sipa> but with HD wallets, you don't really need backups at all to prevent monetary loss
4612017-11-23T19:35:56  <Provoostenator> I guess I'd want two backups: 1) the HD seed, done once 2) everything else, done every now and then
4622017-11-23T19:35:57  <sipa> and which of those is more important depends on the use case
4632017-11-23T19:36:15  <sipa> for businesses, losing labels/transactions may be far more harmful than losing some money
4642017-11-23T19:36:36  <wumpus> the hd seed is in dumpwallet, for (2) a backupwallet makes sense
4652017-11-23T19:36:50  <wumpus> if you just want to backup all data why not use the database format itself
4662017-11-23T19:36:52  <Provoostenator> Yes, and businesses need a paper trail for audits, ideally one that doesn't contain a private key.
4672017-11-23T19:37:05  <sipa> so perhaps there should be a way to separate the two
4682017-11-23T19:37:17  <Provoostenator> Because a database format is too specific.
4692017-11-23T19:37:20  <jonasschnelli> sipa: hardware wallets?
4702017-11-23T19:37:43  <wumpus> Provoostenator: too specific for what? the metadata format is also completely specific to this wallet
4712017-11-23T19:37:52  <Provoostenator> There's no bookkeeper / accountant in the world that can handle a .dat file, but they all know CSV or some other more text-like standard.
4722017-11-23T19:38:00  <jonasschnelli> I think long term we should not expect that private keys are on the same machine then bitcoin core runs (at least not with the current one process design)
4732017-11-23T19:38:18  <wumpus> Provoostenator: the GUI can do a csv export of transactions
4742017-11-23T19:38:30  <wumpus> Provoostenator: if that's what you want
4752017-11-23T19:38:48  <wumpus> also you can trivially implement that with a listtransactions then convert the JSON to CSV
4762017-11-23T19:38:58  <wumpus> no need for that to be the client's storage format
4772017-11-23T19:39:54  <wumpus> too many people are trying to solve problems by changing the program's internal storage format to be an external interface
4782017-11-23T19:39:56  <wumpus> that's IMO wrong
4792017-11-23T19:39:56  <Provoostenator> Ah I didn't know that feature. That's a good step and probably the most important metadata.
4802017-11-23T19:40:18  <wumpus> if you want to export something, export it somehow, export exactly the data you need for some reason
4812017-11-23T19:40:35  <wumpus> doesn't need to map to any internal data storage separation
4822017-11-23T19:40:53  <Provoostenator> There's also the issue of long term storage.
4832017-11-23T19:40:54  <wumpus> do you care how mysql stores its files? (besides it being efficient)
4842017-11-23T19:41:14  <Provoostenator> In 50 years a txt dump will be readable, I doubt anyone can still parse the DB format.
4852017-11-23T19:41:29  <wumpus> Provoostenator: that's where the dump format is for!
4862017-11-23T19:41:54  <Provoostenator> @wumpus true
4872017-11-23T19:42:21  <wumpus> it contains the private keys and the HD seed
4882017-11-23T19:42:27  <meshcollider> And if you go and review #11667 then the dump format can include the scripts too ;)
4892017-11-23T19:42:29  <gribble> https://github.com/bitcoin/bitcoin/issues/11667 | Add scripts to dumpwallet RPC by MeshCollider · Pull Request #11667 · bitcoin/bitcoin · GitHub
4902017-11-23T19:42:36  <wumpus> meshcollider: yes!
4912017-11-23T19:42:49  <Provoostenator> @gribble added to my list
4922017-11-23T19:42:59  <wumpus> we have a surprising lot already covered with the current functionality
4932017-11-23T19:43:17  <sipa> i wish we didn't have to continue the "bag-of-keys-and-script" approach in dumps, but i don't think there is a way around it now
4942017-11-23T19:44:03  <wumpus> how do you mean? how would a dump work if it doesn't contain keys and scripts?
4952017-11-23T19:44:12  <sipa> wumpus: read my writeup
4962017-11-23T19:44:45  <Provoostenator> @sipa apart from your (useful) writeup, is there any other good documentation on how the wallet database and in memory storage currently works?
4972017-11-23T19:44:46  <wumpus> at least for compatiblity with other software it's probably useful if it contains all that data
4982017-11-23T19:45:09  <sipa> Provoostenator: https://github.com/bitcoin/bitcoin/tree/master ;)
4992017-11-23T19:45:12  <Provoostenator> And how that's seperated between the RPC and GUI, if at all.
5002017-11-23T19:45:31  <sipa> Provoostenator: there is no separation, they act on the same data structures
5012017-11-23T19:45:33  <jonasschnelli> only the code can tell you
5022017-11-23T19:45:41  <Provoostenator> @sipa I thought so. I'll figure it out eventually, but probably not before you've finished and merged the improvements.
5032017-11-23T19:46:16  <Provoostenator> Is the idea to have the GUI communicate with the RPC and not have direct access to wallet.dat files?
5042017-11-23T19:46:36  <sipa> i don't believe the RPC interface is the right approach
5052017-11-23T19:46:39  <Provoostenator> Or is the GUI not supposed to be completely seperate?
5062017-11-23T19:46:47  <wumpus> what do you hope to accomplish with that?
5072017-11-23T19:46:53  *** Winwin has joined #bitcoin-core-dev
5082017-11-23T19:46:59  <wumpus> besides satisfying some degree of 'code neatness'
5092017-11-23T19:47:04  <sipa> ryanofsky is working on separating the gui from the daemon, but through a specialized interface
5102017-11-23T19:47:11  <sipa> rather than through RPC
5112017-11-23T19:47:29  <Provoostenator> For one thing, running a GUI wallet on a different machine.
5122017-11-23T19:47:52  <wumpus> the RPC is not for remote communication
5132017-11-23T19:47:54  <dejarp> sounds like there needs to be an open standard for wallet files
5142017-11-23T19:47:55  <wumpus> :-)
5152017-11-23T19:48:00  <jonasschnelli> Provoostenator: I think an viable approach here is communicating over the p2p with SPV and BIP150/151
5162017-11-23T19:48:10  <Provoostenator> ACtually to be more precise, I'd like to keep the blockchain on a seperate machine
5172017-11-23T19:48:10  <sipa> Provoostenator: running a GUI *wallet* on a different machine (from the node)? or running a *GUI* on the a different machine (from the wallet)
5182017-11-23T19:48:24  <sipa> Provoostenator: lightweight mode is the way to go there
5192017-11-23T19:48:43  <sipa> Provoostenator: run several lightweight node+wallet instances, have them connect to a trusted full node
5202017-11-23T19:48:45  <Provoostenator> @sipa the first is good enough.
5212017-11-23T19:48:46  <jonasschnelli> Provoostenator: please review https://github.com/bitcoin/bitcoin/pull/10794 (its a stepping stone for GUI sep.)
5222017-11-23T19:49:14  <sipa> jonasschnelli: no it isn't?
5232017-11-23T19:49:22  <jonasschnelli> sipa: why not?
5242017-11-23T19:49:27  <Provoostenator> @jonasschnelli added to list. Good to understand the context.
5252017-11-23T19:49:38  <Provoostenator> (actually that was already on my review list :-)
5262017-11-23T19:50:14  <sipa> jonasschnelli: GUI separation is about sepating the wallet from the UI
5272017-11-23T19:50:21  <sipa> jonasschnelli: that PR is about separating the wallet from the node
5282017-11-23T19:50:35  <jonasschnelli> sipa: I though we are talking about bothj
5292017-11-23T19:50:46  <Provoostenator> Do I understand correctly that it still needs to download blocks?
5302017-11-23T19:50:47  <jonasschnelli> GUI from the wallet is a different things...
5312017-11-23T19:50:51  <sipa> jonasschnelli: yes, but they're entirely orthogonal
5322017-11-23T19:51:05  <Provoostenator> I mean, I'd like to be able to tell a node: here's the public keys for my wallet, go watch them, I'll call you if I need anything.
5332017-11-23T19:51:14  <Provoostenator> (a very trusted node obviously)
5342017-11-23T19:51:19  <sipa> jonasschnelli: you're saying that 10794 is a step towards GUI separation... no it isn't, it has nothing to do with it
5352017-11-23T19:51:30  <sipa> it's a step towards separating the wallet from the validation
5362017-11-23T19:51:43  <meshcollider> Provoostenator: isn't that exactly what SPV does with bloom filters
5372017-11-23T19:51:45  <wumpus> Provoostenator: FWIW that's how electrum works
5382017-11-23T19:51:48  <Provoostenator> And this would also make it easier to connect third party wallets to a full node.
5392017-11-23T19:51:58  <wumpus> Provoostenator: and all other light clients, yeah
5402017-11-23T19:52:02  <jonasschnelli> sipa: I think it is a step towards Provoostenator usecase "run the wallet on a different machine".
5412017-11-23T19:52:13  <sipa> Provoostenator: the P2P protocol already supports that fine
5422017-11-23T19:52:30  <Provoostenator> Bloom filters seem overkill if you trust the node (and encryption and such are fixed)
5432017-11-23T19:52:44  <jonasschnelli> Provoostenator: yes. But the code is there and works. :)
5442017-11-23T19:53:12  <wumpus> yes, bloom filters work right now
5452017-11-23T19:53:20  <wumpus> there's been so much discussion of doing other things
5462017-11-23T19:53:21  <wumpus> for years
5472017-11-23T19:53:36  <jonasschnelli> Provoostenator: and it would also allow one to scarify privacy and connect to a random peer in case his trusted peer is unavailable
5482017-11-23T19:53:44  *** ekrok has quit IRC
5492017-11-23T19:53:54  <wumpus> if you want the just-send-pubkeys approach, look at the electrum protocol
5502017-11-23T19:54:01  <Provoostenator> Working code and random-peer-fallback is certainly a benefit.
5512017-11-23T19:54:53  <wumpus> run your own trusted electrum server, the client-to-server protocol is encrypted, so you're covered there
5522017-11-23T19:55:22  <Provoostenator> @wumpus doesn't the electrum server need a huge database on top of the blockchain storage?
5532017-11-23T19:55:25  <wumpus> no need to reinvent everything in the ecosystem just to put the 'core' label on it
5542017-11-23T19:55:34  <wumpus> Provoostenator: yes, that's what you need for *general* querying by pubkey
5552017-11-23T19:56:05  <wumpus> Provoostenator: if your wallet keeps its own state and tracks the blockchain, then you don't need that, that's more like SPV clients
5562017-11-23T19:56:15  <wumpus> Provoostenator: it's a compromise
5572017-11-23T19:56:25  <Provoostenator> Watch-only addresses are another route, right?
5582017-11-23T19:56:44  <Provoostenator> So you'd give your trusted node a set of addresses to watch moving forward, and then you use bloom filters to get info later.
5592017-11-23T19:57:14  <Provoostenator> So then the only new feature is watch-only addresses, if I understand correctly (no idea how hard that is).
5602017-11-23T19:58:06  <wumpus> watch-only addresses have been supported for ages, for example the joinmarket wallet uses them
5612017-11-23T20:00:04  <sipa> though you query them over RPC, not via P2P-Bloom
5622017-11-23T20:00:10  <wumpus> importaddress was first added in 0.10.0
5632017-11-23T20:00:13  <jtimon> oops, missed the meeting...
5642017-11-23T20:00:19  <wumpus> yes... they're completely separate
5652017-11-23T20:00:24  <wumpus> jtimon: there was no meeting, thanksgiving
5662017-11-23T20:00:33  *** dcousens has quit IRC
5672017-11-23T20:00:34  <jtimon> oh, ok
5682017-11-23T20:01:49  *** ekrok has joined #bitcoin-core-dev
5692017-11-23T20:02:50  *** dcousens has joined #bitcoin-core-dev
5702017-11-23T20:04:29  <Provoostenator> I need to read up on what bloom filter functionality is in Core.
5712017-11-23T20:04:46  *** Winwin has quit IRC
5722017-11-23T20:05:34  <wumpus> Provoostenator: https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
5732017-11-23T20:05:35  <sipa> BIP37
5742017-11-23T20:06:46  <bitcoin-git> [bitcoin] ldm5180 opened pull request #11760: [crypto] Refactor HMAC_SHA to eliminate code duplication (master...generic-hmac_sha) https://github.com/bitcoin/bitcoin/pull/11760
5752017-11-23T20:08:34  * jonasschnelli not sure if new contributors should fiddle with the SHA256 code
5762017-11-23T20:09:16  <Varunram> Hey, I'm new here but thanks for the attention to new devs, it'll help a lot!
5772017-11-23T20:10:48  <Varunram> I'd like to pitch in regarding GSoC, applications open january 4, if core is interested. You guys will be required to propose a project (or at least a list of possible projects) and applicants will have to choose from them. First time orgs get only 1-2 slots though
5782017-11-23T20:11:00  *** dejarp has quit IRC
5792017-11-23T20:12:07  <Varunram> Doesn't matter for a big project like Core, but still, my 2 sats :)
5802017-11-23T20:12:35  *** wunpunch has joined #bitcoin-core-dev
5812017-11-23T20:14:10  <wumpus> Varunram: thanks for the info - but yes we'll have to think a bit about possible projects then,maybe a topic for next meeting
5822017-11-23T20:20:03  *** SopaXorzTaker has quit IRC
5832017-11-23T20:21:31  <Provoostenator> wumpus: so IIUC: SPV uses more bandwidth than the just-send-pubkeys approach, but doesn't require running an electrum server?
5842017-11-23T20:22:04  <Provoostenator> jonasschnelli: and IIUC your goal with #10794 is to pave the way to run a Core wallet in SPV mode?
5852017-11-23T20:22:07  <gribble> https://github.com/bitcoin/bitcoin/issues/10794 | Add simple light-client mode (RPC only) by jonasschnelli · Pull Request #10794 · bitcoin/bitcoin · GitHub
5862017-11-23T20:24:53  <jonasschnelli> Provoostenator: SPV (especially full block without client side filtering) takes much more bandwith...
5872017-11-23T20:25:12  <Provoostenator> I should have more specific: to use bloom filters?
5882017-11-23T20:25:18  <jonasschnelli> Electrum does not preserve your privacy
5892017-11-23T20:25:25  <jonasschnelli> Bloom filter also not
5902017-11-23T20:25:30  <jonasschnelli> *filters
5912017-11-23T20:25:35  <Provoostenator> Well, it does if it's my own machine :-)
5922017-11-23T20:25:52  <jonasschnelli> Yes.. and if the channel is encrypted and authenticated.
5932017-11-23T20:26:02  <jonasschnelli> BF would be okay if BIP150/151
5942017-11-23T20:26:10  <Provoostenator> I'm trying to think about the use case where I have my own full node in some place, but I want to make transactions on my computer / phone / wherever.
5952017-11-23T20:26:19  <Provoostenator> And understanding the various trade-offs.
5962017-11-23T20:26:24  <wumpus> electrum uses TLS by default, FWIW
5972017-11-23T20:26:32  <jonasschnelli> Provoostenator: I see two solutions for that...
5982017-11-23T20:26:53  <Provoostenator> (assuming BIP150/151 for the sake of argument)
5992017-11-23T20:27:02  <jonasschnelli> a) you use BIP150 (or other enc/auth) via p2p and use SPV BF on your phone/remove client
6002017-11-23T20:27:06  <wumpus> as long as you use it with your own server it's ok, and it already exists
6012017-11-23T20:27:23  <jonasschnelli> b) you add a script to your bitcoin core machine that would server over TLS (an RPC proxy)
6022017-11-23T20:27:36  <jonasschnelli> b2) while your remote phone is just an "extended" RPC client
6032017-11-23T20:27:52  <jonasschnelli> (which would also have the private keys)
6042017-11-23T20:28:02  <Provoostenator> An additional contraint is that I would trust the node for giving me correct data, but not for holding private keys. I'm not sure if that's a reasonable contraint.
6052017-11-23T20:28:27  <jonasschnelli> Yes. The probably simplest approach would be SPV BF over auth/enc
6062017-11-23T20:28:35  *** ghost43 has quit IRC
6072017-11-23T20:28:44  *** ghost43 has joined #bitcoin-core-dev
6082017-11-23T20:28:51  <jonasschnelli> 10794 follows also another goal..
6092017-11-23T20:28:59  <jonasschnelli> What if you don't have a remote node?
6102017-11-23T20:29:27  <jonasschnelli> 10794 (and future work) does allow you to use the wallet while your node is still bootstraping
6112017-11-23T20:29:52  <jonasschnelli> My primary goal is to work against the current wallet trend... which is..
6122017-11-23T20:30:03  <Provoostenator> @jonasschnelli b2 might be acceptable with an ecrypted wallet, but a seems better
6132017-11-23T20:30:06  <jonasschnelli> centralized validation, and even remote key holding
6142017-11-23T20:30:17  *** ghost43 has quit IRC
6152017-11-23T20:30:34  *** ghost43 has joined #bitcoin-core-dev
6162017-11-23T20:30:41  <jonasschnelli> The current bitcoin wallets do loose one of the primary elements Bitcoin can defeat "Trusted third parties are security holes".
6172017-11-23T20:30:50  <Provoostenator> I'm thinking e.g. a full node at home, where if someone physcailly breaks in I'd know about that and just not use it.
6182017-11-23T20:30:58  <jonasschnelli> I'd like to see more users using Bitcoin Core as a wallet
6192017-11-23T20:31:40  <Provoostenator> @jonasschnelli me too, but I think a more realistic scenario is more people running Bitcoin Core nodes and connecting their favorite wallet to it.
6202017-11-23T20:31:52  <jonasschnelli> But right now,... the burden is just to hight
6212017-11-23T20:32:03  <jonasschnelli> Provoostenator: both is possible....
6222017-11-23T20:32:19  <Provoostenator> Although with things like #11720 it might be possible, certainly with bloom filters.
6232017-11-23T20:32:20  <gribble> https://github.com/bitcoin/bitcoin/issues/11720 | iOS Deployment Target for RPC · Issue #11720 · bitcoin/bitcoin · GitHub
6242017-11-23T20:32:25  <jonasschnelli> BIP150/151 would work towards trustworthy direct connections
6252017-11-23T20:32:36  <jonasschnelli> Provoostenator: Sure!
6262017-11-23T20:33:08  <Provoostenator> Right, these are all useful ingredients. I'm mostly trying to wrap my head around how they all fit together.
6272017-11-23T20:34:35  <jonasschnelli> With the current RPC calls it would also be possible to write a (iOS) client that would speak over RPC (via a proxy/apache script via TLS)... the client would hold the keys
6282017-11-23T20:34:46  <jonasschnelli> and use fundrawtransaction and watch-onlies
6292017-11-23T20:36:45  <Provoostenator> Something tells me more people will use it if it "just works" and everything happens on the phone.
6302017-11-23T20:37:56  <Provoostenator> Another benefit of using the Core code base is that you don't have to re-invent the wheel for things like coin selection (especially if it gets dramatic improvements in the future).
6312017-11-23T20:38:37  <jonasschnelli> The "just works" approach is very important and a reason why I try to kick BIP150/151 forward even with the fact that it's already sort of possible with stunnel, VPN, TOR
6322017-11-23T20:40:31  <Provoostenator> jonasschnelli: I was quite surprised when I learned encryption wasn't already a thing. I liked your talk: https://www.youtube.com/watch?v=6VZrT9IOq30
6332017-11-23T20:41:37  *** Jack__ has joined #bitcoin-core-dev
6342017-11-23T20:43:10  <wumpus> TIL there's a program called "tig" that is a ncurses (terminal) git UI, I really like it
6352017-11-23T20:44:39  *** promag has quit IRC
6362017-11-23T20:44:46  * jonasschnelli executing "brew install tig"
6372017-11-23T20:44:58  <jonasschnelli> looks nice
6382017-11-23T20:46:00  *** Jack__ has quit IRC
6392017-11-23T20:46:30  <wumpus> yes I'm surprised I hadn't heard about it before
6402017-11-23T20:48:35  <Provoostenator> Speaking of tools: any favorite IRC clients for OSX? And a good way to setup email notifications if someone mentions you when you're offline? I'm trying to set that up through the Slack bridge now.
6412017-11-23T20:51:22  *** dejarp has joined #bitcoin-core-dev
6422017-11-23T20:51:35  *** BGL has joined #bitcoin-core-dev
6432017-11-23T20:53:25  <sipa> Provoostenator: i use ssh + screen + irssi
6442017-11-23T20:53:25  <wumpus> dunno about mail notifications, but I kind of like quassel, it has a separate frontend and backend, so from whatever device you log in your backlog is there, including highlights if someone mentioned you
6452017-11-23T20:54:05  <jonasschnelli> Provoostenator: I use Textual 7 (macOS) with a ZNC bouncer
6462017-11-23T20:54:23  <jonasschnelli> Provoostenator: I use a ZNC mod that sends me a Telegram on PM
6472017-11-23T20:54:35  <wumpus> there's also a pyquassel to connect programmatically, it's possible to watch for messages and set up things like mail notification or other scripting
6482017-11-23T20:54:37  <jonasschnelli> (the mod has various push channels)
6492017-11-23T20:55:13  <jonasschnelli> Provoostenator: ZNC is you IRC swiss army knife... also can log for you, etc.
6502017-11-23T20:55:18  <wumpus> but yeah you can do the same with irssi - there's even an irssi based frontend for quassel if you want to combine them :-)
6512017-11-23T20:57:48  *** ghost43 has quit IRC
6522017-11-23T20:59:07  <Provoostenator> Thanks, I'll take a look at both approaches.
6532017-11-23T20:59:33  *** ghost43 has joined #bitcoin-core-dev
6542017-11-23T20:59:41  *** Provoostenator has quit IRC
6552017-11-23T21:05:48  *** ghost43 has quit IRC
6562017-11-23T21:10:11  *** ghost43 has joined #bitcoin-core-dev
6572017-11-23T21:11:59  *** Randolf has quit IRC
6582017-11-23T21:12:10  <wumpus> github's commit notifier is broken again
6592017-11-23T21:14:35  *** dejarp has quit IRC
6602017-11-23T21:17:53  <jonasschnelli> wumpus: the twitter bridge worked... only IRC?
6612017-11-23T21:19:20  <wumpus> jonasschnelli: seems so!
6622017-11-23T21:21:16  *** ghost43 has quit IRC
6632017-11-23T21:21:39  *** Randolf has joined #bitcoin-core-dev
6642017-11-23T21:24:42  *** jb55 has quit IRC
6652017-11-23T21:25:53  *** Randolf has quit IRC
6662017-11-23T21:26:21  *** ghost43 has joined #bitcoin-core-dev
6672017-11-23T21:41:30  *** btcdrak has joined #bitcoin-core-dev
6682017-11-23T21:48:50  *** Ge0rges has joined #bitcoin-core-dev
6692017-11-23T21:58:32  *** wunpunch has quit IRC
6702017-11-23T21:58:52  *** wunpunch has joined #bitcoin-core-dev
6712017-11-23T22:00:01  *** booyah_ is now known as booyah
6722017-11-23T22:15:26  *** jb55 has joined #bitcoin-core-dev
6732017-11-23T22:16:14  *** Randolf has joined #bitcoin-core-dev
6742017-11-23T22:21:56  <phantomcircuit> wumpus, i like znc more than quassel
6752017-11-23T22:22:23  <wumpus> ok, I prefer quassel
6762017-11-23T22:24:00  *** meshcollider has quit IRC
6772017-11-23T22:24:01  <sipa> real programmers use telnet, and speak RFC2812 natively
6782017-11-23T22:25:44  <wumpus> hah
6792017-11-23T22:26:30  <phantomcircuit> sipa, gl replying to pings in time from freenode
6802017-11-23T22:27:02  *** telnetuser has joined #bitcoin-core-dev
6812017-11-23T22:27:11  *** Randolf has quit IRC
6822017-11-23T22:27:49  <telnetuser> @phantomcircuit no problem, you'll see!
6832017-11-23T22:30:23  <wumpus> phantomcircuit: no more idlers
6842017-11-23T22:30:53  *** promag has joined #bitcoin-core-dev
6852017-11-23T22:31:26  <phantomcircuit> lol you are using telnet
6862017-11-23T22:31:51  <sipa> damn, how do i type a CTCP version reply? :(
6872017-11-23T22:34:13  *** Randolf has joined #bitcoin-core-dev
6882017-11-23T22:34:42  *** telnetuser has quit IRC
6892017-11-23T22:35:37  <phantomcircuit> sipa, gotcha
6902017-11-23T22:35:45  <phantomcircuit> you have to be able to send 0x01
6912017-11-23T22:36:12  <sipa> yes, i found that out
6922017-11-23T22:36:19  <sipa> but don't know how to do that in telnet
6932017-11-23T22:36:22  <sipa> offtopic i guess :)
6942017-11-23T22:37:17  <wumpus> through xclip maybe
6952017-11-23T22:39:01  <wumpus> or ctrl-A if it works
6962017-11-23T22:45:47  *** Cogito_Ergo_Sum has quit IRC
6972017-11-23T22:50:53  *** timothy has joined #bitcoin-core-dev
6982017-11-23T22:55:21  *** jb55 has quit IRC
6992017-11-23T23:02:40  <phantomcircuit> sipa, fail
7002017-11-23T23:03:21  *** owowo has quit IRC
7012017-11-23T23:11:16  *** promag has quit IRC
7022017-11-23T23:33:09  *** vicenteH has quit IRC
7032017-11-23T23:40:05  *** owowo has joined #bitcoin-core-dev
7042017-11-23T23:47:32  *** Randolf has quit IRC
7052017-11-23T23:59:31  *** promag has joined #bitcoin-core-dev