<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>A New Broadcast Primitive for BFT Protocols · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2410.22080/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2410.22080/feed.xml" rel="self" type="application/rss+xml" /><item><title>A New Broadcast Primitive for BFT Protocols — mentioned by tklenze</title><link>https://news.ycombinator.com/item?id=44356735</link><guid isPermaLink="false">urn:hackerpapers:mention:2410.22080:44356735</guid><pubDate>Mon, 23 Jun 2025 15:23:02 GMT</pubDate><description>&lt;p&gt;Thanks for your insights! Yes, real-life behavior is indeed interesting to look at, and for this purpose, two testnets are running right now (https://www.gmonads.com). RaptorCast uses erasure coding to break a block proposal into smaller pieces with plenty of redundancy to allow for omissions. This means that if you receive sufficiently many chunks, you can decode the block proposal (no matter which of the chunks you received). The redundancy factor can be tweaked, but it’ll likely be &amp;gt;2x, to allow for networking issues and faulty/malicious nodes. Furthermore, the blockchain can make progress…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2410.22080/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.NI</category></item></channel></rss>
