18 standards
Two parties hold overlapping data and have to agree on it: a wallet and its backup, two overlay hosts, or a client resuming a query it was part way through. Standards here define how the catching up happens.
Also searched as sync, replication, resumable, graph aware, reconciliation.
18 standards, spread across 5 of the 12 topics.
Finding your own application's data on the blockchain means either scanning everything or trusting somebody else's index. This defines how to submit transactions to a service that tracks only the subset you care about, and how it reports back what it accepted.
Filed under Overlay services
Synchronization is the main subject of these 5.
Finding your own application's data on the blockchain means either scanning everything or trusting somebody else's index. This defines how to submit transactions to a service that tracks only the subset you care about, and how it reports back what it accepted.
Moving a wallet between storage providers, or keeping two of them in step, otherwise needs custom code for every pairing. This defines a resumable synchronisation protocol so independent providers can exchange wallet state directly.
Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.
Indexes need to find each other and stay in step, and doing that ad hoc leaves gaps. This defines how they announce what they track and what they answer, and how they synchronise once found.
An index cannot easily prove it has seen everything relevant in a block rather than most of it. This gives a per-block summary that makes completeness checkable rather than assumed.
These are about something else, and deal with synchronization on the way.
Raw transaction bytes are compact but almost impossible to search or filter. This describes a structured representation of the same data that can be stored in an ordinary document database and queried like any other record.
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
Wallet data trapped inside one provider's software is a problem for the user who wants to leave and for anyone who has to answer a data request. This defines a single portable file holding everything about one user's wallet.
Handling very high transaction volume means doing as much as possible at the same time, while some checks must still happen in order. This describes how that work is divided across the network so throughput rises without correctness slipping.
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.
Nothing tells a participant which slices of the traffic anyone else is actually carrying. This has each one announce what it holds, so the gaps become visible.
A block pushed over a stream connection needs an agreed layout for its header, its parts and its first transaction. This defines it.
The address space carrying transactions was not designed to carry anything else, so a second kind of object has nowhere to go. This divides it into planes, giving each kind of object its own room.
Large files are usually treated as one indivisible blob: you can't name it until the whole thing has finished uploading, a single failed byte range means retrying the entire download, and there's no way to prove a partial chunk actually belongs to the file it claims to be part of. This makes streaming uploads, resumable downloads, and safe partial reads of big files awkward or impossible with simple whole-file hashing.
Different Bitcoin-based apps use the word "overlay" for two very different setups: one where every server is supposed to agree on the exact same data, and one where servers legitimately hold different, non-matching collections. When people conflate these, it becomes unclear whether a mismatch between two servers is a bug to fix or just two valid, different answers.
Pulling a large, constantly changing list of overlay results used to force a choice between getting a stable view that quickly goes stale, or watching live updates and losing track of what you already saw if your connection dropped. There was no safe way to read the current state of something and then keep watching it change without missing an update that happened during a disconnect. This gives a reader a consistent starting snapshot plus a way to pick back up exactly where it left off, even after going offline.
When a wallet or app stops endorsing an advertisement, or a root decides it no longer wants to show one, there has been no shared, attributable way to ask a server to stop serving that one specific record without pretending to be a global ban or an on-chain spend. Without it, roots either ignore stale or withdrawn ads forever or quietly drop them with no record of who asked or why, and restoring one later is guesswork.
A wallet backup can be restored on more than one phone or laptop, but if two devices both treat the same account as theirs to spend from, they can each build a payment from coins the other has already spent, and the blockchain will only accept one of them. Before this, the only fix was asking a server before every payment, which is slow and breaks when offline. This makes it possible to keep a vault's accounts spread across several trusted devices safely, without that per-payment check.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic