Multicast Transaction Frame Fragmentation
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
21 standards
Frames and fragmentation
A multicast packet has a fixed size and a transaction does not. Standards here define the frame layouts, how a large payload is split across frames, and how a receiver asks for the pieces that went missing.
Also searched as frame format, fragmentation, retransmission, shard, fountain code, packet.
Filed under
21 standards, spread across 3 of the 12 topics.
Start with
BRC-130
Multicast Transaction Frame Fragmentation
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
Filed under Transactions
Standards about this
Frames and fragmentation is the main subject of these 3.
130 141 Fountain-Coded Air-Gap Transport for Arbitrary Payloads
Getting data onto a machine deliberately kept off any network means moving it by eye through a camera. This sends it as a stream of QR codes that keeps going until the receiver has enough, so no missed frame needs re-showing.
225 Animated-QR Air-Gap Transport for Arbitrary Payloads (TKQR1)
Carrying data to an offline machine as QR codes fails if a single frame is missed and nobody notices. This frames it as plain text lines with checks that confirm the far side really reassembled the whole thing.
Standards that touch it
These are about something else, and deal with frames and fragmentation on the way.
12 Raw Transaction Format
Bitcoin transactions travel as raw bytes, and anyone writing software that reads or builds them needs to know exactly what those bytes mean. This documents that layout, field by field.
82 Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
Sending every transaction separately to every interested party wastes enormous bandwidth when they all want the same data. This proposes delivering it once to everyone who has asked, using the network's own one-to-many delivery.
118 Multipart Body Transport for BRC-105 Payments
A payment large enough to need several transactions will not fit in a web request header, where the payment scheme puts it. This moves the payment into the request body when it grows too big.
124 Multicast Transaction Frame Format
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
126 Multicast Transaction NACK Retransmission Protocol
One-to-many network delivery does not tell the sender when a piece went missing. This lets a receiver report exactly what it did not get, and the sender resend only that.
127 Multicast Subtree Group Announcement Frame Format
A receiver has to know which network group carries the slice of traffic it wants before it can subscribe. This has senders announce that mapping periodically, so a listener can join without being told out of band.
128 Multicast Extended Transaction Frame Format
The same frame is useful for a transaction that already carries the details needed to validate it on its own. This defines that variant while leaving the header untouched, so existing readers still work.
129 IPv6 Multicast Group Address Assignments
Splitting traffic across many network groups only works if everyone agrees which group is which. This assigns the address ranges, separating the groups carrying data from those carrying control messages.
131 Multicast Block Announcement Frame Format
Clients need to know when a new block arrives, and polling for it wastes time and bandwidth. This pushes the block's summary to everyone listening as soon as it exists.
132 Multicast Subtree Data Frame Format
Knowing a subtree exists is not the same as having the transaction hashes in it. This defines a frame carrying those contents to everyone subscribed, so nobody has to request them.
133 Multicast Coinbase Transaction Frame Format
The first transaction in a block is a special case, and it does not travel with the ordinary transaction stream. This says how it is carried and who receives it.
134 Multicast Anchor Transaction Frame Format
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
135 Multicast Block Header Frame Format
A client that only tracks block headers should not have to receive a whole block announcement to get one. This carries the eighty-byte header on its own.
142 Multicast Transaction Bundle Frame Format
Sending many tiny transactions as separate packets spends more on overhead than on content. This packs the ones heading the same way into a single frame.
143 Subtree Data Frame Format
The list of transaction hashes making up a subtree also needs to travel over an ordinary byte stream, not just one-to-many delivery. This defines that form and how a receiver takes it in.
144 Block Frame Format
A block pushed over a stream connection needs an agreed layout for its header, its parts and its first transaction. This defines it.
149 Multicast BEEF Object Frame Format
Once a second kind of object has its own space, it needs a frame to travel in and a route back for submissions. This defines those wire forms.
246 Session Upgrade: BRC-33 Messages over WebRTPayDraft (proposed number, not a BSVA assignment)
Two wallets that are both online right now still end up sending chat messages, item deliveries and coordination notices through a slow relay server meant for offline delivery, which adds delay for no reason. At the same time, two installs of the same account (like a phone and a laptop) have no good way to tell each other apart or talk directly. This fixes both by letting online wallets message each other straight over an existing direct connection instead.
Usually read alongside
Concepts that keep appearing on the same standards as this one.
Was this helpful?