rich1.0npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58njumphttps://nostr.ae📅 Original date posted:2014-07-18 📝 Original message:On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen <gavinandresen at gmail.com> wrote: > I'd encourage you to code up a prototype first (or at the same time), in > whatever programming language / networking library you're most familiar > with. +1 > Maybe not even using the existing p2p protocol; there could be a mining-only > very-fast-block-propagation network separate from the existing p2p network. > > Combining your optimizations with "broadcast as many near-miss blocks as > bandwidth will allow" on a mining backbone network should allow insanely > fast propagation of most newly solved blocks. Yes, I would encourage thinking along these lines. That was the motivation of the UDP P2P protocol extension I wrote: https://bitcointalk.org/index.php?topic=156769.0 The intention was to experiment with sending block header + tx list + coinbase, via UDP best effort broadcast. Incentives: If your neighbors receiving this message already have the TXs in the TX list, then the block is complete, and may be relayed further. If your neighbors do not have all TXs in the block, they must fetch them at additional time/latency cost. Thus, you have an incentive to relay blocks containing TXs already distributed out into network mempools and cached in the signature cache. We want to capture that incentive in whatever protocol is eventually used. Miners have a TX fee incentive to include many transactions. In theory, they want to include as many TX as possible. It will help us scale quite a bit to solve this problem.