{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-10\n📝 Original message:Error correction is an interesting suggestion.\n\nIf there was 10000 nodes and each stored 0.1% of the blocks, at random,\nthen the odds of a block not being stored is 45 in a million.\n\nBlocks are stored on average 10 times, so there is already reasonable\nredundancy.\n\nWith 1 million blocks, 45 would be lost in that case, even though most are\nstored multiple times.\n\nWith error correction codes, the chances of blocks going missing is much\nlower.\n\nFor example, if there was 32 out of 34 Reed-Solomon-like system, then 2\nblocks out of 34 could be lost without any actual data loss for the network.\n\nAs a back of the envelop check, the odds of 2 missing blocks landing within\n34 of another is 68/1000000.  That means that the odds of 2 missing blocks\nfalling in the same correction section is 45 * 34 / 1000000 = 0.153%.  Even\nin that case, the missing blocks could be reconstructed, as long as you\nknow that they are missing.\n\nThe error correction code has taken it from being a near certainty that\nsome blocks would be lost to less than 0.153%.\n\nA simple error correction system would just take 32 blocks in sequence and\nthen compute 2 extra blocks.\n\nThe extra blocks would have to be the same length as the longest block in\nthe 32 being corrected.\n\nThe shorter blocks would be padded with zeroes so everything is the same\nsize.\n\nFor each byte position in the blocks you compute the polynomial that goes\nthrough byte (x, data(x)), for x = 0 to 31.  This could be a finite field,\nor just mod 257.\n\nYou can then compute the value for x=32 and x = 33.  Those are the values\nfor the 2 extra blocks.\n\nIf mod 257 is used, then only the 2 extra blocks have to deal with symbols\nfrom 0 to 256.\n\nIf you have 32 of the 34 blocks, you can compute the polynomial and thus\ngenerate the 32 actual blocks.\n\nThis could be achieved by a soft fork by having a commitment every 32\nblocks in the coinbase.\n\nIt makes the header chain much longer though.\n\nLonger sections are more efficient, but need more calculations to recover\neverything.  You could also do interleaving to handle the case where entire\nsections are missing.\n\n\nOn Thu, Apr 10, 2014 at 12:54 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e\n\u003e\n\u003e\n\u003e On 10 April 2014 07:50:55 GMT-04:00, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e(Just be glad I'm not suggesting coding the entire blockchain with an\n\u003e \u003eerror correcting code so that it doesn't matter which subset you're\n\u003e \u003eholding)\n\u003e\n\u003e I forgot to ask last night: if you do that, can you add new blocks to the\n\u003e chain with the encoding incrementally?\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e Version: APG v1.1.1\n\u003e\n\u003e iQFQBAEBCgA6BQJTRoZ+MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8\n\u003e cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhYudCAC7ImifMnLIFHv1UifV\n\u003e zRxtDkx7UxIf9dncDAcrTIyKEDhoouh0TmoZl3HKQ3KUEETAVKsMzqXLgqVe6Ezr\n\u003e ny1bm0pQlkBCZFRwuZvmB27Y3mwC8PD6rT9ywtWzFjWd8PEg6/UaM547nQPw7ir0\n\u003e 27S3XMfE/BMiQWfWnWc/nqpbmJjd8x/dM3oiTG9SVZ7iNxotxAqfnW2X5tkhJb0q\n\u003e dAV08wpu6aZ5hTyLpvDxXDFjEG119HJeLkT9QVIrg+GBG55PYORqE4gQr6uhrF4L\n\u003e fGZS2EIlbk+kAiv0EjglQfxWM7KSRegplSASiKEOuX80tqLIsEugNh1em8qvG401\n\u003e NOAS\n\u003e =CWql\n\u003e -----END PGP SIGNATURE-----\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Put Bad Developers to Shame\n\u003e Dominate Development with Jenkins Continuous Integration\n\u003e Continuously Automate Build, Test \u0026 Deployment\n\u003e Start a new project now. Try Jenkins in the cloud.\n\u003e http://p.sf.net/sfu/13600_Cloudbees\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140410/1f9c48ef/attachment.html\u003e"}