12018-06-28T00:13:18  *** luke-jr has quit IRC
  22018-06-28T00:13:30  *** luke-jr has joined #bitcoin-core-dev
  32018-06-28T00:28:31  *** Randolf has quit IRC
  42018-06-28T00:32:00  *** BashCo has quit IRC
  52018-06-28T00:34:48  *** BashCo has joined #bitcoin-core-dev
  62018-06-28T00:53:02  *** luke-jr has quit IRC
  72018-06-28T00:53:19  *** luke-jr has joined #bitcoin-core-dev
  82018-06-28T00:55:50  <achow101> travis seems dead, nothing is being built
  92018-06-28T01:15:09  *** Victorsueca has quit IRC
 102018-06-28T01:16:23  *** Victorsueca has joined #bitcoin-core-dev
 112018-06-28T01:17:31  *** bitconner has quit IRC
 122018-06-28T01:38:00  *** Murch has quit IRC
 132018-06-28T01:49:11  *** unholymachine has quit IRC
 142018-06-28T02:33:24  *** AaronvanW has quit IRC
 152018-06-28T02:33:33  *** BashCo has quit IRC
 162018-06-28T02:33:58  *** AaronvanW has joined #bitcoin-core-dev
 172018-06-28T02:34:08  *** bitconner has joined #bitcoin-core-dev
 182018-06-28T02:35:36  *** BashCo has joined #bitcoin-core-dev
 192018-06-28T02:38:39  *** bitconner has quit IRC
 202018-06-28T02:38:39  *** AaronvanW has quit IRC
 212018-06-28T03:04:32  <bitcoin-git> [bitcoin] achow101 opened pull request #13557: BIP 174 PSBT Serializations and RPCs (master...psbt) https://github.com/bitcoin/bitcoin/pull/13557
 222018-06-28T03:07:26  *** bitconner has joined #bitcoin-core-dev
 232018-06-28T03:32:59  *** dbt has joined #bitcoin-core-dev
 242018-06-28T03:43:28  *** BashCo has quit IRC
 252018-06-28T03:47:47  *** BashCo has joined #bitcoin-core-dev
 262018-06-28T04:03:10  *** _flow__ has quit IRC
 272018-06-28T04:12:25  *** _flow__ has joined #bitcoin-core-dev
 282018-06-28T04:15:47  *** Randolf has joined #bitcoin-core-dev
 292018-06-28T04:24:22  *** bitconner has quit IRC
 302018-06-28T04:25:39  *** veleiro has joined #bitcoin-core-dev
 312018-06-28T04:41:29  *** bitconner has joined #bitcoin-core-dev
 322018-06-28T05:09:07  <bitcoin-git> [bitcoin] Empact opened pull request #13558: Drop unused GetType() from CSizeComputer (master...c-size-computer) https://github.com/bitcoin/bitcoin/pull/13558
 332018-06-28T05:11:26  *** Krellan has quit IRC
 342018-06-28T05:12:04  *** Krellan has joined #bitcoin-core-dev
 352018-06-28T05:17:38  *** meshcollider has joined #bitcoin-core-dev
 362018-06-28T05:25:04  *** veleiro` has joined #bitcoin-core-dev
 372018-06-28T05:26:56  *** shesek has joined #bitcoin-core-dev
 382018-06-28T05:26:56  *** shesek has joined #bitcoin-core-dev
 392018-06-28T05:27:17  *** veleiro has quit IRC
 402018-06-28T05:32:21  *** zigen has joined #bitcoin-core-dev
 412018-06-28T05:51:25  *** Murch has joined #bitcoin-core-dev
 422018-06-28T06:11:48  *** arubi has quit IRC
 432018-06-28T06:12:11  *** arubi has joined #bitcoin-core-dev
 442018-06-28T06:17:35  *** jtimon has quit IRC
 452018-06-28T06:20:05  *** veleiro` has quit IRC
 462018-06-28T06:28:34  *** bitconner has quit IRC
 472018-06-28T06:29:48  *** bitconner has joined #bitcoin-core-dev
 482018-06-28T06:39:07  *** rex4539 has joined #bitcoin-core-dev
 492018-06-28T06:39:34  *** squarfed[m] has quit IRC
 502018-06-28T06:43:00  *** squarfed[m] has joined #bitcoin-core-dev
 512018-06-28T06:57:24  <bitcoin-git> [bitcoin] Empact opened pull request #13560: Drop unused serialization support from CAddresss (master...caddress-serialization) https://github.com/bitcoin/bitcoin/pull/13560
 522018-06-28T07:09:10  <provoostenator> I'm getting crashes during IBD of a pruned node on one of my ARM devices. It tends to happen during later prune events (e.g. 2015). I set a fairly high dbcache, but during those events dbcache is << RAM (and there's a swap).
 532018-06-28T07:09:39  <provoostenator> Worse, it sometimes tells me to reindex.
 542018-06-28T07:10:39  <provoostenator> Log shows no indication of why it crashed, but my SSH connection to the machine tends to die when it happens, which does suggest OOM?
 552018-06-28T07:12:59  <provoostenator> Perhaps it's just crappy hardware, but given the weird behavior with pruned nodes and large dbcache in IBD I saw in #12404, might indicate some subtle bug.
 562018-06-28T07:13:02  <gribble> https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
 572018-06-28T07:15:29  *** Squidicuz has quit IRC
 582018-06-28T07:18:21  *** Krellan has quit IRC
 592018-06-28T07:19:08  *** Krellan has joined #bitcoin-core-dev
 602018-06-28T07:26:24  *** Randolf has quit IRC
 612018-06-28T07:49:29  *** Murch has quit IRC
 622018-06-28T08:02:10  *** tripleslash has quit IRC
 632018-06-28T08:04:10  *** tripleslash has joined #bitcoin-core-dev
 642018-06-28T08:04:17  *** adam3us has quit IRC
 652018-06-28T08:04:17  *** warren has quit IRC
 662018-06-28T08:06:53  *** adam3us has joined #bitcoin-core-dev
 672018-06-28T08:06:55  *** warren has joined #bitcoin-core-dev
 682018-06-28T08:07:15  *** tripleslash has quit IRC
 692018-06-28T08:12:01  *** d9b4bef9 has quit IRC
 702018-06-28T08:13:15  *** d9b4bef9 has joined #bitcoin-core-dev
 712018-06-28T08:20:30  *** tripleslash has joined #bitcoin-core-dev
 722018-06-28T08:23:06  <bitcoin-git> [bitcoin] Empact closed pull request #13560: WIP: Drop unused serialization support from CAddresss (master...caddress-serialization) https://github.com/bitcoin/bitcoin/pull/13560
 732018-06-28T08:24:34  *** Krellan has quit IRC
 742018-06-28T08:26:55  *** tripleslash has quit IRC
 752018-06-28T08:31:50  *** tripleslash has joined #bitcoin-core-dev
 762018-06-28T08:33:33  *** timothy has joined #bitcoin-core-dev
 772018-06-28T08:57:18  *** promag has joined #bitcoin-core-dev
 782018-06-28T09:13:20  <bitcoin-git> [bitcoin] droark opened pull request #13561: Qt: Remove unnecessary image buffer for Mac dock icon (master...rm_icon_buffer) https://github.com/bitcoin/bitcoin/pull/13561
 792018-06-28T09:16:21  *** laurentmt has joined #bitcoin-core-dev
 802018-06-28T09:17:21  *** meshcollider has quit IRC
 812018-06-28T09:27:28  *** laurentmt has quit IRC
 822018-06-28T09:28:12  *** Sentineo has joined #bitcoin-core-dev
 832018-06-28T09:34:38  *** AaronvanW has joined #bitcoin-core-dev
 842018-06-28T09:37:57  *** Aaronvan_ has joined #bitcoin-core-dev
 852018-06-28T09:39:52  *** AaronvanW has quit IRC
 862018-06-28T09:39:58  *** Aaronva__ has joined #bitcoin-core-dev
 872018-06-28T09:42:39  *** arubi has quit IRC
 882018-06-28T09:43:30  *** Aaronvan_ has quit IRC
 892018-06-28T09:47:34  *** arubi has joined #bitcoin-core-dev
 902018-06-28T09:53:11  <jonasschnelli> Anyone willing to pre-review a BIP proposal for encrypted wallet seeds https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991? gmaxwell, sipa, roasbeef
 912018-06-28T09:58:01  *** ExtraCrispy has joined #bitcoin-core-dev
 922018-06-28T10:09:47  *** jtimon has joined #bitcoin-core-dev
 932018-06-28T10:17:07  *** quer has joined #bitcoin-core-dev
 942018-06-28T10:18:12  *** dbt has left #bitcoin-core-dev
 952018-06-28T10:25:10  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13562: travis: Switch back to trusty for now (master...Mf1806-qaTravisTrusty) https://github.com/bitcoin/bitcoin/pull/13562
 962018-06-28T10:31:38  *** Guyver2 has joined #bitcoin-core-dev
 972018-06-28T10:32:51  <promag> mac build in travis uses qt5.7.1?
 982018-06-28T10:34:54  *** wolfspraul has joined #bitcoin-core-dev
 992018-06-28T10:41:23  *** bitconner has quit IRC
