12018-08-14T00:03:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
22018-08-14T00:12:55 *** justan0theruser has joined #bitcoin-core-dev
32018-08-14T00:15:26 *** promag has quit IRC
42018-08-14T00:16:30 *** miknotauro_ has joined #bitcoin-core-dev
52018-08-14T00:25:53 *** justan0theruser has quit IRC
62018-08-14T00:33:42 *** justanotheruser has joined #bitcoin-core-dev
72018-08-14T00:43:17 *** viaj3ro has quit IRC
82018-08-14T00:48:05 *** ken2812221_ has joined #bitcoin-core-dev
92018-08-14T00:50:41 *** Aaronvan_ has joined #bitcoin-core-dev
102018-08-14T00:57:09 *** AaronvanW has quit IRC
112018-08-14T00:57:09 *** IGHOR has quit IRC
122018-08-14T00:57:09 *** Emcy has quit IRC
132018-08-14T00:57:09 *** ken2812221 has quit IRC
142018-08-14T00:57:09 *** Giszmo has quit IRC
152018-08-14T00:57:09 *** xHire has quit IRC
162018-08-14T00:57:09 *** musalbas has quit IRC
172018-08-14T00:57:10 *** ryanofsky has quit IRC
182018-08-14T00:57:10 *** booyah has quit IRC
192018-08-14T00:57:10 *** games_ has quit IRC
202018-08-14T00:57:10 *** davex__ has quit IRC
212018-08-14T00:57:10 *** chjj has quit IRC
222018-08-14T00:57:10 *** murr4y has quit IRC
232018-08-14T00:57:10 *** petertodd has quit IRC
242018-08-14T01:00:03 *** Emcy has joined #bitcoin-core-dev
252018-08-14T01:04:26 *** IGHOR has joined #bitcoin-core-dev
262018-08-14T01:04:26 *** Giszmo has joined #bitcoin-core-dev
272018-08-14T01:04:26 *** xHire has joined #bitcoin-core-dev
282018-08-14T01:04:26 *** musalbas has joined #bitcoin-core-dev
292018-08-14T01:04:26 *** ryanofsky has joined #bitcoin-core-dev
302018-08-14T01:04:26 *** booyah has joined #bitcoin-core-dev
312018-08-14T01:04:26 *** 18WAA5MDD has joined #bitcoin-core-dev
322018-08-14T01:04:26 *** games_ has joined #bitcoin-core-dev
332018-08-14T01:04:26 *** chjj has joined #bitcoin-core-dev
342018-08-14T01:04:26 *** murr4y has joined #bitcoin-core-dev
352018-08-14T01:04:26 *** petertodd has joined #bitcoin-core-dev
362018-08-14T01:04:28 *** murr4y has quit IRC
372018-08-14T01:04:28 *** 18WAA5MDD has quit IRC
382018-08-14T01:04:28 *** Aaronvan_ has quit IRC
392018-08-14T01:20:06 *** brunner_mobile has joined #bitcoin-core-dev
402018-08-14T01:22:43 *** brunner_mobile has quit IRC
412018-08-14T01:30:41 *** Chris_Stewart_5 has quit IRC
422018-08-14T01:54:40 *** D00M has joined #bitcoin-core-dev
432018-08-14T02:04:05 *** justanotheruser has quit IRC
442018-08-14T02:06:54 *** Krellan_ has quit IRC
452018-08-14T02:15:24 *** plankers has quit IRC
462018-08-14T02:20:48 *** Pasha has quit IRC
472018-08-14T02:22:42 *** goatpig has quit IRC
482018-08-14T02:26:11 *** Cory has joined #bitcoin-core-dev
492018-08-14T02:26:28 *** justanotheruser has joined #bitcoin-core-dev
502018-08-14T02:37:38 *** waiting2compile has joined #bitcoin-core-dev
512018-08-14T02:52:31 <waiting2compile> hi, could someone walk me a bit through running Bitcoin's tests? I tried following the instructions in the README.md, though I suspect there's some extra setup that needs to be done that's missing, since running the command just gives make errors and the like (pardon me, I'm new to this and am trying to fix one of the good first bugs :))
522018-08-14T02:57:04 <sipa> have you looked at build-unix.md (or windows/osx, based on your environement)
532018-08-14T02:57:07 <sipa> ?
542018-08-14T03:01:13 <waiting2compile> Ah I had not, I'll try following the instructions there and see if I have any luck
552018-08-14T03:05:44 *** thaumavorio_ is now known as thaumavorio
562018-08-14T03:18:49 *** D00M has quit IRC
572018-08-14T03:19:11 *** nickler has quit IRC
582018-08-14T03:19:54 *** Cory has quit IRC
592018-08-14T03:26:30 *** Rootsudo has joined #bitcoin-core-dev
602018-08-14T03:33:14 *** plankers has joined #bitcoin-core-dev
612018-08-14T03:46:11 *** unholymachine has quit IRC
622018-08-14T04:01:14 *** Victorsueca has quit IRC
632018-08-14T04:02:25 *** Victorsueca has joined #bitcoin-core-dev
642018-08-14T04:18:36 *** unholymachine has joined #bitcoin-core-dev
652018-08-14T04:32:31 <ken2812221_> Fetching qtbase-opensource-src-5.9.6.tar.xz from https://download.qt.io/official_releases/qt/5.9/5.9.6/submodules
662018-08-14T04:32:31 <ken2812221_> % Total % Received % Xferd Average Speed Time Time Time Current
672018-08-14T04:32:32 <ken2812221_> Dload Upload Total Spent Left Speed
682018-08-14T04:32:32 <ken2812221_> 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0curl: (7) Failed to connect to download.qt.io port 443: No route to host
692018-08-14T04:32:32 <ken2812221_> Fetching qtbase-opensource-src-5.9.6.tar.xz from https://bitcoincore.org/depends-sources
702018-08-14T04:32:34 <ken2812221_> % Total % Received % Xferd Average Speed Time Time Time Current
712018-08-14T04:32:36 <ken2812221_> Dload Upload Total Spent Left Speed
722018-08-14T04:32:38 <ken2812221_> 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
732018-08-14T04:32:40 <ken2812221_> curl: (22) The requested URL returned error: 404 Not Found
742018-08-14T04:33:27 <ken2812221_> download.qt.io is down, also there is no backup at bitcoincore.org
752018-08-14T04:35:43 <luke-jr> not sure who maintains the bitcoincore.org mirrors
762018-08-14T04:36:42 <luke-jr> fwiw there's a mirror here http://distfiles.gentoo.org/distfiles/qtbase-opensource-src-5.9.6.tar.xz
772018-08-14T04:38:13 *** plankers has quit IRC
782018-08-14T04:39:49 *** Krellan has joined #bitcoin-core-dev
792018-08-14T04:44:18 *** jamesob has quit IRC
802018-08-14T04:44:30 *** jnewbery has quit IRC
812018-08-14T04:44:36 *** prod_ has quit IRC
822018-08-14T04:44:58 *** marcinja has quit IRC
832018-08-14T05:05:40 *** waiting2compile has quit IRC
842018-08-14T05:10:41 <ken2812221_> luke-jr: thanks, that works
852018-08-14T05:12:32 <ken2812221_> But I think I'll need to rebuild qt once I change back to download.qt.io site site
862018-08-14T05:13:17 <luke-jr> why?
872018-08-14T05:37:44 <ken2812221_> luke-jr: Since I changed the link in .mk file
882018-08-14T05:38:08 <ken2812221_> hash does not match the previous built one.
892018-08-14T06:21:44 *** baldur has quit IRC
902018-08-14T06:24:02 *** d9b4bef9 has quit IRC
912018-08-14T06:25:13 *** d9b4bef9 has joined #bitcoin-core-dev
922018-08-14T06:52:46 *** hashrate has joined #bitcoin-core-dev
932018-08-14T06:58:32 *** baldur has joined #bitcoin-core-dev
942018-08-14T07:01:01 *** hashrate has quit IRC
952018-08-14T07:20:31 *** fanquake has joined #bitcoin-core-dev
962018-08-14T07:23:07 *** Krellan has quit IRC
972018-08-14T07:24:44 <fanquake> wumpus 13963, 13962 and 13948 are a few trivial merges.
982018-08-14T07:24:51 *** Randolf has joined #bitcoin-core-dev
992018-08-14T07:33:27 <wumpus> fanquake: thanks, agree
1002018-08-14T07:34:20 <wumpus> we really need a replacement for the IRC merges bot
1012018-08-14T07:35:23 <wumpus> ken2812221_: problems with bitcoincore.org you can file at https://github.com/bitcoin-core/bitcoincore.org
1022018-08-14T07:36:38 *** Rootsudo has quit IRC
1032018-08-14T07:38:22 *** SopaXorzTaker has joined #bitcoin-core-dev
1042018-08-14T07:49:39 <ken2812221_> wumpus: Thanks, I'll check that out.
1052018-08-14T07:57:40 *** Rootsudo has joined #bitcoin-core-dev
1062018-08-14T07:57:57 *** Rootsudo has quit IRC
1072018-08-14T07:58:24 *** Rootsudo has joined #bitcoin-core-dev
1082018-08-14T07:58:48 *** dqx has joined #bitcoin-core-dev
1092018-08-14T08:12:45 *** csknk has joined #bitcoin-core-dev
1102018-08-14T08:16:03 *** luke-jr has quit IRC
1112018-08-14T08:25:17 *** Rootsudo has joined #bitcoin-core-dev
1122018-08-14T08:34:10 *** ken2812221_ is now known as ken2812221
1132018-08-14T08:34:32 *** luke-jr has joined #bitcoin-core-dev
1142018-08-14T08:37:56 *** AaronvanW has joined #bitcoin-core-dev
1152018-08-14T08:39:02 *** D00M has joined #bitcoin-core-dev
1162018-08-14T08:59:16 *** timothy has joined #bitcoin-core-dev
1172018-08-14T09:03:59 *** Rootsudo has quit IRC
1182018-08-14T09:20:40 *** nickler has joined #bitcoin-core-dev
1192018-08-14T09:27:52 *** fanquake has quit IRC
1202018-08-14T09:32:36 <wumpus> time to update my build infrastructure so I can finally build the 0.17 branch in gitian
1212018-08-14T09:34:23 *** Rootsudo has joined #bitcoin-core-dev
1222018-08-14T09:37:08 <wumpus> starting with building the most recent lxc, 3.0.1 apparently
1232018-08-14T09:37:22 *** Rootsudo has quit IRC
1242018-08-14T09:37:50 *** Rootsudo has joined #bitcoin-core-dev
1252018-08-14T09:38:29 *** Rootsudo has joined #bitcoin-core-dev
1262018-08-14T09:38:55 *** Rootsudo has quit IRC
1272018-08-14T09:39:15 *** Rootsudo has joined #bitcoin-core-dev
1282018-08-14T09:39:41 *** Rootsudo has quit IRC
1292018-08-14T09:40:15 *** Rootsudo has joined #bitcoin-core-dev
1302018-08-14T09:40:28 *** Rootsudo has quit IRC
1312018-08-14T09:41:05 *** Rootsudo has joined #bitcoin-core-dev
1322018-08-14T09:41:14 *** Rootsudo has quit IRC
1332018-08-14T09:45:24 *** Jmabsd has joined #bitcoin-core-dev
1342018-08-14T09:55:49 *** Gnappuraz has joined #bitcoin-core-dev
1352018-08-14T09:57:01 <Gnappuraz> Hi, I was going through the bitcoin documentation but I can't find the rationale behind the fact of using the prevTx.scriptPubKey in the place of curTx.scriptSig when creating the signature
1362018-08-14T10:01:03 *** Aaronvan_ has joined #bitcoin-core-dev
1372018-08-14T10:04:33 *** AaronvanW has quit IRC
1382018-08-14T10:05:59 *** vexbuy has joined #bitcoin-core-dev
1392018-08-14T10:08:35 *** vexbuy_ has joined #bitcoin-core-dev
1402018-08-14T10:12:17 *** vexbuy has quit IRC
1412018-08-14T10:13:07 *** vexbuy has joined #bitcoin-core-dev
1422018-08-14T10:17:05 *** vexbuy_ has quit IRC
1432018-08-14T10:19:13 *** intcat has quit IRC
1442018-08-14T10:21:54 *** intcat has joined #bitcoin-core-dev
1452018-08-14T10:22:26 *** vexbuy_ has joined #bitcoin-core-dev
1462018-08-14T10:26:01 *** vexbuy has quit IRC
1472018-08-14T10:26:57 *** vexbuy has joined #bitcoin-core-dev
1482018-08-14T10:29:27 *** vexbuy_ has quit IRC
1492018-08-14T10:31:22 *** vexbuy_ has joined #bitcoin-core-dev
1502018-08-14T10:34:05 *** vexbuy has quit IRC
1512018-08-14T10:35:50 *** vexbuy has joined #bitcoin-core-dev
1522018-08-14T10:39:05 *** vexbuy_ has quit IRC
1532018-08-14T10:40:21 *** vexbuy_ has joined #bitcoin-core-dev
1542018-08-14T10:43:26 *** vexbuy has quit IRC
1552018-08-14T10:49:31 *** vexbuy has joined #bitcoin-core-dev
1562018-08-14T10:50:24 *** csknk has quit IRC
1572018-08-14T10:52:58 *** vexbuy_ has quit IRC
1582018-08-14T10:54:05 *** vexbuy_ has joined #bitcoin-core-dev
1592018-08-14T10:54:43 *** jnewbery has joined #bitcoin-core-dev
1602018-08-14T10:57:37 *** vexbuy has quit IRC
1612018-08-14T11:03:19 *** vexbuy has joined #bitcoin-core-dev
1622018-08-14T11:06:27 *** vexbuy_ has quit IRC
1632018-08-14T11:07:44 *** vexbuy_ has joined #bitcoin-core-dev
1642018-08-14T11:10:27 *** vexbuy has quit IRC
1652018-08-14T11:12:21 *** vexbuy has joined #bitcoin-core-dev
1662018-08-14T11:16:17 *** vexbuy_ has quit IRC
1672018-08-14T11:16:37 *** goatpig has joined #bitcoin-core-dev
1682018-08-14T11:16:44 *** vexbuy_ has joined #bitcoin-core-dev
1692018-08-14T11:19:34 *** vexbuy has quit IRC
1702018-08-14T11:21:18 *** vexbuy has joined #bitcoin-core-dev
1712018-08-14T11:24:49 *** vexbuy_ has quit IRC
1722018-08-14T11:26:00 *** vexbuy_ has joined #bitcoin-core-dev
1732018-08-14T11:27:12 *** Gnappuraz has quit IRC
1742018-08-14T11:29:43 *** vexbuy has quit IRC
1752018-08-14T11:30:19 *** vexbuy has joined #bitcoin-core-dev
1762018-08-14T11:33:21 *** vexbuy_ has quit IRC
1772018-08-14T11:33:46 *** JackH has quit IRC
1782018-08-14T11:35:03 *** vexbuy_ has joined #bitcoin-core-dev
1792018-08-14T11:38:21 *** vexbuy has quit IRC
1802018-08-14T11:42:35 *** JackH has joined #bitcoin-core-dev
1812018-08-14T11:53:42 *** miknotauro_ has quit IRC
1822018-08-14T11:54:20 *** vexbuy has joined #bitcoin-core-dev
1832018-08-14T12:09:03 *** vexbuy has quit IRC
1842018-08-14T12:09:51 *** vexbuy has joined #bitcoin-core-dev
1852018-08-14T12:12:47 *** vexbuy has quit IRC
1862018-08-14T12:13:01 *** vexbuy has joined #bitcoin-core-dev
1872018-08-14T12:19:37 <wumpus> $ bin/make-base-vm --lxc --suite bionic --arch amd64
1882018-08-14T12:19:40 <wumpus> E: No such script: /usr/share/debootstrap/scripts/bionic
1892018-08-14T12:19:59 * wumpus wonders where to get this file
1902018-08-14T12:23:35 <wumpus> seemingly the ubuntu package of debootstrap has it, but I don't think I can just install that on debian
1912018-08-14T12:26:01 <wumpus> found the source download @ http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.95.tar.gz
1922018-08-14T12:29:21 <wumpus> nice, removing the debootstrap debian package and simply installing that seems to have worked
1932018-08-14T12:32:46 <wumpus> luckily it's only a VM so I don't care about the mess
1942018-08-14T12:47:00 <wumpus> Failed run an application inside container
1952018-08-14T12:47:00 <wumpus> bin/gbuild:21:in `system!': failed to run make-clean-vm --suite bionic --arch amd64 (RuntimeError)
1962018-08-14T12:47:19 <wumpus> ouch--can't build 0.16.x nor 0.17.x anymore
1972018-08-14T13:07:18 *** vexbuy has quit IRC
1982018-08-14T13:07:38 <wumpus> apparently I'm missing init.lxc.static
1992018-08-14T13:07:54 *** vexbuy has joined #bitcoin-core-dev
2002018-08-14T13:09:42 <BlueMatt> can someone close #13826 and #13901 as dup's (sorry, wasnt able to fix it last week, will fix it soon)
2012018-08-14T13:09:44 <gribble> https://github.com/bitcoin/bitcoin/issues/13826 | packaging: Auto-change datadir in ubuntu ppa · Issue #13826 · bitcoin/bitcoin · GitHub
2022018-08-14T13:09:44 <gribble> https://github.com/bitcoin/bitcoin/issues/13901 | adduser: The user `bitcoin already exists. Exiting. · Issue #13901 · bitcoin/bitcoin · GitHubAsset 1Asset 1
2032018-08-14T13:11:23 <BlueMatt> wait, no I misread the first one, I have no idea what they're even saying
2042018-08-14T13:12:38 *** vexbuy has quit IRC
2052018-08-14T13:13:07 <wumpus> apparently I needed "apt-get libcap-dev", please work now
2062018-08-14T13:13:18 <wumpus> BlueMatt: sure
2072018-08-14T13:14:50 <wumpus> closed the second one
2082018-08-14T13:26:39 *** bytting has joined #bitcoin-core-dev
2092018-08-14T13:32:01 *** d9b4bef9 has quit IRC
2102018-08-14T13:33:07 *** d9b4bef9 has joined #bitcoin-core-dev
2112018-08-14T13:35:09 *** vexbuy has joined #bitcoin-core-dev
2122018-08-14T13:37:04 *** unholymachine has quit IRC
2132018-08-14T13:41:18 *** vexbuy has quit IRC
2142018-08-14T13:44:06 *** vexbuy has joined #bitcoin-core-dev
2152018-08-14T13:47:20 *** jamesob has joined #bitcoin-core-dev
2162018-08-14T14:02:42 *** marcinja_ has joined #bitcoin-core-dev
2172018-08-14T14:05:11 <wumpus> phew, 0.16.2 build succesfully, let's see about 0.17
2182018-08-14T14:05:37 *** bytting has quit IRC
2192018-08-14T14:09:55 *** plankers has joined #bitcoin-core-dev
2202018-08-14T14:25:00 *** harding has joined #bitcoin-core-dev
2212018-08-14T14:34:37 <MarcoFalke> did the irc spam stop?
2222018-08-14T14:34:48 <MarcoFalke> If so could we set the irc flags to what they were a few weeks ago?
2232018-08-14T14:35:07 *** ChanServ sets mode: +o sipa
2242018-08-14T14:35:14 *** sipa sets mode: -n
2252018-08-14T14:35:20 *** sipa sets mode: -o sipa
2262018-08-14T14:35:30 <sipa> done
2272018-08-14T14:35:54 <MarcoFalke> thx
2282018-08-14T14:36:52 *** AaronvanW has joined #bitcoin-core-dev
2292018-08-14T14:39:21 *** Aaronvan_ has quit IRC
2302018-08-14T14:42:15 *** vexbuy has quit IRC
2312018-08-14T14:42:52 *** vexbuy has joined #bitcoin-core-dev
2322018-08-14T14:47:20 *** vexbuy has quit IRC
2332018-08-14T14:52:50 <wumpus> does this mean...
2342018-08-14T14:53:07 *** unholymachine has joined #bitcoin-core-dev
2352018-08-14T14:53:10 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/dabfcb03071e...3e5424faf6ff
2362018-08-14T14:53:12 <bitcoin-git> bitcoin/master 43811e6 Andrew Chow: Fix PSBT deserialization of 0-input transactions...
2372018-08-14T14:53:12 <bitcoin-git> bitcoin/master bd19cc7 Andrew Chow: Serialize non-witness utxo as a non-witness tx but always deserialize as witness...
2382018-08-14T14:53:12 <bitcoin-git> bitcoin/master 3e5424f Wladimir J. van der Laan: Merge #13960: Fix PSBT deserialization of 0-input transactions...
2392018-08-14T14:53:16 <wumpus> YESSSSS
2402018-08-14T14:54:09 *** SopaXorzTaker has quit IRC
2412018-08-14T14:54:22 <bitcoin-git> [bitcoin] laanwj closed pull request #13960: Fix PSBT deserialization of 0-input transactions (master...fix-decodepsbt-no-in) https://github.com/bitcoin/bitcoin/pull/13960
2422018-08-14T14:58:11 <sipa> haha
2432018-08-14T14:59:58 *** plankers has quit IRC
2442018-08-14T15:00:10 *** davex__ has joined #bitcoin-core-dev
2452018-08-14T15:00:56 *** Victorsueca has quit IRC
2462018-08-14T15:02:10 *** Victorsueca has joined #bitcoin-core-dev
2472018-08-14T15:02:38 *** D00M has quit IRC
2482018-08-14T15:10:30 <ben_zen1>      http://magaimg.net/img/wqz.jpg           http://magaimg.net/img/wqz.jpg                                          Â
2492018-08-14T15:10:35 <ben_zen1>                                                                   https://i.redd.it/8w0r915sm1ty.jpg                 Â
2502018-08-14T15:10:41 <ben_zen1>   https://i.imgur.com/FZ5iI6Y.jpg                                                                                 Â
2512018-08-14T15:10:44 <ben_zen1>                   https://i.redd.it/el0p0os7u7fz.jpg                                                     Â
2522018-08-14T15:10:48 <ben_zen1>                     https://i.redd.it/r2n8a788qs211.jpg                                                     Â
2532018-08-14T15:10:52 <ben_zen1> http://i.imgur.com/DfZdPTy.jpg                                                                  Â
2542018-08-14T15:10:56 <ben_zen1> http://magaimg.net/img/5xpf.jpg                                                              Â
2552018-08-14T15:11:01 <ben_zen1>                                 https://i.imgur.com/AaQg3Pp.jpg                                                                    Â
2562018-08-14T15:12:04 *** ChanServ sets mode: +o sipa
2572018-08-14T15:12:06 *** sipa sets mode: +n
2582018-08-14T15:12:08 *** sipa sets mode: -o sipa
2592018-08-14T15:12:10 <sipa> sorry :(
2602018-08-14T15:13:11 *** ChanServ sets mode: +o sipa
2612018-08-14T15:15:35 *** plankers has joined #bitcoin-core-dev
2622018-08-14T15:29:26 <sipa> wumpus: i'm going to clear the 'needs release notes' for all PRs merged before 0.17
2632018-08-14T15:29:40 <sipa> or are there things in the 0.16 branch that haven't been in a release yet?
2642018-08-14T15:43:07 <sipa> are we going to include qt arm builds in 0.17 releases?
2652018-08-14T15:55:58 *** marcinja_ has quit IRC
2662018-08-14T16:01:27 *** nodweber has joined #bitcoin-core-dev
2672018-08-14T16:08:36 <sipa> i went through the list of merged PRs, and added "Needs Release Notes" here and there where i felt it was useful
2682018-08-14T16:09:10 <sipa> some of these already have release notes, but i think it's useful to have such a list to compare with the notes when they are finished
2692018-08-14T16:11:13 *** photonclock_ has joined #bitcoin-core-dev
2702018-08-14T16:12:46 *** belcher_ has joined #bitcoin-core-dev
2712018-08-14T16:18:19 *** Victorsueca has quit IRC
2722018-08-14T16:19:28 *** Victorsueca has joined #bitcoin-core-dev
2732018-08-14T16:46:21 *** marcinja has joined #bitcoin-core-dev
2742018-08-14T16:49:49 *** vexbuy has joined #bitcoin-core-dev
2752018-08-14T16:55:44 *** Rootsudo has joined #bitcoin-core-dev
2762018-08-14T16:59:51 <wumpus> sipa: make ssense
2772018-08-14T16:59:54 <wumpus> +s
2782018-08-14T17:00:34 <wumpus> nothing has been merged after 0.16.2 that needs release notes
2792018-08-14T17:07:32 *** vexbuy_ has joined #bitcoin-core-dev
2802018-08-14T17:10:57 *** vexbuy has quit IRC
2812018-08-14T17:11:12 *** Rootsudo has quit IRC
2822018-08-14T17:34:02 *** d9b4bef9 has quit IRC
2832018-08-14T17:35:07 *** d9b4bef9 has joined #bitcoin-core-dev
2842018-08-14T17:40:10 *** Rootsudo has joined #bitcoin-core-dev
2852018-08-14T17:40:56 *** grubles has quit IRC
2862018-08-14T17:41:19 *** grubles has joined #bitcoin-core-dev
2872018-08-14T17:44:25 *** Victorsueca has quit IRC
2882018-08-14T17:45:58 *** Victorsueca has joined #bitcoin-core-dev
2892018-08-14T17:46:11 *** plankers has quit IRC
2902018-08-14T17:47:57 <wumpus> gitian build--at least for linux--of 0.17 branch worked, phew
2912018-08-14T17:48:53 <wumpus> going to test at least the ARM executables
2922018-08-14T17:49:57 *** StopAndDecrypt has quit IRC
2932018-08-14T17:52:43 *** StopAndDecrypt has joined #bitcoin-core-dev
2942018-08-14T17:57:49 <instagibbs> anyone else getting github.com domain name res failure for git
2952018-08-14T17:58:09 <instagibbs> oh sike, i just have no internet on the device
2962018-08-14T17:58:44 <sipa> i confirm your IRC client is on the internet
2972018-08-14T17:58:47 *** sipa sets mode: -o sipa
2982018-08-14T17:59:01 <instagibbs> the burdens of running multiple computing devices...
2992018-08-14T17:59:26 *** Rootsudo has quit IRC
3002018-08-14T17:59:57 *** Rootsudo has joined #bitcoin-core-dev
3012018-08-14T18:00:35 *** Rootsudo has joined #bitcoin-core-dev
3022018-08-14T18:00:59 *** Rootsudo has quit IRC
3032018-08-14T18:01:32 *** Rootsudo has joined #bitcoin-core-dev
3042018-08-14T18:02:10 *** Rootsudo has joined #bitcoin-core-dev
3052018-08-14T18:03:04 *** Rootsudo has joined #bitcoin-core-dev
3062018-08-14T18:03:18 *** Rootsudo has quit IRC
3072018-08-14T18:03:43 *** math_ has joined #bitcoin-core-dev
3082018-08-14T18:12:14 *** csknk has joined #bitcoin-core-dev
3092018-08-14T18:13:21 *** SopaXorzTaker has joined #bitcoin-core-dev
3102018-08-14T18:28:46 *** itaseski has joined #bitcoin-core-dev
3112018-08-14T18:30:07 *** Jmabsd has quit IRC
3122018-08-14T18:38:52 *** timothy has quit IRC
3132018-08-14T19:13:15 <BlueMatt> hmmm, MarcoFalke points out that it looks like we may be undercounting mempool memory usage by sizeof(CTransaction)*txcount
3142018-08-14T19:14:17 <gmaxwell> BlueMatt: so fix it?
3152018-08-14T19:14:51 <BlueMatt> oh, wait, nvm, I'm misreading it
3162018-08-14T19:15:00 <BlueMatt> gmaxwell: I was hoping for someone to double-check me, but I found myself to be wrong faster :p
3172018-08-14T19:15:46 <gmaxwell> fixing it also has the property of showing you that you're wrong fast. :P
3182018-08-14T19:16:11 *** SopaXorzTaker has quit IRC
3192018-08-14T19:16:15 <BlueMatt> lol true
3202018-08-14T19:21:51 <jonasschnelli_> hmm... manually added nodes with -connect have no service flags?!
3212018-08-14T19:22:08 *** jonasschnelli_ is now known as jonasschnelli
3222018-08-14T19:23:15 <jonasschnelli> If its unknown if the peer supports NODE_ENCRYPTION, I guess just trying and ^NODE_ENCRYPTION if failed seems accptable
3232018-08-14T19:25:12 <gmaxwell> probably just try. maybe in a couple years we mandate encryption for connect and addnode (and add something for a connect that doesn't support it)
3242018-08-14T19:27:23 <jonasschnelli> gmaxwell: you mean also trying on peers not signalling NODE_ENCRYPTION via the service flags (and eventually update addrman's service flags if failed to encrypt)?
3252018-08-14T19:28:11 <sipa> i would only try it for things that signal encryption
3262018-08-14T19:28:25 <sipa> if it doesn't work, drop the flag in your addrman and disconnect
3272018-08-14T19:28:37 <gmaxwell> I was specifically talking about connect and addnode, where there are no 'flags' before we connect.
3282018-08-14T19:28:46 <sipa> ah, makes sense
3292018-08-14T19:28:55 <sipa> uh, that means trying twice :(
3302018-08-14T19:29:06 <gmaxwell> if they don't support it.
3312018-08-14T19:29:12 <gmaxwell> Do you see an alternative?
3322018-08-14T19:29:28 <gmaxwell> We could immediately introduce flags to connect and addnode to say that crypto isn't in use.
3332018-08-14T19:29:31 <sipa> -encaddnode -encconnect :)
3342018-08-14T19:29:48 <gmaxwell> encryption should be the default.
3352018-08-14T19:30:18 <gmaxwell> Ignoring the initial deployment catch22, I dont think there is much reason to even support connect/addnode to non-encryption supporting things...
3362018-08-14T19:30:32 <jonasschnelli> indeed...
3372018-08-14T19:30:33 <sipa> yeah
3382018-08-14T19:30:49 <sipa> but you don't want existing addnode=IP lines in bitcoin.conf files suddenly fail
3392018-08-14T19:31:05 <jonasschnelli> I think if -netconnection is enabled (which could be the default), addnode (and friends) should enforce encrypted peers
3402018-08-14T19:31:24 <gmaxwell> sipa: Major versions can break things, thats what release notes are for.
3412018-08-14T19:31:45 *** michaels_ has joined #bitcoin-core-dev
3422018-08-14T19:32:01 <sipa> or we could add encryption support, and a way to add flags to addnode/connect in one version
3432018-08-14T19:32:04 <jonasschnelli> I think failing on addnodes that are non encrypted is probably a good thing
3442018-08-14T19:32:09 <sipa> and then change the default to encryption in a later version
3452018-08-14T19:32:20 <jonasschnelli> or that,.. yes
3462018-08-14T19:32:20 <gmaxwell> we could make connect and addnode able to take an parameter e.g. connect=1.2.3.4$nocrypto
3472018-08-14T19:32:35 <gmaxwell> yes, that would be okay.
3482018-08-14T19:32:35 <sipa> that may be necessary regardless, yes
3492018-08-14T19:33:00 <sipa> i wonder if we should call it encryption
3502018-08-14T19:33:12 <jonasschnelli> enciphering? *duck*?
3512018-08-14T19:33:17 <gmaxwell> connect=1.2.3.4$crypto connect=1.2.3.4$nocrypto ... and the default if no specified starts out no and gets switched later.
3522018-08-14T19:33:26 <sipa> maybe it should just be "v2 protocol" (which happens to encrypt, but it's really a new non-backward compatible protocol encoding
3532018-08-14T19:34:34 <jonasschnelli> Yes. That sounds good... I just fear scope creeping if we label it like that
3542018-08-14T19:34:50 <sipa> okay
3552018-08-14T19:34:53 <sipa> just an idea
3562018-08-14T19:34:57 <jonasschnelli> "Ah. v2 protocol, why don't use change the inv that way",. etc.
3572018-08-14T19:35:17 <sipa> but encryption isn't something that should be advertized really
3582018-08-14T19:35:21 <jonasschnelli> But since it's a new protocol (kind-of a one time chance), those ideas are maybe welcome
3592018-08-14T19:35:54 <sipa> or "v2 transport"
3602018-08-14T19:36:02 <sipa> it's not really the protocol that changes, just the encoding
3612018-08-14T19:36:03 <jonasschnelli> sipa: what do you mean with "advertised"?
3622018-08-14T19:36:21 <jonasschnelli> sipa: Yes. "v2 transport" is more accurate
3632018-08-14T19:36:58 <sipa> if you use the term 'encryption' to describe the feature there may be a false sense of security risk
3642018-08-14T19:37:03 *** photonclock___ has joined #bitcoin-core-dev
3652018-08-14T19:37:42 <jonasschnelli> Hm... you mean by not protecting from an active MITM?
3662018-08-14T19:38:15 <jonasschnelli> I guess using the word encryption when it comes to the v2 transport would not be entirely wrong though
3672018-08-14T19:38:19 *** photonclock_ has quit IRC
3682018-08-14T19:38:20 *** photonclock___ is now known as photonclock_
3692018-08-14T19:38:59 <sipa> well encryption certainly protects against certain attacks, but not nearly all the ones that people think of when you say encryption :)
3702018-08-14T19:39:20 *** michaels_ has quit IRC
3712018-08-14T19:39:20 <gmaxwell> Yea, it's more than encrypion, also encryption implies properties that it doesn't provide.
3722018-08-14T19:39:42 <gmaxwell> e.g. the oppturnistic encryption does not prevent MITM.
3732018-08-14T19:40:28 <jonasschnelli> It eventually does prevent from MITM because an MITM would be easy to detect, but it does not protect from MITM
3742018-08-14T19:40:32 *** Krellan has joined #bitcoin-core-dev
3752018-08-14T19:41:15 <sipa> not without somewhat deployed authentication
3762018-08-14T19:41:33 <jonasschnelli> Yes
3772018-08-14T19:41:54 <gmaxwell> in any case, we'll want to be able to provide arguments to addnode and connect later for auth keys.
3782018-08-14T19:42:07 <jonasschnelli> With the "stealth handshake" (the very first 32byte message/key exchange), is there anything we should plan for in case we want to add something like RLWE to the handshake
3792018-08-14T19:42:18 <jonasschnelli> +?
3802018-08-14T19:42:37 <gmaxwell> If we did something like add rwle we could establish the secp256k1 handshake first and then inside that stream upgrade.
3812018-08-14T19:43:27 *** bytting has joined #bitcoin-core-dev
3822018-08-14T19:44:40 <jonasschnelli> gmaxwell: wouldn't that partially break the "stealth" component (if we assume ecdh in secp256k1 is broken) since the inner 2nd handshake would probably require standard p2p message encryption?
3832018-08-14T19:45:12 <sipa> jonasschnelli: not more than the current secp stealth component is broken by being sent in cleartest
3842018-08-14T19:45:19 *** Randolf has quit IRC
3852018-08-14T19:45:39 <gmaxwell> ^ plus the 'stealth's is pretty weak, it's mostly just making harder to use dumb pattern matching to block.
3862018-08-14T19:47:16 <jonasschnelli> We could allow additional dummy data in the encryption handshake as we do in the v2 message encoding protocol to make DPI harder
3872018-08-14T19:47:27 <gmaxwell> hm. it really would be much easier if the initial handshake had a flag. e.g. [ecdh key][byte] it could still block dumb pattern matching by making the byte xored with the last byte of the pubkey.
3882018-08-14T19:48:21 <gmaxwell> kinda irritating to add RLWE after the fact, sadly.
3892018-08-14T19:48:58 <jonasschnelli> I think the change is already pretty huge,... I think adding more should be avoided
3902018-08-14T19:49:04 <jonasschnelli> The tor argument "collect now, decrypt later" may not be applicable 1:1 to bitcoin
3912018-08-14T19:49:25 <jonasschnelli> Especially as long as there are no private p2p extensions and an internal auth mechanism
3922018-08-14T19:49:42 <jonasschnelli> IMO deploying RLWE together with auth could make sense
3932018-08-14T19:50:30 <sipa> how much code is it?
3942018-08-14T19:51:05 <jonasschnelli> Right now +1,563/-178 (incomplete, missing tests)
3952018-08-14T19:51:15 <gmaxwell> RWLE is small, one sec.
3962018-08-14T19:52:07 <jonasschnelli> I guess the new code is very critical. Must be review profound
3972018-08-14T19:56:35 *** rls has joined #bitcoin-core-dev
3982018-08-14T19:56:46 <gmaxwell> sipa: the ref implementation of newhope appears to be Total Physical Source Lines of Code (SLOC) = 1,347
3992018-08-14T19:56:51 <gmaxwell> which includes some tests and stuff.
4002018-08-14T19:56:59 <gmaxwell> obviously it's bigger with the AVX versions and whatnot.
4012018-08-14T19:57:46 <jonasschnelli> I guess AVX for Chacha, Poly1305 and newhope could follow later?
4022018-08-14T19:58:02 <gmaxwell> as far as security goes, the interfaces is really trivial, so it's easy to review that the worst risk it presents is not adding security, leaking something about its randomness, or being slow.
4032018-08-14T19:58:16 <gmaxwell> It also has been deployed in _chrome_ as part of an expirement with ssl.
4042018-08-14T19:58:47 <gmaxwell> (they made an expiremental handshake for SSL that did the H(ECDH||newhope) thing.
4052018-08-14T19:58:59 <gmaxwell> implementation is here: https://github.com/newhopecrypto/newhope-usenix/tree/master/ref
4062018-08-14T19:59:40 <gmaxwell> I think the worst outcome from deploying it is that a month after wide deployment, the security is broken completely and we're stuck carrying it around (and wasting cpu cycles on it) even though it does nothing. :P
4072018-08-14T20:00:27 <jonasschnelli> I somehow would prefer a two step implementation (and eventually also specification) approach from current v1 non encrypted network protocol to a quantum safe v2 (or v2.1) protocol
4082018-08-14T20:00:50 <gmaxwell> ah, the torref/toravx implementations are apparently constant time.
4092018-08-14T20:01:26 <jonasschnelli> Is there an anti DPI argument for using 32byte keyhandshakes rather then 64byte?
4102018-08-14T20:01:33 <gmaxwell> jonasschnelli: sad thing is that the quantum safe thing is probably not worth doing on its own.
4112018-08-14T20:01:51 <gmaxwell> jonasschnelli: what would the extra 64 bytes be?
4122018-08-14T20:01:56 <gmaxwell> er extra 32.
4132018-08-14T20:02:32 <jonasschnelli> if we want to add a flag but want to avoid 33bytes (or 34) due to DPI issues, we could pad up to 64?
4142018-08-14T20:03:22 <gmaxwell> I don't think we want to avoid 33. We want to avoid fixed bytes. E.g. "if bytes 32-45 are 0xdeadbeef... reject"
4152018-08-14T20:04:24 <jonasschnelli> Oh that. So the xoring with the last pubkey byte for the flag could then be accptable... I think
4162018-08-14T20:04:59 <gmaxwell> right.
4172018-08-14T20:05:08 <jonasschnelli> gmaxwell: why is upgrading the handshake later to include newhope be "not worth doing on its own"?
4182018-08-14T20:05:43 <jonasschnelli> you mean the additional (questionable) security versus the deployment hassle?
4192018-08-14T20:05:48 <sipa> i think upgrading the transport can be upgraded later easily enough that we don't need to rush including it right now
4202018-08-14T20:06:01 <gmaxwell> because the security benefit is quite conjectural. so taking a network upgrade cycle, with incompatiblities and stuff, to maybe gain nothing.
4212018-08-14T20:06:01 *** arubi has quit IRC
4222018-08-14T20:06:19 <gmaxwell> So for example I think to do newhope nicely later, just a flag isn't enough.
4232018-08-14T20:06:29 *** arubi has joined #bitcoin-core-dev
4242018-08-14T20:06:33 <gmaxwell> because you want the initator to send their DH value in the first message.
4252018-08-14T20:07:03 <gmaxwell> well I don't think we need to rush for sure. But if nothing else it's useful to think about how we would take the next step.
4262018-08-14T20:07:19 <gmaxwell> So lemme talk though my thought process a bit.
4272018-08-14T20:07:24 <jonasschnelli> what if the flag comes first to the message content and length can change later?
4282018-08-14T20:08:13 <gmaxwell> earlier today I was thinking "we could deploy newhope by just brining up the secp256k1 encryption, then sending a rekey message that triggers upgrading." but then I realized that runs into the problem we had before of having to do the keying twice-- once for each direction.
4292018-08-14T20:09:06 <gmaxwell> jonasschnelli: how does the recipent even know the length?
4302018-08-14T20:09:23 <gmaxwell> (if its not fixed)
4312018-08-14T20:09:42 <sipa> wahaha, the low-security version of newhope is called jarjar
4322018-08-14T20:09:54 <jonasschnelli> gmaxwell: right now,... is just looks for 32bytes, if it matches a version message, it transforms the bytes into a legacy v1 message container
4332018-08-14T20:10:08 <jonasschnelli> (and continues with legacy protocol)
4342018-08-14T20:10:21 <jonasschnelli> if not a version message, it tried the handshake
4352018-08-14T20:10:28 <jonasschnelli> *tries
4362018-08-14T20:11:00 <sipa> that seems overly complicated
4372018-08-14T20:11:12 <gmaxwell> okay, so your point is that there could be extra data, but how does a current client know to ignore the extradata? e.g. why won't that just look like an invalid encryption once the handshake completes.
4382018-08-14T20:11:21 <jonasschnelli> sipa: idea how to make this simpler?
4392018-08-14T20:11:31 <sipa> i think you should just assume a connection is encrypted if the flag is set, and it will fail if it turns out it wasn't encrypted
4402018-08-14T20:11:44 <sipa> at which point you just disconnect and try another peer
4412018-08-14T20:12:02 <jonasschnelli> sipa: I thought we want a mode where encryption is optional
4422018-08-14T20:12:09 <gmaxwell> It is optional.
4432018-08-14T20:12:51 <gmaxwell> sipa: how does this avoid an attack where the first peer you connect to gives you the encryption flag set for everyone, causing you to be unable to connect to most of the network?
4442018-08-14T20:14:04 <jonasschnelli> I can't follow. That would mean we drop every connection that failes to do a handshake (think of SPV clients, etc.)?
4452018-08-14T20:14:21 <sipa> jonasschnelli: ah, for incoming connections!
4462018-08-14T20:14:22 <sipa> ugh
4472018-08-14T20:14:32 <gmaxwell> I had the same confusion as sipa.
4482018-08-14T20:14:33 <jonasschnelli> Outgoind is easy
4492018-08-14T20:14:58 <jonasschnelli> Incomming IMHO must be ready to detect a handshake OR a version legacy msg
4502018-08-14T20:15:22 <sipa> unless they're separate ports or something like that... but yeah
4512018-08-14T20:15:53 <jonasschnelli> But code wise its simple: buffer the first 32bytes, check if it is (very likely) a version message and migrate the message type to a legacy message
4522018-08-14T20:15:57 <jonasschnelli> https://github.com/bitcoin/bitcoin/commit/edfbd082af48f3a8f4447083e847e67aa4b2a40b#diff-9a82240fe7dfe86564178691cc57f2f1R791
4532018-08-14T20:16:16 <jonasschnelli> (& avoid pubkeys that start with the network magic & 'version')
4542018-08-14T20:16:30 <sipa> ah yes, that seems reasonable
4552018-08-14T20:17:05 <jonasschnelli> If the handshake flag would be the first byte, and the xor key the second, we could read to bytes and figure out if we need to buffer 64 or 32
4562018-08-14T20:17:10 <sipa> i think it could just be "pubkeys cannot start with the network magic"
4572018-08-14T20:18:11 <jonasschnelli> Wouldn't that reduce the possible key-space by 2^28?
4582018-08-14T20:18:21 <jonasschnelli> I guess I'm wrong though. :)
4592018-08-14T20:19:12 <sipa> from 255 bits to 254.999999999664 bits of entropy
4602018-08-14T20:19:24 <gmaxwell> and not in a useful way that helps attacks regardless.
4612018-08-14T20:20:24 <jonasschnelli> Okay. I see
4622018-08-14T20:20:45 <jonasschnelli> Is using the first pubkey bytes as flag xor key reasonable?
4632018-08-14T20:21:16 <sipa> can't the flag be inside the encrypted stream?
4642018-08-14T20:21:43 <jonasschnelli> It can, but we then would assume that ECDH must always be done
4652018-08-14T20:21:49 <sipa> i think that's fine
4662018-08-14T20:21:57 <gmaxwell> now we wind back to my prior comment about upgrading and synchronizing both directions.
4672018-08-14T20:22:08 <sipa> i don't mean a flag to signal upgrading
4682018-08-14T20:22:14 <jonasschnelli> I guess then we don't need a flag, we can handle it with messages then
4692018-08-14T20:22:16 <sipa> just a flag that says "this is protocol version X"
4702018-08-14T20:22:23 <gmaxwell> I think it's fine if ECDH is always done.
4712018-08-14T20:22:25 <sipa> if you don't understand the flag, disconnect
4722018-08-14T20:22:39 <jonasschnelli> gmaxwell: why is re-keying in both directions a problem?
4732018-08-14T20:22:51 <sipa> and in a new version, the RWLE can be mandatory in both directions, with no synchronization issues
4742018-08-14T20:22:53 <gmaxwell> twice the computation and overhead.
4752018-08-14T20:23:03 <jonasschnelli> AFAIK the current rekeying can only be initiated by the encryption responder (server) by sending a "rekey" message
4762018-08-14T20:23:15 <sipa> both parties should be able to rekey
4772018-08-14T20:23:24 <sipa> or it should be automatic after a certain amount of data
4782018-08-14T20:23:40 <jonasschnelli> Yes. 1GB is currently the specs and not below 10s
4792018-08-14T20:23:49 <gmaxwell> sipa: I pointed out before that we ought to support time based so that we get forward compromise resistance on low traffic links.
4802018-08-14T20:24:11 <sipa> also, is rekeying just hashing the existing encryption key, or is it a new ECDH negotiation?
4812018-08-14T20:24:17 <jonasschnelli> just hashing
4822018-08-14T20:24:18 <gmaxwell> it should be the former.
4832018-08-14T20:24:20 <gmaxwell> right.
4842018-08-14T20:24:24 <sipa> okay
4852018-08-14T20:24:29 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
4862018-08-14T20:24:31 <gmaxwell> I don't see any value in repeating ECDH for incremental rekeying.
4872018-08-14T20:24:41 <sipa> yeah
4882018-08-14T20:25:09 *** rls has quit IRC
4892018-08-14T20:25:15 <gmaxwell> in any case, if your intention is to encrypt the protocol version that means the initator cannot send a version without an extra roundtrip.
4902018-08-14T20:25:34 <sipa> i don't think that matters
4912018-08-14T20:25:34 <gmaxwell> I guess we don't really care too much about roundtrips, but it's the consequence.
4922018-08-14T20:25:43 <sipa> the responder picks the version of the protocl
4932018-08-14T20:25:50 <sipa> of the initiator doesn't like it, disconnect
4942018-08-14T20:25:53 <gmaxwell> but the initator has to offer.
4952018-08-14T20:26:09 <gmaxwell> or the responder will pick something the initator doesn't support, gratitiously.
4962018-08-14T20:26:23 <sipa> that's no different than now
4972018-08-14T20:26:50 <gmaxwell> So say, for example, you deploy newhope on your node... now you lose crypto to all existing peers? because you pick newhope and then they drop you?
4982018-08-14T20:27:19 <sipa> ah yes, i see; there is an assymetry in knowledge
4992018-08-14T20:27:33 <sipa> the initiator can be expected to know what the responder supports beforehand, but not the other way around
5002018-08-14T20:28:57 <jonasschnelli> Would that be an argument for the flag at the very beginning of the handshake?
5012018-08-14T20:29:30 <gmaxwell> or, it's just something that we'd have to handle with an additional round trip.
5022018-08-14T20:29:48 <sipa> i think that's fine
5032018-08-14T20:30:38 <gmaxwell> e.g. ecdh-> <-ecdh,enc(<flags>, extradata like a new hope handshake) ->enc(flags, payload)...
5042018-08-14T20:30:38 <jonasschnelli> But I currently don't know how to handle the re-key sync problem,.. I guess dropping all messages after peer has sent the "rekey" message until it gots the "rekey-ack" response is a no go
5052018-08-14T20:31:06 <gmaxwell> the rekey is determinstic. it should just be you send a rekey message and then the very next byte is encrypted with the next key.
5062018-08-14T20:31:19 <sipa> and do it separately for both directions
5072018-08-14T20:31:20 <gmaxwell> And have the rekey operate independantly for each direction.
5082018-08-14T20:31:39 <gmaxwell> rekeys are cheap, they're fine to do independantly.
5092018-08-14T20:31:41 <jonasschnelli> Ah yes. That would work.
5102018-08-14T20:31:49 <gmaxwell> I want to avoid doing DH protocols independantly even for a newhope upgrade though.
5112018-08-14T20:32:04 <sipa> there could also be a reqrekey message message, which requests that the other party do a rekey, but it has no effect on the protocol until they respond with a rekey
5122018-08-14T20:32:59 <gmaxwell> sipa: I think instead you can just say that you have to do at least one rekey between two rekeys by the other side.
5132018-08-14T20:33:01 <jonasschnelli> or could an initiated rekey from peer A requires an rekeying from peer B within a timeout of X?
5142018-08-14T20:33:21 <gmaxwell> jonasschnelli: then you get into a rekey looop for a link with latency higher than X. :P :P
5152018-08-14T20:33:44 <gmaxwell> But just saying that you must rekey if you have seen two rekeys in the other direction since the last time you rekeyed, I think doesn't have that problem.
5162018-08-14T20:33:44 <jonasschnelli> heh... on dump implementations, yes. But point taken.
5172018-08-14T20:34:54 <gmaxwell> or don't even worry about it and just specify that you must rekey after 1hr or 1GB (whichever comes first). And anyone who doesn't is non-conforming and if anyone cares, they could start banning based on the behavior.
5182018-08-14T20:35:25 <jonasschnelli> Yes. Seems the be required anyways.
5192018-08-14T20:36:11 <jonasschnelli> Okay. Thanks. Going back to the "drawing board" (specs and impl.).
5202018-08-14T20:37:15 <sipa> i guess a rekey request is pointless; the other party could obey the request, but still keep the old encryption key in memory
5212018-08-14T20:39:29 <gmaxwell> yep.
5222018-08-14T20:51:20 *** unholymachine has quit IRC
5232018-08-14T20:56:52 *** csknk has quit IRC
5242018-08-14T21:07:08 *** unholymachine has joined #bitcoin-core-dev
5252018-08-14T21:21:26 *** promag has joined #bitcoin-core-dev
5262018-08-14T21:38:08 *** michaelsdunn1 has joined #bitcoin-core-dev
5272018-08-14T21:55:40 *** vexbuy_ has quit IRC
5282018-08-14T21:56:16 *** vexbuy has joined #bitcoin-core-dev
5292018-08-14T21:57:52 *** vexbuy_ has joined #bitcoin-core-dev
5302018-08-14T21:58:57 *** schmidty has quit IRC
5312018-08-14T21:59:35 *** StopAndDecrypt has quit IRC
5322018-08-14T22:00:46 *** vexbuy has quit IRC
5332018-08-14T22:05:34 *** owowo has quit IRC
5342018-08-14T22:06:53 *** aggieben has quit IRC
5352018-08-14T22:11:22 *** itaseski has quit IRC
5362018-08-14T22:21:29 *** bytting has quit IRC
5372018-08-14T22:21:46 *** StopAndDecrypt has joined #bitcoin-core-dev
5382018-08-14T22:31:00 *** michaelsdunn1 has quit IRC
5392018-08-14T22:31:34 *** belcher_ has quit IRC
5402018-08-14T22:39:58 *** justanotheruser has quit IRC
5412018-08-14T22:40:29 *** justan0theruser has joined #bitcoin-core-dev
5422018-08-14T22:46:29 *** Rootsudo has joined #bitcoin-core-dev
5432018-08-14T22:51:42 *** spinza has quit IRC
5442018-08-14T22:56:08 *** Cogito_Ergo_Sum has quit IRC
5452018-08-14T22:58:40 *** spinza has joined #bitcoin-core-dev
5462018-08-14T23:05:29 *** Victorsueca has quit IRC
5472018-08-14T23:06:43 *** Victorsueca has joined #bitcoin-core-dev
5482018-08-14T23:23:04 *** AaronvanW has quit IRC
5492018-08-14T23:43:02 *** d9b4bef9 has quit IRC
5502018-08-14T23:44:36 *** Rootsudo has quit IRC
5512018-08-14T23:54:22 *** polydin has joined #bitcoin-core-dev
5522018-08-14T23:57:38 *** bytting has joined #bitcoin-core-dev
5532018-08-14T23:59:45 *** profmac has quit IRC