{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-07-18\n📝 Original message:On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e I'd encourage you to code up a prototype first (or at the same time), in\n\u003e whatever programming language / networking library you're most familiar\n\u003e with.\n\n+1\n\n\u003e Maybe not even using the existing p2p protocol; there could be a mining-only\n\u003e very-fast-block-propagation network separate from the existing p2p network.\n\u003e\n\u003e Combining your optimizations with \"broadcast as many near-miss blocks as\n\u003e bandwidth will allow\" on a mining backbone network should allow insanely\n\u003e fast propagation of most newly solved blocks.\n\n\nYes, I would encourage thinking along these lines.  That was the\nmotivation of the UDP P2P protocol extension I wrote:\nhttps://bitcointalk.org/index.php?topic=156769.0\n\nThe intention was to experiment with sending block header + tx list +\ncoinbase, via UDP best effort broadcast.\n\nIncentives:\n\nIf your neighbors receiving this message already have the TXs in the\nTX list, then the block is complete, and may be relayed further.\n\nIf your neighbors do not have all TXs in the block, they must fetch\nthem at additional time/latency cost.\n\nThus, you have an incentive to relay blocks containing TXs already\ndistributed out into network mempools and cached in the signature\ncache.\n\nWe want to capture that incentive in whatever protocol is eventually\nused.  Miners have a TX fee incentive to include many transactions.\nIn theory, they want to include as many TX as possible.  It will help\nus scale quite a bit to solve this problem."}