1002018-06-28T10:51:28  <bitcoin-git> [bitcoin] promag opened pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
1012018-06-28T10:53:42  <promag> MarcoFalke: is that what you mean?
1022018-06-28T11:05:44  *** unholymachine has joined #bitcoin-core-dev
1032018-06-28T11:13:12  *** bitconner has joined #bitcoin-core-dev
1042018-06-28T11:22:40  *** bitconner has quit IRC
1052018-06-28T11:37:47  *** bitconner has joined #bitcoin-core-dev
1062018-06-28T11:42:54  *** bitconner has quit IRC
1072018-06-28T11:43:10  *** bitconner has joined #bitcoin-core-dev
1082018-06-28T11:48:12  *** bitconner has quit IRC
1092018-06-28T12:07:10  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d96bdd78307b...2328039bfc49
1102018-06-28T12:07:10  <bitcoin-git> bitcoin/master fa103a5 MarcoFalke: [qa] wallet_basic: Specify minimum required amount for listunspent
1112018-06-28T12:07:11  <bitcoin-git> bitcoin/master 2328039 MarcoFalke: Merge #13535: [qa] wallet_basic: Specify minimum required amount for listunspent...
1122018-06-28T12:08:07  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13535: [qa] wallet_basic: Specify minimum required amount for listunspent (master...Mf1806-qaWalletBasic) https://github.com/bitcoin/bitcoin/pull/13535
1132018-06-28T12:10:18  *** Aaronva__ is now known as AaronvanW
1142018-06-28T12:11:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2328039bfc49...c93c360eec4d
1152018-06-28T12:11:05  <bitcoin-git> bitcoin/master ea49e06 practicalswift: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok
1162018-06-28T12:11:06  <bitcoin-git> bitcoin/master c93c360 MarcoFalke: Merge #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok...
1172018-06-28T12:11:55  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok (master...truth-in-advertising) https://github.com/bitcoin/bitcoin/pull/13551
1182018-06-28T12:22:35  *** BoxerJack3 has joined #bitcoin-core-dev
1192018-06-28T12:25:42  *** bitconner has joined #bitcoin-core-dev
1202018-06-28T12:26:27  *** quer has quit IRC
1212018-06-28T12:27:23  *** quer has joined #bitcoin-core-dev
1222018-06-28T12:31:29  *** quer has quit IRC
1232018-06-28T12:31:38  *** quer_ has joined #bitcoin-core-dev
1242018-06-28T12:32:17  *** BoxerJack3 has quit IRC
1252018-06-28T12:32:44  *** BoxerJack3 has joined #bitcoin-core-dev
1262018-06-28T12:32:57  *** intcat has quit IRC
1272018-06-28T12:36:34  *** intcat has joined #bitcoin-core-dev
1282018-06-28T12:38:00  *** BoxerJack3 has quit IRC
1292018-06-28T12:40:34  *** bitconner has quit IRC
1302018-06-28T12:42:51  *** schnerchi123 has joined #bitcoin-core-dev
1312018-06-28T13:15:01  *** d9b4bef9 has quit IRC
1322018-06-28T13:16:08  *** d9b4bef9 has joined #bitcoin-core-dev
1332018-06-28T13:18:22  *** bitconner has joined #bitcoin-core-dev
1342018-06-28T13:22:57  *** bitconner has quit IRC
1352018-06-28T13:25:10  *** bedo has joined #bitcoin-core-dev
1362018-06-28T13:34:42  <promag> qt: funny thing, connect(..., &Foo::foo) doesn't work if foo is a private slot, BUT connect(..., SLOT(foo()) works..
1372018-06-28T13:35:21  <bedo> Hi all, it's only me or the testnet are generating crazy amount of block?
1382018-06-28T13:44:25  <jonasschnelli> bedo: yes. Someone mining with an ASIC farm I guess
1392018-06-28T13:44:55  <jonasschnelli> 4-5 seconds interval between blocks. :)
1402018-06-28T13:46:34  <bedo> jonasschnelli: today is hard day for develop over bitcoin
1412018-06-28T13:47:34  <jonasschnelli> bedo: use regtest. :)
1422018-06-28T13:47:57  *** Lightblock_ has joined #bitcoin-core-dev
1432018-06-28T13:48:12  <Lightblock_> Hi
1442018-06-28T13:48:20  <Lightblock_> happy to be here
1452018-06-28T13:48:46  *** Lightblock__ has joined #bitcoin-core-dev
1462018-06-28T13:49:44  <Lightblock_> sorry if silly question, could anyone please suggest a proper way to the bitcoin transaction ID given that I know the blockheight txindex and outputindex ?
1472018-06-28T13:50:11  *** lnostdal has quit IRC
1482018-06-28T13:52:12  <Lightblock_> sorry, seems like I have put in the worng channel
1492018-06-28T13:52:23  <Lightblock_> nevermind, asked in the #bitcoin already
1502018-06-28T13:53:09  *** lnostdal has joined #bitcoin-core-dev
1512018-06-28T13:53:23  <bedo> jonasschnelli: yep, is the only way,  will see you at BOB?
1522018-06-28T13:54:12  <jonasschnelli> bedo: Yes. Sure!
1532018-06-28T13:56:26  <bedo> jonasschnelli: perfect ;)
1542018-06-28T14:14:13  *** piootr has joined #bitcoin-core-dev
1552018-06-28T14:28:00  *** Lightblock_ has quit IRC
1562018-06-28T14:28:16  *** echonaut8 has joined #bitcoin-core-dev
1572018-06-28T14:28:40  *** echonaut has quit IRC
1582018-06-28T14:30:04  *** unholymachine has quit IRC
1592018-06-28T14:31:13  *** Murch has joined #bitcoin-core-dev
1602018-06-28T14:34:35  *** bitconner has joined #bitcoin-core-dev
1612018-06-28T14:54:04  *** belcher has joined #bitcoin-core-dev
1622018-06-28T14:59:05  *** infernix has quit IRC
1632018-06-28T15:00:09  *** rex4539 has quit IRC
1642018-06-28T15:01:50  *** m8tion has joined #bitcoin-core-dev
1652018-06-28T15:07:40  *** piootr has quit IRC
1662018-06-28T15:19:10  *** ossifrage has quit IRC
1672018-06-28T15:21:47  *** infernix has joined #bitcoin-core-dev
1682018-06-28T15:38:11  *** bedo has quit IRC
1692018-06-28T15:39:41  *** bitconner has quit IRC
1702018-06-28T15:47:40  *** bitconner has joined #bitcoin-core-dev
1712018-06-28T15:52:34  *** bitconner has quit IRC
1722018-06-28T15:57:45  *** m8tion has quit IRC
1732018-06-28T15:58:48  *** m8tion has joined #bitcoin-core-dev
1742018-06-28T15:59:11  *** anthis has quit IRC
1752018-06-28T16:00:18  *** anthis has joined #bitcoin-core-dev
1762018-06-28T16:01:21  *** jtimon has quit IRC
1772018-06-28T16:08:10  *** opdenkamp has quit IRC
1782018-06-28T16:16:00  *** bitconner has joined #bitcoin-core-dev
1792018-06-28T16:20:04  *** Krellan has joined #bitcoin-core-dev
1802018-06-28T16:20:27  *** bitconner has quit IRC
1812018-06-28T16:27:33  *** promag has quit IRC
1822018-06-28T16:30:03  *** Murch has quit IRC
1832018-06-28T16:31:11  *** Murch has joined #bitcoin-core-dev
1842018-06-28T16:33:33  *** unholymachine has joined #bitcoin-core-dev
1852018-06-28T16:39:20  *** ossifrage has joined #bitcoin-core-dev
1862018-06-28T16:41:20  *** promag has joined #bitcoin-core-dev
1872018-06-28T16:48:44  *** m8tion has quit IRC
1882018-06-28T16:50:22  *** m8tion has joined #bitcoin-core-dev
1892018-06-28T16:51:20  *** opdenkamp has joined #bitcoin-core-dev
1902018-06-28T16:52:05  *** rex4539 has joined #bitcoin-core-dev
1912018-06-28T16:57:19  *** Lightblock has joined #bitcoin-core-dev
1922018-06-28T17:02:23  *** bitconner has joined #bitcoin-core-dev
1932018-06-28T17:13:40  *** Lightblock has quit IRC
1942018-06-28T17:17:02  *** d9b4bef9 has quit IRC
1952018-06-28T17:17:47  *** Krellan has quit IRC
1962018-06-28T17:18:08  *** d9b4bef9 has joined #bitcoin-core-dev
1972018-06-28T17:20:46  *** bitconner has quit IRC
1982018-06-28T17:21:56  *** Giszmo has joined #bitcoin-core-dev
1992018-06-28T17:25:09  *** bitconner has joined #bitcoin-core-dev
2002018-06-28T17:28:30  *** Murch has quit IRC
2012018-06-28T17:29:43  *** promag has quit IRC
2022018-06-28T17:32:54  *** Murch has joined #bitcoin-core-dev
2032018-06-28T17:37:50  <bitcoin-git> [bitcoin] jnewbery opened pull request #13564: [wallet] loadwallet shouldn't create new wallets. (master...dont_load_nonexistent_wallet) https://github.com/bitcoin/bitcoin/pull/13564
2042018-06-28T17:40:37  *** jtimon has joined #bitcoin-core-dev
2052018-06-28T17:43:08  *** drexl has joined #bitcoin-core-dev
2062018-06-28T17:45:27  *** bitconner has quit IRC
2072018-06-28T17:47:58  *** Alexandra has joined #bitcoin-core-dev
2082018-06-28T17:48:10  <Alexandra> Holaaa
2092018-06-28T17:48:57  *** Alexandra has left #bitcoin-core-dev
2102018-06-28T17:51:09  *** laurentmt has joined #bitcoin-core-dev
2112018-06-28T17:52:51  *** laurentmt has quit IRC
2122018-06-28T17:54:14  *** bitconner has joined #bitcoin-core-dev
2132018-06-28T18:07:04  *** intcat has quit IRC
2142018-06-28T18:07:05  *** bitconner has quit IRC
2152018-06-28T18:08:45  *** intcat has joined #bitcoin-core-dev
2162018-06-28T18:13:23  *** bitconner has joined #bitcoin-core-dev
2172018-06-28T18:18:22  *** bitconner has quit IRC
2182018-06-28T18:19:39  *** m8tion has quit IRC
2192018-06-28T18:39:46  *** promag has joined #bitcoin-core-dev
2202018-06-28T18:40:41  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #13461: Wallet: correctly deprecate accounts in getbalance, re-add minconf / include-watch-only (master...2018/06/watch_only_balance) https://github.com/bitcoin/bitcoin/pull/13461
2212018-06-28T18:41:19  *** bitconner has joined #bitcoin-core-dev
2222018-06-28T18:43:59  <bitcoin-git> [bitcoin] Empact opened pull request #13565: Fix AreInputsStandard test to reference the proper scriptPubKey (master...p2sh-tests-pub-key) https://github.com/bitcoin/bitcoin/pull/13565
2232018-06-28T18:46:59  *** promag has quit IRC
2242018-06-28T18:48:18  *** belcher_ has joined #bitcoin-core-dev
2252018-06-28T18:50:21  *** Murch has quit IRC
2262018-06-28T18:51:37  *** belcher has quit IRC
2272018-06-28T18:58:48  *** promag has joined #bitcoin-core-dev
2282018-06-28T19:00:56  <wumpus> #startmeeting
2292018-06-28T19:00:56  <lightningbot> Meeting started Thu Jun 28 19:00:56 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2302018-06-28T19:00:56  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2312018-06-28T19:01:12  <achow101> hi
2322018-06-28T19:01:17  <sipa> hi
2332018-06-28T19:01:24  <jonasschnelli> hi
2342018-06-28T19:01:24  <cfields> hi
2352018-06-28T19:01:43  <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 provoostenator
2362018-06-28T19:02:06  <promag> hi
2372018-06-28T19:02:08  <kanzure> hi.
2382018-06-28T19:02:12  <instagibbs> hi
2392018-06-28T19:02:23  <jnewbery> half a hi. May be a little distracted for the next ~45 minutes
2402018-06-28T19:02:37  <wumpus> I've had a really crappy week so haven't been able to do much, sorry for that
2412018-06-28T19:02:49  <sipa> sorry to hear that
2422018-06-28T19:02:58  <wumpus> #topic high priority for review
2432018-06-28T19:03:42  <sipa> Currently on the list: #13425 #12196 #13062
2442018-06-28T19:03:45  <gribble> https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
2452018-06-28T19:03:47  <cfields> wumpus: :(
2462018-06-28T19:03:49  <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
2472018-06-28T19:03:52  <wumpus> only three PRs!
2482018-06-28T19:03:52  <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
2492018-06-28T19:04:26  <jonasschnelli> For 12196, I'm not sure if it make sense to adopt sipas output scripts descriptors in the PR itself (or later)
2502018-06-28T19:04:33  <sipa> i'd like to bring up an idea i've been working on for future wallet design/ismine logic, which may interact with #12196
2512018-06-28T19:04:35  <jonasschnelli> (since it already has some reviews/acks)
2522018-06-28T19:04:37  <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
2532018-06-28T19:05:22  <wumpus> jonasschnelli: I think it makes sense to merge something, as you say it has a lot of ACKs, further improvements can be done later unless the current state is really unacceptable
2542018-06-28T19:05:27  <bitcoin-git> [bitcoin] jnewbery opened pull request #13566: Fix get balance (master...fix_get_balance) https://github.com/bitcoin/bitcoin/pull/13566
2552018-06-28T19:05:30  *** meshcollider has joined #bitcoin-core-dev
2562018-06-28T19:05:41  <sipa> wumpus: it's more so that we create something that remains compatible with future APIs
2572018-06-28T19:05:48  <meshcollider> Hi
2582018-06-28T19:06:00  <wumpus> sipa: the API will have to be finalized before the 0.17 release
2592018-06-28T19:06:02  <sipa> (but i understand the desire to merge something; my comment would only apply to the xpub functionality)
2602018-06-28T19:06:37  <wumpus> so FWIW feature freeze for 0.17 is 2018-07-16, if the PR is already merged by then then improvement can be considered a bugfix
2612018-06-28T19:06:49  <sipa> perhaps i should clarify the scope
2622018-06-28T19:06:56  <jonasschnelli> Yes. Please
2632018-06-28T19:07:02  <sipa> my idea for output descriptors is here: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
2642018-06-28T19:07:10  <sipa> i also have a prototype implementation for most of it
2652018-06-28T19:07:23  <wumpus> nice!
2662018-06-28T19:07:47  <jonasschnelli> Yes. I really like it.
2672018-06-28T19:07:47  <promag> wumpus: for 0.17, dyn multi-wallet in the UI is required?
2682018-06-28T19:07:51  <sipa> it is a general language that encodes all information about how to spend a whole set of keys with associated addresses/scripts/private keys/.... into one string, including support for multisig etc
2692018-06-28T19:07:56  <wumpus> promag: why?
2702018-06-28T19:08:15  <promag> it's a question
2712018-06-28T19:08:30  <wumpus> promag: we want toh ave things consistent before a release, at least, apart from that it's simply a matter of what makes it in
2722018-06-28T19:08:45  <sipa> my desire is that the entire wallet moves to something like that (so it's an implementation of my wallet descriptor rant i wrote a while ago: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)
2732018-06-28T19:08:56  <wumpus> I recognized it :)
2742018-06-28T19:09:04  <cfields> sipa: +1, that makes a ton of sense
2752018-06-28T19:09:11  <sipa> so import/export would operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/hdchains/...
2762018-06-28T19:09:17  *** vicenteH has quit IRC
2772018-06-28T19:09:36  *** vicenteH has joined #bitcoin-core-dev
2782018-06-28T19:09:40  <sipa> importmulti is already compatible with that design, for a large extent
2792018-06-28T19:10:15  <sipa> the entirety of that idea is certainly not for 0.17, however
2802018-06-28T19:10:46  <sipa> but that doesn't mean it can't be used already in relatively small scoped things already
2812018-06-28T19:10:52  <sipa> and scanutxoset is one of those
2822018-06-28T19:10:54  <jonasschnelli> what API changes would you propose for scantxoutset so we can migrate towards the output descriptors in the same cycle as migrating importmulti?
2832018-06-28T19:11:01  <wumpus> that would be very last minute, but at least using it as a guideline to be compatible with the current stuff makes sense
2842018-06-28T19:11:23  <sipa> jonasschnelli: you may not like this, but what about just dropping xpub support from the PR right now
2852018-06-28T19:11:36  <jonasschnelli> sipa: this makes the PR pretty useless... :(
2862018-06-28T19:11:42  <sipa> and then i'll PR the descriptor language, together with integration into scanutxoset
2872018-06-28T19:12:06  <sipa> jonasschnelli: i understand
2882018-06-28T19:12:10  <sipa> feel free to disagree
2892018-06-28T19:12:15  <wumpus> it makes sense to divide it up like that
2902018-06-28T19:12:18  <jonasschnelli> But if the API break would be complex and painful, we can do that.
2912018-06-28T19:12:33  <wumpus> makes tha change smaller and less complex
2922018-06-28T19:12:39  <jonasschnelli> I don't disagree... :)
2932018-06-28T19:12:48  <wumpus> (besides sipa's point of course)
2942018-06-28T19:13:11  <sipa> if your concern is that it may not make it in for 0.17, you can still PR the (already written) xpub support as is later, before feature freeze?
2952018-06-28T19:13:37  <jonasschnelli> Sure... I guess its also not utterly bad if the xpub will be in 0.18.
2962018-06-28T19:13:47  <jonasschnelli> Okay. Will remove the xpub stuff
2972018-06-28T19:14:03  <sipa> thank you. i promise i'll work on having a PRable implementation soon
2982018-06-28T19:14:25  <jonasschnelli> The question of a gap limit came up recently (related to the xpub situation) but this concept seems not to work with utxo based scans..
2992018-06-28T19:14:32  <jonasschnelli> So a fixed lookup window makes more sense IMO
3002018-06-28T19:15:15  <sipa> agree
3012018-06-28T19:15:50  <sipa> jonasschnelli: that's actually a good point against having a gap limit inside the descriptor language
3022018-06-28T19:15:59  <sipa> (as a gap limit is not relevant for all use cases)
3032018-06-28T19:16:16  <jonasschnelli> gap limit is a broken concept IMO
3042018-06-28T19:16:59  <jonasschnelli> I would not use it in the descriptors...
3052018-06-28T19:18:06  <sipa> in the context of high priority PRs that's all i have to say about it; but we can discuss this idea in more detail as a separate topic if there's interest
3062018-06-28T19:18:26  <jonasschnelli> Thanks for working on this sipa. will give more feedback soon.
3072018-06-28T19:18:32  <wumpus> any proposals for adding high-priority PRs, or rmaoving them?
3082018-06-28T19:18:57  <wumpus> heh I already considered doing a #topic change
3092018-06-28T19:19:04  <jonasschnelli> I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"
3102018-06-28T19:19:44  <promag> wumpus: I'll complete #13100 soon and it could go to hp list
3112018-06-28T19:19:46  <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
3122018-06-28T19:20:03  <wumpus> let's add it whwen it's ready then
3132018-06-28T19:20:07  <promag> once ready
3142018-06-28T19:20:08  <promag> yes
3152018-06-28T19:20:30  <wumpus> #topic cipherseed
3162018-06-28T19:20:33  <jonasschnelli> I have a specification draft for a new seed format similar to BIP39 with some neat properties and – before sending to the ML – would appreciate feedback.
3172018-06-28T19:20:33  <jonasschnelli> https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
3182018-06-28T19:21:22  <jonasschnelli> (its more an announcement then a topic, sry)
3192018-06-28T19:22:06  <wumpus> #link https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
3202018-06-28T19:22:20  <wumpus> thanks for letting us know, will have a look
3212018-06-28T19:22:34  <wumpus> right, as no one has read it, I don't think there's much to discuss now
3222018-06-28T19:22:46  <wumpus> #topic cores BIP32 derivation "standard"
3232018-06-28T19:22:50  <jonasschnelli> It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
3242018-06-28T19:23:12  <jonasschnelli> Some people think its vanilla/native BIP32... but its not... while other do native BIP32
3252018-06-28T19:23:26  <jonasschnelli> I'm not sure if we should define a standard for out derivation scheme...
3262018-06-28T19:23:34  <jonasschnelli> (would be a very short proposal)
3272018-06-28T19:23:42  <wumpus> agree ti would be good if the difference would be documented somewhere
3282018-06-28T19:23:46  <sipa> jonasschnelli: my thinking is that with output descriptors we can pretty much freely change it
3292018-06-28T19:23:47  <jonasschnelli> The BIP32 based derivation scheme has that security risk
3302018-06-28T19:24:08  <sipa> (including unhardened etc)
3312018-06-28T19:24:44  <jonasschnelli> Changing the scheme is one point,... but there are wallets out there following a derivation scheme that is not specified in word
3322018-06-28T19:24:47  <jonasschnelli> *words
3332018-06-28T19:25:01  <luke-jr> how does it affect other implementations?
3342018-06-28T19:25:03  <sipa> we could have a doc in our source tree that describes it
3352018-06-28T19:25:22  <wumpus> luke-jr: only in the sense that other implementations might want to replicate it
3362018-06-28T19:25:22  <sipa> i don't think it needs to be a bip; there's no real desire to convince others to adopt the same, i think?
3372018-06-28T19:25:31  <jonasschnelli> luke-jr: in case someone wants to import Cores xprivs...
3382018-06-28T19:25:33  <luke-jr> wumpus: why?
3392018-06-28T19:25:50  <wumpus> luke-jr: I don't know
3402018-06-28T19:25:57  <luke-jr> jonasschnelli: but not import a proper wallet in entirety?
3412018-06-28T19:26:13  <jonasschnelli> I precautionally wrote a tiny BIP,... but could also be used as an internal document: https://gist.github.com/jonasschnelli/0d383888ac51d5120540571173e35451
3422018-06-28T19:26:20  <luke-jr> (if there were a BIP, I would think it should cover the whole wallet format, not *just* derivation)
3432018-06-28T19:26:36  <sipa> luke-jr: saw my descriptor proposal above? :)
3442018-06-28T19:26:45  <achow101> just documnting the derivation in the docs repo is sufficient imo
3452018-06-28T19:26:52  <jonasschnelli> I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
3462018-06-28T19:27:57  <sipa> my point is that i don't think our scheme is particularly an improvement over alternatives, or has all that much design we want to convince others about
3472018-06-28T19:28:08  <sipa> it's just one of many choices, and the one we made
3482018-06-28T19:28:18  <jonasschnelli> Agree with that. Yes.
3492018-06-28T19:28:23  <sipa> so we should just document it
3502018-06-28T19:28:28  <jonasschnelli> ack
3512018-06-28T19:28:54  <achow101> +1
3522018-06-28T19:28:55  <gmaxwell> Seems good.
3532018-06-28T19:29:22  <wumpus> agree
3542018-06-28T19:30:36  <wumpus> I think this leaves sipa's topic, but I think that's more or less discussed already?
3552018-06-28T19:31:10  <sipa> yeah, probably needs people reading the idea first to discuss more; can be done offline
3562018-06-28T19:31:44  <wumpus> right
3572018-06-28T19:31:47  <jonasschnelli> sipa: how would it interact with the keypool, flexible keypath?
3582018-06-28T19:31:56  <jonasschnelli> and a xpub
3592018-06-28T19:31:59  <sipa> jonasschnelli: keypool goes away
3602018-06-28T19:32:06  <wumpus> good riddance
3612018-06-28T19:32:35  <sipa> there is ephemeral data in the wallet associated with the descriptor (which is a black box, and descriptor specific), but in practice contains the expanded pubkeys
3622018-06-28T19:32:57  <sipa> that takes the place of the keypool- but those things don't all translate to independent keys in the wallet
3632018-06-28T19:33:06  <sipa> there would just be a single private key in your wallet, for example
3642018-06-28T19:33:22  <sipa> (or none at all; it can be in a hardware device too)
3652018-06-28T19:33:46  <sipa> flexible keypath... the descriptor just contains the path
3662018-06-28T19:34:11  <sipa> you can change it to whatever you like (but default wallets would of course pick some standard scheme)
3672018-06-28T19:34:51  <sipa> or rather you can import things with whatever path you like
3682018-06-28T19:36:09  <wumpus> makes sense
3692018-06-28T19:36:27  <jonasschnelli> Would it make sense that the descriptor support pkh(d34db33f/44'/0'/0':<seed>/1/i). (seed along with xpriv)?
3702018-06-28T19:36:32  <jonasschnelli> for backward compatibility
3712018-06-28T19:36:53  <sipa> jonasschnelli: i've thought about that, but that makes descriptors non-canonical
3722018-06-28T19:37:06  <sipa> (as in: you can't convert them to "public" form and back, and retain all information)
3732018-06-28T19:37:20  *** promag has quit IRC
3742018-06-28T19:37:56  <sipa> i'm unsure how to deal with that; my thinking is initially no
3752018-06-28T19:38:13  <sipa> you can always implement it as an extra utility that converts from seed based format
3762018-06-28T19:38:20  <jonasschnelli> There is always the option of externally converting the seed to an xpriv, yes
3772018-06-28T19:39:06  <jonasschnelli> we can encode seeds into xprivs *duck*
3782018-06-28T19:39:15  *** promag has joined #bitcoin-core-dev
3792018-06-28T19:39:44  <gmaxwell> Not to hijack, but has there been any progress towards implementing P2P link ephemeral encryption lately?  I know we were kinda waiting for some other networking refactors.
3802018-06-28T19:40:10  <sipa> cfields: ping?
3812018-06-28T19:40:12  <wumpus> #topic  P2Plink ephemeral encryptio
3822018-06-28T19:40:18  <jonasschnelli> I'm ready to pick that up any moment but was under the impression that sipa had plans to implement it
3832018-06-28T19:40:32  <jonasschnelli> I started with the implementation but halted at some point...
3842018-06-28T19:40:46  <jonasschnelli> I'm also not sure if we should delay it further more for "refactors"
3852018-06-28T19:40:55  <gmaxwell> I believed sipa did too, but asformentioned delays.
3862018-06-28T19:41:00  <cfields> heh, I was waiting on it to firm up. Guess we were waiting in circles :)
3872018-06-28T19:41:10  <wumpus> hehe
3882018-06-28T19:41:10  <cfields> jonasschnelli: for sure
3892018-06-28T19:41:22  <jonasschnelli> BTW: armory has implemented it and has plans to PR it to Core
3902018-06-28T19:41:26  <gmaxwell> Sipa and I made some major advances in the authentication part but the encryption doesn't need to wait on that.
3912018-06-28T19:41:27  <jonasschnelli> (not sure how soon and in what quality)
3922018-06-28T19:41:28  <sipa> cfields: waiting for encryption proposal to firm up before implementing it? or before continuing with network refactors?
3932018-06-28T19:41:44  <wumpus> jonasschnelli: oh wow
3942018-06-28T19:42:04  <jonasschnelli> Agree with gmaxwell. Authentication can be added later.
3952018-06-28T19:42:22  <cfields> sipa: i've had to put the net stuff on the backburner for now, so certainly don't wait for that.
3962018-06-28T19:42:30  <sipa> cfields: cool
3972018-06-28T19:43:07  <jonasschnelli> cfields: I think BIP151 is almost final (there is some issues with the version handshake)... the only thing that was holding me back where possible network refactors to first wait for
3982018-06-28T19:43:15  <cfields> I'm happy to help with the implementation. I was thinking we were waiting on the auth stuff.
3992018-06-28T19:43:24  <luke-jr> jonasschnelli: it can't be Final until it is adopted..
4002018-06-28T19:43:25  <gmaxwell> no, they're designed to operated independantly.
4012018-06-28T19:43:31  <jonasschnelli> Auth is additional and implementation wise it comes after 151
4022018-06-28T19:43:37  <sipa> we can implement 151 without 150
4032018-06-28T19:43:51  <gmaxwell> I would rather not use the prior auth design, we have better ones now.
4042018-06-28T19:43:54  <jonasschnelli> Yes. 150 can also be replaced (coexist) with other auth proposals
4052018-06-28T19:43:59  <sipa> fair
4062018-06-28T19:44:08  <jonasschnelli> Agree with that.
4072018-06-28T19:44:32  <jonasschnelli> sipas prework is here AFAIK: https://gist.github.com/sipa/29118d3fcfac69f9930d57433316c039
4082018-06-28T19:44:46  <sipa> i need to pick that up again
4092018-06-28T19:44:50  <gmaxwell> but right, there is no need delay 151 on auth-- it's completely oblivious to auth.
4102018-06-28T19:45:04  <jonasschnelli> I guess it uses some non-standard crypto stuff though
4112018-06-28T19:45:25  <sipa> jonasschnelli: no, https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
4122018-06-28T19:45:39  <jonasschnelli> Oh. Mistaken your gist. Thansk
4132018-06-28T19:45:42  <jonasschnelli> *thanks
4142018-06-28T19:45:45  <sipa> the other link is just some cool trick, not a serious proposal
4152018-06-28T19:46:48  <jonasschnelli> Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
4162018-06-28T19:47:08  <gmaxwell> Basically there was an open question of if we wanted the encryption handshake to operate in such a way that there are no fixed bytes for easy blocking/detection.  But I think we thought the benefits were too dubious.
4172018-06-28T19:47:24  <gmaxwell> Esp since traffic patterns will identify bitcoin p2p links very clearly.
4182018-06-28T19:47:34  <cfields> too dubious? you mean foiled by dpi anyway?
4192018-06-28T19:47:40  <gmaxwell> And so probably better to just stick to something simple.
4202018-06-28T19:47:47  <jonasschnelli> Agree
4212018-06-28T19:47:55  <wumpus> hiding what kind of connection something is is very difficult
4222018-06-28T19:48:03  <gmaxwell> cfields: foiled by traffic analysis or smarer DPI (that does EC operations to match traffic)
4232018-06-28T19:48:09  <gmaxwell> smarter*
4242018-06-28T19:48:35  <gmaxwell> People can always carry bitcoin over other transports in any case, ... ones that can do things like pad out to a constant bitrate...
4252018-06-28T19:48:52  <gmaxwell> but we're certantly not going to make BIP151 do that. :P
4262018-06-28T19:48:56  <cfields> mm, that's a good point
4272018-06-28T19:49:24  <wumpus> which is why tor went with pluggable obfuscation layers, this for example: https://arxiv.org/pdf/1305.3199.pdf
4282018-06-28T19:49:47  <wumpus> might be creeping the scope a bit too much
4292018-06-28T19:50:18  <gmaxwell> in any case, changing the handshake to be harder to detect was the only 'maybe' design change that I'm aware of any of us considering.
4302018-06-28T19:50:25  <gmaxwell> For 151.
4312018-06-28T19:51:03  <jonasschnelli> You mean an obfuscation of the encryption handshake?
4322018-06-28T19:51:13  <gmaxwell> So I think we're good to implement, and the only changes that might be proposed would be ones that arose as a side effect of implementing and benchmarking.
4332018-06-28T19:51:18  <gmaxwell> jonasschnelli: yes.
4342018-06-28T19:52:01  <jonasschnelli> Yes. I think there is freedom to change the specs during implementation...
4352018-06-28T19:52:04  <gmaxwell> And my view is that it's not worthwhile because without other more complex obfscuation (which will be bandwidth costly) it'll still be pretty detectable.
4362018-06-28T19:52:08  <jonasschnelli> It's not really deployed on the network yet
4372018-06-28T19:52:51  <gmaxwell> right.
4382018-06-28T19:53:31  <jonasschnelli> Yes. Better not obscure and put efforts in a long term solutions (stuff like the ScrambleSuit)
4392018-06-28T19:54:13  <cfields> my only complaint was that it required message parsing to complete the handshake, but it's been a while since I looked, so I'm not sure if that's still the case. I also got the impression that nobody else seemed all that bothered by that anyway.
4402018-06-28T19:55:06  <jonasschnelli> can you elaborate a bit more on " it required message parsing to complete the handshak"?
4412018-06-28T19:55:51  *** Dizzle has joined #bitcoin-core-dev
4422018-06-28T19:56:18  <cfields> jonasschnelli: we can discuss after the meeting, I need to take a look at the current spec
4432018-06-28T19:56:25  <jonasschnelli> sure. Thanks cfields
4442018-06-28T19:59:47  <wumpus> #endmeeting
4452018-06-28T19:59:47  <lightningbot> Meeting ended Thu Jun 28 19:59:47 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4462018-06-28T19:59:47  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.html
4472018-06-28T19:59:47  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.txt
4482018-06-28T19:59:47  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.log.html
4492018-06-28T20:00:20  <sipa> lunch?
4502018-06-28T20:01:11  <BlueMatt> sounds good
4512018-06-28T20:01:13  <BlueMatt> wait, no, already did that
4522018-06-28T20:01:19  <instagibbs> like 3 hours ago
4532018-06-28T20:02:46  <jonasschnelli> irclunch?
4542018-06-28T20:10:21  <cfields> jonasschnelli: If the first 32bytes over the wire are a pubkey, the network layer can do the handshake and notify us of a new connection only after it's done. The message processor wouldn't have to know or care about encryption, it just pushes messages, and the network layer handles the rest automatically.
4552018-06-28T20:10:35  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c93c360eec4d...b330f3fdd56b
4562018-06-28T20:10:35  <bitcoin-git> bitcoin/master c2e4fc8 João Barbosa: bench: Simplify CoinSelection
4572018-06-28T20:10:36  <bitcoin-git> bitcoin/master b330f3f MarcoFalke: Merge #13563: bench: Simplify CoinSelection...
4582018-06-28T20:10:44  <cfields> If, however, messages have to be parsed before doing the handshake, the net layer has to be told to switch to encryption, which imo is awkward.
4592018-06-28T20:11:08  <jonasschnelli> Yes. I think your right...
4602018-06-28T20:11:25  <jonasschnelli> We should probably do a dummy handshake in advance... what would you think about that cfields?
4612018-06-28T20:11:35  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
4622018-06-28T20:11:42  <cfields> (I'm assuming that encryption would be handled at the net layer, I suppose doing it at the message processing layer is an option is well, but that feels like a step in the wrong direction)
4632018-06-28T20:12:04  <cfields> jonasschnelli: dummy handshake?
4642018-06-28T20:12:44  <jonasschnelli> cfields: we do a normal unencrypted version/verack handshake, .. then p2p initiator sends encinit
4652018-06-28T20:12:51  <cfields> i only bring it up because it seems avoidable, not because it's really a big deal
4662018-06-28T20:13:24  <jonasschnelli> A... I guess now I understand your point...
4672018-06-28T20:13:25  * jonasschnelli thinking
4682018-06-28T20:13:47  <cfields> jonasschnelli: i'm not following. Net would still have to be told to switch to encryption.
4692018-06-28T20:13:59  <jonasschnelli> Yes. It's another issue...
4702018-06-28T20:14:13  <jonasschnelli> Wouldn't it be a problem for some clients if the first package would be a pubkey?
4712018-06-28T20:14:26  <jonasschnelli> Also,.. how would you know if the other side supports encryption?
4722018-06-28T20:14:50  <cfields> jonasschnelli: yea, I trivialized that part for the sake of the example :)
4732018-06-28T20:14:58  <jonasschnelli> Heh... yes.
4742018-06-28T20:15:09  <jonasschnelli> I guess leaving out the message processor is probably hard,...
4752018-06-28T20:15:34  <jonasschnelli> eventually we need to look at the protocol version in the handshake and only send an encinit message if the protocol version signals support
4762018-06-28T20:15:55  <jonasschnelli> Assuming that non-supported message types are just ignore may be a fragile concept
4772018-06-28T20:16:30  <jonasschnelli> (though unsure,... its probably okay)
4782018-06-28T20:16:51  <cfields> jonasschnelli: could just send some magic before the pubkey, which would signal support and require no parsing other than an equality check.
4792018-06-28T20:18:28  <jonasschnelli> But if you connect to a peer and send magic+33b-pubkey+cipertype, woudln't you get disconnected straight away?
4802018-06-28T20:18:44  <jonasschnelli> (if non BIP151 supporting peer)
4812018-06-28T20:21:02  *** d9b4bef9 has quit IRC
4822018-06-28T20:21:08  <cfields> uhmm.. IIRC we allow more than one chance for the initial message? checking.
4832018-06-28T20:22:15  *** d9b4bef9 has joined #bitcoin-core-dev
4842018-06-28T20:22:20  <jonasschnelli> Also,.. not sure if we should respect other implementations.
4852018-06-28T20:22:32  <jonasschnelli> (libbitcoin / btcd / bcoin)
4862018-06-28T20:23:48  <luke-jr> jonasschnelli: that's a disturbing thing to say.
4872018-06-28T20:24:13  <jonasschnelli> luke-jr: I'm only saying since there are no clear protocol specification for this
4882018-06-28T20:24:26  *** Murch has joined #bitcoin-core-dev
4892018-06-28T20:24:28  <jonasschnelli> (is it allow to send data before the version/verack handshake)
4902018-06-28T20:24:48  <luke-jr> oh, I misinterpreted you I think
4912018-06-28T20:24:48  <jonasschnelli> (then s/allowed/tolerated)
4922018-06-28T20:25:10  <jonasschnelli> I mean ethically, we should respect them. :)
4932018-06-28T20:25:20  *** Murch has quit IRC
4942018-06-28T20:25:27  <cfields> haha :)
4952018-06-28T20:25:29  <jonasschnelli> But we where talking on possible encinit p2p encryption disconnets
4962018-06-28T20:27:21  *** Murch has joined #bitcoin-core-dev
4972018-06-28T20:27:27  <cfields> jonasschnelli: ok, looks like we can send before version as long as the magic is correct.
4982018-06-28T20:27:48  <cfields> but yes, that's very much an implementation detail. No clue how other clients handle it.
4992018-06-28T20:28:10  <jonasschnelli> Yes. That sound a bit fragile...
5002018-06-28T20:29:01  <jonasschnelli> But we could reconnect once we got disconnected after that pre-handshake encryption request and try without encryption (if unencrypted connections are allowed)
5012018-06-28T20:30:57  *** promag has quit IRC
5022018-06-28T20:33:53  *** rex4539 has quit IRC
5032018-06-28T20:35:52  *** promag has joined #bitcoin-core-dev
5042018-06-28T20:39:19  *** Victorsueca has quit IRC
5052018-06-28T20:39:25  <cfields> jonasschnelli: mm, it's not worth going that far I think
5062018-06-28T20:40:40  *** Victorsueca has joined #bitcoin-core-dev
5072018-06-28T20:46:27  *** Alexandra has joined #bitcoin-core-dev
5082018-06-28T20:46:36  <Alexandra> holaaaaa?
5092018-06-28T20:50:23  *** Alexandra has left #bitcoin-core-dev
5102018-06-28T20:52:02  *** Murch has quit IRC
5112018-06-28T20:52:53  *** Murch has joined #bitcoin-core-dev
5122018-06-28T21:05:36  <gmaxwell> jonasschnelli: we can coordinate if there is some incompatiblity.
5132018-06-28T21:06:07  <gmaxwell> And we should avoid gratitiously breaking, where its possible without significant harm.
5142018-06-28T21:07:01  <gmaxwell> But if at the end of the day an implementation which is almost non-existant on the public network needs updates to work right with sensible behavior, ... well then it is what it is. To be kind we could offer patches.
5152018-06-28T21:07:12  *** cbt has joined #bitcoin-core-dev
5162018-06-28T21:10:33  <gmaxwell> I'm really not a fan of the "try then retry if it fails" behavior, being stateful makes it more complex and have more ways to fail.
5172018-06-28T21:11:00  <gmaxwell> E.g. say the remote party is almost out of sockets, first try fails due to crypto snafu, second try just doesn't connect due to socket exhaustion.
5182018-06-28T21:14:13  <echeveria> jonasschnelli: gmaxwell: cfields: personally I'd do something a little more interesting. bind a new socket, say 8383 and *only* accept encrypted connections there. older implementations explicitly avoid non-standard ports, and it gives the option to selectively only use bip151.
5192018-06-28T21:14:44  <gmaxwell> echeveria: the downside there is that now everyone's firewall deployments need to change. :(
5202018-06-28T21:14:47  <echeveria> there's already logic for multiple bind interfaces with different properties (ie, whitebind). all this means is you gossip both of your ports.
5212018-06-28T21:15:11  <gmaxwell> one thing we could do in a slower migration is support two ports, one is legacy or encrypted, the other is encrypted only.
5222018-06-28T21:15:41  <gmaxwell> but I'm still skeptical that it's worth doing that.
5232018-06-28T21:15:48  <cfields> yea, I've considered that as well. But I was afraid that we'd get too much backlash from network admin
5242018-06-28T21:15:56  <cfields> ^^ what gmaxwell said
5252018-06-28T21:16:00  <gmaxwell> one could, on the legacy port, hang up whenever encryption isn't used.
5262018-06-28T21:16:15  <cfields> also, we currently penalize non-8333 I believe.
5272018-06-28T21:16:18  <gmaxwell> that sounds silly now, but in two years when 99% of everything has BIP151 it'll be reasonable.
5282018-06-28T21:16:27  <echeveria> cfields: that's sort of why it's ideal.
5292018-06-28T21:16:48  <echeveria> cfields: bitcoin nodes won't ever reasonably connect to a non 8333 rumored port.
5302018-06-28T21:16:53  <gmaxwell> the idea there being that old peers won't rumor or connect to the encrypted ones...
5312018-06-28T21:17:01  *** d9b4bef9 has quit IRC
5322018-06-28T21:17:21  <cfields> hmm. well I'd be all for it if we could get an idea of how many people it would piss off
5332018-06-28T21:18:07  *** d9b4bef9 has joined #bitcoin-core-dev
5342018-06-28T21:18:11  <gmaxwell> echeveria: so what really does that gain over just the disconnection approach?  I think only that old peers will waste less time trying to connect to encrypted only nodes.
5352018-06-28T21:18:27  <cfields> also makes me curious about the reasoning for the historical http/https 80/443 split. I actually have no idea how that unfolded initially.
5362018-06-28T21:19:02  *** d9b4bef9 has quit IRC
5372018-06-28T21:19:21  <gmaxwell> But I think there is relatively little reason to run encrypted-only for inbound. (for outbound connections, you don't need another port, service flags are sufficient)
5382018-06-28T21:19:46  <echeveria> gmaxwell: I like moving away from 8333 that's shared with bcash, and being able to be selectively restrictive about the type of traffic without necessarily inspecting it is nice. to me it's just easier to reason about, but that's possibly personal preference.
5392018-06-28T21:20:00  <gmaxwell> effectively, I think echeveria's proposal is to abuse the port number to create an implicit "old nodes don't connect here please" flag.
5402018-06-28T21:20:09  <echeveria> yup.
5412018-06-28T21:20:29  <cfields> yea. which I guess is exactly the net-level signal that I'm after.
5422018-06-28T21:21:02  <gmaxwell> Probably that idea should get incorporated in wumpus' new addr message proposal.  e.g. define some set of service flags where if you don't know their meaning you avoid connecting.
5432018-06-28T21:21:15  <gmaxwell> doesn't help old peers, but we'll probably have this desire in the future.
5442018-06-28T21:21:26  <cfields> gmaxwell: lol, we could use 18333 :)
5452018-06-28T21:22:07  <gmaxwell> Also, I'd rather bother network admins just once when we add a UDP based transport in the future. :)
5462018-06-28T21:22:09  *** d9b4bef9 has joined #bitcoin-core-dev
5472018-06-28T21:22:12  <cfields> (not a serious suggestion, but it would make life a bit easier on the routing side)
5482018-06-28T21:23:01  *** d9b4bef9 has quit IRC
5492018-06-28T21:24:08  *** d9b4bef9 has joined #bitcoin-core-dev
5502018-06-28T21:27:14  <gmaxwell> I dunno if pieter has talked to y'all about what we came up with for authentication, it's pretty awesome.  We gain the property that an active MITM cannot detect if authentication is actually in use or not, so he can't monitor anyone at all or takes the risk that his interception is detected.  This is a major advance over auth everywhere else where an active MITM can detect users using auth and
5512018-06-28T21:27:14  <gmaxwell> just sever the link (like an innocent network failure) and stop MITMing between that user pair.
5522018-06-28T21:33:56  <sipa> i have
5532018-06-28T21:34:18  <sipa> though the best we have is something that only supports one pubkey and one privkey afaik
5542018-06-28T21:35:16  *** meshcollider has quit IRC
5552018-06-28T21:43:59  <cfields> gmaxwell: yes, that's very cool.
5562018-06-28T21:46:29  <cfields> sipa: thoughts on echeveria's suggestion to use a separate port?
5572018-06-28T21:48:59  <sipa> cfields: seems a nice and easy solution, but i see the possible administrative issues
5582018-06-28T21:49:14  <sipa> i also don't think there is that much of a problem with reconnecting
5592018-06-28T21:50:21  <gmaxwell> I think the only thing a new port would buy is avoiding old peers attempting to connect to us if we were only going to accept encrypted connections on inbound. Or am I missing some other benefit?
5602018-06-28T21:51:15  *** Guyver2 has quit IRC
5612018-06-28T21:52:51  <sipa> well there are 3 approaches suggested (a) new port (b) reconnect on same port with wholly different protocol after learning peer supports encryption (c) upgrade the connection in flight
5622018-06-28T21:53:06  <cfields> gmaxwell: that's it, but it makes traffic significantly easier to handle imo
5632018-06-28T21:54:25  <gmaxwell> cfields: how so?
5642018-06-28T21:54:33  <cfields> sipa: (bi) always plan to reconnect to upgrade (bii) only do it if they boot us for trying
5652018-06-28T21:57:07  <gmaxwell> I think I'm confused. AFAIK the 'boot us for trying' isn't a real problem.
5662018-06-28T21:57:33  <cfields> gmaxwell: as described, bip151 would require us to send the first bytes up for parsing, then have the message handler tell the net handler to deal with encryption from that point on. If encryption could be assumed, net could just handle it transparently.
5672018-06-28T21:58:03  <gmaxwell> This is perhaps a sign that our layering is faulty. :P
5682018-06-28T21:58:20  <cfields> and this is me trying to avoid falling in the same trap again :)
5692018-06-28T21:59:25  <gmaxwell> but okay, I see that. I think forcing onto another port due to software layering in the networking is more than a little ugly.
5702018-06-28T21:59:26  <cfields> er... I say "net layer" and "message processing layer", but I mean those conceptually. Not our specific implementation.
5712018-06-28T21:59:58  <gmaxwell> if encryption must be on another port, rather than optionally on another port then we'd get a massive deployment loss due to users needing to punch new firewall holes.
5722018-06-28T22:00:30  <gmaxwell> E.g. I was thinking of echeveria's proposal as 8333 becomes legacy OR encrypted, and 8334 is encrypted only.
5732018-06-28T22:01:31  <cfields> Ah, ok.
5742018-06-28T22:01:40  *** Krellan has joined #bitcoin-core-dev
5752018-06-28T22:03:23  <cfields> well, I suppose we could do that as well. Introduce the round-trip layer violation for 8333, and hope for some future that's nearly all 8334, and un-encrypted 8333 could be dropped at that point.
5762018-06-28T22:03:55  <cfields> I guess that doesn't provide much motivation to switch, though.
5772018-06-28T22:04:13  <sipa> echo $'\x3d\x20\x53\xd7\xff\x00\x00\x00' | base64
5782018-06-28T22:04:13  <sipa> PSBT1/8K
5792018-06-28T22:04:20  <sipa> echo $'\x3d\x20\x53\xd7\xff\xff\xff\xff' | base64
5802018-06-28T22:04:20  <cfields> blehk, and that would suck to rumor
5812018-06-28T22:04:23  *** arubi has quit IRC
5822018-06-28T22:04:29  <sipa> PSBT1/////8K
5832018-06-28T22:04:47  *** arubi has joined #bitcoin-core-dev
5842018-06-28T22:05:01  <sipa> so if the PSBT magic bytes are 0x3d 0x20 0x53 0xd7 0xff, the base64 encoding will always begin with "PSBT1/"
5852018-06-28T22:10:13  *** Murch has quit IRC
5862018-06-28T22:11:30  <sipa> or {a6 c6 ed fb ff} to encode as "psbt+/"
5872018-06-28T22:16:09  *** Murch has joined #bitcoin-core-dev
5882018-06-28T22:25:39  *** cbt has quit IRC
5892018-06-28T22:30:12  *** booyah has quit IRC
5902018-06-28T22:41:22  *** Dizzle has quit IRC
5912018-06-28T22:50:04  *** drexl has quit IRC
5922018-06-28T22:52:33  *** drexl has joined #bitcoin-core-dev
5932018-06-28T22:53:12  *** Squidicuz has joined #bitcoin-core-dev
5942018-06-28T23:14:46  *** vicenteH has quit IRC
5952018-06-28T23:15:56  *** Victorsueca has quit IRC
5962018-06-28T23:17:11  *** Victorsueca has joined #bitcoin-core-dev
5972018-06-28T23:29:19  *** zautomata has joined #bitcoin-core-dev