{
  "founder": "wumpus",
  "channel": "#bitcoin-core-dev",
  "network": "freenode",
  "id": "d95a86ad54a24cac871d5600a77de0c9",
  "name": "#bitcoin-core-dev",
  "chair": "wumpus",
  "chairs": [
    "wumpus"
  ],
  "nicks": {
    "wumpus": 28,
    "lightningbot": 2,
    "sipa": 37,
    "gmaxwell": 39,
    "jonasschnelli": 6,
    "jtimon": 4,
    "GitHub136": 1,
    "BlueMatt": 20,
    "achow101": 2,
    "btcdrak": 1,
    "sdaftuar": 29,
    "arubi": 1,
    "kanzure": 1,
    "Chris_St1": 1,
    "morcos": 8,
    "GitHub84": 1,
    "gribble": 3,
    "luke-jr": 18
  },
  "start_time": "2016-11-03T19:00:39+00:00",
  "end_time": "2016-11-03T20:00:22+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: https://botbot.me/freenode/bitcoin-core-dev, http://www.erisian.com.au/bitcoin-core-dev/",
  "current_topic": "BIP 152 changes",
  "messages": [
    {
      "id": "64ed64bc8f8b420ba9b829f81421a875",
      "sender": "wumpus",
      "payload": "#startmeeting",
      "action": false,
      "timestamp": "2016-11-03T19:00:39+00:00"
    },
    {
      "id": "15335e777de74e6f96706d850e68be7c",
      "sender": "lightningbot",
      "payload": "Meeting started Thu Nov  3 19:00:39 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.",
      "action": false,
      "timestamp": "2016-11-03T19:00:39+00:00"
    },
    {
      "id": "be8435de12b24d04b112b31138b09189",
      "sender": "lightningbot",
      "payload": "Useful Commands: #action #agreed #help #info #idea #link #topic.",
      "action": false,
      "timestamp": "2016-11-03T19:00:39+00:00"
    },
    {
      "id": "a218bd3253424d6fbdd863e465b45d03",
      "sender": "sipa",
      "payload": "meeting!",
      "action": false,
      "timestamp": "2016-11-03T19:00:44+00:00"
    },
    {
      "id": "855021bad5dd4284bf03ae20df193afb",
      "sender": "wumpus",
      "payload": "#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012",
      "action": false,
      "timestamp": "2016-11-03T19:00:53+00:00"
    },
    {
      "id": "57592e4c702c411f8a452b2f4fb38f6d",
      "sender": "gmaxwell",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-11-03T19:01:02+00:00"
    },
    {
      "id": "f480247732c34d20aee35f18fdc94bd4",
      "sender": "jonasschnelli",
      "payload": "here",
      "action": false,
      "timestamp": "2016-11-03T19:01:03+00:00"
    },
    {
      "id": "d0293feff2444c2ca25c5baa91d0f852",
      "sender": "jtimon",
      "payload": "hello",
      "action": false,
      "timestamp": "2016-11-03T19:01:08+00:00"
    },
    {
      "id": "07c7b1b62dd348bab2a94a77d9ccf9cc",
      "sender": "GitHub136",
      "payload": "[bitcoin] TheBlueMatt opened pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (master...net_processing_4) https://github.com/bitcoin/bitcoin/pull/9075",
      "action": false,
      "timestamp": "2016-11-03T19:01:17+00:00"
    },
    {
      "id": "381c61bcf6844713ba31c53b13c998cf",
      "sender": "BlueMatt",
      "payload": "second to last one ^",
      "action": false,
      "timestamp": "2016-11-03T19:01:18+00:00"
    },
    {
      "id": "4b1874eacba541ddba2d0e7e8579ec8c",
      "sender": "wumpus",
      "payload": "BlueMatt: you just keep reopening it after we merge it, isn't it :)",
      "action": false,
      "timestamp": "2016-11-03T19:01:39+00:00"
    },
    {
      "id": "b22f16d42f2647e1b77a84131704235e",
      "sender": "wumpus",
      "payload": "proposed topics?",
      "action": false,
      "timestamp": "2016-11-03T19:01:45+00:00"
    },
    {
      "id": "096682218f0c4484a8f34240f498ebda",
      "sender": "BlueMatt",
      "payload": "wumpus: E_NO_PARSE, but, yes, all this stuff is pretty much queued up, once one gets merged another gets pr'd",
      "action": false,
      "timestamp": "2016-11-03T19:02:10+00:00"
    },
    {
      "id": "95912f4e5786453bb2cb5ba1b77f2361",
      "sender": "wumpus",
      "payload": "no topics at all for this meeting?",
      "action": false,
      "timestamp": "2016-11-03T19:02:59+00:00"
    },
    {
      "id": "319ddd19a5d64a70b73049bce9a70e30",
      "sender": "wumpus",
      "payload": "did the pre-final alert go out gmaxwell?",
      "action": false,
      "timestamp": "2016-11-03T19:03:20+00:00"
    },
    {
      "id": "d741c0f5195a4cf1aef8ca79acbacc56",
      "sender": "achow101",
      "payload": "it did",
      "action": false,
      "timestamp": "2016-11-03T19:03:24+00:00"
    },
    {
      "id": "6ce9631057bb4dfdace9cdcfa1215c26",
      "sender": "wumpus",
      "payload": "ok, great",
      "action": false,
      "timestamp": "2016-11-03T19:03:29+00:00"
    },
    {
      "id": "0c1a340f4f264316bbddc1fd4196ce88",
      "sender": "sipa",
      "payload": "did anyone see it?",
      "action": false,
      "timestamp": "2016-11-03T19:03:38+00:00"
    },
    {
      "id": "b2cbc81d1820400abe1a5c0089a69752",
      "sender": "btcdrak",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-11-03T19:03:41+00:00"
    },
    {
      "id": "16eae175beb04953a89b6fd51bb90c6a",
      "sender": "sdaftuar",
      "payload": "i did",
      "action": false,
      "timestamp": "2016-11-03T19:03:42+00:00"
    },
    {
      "id": "e8ce81c2d8374e5db5fb4d2f16968b0f",
      "sender": "achow101",
      "payload": "I caught it on a 0.12.0 node I fired up just for it",
      "action": false,
      "timestamp": "2016-11-03T19:03:50+00:00"
    },
    {
      "id": "0aadb92d112046be95ad7bd27210c7dd",
      "sender": "arubi",
      "payload": "I have it on onlynet=onion",
      "action": false,
      "timestamp": "2016-11-03T19:04:21+00:00"
    },
    {
      "id": "9041a86f1bb447199a0b4aab058042e4",
      "sender": "sipa",
      "payload": "gmaxwell and i were talking recently about some improvements to the block/header fetch logic",
      "action": false,
      "timestamp": "2016-11-03T19:04:25+00:00"
    },
    {
      "id": "0871c060abed450bad9a1bab8d1195cf",
      "sender": "wumpus",
      "payload": "#topic block header/fetch logic",
      "action": false,
      "timestamp": "2016-11-03T19:04:50+00:00"
    },
    {
      "id": "4f6d00cedb5842b5b8ae8fa4cdd55cf8",
      "sender": "sipa",
      "payload": "there are a bunch of related points there",
      "action": false,
      "timestamp": "2016-11-03T19:05:03+00:00"
    },
    {
      "id": "2253c8ad93f8489facf2025fad07bbdb",
      "sender": "sipa",
      "payload": "one is that we don't have a timeout for headers requests",
      "action": false,
      "timestamp": "2016-11-03T19:05:14+00:00"
    },
    {
      "id": "8a4946dd0f254487bcd322a36f1ce25a",
      "sender": "jtimon",
      "payload": "BlueMatt: is there a long branch where I can see the code movements you're planning?",
      "action": false,
      "timestamp": "2016-11-03T19:05:36+00:00"
    },
    {
      "id": "2633519cecea4043aabb9b535494c843",
      "sender": "BlueMatt",
      "payload": "jtimon: working on an updated version now",
      "action": false,
      "timestamp": "2016-11-03T19:05:54+00:00"
    },
    {
      "id": "0cf8f716654d4ed68241e2af60f3d37f",
      "sender": "sipa",
      "payload": "and that we don't respond to headers requests while in IBD, which can cause stalls if nodes mistakenly believe they are in IBD",
      "action": false,
      "timestamp": "2016-11-03T19:05:59+00:00"
    },
    {
      "id": "88ffe50b16d7409d89f316eea169adeb",
      "sender": "sipa",
      "payload": "bit it goes even further... the block fetch logic only disconnects peers who slow down the process",
      "action": false,
      "timestamp": "2016-11-03T19:06:21+00:00"
    },
    {
      "id": "be2d69c2c9ef42058a51ec63aae97aac",
      "sender": "sipa",
      "payload": "we may just have a peer who has no blocks we can fetch at all from, and we never try, and we never disconnect them",
      "action": false,
      "timestamp": "2016-11-03T19:06:41+00:00"
    },
    {
      "id": "ebf2191b07974581911af6ea0071f980",
      "sender": "sdaftuar",
      "payload": "sipa: eg non-NODE_WITNESS nodes?",
      "action": false,
      "timestamp": "2016-11-03T19:07:04+00:00"
    },
    {
      "id": "87a8534b70d84d7aae489ebe1bfa4cd1",
      "sender": "jtimon",
      "payload": "BlueMatt: cool",
      "action": false,
      "timestamp": "2016-11-03T19:07:11+00:00"
    },
    {
      "id": "32ee3576bde54c2db12792b707db9590",
      "sender": "sipa",
      "payload": "sdaftuar: or nodes who are legitimately behind",
      "action": false,
      "timestamp": "2016-11-03T19:07:15+00:00"
    },
    {
      "id": "5019560e32ca447a8eac2eff0fa8b15a",
      "sender": "sdaftuar",
      "payload": "ah, right",
      "action": false,
      "timestamp": "2016-11-03T19:07:18+00:00"
    },
    {
      "id": "dfe0c475857f4356a4b5cabd5d4ab0a8",
      "sender": "sipa",
      "payload": "so it seems there is a simple solution: disconnect outgoing connections you're not downloading from while in IBD",
      "action": false,
      "timestamp": "2016-11-03T19:07:50+00:00"
    },
    {
      "id": "97b547d7facf4e2b91b796549933d379",
      "sender": "sipa",
      "payload": "but remove the non-response to getheaders in IBD",
      "action": false,
      "timestamp": "2016-11-03T19:08:13+00:00"
    },
    {
      "id": "7859495c5f5b4741bf2665a5efe0a51b",
      "sender": "jonasschnelli",
      "payload": "sipa: ack",
      "action": false,
      "timestamp": "2016-11-03T19:08:30+00:00"
    },
    {
      "id": "3ba946e3cee44f979f5cadf935f31f18",
      "sender": "sipa",
      "payload": "if the peer actually is behind, we won't fetch from them, and we'll disconnect them instead of stalling yhem",
      "action": false,
      "timestamp": "2016-11-03T19:08:35+00:00"
    },
    {
      "id": "23443cbe81b4483791cb2fded537cf13",
      "sender": "sipa",
      "payload": "gmaxwell suggested something even stronger: ever minute, disconnect the peer that is slowest to give you blocks overall (during IBD)",
      "action": false,
      "timestamp": "2016-11-03T19:09:30+00:00"
    },
    {
      "id": "60a2293230404efe807f1511062f1faf",
      "sender": "sdaftuar",
      "payload": "if we remove the non-response to getheaders in IBD, mightn't we disconnect people who are downloading from us?",
      "action": false,
      "timestamp": "2016-11-03T19:09:35+00:00"
    },
    {
      "id": "5c3a37ce606047aaae98bb6ee433f297",
      "sender": "jonasschnelli",
      "payload": "During IBD?",
      "action": false,
      "timestamp": "2016-11-03T19:09:54+00:00"
    },
    {
      "id": "2ab299e551fd4868a5c58a1398674ac4",
      "sender": "sipa",
      "payload": "sdaftuar: note that this is only for outgoing connections",
      "action": false,
      "timestamp": "2016-11-03T19:10:05+00:00"
    },
    {
      "id": "1613ab0278144269b306c5f6cd1e7754",
      "sender": "sdaftuar",
      "payload": "ah",
      "action": false,
      "timestamp": "2016-11-03T19:10:14+00:00"
    },
    {
      "id": "50c2330eac664302b4a8a2e3230f8dd3",
      "sender": "sipa",
      "payload": "i think serving blocks to someone who is even more behind than us, whike we are in IBD, is perfectly fine",
      "action": false,
      "timestamp": "2016-11-03T19:10:48+00:00"
    },
    {
      "id": "030f88cb567643d0b3af564ac22cb497",
      "sender": "gmaxwell",
      "payload": "I believe my suggestion went further, if you have MAX outbound, and it's been a minute since you disconnected anyone, and you're downloading blocks, disconnect the outbound peer you recieved the fewest blocks from in the last minute. (or, least recently recieved a block from). Presumably excempting -connect peers.",
      "action": false,
      "timestamp": "2016-11-03T19:10:58+00:00"
    },
    {
      "id": "1ea6491f64fb4ccdba046dfdccf6798a",
      "sender": "gmaxwell",
      "payload": "(ah pieter just said some of that)",
      "action": false,
      "timestamp": "2016-11-03T19:11:06+00:00"
    },
    {
      "id": "b265edeb63bf42f8b1f8b77975ada198",
      "sender": "jonasschnelli",
      "payload": "What about prioritize peers that can server \"faster\" (don't know if it's really measurable)",
      "action": false,
      "timestamp": "2016-11-03T19:11:42+00:00"
    },
    {
      "id": "c038d72b56c94eeeaa9f31517898d800",
      "sender": "sdaftuar",
      "payload": "sipa: one complication with serving headers during IBD is that we might be on a bogus chain",
      "action": false,
      "timestamp": "2016-11-03T19:12:05+00:00"
    },
    {
      "id": "205c29093ce043f9be0a2d68c7047deb",
      "sender": "sipa",
      "payload": "jonasschnelli: that's what we already do... the slowest ones get disconnected if they slow your overall sync speed down",
      "action": false,
      "timestamp": "2016-11-03T19:12:14+00:00"
    },
    {
      "id": "c59d0fbee60e4528b27948526bd6d4af",
      "sender": "jonasschnelli",
      "payload": "sipa: ah",
      "action": false,
      "timestamp": "2016-11-03T19:12:28+00:00"
    },
    {
      "id": "c420fceb4fdb428394c93e3363546f6c",
      "sender": "sipa",
      "payload": "sdaftuar: that's something better IBD/chainpoint replacement is for, i guess?",
      "action": false,
      "timestamp": "2016-11-03T19:12:58+00:00"
    },
    {
      "id": "8af9c22223b449a48585a20a9bef54b8",
      "sender": "sipa",
      "payload": "*checkpoint",
      "action": false,
      "timestamp": "2016-11-03T19:13:09+00:00"
    },
    {
      "id": "ee6eb8f540354b3d83017d5181242ff5",
      "sender": "jonasschnelli",
      "payload": "during my SPV work I encountered some stalling because of peers serving blocks each in a ~5min rhythm.",
      "action": false,
      "timestamp": "2016-11-03T19:13:23+00:00"
    },
    {
      "id": "65bac9f600b94124b8cd187a78be78a3",
      "sender": "sdaftuar",
      "payload": "i thought gmaxwell's PR to replcae the checkpointed-height with a checkpointed work as a way to determine if you're in IBD makes sense",
      "action": false,
      "timestamp": "2016-11-03T19:13:30+00:00"
    },
    {
      "id": "b0e17a1bd712456a9854f04addf7ceb1",
      "sender": "sdaftuar",
      "payload": "so if we eliminate the IBD restriction on serving headers, we'd still want to keep some version of that checkpointed-work requirement i think",
      "action": false,
      "timestamp": "2016-11-03T19:14:07+00:00"
    },
    {
      "id": "4bb0468d8bb845a49a44bf65497d2a3a",
      "sender": "sdaftuar",
      "payload": "which i guess would be fine?",
      "action": false,
      "timestamp": "2016-11-03T19:15:09+00:00"
    },
    {
      "id": "d227645b4f04403da1a96a406a3172d5",
      "sender": "sdaftuar",
      "payload": "and an improvement over the current situation",
      "action": false,
      "timestamp": "2016-11-03T19:15:15+00:00"
    },
    {
      "id": "78ed77ab8a0c4ae38104ec18a4b48e7c",
      "sender": "sdaftuar",
      "payload": "?",
      "action": false,
      "timestamp": "2016-11-03T19:15:18+00:00"
    },
    {
      "id": "5d8341cb48af4ce792d7b00ca7ff8107",
      "sender": "kanzure",
      "payload": "hi.",
      "action": false,
      "timestamp": "2016-11-03T19:15:20+00:00"
    },
    {
      "id": "e32b71102b95418c91d5f56d0afd813a",
      "sender": "sipa",
      "payload": "i think so",
      "action": false,
      "timestamp": "2016-11-03T19:15:22+00:00"
    },
    {
      "id": "9078942a375a41fab8ae09b8a9a73cbc",
      "sender": "sipa",
      "payload": "it's hard to reason about this. if you're truly sybilled during IBD, none of this will have an effect",
      "action": false,
      "timestamp": "2016-11-03T19:15:54+00:00"
    },
    {
      "id": "9dd1b5da6d2b47e1ad02d53253f504d4",
      "sender": "sipa",
      "payload": "if not, you'll quickly learn about the real chain anyway",
      "action": false,
      "timestamp": "2016-11-03T19:16:07+00:00"
    },
    {
      "id": "df6b73c3354345de9c785cc776c4d460",
      "sender": "Chris_St1",
      "payload": "sipa: So that pull request does not help if you are fully sybilled? Won't you at least be able to determine if there was a lot of work expended in the sybil attack? (not sure how reassuring that is)",
      "action": false,
      "timestamp": "2016-11-03T19:17:22+00:00"
    },
    {
      "id": "5ae27ee8b98d43d6a7fe1a73039edd75",
      "sender": "gmaxwell",
      "payload": "this is going offtopic. :)",
      "action": false,
      "timestamp": "2016-11-03T19:17:41+00:00"
    },
    {
      "id": "05b402b5e837409fbaa3b136c8128e88",
      "sender": "gmaxwell",
      "payload": "sipa: sdaftuar is pointing out that if we're on a checkpoint invalid chain, and serve headers for it, our peers will ban us. So thats a complication with serving headers while below the top checkpoint.",
      "action": false,
      "timestamp": "2016-11-03T19:18:17+00:00"
    },
    {
      "id": "193c40f2fc7944ba9050d6adf3c828ed",
      "sender": "sipa",
      "payload": "ah.",
      "action": false,
      "timestamp": "2016-11-03T19:18:45+00:00"
    },
    {
      "id": "a47521dfb597406b867f0df182b890f4",
      "sender": "sdaftuar",
      "payload": "right, so assuming we are keeping the checkpoint-work-requirement (or some version of it) as a gate on responding to a getheaders, then which of the IBD checks are we trying to eliminate?",
      "action": false,
      "timestamp": "2016-11-03T19:19:17+00:00"
    },
    {
      "id": "4f6ab9787b9d43ca8df5c795b906afb2",
      "sender": "sdaftuar",
      "payload": "from past conversations i think the concern is that we might have some long headers chain that we can't access/download blocks towards, like on testnet or something",
      "action": false,
      "timestamp": "2016-11-03T19:19:42+00:00"
    },
    {
      "id": "14ac3c92be2f4b1e8322c6d6915811a1",
      "sender": "sdaftuar",
      "payload": "is that basicalyl right?",
      "action": false,
      "timestamp": "2016-11-03T19:19:46+00:00"
    },
    {
      "id": "4c1339d74fec48a2a8f26a06a34bd22e",
      "sender": "gmaxwell",
      "payload": "We'd like to eliminate all cases where we simply ignore a getheaders request (potentially replace it with hanging up on the peer)-- because it DOS attacks peers unlucky enough to select us for their initial headers fetch.",
      "action": false,
      "timestamp": "2016-11-03T19:20:14+00:00"
    },
    {
      "id": "03270c7b1bbe4e24aa56a21ad436aebd",
      "sender": "sipa",
      "payload": "we only serve headers for blocks in our main chain, no?",
      "action": false,
      "timestamp": "2016-11-03T19:20:27+00:00"
    },
    {
      "id": "bcf3a7e1d7d74eb09ecbc402fa6c7c3a",
      "sender": "sdaftuar",
      "payload": "sipa: yes",
      "action": false,
      "timestamp": "2016-11-03T19:20:35+00:00"
    },
    {
      "id": "1ea091fbc459409d9479455e1760c368",
      "sender": "sipa",
      "payload": "which indeed may contains dummy low difficulty blocks",
      "action": false,
      "timestamp": "2016-11-03T19:20:38+00:00"
    },
    {
      "id": "f77dbfb256d64719948c0ca03d4fb74b",
      "sender": "gmaxwell",
      "payload": "In any case, the download part of this can be done first before any change to how we respond to getheaders.",
      "action": false,
      "timestamp": "2016-11-03T19:21:40+00:00"
    },
    {
      "id": "de445094f34e43259c169d1a8cc4b441",
      "sender": "sipa",
      "payload": "right",
      "action": false,
      "timestamp": "2016-11-03T19:21:51+00:00"
    },
    {
      "id": "3b5c10ac35d24201a6db0a28bf6e1eb7",
      "sender": "morcos",
      "payload": "gmaxwell: thanks, i think it was important to clearly delineate the problem.  i didn't know what we were trying to accomplish.  it doesn't seem that having a bunch of IBD nodes able to serve each other as much as they have is _that_ beneficial",
      "action": false,
      "timestamp": "2016-11-03T19:21:59+00:00"
    },
    {
      "id": "d42e7645f22645aa88e3bdafbf9754b0",
      "sender": "morcos",
      "payload": "however freeing them up to ask someone else for headers withotu waiting for a long timeout seems valuable",
      "action": false,
      "timestamp": "2016-11-03T19:22:19+00:00"
    },
    {
      "id": "6977f1e6625149969f5d3a7f862bd010",
      "sender": "GitHub84",
      "payload": "[bitcoin] TheBlueMatt closed pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930",
      "action": false,
      "timestamp": "2016-11-03T19:22:29+00:00"
    },
    {
      "id": "13a4e1ccae1b4dc3873104d58862a45a",
      "sender": "gmaxwell",
      "payload": "morcos: yes, thats mostly irrelevant, the concern is primarily that we cause harm to peers by not responding.",
      "action": false,
      "timestamp": "2016-11-03T19:22:33+00:00"
    },
    {
      "id": "96165ae47c3f48aab2a52d46be692f2a",
      "sender": "gmaxwell",
      "payload": "morcos: My recollection is that currently we don't even have a timeout for the initial headers fetch! the 'timeout' is a new block being offered by some other peer.",
      "action": false,
      "timestamp": "2016-11-03T19:22:58+00:00"
    },
    {
      "id": "a84d5fbe8af94e8481e3035f72f176fe",
      "sender": "sdaftuar",
      "payload": "so step 1: #9068?",
      "action": false,
      "timestamp": "2016-11-03T19:23:14+00:00"
    },
    {
      "id": "2ecb98735ef943ec8169f4bff41365ac",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/9068 | Timeout for headers fetch \u00c3\u0082\u00c2\u00b7 Issue #9068 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2016-11-03T19:23:15+00:00"
    },
    {
      "id": "723f4de938b846029bd9875faeda69c5",
      "sender": "sipa",
      "payload": "morcos: right... i think by using a \"kick peers that aren't useful for sync\" generic approach, we won't need the \"don't serve headers while in IBD\" anyway... less comllexity",
      "action": false,
      "timestamp": "2016-11-03T19:23:35+00:00"
    },
    {
      "id": "85042d44ba1844cdbd8f153cbc35dc3e",
      "sender": "sipa",
      "payload": "*complexity",
      "action": false,
      "timestamp": "2016-11-03T19:23:40+00:00"
    },
    {
      "id": "320c1d7f34804e43a3f317ea765d35b8",
      "sender": "luke-jr",
      "payload": "(suggested topic: when to halt changes to BIPs; 0.13.1 is no longer BIP 152-compatible I think)",
      "action": false,
      "timestamp": "2016-11-03T19:24:31+00:00"
    },
    {
      "id": "2cfe0e7daec54b098823e08af15604ff",
      "sender": "gmaxwell",
      "payload": "That should be fixed as well, but even with it fixed it would be rude to make them wait.",
      "action": false,
      "timestamp": "2016-11-03T19:24:35+00:00"
    },
    {
      "id": "f47c8b80c8e0419ab3a388407d9f7019",
      "sender": "wumpus",
      "payload": "0.13.1 is no longer BIP 152 compatible?",
      "action": false,
      "timestamp": "2016-11-03T19:28:16+00:00"
    },
    {
      "id": "872cc7b4c09b43708cf722b7913f237c",
      "sender": "sdaftuar",
      "payload": "well, it seems to have some bugs",
      "action": false,
      "timestamp": "2016-11-03T19:28:25+00:00"
    },
    {
      "id": "949f7f6c683e42faac1883a249afc97d",
      "sender": "BlueMatt",
      "payload": "0.13.1 is bip 152 compatible after sdaftuar's proposed changes",
      "action": false,
      "timestamp": "2016-11-03T19:28:39+00:00"
    },
    {
      "id": "018735a01ff640909c57658464a2bbdb",
      "sender": "sipa",
      "payload": "switch topic?",
      "action": false,
      "timestamp": "2016-11-03T19:28:52+00:00"
    },
    {
      "id": "c911a40e5a594fed80329b87529e7ee2",
      "sender": "wumpus",
      "payload": "#topic BIP 152 changes",
      "action": false,
      "timestamp": "2016-11-03T19:28:59+00:00"
    },
    {
      "id": "507892d1c7d6429386643f5f5fb97230",
      "sender": "BlueMatt",
      "payload": "which was merged",
      "action": false,
      "timestamp": "2016-11-03T19:29:10+00:00"
    },
    {
      "id": "7415fee4d2f8414889a4e2ece95965fa",
      "sender": "sipa",
      "payload": "0.13.1 does not relayever before validating, right?",
      "action": false,
      "timestamp": "2016-11-03T19:29:18+00:00"
    },
    {
      "id": "2dd00911234645f7a8b876fe42de7c65",
      "sender": "wumpus",
      "payload": "but if it has bugs, was it ever BIP 152 compatible?",
      "action": false,
      "timestamp": "2016-11-03T19:29:21+00:00"
    },
    {
      "id": "c13b9e653ac14b4ba1e9ceab709a70ed",
      "sender": "BlueMatt",
      "payload": "sipa: yes, but it can ban in response to a peer doing that",
      "action": false,
      "timestamp": "2016-11-03T19:29:29+00:00"
    },
    {
      "id": "0e11a7f2584d425d960d34977c698867",
      "sender": "wumpus",
      "payload": "or were the bugsin the BIP",
      "action": false,
      "timestamp": "2016-11-03T19:29:31+00:00"
    },
    {
      "id": "cce31aa8db0a45a68e0c40e14bc6425e",
      "sender": "sdaftuar",
      "payload": "sipa: correct",
      "action": false,
      "timestamp": "2016-11-03T19:29:34+00:00"
    },
    {
      "id": "776e1172d8f64a7587b4f4580eab3c46",
      "sender": "BlueMatt",
      "payload": "sipa: the bip has been updated to say that you may no longer pre-relay unless there was a version bump",
      "action": false,
      "timestamp": "2016-11-03T19:29:42+00:00"
    },
    {
      "id": "83f42385bfb145fdb78f3f6fa4a07e7b",
      "sender": "BlueMatt",
      "payload": "which is #9026",
      "action": false,
      "timestamp": "2016-11-03T19:29:56+00:00"
    },
    {
      "id": "3a8e162962154f0db786726e666c7e61",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar \u00c3\u0082\u00c2\u00b7 Pull Request #9026 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2016-11-03T19:29:57+00:00"
    },
    {
      "id": "4bd9f9d52ee64d64b989253e5d574b82",
      "sender": "sipa",
      "payload": "so the issue is only when potential other bip152 implementations are oresent on the network",
      "action": false,
      "timestamp": "2016-11-03T19:30:05+00:00"
    },
    {
      "id": "782d9272f2d54afd94701fa19b4b2e11",
      "sender": "sdaftuar",
      "payload": "right",
      "action": false,
      "timestamp": "2016-11-03T19:30:11+00:00"
    },
    {
      "id": "582898c75cd5484cbf9fad5c663adc56",
      "sender": "BlueMatt",
      "payload": "sipa: yes, but no such implementations exist, and if they do it now they must wait for the protocol version",
      "action": false,
      "timestamp": "2016-11-03T19:30:27+00:00"
    },
    {
      "id": "4d575e9e65b84f51942605c8f74e018f",
      "sender": "sipa",
      "payload": "so i believe 0.13.1 is compliant with the updated bip152",
      "action": false,
      "timestamp": "2016-11-03T19:30:30+00:00"
    },
    {
      "id": "f2f7ffa4ce7e49d4a707e51a13bb6b91",
      "sender": "BlueMatt",
      "payload": "yes",
      "action": false,
      "timestamp": "2016-11-03T19:30:38+00:00"
    },
    {
      "id": "8b9ee14642964e64ad1f5db0f1e85792",
      "sender": "sdaftuar",
      "payload": "yes, i think so as well.",
      "action": false,
      "timestamp": "2016-11-03T19:30:39+00:00"
    },
    {
      "id": "3c8813b2fd2446a78ae23f89b47bb26b",
      "sender": "gmaxwell",
      "payload": "sipa: unfortunately because of the checkpoint stupidity we may still. :(",
      "action": false,
      "timestamp": "2016-11-03T19:30:45+00:00"
    },
    {
      "id": "f3fbe26b4bb84247b620c8a357d114d9",
      "sender": "gmaxwell",
      "payload": "but lets think about that outside of the meeting.",
      "action": false,
      "timestamp": "2016-11-03T19:30:46+00:00"
    },
    {
      "id": "f56096bd605946cdb7174d79be4b0b92",
      "sender": "gmaxwell",
      "payload": "0.13.0 did too.",
      "action": false,
      "timestamp": "2016-11-03T19:30:46+00:00"
    },
    {
      "id": "2121d952be0946ebb1128424e4712224",
      "sender": "gmaxwell",
      "payload": "But I think what luke was referring to is that BIP152 didn't originally document version 2 compact blocks that use the wtxid instead.",
      "action": false,
      "timestamp": "2016-11-03T19:30:46+00:00"
    },
    {
      "id": "5692d2152c10402fa58001151fd121be",
      "sender": "luke-jr",
      "payload": "wumpus: people are changing BIP 152 still",
      "action": false,
      "timestamp": "2016-11-03T19:30:57+00:00"
    },
    {
      "id": "7a34049657cb43f4bde5525b03977792",
      "sender": "gmaxwell",
      "payload": "Luke's question was really about when should someone be told 'write a new BIP' rather than changing an existing one.",
      "action": false,
      "timestamp": "2016-11-03T19:31:14+00:00"
    },
    {
      "id": "932ab94a1d1e41f5a34f0696a4974e23",
      "sender": "sipa",
      "payload": "yes, this is a good question",
      "action": false,
      "timestamp": "2016-11-03T19:31:26+00:00"
    },
    {
      "id": "36e4ad494fdc4a61acb3db892aa62f72",
      "sender": "luke-jr",
      "payload": "I may be wrong about the current status of v0.13.1 and BIP 152, but yes, the general principle is what I think needs to be discussed",
      "action": false,
      "timestamp": "2016-11-03T19:32:04+00:00"
    },
    {
      "id": "cf3155f18de943599124227abc184172",
      "sender": "gmaxwell",
      "payload": "Not really much of a question for this meeting though, perhaps solicit input on the mailing list?",
      "action": false,
      "timestamp": "2016-11-03T19:32:30+00:00"
    },
    {
      "id": "cb43c43985cc4e8282bbbdc632b9fd49",
      "sender": "luke-jr",
      "payload": "I didn't realise v0.13.1 bumped the protocol version-number",
      "action": false,
      "timestamp": "2016-11-03T19:32:42+00:00"
    },
    {
      "id": "87e7fc95077b4fe89544a34eff68d6d5",
      "sender": "sdaftuar",
      "payload": "it didn't",
      "action": false,
      "timestamp": "2016-11-03T19:32:47+00:00"
    },
    {
      "id": "7e9cc70fd67e47e09c97e3c433685566",
      "sender": "luke-jr",
      "payload": "hmm, ok",
      "action": false,
      "timestamp": "2016-11-03T19:32:49+00:00"
    },
    {
      "id": "856f6a35036f4462b0cbb0dcb70dd00c",
      "sender": "morcos",
      "payload": "i don't think its realistic to think we're going to not want to make small tweaks to complicated BIP's like this after releasing implementations of it.  and it seems much clearer in the future to just edit the original bip to reflect the fully thought out final design",
      "action": false,
      "timestamp": "2016-11-03T19:33:10+00:00"
    },
    {
      "id": "dd78e5655592479d8c5e617b7463e1f9",
      "sender": "luke-jr",
      "payload": "sdaftuar: then how is it BIP 152 compatible iwth your change?",
      "action": false,
      "timestamp": "2016-11-03T19:33:14+00:00"
    },
    {
      "id": "1b092e3fc93446f3a383678d79458a62",
      "sender": "sdaftuar",
      "payload": "luke-jr: it imposes a restriction on code to not do something (which no one is currently doing) unless the recipient is at-or-above the bumped version number",
      "action": false,
      "timestamp": "2016-11-03T19:33:42+00:00"
    },
    {
      "id": "6e341a7ba4cf4ee9be7b496d73c823d6",
      "sender": "sdaftuar",
      "payload": "in this case, relay before full validation",
      "action": false,
      "timestamp": "2016-11-03T19:33:54+00:00"
    },
    {
      "id": "58ac4eacd8cf4b24a69b76a0e38f0f87",
      "sender": "gmaxwell",
      "payload": "luke-jr: for the specifics here, 0.13.1 is compatible with BIP152 because it implements a new version number that the original bip152 was just silent on.",
      "action": false,
      "timestamp": "2016-11-03T19:35:14+00:00"
    },
    {
      "id": "11322472489e404aaf9aa40b16859f2a",
      "sender": "luke-jr",
      "payload": "it says \"nodes SHOULD NOT ban a peer for announcing a new block with a CMPCTBLOCK message that is invalid, but has a valid header\" unconditionally, and says nodes should bump the version number",
      "action": false,
      "timestamp": "2016-11-03T19:35:30+00:00"
    },
    {
      "id": "1d077d79926142e9a349ddf43354b074",
      "sender": "BlueMatt",
      "payload": "oh, well that is a language mistake",
      "action": false,
      "timestamp": "2016-11-03T19:36:16+00:00"
    },
    {
      "id": "1b3b33241d72440399e922fc0179a191",
      "sender": "gmaxwell",
      "payload": "and BIP152 already explained how versions were to be handled in a compatible way.",
      "action": false,
      "timestamp": "2016-11-03T19:36:20+00:00"
    },
    {
      "id": "9a02dbb1dd454336b75556a74f8d91dd",
      "sender": "BlueMatt",
      "payload": "by that language, indeed, 0.13.1 violates a SHOULD NOT",
      "action": false,
      "timestamp": "2016-11-03T19:36:30+00:00"
    },
    {
      "id": "5cd54ff27f494ceb8f53931a74cfd9a4",
      "sender": "gmaxwell",
      "payload": "luke-jr: re banning it's just a bug that all prior versions have as well.",
      "action": false,
      "timestamp": "2016-11-03T19:36:43+00:00"
    },
    {
      "id": "3594164c34714e36a22b42750f8be7a9",
      "sender": "BlueMatt",
      "payload": "however, this wont effect functionality, as we're a) fixing this as if it were a bug, b) we say you SHOULD NOT announce without validation if the number is below",
      "action": false,
      "timestamp": "2016-11-03T19:37:14+00:00"
    },
    {
      "id": "69038b7bc2c8471f8b891af035a7246a",
      "sender": "luke-jr",
      "payload": "ok",
      "action": false,
      "timestamp": "2016-11-03T19:37:54+00:00"
    },
    {
      "id": "580c3567e71141daa3e7e335bcb7fe74",
      "sender": "luke-jr",
      "payload": "BlueMatt: with this change, as the author are you comfortable with a freeze to the BIP so we can move it forward to Final status?",
      "action": false,
      "timestamp": "2016-11-03T19:39:02+00:00"
    },
    {
      "id": "790b5bd70d544e4ca97e3a42afd6c45a",
      "sender": "gmaxwell",
      "payload": "is there a reason to rush?",
      "action": false,
      "timestamp": "2016-11-03T19:40:08+00:00"
    },
    {
      "id": "e25a0a5c13014c2b882efa80db4a5347",
      "sender": "wumpus",
      "payload": "is this about https://github.com/bitcoin/bitcoin/pull/9058? there was also talk of a protocol change there",
      "action": false,
      "timestamp": "2016-11-03T19:40:44+00:00"
    },
    {
      "id": "5be71f263af14458bbd2e8d6e2d737fb",
      "sender": "BlueMatt",
      "payload": "luke-jr: after https://github.com/bitcoin/bips/pull/469, yea, probably",
      "action": false,
      "timestamp": "2016-11-03T19:40:47+00:00"
    },
    {
      "id": "f69fd02501514e2893a4610a3c71526b",
      "sender": "BlueMatt",
      "payload": "but need to review tht",
      "action": false,
      "timestamp": "2016-11-03T19:40:51+00:00"
    },
    {
      "id": "8687a8c762ff475bb9f385b8b38b326e",
      "sender": "BlueMatt",
      "payload": "at",
      "action": false,
      "timestamp": "2016-11-03T19:40:52+00:00"
    },
    {
      "id": "51bd4af733b34e55bd67c50d7a97b350",
      "sender": "wumpus",
      "payload": "I thought it mentioned a BIP change, but doesn't seem to mention that anymore",
      "action": false,
      "timestamp": "2016-11-03T19:41:20+00:00"
    },
    {
      "id": "5bf337e6a78a4295b642a1beab76492b",
      "sender": "luke-jr",
      "payload": "BlueMatt: how will existing nodes react if they get a full block message there?",
      "action": false,
      "timestamp": "2016-11-03T19:41:22+00:00"
    },
    {
      "id": "c95d2bff637e4d83b67f17e45bbbf40a",
      "sender": "morcos",
      "payload": "i don't see why we should Finalize it at all until we've stopped changing it for 6-12 mos",
      "action": false,
      "timestamp": "2016-11-03T19:41:45+00:00"
    },
    {
      "id": "da073bc372ca4f67947e46f21e960390",
      "sender": "wumpus",
      "payload": "morcos: makes sense to not finalize too soon, it's unrealistic to expect a bip to come into being completely perfect",
      "action": false,
      "timestamp": "2016-11-03T19:42:28+00:00"
    },
    {
      "id": "abe4075038f442519dfa1c2b9461f079",
      "sender": "sipa",
      "payload": "i think it depends",
      "action": false,
      "timestamp": "2016-11-03T19:42:31+00:00"
    },
    {
      "id": "f837b98f075142c8b20ee79517061d33",
      "sender": "gmaxwell",
      "payload": "Agreed with Morcos. Though for things like consensus code, really being widely active on the network defines final.",
      "action": false,
      "timestamp": "2016-11-03T19:42:34+00:00"
    },
    {
      "id": "2cdff76472de41f88d30e8ad66f4a189",
      "sender": "sipa",
      "payload": "there shouldn't be material changes to ideas",
      "action": false,
      "timestamp": "2016-11-03T19:42:42+00:00"
    },
    {
      "id": "da88103f346447aba880d8851355b73d",
      "sender": "luke-jr",
      "payload": "no particular reason to rush, I guess, just feels like a moving goal for anyone who wanted to be compatible with it",
      "action": false,
      "timestamp": "2016-11-03T19:42:47+00:00"
    },
    {
      "id": "d55224af7a7c4d7ea92a16cfb8c3033e",
      "sender": "gmaxwell",
      "payload": "luke-jr: at least they are minor alterations.",
      "action": false,
      "timestamp": "2016-11-03T19:43:07+00:00"
    },
    {
      "id": "223554a045c040e78961b6a2ff00880b",
      "sender": "wumpus",
      "payload": "that's always the case. Others could also report problems encountered during implementing it",
      "action": false,
      "timestamp": "2016-11-03T19:43:09+00:00"
    },
    {
      "id": "cc6e7a081e864ff38c45516281eb9b90",
      "sender": "sipa",
      "payload": "but clarifications and elaborating on edge cases is something else",
      "action": false,
      "timestamp": "2016-11-03T19:43:13+00:00"
    },
    {
      "id": "beabb99528b941b0884b11910e8962d4",
      "sender": "morcos",
      "payload": "gmaxwell: heh, even there, its a matter of whether we are confident that we've really understood what the consensus is.   but yeah i agree it shoudl depend on the changes we want to make.",
      "action": false,
      "timestamp": "2016-11-03T19:43:22+00:00"
    },
    {
      "id": "e10949b4da5b4971aa0537bca85853d9",
      "sender": "luke-jr",
      "payload": "sipa: sure, we still make clarifications to Final BIPs even now I think",
      "action": false,
      "timestamp": "2016-11-03T19:43:26+00:00"
    },
    {
      "id": "d2925d8be1b140fa963a18af01ca341a",
      "sender": "BlueMatt",
      "payload": "luke-jr: agreed, it sucks that its still moving, but currently there are no other implementors (except XT, which I believe is still moving as well)",
      "action": false,
      "timestamp": "2016-11-03T19:43:29+00:00"
    },
    {
      "id": "0f6ce600493b4573bf85db2b9bd14904",
      "sender": "wumpus",
      "payload": "it could also move because of problems other implementors find",
      "action": false,
      "timestamp": "2016-11-03T19:43:53+00:00"
    },
    {
      "id": "de59c7c01a154552a0d0cc5992393816",
      "sender": "luke-jr",
      "payload": "since it's being used live on the network, changes also should probably address backwards compatibility, which they aren't in this case",
      "action": false,
      "timestamp": "2016-11-03T19:44:53+00:00"
    },
    {
      "id": "d3c44209d32e4624bc4f108a0281ccb1",
      "sender": "wumpus",
      "payload": "it's just unrealsitic to expect not even small issues in wording/clarity/definitions, although I guess if it is in a release there should not be substantial incompatible changes anymore",
      "action": false,
      "timestamp": "2016-11-03T19:45:05+00:00"
    },
    {
      "id": "9e75ad10990a4deaafec5557c7ec9cae",
      "sender": "gmaxwell",
      "payload": "morcos: so interesting point, say we discovered that BIP30 was implemented differently from the BIP tomorrow. What should we do?   IETF way would be to attach an erratum to the document right away. But I find that this often confuses people who manage to read the document without an erratum. Then later a new document is published that reflects reality.  Though this has a problem that people reme",
      "action": false,
      "timestamp": "2016-11-03T19:45:48+00:00"
    },
    {
      "id": "327da59b2e1845d1accb74608f7e901b",
      "sender": "gmaxwell",
      "payload": "mber the original number.",
      "action": false,
      "timestamp": "2016-11-03T19:45:48+00:00"
    },
    {
      "id": "c294a600b7884b21acb0d4f2f0e6884d",
      "sender": "gmaxwell",
      "payload": "If no one of consequence actually implemented BIP30 as specified in the doc, what use does keeping the old doc around (except in the git history) serve?",
      "action": false,
      "timestamp": "2016-11-03T19:45:48+00:00"
    },
    {
      "id": "9dba2f319f6a4ffd85831c5df4ebe443",
      "sender": "wumpus",
      "payload": "yes, those at least will need to address backwards compatibilty",
      "action": false,
      "timestamp": "2016-11-03T19:45:48+00:00"
    },
    {
      "id": "024d9c8d215b43c1b72ca3d90e806939",
      "sender": "luke-jr",
      "payload": "gmaxwell: I *think* we've fixed such issues in Final BIPs already",
      "action": false,
      "timestamp": "2016-11-03T19:46:28+00:00"
    },
    {
      "id": "be6b1410e8a14e8188d92bf591714ec8",
      "sender": "BlueMatt",
      "payload": "gmaxwell: we're not plaintext, lets highlight it in red! :p",
      "action": false,
      "timestamp": "2016-11-03T19:46:45+00:00"
    },
    {
      "id": "89e378cc36534577b83d06391bbf3f35",
      "sender": "luke-jr",
      "payload": ">_<",
      "action": false,
      "timestamp": "2016-11-03T19:46:51+00:00"
    },
    {
      "id": "0e70be6542964544a6c0c7954569bdfb",
      "sender": "morcos",
      "payload": "yes, BIP 34 for example",
      "action": false,
      "timestamp": "2016-11-03T19:46:53+00:00"
    },
    {
      "id": "c3be0423b6d64a8c907e2fba77d2dc69",
      "sender": "morcos",
      "payload": "ehh, i guess that was just wrong explanation",
      "action": false,
      "timestamp": "2016-11-03T19:47:34+00:00"
    },
    {
      "id": "887f035772b540658418139eed42073d",
      "sender": "luke-jr",
      "payload": "BIP 16",
      "action": false,
      "timestamp": "2016-11-03T19:47:50+00:00"
    },
    {
      "id": "5ce8ec63d273426ebbb544dfbc06cee5",
      "sender": "luke-jr",
      "payload": "https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size",
      "action": false,
      "timestamp": "2016-11-03T19:48:01+00:00"
    },
    {
      "id": "adb13607ac0a4b418f662a3c909337ab",
      "sender": "gribble",
      "payload": "https://github.com/bitcoin/bitcoin/issues/520 | log low-level network messages only when fDebug is set by tcatm \u00c3\u0082\u00c2\u00b7 Pull Request #520 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
      "action": false,
      "timestamp": "2016-11-03T19:48:02+00:00"
    },
    {
      "id": "d756d97e00774e30aceec99b13e1456d",
      "sender": "gmaxwell",
      "payload": "BlueMatt: the erratum link on the ietf website is red, https://tools.ietf.org/html/rfc6716",
      "action": false,
      "timestamp": "2016-11-03T19:48:03+00:00"
    },
    {
      "id": "a1b9360868b1496ab7f20b6a113e6413",
      "sender": "luke-jr",
      "payload": "looks at gribble",
      "action": true,
      "timestamp": "2016-11-03T19:48:35+00:00"
    },
    {
      "id": "1669a1349e0b44ff82b9ecab2637ca8c",
      "sender": "gmaxwell",
      "payload": "I warned about that!",
      "action": false,
      "timestamp": "2016-11-03T19:49:20+00:00"
    },
    {
      "id": "d559115053ea4b0891c4a0edb15e7c9b",
      "sender": "gmaxwell",
      "payload": "In any case, I still think that the BIP discussion belongs elsewhere. :)",
      "action": false,
      "timestamp": "2016-11-03T19:49:56+00:00"
    },
    {
      "id": "139bcc4c1cbb4995b43daec4711dd1be",
      "sender": "morcos",
      "payload": "well you come up with something else to talk about for 11 more minutes then!",
      "action": false,
      "timestamp": "2016-11-03T19:50:47+00:00"
    },
    {
      "id": "d37aea6a6cf5489caa4de07fe353aba6",
      "sender": "gmaxwell",
      "payload": "wumpus: sipa: thanks for merging lots of stuff!",
      "action": false,
      "timestamp": "2016-11-03T19:51:03+00:00"
    },
    {
      "id": "153b78beca8843a6837e175b0adcfb2d",
      "sender": "BlueMatt",
      "payload": "<3",
      "action": false,
      "timestamp": "2016-11-03T19:51:12+00:00"
    },
    {
      "id": "c2f0a509480a4263b29305740cb81190",
      "sender": "sdaftuar",
      "payload": "+1",
      "action": false,
      "timestamp": "2016-11-03T19:51:13+00:00"
    },
    {
      "id": "100e5bdfe93f4f4e84254a0762b9cadd",
      "sender": "wumpus",
      "payload": "I think there was some pull where we wondered whether to backport to 0.13.2",
      "action": false,
      "timestamp": "2016-11-03T19:51:16+00:00"
    },
    {
      "id": "1b103b74417e4c0fba1c8210400a70ee",
      "sender": "wumpus",
      "payload": "np :)",
      "action": false,
      "timestamp": "2016-11-03T19:51:27+00:00"
    },
    {
      "id": "81c1f8ca4eda4161b437fc1be8ead80f",
      "sender": "BlueMatt",
      "payload": "making 0.14 great again!",
      "action": false,
      "timestamp": "2016-11-03T19:51:48+00:00"
    },
    {
      "id": "11cfedcde7594f8387cfb912e95b00eb",
      "sender": "wumpus",
      "payload": "https://github.com/bitcoin/bitcoin/pull/9053",
      "action": false,
      "timestamp": "2016-11-03T19:51:50+00:00"
    },
    {
      "id": "13249c8a3a974d348b7796e152b2a789",
      "sender": "jtimon",
      "payload": "topic potential backports to 0.13.2 ?",
      "action": false,
      "timestamp": "2016-11-03T19:51:56+00:00"
    },
    {
      "id": "524186f190584ee2a064af677b21ab33",
      "sender": "wumpus",
      "payload": "I don't think there's time enough to discuss all potential backports to 0.13.2, but that one would do",
      "action": false,
      "timestamp": "2016-11-03T19:52:38+00:00"
    },
    {
      "id": "846ceea47947474c9cd6470fb2f23126",
      "sender": "gmaxwell",
      "payload": "I think it would be harmless to backport, and helpful for testnet nodes.  But I don't have a strong opinion.",
      "action": false,
      "timestamp": "2016-11-03T19:53:18+00:00"
    },
    {
      "id": "aff4d41ff95346489001d85efe7d1199",
      "sender": "gmaxwell",
      "payload": "oh I see sipa mentioned testnet.",
      "action": false,
      "timestamp": "2016-11-03T19:53:23+00:00"
    },
    {
      "id": "7eaaf3dfa38e4e52bde259c51f580152",
      "sender": "wumpus",
      "payload": "so I guess in practice it fixes testnet issues only on 0.13.2, so the question would be is that worth it to potential regressions?",
      "action": false,
      "timestamp": "2016-11-03T19:54:14+00:00"
    },
    {
      "id": "c7ffd094678f4562be11a7f3c0068617",
      "sender": "sdaftuar",
      "payload": "it's not that much of a fix for testnet right, it just allows you to reorg out the non-segwit chain?",
      "action": false,
      "timestamp": "2016-11-03T19:54:41+00:00"
    },
    {
      "id": "388a007064ac454c8bd5275f0c02e781",
      "sender": "gmaxwell",
      "payload": "it does actually fix a misbehavior that we see on testnet. <famous last words>I can't see it causing a regression.</famous last words>",
      "action": false,
      "timestamp": "2016-11-03T19:55:09+00:00"
    },
    {
      "id": "e4255048bfc24931b0f9f548c414bd18",
      "sender": "gmaxwell",
      "payload": "sdaftuar: because of the 20 minute rule in general it's very easy to get testnet nodes into a state where they just stop mining. Trivial vulnerablity, the active issue is that the non-segwit chain there unintentionally triggers it from time to time.",
      "action": false,
      "timestamp": "2016-11-03T19:55:50+00:00"
    },
    {
      "id": "74468b46023541eeb4086e68df27fd7c",
      "sender": "gmaxwell",
      "payload": "('stop mining' is ambigious, they won't mine after they're restarted)",
      "action": false,
      "timestamp": "2016-11-03T19:56:16+00:00"
    },
    {
      "id": "653c9f9832de45aa9e8c050e89f8b129",
      "sender": "sdaftuar",
      "payload": "fwiw i have a few bridges of my own back up now that i hope will keep that from happening again",
      "action": false,
      "timestamp": "2016-11-03T19:56:48+00:00"
    },
    {
      "id": "2fa292a42e1c4460bc7ad0577f973a05",
      "sender": "sdaftuar",
      "payload": "can you elaborate on the 20 minute rule though?",
      "action": false,
      "timestamp": "2016-11-03T19:56:58+00:00"
    },
    {
      "id": "7058dfb3d36e4124b922000fd8576804",
      "sender": "sdaftuar",
      "payload": "oh",
      "action": false,
      "timestamp": "2016-11-03T19:57:08+00:00"
    },
    {
      "id": "d95ee0a48def453c85dfacdaf702f021",
      "sender": "wumpus",
      "payload": "I think personally I'd prefer to keep it for 0.14, so the new rule/logic can prove itself a while",
      "action": false,
      "timestamp": "2016-11-03T19:57:23+00:00"
    },
    {
      "id": "8e35a8727f6f4377b77809e09ee5800b",
      "sender": "gmaxwell",
      "payload": "sdaftuar: the issue is that if anyone produces a lot of headers beyond your current tip which you accept (made computationally easy by the diff1 blocks) then you'll not leave IBD.",
      "action": false,
      "timestamp": "2016-11-03T19:57:44+00:00"
    },
    {
      "id": "9d157330672f43beac540c0d4e7a7707",
      "sender": "sdaftuar",
      "payload": "got it",
      "action": false,
      "timestamp": "2016-11-03T19:58:29+00:00"
    },
    {
      "id": "cdcb2960e5d547b9b4986e61c8dfafbd",
      "sender": "gmaxwell",
      "payload": "sdaftuar: the non-segwit chain does this by accident through a confluence of other behaviors (the not fetching blocks from non-witness peers). But the real bug is just using forward header count to cause you to not leave ibd.",
      "action": false,
      "timestamp": "2016-11-03T19:58:40+00:00"
    },
    {
      "id": "fbb28a3a1de84a1eba01fbead77789d5",
      "sender": "gmaxwell",
      "payload": "which that PR fixes.",
      "action": false,
      "timestamp": "2016-11-03T19:58:49+00:00"
    },
    {
      "id": "56a234b23bfa4efe925edc17dc7c3f7c",
      "sender": "sipa",
      "payload": "wumpus: ok, we can of course later decide to backport to whatever 0.13.x at that time",
      "action": false,
      "timestamp": "2016-11-03T19:58:58+00:00"
    },
    {
      "id": "a73eea381d63483d901973e6346c6a19",
      "sender": "wumpus",
      "payload": "sipa: yes",
      "action": false,
      "timestamp": "2016-11-03T19:59:07+00:00"
    },
    {
      "id": "af47a5906282470c82e2ba1def13b976",
      "sender": "gmaxwell",
      "payload": "sounds fine to me.",
      "action": false,
      "timestamp": "2016-11-03T19:59:16+00:00"
    },
    {
      "id": "4704f03b01ce4fc4a9f72c4c3308d2ea",
      "sender": "wumpus",
      "payload": "that doesn't prohibit backporting it later",
      "action": false,
      "timestamp": "2016-11-03T19:59:19+00:00"
    },
    {
      "id": "0dbef2f3803f4de69c13bf2fa8fb253c",
      "sender": "gmaxwell",
      "payload": "because of the latching in IBD this code is pretty robust against mistbehavior to begin with.",
      "action": false,
      "timestamp": "2016-11-03T19:59:36+00:00"
    },
    {
      "id": "e58fd6fb838748b692f97620ee5a4890",
      "sender": "sipa",
      "payload": "$-+(#(_+$+ PC LOAD LETTER",
      "action": false,
      "timestamp": "2016-11-03T20:00:05+00:00"
    },
    {
      "id": "00fcf778c46f446bb4db5ce5de7ca291",
      "sender": "wumpus",
      "payload": "#endmeeting",
      "action": false,
      "timestamp": "2016-11-03T20:00:22+00:00"
    }
  ],
  "events": [
    {
      "event_type": "START_MEETING",
      "message": {
        "id": "64ed64bc8f8b420ba9b829f81421a875",
        "sender": "wumpus",
        "payload": "#startmeeting",
        "action": false,
        "timestamp": "2016-11-03T19:00:39+00:00"
      },
      "operand": null,
      "id": "64ed64bc8f8b420ba9b829f81421a875",
      "timestamp": "2016-11-03T19:00:39+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "0871c060abed450bad9a1bab8d1195cf",
        "sender": "wumpus",
        "payload": "#topic block header/fetch logic",
        "action": false,
        "timestamp": "2016-11-03T19:04:50+00:00"
      },
      "operand": "block header/fetch logic",
      "id": "0871c060abed450bad9a1bab8d1195cf",
      "timestamp": "2016-11-03T19:04:50+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "2ecb98735ef943ec8169f4bff41365ac",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/9068 | Timeout for headers fetch \u00c3\u0082\u00c2\u00b7 Issue #9068 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2016-11-03T19:23:15+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/9068",
      "id": "2ecb98735ef943ec8169f4bff41365ac",
      "timestamp": "2016-11-03T19:23:15+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "c911a40e5a594fed80329b87529e7ee2",
        "sender": "wumpus",
        "payload": "#topic BIP 152 changes",
        "action": false,
        "timestamp": "2016-11-03T19:28:59+00:00"
      },
      "operand": "BIP 152 changes",
      "id": "c911a40e5a594fed80329b87529e7ee2",
      "timestamp": "2016-11-03T19:28:59+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "3a8e162962154f0db786726e666c7e61",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/9026 | Fix handling of invalid compact blocks by sdaftuar \u00c3\u0082\u00c2\u00b7 Pull Request #9026 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2016-11-03T19:29:57+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/9026",
      "id": "3a8e162962154f0db786726e666c7e61",
      "timestamp": "2016-11-03T19:29:57+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "5ce8ec63d273426ebbb544dfbc06cee5",
        "sender": "luke-jr",
        "payload": "https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size",
        "action": false,
        "timestamp": "2016-11-03T19:48:01+00:00"
      },
      "operand": "https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size",
      "id": "5ce8ec63d273426ebbb544dfbc06cee5",
      "timestamp": "2016-11-03T19:48:01+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "adb13607ac0a4b418f662a3c909337ab",
        "sender": "gribble",
        "payload": "https://github.com/bitcoin/bitcoin/issues/520 | log low-level network messages only when fDebug is set by tcatm \u00c3\u0082\u00c2\u00b7 Pull Request #520 \u00c3\u0082\u00c2\u00b7 bitcoin/bitcoin \u00c3\u0082\u00c2\u00b7 GitHub",
        "action": false,
        "timestamp": "2016-11-03T19:48:02+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/issues/520",
      "id": "adb13607ac0a4b418f662a3c909337ab",
      "timestamp": "2016-11-03T19:48:02+00:00"
    },
    {
      "event_type": "LINK",
      "message": {
        "id": "11cfedcde7594f8387cfb912e95b00eb",
        "sender": "wumpus",
        "payload": "https://github.com/bitcoin/bitcoin/pull/9053",
        "action": false,
        "timestamp": "2016-11-03T19:51:50+00:00"
      },
      "operand": "https://github.com/bitcoin/bitcoin/pull/9053",
      "id": "11cfedcde7594f8387cfb912e95b00eb",
      "timestamp": "2016-11-03T19:51:50+00:00"
    },
    {
      "event_type": "END_MEETING",
      "message": {
        "id": "00fcf778c46f446bb4db5ce5de7ca291",
        "sender": "wumpus",
        "payload": "#endmeeting",
        "action": false,
        "timestamp": "2016-11-03T20:00:22+00:00"
      },
      "operand": null,
      "id": "00fcf778c46f446bb4db5ce5de7ca291",
      "timestamp": "2016-11-03T20:00:22+00:00"
    }
  ],
  "aliases": {},
  "vote_in_progress": false,
  "motion_index": null
}