{
  "founder": "wumpus",
  "channel": "#bitcoin-core-dev",
  "network": "freenode",
  "id": "6b4a29e0d5804244b94fc1db9ebcad9b",
  "name": "#bitcoin-core-dev",
  "chair": "wumpus",
  "chairs": [
    "wumpus"
  ],
  "nicks": {
    "wumpus": 85,
    "lightningbot": 2,
    "BakSAj": 1,
    "CodeShark": 11,
    "MarcoFalke": 2,
    "btcdrak": 2,
    "cfields_": 1,
    "kanzure": 1,
    "jonasschnelli": 35,
    "petertodd": 48,
    "sipa": 74,
    "luke-jr": 16,
    "gmaxwell": 71,
    "morcos": 8,
    "sdaftuar": 2,
    "Chris_Stewart_5": 3,
    "achow101": 9,
    "jl2012_": 1,
    "michagogo": 1
  },
  "start_time": "2016-09-29T19:01:19+00:00",
  "end_time": "2016-09-29T20:00:15+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": "segwit against uncompressed keys or not",
  "messages": [
    {
      "id": "881f2e08c0004e07bfd91273f34d55ac",
      "sender": "wumpus",
      "payload": "#startmeeting",
      "action": false,
      "timestamp": "2016-09-29T19:01:19+00:00"
    },
    {
      "id": "8d42fc5ed24b45a48fa555d4421bb3bb",
      "sender": "lightningbot",
      "payload": "Meeting started Thu Sep 29 19:01:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.",
      "action": false,
      "timestamp": "2016-09-29T19:01:19+00:00"
    },
    {
      "id": "62f64b43770e43ba96188f498c3440c8",
      "sender": "lightningbot",
      "payload": "Useful Commands: #action #agreed #help #info #idea #link #topic.",
      "action": false,
      "timestamp": "2016-09-29T19:01:19+00:00"
    },
    {
      "id": "6bf372fbbca34f7d94d0173eff799098",
      "sender": "BakSAj",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-09-29T19:01:26+00:00"
    },
    {
      "id": "b00c2ad06af649ccbde5378b6474a5d0",
      "sender": "CodeShark",
      "payload": "meeting time!",
      "action": false,
      "timestamp": "2016-09-29T19:01:36+00:00"
    },
    {
      "id": "5c5dde1c86624b72a28fb7f14246b28f",
      "sender": "MarcoFalke",
      "payload": "meeting!",
      "action": false,
      "timestamp": "2016-09-29T19:01:46+00:00"
    },
    {
      "id": "2a472da37cd64487bbff3724a23fdfea",
      "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",
      "action": false,
      "timestamp": "2016-09-29T19:01:56+00:00"
    },
    {
      "id": "2a7ef5293d1d4a9bbfa0197eb6eb1786",
      "sender": "MarcoFalke",
      "payload": "(oh already started)",
      "action": false,
      "timestamp": "2016-09-29T19:02:04+00:00"
    },
    {
      "id": "8c4a86e452f447369b7928356c05b784",
      "sender": "btcdrak",
      "payload": "here",
      "action": false,
      "timestamp": "2016-09-29T19:02:07+00:00"
    },
    {
      "id": "f63f9bb9b3c7449a8c35e0f63bebc864",
      "sender": "cfields_",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-09-29T19:02:07+00:00"
    },
    {
      "id": "9b8c28af8a4945caa552cb08be4f3d7b",
      "sender": "kanzure",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-09-29T19:02:12+00:00"
    },
    {
      "id": "471f1569f02a47fa8ca734055b336348",
      "sender": "wumpus",
      "payload": "any proposed topics?",
      "action": false,
      "timestamp": "2016-09-29T19:02:20+00:00"
    },
    {
      "id": "073833d0448c4a928da3345305867f7a",
      "sender": "jonasschnelli",
      "payload": "topic proposal: pruning and blockrelay",
      "action": false,
      "timestamp": "2016-09-29T19:02:24+00:00"
    },
    {
      "id": "864aad403bd347f49623b649bc65b214",
      "sender": "petertodd",
      "payload": "hi",
      "action": false,
      "timestamp": "2016-09-29T19:02:56+00:00"
    },
    {
      "id": "27c27d4e55aa4a1b830d1d4a2438c0b7",
      "sender": "sipa",
      "payload": "policy against uncompressed keys or not",
      "action": false,
      "timestamp": "2016-09-29T19:03:11+00:00"
    },
    {
      "id": "44974a989acf41a0b2d56ff3d0b04472",
      "sender": "wumpus",
      "payload": "#topic pruning and blockrelay",
      "action": false,
      "timestamp": "2016-09-29T19:03:11+00:00"
    },
    {
      "id": "ebe4be5ab8da4295b69793e7e69a3bd6",
      "sender": "jonasschnelli",
      "payload": "I think we should add a service flag for block relay with a min-height",
      "action": false,
      "timestamp": "2016-09-29T19:03:38+00:00"
    },
    {
      "id": "7b17aeeac545403187559665f3739a5b",
      "sender": "jonasschnelli",
      "payload": "NODE_PRUNENETWORK or something",
      "action": false,
      "timestamp": "2016-09-29T19:03:52+00:00"
    },
    {
      "id": "9692477d0a524cb299c81faff486ce8e",
      "sender": "sipa",
      "payload": "there have been multiple ideas around that",
      "action": false,
      "timestamp": "2016-09-29T19:03:57+00:00"
    },
    {
      "id": "db24c896e22540a5be324dae4c418cfd",
      "sender": "petertodd",
      "payload": "IMO whatever we do, we should recognise that w/ segwit's larger blocks we can expect a lot of full nodes to run out of disk space quite soon",
      "action": false,
      "timestamp": "2016-09-29T19:04:35+00:00"
    },
    {
      "id": "3059dc283c5140f7bda555c276404f47",
      "sender": "sipa",
      "payload": "the easiest is just to add a flag that says you relay valid blocks and transactions, but not historical blocks more than a few deep",
      "action": false,
      "timestamp": "2016-09-29T19:04:35+00:00"
    },
    {
      "id": "370f894fedaa4b1a98bbb6f20d8b07d7",
      "sender": "jonasschnelli",
      "payload": "I guess people slowly start to prune the blockchain to a max of 80GB or similar... but I guess not everyone is aware of the fact that you don't relay then",
      "action": false,
      "timestamp": "2016-09-29T19:04:35+00:00"
    },
    {
      "id": "592dd38d51104e47b817be354ee9cfd1",
      "sender": "wumpus",
      "payload": "it would be nice to support more than one range, e.g. also archive nodes that host part of the old blocks",
      "action": false,
      "timestamp": "2016-09-29T19:04:36+00:00"
    },
    {
      "id": "f166ecd7f87a4fff96729320dd495be4",
      "sender": "sipa",
      "payload": "it becomes harder when you want multiple ranger",
      "action": false,
      "timestamp": "2016-09-29T19:04:49+00:00"
    },
    {
      "id": "0feac3b90fae4d6fb65788af88663db7",
      "sender": "petertodd",
      "payload": "do we have a reason for more than one range?",
      "action": false,
      "timestamp": "2016-09-29T19:04:57+00:00"
    },
    {
      "id": "c9d287ddacb84fd6ba94454ab78342b1",
      "sender": "jonasschnelli",
      "payload": "We could introduce another message type... blockrange  or so",
      "action": false,
      "timestamp": "2016-09-29T19:05:00+00:00"
    },
    {
      "id": "6b9c929a38af4a74bf6899edb89bbc08",
      "sender": "sipa",
      "payload": "it becomes even harder when you want to support sharding in an efficient way",
      "action": false,
      "timestamp": "2016-09-29T19:05:01+00:00"
    },
    {
      "id": "d16396bade614daaa3547b688b09186f",
      "sender": "wumpus",
      "payload": "I'm not sure why itb ecomes hard, just add a query message that returns what ranges are supported",
      "action": false,
      "timestamp": "2016-09-29T19:05:08+00:00"
    },
    {
      "id": "be94c648000c441da74bc38cc7fb773c",
      "sender": "petertodd",
      "payload": "sipa: what do you mean by sharding exactly?",
      "action": false,
      "timestamp": "2016-09-29T19:05:11+00:00"
    },
    {
      "id": "b380291a2a3d43dbbc4ae1065736e520",
      "sender": "sipa",
      "payload": "petertodd: you'd configure your node to maintain a certain % of blocks",
      "action": false,
      "timestamp": "2016-09-29T19:05:25+00:00"
    },
    {
      "id": "57fb99e085ae49b2906c670c2320027f",
      "sender": "jonasschnelli",
      "payload": "wumpus: query, yes, why not, or just inform like we do with sendheaders",
      "action": false,
      "timestamp": "2016-09-29T19:05:45+00:00"
    },
    {
      "id": "80dd97eaebe14547922c06d6cb06652b",
      "sender": "petertodd",
      "payload": "sipa: see, given that the bitcoin protocol can't be safely sharded right now, I think we can safely say that we don't need to support sharding in block relay yet",
      "action": false,
      "timestamp": "2016-09-29T19:05:47+00:00"
    },
    {
      "id": "9600247fcd8a42a6a8c3762c3907781a",
      "sender": "petertodd",
      "payload": "sipa: doing so might even be dangerous if people start using it",
      "action": false,
      "timestamp": "2016-09-29T19:05:55+00:00"
    },
    {
      "id": "138a181e31a346549e51b211dbd1812a",
      "sender": "sipa",
      "payload": "petertodd: not in block relay",
      "action": false,
      "timestamp": "2016-09-29T19:06:04+00:00"
    },
    {
      "id": "066134c94ed04daf8e19875feb2127df",
      "sender": "sipa",
      "payload": "petertodd: for block archival",
      "action": false,
      "timestamp": "2016-09-29T19:06:08+00:00"
    },
    {
      "id": "95da17b41d024e51856d33874af3caa5",
      "sender": "petertodd",
      "payload": "sipa: but why shard vs. keep ranges?",
      "action": false,
      "timestamp": "2016-09-29T19:06:16+00:00"
    },
    {
      "id": "916561f36f1541f48525f77aa9aee1af",
      "sender": "petertodd",
      "payload": "sipa: (ranges of full blocks)",
      "action": false,
      "timestamp": "2016-09-29T19:06:23+00:00"
    },
    {
      "id": "926a2d62b2044db8b50797b133daa62f",
      "sender": "luke-jr",
      "payload": "BitTorrent already does this. Surely we can learn from that?",
      "action": false,
      "timestamp": "2016-09-29T19:06:25+00:00"
    },
    {
      "id": "3a727359275d46df9892a74ed3189d7d",
      "sender": "petertodd",
      "payload": "luke-jr: I don't think so - bittorrent is a very different problem than bitcoin",
      "action": false,
      "timestamp": "2016-09-29T19:06:38+00:00"
    },
    {
      "id": "4c1cfe2e55b54a9fb2cf27321b921135",
      "sender": "wumpus",
      "payload": "this is for letting other peers know what ranges of blocks are hosted, I don't think this should affect releay",
      "action": false,
      "timestamp": "2016-09-29T19:06:38+00:00"
    },
    {
      "id": "c05685edef7e471bb64d6222651b6527",
      "sender": "sipa",
      "payload": "so, i've been running statistics on what block depths are being requested from nodes",
      "action": false,
      "timestamp": "2016-09-29T19:06:41+00:00"
    },
    {
      "id": "fe8a79ad44c94da0a9c6f7070bfd3700",
      "sender": "luke-jr",
      "payload": "petertodd: learn from it, not use it directly",
      "action": false,
      "timestamp": "2016-09-29T19:06:47+00:00"
    },
    {
      "id": "94fd028972244f969f1a3cff77cf1a3c",
      "sender": "luke-jr",
      "payload": "petertodd: BitTorrent's problem isn't very different from IBD",
      "action": false,
      "timestamp": "2016-09-29T19:07:01+00:00"
    },
    {
      "id": "b2d3a883f56d44d49ca8218696e3b2bd",
      "sender": "jonasschnelli",
      "payload": "sipa: interesting.. do you have the stats public available somewhere",
      "action": false,
      "timestamp": "2016-09-29T19:07:08+00:00"
    },
    {
      "id": "00670f8a9b134d1886fd72c1cb53eb2c",
      "sender": "jonasschnelli",
      "payload": "I wanted to do this a long time",
      "action": false,
      "timestamp": "2016-09-29T19:07:16+00:00"
    },
    {
      "id": "138d8bbc33584f6abb9f692c23455cd7",
      "sender": "petertodd",
      "payload": "luke-jr: so, the thing is bittorrent has the problem of a diverse set of files, we just don't have that problem and can optimise differently because everyone needs access t othe same set of data",
      "action": false,
      "timestamp": "2016-09-29T19:07:20+00:00"
    },
    {
      "id": "3af0c36a2b5e4a75b373d1239b2d1810",
      "sender": "sipa",
      "payload": "there are something like 4 meaningful 'ranges' 1) the top 2 blocks (just relay) 2) up to ~2500 blocks deep... requested very often 3) up to ~10000 deep... requested a few times more than the next range 4) the rest",
      "action": false,
      "timestamp": "2016-09-29T19:08:03+00:00"
    },
    {
      "id": "ecf7a7ca3a1f4351940a28d246839f94",
      "sender": "wumpus",
      "payload": "otoh bittorrent has a fixed block size :)",
      "action": false,
      "timestamp": "2016-09-29T19:08:15+00:00"
    },
    {
      "id": "f3c80466c1794cdaa028c5b66c38fbc4",
      "sender": "sipa",
      "payload": "wumpus: so do we *ducks*",
      "action": false,
      "timestamp": "2016-09-29T19:08:22+00:00"
    },
    {
      "id": "9bc2c142f8f0424585d7609c37618456",
      "sender": "petertodd",
      "payload": "sipa: that probably corresponds to how long people leave their nodes offline :)",
      "action": false,
      "timestamp": "2016-09-29T19:08:38+00:00"
    },
    {
      "id": "7f5c531be3254307825883b071e3c332",
      "sender": "btcdrak",
      "payload": "inb4 Bittorrent XT",
      "action": false,
      "timestamp": "2016-09-29T19:08:51+00:00"
    },
    {
      "id": "a34ea814337e45a79bd209dd3a1a5d96",
      "sender": "sipa",
      "payload": "jonasschnelli: they're not available, and the ranges i gave above are just from me quickly glancing over the result",
      "action": false,
      "timestamp": "2016-09-29T19:09:04+00:00"
    },
    {
      "id": "a0a4ae30e10f4f68a221d25321828ff8",
      "sender": "petertodd",
      "payload": "btcdrak: I use Bittorrent Unlimited myself",
      "action": false,
      "timestamp": "2016-09-29T19:09:04+00:00"
    },
    {
      "id": "e8af8f1e82254f6c816bbb782b613229",
      "sender": "jonasschnelli",
      "payload": "What about fingerprinting issued in conjunction with available ranges?",
      "action": false,
      "timestamp": "2016-09-29T19:09:05+00:00"
    },
    {
      "id": "850665086e5b4c10a7b6330983139325",
      "sender": "jonasschnelli",
      "payload": "*issues",
      "action": false,
      "timestamp": "2016-09-29T19:09:16+00:00"
    },
    {
      "id": "1a19d0a084e940af8c1251d12d415082",
      "sender": "petertodd",
      "payload": "jonasschnelli: make them powers of two?",
      "action": false,
      "timestamp": "2016-09-29T19:09:20+00:00"
    },
    {
      "id": "7984dea7613248099a10bf0f6891aeac",
      "sender": "sipa",
      "payload": "well 4 ranges can be done with 2 service bit flags",
      "action": false,
      "timestamp": "2016-09-29T19:09:33+00:00"
    },
    {
      "id": "66ffafdb75584c988c5c048824e40160",
      "sender": "sipa",
      "payload": "gmaxwell: you've worked on these ideas before, comments?",
      "action": false,
      "timestamp": "2016-09-29T19:09:45+00:00"
    },
    {
      "id": "1bbbe05d6cfd43f1836ed035b3593738",
      "sender": "jonasschnelli",
      "payload": "But would that work with the flexible pruning option based on MB?",
      "action": false,
      "timestamp": "2016-09-29T19:09:47+00:00"
    },
    {
      "id": "90e277040e9c4135804044147c6a20fc",
      "sender": "petertodd",
      "payload": "jonasschnelli: sure, just find the biggest range less than the pruning amount",
      "action": false,
      "timestamp": "2016-09-29T19:10:05+00:00"
    },
    {
      "id": "ee224d85beda4bf890cbbf7666d6cf98",
      "sender": "sipa",
      "payload": "jonasschnelli: you'd change your service bits on the fly",
      "action": false,
      "timestamp": "2016-09-29T19:10:12+00:00"
    },
    {
      "id": "bef33a5809994111b14f845f97b5330a",
      "sender": "wumpus",
      "payload": "why would the ranges need to be in the flags?",
      "action": false,
      "timestamp": "2016-09-29T19:10:20+00:00"
    },
    {
      "id": "47a2b35aaab24442ba2ac21caa8e1628",
      "sender": "gmaxwell",
      "payload": "sorry, I missed that the meeting started.",
      "action": false,
      "timestamp": "2016-09-29T19:10:30+00:00"
    },
    {
      "id": "8c288ede096249e783dc565ae62f0312",
      "sender": "jonasschnelli",
      "payload": "Yes. Why? Better add an explicit message for the range",
      "action": false,
      "timestamp": "2016-09-29T19:10:32+00:00"
    },
    {
      "id": "9be0406f03a846c9a98017e96243ea1a",
      "sender": "sipa",
      "payload": "how would you otherwise discover what nodes to connect to?",
      "action": false,
      "timestamp": "2016-09-29T19:10:34+00:00"
    },
    {
      "id": "3e6ce1baa6d54f6da2a78878096bc2f9",
      "sender": "sipa",
      "payload": "just randomly try?",
      "action": false,
      "timestamp": "2016-09-29T19:10:45+00:00"
    },
    {
      "id": "8dc9fa7637464513ab500ec9b5afee20",
      "sender": "petertodd",
      "payload": "jonasschnelli: oh right, you mean if MB != blocks... sorry.",
      "action": false,
      "timestamp": "2016-09-29T19:10:45+00:00"
    },
    {
      "id": "d7d26c02a794474e910b499fa34cc996",
      "sender": "wumpus",
      "payload": "I think you'll need a service flag to show support for the protocol, but not what ranges you have",
      "action": false,
      "timestamp": "2016-09-29T19:10:49+00:00"
    },
    {
      "id": "c3ed3c6d37cd434da59cf90a64e29d4f",
      "sender": "jonasschnelli",
      "payload": "query or inform the other node if proto-ver > NODE_PRUNENETWORK",
      "action": false,
      "timestamp": "2016-09-29T19:10:52+00:00"
    },
    {
      "id": "eafac1af3249462b9defa681d79a09d3",
      "sender": "wumpus",
      "payload": "well that can be negotiated later, like bittorrent does I guess",
      "action": false,
      "timestamp": "2016-09-29T19:11:00+00:00"
    },
    {
      "id": "99c6fc9ab5c2400f85d425d4f927f30e",
      "sender": "sipa",
      "payload": "wumpus: well you do want addr messages to contain this information",
      "action": false,
      "timestamp": "2016-09-29T19:11:08+00:00"
    },
    {
      "id": "13e73a87381f4524b5b271fe0402aeb3",
      "sender": "wumpus",
      "payload": "I doubt bitcoin has 'service flags' in its tracker what blocks nodes have",
      "action": false,
      "timestamp": "2016-09-29T19:11:18+00:00"
    },
    {
      "id": "43faa72f4f2647bd9415a3ff8c92d6fb",
      "sender": "petertodd",
      "payload": "sipa: so the nice thing about bitcoin, is just randomly try will probably work fairly often due to the low number of ranges out there",
      "action": false,
      "timestamp": "2016-09-29T19:11:18+00:00"
    },
    {
      "id": "e335323c840d4465abda372de9e1a2f4",
      "sender": "wumpus",
      "payload": "as that changes all the time anyhow",
      "action": false,
      "timestamp": "2016-09-29T19:11:26+00:00"
    },
    {
      "id": "492f8f6f390f4f52a11697ba0a89762d",
      "sender": "gmaxwell",
      "payload": "I was strongly of the view that we needed to signal at least two ranges. Sipa's latest measurements make me think at least three are needed.",
      "action": false,
      "timestamp": "2016-09-29T19:11:29+00:00"
    },
    {
      "id": "704ccbdde1ab4a3189cd5e4298ec4c43",
      "sender": "wumpus",
      "payload": "s/bitcoin/bittorrent/",
      "action": false,
      "timestamp": "2016-09-29T19:11:31+00:00"
    },
    {
      "id": "fd992337168d4da4afeaf654a07e5276",
      "sender": "jonasschnelli",
      "payload": "I think informing other nodes ranges over addr is another thing...",
      "action": false,
      "timestamp": "2016-09-29T19:11:37+00:00"
    },
    {
      "id": "6353bdd40d224f10bdf81604ff582697",
      "sender": "jonasschnelli",
      "payload": "A first step would be a information after connect",
      "action": false,
      "timestamp": "2016-09-29T19:11:46+00:00"
    },
    {
      "id": "33f53ff20d5f4da1bd264dc02a91c4cf",
      "sender": "wumpus",
      "payload": "yes, addr is another thing",
      "action": false,
      "timestamp": "2016-09-29T19:11:55+00:00"
    },
    {
      "id": "fa085d8b58e64b958d0b227f4c613ad7",
      "sender": "gmaxwell",
      "payload": "I think ranges in service bits are no big deal, the harder question is what to do about the history. having nodes with 150GB of history in order to serve the last range is not very viable.",
      "action": false,
      "timestamp": "2016-09-29T19:12:22+00:00"
    },
    {
      "id": "4ac3fa81f80f4aa29295644c31a5063a",
      "sender": "wumpus",
      "payload": "could be done later if an efficient way is needed to *locate* peers with certain ranges",
      "action": false,
      "timestamp": "2016-09-29T19:12:23+00:00"
    },
    {
      "id": "ba792af0929249fb935cbe8faef62121",
      "sender": "wumpus",
      "payload": "but that seems premature optimization",
      "action": false,
      "timestamp": "2016-09-29T19:12:31+00:00"
    },
    {
      "id": "4e70b20d832946c2b46ff2db0a0f5d57",
      "sender": "gmaxwell",
      "payload": "We will need to redo addr sometime relatively soon in any case, as our messages are not compatible with HS-NG.",
      "action": false,
      "timestamp": "2016-09-29T19:12:36+00:00"
    },
    {
      "id": "81419af267c6425ca18e05772ebb1c48",
      "sender": "petertodd",
      "payload": "gmaxwell: oh, you mean Tor's new hidden services standard right?",
      "action": false,
      "timestamp": "2016-09-29T19:12:52+00:00"
    },
    {
      "id": "bb0840c6d1ea403497060238d41f50fd",
      "sender": "gmaxwell",
      "payload": "petertodd: yes.",
      "action": false,
      "timestamp": "2016-09-29T19:12:56+00:00"
    },
    {
      "id": "8cb8c64063ca4a80b2105d013e630644",
      "sender": "gmaxwell",
      "payload": "(also I2P though thats not new)",
      "action": false,
      "timestamp": "2016-09-29T19:13:02+00:00"
    },
    {
      "id": "4a3270ccc03542dd9fcd842d2f23d680",
      "sender": "wumpus",
      "payload": "I think the number of ranges should be variable",
      "action": false,
      "timestamp": "2016-09-29T19:13:18+00:00"
    },
    {
      "id": "0e4be2f803004cd58446e9583b9fb079",
      "sender": "wumpus",
      "payload": "redesigning addr is a different topic",
      "action": false,
      "timestamp": "2016-09-29T19:13:24+00:00"
    },
    {
      "id": "737a5d8ec1f744c59964d6a3fee4900f",
      "sender": "wumpus",
      "payload": "also necessary, but again, doesn't need to be on one heap",
      "action": false,
      "timestamp": "2016-09-29T19:13:35+00:00"
    },
    {
      "id": "9be7c25d41d4464caa97de8d6bddcea9",
      "sender": "gmaxwell",
      "payload": "wumpus: when I'm saying ranges I am specifically referring to the top-N zomes.",
      "action": false,
      "timestamp": "2016-09-29T19:13:45+00:00"
    },
    {
      "id": "41e80bddba2f47b8a12cff56ba5ed8a0",
      "sender": "petertodd",
      "payload": "well, so if we add service bits for recent history ranges, that should be possible to implement as a separate feature to archival history ranges, and it'd be a big first step",
      "action": false,
      "timestamp": "2016-09-29T19:14:14+00:00"
    },
    {
      "id": "e8d9b57f3f704284a75b6afb52c7d313",
      "sender": "wumpus",
      "payload": "I think it should be possible to, say, only host the first 20GB of blocks",
      "action": false,
      "timestamp": "2016-09-29T19:14:22+00:00"
    },
    {
      "id": "7fb48ab987614df3b78bd0c6a1337e65",
      "sender": "jonasschnelli",
      "payload": "historic only nodes",
      "action": false,
      "timestamp": "2016-09-29T19:14:37+00:00"
    },
    {
      "id": "c7a247c1288e4cceb59e89fd08bf87ed",
      "sender": "wumpus",
      "payload": "I don't see why it should be restricted to only recent history",
      "action": false,
      "timestamp": "2016-09-29T19:14:37+00:00"
    },
    {
      "id": "54adb1fbf424475b8610e7c50afb88fa",
      "sender": "petertodd",
      "payload": "I don't think it's likely we'll see the two different features collide, so maybe implement recent history ranges first",
      "action": false,
      "timestamp": "2016-09-29T19:14:38+00:00"
    },
    {
      "id": "446579a9f218464ba8713ca67238f00f",
      "sender": "wumpus",
      "payload": "or I mean first 20GB + last 144 blocks",
      "action": false,
      "timestamp": "2016-09-29T19:14:55+00:00"
    },
    {
      "id": "42258c788e1941629a7c10487041a111",
      "sender": "gmaxwell",
      "payload": "For history storage, I was previously working on a proposal where nodes could signal a small (32 bit) seed and a size and from that everyone would know what parts of the history they would store.  I was so far unable to unify two different schemes, one which was computationally efficient to figure out who had what, and one which never required a peer to fetch a block it had previously deleted.",
      "action": false,
      "timestamp": "2016-09-29T19:15:07+00:00"
    },
    {
      "id": "63b6f736baec44178fc58aca67684b1d",
      "sender": "sipa",
      "payload": "so very quick breakdown: out of 7M requested blocks, 100k were for the tip, range 2-2500 has around 200-2000 requests per block, and from 10000 to genesis deep there are around 20 per block",
      "action": false,
      "timestamp": "2016-09-29T19:15:15+00:00"
    },
    {
      "id": "9ca0c5c57e9e4205af6410872f1d6421",
      "sender": "gmaxwell",
      "payload": "I think for now we should not worry about the old history part and only worry about Top-n vs everything, as that fits into the pruning we already have and can be accomplished purely with service bits.",
      "action": false,
      "timestamp": "2016-09-29T19:16:19+00:00"
    },
    {
      "id": "ff962b34faf24ed0903b945e3a5d250e",
      "sender": "wumpus",
      "payload": "the bittorrent problem is different in that there the goal of each node is to have everything",
      "action": false,
      "timestamp": "2016-09-29T19:16:22+00:00"
    },
    {
      "id": "54ec54d31d524acda324e50c5c80aebe",
      "sender": "petertodd",
      "payload": "so a social consideration here, is we can think in terms of recent history as \"if there's a flaw, how much would we ever reorg w/o just saying bitcoin has failed?\"",
      "action": false,
      "timestamp": "2016-09-29T19:16:25+00:00"
    },
    {
      "id": "07491de3ffb74ab6995bc0a576c91614",
      "sender": "gmaxwell",
      "payload": "petertodd: thats partly why we have the 288 block maximum amount of pruning.",
      "action": false,
      "timestamp": "2016-09-29T19:16:44+00:00"
    },
    {
      "id": "398bbc3b6a3d4c2e884c7d69fd9c25f6",
      "sender": "petertodd",
      "payload": "gmaxwell: indeed, and that's only two days...",
      "action": false,
      "timestamp": "2016-09-29T19:17:13+00:00"
    },
    {
      "id": "3f7137e4a0494c5295dc8c7f60894f41",
      "sender": "jonasschnelli",
      "payload": "Using multiple service bits for 4 ranges seems to be a hackish-design IMO",
      "action": false,
      "timestamp": "2016-09-29T19:17:36+00:00"
    },
    {
      "id": "dfd871675eb0414a9e4196b9778fd9b8",
      "sender": "gmaxwell",
      "payload": "at 100 blocks any reorg will _necessarily_ cause unrecoverable losses. So 288 basically gives a day plus an extra day for overhead.",
      "action": false,
      "timestamp": "2016-09-29T19:17:49+00:00"
    },
    {
      "id": "5f0ea3349bd04f3e9d62b1e5d9ba3e38",
      "sender": "petertodd",
      "payload": "there's also a natural time criteria from how the difficulty adjustments reduce your resistance to 51% attack - if your node is offline longer, the minimum attacker size to fool you goes down",
      "action": false,
      "timestamp": "2016-09-29T19:17:50+00:00"
    },
    {
      "id": "04af21ffb17347f4a2fedb88b9118ee5",
      "sender": "sipa",
      "payload": "strangely enough: i see much more requests around 1000 deep than around 100 deep",
      "action": false,
      "timestamp": "2016-09-29T19:17:52+00:00"
    },
    {
      "id": "2078755dfa1647e184ee5f4ce7586d41",
      "sender": "gmaxwell",
      "payload": "jonasschnelli: I don't see anything hackish.",
      "action": false,
      "timestamp": "2016-09-29T19:18:04+00:00"
    },
    {
      "id": "bea049938540442f8017ec28d5d6a32d",
      "sender": "wumpus",
      "payload": "jonasschnelli: I also think it's a strange use of service bits",
      "action": false,
      "timestamp": "2016-09-29T19:18:05+00:00"
    },
    {
      "id": "8583adf6a84149ef8367998c7442066e",
      "sender": "jonasschnelli",
      "payload": "I'd prefere using a single service bit to state pruned blockchain and then a new message (or append something to version?)",
      "action": false,
      "timestamp": "2016-09-29T19:18:07+00:00"
    },
    {
      "id": "b265ac4fde664a45878bccc8386f3a31",
      "sender": "petertodd",
      "payload": "sipa: probably because people don't turn their nodes on and off every day",
      "action": false,
      "timestamp": "2016-09-29T19:18:24+00:00"
    },
    {
      "id": "f67845f2349242db82905d15fd3f898f",
      "sender": "gmaxwell",
      "payload": "sipa: you probably want to filter out the bitnodes spider, as I believe it requests a block to check the node is working.",
      "action": false,
      "timestamp": "2016-09-29T19:18:25+00:00"
    },
    {
      "id": "667dad1cde534cbb9ddf7d32b2283dd1",
      "sender": "sipa",
      "payload": "gmaxwell: ah.",
      "action": false,
      "timestamp": "2016-09-29T19:18:35+00:00"
    },
    {
      "id": "3e4aa1c0ccb649a299b939069e1d71cc",
      "sender": "gmaxwell",
      "payload": "petertodd: someone who hasn't turned their node on will request all of 0 to -1000. so it will not make 1000 greater.",
      "action": false,
      "timestamp": "2016-09-29T19:18:53+00:00"
    },
    {
      "id": "fd78671956dd479694cd0c974c82cf76",
      "sender": "gmaxwell",
      "payload": "jonasschnelli: NAK.",
      "action": false,
      "timestamp": "2016-09-29T19:19:07+00:00"
    },
    {
      "id": "1c952ab157fc4224b87dba529fc51275",
      "sender": "petertodd",
      "payload": "gmaxwell: oh! I didn't know we did that",
      "action": false,
      "timestamp": "2016-09-29T19:19:07+00:00"
    },
    {
      "id": "5a872d71fb294e3da240e1901e2886e4",
      "sender": "sipa",
      "payload": "i'm a bit surprised people think there is no need to have the available block ranges indicated in addr messages",
      "action": false,
      "timestamp": "2016-09-29T19:19:09+00:00"
    },
    {
      "id": "cd6387b2b8e94977931607320ace3d01",
      "sender": "sipa",
      "payload": "(whether through service bits, or some extension)",
      "action": false,
      "timestamp": "2016-09-29T19:19:30+00:00"
    },
    {
      "id": "ad3b62b5dc164670b9e57201503845ce",
      "sender": "jonasschnelli",
      "payload": "I think there is a need... but it could be a second step",
      "action": false,
      "timestamp": "2016-09-29T19:19:30+00:00"
    },
    {
      "id": "cea4b6cc5ae24b4eaf4aabfa00cffd66",
      "sender": "wumpus",
      "payload": "jonasschnelli: appending to version should be unnecessary, that's also a hack :)",
      "action": false,
      "timestamp": "2016-09-29T19:19:38+00:00"
    },
    {
      "id": "d37cf3bf3af54872a87f5699fe32b82c",
      "sender": "sipa",
      "payload": "jonasschnelli: if it's a second step, we need to extend addr, and the whole management of addresses",
      "action": false,
      "timestamp": "2016-09-29T19:19:50+00:00"
    },
    {
      "id": "310d3383bbd349a3aa9c95857bd508d0",
      "sender": "jonasschnelli",
      "payload": "Okay. Agree. What about a new message type?",
      "action": false,
      "timestamp": "2016-09-29T19:19:51+00:00"
    },
    {
      "id": "689288b7bf2c49828fcb7c600e410844",
      "sender": "jonasschnelli",
      "payload": "blockrange",
      "action": false,
      "timestamp": "2016-09-29T19:19:55+00:00"
    },
    {
      "id": "ff2f862a329e45b087c623eea0297d9f",
      "sender": "sipa",
      "payload": "jonasschnelli: you don't understand.",
      "action": false,
      "timestamp": "2016-09-29T19:19:58+00:00"
    },
    {
      "id": "42754cd85c614a56a75f9de7ceca4c61",
      "sender": "gmaxwell",
      "payload": "jonasschnelli: look at pieter's request figures, if nodes are effectively forced to go to peers that have everything whenever they connect becuase if they don't know they'll be able to fetch any blocks at all, then it will put lots more load on them.. causing people to stop offering blocks... causing more pressure on what remains.",
      "action": false,
      "timestamp": "2016-09-29T19:20:18+00:00"
    },
    {
      "id": "76e13dd0812144579bb77e49b6ab2914",
      "sender": "sipa",
      "payload": "jonasschnelli: the point of having it in service bits is so nodes can find peers that have the range they need",
      "action": false,
      "timestamp": "2016-09-29T19:20:56+00:00"
    },
    {
      "id": "2d06c3bd73424d989ed9994cd7d5e8ee",
      "sender": "wumpus",
      "payload": "but addr information gets old really fast",
      "action": false,
      "timestamp": "2016-09-29T19:20:58+00:00"
    },
    {
      "id": "279b3774e3c04865921e56217cb0acd6",
      "sender": "sipa",
      "payload": "wumpus: much less so with feeler connections",
      "action": false,
      "timestamp": "2016-09-29T19:21:17+00:00"
    },
    {
      "id": "5b0a5eed99fa4cf587dc5b7d2a26dee5",
      "sender": "wumpus",
      "payload": "nodes may dynamically change what blocks they have, so there will always be cases of nodes connecting and realizing they have nothing to offer each other",
      "action": false,
      "timestamp": "2016-09-29T19:21:26+00:00"
    },
    {
      "id": "72aae92b3b3a439c884b304318295c53",
      "sender": "jonasschnelli",
      "payload": "Okay. I see the point.",
      "action": false,
      "timestamp": "2016-09-29T19:21:27+00:00"
    },
    {
      "id": "a3d782c4621a41e7ae0b582b237c52dc",
      "sender": "sipa",
      "payload": "(presumably, i don't have numbers)",
      "action": false,
      "timestamp": "2016-09-29T19:21:29+00:00"
    },
    {
      "id": "a9938ea43129464caf347dd2a6027fab",
      "sender": "wumpus",
      "payload": "just like currently nodes will try to connect into black holes that no longer host a node",
      "action": false,
      "timestamp": "2016-09-29T19:21:54+00:00"
    },
    {
      "id": "4149cfcd391c40508072ce37ba8927bc",
      "sender": "petertodd",
      "payload": "so another interesting thing here is that ranges are queried linearly - you download blocks in a roughly linear fashion - so we could take advantage of that by making sure that nodes with one range keep track of nodes with adjacent ranges",
      "action": false,
      "timestamp": "2016-09-29T19:22:24+00:00"
    },
    {
      "id": "8917b857c956464e9c15a4dc2a51f885",
      "sender": "wumpus",
      "payload": "sipa: sure, feeler connections make it somewhat better",
      "action": false,
      "timestamp": "2016-09-29T19:22:29+00:00"
    },
    {
      "id": "623fc85aada045ecb0cba7d33de4ba72",
      "sender": "gmaxwell",
      "payload": "wumpus: yes, sometimes the data is wrong. But there is a big difference between having 80% of the nodes on the network giving you no idea if they'll be useful at all until after you connect, vs a suggestion that might sometimes be wrong.",
      "action": false,
      "timestamp": "2016-09-29T19:22:35+00:00"
    },
    {
      "id": "55f0a1bbd27d43a9b33a927bc1c427f7",
      "sender": "wumpus",
      "payload": "but I don't think addr is a very up-to-date information source",
      "action": false,
      "timestamp": "2016-09-29T19:22:41+00:00"
    },
    {
      "id": "bd4e942876074d3f918d183936d2f2a9",
      "sender": "petertodd",
      "payload": "thus, as you sync the first time, ask nodes with the range you're syncing at this moment for the next range you need",
      "action": false,
      "timestamp": "2016-09-29T19:22:46+00:00"
    },
    {
      "id": "445f32cedaf541228ebb35a3d64921d0",
      "sender": "luke-jr",
      "payload": "wumpus: if ranges are deterministic, they don't need to be up to date",
      "action": false,
      "timestamp": "2016-09-29T19:23:08+00:00"
    },
    {
      "id": "6a8294e487424418b22e2bba10f4938e",
      "sender": "sipa",
      "payload": "petertodd: yes, any sharding plan wouldn't randomly distribute the kept blocks, but keep randomly distributed ranges",
      "action": false,
      "timestamp": "2016-09-29T19:23:15+00:00"
    },
    {
      "id": "dc713d36064b4b299d62691c09551a77",
      "sender": "gmaxwell",
      "payload": "wumpus: I don't know if you realize that sipa and I are not thinking in terms of absolute ranges here. but nodes saying \"I keep the last 288\" or \"I keep the last 2016\" or \"I have all of history\".",
      "action": false,
      "timestamp": "2016-09-29T19:23:32+00:00"
    },
    {
      "id": "62fbccc25529435690b4b86ad19006f1",
      "sender": "wumpus",
      "payload": "gmaxwell: but indeed this is a different problem from the bittorrent problem where everyone's goal is to have everything",
      "action": false,
      "timestamp": "2016-09-29T19:23:38+00:00"
    },
    {
      "id": "3249a22de00744f0b683bc0342886de9",
      "sender": "sipa",
      "payload": "gmaxwell: well that's sharding... maybe that is something to postpone for later",
      "action": false,
      "timestamp": "2016-09-29T19:23:56+00:00"
    },
    {
      "id": "cd84aec7760341efaa70c95e071cf123",
      "sender": "petertodd",
      "payload": "sipa: sure, I'm more talking about how the linearity affects the network p2p design - prefentially peering with peers with the adjacent range may even be a reasonable design",
      "action": false,
      "timestamp": "2016-09-29T19:24:01+00:00"
    },
    {
      "id": "a11cf74ffbba4c7c8ae988d88d651d9c",
      "sender": "luke-jr",
      "payload": "wumpus: eh, everyone needs to get everything",
      "action": false,
      "timestamp": "2016-09-29T19:24:03+00:00"
    },
    {
      "id": "1f35288089344a2c8211b6ed2a50127e",
      "sender": "wumpus",
      "payload": "there, nodes can just connect randomly and have a high change the other nodes has something to offer them",
      "action": false,
      "timestamp": "2016-09-29T19:24:03+00:00"
    },
    {
      "id": "4aa81d61ab20414fafd17abe09fa065a",
      "sender": "gmaxwell",
      "payload": "wumpus: and I wouldn't expect that data to go out of date fast.. pretty much only when nodes go up and down.",
      "action": false,
      "timestamp": "2016-09-29T19:24:04+00:00"
    },
    {
      "id": "2a079d2b97974e9fbb0cd373c51e4e26",
      "sender": "sipa",
      "payload": "oh, nvm, i'm misreading",
      "action": false,
      "timestamp": "2016-09-29T19:24:04+00:00"
    },
    {
      "id": "60669702250c46b59141338ea22ce15d",
      "sender": "wumpus",
      "payload": "luke-jr: only initially",
      "action": false,
      "timestamp": "2016-09-29T19:24:20+00:00"
    },
    {
      "id": "f321653f1dd546e89aa5cbf4f328a0b8",
      "sender": "luke-jr",
      "payload": "oh, I see the distinction",
      "action": false,
      "timestamp": "2016-09-29T19:24:28+00:00"
    },
    {
      "id": "a10def38eb6e4a67a383ceebc968d231",
      "sender": "wumpus",
      "payload": "luke-jr: bittorrent nodes don't throw away blocks, generally",
      "action": false,
      "timestamp": "2016-09-29T19:24:41+00:00"
    },
    {
      "id": "15dd0f6b5d1645e7b9fc358fea61bdca",
      "sender": "luke-jr",
      "payload": "f(best-height, seed-in-addr) -> ranges",
      "action": false,
      "timestamp": "2016-09-29T19:24:53+00:00"
    },
    {
      "id": "25e9e2c337f14e01883fda4c3f23ad81",
      "sender": "gmaxwell",
      "payload": "for the spreading the history around, as mentioned I came up with concrete schemes (based on consistent hashes) that have nice properties.",
      "action": false,
      "timestamp": "2016-09-29T19:25:12+00:00"
    },
    {
      "id": "7888ac3790454f53b6af21a53e92fe9c",
      "sender": "sipa",
      "payload": "i wonder whether we need to have that in the first go at this",
      "action": false,
      "timestamp": "2016-09-29T19:25:30+00:00"
    },
    {
      "id": "bdaa0fbd013548928a470bc798771b36",
      "sender": "jonasschnelli",
      "payload": "I think a first simple solution that allow to extend it further would be appriciated.",
      "action": false,
      "timestamp": "2016-09-29T19:26:04+00:00"
    },
    {
      "id": "6c069854ddc84b8580dff8c29da20d50",
      "sender": "sipa",
      "payload": "even just having serve-everything and server-the-last-288-and-relay-at-tip would be a good addition",
      "action": false,
      "timestamp": "2016-09-29T19:26:10+00:00"
    },
    {
      "id": "a60c55b228a84ea8a5543e38cc56ee6d",
      "sender": "wumpus",
      "payload": "making the ranges deterministic makes some sense, on the other hand, it does restrict the flexibilty of nodes to choose what ranges they host, it means everything has to be got right in first try",
      "action": false,
      "timestamp": "2016-09-29T19:26:15+00:00"
    },
    {
      "id": "abfa1a3e5a8d4cfbaf9bb88f9b5648c0",
      "sender": "gmaxwell",
      "payload": "sipa: thats what I am saying.",
      "action": false,
      "timestamp": "2016-09-29T19:26:23+00:00"
    },
    {
      "id": "8f2581ca738d419fb6fd5ade00d06d00",
      "sender": "jonasschnelli",
      "payload": "sipa: agree",
      "action": false,
      "timestamp": "2016-09-29T19:26:27+00:00"
    },
    {
      "id": "147a24277b964ef48ec79479b2d42447",
      "sender": "gmaxwell",
      "payload": "I do not think we can do better immediately anyways.",
      "action": false,
      "timestamp": "2016-09-29T19:26:30+00:00"
    },
    {
      "id": "1110518a069f4a12a7ed979e5d6d4349",
      "sender": "sipa",
      "payload": "21:18:07 < jonasschnelli> I'd prefere using a single service bit to state pruned blockchain and then a new message (or append something to version?)",
      "action": false,
      "timestamp": "2016-09-29T19:26:45+00:00"
    },
    {
      "id": "8f9cc43cee6c4e5986493e13e3b4e895",
      "sender": "gmaxwell",
      "payload": "sipa: though your latest figures suggest that the 2016 depth is important too.",
      "action": false,
      "timestamp": "2016-09-29T19:26:47+00:00"
    },
    {
      "id": "86f7af62e17c4dc19b60947d6cf1ea12",
      "sender": "sipa",
      "payload": "21:19:07 < gmaxwell> jonasschnelli: NAK.",
      "action": false,
      "timestamp": "2016-09-29T19:26:48+00:00"
    },
    {
      "id": "dc73985ed07c4a2bacb28f3e33203f43",
      "sender": "petertodd",
      "payload": "if nodes attempt to maintain a few connections to peers that have the next range after they have, maybe it doesn't matter exactly what the ranges actually are? any given node would have a few connections to the next range, and anyone syncing from them could ask for those connections",
      "action": false,
      "timestamp": "2016-09-29T19:27:10+00:00"
    },
    {
      "id": "1e974cc719584013997ea917004ed90c",
      "sender": "gmaxwell",
      "payload": "sipa: my understanding of jonasschnelli comment was there should be a bit that says \"I relay blocks but don't have history\" I am NAK on that.",
      "action": false,
      "timestamp": "2016-09-29T19:27:15+00:00"
    },
    {
      "id": "c44345c808f24900be1fa3312d07cd04",
      "sender": "wumpus",
      "payload": "as there is no scope for later optimization, because all nodes have to agree what ranges are implied",
      "action": false,
      "timestamp": "2016-09-29T19:27:36+00:00"
    },
    {
      "id": "8fd03fdcb37d4ef0a1e2ee6d19dc8629",
      "sender": "jonasschnelli",
      "payload": "We could add a service bit that says \"I relay only the last 288 blocks\"",
      "action": false,
      "timestamp": "2016-09-29T19:27:40+00:00"
    },
    {
      "id": "f6510d5e8a1f4dfbabf6bf55e5788495",
      "sender": "wumpus",
      "payload": "jannes: yes that would be the initial idea",
      "action": false,
      "timestamp": "2016-09-29T19:27:50+00:00"
    },
    {
      "id": "656b6d5e53894f989485b31d76aac63e",
      "sender": "wumpus",
      "payload": "jonasschnelli*",
      "action": false,
      "timestamp": "2016-09-29T19:27:54+00:00"
    },
    {
      "id": "9e72f41c3edc45be9fc4a8587ac3b346",
      "sender": "sipa",
      "payload": "gmaxwell: how is that different from what i suggested?",
      "action": false,
      "timestamp": "2016-09-29T19:28:08+00:00"
    },
    {
      "id": "d0a6baf01add4ce08f8117770c19da60",
      "sender": "sipa",
      "payload": "21:26:10 < sipa> even just having serve-everything and server-the-last-288-and-relay-at-tip would be a good addition",
      "action": false,
      "timestamp": "2016-09-29T19:28:11+00:00"
    },
    {
      "id": "1c137cda144144eca98f9c78f5d05a13",
      "sender": "jonasschnelli",
      "payload": "I think my initial idea with the general pruning sevice bit and a new message type is to complex and inflexible",
      "action": false,
      "timestamp": "2016-09-29T19:28:21+00:00"
    },
    {
      "id": "0f7071993c454bf3a13fdc138d55a2ac",
      "sender": "gmaxwell",
      "payload": "jonasschnelli: yes, that would be better, though pieter's data suggests that there are a LOT of requests at 1000. I think if I had that data I would have been suggesting the maximum pruning should be 2016, and then had the bit at that dep.",
      "action": false,
      "timestamp": "2016-09-29T19:28:28+00:00"
    },
    {
      "id": "3cb176bc63754ebfaf4ee28af07e2d50",
      "sender": "gmaxwell",
      "payload": "sipa: the ability to relay blocks at depth -10.",
      "action": false,
      "timestamp": "2016-09-29T19:28:50+00:00"
    },
    {
      "id": "8f58163cb22840b280b2f577718705d3",
      "sender": "sipa",
      "payload": "gmaxwell: less than 2% of blocks requested from my node are at the tip",
      "action": false,
      "timestamp": "2016-09-29T19:29:04+00:00"
    },
    {
      "id": "c40d0235e28a46a587b0b45f425a5d90",
      "sender": "sipa",
      "payload": "(but the tip is still 100x more frequent than any other individual depth)",
      "action": false,
      "timestamp": "2016-09-29T19:29:22+00:00"
    },
    {
      "id": "774b9ffd2715431faf1f3477d1267be0",
      "sender": "sipa",
      "payload": "gmaxwell: \"a service bit to indicate pruned blockchain\" implies you can serve 288 deep :)",
      "action": false,
      "timestamp": "2016-09-29T19:29:50+00:00"
    },
    {
      "id": "175e8572cbaa4272b58b20c9f7282e36",
      "sender": "petertodd",
      "payload": "gmaxwell: re: maximum pruning depth, it's reasonable for that to be a similar % of the total data that storing the UTXO set takes - if you have 10GB of UTXO, 2GB of block data isn't a big change",
      "action": false,
      "timestamp": "2016-09-29T19:30:08+00:00"
    },
    {
      "id": "261836467d844e47a10a2511eb086b63",
      "sender": "wumpus",
      "payload": "yes, you could define it as that",
      "action": false,
      "timestamp": "2016-09-29T19:30:11+00:00"
    },
    {
      "id": "491a124bec60427796694acc94ab0ca6",
      "sender": "gmaxwell",
      "payload": "I don't think there is any remaining disagreement on using bit(s) to signal I have a top-n.  But I have some doubt on N. it needs to capture the largest amount of the block realy bandwidth without being unduely pruning incompatible.",
      "action": false,
      "timestamp": "2016-09-29T19:30:15+00:00"
    },
    {
      "id": "142af92dbbe94d368de10f1c7a2bb894",
      "sender": "wumpus",
      "payload": "288 is the minimum pruning amount in bitcoin core already so it'd be a valid choice",
      "action": false,
      "timestamp": "2016-09-29T19:30:37+00:00"
    },
    {
      "id": "18936b8fdbab4b229fe20ef1655246b4",
      "sender": "morcos",
      "payload": "as a first pass, i wonder if you preferentially downloaded from pruned peers whenever you were behind by less than 288 blocks, that would take enough load of peers serving full history?",
      "action": false,
      "timestamp": "2016-09-29T19:30:44+00:00"
    },
    {
      "id": "c5f69feb56c749e5a01a98a04c893738",
      "sender": "gmaxwell",
      "payload": "morcos: absolutely.",
      "action": false,
      "timestamp": "2016-09-29T19:30:50+00:00"
    },
    {
      "id": "86cbb8a761c14f7fbd757e761a485b37",
      "sender": "jonasschnelli",
      "payload": "Good idea",
      "action": false,
      "timestamp": "2016-09-29T19:31:01+00:00"
    },
    {
      "id": "f37bb3bc6923493cb04216e20570a9e7",
      "sender": "wumpus",
      "payload": "yes, that would make sense",
      "action": false,
      "timestamp": "2016-09-29T19:31:09+00:00"
    },
    {
      "id": "ef4e441c4c0b4d10b158c77e5fc39b2e",
      "sender": "gmaxwell",
      "payload": "unfortunately, sipa's data suggests that 288 sheds less traffic than measurements years ago suggested.",
      "action": false,
      "timestamp": "2016-09-29T19:31:23+00:00"
    },
    {
      "id": "39551802ee6740699cc7bf4c3a52c00e",
      "sender": "sipa",
      "payload": "maybe i should compute statistics in bytes rather than blocks",
      "action": false,
      "timestamp": "2016-09-29T19:31:43+00:00"
    },
    {
      "id": "560a2cdaf23640e7a6f43282a766a7e9",
      "sender": "morcos",
      "payload": "gmaxwell: it wasn't clear to me what the integral from 1 to 288 was compared to 288 to inf",
      "action": false,
      "timestamp": "2016-09-29T19:31:45+00:00"
    },
    {
      "id": "d10a05fcda4a43bd8c91f73ff2f405e4",
      "sender": "wumpus",
      "payload": "well it is a compromise",
      "action": false,
      "timestamp": "2016-09-29T19:31:46+00:00"
    },
    {
      "id": "f3b81715318f4ff1952778a5442c3b2a",
      "sender": "wumpus",
      "payload": "putting the threshold higher makes some peers completely useless",
      "action": false,
      "timestamp": "2016-09-29T19:31:53+00:00"
    },
    {
      "id": "6b7cccd72964443aac24a5d8fd79a1e0",
      "sender": "sipa",
      "payload": "to see what percentage of bandwidth is needed in 1-288",
      "action": false,
      "timestamp": "2016-09-29T19:31:57+00:00"
    },
    {
      "id": "10902d76506b4f98a3b6a4ddeb4e2385",
      "sender": "wumpus",
      "payload": "which reduces morcos 's argument",
      "action": false,
      "timestamp": "2016-09-29T19:31:58+00:00"
    },
    {
      "id": "f9c367a299f44c6fae6102a3a5a3f957",
      "sender": "jonasschnelli",
      "payload": "Yes. I guess you convinced me to use two service bits then. -288 and -2016",
      "action": false,
      "timestamp": "2016-09-29T19:32:04+00:00"
    },
    {
      "id": "f002faa830d141b7ac73dd6749b05685",
      "sender": "gmaxwell",
      "payload": "which is why it might be useful to use two bits and be able to signal 1-288, 1-2016... and perhaps start encouraging people to not prune shorter than 2016.",
      "action": false,
      "timestamp": "2016-09-29T19:32:16+00:00"
    },
    {
      "id": "1b4983ab21f240f9acbd7697b60de8fc",
      "sender": "sipa",
      "payload": "i think we're getting into a design discussion here",
      "action": false,
      "timestamp": "2016-09-29T19:32:37+00:00"
    },
    {
      "id": "0e6302c49a1045a0974807c40d4fe003",
      "sender": "sipa",
      "payload": "my number are very premature and not well analysed",
      "action": false,
      "timestamp": "2016-09-29T19:32:47+00:00"
    },
    {
      "id": "b978f60345094ef4868932e79bcfeb92",
      "sender": "wumpus",
      "payload": "it'd also be possible to add a 288-flag now, and then consider a 2016 flag later",
      "action": false,
      "timestamp": "2016-09-29T19:32:50+00:00"
    },
    {
      "id": "107c12e079c04d0ea115290ac6075796",
      "sender": "gmaxwell",
      "payload": "sipa: indeed, thought that was the input you requested from me.",
      "action": false,
      "timestamp": "2016-09-29T19:32:54+00:00"
    },
    {
      "id": "89976c438fc14a38b9bbd7e155fb2f96",
      "sender": "morcos",
      "payload": "wumpus: yes, thats what i'm saying",
      "action": false,
      "timestamp": "2016-09-29T19:32:57+00:00"
    },
    {
      "id": "621cd4af5514495085806ee0abf39f45",
      "sender": "gmaxwell",
      "payload": "wumpus: yes! indeed.",
      "action": false,
      "timestamp": "2016-09-29T19:32:59+00:00"
    },
    {
      "id": "c5a3fe2d69324ce6bf98d8e24746b108",
      "sender": "jonasschnelli",
      "payload": "Agree with wumpus",
      "action": false,
      "timestamp": "2016-09-29T19:33:03+00:00"
    },
    {
      "id": "6c9574bb738f44fd885e3eb26963c6fc",
      "sender": "wumpus",
      "payload": "if it turns out to be necessary",
      "action": false,
      "timestamp": "2016-09-29T19:33:04+00:00"
    },
    {
      "id": "607ba281a32f4b76a9ab4d305e5a8607",
      "sender": "petertodd",
      "payload": "wumpus: ACK",
      "action": false,
      "timestamp": "2016-09-29T19:33:10+00:00"
    },
    {
      "id": "200d00b9d8744a43817d7a25add019a2",
      "sender": "sipa",
      "payload": "yes, i think just a 1-288 one seems useful",
      "action": false,
      "timestamp": "2016-09-29T19:33:15+00:00"
    },
    {
      "id": "a0513c08bb324dd5aec1873866993ca2",
      "sender": "wumpus",
      "payload": "good :)",
      "action": false,
      "timestamp": "2016-09-29T19:33:16+00:00"
    },
    {
      "id": "53c3b8d5eda441d3ae075135576e3c54",
      "sender": "jonasschnelli",
      "payload": "Start with a simple tip-288 relay, and get some experience",
      "action": false,
      "timestamp": "2016-09-29T19:33:16+00:00"
    },
    {
      "id": "c831097025ab46c3a3c2957aace10bf4",
      "sender": "gmaxwell",
      "payload": "wumpus: it looks pretty clearly necessary but no need to do everything at once.",
      "action": false,
      "timestamp": "2016-09-29T19:33:23+00:00"
    },
    {
      "id": "41a96666e89f42e7ab67fe9bb98b5efb",
      "sender": "petertodd",
      "payload": "wumpus: basically advice is, turn your node on at least once every two days",
      "action": false,
      "timestamp": "2016-09-29T19:33:30+00:00"
    },
    {
      "id": "e0cd879a24d043839197f5dd9ecfff48",
      "sender": "wumpus",
      "payload": "petertodd: yes",
      "action": false,
      "timestamp": "2016-09-29T19:33:54+00:00"
    },
    {
      "id": "f2d56d3fb87c4ba7b8bb08cea7038a25",
      "sender": "gmaxwell",
      "payload": "petertodd: we really should have cron mode for the daemon where it just syncs up and shuts off. :P",
      "action": false,
      "timestamp": "2016-09-29T19:33:55+00:00"
    },
    {
      "id": "6aadcf4ece614cb8b591fbbcbfb2cc65",
      "sender": "gmaxwell",
      "payload": "bitcoind -oneshot",
      "action": false,
      "timestamp": "2016-09-29T19:34:06+00:00"
    },
    {
      "id": "f4051b0d4d034fdc867cba11cfef476c",
      "sender": "gmaxwell",
      "payload": ":P",
      "action": false,
      "timestamp": "2016-09-29T19:34:08+00:00"
    },
    {
      "id": "f430e4f77ee14e14bc004de9549e74f1",
      "sender": "petertodd",
      "payload": "gmaxwell: heh, that's not a crazy idea - I'd use it on my laptop",
      "action": false,
      "timestamp": "2016-09-29T19:34:17+00:00"
    },
    {
      "id": "5a2df7ebb468415eabfb37700f17fcf9",
      "sender": "jonasschnelli",
      "payload": "didn't we once had a proposal for the pause option?",
      "action": false,
      "timestamp": "2016-09-29T19:34:18+00:00"
    },
    {
      "id": "4a9a83de6cf646da88f12b28929a1cc1",
      "sender": "wumpus",
      "payload": "right, there's a flag that quits after reindex, but none that exits after sync",
      "action": false,
      "timestamp": "2016-09-29T19:34:24+00:00"
    },
    {
      "id": "b92256adbea74af5b78a030dff49b177",
      "sender": "wumpus",
      "payload": "would be easy to add tho",
      "action": false,
      "timestamp": "2016-09-29T19:34:31+00:00"
    },
    {
      "id": "4b59dcd18b5f4509834413dbb0ca2428",
      "sender": "morcos",
      "payload": "we could just ask for the utxo set, shoudl we discuss ideas how to do that",
      "action": false,
      "timestamp": "2016-09-29T19:34:41+00:00"
    },
    {
      "id": "dfd02ce3fe8c4868b3fb76ec8f458f96",
      "sender": "CodeShark",
      "payload": "^ yes :)",
      "action": false,
      "timestamp": "2016-09-29T19:34:51+00:00"
    },
    {
      "id": "3d87bea456a14feea1f67213992d3709",
      "sender": "petertodd",
      "payload": "make -oneshot run in the foreground with a progress bar :)",
      "action": false,
      "timestamp": "2016-09-29T19:34:58+00:00"
    },
    {
      "id": "fa66db3a1968453d84ca87d81a08cb46",
      "sender": "wumpus",
      "payload": "without utxo commitment that's a no-go",
      "action": false,
      "timestamp": "2016-09-29T19:34:59+00:00"
    },
    {
      "id": "fb811aaf39f848078551603e076914ce",
      "sender": "morcos",
      "payload": "thanks codeshark",
      "action": false,
      "timestamp": "2016-09-29T19:35:05+00:00"
    },
    {
      "id": "3d1f2616e56042719cec66262a21e9a7",
      "sender": "petertodd",
      "payload": "wumpus: +1",
      "action": false,
      "timestamp": "2016-09-29T19:35:20+00:00"
    },
    {
      "id": "28dce3c2c49340b089d8f1a4fa7d3128",
      "sender": "gmaxwell",
      "payload": "morcos: pointless when we were unable to get past the discussion for the security model change to not validate the past history based on proof of work.",
      "action": false,
      "timestamp": "2016-09-29T19:35:42+00:00"
    },
    {
      "id": "f5012ae9945e4035ba7dc5718df132cb",
      "sender": "petertodd",
      "payload": "and lets not underestimate how dangerous UTXO commitments can be - I'm very dubious about committing to the (U)TXO set more recently than maybe a month or two",
      "action": false,
      "timestamp": "2016-09-29T19:35:48+00:00"
    },
    {
      "id": "5de13343285441378b5d644018c9fdc3",
      "sender": "CodeShark",
      "payload": "would be great to query utxo for quick sync, then go backwards in time fetching blocks to increase security...but yes, this is a design discussion",
      "action": false,
      "timestamp": "2016-09-29T19:35:51+00:00"
    },
    {
      "id": "6e231f566cc944f1a54bca1172f02826",
      "sender": "morcos",
      "payload": "i was making a joke, sorry",
      "action": false,
      "timestamp": "2016-09-29T19:35:53+00:00"
    },
    {
      "id": "2e4c26b13f48482890ee012f501743ba",
      "sender": "CodeShark",
      "payload": "alas, quick sync doesn't look feasible in the nearterm",
      "action": false,
      "timestamp": "2016-09-29T19:36:18+00:00"
    },
    {
      "id": "fa472039c79a410db462a116987c06b4",
      "sender": "wumpus",
      "payload": "ok, next topic?",
      "action": false,
      "timestamp": "2016-09-29T19:36:20+00:00"
    },
    {
      "id": "e61c9707ca27414abaa838ba942ce298",
      "sender": "gmaxwell",
      "payload": "but since that was brought up... Can we talk about removing checkpoints?",
      "action": false,
      "timestamp": "2016-09-29T19:36:36+00:00"
    },
    {
      "id": "b46eb900f44344e8a6bd6ca3428a7e56",
      "sender": "wumpus",
      "payload": "#topic removing checkpoints",
      "action": false,
      "timestamp": "2016-09-29T19:36:55+00:00"
    },
    {
      "id": "b51646bdadbd4be787296259d457e1e1",
      "sender": "sipa",
      "payload": "what % of transactions are before the last checkpoint",
      "action": false,
      "timestamp": "2016-09-29T19:36:59+00:00"
    },
    {
      "id": "b5adad98e3d540dc98e2e8e92a81e658",
      "sender": "sipa",
      "payload": "does anyone know?",
      "action": false,
      "timestamp": "2016-09-29T19:37:01+00:00"
    },
    {
      "id": "1af1702aa25d440bba85bedfa0090247",
      "sender": "morcos",
      "payload": "someone should write up a design proposal for that to be evaluated",
      "action": false,
      "timestamp": "2016-09-29T19:37:03+00:00"
    },
    {
      "id": "645d57d72d774e5ea4b57d48e8da7d65",
      "sender": "gmaxwell",
      "payload": "Right now they're used for two things, preventing header flooding with low difficulty headers; and skipping signatures in earlier blocks.",
      "action": false,
      "timestamp": "2016-09-29T19:37:18+00:00"
    },
    {
      "id": "1304304576cf4b45a465adfb22e9d49c",
      "sender": "petertodd",
      "payload": "gmaxwell: just removing checkpoints, or assuming sigs are valid if buried deep enough?",
      "action": false,
      "timestamp": "2016-09-29T19:37:21+00:00"
    },
    {
      "id": "d4bb86035cd9471d879f1b56a9e19b3a",
      "sender": "sipa",
      "payload": "gmaxwell: and 3) estimating progress",
      "action": false,
      "timestamp": "2016-09-29T19:37:27+00:00"
    },
    {
      "id": "93b4a12da324421e981b259c76a093cd",
      "sender": "wumpus",
      "payload": "keeping something for estimating progress would make sense",
      "action": false,
      "timestamp": "2016-09-29T19:37:45+00:00"
    },
    {
      "id": "8794127440574f0cad7fed433d0cd9f7",
      "sender": "sipa",
      "payload": "i think 1) remains needed and 3) remains useful",
      "action": false,
      "timestamp": "2016-09-29T19:37:47+00:00"
    },
    {
      "id": "35510c79236a4595a30735a014daede7",
      "sender": "wumpus",
      "payload": "that doesn't need to be checkpoints",
      "action": false,
      "timestamp": "2016-09-29T19:37:50+00:00"
    },
    {
      "id": "73ba67ff9351474aa56df9d796abd8d9",
      "sender": "gmaxwell",
      "payload": "because very few percentage of the transactions are below the checkpoint .. since libsecp256k1 (and I expect the checkqueue)-- my point two is basically pointless, and I think it could just be removed",
      "action": false,
      "timestamp": "2016-09-29T19:38:06+00:00"
    },
    {
      "id": "eeb0e4b844864f808a50eb5e09932cbc",
      "sender": "gmaxwell",
      "payload": "I think on a desktop it only adds 15-20 minutes to the sync.",
      "action": false,
      "timestamp": "2016-09-29T19:38:29+00:00"
    },
    {
      "id": "934a86bc135649c0babb315123fff004",
      "sender": "petertodd",
      "payload": "gmaxwell: I'd ACK simply removing checkpoints entirely; I'm not happy to see them replaced with another scheme to skip sig checking",
      "action": false,
      "timestamp": "2016-09-29T19:38:29+00:00"
    },
    {
      "id": "b43439cb6ca54ecc8032355922aa8ae7",
      "sender": "wumpus",
      "payload": "a block-height-to-relative-difficulty map would have much less of a stigma",
      "action": false,
      "timestamp": "2016-09-29T19:38:33+00:00"
    },
    {
      "id": "44a6e5bf33c64d12a66e2ef8263a7f43",
      "sender": "wumpus",
      "payload": "eh, verification difficulty that is",
      "action": false,
      "timestamp": "2016-09-29T19:38:46+00:00"
    },
    {
      "id": "e25c910d675c4c39920d657cae86d317",
      "sender": "sipa",
      "payload": "gmaxwell: really?",
      "action": false,
      "timestamp": "2016-09-29T19:38:52+00:00"
    },
    {
      "id": "13033b84bba54c0cbea70ac049184035",
      "sender": "gmaxwell",
      "payload": "petertodd: I think we could remove CP from reason two without implementing the replcement.",
      "action": false,
      "timestamp": "2016-09-29T19:38:54+00:00"
    },
    {
      "id": "2a9f88b7f4774e619901e80196383193",
      "sender": "gmaxwell",
      "payload": "petertodd: morcos is right that needs a design proposal outside of the meeting.",
      "action": false,
      "timestamp": "2016-09-29T19:39:06+00:00"
    },
    {
      "id": "2ffe41aa0fa74b27bf1148bac698cc5e",
      "sender": "sdaftuar",
      "payload": "i'm a bit confused about how to think about checkpoints for signature skipping",
      "action": false,
      "timestamp": "2016-09-29T19:39:12+00:00"
    },
    {
      "id": "835c0e79de854d3c992e02e945ba0cd7",
      "sender": "gmaxwell",
      "payload": "sipa: I benchmarked before but I'm going off of memory, I could be wildly wrong. I will test again if there is interest.",
      "action": false,
      "timestamp": "2016-09-29T19:39:22+00:00"
    },
    {
      "id": "f6a883e2d79d454f90a86ea22cecf7ab",
      "sender": "jonasschnelli",
      "payload": "Removing checkpoints would slow down (maybe insignificant) a scan in a possible SPV hybrid mode?",
      "action": false,
      "timestamp": "2016-09-29T19:39:52+00:00"
    },
    {
      "id": "31466bc8095643b48e79b22c581ac2da",
      "sender": "gmaxwell",
      "payload": "For reason (1) the only answer I have is that I think we should proposal a bit to perpetually increase the minimum difficulty from 1 to something else.",
      "action": false,
      "timestamp": "2016-09-29T19:39:54+00:00"
    },
    {
      "id": "a1750b2b54424182916a3d112f80350d",
      "sender": "sdaftuar",
      "payload": "for instance the recent ISM change caused us to do less validation for certain blocks in our history (blocks in a softfork between the 75% and 95% thresholds)",
      "action": false,
      "timestamp": "2016-09-29T19:40:00+00:00"
    },
    {
      "id": "c251d990d1414e6782e197adc413d891",
      "sender": "sipa",
      "payload": "jonasschnelli: SPV mode won't validate *anything* at all",
      "action": false,
      "timestamp": "2016-09-29T19:40:10+00:00"
    },
    {
      "id": "8e76224503f3432b8a9048f7ae4337a7",
      "sender": "gmaxwell",
      "payload": "(with a checkpoint like bypass of that new rule, for existing blocks that break it) As little as 100,000 would eliminate the header flooding vulenrablity.",
      "action": false,
      "timestamp": "2016-09-29T19:40:28+00:00"
    },
    {
      "id": "8d161032690548e7a0f82f22cbacc301",
      "sender": "jonasschnelli",
      "payload": "Yes. But assume we would add an SPV hibrid mode in oder to received payment during IBD",
      "action": false,
      "timestamp": "2016-09-29T19:40:33+00:00"
    },
    {
      "id": "502f229981194b5991e06d147f05f239",
      "sender": "jonasschnelli",
      "payload": "One would need to download 400k headers without a checkpoint at h400k",
      "action": false,
      "timestamp": "2016-09-29T19:40:50+00:00"
    },
    {
      "id": "c6025496e92546a0b4d25a3d1f56aba7",
      "sender": "luke-jr",
      "payload": "maybe checkpoints should just be disabled by default before complete removal?",
      "action": false,
      "timestamp": "2016-09-29T19:40:53+00:00"
    },
    {
      "id": "ebda73f8346d4dddbfcec5fba3640c4d",
      "sender": "sipa",
      "payload": "jonasschnelli: i think you're confused",
      "action": false,
      "timestamp": "2016-09-29T19:41:00+00:00"
    },
    {
      "id": "a613503d9e8c4ad4ae1c56512c508183",
      "sender": "gmaxwell",
      "payload": "for Sipa's (3) reason for 'checkpoints' I don't give a darn, use chicken bones for progress estimation for all I care. :P it's historical accident that checkpoints and progress use the same data structure.",
      "action": false,
      "timestamp": "2016-09-29T19:41:07+00:00"
    },
    {
      "id": "84504eea920744caa12ddef6551e1ffc",
      "sender": "morcos",
      "payload": "gmaxwell: :) +1",
      "action": false,
      "timestamp": "2016-09-29T19:41:24+00:00"
    },
    {
      "id": "4584b6b62fa444029c8dbc23247166e1",
      "sender": "wumpus",
      "payload": "gmaxwell: yes, my point too",
      "action": false,
      "timestamp": "2016-09-29T19:41:28+00:00"
    },
    {
      "id": "194c107250c245c29900192d781ee350",
      "sender": "sipa",
      "payload": "gmaxwell: agree, those could be completely separated",
      "action": false,
      "timestamp": "2016-09-29T19:41:34+00:00"
    },
    {
      "id": "06a7fe192ef54987bad63395c8109a31",
      "sender": "petertodd",
      "payload": "gmaxwell: ACK checken bones",
      "action": false,
      "timestamp": "2016-09-29T19:41:36+00:00"
    },
    {
      "id": "fea2280e846046498c99906750e4d3ab",
      "sender": "gmaxwell",
      "payload": "Might as well fit a cubic spline to the height vs txn count... and store the parameters.",
      "action": false,
      "timestamp": "2016-09-29T19:41:36+00:00"
    },
    {
      "id": "56a29eb981964345af0cfd1cba0fde48",
      "sender": "wumpus",
      "payload": "right",
      "action": false,
      "timestamp": "2016-09-29T19:41:53+00:00"
    },
    {
      "id": "ab4c444a9a5242e7a29fcaf923bad8b3",
      "sender": "petertodd",
      "payload": "gmaxwell: heh, if we do that with floating point math that has the advantage that it _can't_ be used for consensus :)",
      "action": false,
      "timestamp": "2016-09-29T19:42:09+00:00"
    },
    {
      "id": "b1257f2d40cf47c5ae8cba5b010c992c",
      "sender": "sipa",
      "payload": "now remembers a song our student organization wrote to the melody of staying alive, called 'cubic spline'",
      "action": true,
      "timestamp": "2016-09-29T19:42:18+00:00"
    },
    {
      "id": "8138310d80e8429cb26705353fc198b5",
      "sender": "gmaxwell",
      "payload": "so my proposal, if there is interest, is that I'll measure the performance impact of removing the signature skippingentirely (esp post checkqueue). And if it's not awful, we'll remove.",
      "action": false,
      "timestamp": "2016-09-29T19:42:21+00:00"
    },
    {
      "id": "316841ff334b4cfe9d80576d43d18e94",
      "sender": "wumpus",
      "payload": "+1",
      "action": false,
      "timestamp": "2016-09-29T19:42:37+00:00"
    },
    {
      "id": "47032c7d92674996840606e40fc1f6dd",
      "sender": "sipa",
      "payload": "gmaxwell: i'm unconvinced",
      "action": false,
      "timestamp": "2016-09-29T19:42:44+00:00"
    },
    {
      "id": "44700478f1e9434ca936ffe878c6d33b",
      "sender": "wumpus",
      "payload": "it doesn't hurt to benchmark",
      "action": false,
      "timestamp": "2016-09-29T19:42:52+00:00"
    },
    {
      "id": "5c563f539b874ed6915c6301fa16cfa8",
      "sender": "gmaxwell",
      "payload": "and maybe I'll tender a proposal to up the minimum difficulty, but I'd like to know what people think about that.",
      "action": false,
      "timestamp": "2016-09-29T19:43:00+00:00"
    },
    {
      "id": "1ab4319194794479b2c54878a10f36ff",
      "sender": "wumpus",
      "payload": "measuring is always better than making assumptions",
      "action": false,
      "timestamp": "2016-09-29T19:43:04+00:00"
    },
    {
      "id": "7f7ab33baf0545a994c9a80d11ed9ae9",
      "sender": "sipa",
      "payload": "with a replacement for sig skipping that isn't based on checkpoints we could significantly improve things",
      "action": false,
      "timestamp": "2016-09-29T19:43:11+00:00"
    },
    {
      "id": "08a616239f9940699c11e4d7361e1703",
      "sender": "petertodd",
      "payload": "sipa: I don't think such a replacement can exist without changing the security assumptions; I'd *rather* have checkpoints than trusting hashing power for that",
      "action": false,
      "timestamp": "2016-09-29T19:43:39+00:00"
    },
    {
      "id": "82198d94bfcf43549fab55f02e413467",
      "sender": "sipa",
      "payload": "the last checkpoint currently is very old for the very reason that we've been planning to replace it",
      "action": false,
      "timestamp": "2016-09-29T19:43:44+00:00"
    },
    {
      "id": "ab3318bca4ae4508a338c8d6adc9c6ac",
      "sender": "gmaxwell",
      "payload": "sipa: would you like to help work on a proposal for that? it has been controversial in the past. I'd like to do something good, because otherwise imprudent attempts will be adopted instead.",
      "action": false,
      "timestamp": "2016-09-29T19:43:47+00:00"
    },
    {
      "id": "6fd6c83a038c43d59c8eb75d9478e237",
      "sender": "sipa",
      "payload": "so it's unfair to use the \"the last checkpoint is old\" as a given; it's something we've affected indirectly",
      "action": false,
      "timestamp": "2016-09-29T19:44:15+00:00"
    },
    {
      "id": "5a0efca6b6a04e9faf9303c0102491a5",
      "sender": "petertodd",
      "payload": "sipa: though what checkpoints should do is say \"Something big has changed; you can disable checkpoints with --no-checkpoints, but you should find out what this means before doing so.\"",
      "action": false,
      "timestamp": "2016-09-29T19:44:19+00:00"
    },
    {
      "id": "6627810e555f4a18ba526c0ef7dcb021",
      "sender": "gmaxwell",
      "payload": "(for example Bitcoin Classic's current behavior simply looks at block header timestamps and ignores signatures when they're more than 24 hours (*par) old by the local clock. It's easily exploited and makes me sad.",
      "action": false,
      "timestamp": "2016-09-29T19:44:29+00:00"
    },
    {
      "id": "e495dc6e927448bd8510c0e867445238",
      "sender": "sipa",
      "payload": "petertodd: it's my opinion that on a timescale of months, it doesn't matter",
      "action": false,
      "timestamp": "2016-09-29T19:44:40+00:00"
    },
    {
      "id": "7208c3e9eee841a89b39196f58f33c83",
      "sender": "sipa",
      "payload": "IF you can guarantee it's actually a timescale of months",
      "action": false,
      "timestamp": "2016-09-29T19:44:53+00:00"
    },
    {
      "id": "996bb8c1984c406bac2eddf5f8710bef",
      "sender": "wumpus",
      "payload": "yes that makes me sad too",
      "action": false,
      "timestamp": "2016-09-29T19:44:55+00:00"
    },
    {
      "id": "197aa61ffa894a58a23ed34fb5153e6b",
      "sender": "petertodd",
      "payload": "sipa: on a timescale of months, checkpoints shouldn't matter either...",
      "action": false,
      "timestamp": "2016-09-29T19:44:58+00:00"
    },
    {
      "id": "b399c238053a4fa9b78ab64e7a93cb25",
      "sender": "wumpus",
      "payload": "anything based on time seems very brittle",
      "action": false,
      "timestamp": "2016-09-29T19:45:06+00:00"
    },
    {
      "id": "e0e821ce367a4ca3a04d2cd7fe9ddf5f",
      "sender": "sipa",
      "payload": "petertodd: look at the current hashrate; what's 3 months worth of chain work at that hashrate",
      "action": false,
      "timestamp": "2016-09-29T19:45:27+00:00"
    },
    {
      "id": "d2680056c7114f109b0fa9811945ec8e",
      "sender": "petertodd",
      "payload": "wumpus: and anything based on work isn't much better if you're running an old client, and mining has advanced significantly",
      "action": false,
      "timestamp": "2016-09-29T19:45:31+00:00"
    },
    {
      "id": "4996be6a7dcc43949d97bd2eee895e12",
      "sender": "jonasschnelli",
      "payload": "sipa: I (hope) I'm not confused. If we would add a SPV hybrid mode directly fetch blocks at the tip (in order to received payments), no available checkpoint would result in downloading all headers *losing* maybe 3-4mins before you can start using SPV... minor issue though, I agree",
      "action": false,
      "timestamp": "2016-09-29T19:45:37+00:00"
    },
    {
      "id": "5db073b4fe9a47309d7d152cb76d9ab7",
      "sender": "petertodd",
      "payload": "sipa: that assumes you know what the current hashrate is",
      "action": false,
      "timestamp": "2016-09-29T19:45:38+00:00"
    },
    {
      "id": "492f80d9bfc245fcbd99678b0f840685",
      "sender": "gmaxwell",
      "payload": "wumpus: the prior proposals were based on work,  e.g. skip if the best chain you see dominates the next conflicted chain at that hight by N months of work.",
      "action": false,
      "timestamp": "2016-09-29T19:45:41+00:00"
    },
    {
      "id": "4473f58d7d394f1c841fafd477970a8c",
      "sender": "Chris_Stewart_5",
      "payload": "gmaxwell: How have we solved the problem that checkpoints were originally created for? You have an excerpt in here: https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download#Checkpoints",
      "action": false,
      "timestamp": "2016-09-29T19:45:44+00:00"
    },
    {
      "id": "3336d8825ddd41edbc226212b9f108de",
      "sender": "petertodd",
      "payload": "sipa: your node might be surrounded by sybils",
      "action": false,
      "timestamp": "2016-09-29T19:45:45+00:00"
    },
    {
      "id": "6d315e06fff34c4fb574067b6479a6ed",
      "sender": "gmaxwell",
      "payload": "wumpus: with a 'minimum total work' coded in as part of the release proces.",
      "action": false,
      "timestamp": "2016-09-29T19:45:52+00:00"
    },
    {
      "id": "6fbc1fd9ba224ceeb23082c44b961e10",
      "sender": "sipa",
      "payload": "Chris_Stewart_5: headers first sync",
      "action": false,
      "timestamp": "2016-09-29T19:46:00+00:00"
    },
    {
      "id": "8696b9389c5842c890802c262fbf2ef1",
      "sender": "sipa",
      "payload": "Chris_Stewart_5: 0.10",
      "action": false,
      "timestamp": "2016-09-29T19:46:08+00:00"
    },
    {
      "id": "a144c4ca7dae429ea0f0befdd7b7d77d",
      "sender": "gmaxwell",
      "payload": "Chris_Stewart_5: headers first sync.",
      "action": false,
      "timestamp": "2016-09-29T19:46:08+00:00"
    },
    {
      "id": "cf6bb275978c41cea38e095c847a9eff",
      "sender": "wumpus",
      "payload": "gmaxwell: right. Well, at the least it should be measured whether such a change is really worth it.",
      "action": false,
      "timestamp": "2016-09-29T19:46:09+00:00"
    },
    {
      "id": "e41f1de650964730afeedb43a24ac98a",
      "sender": "sipa",
      "payload": "petertodd: yes, i know...",
      "action": false,
      "timestamp": "2016-09-29T19:46:16+00:00"
    },
    {
      "id": "f55a4a7321fb4628a4ba626bbe8bafab",
      "sender": "sipa",
      "payload": "so, let's measure.",
      "action": false,
      "timestamp": "2016-09-29T19:46:21+00:00"
    },
    {
      "id": "4cb9b9f96d4e4986b318f3f1db7acd4e",
      "sender": "sipa",
      "payload": "and discuss later",
      "action": false,
      "timestamp": "2016-09-29T19:46:25+00:00"
    },
    {
      "id": "6718f97a62454e389a776251465ae474",
      "sender": "gmaxwell",
      "payload": "Chris_Stewart_5: and the signature skipping behavior in checkpoints was actually a result of a bug fixed years ago.. mlock being used on all allocations making script validation INSANELY slow.",
      "action": false,
      "timestamp": "2016-09-29T19:46:37+00:00"
    },
    {
      "id": "e1bc1cf59de34096a3cc260a5c280b34",
      "sender": "wumpus",
      "payload": "so much of the verification overhead is looking up UTXOs",
      "action": false,
      "timestamp": "2016-09-29T19:46:41+00:00"
    },
    {
      "id": "5876e67b830443fca4746162da0dfca4",
      "sender": "gmaxwell",
      "payload": "sipa: okay.",
      "action": false,
      "timestamp": "2016-09-29T19:46:44+00:00"
    },
    {
      "id": "420ceeea3ab940bea308a28205456722",
      "sender": "wumpus",
      "payload": "something you'll not avoid",
      "action": false,
      "timestamp": "2016-09-29T19:46:47+00:00"
    },
    {
      "id": "3ee4457f86d24d239c341c5c79e7ec46",
      "sender": "gmaxwell",
      "payload": "Chris_Stewart_5: but then with chain growth we became dependant on it to keep sync times reasonable. but libsecp256k1 made signature validation >5x faster.",
      "action": false,
      "timestamp": "2016-09-29T19:47:20+00:00"
    },
    {
      "id": "5d7d33fe301d48dd87b234aa7b420197",
      "sender": "wumpus",
      "payload": "especially for recent blocks",
      "action": false,
      "timestamp": "2016-09-29T19:47:21+00:00"
    },
    {
      "id": "4923853b6c1744f29e69254107afe3c2",
      "sender": "wumpus",
      "payload": "if you do any benchmarking please look at the recent blocks, not the first N",
      "action": false,
      "timestamp": "2016-09-29T19:47:38+00:00"
    },
    {
      "id": "37685c7c8231472a82e5c0515aca0961",
      "sender": "gmaxwell",
      "payload": "wumpus: it's still a major speed up on existing blocks.",
      "action": false,
      "timestamp": "2016-09-29T19:48:04+00:00"
    },
    {
      "id": "dd3266894a124f789d026a73fdbe7479",
      "sender": "sipa",
      "payload": "in a side node: i've already updated my logging to measure bandwidth vs blockdepth instead of just count.",
      "action": false,
      "timestamp": "2016-09-29T19:48:07+00:00"
    },
    {
      "id": "1eeab7f8fe0f4da28f7f39f606495476",
      "sender": "Chris_Stewart_5",
      "payload": "So header sync solves the attack of flooding disk space, but not having your entire network hijacked, correct?",
      "action": false,
      "timestamp": "2016-09-29T19:48:11+00:00"
    },
    {
      "id": "034069b1d34e4e418eba19502895ef67",
      "sender": "wumpus",
      "payload": "Chris_Stewart_5: huh?",
      "action": false,
      "timestamp": "2016-09-29T19:48:32+00:00"
    },
    {
      "id": "7b42f4db3aa940ebac3e629819b5160a",
      "sender": "wumpus",
      "payload": "gmaxwell: sure, could be",
      "action": false,
      "timestamp": "2016-09-29T19:48:41+00:00"
    },
    {
      "id": "ef1e616787e64bf3ad03e24f8c717411",
      "sender": "gmaxwell",
      "payload": "Chris_Stewart_5: isolation can be resolved by simply knowing what the total work of the best chain was at release.",
      "action": false,
      "timestamp": "2016-09-29T19:48:42+00:00"
    },
    {
      "id": "0ae751612b1b4f84bae8ac06d9eda802",
      "sender": "gmaxwell",
      "payload": "Chris_Stewart_5: sorry, this was discussed prior times removing checkpoints had come up, I haven't completely described the background.",
      "action": false,
      "timestamp": "2016-09-29T19:49:00+00:00"
    },
    {
      "id": "324c034f500840459f9f4eb75ab47682",
      "sender": "Chris_Stewart_5",
      "payload": "gmaxwell: Thanks for the explanation, i'll keep digging.",
      "action": false,
      "timestamp": "2016-09-29T19:49:19+00:00"
    },
    {
      "id": "fd525260131b47a5a7faa2af28f75695",
      "sender": "wumpus",
      "payload": "Chris_Stewart_5: ah, you mean being isolated and being fed a wrong chain, sorry I was imaginging some wacky things at having your network hijacked :)",
      "action": false,
      "timestamp": "2016-09-29T19:49:45+00:00"
    },
    {
      "id": "4ce25e52e3804ceeae5741835da7cf0e",
      "sender": "wumpus",
      "payload": "ok, next topic?",
      "action": false,
      "timestamp": "2016-09-29T19:51:01+00:00"
    },
    {
      "id": "f0c37c8eeabb4f70b2beb3118f767b12",
      "sender": "gmaxwell",
      "payload": "wumpus: just the \"you got a faithful bitcoin core download but the attacker controls your network\"... but that doesn't need a checkpoint to fix, a simple partitioning detction that knows the total work of the best chain at releast time is sufficient.",
      "action": false,
      "timestamp": "2016-09-29T19:51:01+00:00"
    },
    {
      "id": "62e96e8c87844afc91e7a3d5c79a44df",
      "sender": "gmaxwell",
      "payload": "Thanks for the discussion.",
      "action": false,
      "timestamp": "2016-09-29T19:51:01+00:00"
    },
    {
      "id": "d42677cda9fa4de08926f606d77730c0",
      "sender": "wumpus",
      "payload": "#topic segwit against uncompressed keys or not",
      "action": false,
      "timestamp": "2016-09-29T19:51:13+00:00"
    },
    {
      "id": "5cd8189dfd114b2eb50756e42702dc6b",
      "sender": "wumpus",
      "payload": "(10 minutes to go)",
      "action": false,
      "timestamp": "2016-09-29T19:51:17+00:00"
    },
    {
      "id": "98687c9ea5654d4c9b819b5146865e1a",
      "sender": "wumpus",
      "payload": "(9 minutes to go)",
      "action": false,
      "timestamp": "2016-09-29T19:51:24+00:00"
    },
    {
      "id": "fbdd2c539deb4b63b9332a1dffb6b6ba",
      "sender": "petertodd",
      "payload": "so to be clear, *just* segwit right?",
      "action": false,
      "timestamp": "2016-09-29T19:51:27+00:00"
    },
    {
      "id": "849c6235e56c4eec9745a0d242d56544",
      "sender": "CodeShark",
      "payload": "does anyone still use uncompressed keys?",
      "action": false,
      "timestamp": "2016-09-29T19:51:30+00:00"
    },
    {
      "id": "d6e9990f290d4a19b55dbdf84bb251ef",
      "sender": "wumpus",
      "payload": "yes, only segwit",
      "action": false,
      "timestamp": "2016-09-29T19:51:33+00:00"
    },
    {
      "id": "b6ee3d92dbb242758b1c9bec7ca842ef",
      "sender": "achow101",
      "payload": "CodeShark: armory does",
      "action": false,
      "timestamp": "2016-09-29T19:51:39+00:00"
    },
    {
      "id": "c4f2da4cf996452b8f5ea705c250e83a",
      "sender": "luke-jr",
      "payload": "seems uncontroversial",
      "action": false,
      "timestamp": "2016-09-29T19:51:42+00:00"
    },
    {
      "id": "56565c0b9d914ff387bd28b997abf2d2",
      "sender": "petertodd",
      "payload": "I'm happy to ACK that given just segwit",
      "action": false,
      "timestamp": "2016-09-29T19:51:49+00:00"
    },
    {
      "id": "0a4a9df86d554eea968b493ee023b692",
      "sender": "achow101",
      "payload": "having segwit enforce uncompressed keys would delay segwit adoption for armory users",
      "action": false,
      "timestamp": "2016-09-29T19:51:57+00:00"
    },
    {
      "id": "a3db48041fdb450fb2dcbdc92d7c29bb",
      "sender": "achow101",
      "payload": "*compressed",
      "action": false,
      "timestamp": "2016-09-29T19:52:03+00:00"
    },
    {
      "id": "78cf29fb845b4b588b54c4fc5d4fd0bc",
      "sender": "jl2012_",
      "payload": "it's in #8499",
      "action": false,
      "timestamp": "2016-09-29T19:52:05+00:00"
    },
    {
      "id": "ce3cc4b0ba244287884d4f622ec8df8a",
      "sender": "luke-jr",
      "payload": "achow101: why? just compress them",
      "action": false,
      "timestamp": "2016-09-29T19:52:09+00:00"
    },
    {
      "id": "4e0b66008ad4407a9bf754342c452b4d",
      "sender": "wumpus",
      "payload": "gmaxwell: yes, though we had a lot of trouble with partitioning detection, I remember some code being stripped out and such. But anyhow, yes that's the better approach if it can be gotten to work.",
      "action": false,
      "timestamp": "2016-09-29T19:52:13+00:00"
    },
    {
      "id": "a865d96077e048028dcad9e28be4ce2b",
      "sender": "sipa",
      "payload": "achow101: sigh, does armory still not do that?",
      "action": false,
      "timestamp": "2016-09-29T19:52:22+00:00"
    },
    {
      "id": "eda81b70ca654fe48f99a8a7a0f3f7cc",
      "sender": "achow101",
      "payload": "luke-jr: we have to change the whole wallet structure (it's still going to happen anyways)",
      "action": false,
      "timestamp": "2016-09-29T19:52:30+00:00"
    },
    {
      "id": "1967a0748d134bdb8b1f061b06819785",
      "sender": "wumpus",
      "payload": "gmaxwell: without too much false positives",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "8756662a89dd48c88512973adde8614c",
      "sender": "luke-jr",
      "payload": "achow101: why?",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "a5b3abaa71684d73bfb4403463aec939",
      "sender": "sipa",
      "payload": "achow101: alan said somewhere in 2013 he was implementing it...",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "6ce91f76a10d4de7bf5c4c066d335219",
      "sender": "achow101",
      "payload": "alan's gone now..",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "581b272031ce44a1bfe319fcf8cdafe8",
      "sender": "luke-jr",
      "payload": "afaik the only downside to using compressed keys is it changes the address, which segwit is changing anyway",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "d98157e97b8d4123aded45181df06404",
      "sender": "CodeShark",
      "payload": "it's not a very complicated change",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "87e3827a087c4da48b33655e4f5248ed",
      "sender": "wumpus",
      "payload": "armory still uses uncompressed keys?!",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "2a5fd853df9e4c21b4fca5152ba5e2d0",
      "sender": "luke-jr",
      "payload": "there's no reason you'd need to change the wallet structure I can see",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "c60161d6c99b49e280199ea0157eef8c",
      "sender": "wumpus",
      "payload": "in any case this only applies to segwit, not to old transactions",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "f4abf329d0cd4e4db7c4f33512b75b31",
      "sender": "achow101",
      "payload": "the plan is to have a new wallet structure with bip32 that supports segwit and compressed keys",
      "action": false,
      "timestamp": "2016-09-29T19:53:34+00:00"
    },
    {
      "id": "765b91a3a1c94c1c81db4c2af651e43b",
      "sender": "gmaxwell",
      "payload": "wumpus: \"you're partitioned until you see a header chain with at least work X\" is a pretty simple critera. :P",
      "action": false,
      "timestamp": "2016-09-29T19:53:41+00:00"
    },
    {
      "id": "a4c8d7c4d2d4485e9b199f3c9800d6e5",
      "sender": "sipa",
      "payload": "luke-jr: it had fixed size records in its wallet format for pubkeys",
      "action": false,
      "timestamp": "2016-09-29T19:53:44+00:00"
    },
    {
      "id": "1abb8a84f8c642988b1f8f9239556b5e",
      "sender": "sipa",
      "payload": "achow101: well if a new wallet format is needed for segwit anyway, it doesn't matter right?",
      "action": false,
      "timestamp": "2016-09-29T19:54:05+00:00"
    },
    {
      "id": "7a9048e66985493bae790ec9fc1bff2c",
      "sender": "gmaxwell",
      "payload": "achow101: oh god please do not use uncompressed keys with segwit. why would you do that?",
      "action": false,
      "timestamp": "2016-09-29T19:54:10+00:00"
    },
    {
      "id": "4cfb0b9991fc4848b73bb6fe54192af1",
      "sender": "luke-jr",
      "payload": "sipa: zero-pad it?",
      "action": false,
      "timestamp": "2016-09-29T19:54:13+00:00"
    },
    {
      "id": "4ab109430d5447ccb26766e9c35609f1",
      "sender": "achow101",
      "payload": "sipa: well no, we don't need a new wallet for segwit as it could still work with the old one with a little bit of hacking",
      "action": false,
      "timestamp": "2016-09-29T19:54:35+00:00"
    },
    {
      "id": "79d1e305a33345ed91e454c7caab3695",
      "sender": "achow101",
      "payload": "that was the original plan",
      "action": false,
      "timestamp": "2016-09-29T19:54:48+00:00"
    },
    {
      "id": "1eb94ce8b0d34c0899ec2f94d4143262",
      "sender": "luke-jr",
      "payload": "achow101: no less than compressed could",
      "action": false,
      "timestamp": "2016-09-29T19:54:48+00:00"
    },
    {
      "id": "1910d2936e7844b1b2730ac8dbd3904b",
      "sender": "luke-jr",
      "payload": "sipa: or store the uncompressed key, and compress it at address-generation/signing",
      "action": false,
      "timestamp": "2016-09-29T19:55:15+00:00"
    },
    {
      "id": "66a2aef9a9fc40b2aabf2e9f1790e486",
      "sender": "gmaxwell",
      "payload": "achow101: why cant the same hack that indicates segwit is in use indicate compressed.. you just chop off some bytes of the key pretty much.",
      "action": false,
      "timestamp": "2016-09-29T19:55:26+00:00"
    },
    {
      "id": "72e94381fb194158b91900af371c32dd",
      "sender": "sipa",
      "payload": "btw, uncompressed keys account for 0.7% of used keys in succesful sigs on the network (in the past 2 hours)",
      "action": false,
      "timestamp": "2016-09-29T19:55:43+00:00"
    },
    {
      "id": "20f626aae8a7415a83baeec0eb153e81",
      "sender": "gmaxwell",
      "payload": "it could be done entirely inside the process that seralizes the segwit scriptpubkey.",
      "action": false,
      "timestamp": "2016-09-29T19:55:44+00:00"
    },
    {
      "id": "14cda78ecad746a48986fb4781fa061b",
      "sender": "achow101",
      "payload": "gmaxwell: idk. ask goatpig",
      "action": false,
      "timestamp": "2016-09-29T19:56:06+00:00"
    },
    {
      "id": "a68eb745a86541f38813afb30a7074df",
      "sender": "gmaxwell",
      "payload": "achow101: okay",
      "action": false,
      "timestamp": "2016-09-29T19:56:06+00:00"
    },
    {
      "id": "833d154246694ba68b49afda99a5fe2d",
      "sender": "michagogo",
      "payload": "pokes his head in belatedly",
      "action": true,
      "timestamp": "2016-09-29T19:56:09+00:00"
    },
    {
      "id": "faf8587ab0284b9aa229ef41b452adac",
      "sender": "CodeShark",
      "payload": "I think we should encourage all wallets to use compressed keys - achow101, if you need help with this I'd be willing to help",
      "action": false,
      "timestamp": "2016-09-29T19:56:10+00:00"
    },
    {
      "id": "5d85c124d9b344c7bb8f18e9243e66e7",
      "sender": "sipa",
      "payload": "agree - we should help",
      "action": false,
      "timestamp": "2016-09-29T19:56:25+00:00"
    },
    {
      "id": "9dbd1f60ea6f4340a40459e6a9b94ab6",
      "sender": "gmaxwell",
      "payload": "yes, lots of people would be glad to help.",
      "action": false,
      "timestamp": "2016-09-29T19:56:27+00:00"
    },
    {
      "id": "669e5573a9c0403ca70a1c15f2aff719",
      "sender": "sipa",
      "payload": "instead of just yell",
      "action": false,
      "timestamp": "2016-09-29T19:56:32+00:00"
    },
    {
      "id": "d5f65f96c93f49808fb96cef343c7fef",
      "sender": "gmaxwell",
      "payload": "well I offered to help armory move off uncompressed keys to alan several times, including offering to pay to do it.",
      "action": false,
      "timestamp": "2016-09-29T19:56:50+00:00"
    },
    {
      "id": "d325858153b045eb9ba23a72076ebd10",
      "sender": "gmaxwell",
      "payload": "so please don't say anyone just yelled.",
      "action": false,
      "timestamp": "2016-09-29T19:56:56+00:00"
    },
    {
      "id": "055038ea02d6483999767d50eb1e513a",
      "sender": "CodeShark",
      "payload": "I initially designed my account structures to only use compressed keys - but later added a compressed bit to support legacy stuff",
      "action": false,
      "timestamp": "2016-09-29T19:58:39+00:00"
    },
    {
      "id": "b484bbd7b979496fa8859aed4aa30030",
      "sender": "petertodd",
      "payload": "CodeShark: what legacy stuff specifically? legacy armory users?",
      "action": false,
      "timestamp": "2016-09-29T19:59:06+00:00"
    },
    {
      "id": "4b12247da1fc4b1d9925b1e7793b8098",
      "sender": "wumpus",
      "payload": "CodeShark: bah,it's kind of sad that to hear some things seem to be going back instead of forward :)",
      "action": false,
      "timestamp": "2016-09-29T19:59:08+00:00"
    },
    {
      "id": "e8fd2c329f0f4a749e3f8ecb22f1a703",
      "sender": "CodeShark",
      "payload": "yes, to support other wallets",
      "action": false,
      "timestamp": "2016-09-29T19:59:18+00:00"
    },
    {
      "id": "3773289ef111463286b0581dce2f816f",
      "sender": "wumpus",
      "payload": "it's time",
      "action": false,
      "timestamp": "2016-09-29T19:59:27+00:00"
    },
    {
      "id": "0df3b84995274c71b38af3c72ed6ff07",
      "sender": "CodeShark",
      "payload": "but I think we really do need to prod all wallets to move to compressed keys",
      "action": false,
      "timestamp": "2016-09-29T19:59:50+00:00"
    },
    {
      "id": "8115c04cea9d477a9bc7bae475cf3725",
      "sender": "CodeShark",
      "payload": "there's really no reason to continue to support uncompressed keys - other than perhaps some migration tools",
      "action": false,
      "timestamp": "2016-09-29T20:00:07+00:00"
    },
    {
      "id": "cf8ec74e66f64a749a75dfafcfa86fad",
      "sender": "wumpus",
      "payload": "#endmeeting",
      "action": false,
      "timestamp": "2016-09-29T20:00:15+00:00"
    }
  ],
  "events": [
    {
      "event_type": "START_MEETING",
      "message": {
        "id": "881f2e08c0004e07bfd91273f34d55ac",
        "sender": "wumpus",
        "payload": "#startmeeting",
        "action": false,
        "timestamp": "2016-09-29T19:01:19+00:00"
      },
      "operand": null,
      "id": "881f2e08c0004e07bfd91273f34d55ac",
      "timestamp": "2016-09-29T19:01:19+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "44974a989acf41a0b2d56ff3d0b04472",
        "sender": "wumpus",
        "payload": "#topic pruning and blockrelay",
        "action": false,
        "timestamp": "2016-09-29T19:03:11+00:00"
      },
      "operand": "pruning and blockrelay",
      "id": "44974a989acf41a0b2d56ff3d0b04472",
      "timestamp": "2016-09-29T19:03:11+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "b46eb900f44344e8a6bd6ca3428a7e56",
        "sender": "wumpus",
        "payload": "#topic removing checkpoints",
        "action": false,
        "timestamp": "2016-09-29T19:36:55+00:00"
      },
      "operand": "removing checkpoints",
      "id": "b46eb900f44344e8a6bd6ca3428a7e56",
      "timestamp": "2016-09-29T19:36:55+00:00"
    },
    {
      "event_type": "TOPIC",
      "message": {
        "id": "d42677cda9fa4de08926f606d77730c0",
        "sender": "wumpus",
        "payload": "#topic segwit against uncompressed keys or not",
        "action": false,
        "timestamp": "2016-09-29T19:51:13+00:00"
      },
      "operand": "segwit against uncompressed keys or not",
      "id": "d42677cda9fa4de08926f606d77730c0",
      "timestamp": "2016-09-29T19:51:13+00:00"
    },
    {
      "event_type": "END_MEETING",
      "message": {
        "id": "cf8ec74e66f64a749a75dfafcfa86fad",
        "sender": "wumpus",
        "payload": "#endmeeting",
        "action": false,
        "timestamp": "2016-09-29T20:00:15+00:00"
      },
      "operand": null,
      "id": "cf8ec74e66f64a749a75dfafcfa86fad",
      "timestamp": "2016-09-29T20:00:15+00:00"
    }
  ],
  "aliases": {},
  "vote_in_progress": false,
  "motion_index": null
}