12020-09-08T00:00:02 *** AIM` has quit IRC
22020-09-08T00:36:56 *** kanzure has quit IRC
32020-09-08T00:37:07 *** kanzure has joined #bitcoin-core-dev
42020-09-08T00:46:25 *** davec has quit IRC
52020-09-08T00:52:50 *** davec has joined #bitcoin-core-dev
62020-09-08T00:56:50 *** lahwran has joined #bitcoin-core-dev
72020-09-08T01:12:02 *** berndj has quit IRC
82020-09-08T01:12:18 *** berndj has joined #bitcoin-core-dev
92020-09-08T01:40:09 *** luke-jr has quit IRC
102020-09-08T01:41:04 *** luke-jr has joined #bitcoin-core-dev
112020-09-08T02:07:05 *** arowser has quit IRC
122020-09-08T02:07:31 *** arowser has joined #bitcoin-core-dev
132020-09-08T02:38:52 *** justanotheruser has quit IRC
142020-09-08T02:40:24 *** Highway61 has quit IRC
152020-09-08T02:45:05 *** arowser has quit IRC
162020-09-08T02:45:28 *** arowser has joined #bitcoin-core-dev
172020-09-08T02:56:44 *** vadorovsky__ has joined #bitcoin-core-dev
182020-09-08T02:59:03 *** mrostecki_ has quit IRC
192020-09-08T03:00:01 *** lahwran has quit IRC
202020-09-08T03:22:05 *** arowser has quit IRC
212020-09-08T03:22:17 *** davidfg41 has joined #bitcoin-core-dev
222020-09-08T03:22:35 *** arowser has joined #bitcoin-core-dev
232020-09-08T03:23:59 *** Highway61 has joined #bitcoin-core-dev
242020-09-08T03:25:50 *** dongcarl has joined #bitcoin-core-dev
252020-09-08T03:28:11 *** Highway61 has quit IRC
262020-09-08T03:38:16 *** Highway61 has joined #bitcoin-core-dev
272020-09-08T03:38:32 *** vadorovsky__ has quit IRC
282020-09-08T03:39:00 *** vadorovsky__ has joined #bitcoin-core-dev
292020-09-08T03:59:32 *** Davterra has quit IRC
302020-09-08T03:59:48 *** Davterra has joined #bitcoin-core-dev
312020-09-08T04:15:40 *** Highway61 has quit IRC
322020-09-08T04:22:04 *** Highway61 has joined #bitcoin-core-dev
332020-09-08T04:24:54 *** Highway61 has quit IRC
342020-09-08T04:25:14 *** Highway61 has joined #bitcoin-core-dev
352020-09-08T04:31:59 *** Highway61 has quit IRC
362020-09-08T04:32:30 *** Highway61 has joined #bitcoin-core-dev
372020-09-08T04:43:25 *** Highway61 has quit IRC
382020-09-08T04:43:46 *** rodarmor has joined #bitcoin-core-dev
392020-09-08T04:45:42 *** elenaIncognito has joined #bitcoin-core-dev
402020-09-08T04:48:54 *** Highway61 has joined #bitcoin-core-dev
412020-09-08T05:02:36 *** Emcy has quit IRC
422020-09-08T05:02:38 *** Highway61 has quit IRC
432020-09-08T05:04:33 *** Highway61 has joined #bitcoin-core-dev
442020-09-08T05:04:38 *** Emcy has joined #bitcoin-core-dev
452020-09-08T05:10:59 *** IGHOR has quit IRC
462020-09-08T05:13:01 *** IGHOR has joined #bitcoin-core-dev
472020-09-08T05:15:06 *** arowser has quit IRC
482020-09-08T05:15:26 *** arowser has joined #bitcoin-core-dev
492020-09-08T05:17:51 *** elenaIncognito has quit IRC
502020-09-08T05:20:15 *** Highway61 has quit IRC
512020-09-08T05:41:12 <fanquake> Wumpus / sipa: can you block maza1374
522020-09-08T05:41:43 *** Davterra has quit IRC
532020-09-08T05:42:04 *** arowser has quit IRC
542020-09-08T05:42:46 *** arowser has joined #bitcoin-core-dev
552020-09-08T05:57:07 *** bitcoin-git has joined #bitcoin-core-dev
562020-09-08T05:57:08 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice (master...2009-netNo2ChainParams) https://github.com/bitcoin/bitcoin/pull/19914
572020-09-08T05:57:08 *** bitcoin-git has left #bitcoin-core-dev
582020-09-08T05:58:37 *** worc3131 has quit IRC
592020-09-08T06:00:01 *** davidfg41 has quit IRC
602020-09-08T06:17:24 *** jonatack has quit IRC
612020-09-08T06:21:22 *** nihui has joined #bitcoin-core-dev
622020-09-08T06:23:57 *** wumpus has joined #bitcoin-core-dev
632020-09-08T06:37:53 *** andreacab has joined #bitcoin-core-dev
642020-09-08T06:42:14 *** andreacab has quit IRC
652020-09-08T06:42:41 *** andreacab has joined #bitcoin-core-dev
662020-09-08T06:44:05 *** arowser has quit IRC
672020-09-08T06:44:37 *** arowser has joined #bitcoin-core-dev
682020-09-08T06:47:18 *** andreacab has quit IRC
692020-09-08T06:47:25 <gleb> #19895 should be closed I assume.
702020-09-08T06:47:26 <gribble> https://github.com/bitcoin/bitcoin/issues/19895 | I find this line very offensive. · Issue #19895 · bitcoin/bitcoin · GitHub
712020-09-08T06:49:28 *** Guyver2 has joined #bitcoin-core-dev
722020-09-08T06:52:39 <aj> closed/locked
732020-09-08T06:55:49 *** marcoagner has joined #bitcoin-core-dev
742020-09-08T06:56:28 *** luke-jr has quit IRC
752020-09-08T06:57:02 *** luke-jr has joined #bitcoin-core-dev
762020-09-08T06:58:43 *** sipa has quit IRC
772020-09-08T06:59:55 *** bitcoin-git has joined #bitcoin-core-dev
782020-09-08T06:59:55 <bitcoin-git> [bitcoin] hebasto closed pull request #19913: refactor: Drop unused `UniqueLock(Mutex*, ...)` constructor in sync.h (master...200907-sync) https://github.com/bitcoin/bitcoin/pull/19913
792020-09-08T06:59:56 *** bitcoin-git has left #bitcoin-core-dev
802020-09-08T07:00:50 *** sipa has joined #bitcoin-core-dev
812020-09-08T07:05:54 *** vadorovsky__ has quit IRC
822020-09-08T07:06:16 *** vadorovsky__ has joined #bitcoin-core-dev
832020-09-08T07:14:33 *** EagleTM has joined #bitcoin-core-dev
842020-09-08T07:15:20 *** shesek has quit IRC
852020-09-08T07:20:07 *** arowser has quit IRC
862020-09-08T07:20:26 *** arowser has joined #bitcoin-core-dev
872020-09-08T07:21:38 *** davterra has joined #bitcoin-core-dev
882020-09-08T07:28:07 *** reallll has joined #bitcoin-core-dev
892020-09-08T07:31:52 *** belcher_ has quit IRC
902020-09-08T07:40:36 *** kljasdfvv has quit IRC
912020-09-08T07:42:37 *** kljasdfvv has joined #bitcoin-core-dev
922020-09-08T07:56:29 *** xxxx has joined #bitcoin-core-dev
932020-09-08T07:58:53 *** xxxx has quit IRC
942020-09-08T07:59:37 *** promag has joined #bitcoin-core-dev
952020-09-08T08:00:37 *** dermoth_ has joined #bitcoin-core-dev
962020-09-08T08:00:53 *** dermoth has quit IRC
972020-09-08T08:00:55 *** dermoth_ is now known as dermoth
982020-09-08T08:03:55 *** MasterdonX has quit IRC
992020-09-08T08:04:51 *** promag has quit IRC
1002020-09-08T08:05:50 *** MasterdonX has joined #bitcoin-core-dev
1012020-09-08T08:21:46 *** jb55 has quit IRC
1022020-09-08T08:22:14 *** jb55 has joined #bitcoin-core-dev
1032020-09-08T08:28:49 *** vadorovsky__ has quit IRC
1042020-09-08T08:29:12 *** vadorovsky__ has joined #bitcoin-core-dev
1052020-09-08T08:30:56 *** bitcoin-git has joined #bitcoin-core-dev
1062020-09-08T08:30:57 <bitcoin-git> [bitcoin] hebasto opened pull request #19915: refactor: Use Mutex type for some mutexes in CNode class (master...200908-netmx) https://github.com/bitcoin/bitcoin/pull/19915
1072020-09-08T08:30:58 *** bitcoin-git has left #bitcoin-core-dev
1082020-09-08T08:36:44 *** bitcoin-git has joined #bitcoin-core-dev
1092020-09-08T08:36:44 <bitcoin-git> [bitcoin] Crypt-iQ opened pull request #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS when invoking cov_fuzz target (master...cov_fuzz_cleanup_0908) https://github.com/bitcoin/bitcoin/pull/19916
1102020-09-08T08:36:45 *** bitcoin-git has left #bitcoin-core-dev
1112020-09-08T08:42:08 *** theStack has joined #bitcoin-core-dev
1122020-09-08T08:52:49 *** Dean_Guss has quit IRC
1132020-09-08T08:53:01 *** promag has joined #bitcoin-core-dev
1142020-09-08T08:53:10 *** Dean_Guss has joined #bitcoin-core-dev
1152020-09-08T08:55:52 *** Dean_Guss has quit IRC
1162020-09-08T08:56:09 *** andreacab has joined #bitcoin-core-dev
1172020-09-08T08:56:14 *** Dean_Guss has joined #bitcoin-core-dev
1182020-09-08T09:00:01 *** nihui has quit IRC
1192020-09-08T09:00:04 *** jonatack has joined #bitcoin-core-dev
1202020-09-08T09:02:17 *** bitcoin-git has joined #bitcoin-core-dev
1212020-09-08T09:02:17 <bitcoin-git> [bitcoin] naumenkogs closed pull request #19697: Improvements on ADDR caching (master...2020-08-addr-cache-follow-up) https://github.com/bitcoin/bitcoin/pull/19697
1222020-09-08T09:02:18 *** bitcoin-git has left #bitcoin-core-dev
1232020-09-08T09:02:36 *** bitcoin-git has joined #bitcoin-core-dev
1242020-09-08T09:02:36 <bitcoin-git> [bitcoin] naumenkogs reopened pull request #19697: Improvements on ADDR caching (master...2020-08-addr-cache-follow-up) https://github.com/bitcoin/bitcoin/pull/19697
1252020-09-08T09:02:37 *** bitcoin-git has left #bitcoin-core-dev
1262020-09-08T09:05:28 *** jonatack has quit IRC
1272020-09-08T09:06:01 *** promag has quit IRC
1282020-09-08T09:06:20 *** jonatack has joined #bitcoin-core-dev
1292020-09-08T09:08:12 *** andreacab has quit IRC
1302020-09-08T09:08:38 *** andreacab has joined #bitcoin-core-dev
1312020-09-08T09:12:59 *** andreaca_ has joined #bitcoin-core-dev
1322020-09-08T09:13:10 *** andreacab has quit IRC
1332020-09-08T09:14:05 *** arowser has quit IRC
1342020-09-08T09:14:26 *** arowser has joined #bitcoin-core-dev
1352020-09-08T09:15:57 *** andreaca_ has quit IRC
1362020-09-08T09:16:25 *** andreacab has joined #bitcoin-core-dev
1372020-09-08T09:20:48 *** opsec_x12 has quit IRC
1382020-09-08T09:21:02 *** andreacab has quit IRC
1392020-09-08T09:21:13 *** opsec_x12 has joined #bitcoin-core-dev
1402020-09-08T09:22:32 *** shesek has joined #bitcoin-core-dev
1412020-09-08T09:22:38 *** dfkt has joined #bitcoin-core-dev
1422020-09-08T09:27:29 *** andreacab has joined #bitcoin-core-dev
1432020-09-08T09:30:11 <meshcollider> I propose for discussion that fanquake be made an admin on the repo so he can block people like Wladimir and Peter can (assuming he wants the ability)
1442020-09-08T09:33:30 *** dfkt has quit IRC
1452020-09-08T09:43:52 <wumpus> sgtm
1462020-09-08T09:45:47 <provoostenator> No objection. I assume it's announced somewhere who is blocked?
1472020-09-08T09:46:39 <provoostenator> (or I guess the blockee can complain via other channels, it's not like the Black Mirror episode)
1482020-09-08T09:49:05 *** arowser has quit IRC
1492020-09-08T09:49:24 *** arowser has joined #bitcoin-core-dev
1502020-09-08T09:52:01 *** Guyver2_ has joined #bitcoin-core-dev
1512020-09-08T09:52:49 *** Dean_Guss has quit IRC
1522020-09-08T09:53:31 *** Dean_Guss has joined #bitcoin-core-dev
1532020-09-08T09:55:12 *** Guyver2 has quit IRC
1542020-09-08T10:01:08 *** sr_gi has joined #bitcoin-core-dev
1552020-09-08T10:01:13 <wumpus> it's always mentioned here
1562020-09-08T10:02:06 <wumpus> at least, that's what we should aim for
1572020-09-08T10:09:16 *** promag has joined #bitcoin-core-dev
1582020-09-08T10:09:19 <wumpus> apart from the really rare persistent troll it's only been used for obvious fake and scam and spam accounts, who never complain because they understand what they're doing
1592020-09-08T10:09:36 *** sdad12121 has joined #bitcoin-core-dev
1602020-09-08T10:12:10 *** promag has quit IRC
1612020-09-08T10:23:46 *** andreacab has quit IRC
1622020-09-08T10:24:13 *** andreacab has joined #bitcoin-core-dev
1632020-09-08T10:25:17 *** yonatanbl has joined #bitcoin-core-dev
1642020-09-08T10:28:42 *** andreacab has quit IRC
1652020-09-08T10:29:55 <yonatanbl> Can anyone here review the Hebrew translation for Core on Transifex?
1662020-09-08T10:30:45 *** auscompgeek1 has joined #bitcoin-core-dev
1672020-09-08T10:31:19 *** andreacab has joined #bitcoin-core-dev
1682020-09-08T10:36:07 <wumpus> hi, not sure anyone reads Hebrew here but you never know
1692020-09-08T10:37:57 <elichai2> yonatanbl: sure, a link?
1702020-09-08T10:40:16 <yonatanbl> https://www.transifex.com/bitcoin/bitcoin/language/he/
1712020-09-08T10:42:10 <elichai2> oh I thought you meant something specific, I went over it a couple of times in the past, but it's pretty exhausting honestly
1722020-09-08T10:43:27 <yonatanbl> I see
1732020-09-08T10:46:59 *** Guyver2__ has joined #bitcoin-core-dev
1742020-09-08T10:47:27 *** mdunnio has joined #bitcoin-core-dev
1752020-09-08T10:48:14 *** andreacab has quit IRC
1762020-09-08T10:48:32 *** andreacab has joined #bitcoin-core-dev
1772020-09-08T10:50:01 *** Guyver2_ has quit IRC
1782020-09-08T10:52:25 *** mdunnio has quit IRC
1792020-09-08T10:56:37 *** jonatack has quit IRC
1802020-09-08T10:57:31 *** jonatack has joined #bitcoin-core-dev
1812020-09-08T10:59:03 *** vasild has quit IRC
1822020-09-08T11:01:07 *** vasild has joined #bitcoin-core-dev
1832020-09-08T11:03:14 <elichai2> did anyone see this error while trying to compile the fuzzers? `crypto/sha256_sse4.cpp:44:9: error: expected relocatable expression`
1842020-09-08T11:06:32 *** andreacab has quit IRC
1852020-09-08T11:06:55 <wumpus> never saw it before
1862020-09-08T11:07:05 *** andreacab has joined #bitcoin-core-dev
1872020-09-08T11:07:24 <wumpus> apparently it cannot make the inline assembly relocatable? is that a compiler or linker error?
1882020-09-08T11:07:48 *** andreaca_ has joined #bitcoin-core-dev
1892020-09-08T11:09:15 *** Guyver2__ is now known as Guyver2
1902020-09-08T11:11:24 *** andreacab has quit IRC
1912020-09-08T11:12:20 <elichai2> Looks like compiler, bigger output: https://pastebin.com/raw/fnV6J9MR. I'm trying to mix some flags to pinpoint what's doing that (currently it's fuzzer+debug+asan+libfuzzer+clang)
1922020-09-08T11:12:25 *** jonatack has quit IRC
1932020-09-08T11:15:40 *** yonatanbl has quit IRC
1942020-09-08T11:17:18 <elichai2> Ok, that's weird, it only happens with asan+fuzzer, but not with any of them alone (`AS=clang CC=clang CXX=clang++ ./configure --enable-debug --with-incompatible-bdb --enable-fuzz --with-sanitizers=address`)
1952020-09-08T11:17:35 <elichai2> Ops, * `AS=clang CC=clang CXX=clang++ ./configure --enable-debug --with-incompatible-bdb --enable-fuzz --with-sanitizers=fuzzer,address`
1962020-09-08T11:18:49 *** andreaca_ has quit IRC
1972020-09-08T11:19:19 *** andreacab has joined #bitcoin-core-dev
1982020-09-08T11:22:34 *** andreaca_ has joined #bitcoin-core-dev
1992020-09-08T11:23:22 *** andreacab has quit IRC
2002020-09-08T11:25:15 <elichai2> so apparently it only happens with debug, I guess i'll live with longer compile times
2012020-09-08T11:27:05 *** arowser has quit IRC
2022020-09-08T11:27:35 *** arowser has joined #bitcoin-core-dev
2032020-09-08T11:29:01 *** gleb has quit IRC
2042020-09-08T11:29:13 <jonasschnelli> sipa, elichai2, real_or_random: what are your thoughts on the BIP342 comment here: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#gistcomment-3345400
2052020-09-08T11:29:51 <jonasschnelli> Especially the point to retrieve further packets up to MAX_PACKET_LENGTH on an invalid MAC
2062020-09-08T11:30:49 <jonasschnelli> ^ ariard
2072020-09-08T11:36:28 *** gleb has joined #bitcoin-core-dev
2082020-09-08T11:38:03 *** vadorovsky__ has quit IRC
2092020-09-08T11:38:36 <real_or_random> jonasschnelli: oh I think I missed that one, I need to read up on this first
2102020-09-08T11:38:57 <jonasschnelli> would be great! thanks
2112020-09-08T11:39:07 <jonasschnelli> Unifying the error case for invalid MAC and MAX_PACKET_SIZE overflow makes much sense to me
2122020-09-08T11:40:10 *** mrostecki has joined #bitcoin-core-dev
2132020-09-08T11:42:09 *** andreaca_ has quit IRC
2142020-09-08T11:42:36 *** andreacab has joined #bitcoin-core-dev
2152020-09-08T11:46:45 *** andreacab has quit IRC
2162020-09-08T11:48:43 *** worc3131 has joined #bitcoin-core-dev
2172020-09-08T11:55:17 *** Highway61 has joined #bitcoin-core-dev
2182020-09-08T11:56:03 <elichai2> jonasschnelli: hmm I think it would still be obvious that it is an invalid MAC error, but at least it hides the size. what happens if the sender doesn't try to send that many packets? the connection will halt until timeout?
2192020-09-08T11:57:27 *** auscompgeek1 has quit IRC
2202020-09-08T11:58:35 *** hadjiszs has quit IRC
2212020-09-08T12:08:59 <fanquake> meshcollider: fine with me
2222020-09-08T12:10:06 *** arowser has quit IRC
2232020-09-08T12:10:27 *** arowser has joined #bitcoin-core-dev
2242020-09-08T12:12:57 <jonasschnelli> elichai2: yes. It will lead to the timeout... (currently checking the code path)
2252020-09-08T12:14:56 <jonasschnelli> elichai2: the pnode->nLastRecv is indifferent in V1/V2. So no traffic == timeout-disconnect (V1/V2)
2262020-09-08T12:16:35 *** Highway61 has quit IRC
2272020-09-08T12:17:07 *** Highway61 has joined #bitcoin-core-dev
2282020-09-08T12:22:07 *** sammuel86 has joined #bitcoin-core-dev
2292020-09-08T12:23:50 *** EagleTM has quit IRC
2302020-09-08T12:31:54 *** reallll is now known as belcher
2312020-09-08T12:46:27 *** TheRec has quit IRC
2322020-09-08T12:50:40 *** Highway61 has quit IRC
2332020-09-08T12:51:32 *** Highway61 has joined #bitcoin-core-dev
2342020-09-08T12:55:43 *** palazzovincenzo has joined #bitcoin-core-dev
2352020-09-08T12:55:45 *** vincenzopalazzo has quit IRC
2362020-09-08T13:01:45 *** Tennis has joined #bitcoin-core-dev
2372020-09-08T13:02:03 *** ghost43 has quit IRC
2382020-09-08T13:04:05 *** arowser has quit IRC
2392020-09-08T13:04:25 *** arowser has joined #bitcoin-core-dev
2402020-09-08T13:05:05 *** arowser has quit IRC
2412020-09-08T13:05:26 *** arowser has joined #bitcoin-core-dev
2422020-09-08T13:06:05 *** arowser has quit IRC
2432020-09-08T13:06:25 *** arowser has joined #bitcoin-core-dev
2442020-09-08T13:07:06 *** arowser has quit IRC
2452020-09-08T13:07:25 *** arowser has joined #bitcoin-core-dev
2462020-09-08T13:08:06 *** arowser has quit IRC
2472020-09-08T13:08:25 *** arowser has joined #bitcoin-core-dev
2482020-09-08T13:09:06 *** arowser has quit IRC
2492020-09-08T13:09:26 *** arowser has joined #bitcoin-core-dev
2502020-09-08T13:10:05 *** arowser has quit IRC
2512020-09-08T13:10:15 *** TheRec has joined #bitcoin-core-dev
2522020-09-08T13:10:15 *** TheRec has joined #bitcoin-core-dev
2532020-09-08T13:10:26 *** arowser has joined #bitcoin-core-dev
2542020-09-08T13:11:01 *** jonatack has joined #bitcoin-core-dev
2552020-09-08T13:12:05 *** arowser has quit IRC
2562020-09-08T13:12:26 *** arowser has joined #bitcoin-core-dev
2572020-09-08T13:13:05 *** arowser has quit IRC
2582020-09-08T13:13:25 *** arowser has joined #bitcoin-core-dev
2592020-09-08T13:14:05 *** arowser has quit IRC
2602020-09-08T13:14:26 *** arowser has joined #bitcoin-core-dev
2612020-09-08T13:16:38 *** ghost43 has joined #bitcoin-core-dev
2622020-09-08T13:26:04 *** arowser has quit IRC
2632020-09-08T13:26:25 *** arowser has joined #bitcoin-core-dev
2642020-09-08T13:27:29 *** shesek has quit IRC
2652020-09-08T13:30:05 *** arowser has quit IRC
2662020-09-08T13:30:23 *** arowser has joined #bitcoin-core-dev
2672020-09-08T13:43:05 *** arowser has quit IRC
2682020-09-08T13:43:23 *** arowser has joined #bitcoin-core-dev
2692020-09-08T13:45:39 *** mdunnio has joined #bitcoin-core-dev
2702020-09-08T13:54:12 *** justanotheruser has joined #bitcoin-core-dev
2712020-09-08T13:57:26 *** bitcoin-git has joined #bitcoin-core-dev
2722020-09-08T13:57:26 <bitcoin-git> [bitcoin] promag opened pull request #19917: RemoveUnbroadcastTx requires mempool lock (master...2020-09-removeunbroadcasttx) https://github.com/bitcoin/bitcoin/pull/19917
2732020-09-08T13:57:27 *** bitcoin-git has left #bitcoin-core-dev
2742020-09-08T14:12:32 *** mrostecki has quit IRC
2752020-09-08T14:12:54 *** mdunnio has quit IRC
2762020-09-08T14:13:08 *** mdunnio has joined #bitcoin-core-dev
2772020-09-08T14:15:27 *** sr_gi has quit IRC
2782020-09-08T14:15:49 *** sr_gi has joined #bitcoin-core-dev
2792020-09-08T14:34:10 *** harrigan has quit IRC
2802020-09-08T14:34:22 *** harrigan has joined #bitcoin-core-dev
2812020-09-08T14:42:06 *** arowser has quit IRC
2822020-09-08T14:42:26 *** arowser has joined #bitcoin-core-dev
2832020-09-08T14:43:04 *** arowser has quit IRC
2842020-09-08T14:43:04 <jnewbery> #17785 may be close to ready for merge
2852020-09-08T14:43:07 <gribble> https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto · Pull Request #17785 · bitcoin/bitcoin · GitHub
2862020-09-08T14:43:25 *** arowser has joined #bitcoin-core-dev
2872020-09-08T14:44:20 <jnewbery> sipa: not sure if you want to take a quick look. It's somewhat adjacent (though not conflicting) with your work in #19503 and I think you mentioned something about wanting to tidy up how we handle p2p versions
2882020-09-08T14:44:23 <gribble> https://github.com/bitcoin/bitcoin/issues/19503 | Add parameter feature to serialization and use it for CAddress by sipa · Pull Request #19503 · bitcoin/bitcoin · GitHub
2892020-09-08T14:45:25 <jnewbery> reminder: p2p meeting in 15 minutes. One suggested topic so far "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals" #19820 (ariard)
2902020-09-08T14:45:26 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
2912020-09-08T14:46:01 <jnewbery> #19914 is also RFM
2922020-09-08T14:46:03 <gribble> https://github.com/bitcoin/bitcoin/issues/19914 | refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice by MarcoFalke · Pull Request #19914 · bitcoin/bitcoin · GitHub
2932020-09-08T14:52:48 *** lightlike has joined #bitcoin-core-dev
2942020-09-08T15:00:02 *** sammuel86 has quit IRC
2952020-09-08T15:00:18 <jnewbery> #startmeeting
2962020-09-08T15:00:18 <lightningbot> Meeting started Tue Sep 8 15:00:18 2020 UTC. The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
2972020-09-08T15:00:18 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2982020-09-08T15:00:29 <sdaftuar> hello
2992020-09-08T15:00:31 <hebasto> hi
3002020-09-08T15:00:34 <gleb> hi!
3012020-09-08T15:00:35 <jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
3022020-09-08T15:00:36 <ariard> hi
3032020-09-08T15:00:42 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
3042020-09-08T15:00:48 <jnewbery> hi folks
3052020-09-08T15:00:57 <ajonas> hi
3062020-09-08T15:00:57 <sdaftuar> topic suggestion: gleb's PR on netgroup diversity of outbound peers
3072020-09-08T15:01:22 <gleb> sure :)
3082020-09-08T15:01:39 <jonasschnelli> hi
3092020-09-08T15:01:44 <fanquake> hi
3102020-09-08T15:02:04 <jnewbery> one proposed topic in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings: Follow-up on last meeting's "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard)
3112020-09-08T15:02:05 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
3122020-09-08T15:02:10 <amiti> hi
3132020-09-08T15:02:35 <ariard> we can start by gleb's one np
3142020-09-08T15:02:51 <jnewbery> ok, before we get started with those topics, does anyone have any general updates on what they're working on, or what they're prioritizing? Raise your hand if you want to give an update o/
3152020-09-08T15:03:01 <gleb> Over the last 10 days I opened 4 addr-related prs⦠I really think addr needs some attention, and my further work is blocked on this. I know addr is not the most well-known topic. Iâm willing to provide any help to facilitate that review :)
3162020-09-08T15:03:08 <sipa> hi
3172020-09-08T15:03:35 <aj> oh, sdaftuar said something other than hi!
3182020-09-08T15:03:40 <aj> holla
3192020-09-08T15:03:41 <gleb> Some of them is refactoring, other have important implications and fix bugs
3202020-09-08T15:03:43 <jonatack> hi
3212020-09-08T15:03:51 <sdaftuar> aj: hi
3222020-09-08T15:04:02 <aj> sdaftuar: nack
3232020-09-08T15:04:30 <jnewbery> ok, well if no-one else has any general updates, I'll just share one of mine, then we can go onto proposed topics?
3242020-09-08T15:04:39 <sdaftuar> jnewbery: ack
3252020-09-08T15:04:54 <ariard> yes
3262020-09-08T15:04:58 <jnewbery> I'd still encourage review of the remaining backport #19606
3272020-09-08T15:05:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
3282020-09-08T15:05:34 <jnewbery> there was some confusion about Marco's comment a few weeks ago about merge order. Is MarcoFalke here?
3292020-09-08T15:06:13 <jnewbery> Either way, I'd encourage review. It's not a totally clean backport, but it shouldn't be impossible to review
3302020-09-08T15:06:19 <jonatack> quick reminder to review the bip155 and bip324 implementation PRs
3312020-09-08T15:06:41 <jnewbery> #topic netgroup diversity of outbound peers (gleb)
3322020-09-08T15:06:48 <gleb> #19860
3332020-09-08T15:06:49 <gribble> https://github.com/bitcoin/bitcoin/issues/19860 | Improve diversification of new connections: privacy and stability by naumenkogs · Pull Request #19860 · bitcoin/bitcoin · GitHub
3342020-09-08T15:07:17 <sdaftuar> i suggested that topic because some of the changes are non-obvious to me, and thought discussion would help
3352020-09-08T15:07:46 <gleb> This PR has some obvious improvement: e.g. don't look at current feelers when make new persistent connection, because feelers are temporary so shold not affect I believe.
3362020-09-08T15:07:53 <gleb> I guess there is one nuance that is not obvious.
3372020-09-08T15:07:58 *** andreacab has joined #bitcoin-core-dev
3382020-09-08T15:08:30 <gleb> I suggested to not look at the *existent* block-relay-only conns (2 conns we have) while making *new* full relay conns.
3392020-09-08T15:08:55 <gleb> Because block-relay-conns should be more private (we rely on them for anti-eclipse).
3402020-09-08T15:09:36 <gleb> And someone controlling our AddrMan (e.g. by occupying all our full relay slots) may deduce which netgroups are existent block-relay-o conns are taking.
3412020-09-08T15:10:10 <gleb> The disadvantage of this change is that we will have a little less diversity as a whole
3422020-09-08T15:10:24 <gleb> (new full-relay conns may be in same net group with existent block relay only conns)
3432020-09-08T15:10:49 <sdaftuar> That last point is the one that I thought should be the primary consideration, as that seems like it has the greatest effect on our partition-resistance -- more diversity seems better
3442020-09-08T15:10:51 <gleb> So I guess it's questionable whether this privacy benefit worth sacrificing a bit of diversity. And whether this kind of privacy threat is real, in general.
3452020-09-08T15:10:58 <amiti> if someone has taken over our addrman & we're trying to open block-relay-only conns, isn't the bigger concern that we would just be opening connections to the poisoned addresses?
3462020-09-08T15:11:39 <gleb> amiti: I assume that at that time we still have 2 healthy block-relay-only conns, and I want to expose them as little as possible.
3472020-09-08T15:12:16 <ariard> sdaftuar: does the design goal of block-relay-only connections was to mask better block-relay topology, thus masking netgroups of such peers should be in agreement?
3482020-09-08T15:12:57 <gleb> sdaftuar: I was fine with sacrificing diversity here, because it has so little effect. The only difference will be that *just two* existing block-relay-only conns may overlap with new full relay conns.
3492020-09-08T15:13:11 <amiti> whats the worst attack that could be carried out if an adversary knows the netgroups of the conns?
3502020-09-08T15:13:15 <gleb> And if we have more than two in the future, we can make 2 of them private, and N-2 of them overlappable.
3512020-09-08T15:13:28 <jnewbery> gleb: is it fair to say the effect is that we'll have the same level of diversity as we did prior to block-relay-only peers being introduced?
3522020-09-08T15:13:46 <gleb> amiti: they can further deduce what are those peers in the network, and evict us from them.
3532020-09-08T15:13:56 <amiti> gleb: how?
3542020-09-08T15:14:06 <ariard> amiti: I think about looking among available public peers in this netgroup and open connection to them to try to evict inbound slot of your victim
3552020-09-08T15:14:07 <gleb> jnewbery: Yes, I think it's fair. sdaftuar?
3562020-09-08T15:14:17 <sdaftuar> gleb: we do have keyed network groups, so i am curious what you have in mind there?
3572020-09-08T15:14:51 <sdaftuar> jnewbery: yes, i think that's likely true
3582020-09-08T15:14:59 <amiti> ariard: thanks!
3592020-09-08T15:15:02 <sdaftuar> ariard: the goal of the connections is twofold:
3602020-09-08T15:15:30 <sdaftuar> - the main goal is to increase the difficulty/cost/power of an adversary required to carry out a network partitioning attack against a target node
3612020-09-08T15:16:09 <sdaftuar> and the specific motivation was that our existing full-relay connections leak topology information, and fixing that is sort of hopeless in the long run, though we certainly can and should make improvements where possible
3622020-09-08T15:16:27 <jnewbery> the questions I'd ask are: was diversity a problem to block-relay-only peers being introduced? Did block-relay-only peers make it measurably better? I guess there aren't answers to those except "more is generally better"
3632020-09-08T15:16:51 <sdaftuar> - the second goal is a bit more nebulous, but my thinking is that it's easier to get the anti-DoS tradeoffs right if we focus on the different aspects of network traffic separately
3642020-09-08T15:17:06 <sdaftuar> so for instance i think the design goals around transaction relay may leads us to different peering strategies than the design goals around block relay
3652020-09-08T15:17:46 <gleb> jnewbery: In my opinion, block-relay-only connections wasn't intended to improve diversity at all. I'd say it was a side-effect benefit we got for free.
3662020-09-08T15:18:27 <sdaftuar> gleb: i think i agree, but that benefit seems so substantial that i think taking it away for the sake of privacy is hard for me to imagine, without a concrete understanding of where the privacy would be lost
3672020-09-08T15:18:40 <gleb> sdaftuar: an attacker just forces us to connect to a peer from some netgroup, sees that we refuses, and deduces that our block-relay-only is in that group.
3682020-09-08T15:18:42 <sipa> sdaftuar: i think you're missing one point: block-only connections increase partition resistance without the bandwidth overhead that full connections have
3692020-09-08T15:18:51 <sdaftuar> sipa: yes, thank you
3702020-09-08T15:18:57 <ariard> wrt to increase the difficulty/cost/power, I think you can achieve this by either more diversity and/or more non-observability of your peerings, what gleb's PR is underscoring IMO is a potential trade-off between them
3712020-09-08T15:19:20 <sipa> gleb: how can they force us to connect somewhere?
3722020-09-08T15:20:01 <gleb> sipa: have all our full relay slots, feed only selected addr records of their sybils, drop connections and see us connect to one of their sybils
3732020-09-08T15:20:25 <jnewbery> gleb: 'just forces us to connect to a peer from some netgroup' sounds very difficult. If an attacker can already do that, I think we're in a lot of trouble already
3742020-09-08T15:20:41 <sipa> gleb: that sounds like they've already succesfully pattitioned us?
3752020-09-08T15:20:52 <gleb> I assume a scenario when we lost all our full relay slots, but still have 2 block-relay-only slots.
3762020-09-08T15:20:57 <sipa> or are trivially able to do so as well
3772020-09-08T15:21:05 <ariard> do we assume that our full-relay can be discovered through transaction relay in that way you can learn their netgroups and exclude block-relay-o to be there
3782020-09-08T15:21:10 <gleb> b-r-o slots don't answer addr queries i believe, so they won't help to sanitize our addr man
3792020-09-08T15:21:28 <sdaftuar> correct, or rather we ignore addr messages from our block-relay peers
3802020-09-08T15:21:28 *** afb has joined #bitcoin-core-dev
3812020-09-08T15:21:36 <aj> sipa: if we had (say) 10 blocks-only connectoins and 6 tx-relay connections, it might make sense to have separate netgroups for each blocks-only peer and separate netgroups for each tx-relay peer, but not worry about overlap between the two?
3822020-09-08T15:21:56 <ariard> if you can learn the full-relay peers of your victim, you can try to influence peering of those full-relay by exploiting their inbound eviction logic
3832020-09-08T15:21:59 <sdaftuar> aj: isn't more diversity still better?
3842020-09-08T15:22:19 <jonatack> sdaftuar: separate design goals make sense to me as well given the very different characteristics of tx relay and block relay. for instance, from what i see, last tx is frequent, many/most peers, and often in seconds. last block is rare, comes from only a few peers, over minutes and hours.
3852020-09-08T15:22:53 <sipa> my thinking (but i haven't thought/looked too much) is that you want to maximize diversity of (full+blockonly), and of (full) alone
3862020-09-08T15:23:08 <sdaftuar> sipa: that lines up with my intuition as well
3872020-09-08T15:23:16 <ariard> aj: I agree with these logic, but as of today full-relay we have an overlap between connections types, that's more how we address this while moving in this direction
3882020-09-08T15:23:20 <ariard> *this
3892020-09-08T15:23:41 <sipa> the former for partition resistance, the second for actual short-term efficient connectivity
3902020-09-08T15:24:07 <gleb> I just thought that the impact of dropping block-relay-only from the full relay diversity set would be fine. It's just 2 peers. And they still be diverse among themselves.
3912020-09-08T15:24:23 <aj> sdaftuar: i guess my gut feel is that once you have sufficient diversity, then having them be independent gets you more robustness as well since one network can't interfere with the other?
3922020-09-08T15:24:36 <gleb> And block-relay-only will be diverse w.r.t existent full-relay conns. Just not vice versa :)
3932020-09-08T15:24:43 <aj> sdaftuar: (2 peers not being sufficiently diverse, 6-10 maybe being sufficiently diverse)
3942020-09-08T15:24:54 <jnewbery> aj: that seems like a good end-goal. Totally separating logic for the connection types allows us to reason about each individually and prevents potentially privacy/exploitability by not allowing information to leak between the two.
3952020-09-08T15:25:01 <sdaftuar> gleb: that part of the logic is strange to me, because the peering logic is not symmetric depending on what order you connect in?
3962020-09-08T15:25:39 <sipa> jnewbery: hmm, i see the appeal for that too
3972020-09-08T15:25:41 <gleb> sdaftuar: I don't see symmetry as a good goal :)
3982020-09-08T15:26:37 <sdaftuar> aj: yeah so i guess there are two goals, one is how we minimize the likelihood of being partitioned, but then maybe once we're close enough on that point, we can choose other tradeoffs e.g. for robustness/design clarity as jnewbery suggested
3992020-09-08T15:26:39 <gleb> Maybe we should keep this until more block-relay-only, and then make part of them private and part of them diverse?
4002020-09-08T15:27:18 <amiti> I'm still trying to wrap my head around the attack vectors in the scenario (full-relay taken over, block-relay safe). I think ofc diversity is good, but the small decrease might be worthwhile if its offering protection. but I need to understand exactly what its protecting against in order to evaluate that tradeoff.
4012020-09-08T15:27:24 <sdaftuar> it does seem like we're a long way from truly separating connection types, as long as addrman is firmly in the middle here
4022020-09-08T15:27:25 <sipa> sdaftuar: looking at full only when making a new full connection, and looking at both when making a blocksonly connection... isn't that how you'd implememt maximization of diversity for (blocksonly+full) and for (full) alone?
4032020-09-08T15:27:55 <ariard> sdaftuar: non-observability of victim's connections likely minimizes the likelihood of being partitioned
4042020-09-08T15:28:14 <gleb> sipa: this is my exact suggestion btw.
4052020-09-08T15:28:19 <sipa> amiti: i'm not there is a concrete attack beyond "8 connections is easier to partition than 10"
4062020-09-08T15:28:25 <sdaftuar> sipa: i was going to point out that achieving maximum diversity for blocksonly+full is sufficient to achieve maximum diversity for full alone
4072020-09-08T15:28:53 <sipa> sdaftuar: hmm!
4082020-09-08T15:29:04 <sipa> of course
4092020-09-08T15:30:04 <jnewbery> it seems like it's ok for information about full connections to leak into our blocksonly connection logic, since blocksonly are meant to be private?
4102020-09-08T15:30:34 <sdaftuar> i think this comes down to whether we think this attack -- can we observe keyed-netgroup collisions from observed outbound connections -- is practical for some kind of attacker we're concerned about?
4112020-09-08T15:30:45 <gleb> jnewbery: yeah, I think so. Because there are probably better ways to learn full conns anyway
4122020-09-08T15:31:14 <gleb> sdaftuar: do you accept the setting where we lost all our full conns, but 2 block-relay-only are still healthy?
4132020-09-08T15:31:25 <gleb> or you think it's unrealistic
4142020-09-08T15:31:40 <sdaftuar> if our addrman starts off healthy, then i think we're probably ok in that scenario
4152020-09-08T15:32:00 <sdaftuar> if our addrman is already poisoned but for the two block-relay only connections, i think that's a very edge-case scenario to try to optimize for
4162020-09-08T15:32:17 <sdaftuar> (i think we're ok because of feelers, maybe that's wrong)
4172020-09-08T15:32:55 <gleb> i see.
4182020-09-08T15:32:57 <sipa> i have a hard time imagining how that's not a problem
4192020-09-08T15:33:10 <ariard> gleb: when you assume addrman poisoning, do you scope knocking-out the feeler logic by an attacker?
4202020-09-08T15:33:26 <jnewbery> does anchor connections make gleb's scenario more likely?
4212020-09-08T15:33:41 <sdaftuar> sipa: i guess one thing that goes wrong is that eventually nodes go offline, and so in the long run you lose all your honest peers?
4222020-09-08T15:33:43 <sipa> because with all normal connections sybilled, the attacker can probably start poisoning addrman, and leave you no way to recover
4232020-09-08T15:33:54 <amiti> jnewbery: was wondering that. I think so
4242020-09-08T15:33:57 <ariard> jnewbery: I think it makes it easier to observe them as block-relay-o become more stable?
4252020-09-08T15:34:00 <jnewbery> (#17428)
4262020-09-08T15:34:04 <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
4272020-09-08T15:34:29 <sdaftuar> sipa: does this problem get solved if we introduce some level of rotation of tx-relay peers?
4282020-09-08T15:34:40 <gleb> Yeah I don't have big faith in feelers once we lost all our full conns
4292020-09-08T15:34:54 <gleb> We don't even send GETADDR to feelers iirc?
4302020-09-08T15:35:00 <sdaftuar> sorry, i don't mean feelers
4312020-09-08T15:35:07 <sdaftuar> what i mean is the tried-table-collision resolution algorithm
4322020-09-08T15:35:17 <sipa> that's feelers, no?
4332020-09-08T15:35:26 <gleb> oh, that's interesting.
4342020-09-08T15:35:28 <ariard> that's done by feelers connection
4352020-09-08T15:35:29 <sdaftuar> no, feelers are for connecting to NEW table entries and trying to mive them to tried
4362020-09-08T15:35:32 <gleb> Not sure how that thing is effective.
4372020-09-08T15:35:34 <sdaftuar> yes, we call them feelers too
4382020-09-08T15:35:36 <sdaftuar> but it's confusing
4392020-09-08T15:35:50 <sipa> mive?
4402020-09-08T15:35:54 <sdaftuar> move*
4412020-09-08T15:35:56 <jnewbery> I do like the concept of not allowing any information at all to leak from our blocksonly connections into our other connection logic. Even if this particular scenario is unlikely, it's still nice to be able to count out any such similar attacks.
4422020-09-08T15:35:56 <sipa> ah, move
4432020-09-08T15:36:44 <sipa> thinking ahout this, i wonder if we need addr-only connections too
4442020-09-08T15:36:56 <gleb> The worst diversity degradation here btw: 2 newly selected full peers are from the same netgroup as 2 existent block-relay-only conns
4452020-09-08T15:37:03 <gleb> sipa: working on that stuff.
4462020-09-08T15:37:05 <sdaftuar> sipa: yeah i was thinking about that a bit as well
4472020-09-08T15:37:15 <gleb> it's blocked by my 4 addr-related prs :)
4482020-09-08T15:37:23 <sipa> i'm not worried about information leakage of our selection of full/blockonly connections
4492020-09-08T15:37:49 <sipa> but our partitition resistance gained (assuming blockonly is diverse wrt full) is only for block connectivity
4502020-09-08T15:37:53 <sipa> not for addrmam health
4512020-09-08T15:38:04 <sipa> which is valuable, but shorter term
4522020-09-08T15:38:15 <aj> sipa: maybe addr-only connections should mean occassionally requery dns-seeds too (once a day or once a week, poisson'ed eg) ?
4532020-09-08T15:38:31 <sipa> maybe
4542020-09-08T15:38:37 <ariard> sipa: you mean an attacker can't interfere with victim's blockonly connections if it learns their netgroups?
4552020-09-08T15:38:49 <sdaftuar> aj: that leaks different information that people are concerend about i think?
4562020-09-08T15:38:56 <gleb> aj: this is a follow-up for #18421
4572020-09-08T15:38:59 <gribble> https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs · Pull Request #18421 · bitcoin/bitcoin · GitHub
4582020-09-08T15:39:07 <gleb> I gave up on periodic DNS queries for now :)
4592020-09-08T15:39:30 <sipa> ariard: i think that if all connections that convey addr informarion are sybilled, it's game over for addrman sanity
4602020-09-08T15:39:41 <sipa> ariard: and blocksonly connections cannot help with that
4612020-09-08T15:39:55 <gleb> sipa: but we're not eclipsed at least?
4622020-09-08T15:40:04 <sdaftuar> sipa: one alternate implementation idea i had for syncing our chain tip with more peers, was to couple that with addrman updates
4632020-09-08T15:40:13 <sipa> gleb: not eclipsed wrt to block propagation
4642020-09-08T15:40:42 <gleb> sipa: sure.
4652020-09-08T15:40:43 <ariard> sipa: you might still be okay for a while more until your current block-relay-only are stable, and this is already a gain
4662020-09-08T15:40:47 <sipa> gleb: but you are eclipsed wrt addr relay, which means addrman will (if the situation persists) become attacker controlled
4672020-09-08T15:40:48 <sdaftuar> sipa: so that we bump a peer's status (maybe just updating its times in the tried table) only if their tip was synced to something with as much work as ours, or something like that
4682020-09-08T15:42:02 *** proofofkeags has quit IRC
4692020-09-08T15:42:13 <sipa> so i think this means we want full connections, blockonly connections, addronly connections... and diversity of (full+blockonly) and of (full+addronly) ?
4702020-09-08T15:42:13 <sdaftuar> i think it would be helpful to run some simulations on that point
4712020-09-08T15:42:44 <sipa> or just diversity of everything, really
4722020-09-08T15:42:49 <ariard> sdaftuar: if you take this info for future peers selections, you might favor even more performant peers, and tight network topology ?
4732020-09-08T15:43:27 <sipa> ariard: being more or less in sync isn't a very strong preference for.performamt peers
4742020-09-08T15:43:40 <sipa> just an aversion for broken ones
4752020-09-08T15:44:03 <sdaftuar> right, we could put in a tolerance of being a block or two behind, that's very different from having no knowledge of their chain
4762020-09-08T15:44:13 <ariard> sipa: aren't low-grades peers really likely to be late on tip view ?
4772020-09-08T15:44:15 *** bitcoin-git has joined #bitcoin-core-dev
4782020-09-08T15:44:15 <bitcoin-git> [bitcoin] ryanofsky opened pull request #19918: sync: Replace LockAssertion with WeaklyAssertLockHeld (master...pr/lockb) https://github.com/bitcoin/bitcoin/pull/19918
4792020-09-08T15:44:16 *** bitcoin-git has left #bitcoin-core-dev
4802020-09-08T15:44:41 <sipa> ariard: by a few seconds maybe
4812020-09-08T15:45:32 <sdaftuar> sipa: it seems a shame to not relay blocks on addronly links
4822020-09-08T15:45:37 <sdaftuar> (or at least headers)
4832020-09-08T15:45:47 <gleb> sdaftuar: agree.
4842020-09-08T15:45:58 <jnewbery> gleb: one of your concerns was about an attackers knowing about which netgroups you're connected to. Would it make sense for each node to have their own way of dividing the address space into netgroups (eg by clustering ASs differently)
4852020-09-08T15:46:12 <sdaftuar> jnewbery: we do that already, don't we?
4862020-09-08T15:46:19 <sipa> jnewbery: we do!
4872020-09-08T15:46:25 <jnewbery> oh! Good!
4882020-09-08T15:46:28 <sipa> there is an addrman key for that
4892020-09-08T15:46:33 <ariard> should we have a hierarchy of types of traffic, i.e it's okay to relay public informations like block on more private ones (tx/addr) but not the reverse ?
4902020-09-08T15:46:33 <sdaftuar> that's what i said before about keyed network groups
4912020-09-08T15:46:35 <jnewbery> I should have reviewed the AS PRs
4922020-09-08T15:46:48 <jnewbery> sdaftuar: got it. Thanks!
4932020-09-08T15:46:58 <sipa> jnewbery: this was part of the original addrman :)
4942020-09-08T15:47:06 <gleb> Yeah, this part makes it a bit less realistic.
4952020-09-08T15:47:17 <jonatack> question: how effective is -seednode/-addnode to trusted peers as an anti-eclipse tactic?
4962020-09-08T15:47:35 <jnewbery> sipa: ah, ok. I guess I should just review more of the code in general then :)
4972020-09-08T15:47:43 <sipa> jonatack: assuming no network-level attacker, addnode is great for that
4982020-09-08T15:47:57 <sdaftuar> well, hopefully your trusted peer is also not eclipsed :)
4992020-09-08T15:48:20 <ariard> jonatack: really depends of the capabilites of your eclipse attacker
5002020-09-08T15:48:43 <sipa> i see no reason why you wouldn't also send blocks over addr links, agree
5012020-09-08T15:48:58 <sdaftuar> sipa: so perhaps we should have two kinds of block-relay links then
5022020-09-08T15:48:59 <jonatack> thanks. i seem to recall matt tweeting about doing that a while back
5032020-09-08T15:49:21 <gleb> sdaftuar: I'm lost. Which kinds?
5042020-09-08T15:49:28 *** andreacab has quit IRC
5052020-09-08T15:49:51 <sipa> gleb: blocksonly and addrplusblocksonly
5062020-09-08T15:49:55 *** andreacab has joined #bitcoin-core-dev
5072020-09-08T15:50:01 <aj> is the idea that addr-relay nodes are long-lived or short-lived (like feelers) ?
5082020-09-08T15:50:21 <sipa> long-lived, i'd say
5092020-09-08T15:50:25 <sdaftuar> aj: i think they could be long lived? they would be very low bandwidth
5102020-09-08T15:50:25 <gleb> I have a branch with short-lived self-announcement addr links :)
5112020-09-08T15:50:35 <ariard> even if they're short-lived you want to do headers-sync on them
5122020-09-08T15:50:40 <gleb> But that's different from what was discussed.
5132020-09-08T15:51:22 <lightlike> hi - we probably can't rely much on our addr-links staying private, or can we?
5142020-09-08T15:51:28 <aj> so blocks-only is eclipse prevention, addr+blocks is low-bw extra diversity, tx-relay is tx relay?
5152020-09-08T15:51:39 <sdaftuar> i'm actually not sure if it's better to use a connection slot on a long-lived addr+block-relay peer, than it is to just rotate our full-relay peers some and get addrman updates from the getaddr message we send
5162020-09-08T15:51:43 <jnewbery> We have 10 minutes left and one other topic (What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals)
5172020-09-08T15:51:56 <jnewbery> ariard: are you happy to punt that to the next meeting?
5182020-09-08T15:52:01 <ariard> aj: being eclipsed at the tx-relay level is really bad for offchain stuff
5192020-09-08T15:52:12 <ariard> jnewbery: I feel we need it better to end on this topics
5202020-09-08T15:52:26 *** andreacab has quit IRC
5212020-09-08T15:52:27 <aj> ariard: not as bad as being eclipsed from the most-work chain though
5222020-09-08T15:52:32 *** andreacab has joined #bitcoin-core-dev
5232020-09-08T15:52:38 <sdaftuar> lightlike: agreed, addr relay likely leaks topology
5242020-09-08T15:52:56 <aj> sipa: (what's the blocker for getting tx relay overhaul rebased/out-of-draft?)
5252020-09-08T15:53:15 <gleb> sdaftuar: have you checked out caches yet? It's getting better!
5262020-09-08T15:53:26 <sipa> ariard: parse error
5272020-09-08T15:53:28 <jnewbery> ariard: does that mean punt to next meeting?
5282020-09-08T15:53:37 <ariard> aj: in fact I think that's a bit more subtle, you can close your channels without knowing what the state chain is ?
5292020-09-08T15:53:41 <sdaftuar> gleb: no idea what you're referring to...
5302020-09-08T15:53:44 <ariard> jnewbery: yes next meeting :)
5312020-09-08T15:54:02 <gleb> sdaftuar: #18991
5322020-09-08T15:54:06 <gribble> https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs · Pull Request #18991 · bitcoin/bitcoin · GitHub
5332020-09-08T15:54:08 <sdaftuar> gleb: oh, addr-relay privacy leaks
5342020-09-08T15:54:10 <jnewbery> great. Thanks. That'll also give people a bit more time to read your doc here: https://github.com/bitcoin/bitcoin/issues/19820
5352020-09-08T15:54:11 <ariard> sipa: if a LN node can't broadcast its punishment transaction that's worthless to see a revoked commitment transaction on the most-valid PoW chain
5362020-09-08T15:55:09 <sipa> ariard: you know my thinking on that
5372020-09-08T15:55:24 <aj> ariard: if you see the revoked commitment tx, you can aggressively try connecting to many peers to find one that relays honestly; if you don't see the commitment tx at all, your opportunity to do a punishment can time out
5382020-09-08T15:55:42 <sipa> aj: i have a branch where it's half done, but i got preempted by bip340/taproot stuff
5392020-09-08T15:56:07 <ariard> sipa: I know, I know that's the reason to talk about #19820 next time :)
5402020-09-08T15:56:07 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
5412020-09-08T15:57:39 <gleb> Alright, so I think i'll turn that PR into a harmless refactoring (don't diversify by current feeler or oneshot/addr_fetch), and keep the non-diverse/more-private idea for future.
5422020-09-08T15:57:57 <sdaftuar> gleb: that sounds good to me. thanks for the discussion!
5432020-09-08T15:58:01 <sipa> gleb: sounds good
5442020-09-08T15:58:12 <jnewbery> Thanks gleb!
5452020-09-08T15:58:13 <ariard> aj: you can probalistically close your channel, if you don't see block for a hour, that's likely something is wrong (but more an open question how offchain stuff should react in case of block eclipse)
5462020-09-08T15:58:43 <jnewbery> Any final topics before we end? Remember it's feature freeze in 5 weeks (https://github.com/bitcoin/bitcoin/issues/18947) so it's a great time to shill your PRs!
5472020-09-08T15:59:10 <sdaftuar> if we're shilling, i'd love review on #19858
5482020-09-08T15:59:13 <gribble> https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar · Pull Request #19858 · bitcoin/bitcoin · GitHub
5492020-09-08T15:59:24 <ariard> sdaftuar: updated #19871 in the hope to clarify outbound eviction
5502020-09-08T15:59:25 <gribble> https://github.com/bitcoin/bitcoin/issues/19871 | doc: Clarify scope of eviction protection of outbound block-relay peers by ariard · Pull Request #19871 · bitcoin/bitcoin · GitHub
5512020-09-08T15:59:37 <sdaftuar> ariard: thanks, i'll take a look
5522020-09-08T15:59:39 <hebasto> o/
5532020-09-08T15:59:41 <sipa> i have been succesfully shilled
5542020-09-08T15:59:43 <jnewbery> any advances on one shilling?
5552020-09-08T15:59:46 <jnewbery> going once
5562020-09-08T15:59:46 <hebasto> #17785
5572020-09-08T15:59:48 <jonatack> It would be great to have #19643 in master and it seems RFM
5582020-09-08T15:59:48 <gribble> https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto · Pull Request #17785 · bitcoin/bitcoin · GitHub
5592020-09-08T15:59:49 <jnewbery> going twice
5602020-09-08T15:59:51 <gribble> https://github.com/bitcoin/bitcoin/issues/19643 | Add -netinfo peer connections dashboard by jonatack · Pull Request #19643 · bitcoin/bitcoin · GitHub
5612020-09-08T15:59:54 <gleb> super-easy little refactoring which will unlock my future work #19843
5622020-09-08T15:59:55 <gribble> https://github.com/bitcoin/bitcoin/issues/19843 | Refactoring and minor improvement for self-advertisements by naumenkogs · Pull Request #19843 · bitcoin/bitcoin · GitHub
5632020-09-08T15:59:59 <jnewbery> #endmeeting
5642020-09-08T15:59:59 <lightningbot> Meeting ended Tue Sep 8 15:59:59 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5652020-09-08T15:59:59 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.html
5662020-09-08T15:59:59 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.txt
5672020-09-08T15:59:59 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-08-15.00.log.html
5682020-09-08T16:00:16 <sdaftuar> two shillings
5692020-09-08T16:00:31 <jnewbery> sold!
5702020-09-08T16:00:47 <sdaftuar> i forgot what i was bidding on
5712020-09-08T16:05:26 <instagibbs> leading the next core pr review
5722020-09-08T16:06:12 <sdaftuar> sweet, instagibbs i pick you
5732020-09-08T16:07:27 <aj> "tangy and quite full-bodied, with a lasting, mostly pleasant, aftertaste"
5742020-09-08T16:07:34 * aj reviews instagibbs now to get it out of the way
5752020-09-08T16:09:02 <sipa> aj: is that how we'll describe connection types in getpeerinfo ?
5762020-09-08T16:09:26 <sdaftuar> block-relay peers: mostly pleasant?
5772020-09-08T16:10:03 <aj> sipa: full-bodied: relays tx; tangy: relays addresses; lasting aftertase: longlived; mostly pleasant: low but nonzero discouragement score?
5782020-09-08T16:10:59 <sipa> something like that
5792020-09-08T16:11:25 <aj> bool IsTangy(conn_type ct);
5802020-09-08T16:11:28 *** alko89 has quit IRC
5812020-09-08T16:11:38 *** alko89 has joined #bitcoin-core-dev
5822020-09-08T16:12:18 *** lightlike has quit IRC
5832020-09-08T16:13:01 <luke-jr> aj: aftertaste implies you stopped using it..?
5842020-09-08T16:13:15 <sdaftuar> addr-relay peers really have the best aftertaste imo
5852020-09-08T16:13:35 <aj> luke-jr: pause inbetween uses works to i think?
5862020-09-08T16:13:49 <luke-jr> not enough to tell that the aftertaste is lasting
5872020-09-08T16:14:36 <aj> luke-jr: unrelated, any thoughts on https://github.com/bitcoin/bitcoin/pull/19401#pullrequestreview-482271390
5882020-09-08T16:15:19 <aj> (or anyone else, re: gbt for test chains)
5892020-09-08T16:15:35 <luke-jr> aj: I think it's better to avoid special casing test code in the main codebase
5902020-09-08T16:17:21 <luke-jr> (not sure if we do, but we *should* have a test that one node by itself can't mine)
5912020-09-08T16:19:13 <aj> luke-jr: regtest nodes can trivially mine on their own via generate
5922020-09-08T16:19:33 <luke-jr> ok?
5932020-09-08T16:19:36 <aj> luke-jr: not being able to mine without being connected matters for mainnet, sure; but not for anything else
5942020-09-08T16:19:47 <luke-jr> mainnet is all that matters in the end
5952020-09-08T16:21:39 *** EagleTM has joined #bitcoin-core-dev
5962020-09-08T16:23:24 *** Talkless has joined #bitcoin-core-dev
5972020-09-08T16:45:07 *** proofofkeags has joined #bitcoin-core-dev
5982020-09-08T16:45:49 *** cato_ has quit IRC
5992020-09-08T16:46:55 *** bitcoin-git has joined #bitcoin-core-dev
6002020-09-08T16:46:55 <bitcoin-git> [bitcoin] AkioNak opened pull request #19919: bugfix: make LoadWallet assigns status always (master...set_databasestatus) https://github.com/bitcoin/bitcoin/pull/19919
6012020-09-08T16:46:56 *** bitcoin-git has left #bitcoin-core-dev
6022020-09-08T16:51:08 *** cato_ has joined #bitcoin-core-dev
6032020-09-08T16:51:38 *** EagleTM has quit IRC
6042020-09-08T17:05:29 <darosior> jnewbery: you were right regarding #18766: it's much nicer by keeping the feeEstimator as a separate component :)
6052020-09-08T17:05:31 <gribble> https://github.com/bitcoin/bitcoin/issues/18766 | Disable fee estimation in blocksonly mode (by removing the fee estimates global) by darosior · Pull Request #18766 · bitcoin/bitcoin · GitHub
6062020-09-08T17:15:02 *** IGHOR has quit IRC
6072020-09-08T17:17:31 *** IGHOR has joined #bitcoin-core-dev
6082020-09-08T17:24:02 <jnewbery> darosior: cool. Thanks for being open to trying it both ways. Hopefully I'll have time to review the new version this week.
6092020-09-08T17:26:01 *** andreacab has quit IRC
6102020-09-08T17:26:36 *** andreacab has joined #bitcoin-core-dev
6112020-09-08T17:30:47 *** andreacab has quit IRC
6122020-09-08T17:33:46 *** Highway62 has joined #bitcoin-core-dev
6132020-09-08T17:35:33 *** Highway61 has quit IRC
6142020-09-08T17:35:33 *** Highway62 is now known as Highway61
6152020-09-08T17:45:53 *** theStack has quit IRC
6162020-09-08T17:48:13 *** opsec_x12 has quit IRC
6172020-09-08T17:54:51 *** andreacab has joined #bitcoin-core-dev
6182020-09-08T18:00:01 *** afb has quit IRC
6192020-09-08T18:14:31 *** filchef has joined #bitcoin-core-dev
6202020-09-08T18:25:24 *** sr_gi has quit IRC
6212020-09-08T18:26:01 *** sr_gi has joined #bitcoin-core-dev
6222020-09-08T18:36:51 *** andreacab has quit IRC
6232020-09-08T18:38:38 *** andreacab has joined #bitcoin-core-dev
6242020-09-08T18:42:58 *** andreacab has quit IRC
6252020-09-08T18:47:24 *** Highway62 has joined #bitcoin-core-dev
6262020-09-08T18:48:51 *** Highway61 has quit IRC
6272020-09-08T18:54:45 *** ecrist1 has joined #bitcoin-core-dev
6282020-09-08T19:00:35 *** justanotheruser has quit IRC
6292020-09-08T19:03:01 *** afk11 has quit IRC
6302020-09-08T19:03:30 *** afk11 has joined #bitcoin-core-dev
6312020-09-08T19:18:02 *** andreacab has joined #bitcoin-core-dev
6322020-09-08T19:22:53 *** andreacab has quit IRC
6332020-09-08T19:27:59 *** shesek has joined #bitcoin-core-dev
6342020-09-08T19:27:59 *** shesek has joined #bitcoin-core-dev
6352020-09-08T19:31:11 <shesek> does bitcoin core ever verify merkle inclusion proofs? (I assume not, it only verifies that the merkle root matches the set of txids. but maybe I'm missing some other ways its being used?)
6362020-09-08T19:32:00 *** Talkless has quit IRC
6372020-09-08T19:32:04 <sipa> gettxoutproof will let you construct one
6382020-09-08T19:32:09 <sipa> i don't think anything verifies them
6392020-09-08T19:32:15 <phantomcircuit> shesek, why?
6402020-09-08T19:34:10 <shesek> just curious. I was writing about that in a comment in the context of me claiming that merkle trees aren't an essential component of Bitcoin's breakthrough, and someone saying that they are (and being wrong :p)
6412020-09-08T19:34:40 <pinheadmz> sipa isnt there a verifytxoutproof rpc ?
6422020-09-08T19:34:46 <shesek> I wanted to write that full nodes don't ever verify merkle inclusion proofs at all, and wanted to be sure I'm not wrong
6432020-09-08T19:34:53 <sipa> pinheadmz: oh, there is!
6442020-09-08T19:35:03 *** opsec_x122 has joined #bitcoin-core-dev
6452020-09-08T19:35:04 <sipa> shesek: no, they don't even ever receive any
6462020-09-08T19:35:06 <shesek> I was thinking more in the context of the protocol and p2p interaction, not the user facing rpcs
6472020-09-08T19:35:23 <sipa> though they were an essential part of BIP37
6482020-09-08T19:35:29 <shesek> (if anyone is curious: https://news.ycombinator.com/item?id=24407196)
6492020-09-08T19:35:54 <phantomcircuit> shesek, for a full node theres no real difference between receiving a merkle tree and a hash of a list
6502020-09-08T19:36:15 <phantomcircuit> but for spvish clients its very different
6512020-09-08T19:36:57 <sipa> yeah, for a full-blocks-only bitcoin like protocol, the "merkle root" stored in the block header could just be a flat hash of all txids
6522020-09-08T19:36:58 <shesek> right, my claim was that the SPV model isn't all that important, and that if Satoshi released Bitcoin without considering light clients at all it would still be the incredible breakthrough that it is
6532020-09-08T19:37:28 <shesek> I'm aware. :) "If light SPV clients weren't a consideration, we could just concatenate all txids together and use the hash of that in the block header instead of a merkle root, and get the same effect. ... For a full node that has the full list of txids regardless, this is basically meaningless."
6542020-09-08T19:37:29 <yanmaani> is txn noninclusion proofs something bitcoin core intends to include?
6552020-09-08T19:37:41 <yanmaani> 'UTXO X did/did not exist in the UTXO set as of this block"
6562020-09-08T19:37:58 <sipa> yanmaani: the current bitcoin protocol does not permit compact proofs for that
6572020-09-08T19:38:09 *** opsec_x122 has quit IRC
6582020-09-08T19:38:23 *** opsec_x12 has joined #bitcoin-core-dev
6592020-09-08T19:39:49 *** opsec_x122 has joined #bitcoin-core-dev
6602020-09-08T19:39:55 *** opsec_x12 has quit IRC
6612020-09-08T19:40:18 *** opsec_x122 is now known as opsec_x12
6622020-09-08T19:42:12 <yanmaani> I know, but is there any research being done? Like on BIPs or stuff? I know about utreexo
6632020-09-08T19:42:35 <sipa> in that case, you're asking about proposal bitcoin protocol changes, not bitcoin core
6642020-09-08T19:42:53 *** opsec_x122 has joined #bitcoin-core-dev
6652020-09-08T19:43:11 <sipa> utreexo doesn't permit this, as it's insertion ordered
6662020-09-08T19:43:16 *** opsec_x12 has quit IRC
6672020-09-08T19:43:36 <sipa> probably better for #bitcoin-wizards
6682020-09-08T19:48:07 *** arowser has quit IRC
6692020-09-08T19:48:43 *** davterra has quit IRC
6702020-09-08T19:48:44 *** justanotheruser has joined #bitcoin-core-dev
6712020-09-08T19:48:48 *** arowser has joined #bitcoin-core-dev
6722020-09-08T19:59:50 *** crtn32002[m] has joined #bitcoin-core-dev
6732020-09-08T20:03:05 *** gzhao408 has quit IRC
6742020-09-08T20:09:52 *** lightlike has joined #bitcoin-core-dev
6752020-09-08T20:13:05 *** arowser has quit IRC
6762020-09-08T20:13:26 *** arowser has joined #bitcoin-core-dev
6772020-09-08T20:17:12 *** bitcoin-git has joined #bitcoin-core-dev
6782020-09-08T20:17:12 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/147d50d63e07...4f229d8904f8
6792020-09-08T20:17:12 <bitcoin-git> bitcoin/master fa7e407 MarcoFalke: Do not pass chain params to CheckForStaleTipAndEvictPeers twice
6802020-09-08T20:17:13 <bitcoin-git> bitcoin/master 4f229d8 MarcoFalke: Merge #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvi...
6812020-09-08T20:17:14 *** bitcoin-git has left #bitcoin-core-dev
6822020-09-08T20:17:32 *** bitcoin-git has joined #bitcoin-core-dev
6832020-09-08T20:17:32 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice (master...2009-netNo2ChainParams) https://github.com/bitcoin/bitcoin/pull/19914
6842020-09-08T20:17:33 *** bitcoin-git has left #bitcoin-core-dev
6852020-09-08T20:20:22 *** harrigan has quit IRC
6862020-09-08T20:24:03 *** Guyver2 has quit IRC
6872020-09-08T20:53:53 *** gleb has quit IRC
6882020-09-08T20:58:54 *** gleb has joined #bitcoin-core-dev
6892020-09-08T21:00:02 *** ecrist1 has quit IRC
6902020-09-08T21:03:27 *** Highway61 has joined #bitcoin-core-dev
6912020-09-08T21:15:09 *** filchef has joined #bitcoin-core-dev
6922020-09-08T21:21:14 *** Voker571 has joined #bitcoin-core-dev
6932020-09-08T21:21:58 *** promag has joined #bitcoin-core-dev
6942020-09-08T21:22:23 *** davterra has joined #bitcoin-core-dev
6952020-09-08T21:29:27 *** bitcoin-git has joined #bitcoin-core-dev
6962020-09-08T21:29:27 <bitcoin-git> [bitcoin] elichai opened pull request #19920: test: Fuzzing siphash against reference implementation [Request for feedback] (master...2020-fuzzing-siphash) https://github.com/bitcoin/bitcoin/pull/19920
6972020-09-08T21:29:37 *** bitcoin-git has left #bitcoin-core-dev
6982020-09-08T21:35:23 *** yanmaani has quit IRC
6992020-09-08T21:37:49 *** yanmaani has joined #bitcoin-core-dev
7002020-09-08T21:39:07 *** davterra has quit IRC
7012020-09-08T21:39:08 *** yanmaani has quit IRC
7022020-09-08T21:39:32 *** davterra has joined #bitcoin-core-dev
7032020-09-08T21:39:50 *** yanmaani has joined #bitcoin-core-dev
7042020-09-08T21:45:18 *** morcos has quit IRC
7052020-09-08T21:45:34 *** morcos has joined #bitcoin-core-dev
7062020-09-08T21:57:05 *** andreacab has joined #bitcoin-core-dev
7072020-09-08T22:00:23 *** davterra has quit IRC
7082020-09-08T22:01:51 *** andreacab has quit IRC
7092020-09-08T22:11:07 *** promag_ has joined #bitcoin-core-dev
7102020-09-08T22:26:25 *** palazzovincenzo has quit IRC
7112020-09-08T22:38:55 *** justanotheruser has quit IRC
7122020-09-08T22:47:53 *** lightlike has quit IRC
7132020-09-08T22:54:04 *** proofofkeags has quit IRC
7142020-09-08T22:59:03 *** vasild has quit IRC
7152020-09-08T23:01:16 *** vasild has joined #bitcoin-core-dev
7162020-09-08T23:02:30 *** proofofkeags has joined #bitcoin-core-dev
7172020-09-08T23:04:07 *** bitcoin-git has joined #bitcoin-core-dev
7182020-09-08T23:04:07 <bitcoin-git> [bitcoin] dr-orlovsky closed pull request #19907: util: add psbt combiner role (master...feat/psbt-combiner) https://github.com/bitcoin/bitcoin/pull/19907
7192020-09-08T23:04:19 *** bitcoin-git has left #bitcoin-core-dev
7202020-09-08T23:08:32 *** marcoagner has quit IRC
7212020-09-08T23:09:03 *** Highway61 has quit IRC
7222020-09-08T23:10:40 *** justanotheruser has joined #bitcoin-core-dev
7232020-09-08T23:23:01 *** davterra has joined #bitcoin-core-dev
7242020-09-08T23:29:03 *** tryphe_ has joined #bitcoin-core-dev
7252020-09-08T23:32:15 *** tryphe has quit IRC
7262020-09-08T23:56:05 *** arowser has quit IRC
7272020-09-08T23:56:25 *** arowser has joined #bitcoin-core-dev
7282020-09-08T23:59:33 *** AaronvanW has quit IRC