{
  "founder": "jnewbery",
  "channel": "#bitcoin-core-dev",
  "network": "freenode",
  "id": "c588f45156344c919512735fcf238aa3",
  "name": "#bitcoin-core-dev",
  "chair": "jnewbery",
  "chairs": [
    "jnewbery"
  ],
  "nicks": {
    "jnewbery": 34,
    "lightningbot": 2,
    "sdaftuar": 54,
    "hebasto": 3,
    "gleb": 52,
    "ariard": 29,
    "ajonas": 1,
    "jonasschnelli": 1,
    "fanquake": 1,
    "gribble": 12,
    "amiti": 7,
    "sipa": 44,
    "aj": 12,
    "jonatack": 6,
    "bitcoin-git": 1,
    "lightlike": 1
  },
  "start_time": "2020-09-08T15:00:18+00:00",
  "end_time": "2020-09-08T15:59:59+00:00",
  "active": false,
  "original_topic": "Bitcoin Core development discussion and commit log | This is the channel for developing Bitcoin Core. Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a",
  "current_topic": "netgroup diversity of outbound peers (gleb)",
  "messages": [
    {
      "id": "376a438765564503a3d5798395c77228",
      "sender": "jnewbery",
      "payload": "#startmeeting",
      "action": false,
      "timestamp": "2020-09-08T15:00:18+00:00"
    },
    {
      "id": "86d62efb8a8a4ca0a0231b7411aa9c38",
      "sender": "lightningbot",
      "payload": "Meeting started Tue Sep  8 15:00:18 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.",
      "action": false,
      "timestamp": "2020-09-08T15:00:18+00:00"
    },
    {
      "id": "18f90bba31d3433380dbf1fff15be6f0",
      "sender": "lightningbot",
      "payload": "Useful Commands: #action #agreed #help #info #idea #link #topic.",
      "action": false,
      "timestamp": "2020-09-08T15:00:18+00:00"
    },
    {
      "id": "7d4b4aa809144bf0af593074f2533597",
      "sender": "sdaftuar",
      "payload": "hello",
      "action": false,
      "timestamp": "2020-09-08T15:00:29+00:00"
    },
    {
      "id": "54a0d6ba3ada4a4db9bd9166c60ed256",
      "sender": "hebasto",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:00:31+00:00"
    },
    {
      "id": "56897627e2244f6bbc67c1b1776d8d8c",
      "sender": "gleb",
      "payload": "hi!",
      "action": false,
      "timestamp": "2020-09-08T15:00:34+00:00"
    },
    {
      "id": "22c7f56e449c4532988f8267adb67118",
      "sender": "jnewbery",
      "payload": "#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",
      "action": false,
      "timestamp": "2020-09-08T15:00:35+00:00"
    },
    {
      "id": "6956d7e3c51b4e9caea2107d13929b8a",
      "sender": "ariard",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:00:36+00:00"
    },
    {
      "id": "0c423d47228a4b209ea58864e719ea15",
      "sender": "jnewbery",
      "payload": "amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2",
      "action": false,
      "timestamp": "2020-09-08T15:00:42+00:00"
    },
    {
      "id": "eef25f3cc5f34371b571bc1927f621cb",
      "sender": "jnewbery",
      "payload": "hi folks",
      "action": false,
      "timestamp": "2020-09-08T15:00:48+00:00"
    },
    {
      "id": "3fc61987d53b4763868bf94be3b126b1",
      "sender": "ajonas",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:00:57+00:00"
    },
    {
      "id": "7ef051c13756442090d25b8b3b1a70a9",
      "sender": "sdaftuar",
      "payload": "topic suggestion: gleb's PR on netgroup diversity of outbound peers",
      "action": false,
      "timestamp": "2020-09-08T15:00:57+00:00"
    },
    {
      "id": "03784e5d0de442f0996c8fb1e43f9546",
      "sender": "gleb",
      "payload": "sure :)",
      "action": false,
      "timestamp": "2020-09-08T15:01:22+00:00"
    },
    {
      "id": "c7d5d09a514d4c5eb10343f9ccf0eb9c",
      "sender": "jonasschnelli",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:01:39+00:00"
    },
    {
      "id": "272f25e9c51b473282fc1088d8c42ca2",
      "sender": "fanquake",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:01:44+00:00"
    },
    {
      "id": "b15f489b139e426ba8948da595b7bb26",
      "sender": "jnewbery",
      "payload": "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)",
      "action": false,
      "timestamp": "2020-09-08T15:02:04+00:00"
    },
    {
      "id": "c68052579bf341abb6d8a9c7050b7cf3",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals \u00c3\u0082\u00c2\u00b7 Issue #19820 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:02:05+00:00"
    },
    {
      "id": "f7ed56ce32714bc2b69cb29230959ec8",
      "sender": "amiti",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:02:10+00:00"
    },
    {
      "id": "efd7693018ad47ddb3142ab4690d2dcd",
      "sender": "ariard",
      "payload": "we can start by gleb's one np",
      "action": false,
      "timestamp": "2020-09-08T15:02:35+00:00"
    },
    {
      "id": "eda789fa534f40a4b630c07b560e2fd0",
      "sender": "jnewbery",
      "payload": "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/",
      "action": false,
      "timestamp": "2020-09-08T15:02:51+00:00"
    },
    {
      "id": "8d85e7c3d34b416fabab66c110319500",
      "sender": "gleb",
      "payload": "Over the last 10 days I opened 4 addr-related prs\u00c3\u00a2\u00c2\u0080\u00c2\u00a6 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\u00c3\u00a2\u00c2\u0080\u00c2\u0099m willing to provide any help to facilitate that review :)",
      "action": false,
      "timestamp": "2020-09-08T15:03:01+00:00"
    },
    {
      "id": "d17d7ef0a851403cb812823f2aa2e115",
      "sender": "sipa",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:03:08+00:00"
    },
    {
      "id": "9d8f57e527924264a71cc43ade53155d",
      "sender": "aj",
      "payload": "oh, sdaftuar said something other than hi!",
      "action": false,
      "timestamp": "2020-09-08T15:03:35+00:00"
    },
    {
      "id": "a49b94d0cc1348c5812c99e5b4595d84",
      "sender": "aj",
      "payload": "holla",
      "action": false,
      "timestamp": "2020-09-08T15:03:40+00:00"
    },
    {
      "id": "43f0b99836754cd09e12a7ba12261855",
      "sender": "gleb",
      "payload": "Some of them is refactoring, other have important implications and fix bugs",
      "action": false,
      "timestamp": "2020-09-08T15:03:41+00:00"
    },
    {
      "id": "7a09498d96ae453791ae3d592034b464",
      "sender": "jonatack",
      "payload": "hi",
      "action": false,
      "timestamp": "2020-09-08T15:03:43+00:00"
    },
    {
      "id": "383dce094105474c8c0860ebe88d4509",
      "sender": "sdaftuar",
      "payload": "aj: hi",
      "action": false,
      "timestamp": "2020-09-08T15:03:51+00:00"
    },
    {
      "id": "961aaf38de0b4aafb621c1384cb79a14",
      "sender": "aj",
      "payload": "sdaftuar: nack",
      "action": false,
      "timestamp": "2020-09-08T15:04:02+00:00"
    },
    {
      "id": "672d1dc0497e431c84bb9efee47ddb75",
      "sender": "jnewbery",
      "payload": "ok, well if no-one else has any general updates, I'll just share one of mine, then we can go onto proposed topics?",
      "action": false,
      "timestamp": "2020-09-08T15:04:30+00:00"
    },
    {
      "id": "52da11405033480f9d8337858c3ad3ab",
      "sender": "sdaftuar",
      "payload": "jnewbery: ack",
      "action": false,
      "timestamp": "2020-09-08T15:04:39+00:00"
    },
    {
      "id": "6e10dfa8878a4b988f1a41ce6f93d852",
      "sender": "ariard",
      "payload": "yes",
      "action": false,
      "timestamp": "2020-09-08T15:04:54+00:00"
    },
    {
      "id": "d115f9acaab246c2b3ca0df3d773fe3e",
      "sender": "jnewbery",
      "payload": "I'd still encourage review of the remaining backport #19606",
      "action": false,
      "timestamp": "2020-09-08T15:04:58+00:00"
    },
    {
      "id": "ca27e55d0b3f4516a7907ccd4fd937ec",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery \u00c3\u0082\u00c2\u00b7 Pull Request #19606 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:05:01+00:00"
    },
    {
      "id": "69557755ebe646f19767d21f7e9b6de0",
      "sender": "jnewbery",
      "payload": "there was some confusion about Marco's comment a few weeks ago about merge order. Is MarcoFalke here?",
      "action": false,
      "timestamp": "2020-09-08T15:05:34+00:00"
    },
    {
      "id": "4f948b89cc5b4cc788dee08978ad218e",
      "sender": "jnewbery",
      "payload": "Either way, I'd encourage review. It's not a totally clean backport, but it shouldn't be impossible to review",
      "action": false,
      "timestamp": "2020-09-08T15:06:13+00:00"
    },
    {
      "id": "975b22e7ebeb4644ada4150b2cf980fd",
      "sender": "jonatack",
      "payload": "quick reminder to review the bip155 and bip324 implementation PRs",
      "action": false,
      "timestamp": "2020-09-08T15:06:19+00:00"
    },
    {
      "id": "f1b10d6c5e2b48c0bfb55cc35446472e",
      "sender": "jnewbery",
      "payload": "#topic netgroup diversity of outbound peers (gleb)",
      "action": false,
      "timestamp": "2020-09-08T15:06:41+00:00"
    },
    {
      "id": "ad435733b86d4b86af78a8808a2db8fb",
      "sender": "gleb",
      "payload": "#19860",
      "action": false,
      "timestamp": "2020-09-08T15:06:48+00:00"
    },
    {
      "id": "b392d54b28ee4324806039b6e6d38fb0",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19860 | Improve diversification of new connections: privacy and stability by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #19860 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:06:49+00:00"
    },
    {
      "id": "67dd8dde09dd4228937c8b77cb5cb2c5",
      "sender": "sdaftuar",
      "payload": "i suggested that topic because some of the changes are non-obvious to me, and thought discussion would help",
      "action": false,
      "timestamp": "2020-09-08T15:07:17+00:00"
    },
    {
      "id": "441fede5666345c0af5b3aa30041eca5",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:07:46+00:00"
    },
    {
      "id": "507aafc1303141d5994db3e09511c316",
      "sender": "gleb",
      "payload": "I guess there is one nuance that is not obvious.",
      "action": false,
      "timestamp": "2020-09-08T15:07:53+00:00"
    },
    {
      "id": "42c803a2a7ad4f7f9550ded6efd3edf4",
      "sender": "gleb",
      "payload": "I suggested to not look at the *existent* block-relay-only conns (2 conns we have) while making *new* full relay conns.",
      "action": false,
      "timestamp": "2020-09-08T15:08:30+00:00"
    },
    {
      "id": "86dd0727f27a45abb54c4c704e8a3223",
      "sender": "gleb",
      "payload": "Because block-relay-conns should be more private (we rely on them for anti-eclipse).",
      "action": false,
      "timestamp": "2020-09-08T15:08:55+00:00"
    },
    {
      "id": "22e9d1af45fd411ca45f6bdedaf65278",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:09:36+00:00"
    },
    {
      "id": "e0cda01397d3496ea5b87eebb8048c5a",
      "sender": "gleb",
      "payload": "The disadvantage of this change is that we will have a little less diversity as a whole",
      "action": false,
      "timestamp": "2020-09-08T15:10:10+00:00"
    },
    {
      "id": "57695ad661984db3b268bc95f603553f",
      "sender": "gleb",
      "payload": "(new full-relay conns may be in same net group with existent block relay only conns)",
      "action": false,
      "timestamp": "2020-09-08T15:10:24+00:00"
    },
    {
      "id": "833d98d4236745a188eca3949f7da63b",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:10:49+00:00"
    },
    {
      "id": "d81d4fd9135442ee95155b983ebb715f",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:10:51+00:00"
    },
    {
      "id": "2d417fbc9ab147b1877d0befd854244d",
      "sender": "amiti",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:10:58+00:00"
    },
    {
      "id": "3607875831e743ab9c17bf21bdd7ba1f",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:11:39+00:00"
    },
    {
      "id": "aa8147dadd0043a2b999b64345b81c94",
      "sender": "ariard",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:12:16+00:00"
    },
    {
      "id": "b07cb5982cac476589a417d4a4ebfd0e",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:12:57+00:00"
    },
    {
      "id": "a890cf21fd504280ae918e31366215e9",
      "sender": "amiti",
      "payload": "whats the worst attack that could be carried out if an adversary knows the netgroups of the conns?",
      "action": false,
      "timestamp": "2020-09-08T15:13:11+00:00"
    },
    {
      "id": "caea56ac69cd4ec0976215b54b4408fa",
      "sender": "gleb",
      "payload": "And if we have more than two in the future, we can make 2 of them private, and N-2 of them overlappable.",
      "action": false,
      "timestamp": "2020-09-08T15:13:15+00:00"
    },
    {
      "id": "a25fc7d6f4134d60a052738bc204a9ac",
      "sender": "jnewbery",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:13:28+00:00"
    },
    {
      "id": "30f46318eb7d4a6f9daba56c800cea50",
      "sender": "gleb",
      "payload": "amiti: they can further deduce what are those peers in the network, and evict us from them.",
      "action": false,
      "timestamp": "2020-09-08T15:13:46+00:00"
    },
    {
      "id": "ae3212b54ba94d429d9ebcb3467e53bc",
      "sender": "amiti",
      "payload": "gleb: how?",
      "action": false,
      "timestamp": "2020-09-08T15:13:56+00:00"
    },
    {
      "id": "3feed8f301bf49dcb1a4bfe2e176af82",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:14:06+00:00"
    },
    {
      "id": "7cbf81823933438884596048e5279d84",
      "sender": "gleb",
      "payload": "jnewbery: Yes, I think it's fair. sdaftuar?",
      "action": false,
      "timestamp": "2020-09-08T15:14:07+00:00"
    },
    {
      "id": "c282381109294bc788160ef5554eef98",
      "sender": "sdaftuar",
      "payload": "gleb: we do have keyed network groups, so i am curious what you have in mind there?",
      "action": false,
      "timestamp": "2020-09-08T15:14:17+00:00"
    },
    {
      "id": "394df58fc2f84b47aac5a736a985cc09",
      "sender": "sdaftuar",
      "payload": "jnewbery: yes, i think that's likely true",
      "action": false,
      "timestamp": "2020-09-08T15:14:51+00:00"
    },
    {
      "id": "72894c184c864aa7b95b755b53103207",
      "sender": "amiti",
      "payload": "ariard: thanks!",
      "action": false,
      "timestamp": "2020-09-08T15:14:59+00:00"
    },
    {
      "id": "305bb6de305c458b92353e317d98d1df",
      "sender": "sdaftuar",
      "payload": "ariard: the goal of the connections is twofold:",
      "action": false,
      "timestamp": "2020-09-08T15:15:02+00:00"
    },
    {
      "id": "0be40fae15934e4aa176f9af8488feff",
      "sender": "sdaftuar",
      "payload": "- 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",
      "action": false,
      "timestamp": "2020-09-08T15:15:30+00:00"
    },
    {
      "id": "9e4fdf6e657a487980c3c9c37aaaf9ea",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:16:09+00:00"
    },
    {
      "id": "14b777d847a04ec18dab4ee3ecab6666",
      "sender": "jnewbery",
      "payload": "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\"",
      "action": false,
      "timestamp": "2020-09-08T15:16:27+00:00"
    },
    {
      "id": "e921f9d4eab6435ea9bf493bb2dfe4d7",
      "sender": "sdaftuar",
      "payload": "- 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",
      "action": false,
      "timestamp": "2020-09-08T15:16:51+00:00"
    },
    {
      "id": "5604a845498b4485978be0dd96152c1d",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:17:06+00:00"
    },
    {
      "id": "c6dfca50680a476bbf163900ff9c1c9a",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:17:46+00:00"
    },
    {
      "id": "b9d8ae915a404c6ab1c07ae7daa91f76",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:18:27+00:00"
    },
    {
      "id": "193ce3ffe48548cd942f7b1f155f2974",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:18:40+00:00"
    },
    {
      "id": "5364bb29db9d4c3db5a80c7d32a83bee",
      "sender": "sipa",
      "payload": "sdaftuar: i think you're missing one point: block-only connections increase partition resistance without the bandwidth overhead that full connections have",
      "action": false,
      "timestamp": "2020-09-08T15:18:42+00:00"
    },
    {
      "id": "2ec952d312a743d7bcb9af58adf644bc",
      "sender": "sdaftuar",
      "payload": "sipa: yes, thank you",
      "action": false,
      "timestamp": "2020-09-08T15:18:51+00:00"
    },
    {
      "id": "c5bbf85c583a430d88f8aac02f9bf23a",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:18:57+00:00"
    },
    {
      "id": "e367c40626084728b743782e4ff5c009",
      "sender": "sipa",
      "payload": "gleb: how can they force us to connect somewhere?",
      "action": false,
      "timestamp": "2020-09-08T15:19:20+00:00"
    },
    {
      "id": "12131a6c7c364482939fcf9b3331fdbd",
      "sender": "gleb",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:20:01+00:00"
    },
    {
      "id": "d34dc2c2529147dea30ad96e3e2d9253",
      "sender": "jnewbery",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:20:25+00:00"
    },
    {
      "id": "4b7fdbafefc742b98b8903ac6d39b8f6",
      "sender": "sipa",
      "payload": "gleb: that sounds like they've already succesfully pattitioned us?",
      "action": false,
      "timestamp": "2020-09-08T15:20:41+00:00"
    },
    {
      "id": "7df3777117c842bfa810200c53898d79",
      "sender": "gleb",
      "payload": "I assume a scenario when we lost all our full relay slots, but still have 2 block-relay-only slots.",
      "action": false,
      "timestamp": "2020-09-08T15:20:52+00:00"
    },
    {
      "id": "494c5f7de3e74cf4b7bc5053a403a9a1",
      "sender": "sipa",
      "payload": "or are trivially able to do so as well",
      "action": false,
      "timestamp": "2020-09-08T15:20:57+00:00"
    },
    {
      "id": "a2193330966f4169bb37681b3eead795",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:21:05+00:00"
    },
    {
      "id": "61de0452c8a94ac4bc7e830d218c808f",
      "sender": "gleb",
      "payload": "b-r-o slots don't answer addr queries i believe, so they won't help to sanitize our addr man",
      "action": false,
      "timestamp": "2020-09-08T15:21:10+00:00"
    },
    {
      "id": "c3205228d9d1462eb247bf4c211b117d",
      "sender": "sdaftuar",
      "payload": "correct, or rather we ignore addr messages from our block-relay peers",
      "action": false,
      "timestamp": "2020-09-08T15:21:28+00:00"
    },
    {
      "id": "53d02d249d414d819fddcbb95939748f",
      "sender": "aj",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:21:36+00:00"
    },
    {
      "id": "4e0a92411109409ea9f1373dbedc22bb",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:21:56+00:00"
    },
    {
      "id": "c40f891e058f4173abdd3d7510f05a6c",
      "sender": "sdaftuar",
      "payload": "aj: isn't more diversity still better?",
      "action": false,
      "timestamp": "2020-09-08T15:21:59+00:00"
    },
    {
      "id": "06f2c3269f7c40a3b138ef0b4293fc60",
      "sender": "jonatack",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:22:19+00:00"
    },
    {
      "id": "71b2db3c3e6349fb854520b8ab40da1f",
      "sender": "sipa",
      "payload": "my thinking (but i haven't thought/looked too much) is that you want to maximize diversity of (full+blockonly), and of (full) alone",
      "action": false,
      "timestamp": "2020-09-08T15:22:53+00:00"
    },
    {
      "id": "ac22edf97ee24485a95d6c253dab0096",
      "sender": "sdaftuar",
      "payload": "sipa: that lines up with my intuition as well",
      "action": false,
      "timestamp": "2020-09-08T15:23:08+00:00"
    },
    {
      "id": "0bee8eacbd3f4f918e5bc1ab5b914869",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:23:16+00:00"
    },
    {
      "id": "8f3ca8a042ed46919c587a05f687dcb4",
      "sender": "ariard",
      "payload": "*this",
      "action": false,
      "timestamp": "2020-09-08T15:23:20+00:00"
    },
    {
      "id": "64ccf5f1ed04443d93dfa9a24c4b5722",
      "sender": "sipa",
      "payload": "the former for partition resistance, the second for actual short-term efficient connectivity",
      "action": false,
      "timestamp": "2020-09-08T15:23:41+00:00"
    },
    {
      "id": "d3afd3ed4fb543879f0da07ed4e4a4d4",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:24:07+00:00"
    },
    {
      "id": "fd65dca93ac348fcb2386ff171bc9693",
      "sender": "aj",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:24:23+00:00"
    },
    {
      "id": "45d145a178dd468485c3ef325ac873a1",
      "sender": "gleb",
      "payload": "And block-relay-only will be diverse w.r.t existent full-relay conns. Just not vice versa :)",
      "action": false,
      "timestamp": "2020-09-08T15:24:36+00:00"
    },
    {
      "id": "ad27514e94624ffc954e14a4afef25ce",
      "sender": "aj",
      "payload": "sdaftuar: (2 peers not being sufficiently diverse, 6-10 maybe being sufficiently diverse)",
      "action": false,
      "timestamp": "2020-09-08T15:24:43+00:00"
    },
    {
      "id": "b9b48fcf6416491485db3eaec2db49ad",
      "sender": "jnewbery",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:24:54+00:00"
    },
    {
      "id": "dbfbd09ed1974962bdbfa43cac2d3718",
      "sender": "sdaftuar",
      "payload": "gleb: that part of the logic is strange to me, because the peering logic is not symmetric depending on what order you connect in?",
      "action": false,
      "timestamp": "2020-09-08T15:25:01+00:00"
    },
    {
      "id": "a6860152542e43c9b1700f38cce7aae5",
      "sender": "sipa",
      "payload": "jnewbery: hmm, i see the appeal for that too",
      "action": false,
      "timestamp": "2020-09-08T15:25:39+00:00"
    },
    {
      "id": "06e9bbc00a1146fdb483d4a12d34fd4e",
      "sender": "gleb",
      "payload": "sdaftuar: I don't see symmetry as a good goal :)",
      "action": false,
      "timestamp": "2020-09-08T15:25:41+00:00"
    },
    {
      "id": "25454d36aa5040e8a81ae72fb91c617f",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:26:37+00:00"
    },
    {
      "id": "d67446303cef4d72acc31fbdb7805d67",
      "sender": "gleb",
      "payload": "Maybe we should keep this until more block-relay-only, and then make part of them private and part of them diverse?",
      "action": false,
      "timestamp": "2020-09-08T15:26:39+00:00"
    },
    {
      "id": "adc63bc999ac44819c22a18c6fd80fc9",
      "sender": "amiti",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:27:18+00:00"
    },
    {
      "id": "a800279a290147bb97d37fd1174f4d1c",
      "sender": "sdaftuar",
      "payload": "it does seem like we're a long way from truly separating connection types, as long as addrman is firmly in the middle here",
      "action": false,
      "timestamp": "2020-09-08T15:27:24+00:00"
    },
    {
      "id": "a27d2f913e504b5ba64a8e8e72dfadfe",
      "sender": "sipa",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:27:25+00:00"
    },
    {
      "id": "946ec65f8ea445e2a0f0c1949e19ca3d",
      "sender": "ariard",
      "payload": "sdaftuar: non-observability of victim's connections likely minimizes the likelihood of being partitioned",
      "action": false,
      "timestamp": "2020-09-08T15:27:55+00:00"
    },
    {
      "id": "f63e82838b874ba1acd80c378776dbff",
      "sender": "gleb",
      "payload": "sipa: this is my exact suggestion btw.",
      "action": false,
      "timestamp": "2020-09-08T15:28:14+00:00"
    },
    {
      "id": "9e2708ff272c4dffacb71fad7e976a45",
      "sender": "sipa",
      "payload": "amiti: i'm not there is a concrete attack beyond \"8 connections is easier to partition than 10\"",
      "action": false,
      "timestamp": "2020-09-08T15:28:19+00:00"
    },
    {
      "id": "d55222547e764fc4b82038147809bee0",
      "sender": "sdaftuar",
      "payload": "sipa: i was going to point out that achieving maximum diversity for blocksonly+full is sufficient to achieve maximum diversity for full alone",
      "action": false,
      "timestamp": "2020-09-08T15:28:25+00:00"
    },
    {
      "id": "cf55060c0d70457d86538b2e4824fd2e",
      "sender": "sipa",
      "payload": "sdaftuar: hmm!",
      "action": false,
      "timestamp": "2020-09-08T15:28:53+00:00"
    },
    {
      "id": "fd2cb60ed85e4e81bc22806289117fd6",
      "sender": "sipa",
      "payload": "of course",
      "action": false,
      "timestamp": "2020-09-08T15:29:04+00:00"
    },
    {
      "id": "732f3b5ed068423596607790aae67314",
      "sender": "jnewbery",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:30:04+00:00"
    },
    {
      "id": "713c0e801b364fd892a72e8591ab64f8",
      "sender": "sdaftuar",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:30:34+00:00"
    },
    {
      "id": "5821b147fd0b4a6a84a9ee05b27c4c96",
      "sender": "gleb",
      "payload": "jnewbery: yeah, I think so. Because there are probably better ways to learn full conns anyway",
      "action": false,
      "timestamp": "2020-09-08T15:30:45+00:00"
    },
    {
      "id": "113f9cbf1ba84ca3b36b1ce84c9e5ced",
      "sender": "gleb",
      "payload": "sdaftuar: do you accept the setting where we lost all our full conns, but 2 block-relay-only are still healthy?",
      "action": false,
      "timestamp": "2020-09-08T15:31:14+00:00"
    },
    {
      "id": "a2e07535a39e412ba496c753aeb331ab",
      "sender": "gleb",
      "payload": "or you think it's unrealistic",
      "action": false,
      "timestamp": "2020-09-08T15:31:25+00:00"
    },
    {
      "id": "5559b79105b64b82bdab662dbf84ae6d",
      "sender": "sdaftuar",
      "payload": "if our addrman starts off healthy, then i think we're probably ok in that scenario",
      "action": false,
      "timestamp": "2020-09-08T15:31:40+00:00"
    },
    {
      "id": "ee5e82e0b56142a4964fb5659fb9f51a",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:32:00+00:00"
    },
    {
      "id": "d2e2d4464e1146e9814b45079d0c7367",
      "sender": "sdaftuar",
      "payload": "(i think we're ok because of feelers, maybe that's wrong)",
      "action": false,
      "timestamp": "2020-09-08T15:32:17+00:00"
    },
    {
      "id": "38e414c0b1764882ac1af8758c153ed5",
      "sender": "gleb",
      "payload": "i see.",
      "action": false,
      "timestamp": "2020-09-08T15:32:55+00:00"
    },
    {
      "id": "2ff5585f29a143c2997bedf18965f11f",
      "sender": "sipa",
      "payload": "i have a hard time imagining how that's not a problem",
      "action": false,
      "timestamp": "2020-09-08T15:32:57+00:00"
    },
    {
      "id": "9fae8d11a5b046598115989d687b8c4f",
      "sender": "ariard",
      "payload": "gleb: when you assume addrman poisoning, do you scope knocking-out the feeler logic by an attacker?",
      "action": false,
      "timestamp": "2020-09-08T15:33:10+00:00"
    },
    {
      "id": "343571b2b66646f69030a34059340619",
      "sender": "jnewbery",
      "payload": "does anchor connections make gleb's scenario more likely?",
      "action": false,
      "timestamp": "2020-09-08T15:33:26+00:00"
    },
    {
      "id": "c30cf3e1601b48b19e7fdd287be53639",
      "sender": "sdaftuar",
      "payload": "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?",
      "action": false,
      "timestamp": "2020-09-08T15:33:41+00:00"
    },
    {
      "id": "8017422f3e1b4dc39298099deaa46144",
      "sender": "sipa",
      "payload": "because with all normal connections sybilled, the attacker can probably start poisoning addrman, and leave you no way to recover",
      "action": false,
      "timestamp": "2020-09-08T15:33:43+00:00"
    },
    {
      "id": "b0be04c3bc14475aa748681b06694c80",
      "sender": "amiti",
      "payload": "jnewbery: was wondering that. I think so",
      "action": false,
      "timestamp": "2020-09-08T15:33:54+00:00"
    },
    {
      "id": "3a3672fdbf7c40baaedb9af1ee193a83",
      "sender": "ariard",
      "payload": "jnewbery: I think it makes it easier to observe them as block-relay-o become more stable?",
      "action": false,
      "timestamp": "2020-09-08T15:33:57+00:00"
    },
    {
      "id": "43a316acf830404c93b15e19d865170e",
      "sender": "jnewbery",
      "payload": "(#17428)",
      "action": false,
      "timestamp": "2020-09-08T15:34:00+00:00"
    },
    {
      "id": "c25926c3bb4545f6ba4d3e6d55856987",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto \u00c3\u0082\u00c2\u00b7 Pull Request #17428 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:34:04+00:00"
    },
    {
      "id": "d4668acdff8c41f1880d3f96ece04bc6",
      "sender": "sdaftuar",
      "payload": "sipa: does this problem get solved if we introduce some level of rotation of tx-relay peers?",
      "action": false,
      "timestamp": "2020-09-08T15:34:29+00:00"
    },
    {
      "id": "a2c1284b8ad549c38347959a87069aa5",
      "sender": "gleb",
      "payload": "Yeah I don't have big faith in feelers once we lost all our full conns",
      "action": false,
      "timestamp": "2020-09-08T15:34:40+00:00"
    },
    {
      "id": "179c332d10a446b982e1a2e28b6e53f7",
      "sender": "gleb",
      "payload": "We don't even send GETADDR to feelers iirc?",
      "action": false,
      "timestamp": "2020-09-08T15:34:54+00:00"
    },
    {
      "id": "0c99435916b544cc8689e614943685f0",
      "sender": "sdaftuar",
      "payload": "sorry, i don't mean feelers",
      "action": false,
      "timestamp": "2020-09-08T15:35:00+00:00"
    },
    {
      "id": "f743a537f5894bd39e1d215eaa31d6a7",
      "sender": "sdaftuar",
      "payload": "what i mean is the tried-table-collision resolution algorithm",
      "action": false,
      "timestamp": "2020-09-08T15:35:07+00:00"
    },
    {
      "id": "c2954f494df44e35ab4e59165acda444",
      "sender": "sipa",
      "payload": "that's feelers, no?",
      "action": false,
      "timestamp": "2020-09-08T15:35:17+00:00"
    },
    {
      "id": "fd8c9ca1acb5445cac39a273aee25079",
      "sender": "gleb",
      "payload": "oh, that's interesting.",
      "action": false,
      "timestamp": "2020-09-08T15:35:26+00:00"
    },
    {
      "id": "3cea7f18b1f541c4b538b7cb363bf19e",
      "sender": "ariard",
      "payload": "that's done by feelers connection",
      "action": false,
      "timestamp": "2020-09-08T15:35:28+00:00"
    },
    {
      "id": "a072ca7a22e44853af1f4c3fcb6d394a",
      "sender": "sdaftuar",
      "payload": "no, feelers are for connecting to NEW table entries and trying to mive them to tried",
      "action": false,
      "timestamp": "2020-09-08T15:35:29+00:00"
    },
    {
      "id": "2c3be678cc7740c29ec1a7f6cf5d3b04",
      "sender": "gleb",
      "payload": "Not sure how that thing is effective.",
      "action": false,
      "timestamp": "2020-09-08T15:35:32+00:00"
    },
    {
      "id": "d6e5eba003144b589161d11e56e8d93d",
      "sender": "sdaftuar",
      "payload": "yes, we call them feelers too",
      "action": false,
      "timestamp": "2020-09-08T15:35:34+00:00"
    },
    {
      "id": "6bb8ce4eaba7494b9823188d0e7a2a56",
      "sender": "sdaftuar",
      "payload": "but it's confusing",
      "action": false,
      "timestamp": "2020-09-08T15:35:36+00:00"
    },
    {
      "id": "df63811a7cba4a62a91ae927804310ab",
      "sender": "sipa",
      "payload": "mive?",
      "action": false,
      "timestamp": "2020-09-08T15:35:50+00:00"
    },
    {
      "id": "fc3b142e7223480eaee1dabe2f3059bd",
      "sender": "sdaftuar",
      "payload": "move*",
      "action": false,
      "timestamp": "2020-09-08T15:35:54+00:00"
    },
    {
      "id": "997471d24cb64ee29e080579cc8f4f40",
      "sender": "jnewbery",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:35:56+00:00"
    },
    {
      "id": "ac8e8fcc8a7c48b49c3bb40e9b7833ad",
      "sender": "sipa",
      "payload": "ah, move",
      "action": false,
      "timestamp": "2020-09-08T15:35:56+00:00"
    },
    {
      "id": "9ddf370eb9ad497aa97c9e10096daf1d",
      "sender": "sipa",
      "payload": "thinking ahout this, i wonder if we need addr-only connections too",
      "action": false,
      "timestamp": "2020-09-08T15:36:44+00:00"
    },
    {
      "id": "b8389adc752e49c8b4081b7bc05ac6f3",
      "sender": "gleb",
      "payload": "The worst diversity degradation here btw: 2 newly selected full peers are from the same netgroup as 2 existent block-relay-only conns",
      "action": false,
      "timestamp": "2020-09-08T15:36:56+00:00"
    },
    {
      "id": "ed62f95c467d4e99bc101fd9fd20b3ab",
      "sender": "gleb",
      "payload": "sipa: working on that stuff.",
      "action": false,
      "timestamp": "2020-09-08T15:37:03+00:00"
    },
    {
      "id": "803828aaf382468c8b394a10fc52fcce",
      "sender": "sdaftuar",
      "payload": "sipa: yeah i was thinking about that a bit as well",
      "action": false,
      "timestamp": "2020-09-08T15:37:05+00:00"
    },
    {
      "id": "38d78634afaa4422be446ebcc9996922",
      "sender": "gleb",
      "payload": "it's blocked by my 4 addr-related prs :)",
      "action": false,
      "timestamp": "2020-09-08T15:37:15+00:00"
    },
    {
      "id": "9029b9e3dcff4be381afa2e6ca4d1b11",
      "sender": "sipa",
      "payload": "i'm not worried about information leakage of our selection of full/blockonly connections",
      "action": false,
      "timestamp": "2020-09-08T15:37:23+00:00"
    },
    {
      "id": "515e3334dc9240bd94335968ecf3e152",
      "sender": "sipa",
      "payload": "but our partitition resistance gained (assuming blockonly is diverse wrt full) is only for block connectivity",
      "action": false,
      "timestamp": "2020-09-08T15:37:49+00:00"
    },
    {
      "id": "47266d691a434849aa9cb8c356d28761",
      "sender": "sipa",
      "payload": "not for addrmam health",
      "action": false,
      "timestamp": "2020-09-08T15:37:53+00:00"
    },
    {
      "id": "75c17c8924dd4026ad88ced9508138b2",
      "sender": "sipa",
      "payload": "which is valuable, but shorter term",
      "action": false,
      "timestamp": "2020-09-08T15:38:04+00:00"
    },
    {
      "id": "987ffd95ccec4de5b356ab30d4924fc0",
      "sender": "aj",
      "payload": "sipa: maybe addr-only connections should mean occassionally requery dns-seeds too (once a day or once a week, poisson'ed eg) ?",
      "action": false,
      "timestamp": "2020-09-08T15:38:15+00:00"
    },
    {
      "id": "c33f200a14ea4805919178543b8acc9c",
      "sender": "sipa",
      "payload": "maybe",
      "action": false,
      "timestamp": "2020-09-08T15:38:31+00:00"
    },
    {
      "id": "05490635713942db9be3a27e203b23ed",
      "sender": "ariard",
      "payload": "sipa: you mean an attacker can't interfere with victim's blockonly connections if it learns their netgroups?",
      "action": false,
      "timestamp": "2020-09-08T15:38:37+00:00"
    },
    {
      "id": "13ef2d7adcb549b1a5761d5341bbe3a7",
      "sender": "sdaftuar",
      "payload": "aj: that leaks different information that people are concerend about i think?",
      "action": false,
      "timestamp": "2020-09-08T15:38:49+00:00"
    },
    {
      "id": "fe5693c5d3b54266b801a53cd3026ca2",
      "sender": "gleb",
      "payload": "aj: this is a follow-up for #18421",
      "action": false,
      "timestamp": "2020-09-08T15:38:56+00:00"
    },
    {
      "id": "d8a550cc5ef74e6ea321d5461c266732",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #18421 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:38:59+00:00"
    },
    {
      "id": "f7c8e5c12d8442a9a4002b0550230bd3",
      "sender": "gleb",
      "payload": "I gave up on periodic DNS queries for now :)",
      "action": false,
      "timestamp": "2020-09-08T15:39:07+00:00"
    },
    {
      "id": "a62498c42a7d49a2b804aeb13007f272",
      "sender": "sipa",
      "payload": "ariard: i think that if all connections that convey addr informarion are sybilled, it's game over for addrman sanity",
      "action": false,
      "timestamp": "2020-09-08T15:39:30+00:00"
    },
    {
      "id": "0d4b0dba83d34198b73e683a1c8128fa",
      "sender": "sipa",
      "payload": "ariard: and blocksonly connections cannot help with that",
      "action": false,
      "timestamp": "2020-09-08T15:39:41+00:00"
    },
    {
      "id": "8bae5bc5e9124e32b7d0d046cf759c04",
      "sender": "gleb",
      "payload": "sipa: but we're not eclipsed at least?",
      "action": false,
      "timestamp": "2020-09-08T15:39:55+00:00"
    },
    {
      "id": "174a5167aa6e4354bd1ffc9928023afd",
      "sender": "sdaftuar",
      "payload": "sipa: one alternate implementation idea i had for syncing our chain tip with more peers, was to couple that with addrman updates",
      "action": false,
      "timestamp": "2020-09-08T15:40:04+00:00"
    },
    {
      "id": "1cbb0170b92d426aa443a1eab3a962ee",
      "sender": "sipa",
      "payload": "gleb: not eclipsed wrt to block propagation",
      "action": false,
      "timestamp": "2020-09-08T15:40:13+00:00"
    },
    {
      "id": "588a4b812d074324b63cf18bba13f136",
      "sender": "gleb",
      "payload": "sipa: sure.",
      "action": false,
      "timestamp": "2020-09-08T15:40:42+00:00"
    },
    {
      "id": "6239abbcff874f589c2f67b776d89a21",
      "sender": "ariard",
      "payload": "sipa: you might still be okay for a while more until your current block-relay-only are stable, and this is already a gain",
      "action": false,
      "timestamp": "2020-09-08T15:40:43+00:00"
    },
    {
      "id": "30dcf334c8364ba9b12e536be2560a8b",
      "sender": "sipa",
      "payload": "gleb: but you are eclipsed wrt addr relay, which means addrman will (if the situation persists) become attacker controlled",
      "action": false,
      "timestamp": "2020-09-08T15:40:47+00:00"
    },
    {
      "id": "920213fd8eb9456ea86b4184161704cc",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:40:48+00:00"
    },
    {
      "id": "a48fd2e582cd43ff9bf41ae6aa664022",
      "sender": "sipa",
      "payload": "so i think this means we want full connections, blockonly connections, addronly connections... and diversity of (full+blockonly) and of (full+addronly) ?",
      "action": false,
      "timestamp": "2020-09-08T15:42:13+00:00"
    },
    {
      "id": "391192fe1a4f4dc784508ff4d287ba2e",
      "sender": "sdaftuar",
      "payload": "i think it would be helpful to run some simulations on that point",
      "action": false,
      "timestamp": "2020-09-08T15:42:13+00:00"
    },
    {
      "id": "224185caaa0746c3baee373f6658566c",
      "sender": "sipa",
      "payload": "or just diversity of everything, really",
      "action": false,
      "timestamp": "2020-09-08T15:42:44+00:00"
    },
    {
      "id": "ef0c3b661ac04a0baab25a4872d4bfa0",
      "sender": "ariard",
      "payload": "sdaftuar: if you take this info for future peers selections, you might favor even more performant peers, and tight network topology ?",
      "action": false,
      "timestamp": "2020-09-08T15:42:49+00:00"
    },
    {
      "id": "eea5e2b93c134bc4832aba1678580ab5",
      "sender": "sipa",
      "payload": "ariard: being more or less in sync isn't a very strong preference for.performamt peers",
      "action": false,
      "timestamp": "2020-09-08T15:43:27+00:00"
    },
    {
      "id": "9e29f747eaf74968bf2dd35941be1e50",
      "sender": "sipa",
      "payload": "just an aversion for broken ones",
      "action": false,
      "timestamp": "2020-09-08T15:43:40+00:00"
    },
    {
      "id": "c45199e3e82a415fbb34232f8e9abe46",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:44:03+00:00"
    },
    {
      "id": "ee5df666778f4d6e8bfc4ab0005abfe7",
      "sender": "ariard",
      "payload": "sipa: aren't low-grades peers really likely to be late on tip view ?",
      "action": false,
      "timestamp": "2020-09-08T15:44:13+00:00"
    },
    {
      "id": "f358b43b35fc410ebf46f8285ba1bee6",
      "sender": "bitcoin-git",
      "payload": "[bitcoin] ryanofsky opened pull request #19918: sync: Replace LockAssertion with WeaklyAssertLockHeld (master...pr/lockb) https://github.com/bitcoin/bitcoin/pull/19918",
      "action": false,
      "timestamp": "2020-09-08T15:44:15+00:00"
    },
    {
      "id": "97100a3d676445c0a4d086d10ecb961d",
      "sender": "sipa",
      "payload": "ariard: by a few seconds maybe",
      "action": false,
      "timestamp": "2020-09-08T15:44:41+00:00"
    },
    {
      "id": "9e36ee18b8e84ef281206e2d119d727c",
      "sender": "sdaftuar",
      "payload": "sipa: it seems a shame to not relay blocks on addronly links",
      "action": false,
      "timestamp": "2020-09-08T15:45:32+00:00"
    },
    {
      "id": "445045ff24854890a53dfe5e54eaa102",
      "sender": "sdaftuar",
      "payload": "(or at least headers)",
      "action": false,
      "timestamp": "2020-09-08T15:45:37+00:00"
    },
    {
      "id": "4735707cf2444b718ddcef279ea7da0b",
      "sender": "gleb",
      "payload": "sdaftuar: agree.",
      "action": false,
      "timestamp": "2020-09-08T15:45:47+00:00"
    },
    {
      "id": "cc67a75fa59b4e738fc56c8e702306c5",
      "sender": "jnewbery",
      "payload": "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)",
      "action": false,
      "timestamp": "2020-09-08T15:45:58+00:00"
    },
    {
      "id": "a8766a5868d8405e803037aedfc7aaaf",
      "sender": "sdaftuar",
      "payload": "jnewbery: we do that already, don't we?",
      "action": false,
      "timestamp": "2020-09-08T15:46:12+00:00"
    },
    {
      "id": "89ded6b21f4a4a738013ff4651026809",
      "sender": "sipa",
      "payload": "jnewbery: we do!",
      "action": false,
      "timestamp": "2020-09-08T15:46:19+00:00"
    },
    {
      "id": "f93ea7eac7e3420aa79722ca5acb6f6c",
      "sender": "jnewbery",
      "payload": "oh! Good!",
      "action": false,
      "timestamp": "2020-09-08T15:46:25+00:00"
    },
    {
      "id": "70011cdef9c149e7a1d0d7dd043c453d",
      "sender": "sipa",
      "payload": "there is an addrman key for that",
      "action": false,
      "timestamp": "2020-09-08T15:46:28+00:00"
    },
    {
      "id": "4f5e0a032e8c43559ba44ec8e8a4982c",
      "sender": "ariard",
      "payload": "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 ?",
      "action": false,
      "timestamp": "2020-09-08T15:46:33+00:00"
    },
    {
      "id": "4747f432add1478db1f00d5cccd0b450",
      "sender": "sdaftuar",
      "payload": "that's what i said before about keyed network groups",
      "action": false,
      "timestamp": "2020-09-08T15:46:33+00:00"
    },
    {
      "id": "cea11c158b924df3a4f7e3968984adb8",
      "sender": "jnewbery",
      "payload": "I should have reviewed the AS PRs",
      "action": false,
      "timestamp": "2020-09-08T15:46:35+00:00"
    },
    {
      "id": "375e4cd65cda4659a9b0924410e5396a",
      "sender": "jnewbery",
      "payload": "sdaftuar: got it. Thanks!",
      "action": false,
      "timestamp": "2020-09-08T15:46:48+00:00"
    },
    {
      "id": "951de2e4f3a14bf48b46a4ebc02cc48a",
      "sender": "sipa",
      "payload": "jnewbery: this was part of the original addrman :)",
      "action": false,
      "timestamp": "2020-09-08T15:46:58+00:00"
    },
    {
      "id": "de569c5d97df4a2191929efa623df11e",
      "sender": "gleb",
      "payload": "Yeah, this part makes it a bit less realistic.",
      "action": false,
      "timestamp": "2020-09-08T15:47:06+00:00"
    },
    {
      "id": "fc986324b2004fa48d8bc9e0c6c76f56",
      "sender": "jonatack",
      "payload": "question: how effective is -seednode/-addnode to trusted peers as an anti-eclipse tactic?",
      "action": false,
      "timestamp": "2020-09-08T15:47:17+00:00"
    },
    {
      "id": "f7f66cc24f9840f28e1c9e6d9bad1ab5",
      "sender": "jnewbery",
      "payload": "sipa: ah, ok. I guess I should just review more of the code in general then :)",
      "action": false,
      "timestamp": "2020-09-08T15:47:35+00:00"
    },
    {
      "id": "355d91ceb5a84616943a4f29ed12b03e",
      "sender": "sipa",
      "payload": "jonatack: assuming no network-level attacker, addnode is great for that",
      "action": false,
      "timestamp": "2020-09-08T15:47:43+00:00"
    },
    {
      "id": "53115824649e4175b86e17cc693689d4",
      "sender": "sdaftuar",
      "payload": "well, hopefully your trusted peer is also not eclipsed :)",
      "action": false,
      "timestamp": "2020-09-08T15:47:57+00:00"
    },
    {
      "id": "a3dc4a32434f4bc39cc985fa71b9137f",
      "sender": "ariard",
      "payload": "jonatack: really depends of the capabilites of your eclipse attacker",
      "action": false,
      "timestamp": "2020-09-08T15:48:20+00:00"
    },
    {
      "id": "fe35d0c7eff247679a1352da19c9f24d",
      "sender": "sipa",
      "payload": "i see no reason why you wouldn't also send blocks over addr links, agree",
      "action": false,
      "timestamp": "2020-09-08T15:48:43+00:00"
    },
    {
      "id": "c03b90f6743240c5b0afabc2ff579fed",
      "sender": "sdaftuar",
      "payload": "sipa: so perhaps we should have two kinds of block-relay links then",
      "action": false,
      "timestamp": "2020-09-08T15:48:58+00:00"
    },
    {
      "id": "8baa48c0610640128f2ea4f6970930ac",
      "sender": "jonatack",
      "payload": "thanks. i seem to recall matt tweeting about doing that a while back",
      "action": false,
      "timestamp": "2020-09-08T15:48:59+00:00"
    },
    {
      "id": "75ab315057ee48df867a11ae1c52c1a0",
      "sender": "gleb",
      "payload": "sdaftuar: I'm lost. Which kinds?",
      "action": false,
      "timestamp": "2020-09-08T15:49:21+00:00"
    },
    {
      "id": "9a49bed43cec48e3892042fecc766941",
      "sender": "sipa",
      "payload": "gleb: blocksonly and addrplusblocksonly",
      "action": false,
      "timestamp": "2020-09-08T15:49:51+00:00"
    },
    {
      "id": "948d65fc35c84991be794d5b4b87542f",
      "sender": "aj",
      "payload": "is the idea that addr-relay nodes are long-lived or short-lived (like feelers) ?",
      "action": false,
      "timestamp": "2020-09-08T15:50:01+00:00"
    },
    {
      "id": "a19cdedc77a841bb95d7aad1863229c1",
      "sender": "sipa",
      "payload": "long-lived, i'd say",
      "action": false,
      "timestamp": "2020-09-08T15:50:21+00:00"
    },
    {
      "id": "f6dbc202fcbe4d94be433144f9306426",
      "sender": "sdaftuar",
      "payload": "aj: i think they could be long lived?  they would be very low bandwidth",
      "action": false,
      "timestamp": "2020-09-08T15:50:25+00:00"
    },
    {
      "id": "6096397a1f384879b475ce25c3466aca",
      "sender": "gleb",
      "payload": "I have a branch with short-lived self-announcement addr links :)",
      "action": false,
      "timestamp": "2020-09-08T15:50:25+00:00"
    },
    {
      "id": "f86e94b3105c4672b10799384b3162d2",
      "sender": "ariard",
      "payload": "even if they're short-lived you want to do headers-sync on them",
      "action": false,
      "timestamp": "2020-09-08T15:50:35+00:00"
    },
    {
      "id": "85238e127b5a42bbbfc7237a3a96c37c",
      "sender": "gleb",
      "payload": "But that's different from what was discussed.",
      "action": false,
      "timestamp": "2020-09-08T15:50:40+00:00"
    },
    {
      "id": "c0a1ff3c764e478aad4821fe7809e155",
      "sender": "lightlike",
      "payload": "hi - we probably can't rely much on our addr-links staying private, or can we?",
      "action": false,
      "timestamp": "2020-09-08T15:51:22+00:00"
    },
    {
      "id": "cbe4f4a338094df8a896665a1fd2bff1",
      "sender": "aj",
      "payload": "so blocks-only is eclipse prevention, addr+blocks is low-bw extra diversity, tx-relay is tx relay?",
      "action": false,
      "timestamp": "2020-09-08T15:51:28+00:00"
    },
    {
      "id": "7a934677d1f744d7a422d70c7f51eaf9",
      "sender": "sdaftuar",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:51:39+00:00"
    },
    {
      "id": "6839de0aee6d4cffa6f3e88cc84dc274",
      "sender": "jnewbery",
      "payload": "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)",
      "action": false,
      "timestamp": "2020-09-08T15:51:43+00:00"
    },
    {
      "id": "f66a3b3a39a34cad82ac12c6b3cc6f9a",
      "sender": "jnewbery",
      "payload": "ariard: are you happy to punt that to the next meeting?",
      "action": false,
      "timestamp": "2020-09-08T15:51:56+00:00"
    },
    {
      "id": "59297db38c9746acbe44f0ee265a4a4d",
      "sender": "ariard",
      "payload": "aj: being eclipsed at the tx-relay level is really bad for offchain stuff",
      "action": false,
      "timestamp": "2020-09-08T15:52:01+00:00"
    },
    {
      "id": "9aa25ab24da6470b95205aacfd672aa2",
      "sender": "ariard",
      "payload": "jnewbery: I feel we need it better to end on this topics",
      "action": false,
      "timestamp": "2020-09-08T15:52:12+00:00"
    },
    {
      "id": "e552bba0386849eb97ebd7186d9789ff",
      "sender": "aj",
      "payload": "ariard: not as bad as being eclipsed from the most-work chain though",
      "action": false,
      "timestamp": "2020-09-08T15:52:27+00:00"
    },
    {
      "id": "32a9ee08be5048b192085ad52fee0631",
      "sender": "sdaftuar",
      "payload": "lightlike: agreed, addr relay likely leaks topology",
      "action": false,
      "timestamp": "2020-09-08T15:52:38+00:00"
    },
    {
      "id": "41731f46b7cf4c6ca861349fc8e7715a",
      "sender": "aj",
      "payload": "sipa: (what's the blocker for getting tx relay overhaul rebased/out-of-draft?)",
      "action": false,
      "timestamp": "2020-09-08T15:52:56+00:00"
    },
    {
      "id": "6d8e55b07b954135b6c2c625dbeb9539",
      "sender": "gleb",
      "payload": "sdaftuar: have you checked out caches yet? It's getting better!",
      "action": false,
      "timestamp": "2020-09-08T15:53:15+00:00"
    },
    {
      "id": "5d54b2f57a184e88883e89c73b8fb991",
      "sender": "sipa",
      "payload": "ariard: parse error",
      "action": false,
      "timestamp": "2020-09-08T15:53:26+00:00"
    },
    {
      "id": "26a1ef27fbe14cac8a354fb6a6e89e4c",
      "sender": "jnewbery",
      "payload": "ariard: does that mean punt to next meeting?",
      "action": false,
      "timestamp": "2020-09-08T15:53:28+00:00"
    },
    {
      "id": "680d77005fb6446b86a3690f0bb4ace6",
      "sender": "ariard",
      "payload": "aj: in fact I think that's a bit more subtle, you can close your channels without knowing what the state chain is ?",
      "action": false,
      "timestamp": "2020-09-08T15:53:37+00:00"
    },
    {
      "id": "20acbfe8c3b24dc3948ab2c5b30a8f71",
      "sender": "sdaftuar",
      "payload": "gleb: no idea what you're referring to...",
      "action": false,
      "timestamp": "2020-09-08T15:53:41+00:00"
    },
    {
      "id": "2e0955cbb5994322bc9e01c51fbcedc1",
      "sender": "ariard",
      "payload": "jnewbery: yes next meeting :)",
      "action": false,
      "timestamp": "2020-09-08T15:53:44+00:00"
    },
    {
      "id": "c57e685f52bf43cfb7ab161af268b637",
      "sender": "gleb",
      "payload": "sdaftuar: #18991",
      "action": false,
      "timestamp": "2020-09-08T15:54:02+00:00"
    },
    {
      "id": "1711d8309e184af1a5a791d6bdb8e10f",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #18991 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:54:06+00:00"
    },
    {
      "id": "eae5417eb5004133a51efefbe9bbcf47",
      "sender": "sdaftuar",
      "payload": "gleb: oh, addr-relay privacy leaks",
      "action": false,
      "timestamp": "2020-09-08T15:54:08+00:00"
    },
    {
      "id": "e756855b1b9c49c1a07df61ee859775f",
      "sender": "jnewbery",
      "payload": "great. Thanks. That'll also give people a bit more time to read your doc here: https://github.com/bitcoin/bitcoin/issues/19820",
      "action": false,
      "timestamp": "2020-09-08T15:54:10+00:00"
    },
    {
      "id": "e2ca492371094c3d9444f851792aac99",
      "sender": "ariard",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:54:11+00:00"
    },
    {
      "id": "a5e9c49e26164531926553514846a1db",
      "sender": "sipa",
      "payload": "ariard: you know my thinking on that",
      "action": false,
      "timestamp": "2020-09-08T15:55:09+00:00"
    },
    {
      "id": "22ec55c39ff94976b962f46e60530510",
      "sender": "aj",
      "payload": "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",
      "action": false,
      "timestamp": "2020-09-08T15:55:24+00:00"
    },
    {
      "id": "bb646ada473847ffa7e0cae37b857554",
      "sender": "sipa",
      "payload": "aj: i have a branch where it's half done, but i got preempted by bip340/taproot stuff",
      "action": false,
      "timestamp": "2020-09-08T15:55:42+00:00"
    },
    {
      "id": "685d4de8aa05427c8101f6e8b50e3cbe",
      "sender": "ariard",
      "payload": "sipa: I know, I know that's the reason to talk about #19820 next time :)",
      "action": false,
      "timestamp": "2020-09-08T15:56:07+00:00"
    },
    {
      "id": "7079bf0489174c288ca1236419f8532c",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals \u00c3\u0082\u00c2\u00b7 Issue #19820 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:56:07+00:00"
    },
    {
      "id": "bc6727da31384706ae29234ea4fa609a",
      "sender": "gleb",
      "payload": "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.",
      "action": false,
      "timestamp": "2020-09-08T15:57:39+00:00"
    },
    {
      "id": "749e24fe97ce49caaa7cd1f0beb21e30",
      "sender": "sdaftuar",
      "payload": "gleb: that sounds good to me.  thanks for the discussion!",
      "action": false,
      "timestamp": "2020-09-08T15:57:57+00:00"
    },
    {
      "id": "b689fe6bdc6d477fb4e65893a65681cb",
      "sender": "sipa",
      "payload": "gleb: sounds good",
      "action": false,
      "timestamp": "2020-09-08T15:58:01+00:00"
    },
    {
      "id": "5008067fb133415a95965849b587f7b1",
      "sender": "jnewbery",
      "payload": "Thanks gleb!",
      "action": false,
      "timestamp": "2020-09-08T15:58:12+00:00"
    },
    {
      "id": "62531d71a8b5469aa4eb5dc0bae48c6c",
      "sender": "ariard",
      "payload": "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)",
      "action": false,
      "timestamp": "2020-09-08T15:58:13+00:00"
    },
    {
      "id": "c7d49bd2e2b344fab871ea79b162aa0f",
      "sender": "jnewbery",
      "payload": "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!",
      "action": false,
      "timestamp": "2020-09-08T15:58:43+00:00"
    },
    {
      "id": "843e232ca1b34bdbb3af1edfebb9603c",
      "sender": "sdaftuar",
      "payload": "if we're shilling, i'd love review on #19858",
      "action": false,
      "timestamp": "2020-09-08T15:59:10+00:00"
    },
    {
      "id": "b42967f430d1431181f9485ab1d0d71d",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar \u00c3\u0082\u00c2\u00b7 Pull Request #19858 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:59:13+00:00"
    },
    {
      "id": "dfb1fc947eed493e90a7bf2fc8c84f9c",
      "sender": "ariard",
      "payload": "sdaftuar: updated #19871 in the hope to clarify outbound eviction",
      "action": false,
      "timestamp": "2020-09-08T15:59:24+00:00"
    },
    {
      "id": "3d5ae3d2b04e482b847a065028fb39b8",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19871 | doc: Clarify scope of eviction protection of outbound block-relay peers by ariard \u00c3\u0082\u00c2\u00b7 Pull Request #19871 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:59:25+00:00"
    },
    {
      "id": "9f7d66798a724d1cb611c47b1cd6530e",
      "sender": "sdaftuar",
      "payload": "ariard: thanks, i'll take a look",
      "action": false,
      "timestamp": "2020-09-08T15:59:37+00:00"
    },
    {
      "id": "e10449980fcf4608a6588ea5d7ecdcdf",
      "sender": "hebasto",
      "payload": "o/",
      "action": false,
      "timestamp": "2020-09-08T15:59:39+00:00"
    },
    {
      "id": "bfb1fbf58a9641b7a0ab876c2e308be9",
      "sender": "sipa",
      "payload": "i have been succesfully shilled",
      "action": false,
      "timestamp": "2020-09-08T15:59:41+00:00"
    },
    {
      "id": "3ad82f17e759415f9ad3f04069efc097",
      "sender": "jnewbery",
      "payload": "any advances on one shilling?",
      "action": false,
      "timestamp": "2020-09-08T15:59:43+00:00"
    },
    {
      "id": "a7b2d2155dec4623a58e89b18f457ef7",
      "sender": "jnewbery",
      "payload": "going once",
      "action": false,
      "timestamp": "2020-09-08T15:59:46+00:00"
    },
    {
      "id": "e4e48f8360bd4ee8bc5d1e0c840d360c",
      "sender": "hebasto",
      "payload": "#17785",
      "action": false,
      "timestamp": "2020-09-08T15:59:46+00:00"
    },
    {
      "id": "195a4acd37e442c5a086eb61ef3349ec",
      "sender": "jonatack",
      "payload": "It would be great to have #19643 in master and it seems RFM",
      "action": false,
      "timestamp": "2020-09-08T15:59:48+00:00"
    },
    {
      "id": "f0683cabd49d423a82e2646cae14ce8d",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto \u00c3\u0082\u00c2\u00b7 Pull Request #17785 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:59:48+00:00"
    },
    {
      "id": "67fb4f112bfe434d845488574ee9ae79",
      "sender": "jnewbery",
      "payload": "going twice",
      "action": false,
      "timestamp": "2020-09-08T15:59:49+00:00"
    },
    {
      "id": "be03a317532f4fe4a78315abafd1ce4b",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19643 | Add -netinfo peer connections dashboard by jonatack \u00c3\u0082\u00c2\u00b7 Pull Request #19643 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:59:51+00:00"
    },
    {
      "id": "e83e3c7fa7484424b047882e6ea3471b",
      "sender": "gleb",
      "payload": "super-easy little refactoring which will unlock my future work #19843",
      "action": false,
      "timestamp": "2020-09-08T15:59:54+00:00"
    },
    {
      "id": "cb4a5d8abad44c02976b8b2431b0212d",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/19843 | Refactoring and minor improvement for self-advertisements by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #19843 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2020-09-08T15:59:55+00:00"
    },
    {
      "id": "34551378247c493b8b4b9756bbae2039",
      "sender": "jnewbery",
      "payload": "#endmeeting",
      "action": false,
      "timestamp": "2020-09-08T15:59:59+00:00"
    }
  ],
  "events": [
    {
      "event_type": "START_MEETING",
      "message": {
        "id": "376a438765564503a3d5798395c77228",
        "sender": "jnewbery",
        "payload": "#startmeeting",
        "action": false,
        "timestamp": "2020-09-08T15:00:18+00:00"
      },
      "operand": null,
      "id": "376a438765564503a3d5798395c77228",
      "timestamp": "2020-09-08T15:00:18+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "c68052579bf341abb6d8a9c7050b7cf3",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals \u00c3\u0082\u00c2\u00b7 Issue #19820 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:02:05+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19820",
      "id": "c68052579bf341abb6d8a9c7050b7cf3",
      "timestamp": "2020-09-08T15:02:05+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "ca27e55d0b3f4516a7907ccd4fd937ec",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery \u00c3\u0082\u00c2\u00b7 Pull Request #19606 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:05:01+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19606",
      "id": "ca27e55d0b3f4516a7907ccd4fd937ec",
      "timestamp": "2020-09-08T15:05:01+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "f1b10d6c5e2b48c0bfb55cc35446472e",
        "sender": "jnewbery",
        "payload": "#topic netgroup diversity of outbound peers (gleb)",
        "action": false,
        "timestamp": "2020-09-08T15:06:41+00:00"
      },
      "operand": "netgroup diversity of outbound peers (gleb)",
      "id": "f1b10d6c5e2b48c0bfb55cc35446472e",
      "timestamp": "2020-09-08T15:06:41+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "b392d54b28ee4324806039b6e6d38fb0",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19860 | Improve diversification of new connections: privacy and stability by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #19860 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:06:49+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19860",
      "id": "b392d54b28ee4324806039b6e6d38fb0",
      "timestamp": "2020-09-08T15:06:49+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "c25926c3bb4545f6ba4d3e6d55856987",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto \u00c3\u0082\u00c2\u00b7 Pull Request #17428 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:34:04+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/17428",
      "id": "c25926c3bb4545f6ba4d3e6d55856987",
      "timestamp": "2020-09-08T15:34:04+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "d8a550cc5ef74e6ea321d5461c266732",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/18421 | Periodically update DNS caches for better privacy of non-reachable nodes by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #18421 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:38:59+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/18421",
      "id": "d8a550cc5ef74e6ea321d5461c266732",
      "timestamp": "2020-09-08T15:38:59+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "1711d8309e184af1a5a791d6bdb8e10f",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/18991 | Cache responses to GETADDR to prevent topology leaks by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #18991 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:54:06+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/18991",
      "id": "1711d8309e184af1a5a791d6bdb8e10f",
      "timestamp": "2020-09-08T15:54:06+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "7079bf0489174c288ca1236419f8532c",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals \u00c3\u0082\u00c2\u00b7 Issue #19820 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:56:07+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19820",
      "id": "7079bf0489174c288ca1236419f8532c",
      "timestamp": "2020-09-08T15:56:07+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "b42967f430d1431181f9485ab1d0d71d",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19858 | Periodically make block-relay connections and sync headers by sdaftuar \u00c3\u0082\u00c2\u00b7 Pull Request #19858 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:59:13+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19858",
      "id": "b42967f430d1431181f9485ab1d0d71d",
      "timestamp": "2020-09-08T15:59:13+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "3d5ae3d2b04e482b847a065028fb39b8",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19871 | doc: Clarify scope of eviction protection of outbound block-relay peers by ariard \u00c3\u0082\u00c2\u00b7 Pull Request #19871 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:59:25+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19871",
      "id": "3d5ae3d2b04e482b847a065028fb39b8",
      "timestamp": "2020-09-08T15:59:25+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "f0683cabd49d423a82e2646cae14ce8d",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/17785 | p2p: Unify Send and Receive protocol versions by hebasto \u00c3\u0082\u00c2\u00b7 Pull Request #17785 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:59:48+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/17785",
      "id": "f0683cabd49d423a82e2646cae14ce8d",
      "timestamp": "2020-09-08T15:59:48+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "be03a317532f4fe4a78315abafd1ce4b",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19643 | Add -netinfo peer connections dashboard by jonatack \u00c3\u0082\u00c2\u00b7 Pull Request #19643 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:59:51+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19643",
      "id": "be03a317532f4fe4a78315abafd1ce4b",
      "timestamp": "2020-09-08T15:59:51+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "cb4a5d8abad44c02976b8b2431b0212d",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/19843 | Refactoring and minor improvement for self-advertisements by naumenkogs \u00c3\u0082\u00c2\u00b7 Pull Request #19843 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2020-09-08T15:59:55+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/19843",
      "id": "cb4a5d8abad44c02976b8b2431b0212d",
      "timestamp": "2020-09-08T15:59:55+00:00"
    },
    {
      "event_type": "END_MEETING",
      "message": {
        "id": "34551378247c493b8b4b9756bbae2039",
        "sender": "jnewbery",
        "payload": "#endmeeting",
        "action": false,
        "timestamp": "2020-09-08T15:59:59+00:00"
      },
      "operand": null,
      "id": "34551378247c493b8b4b9756bbae2039",
      "timestamp": "2020-09-08T15:59:59+00:00"
    }
  ],
  "aliases": {},
  "vote_in_progress": false,
  "motion_index": null
}