Merkle Path JSON format
A lightweight client asking a service for proof that a transaction is in a block needs that proof in a form it can read over an ordinary web request. This gives it a plain readable shape rather than raw bytes.
Beered by 5 people
16 standards · 7 topics
A lightweight client asking a service for proof that a transaction is in a block needs that proof in a form it can read over an ordinary web request. This gives it a plain readable shape rather than raw bytes.
Sending proofs for several transactions separately repeats the same hashes over and over. This defines a compact form that carries proofs for many transactions at once with the shared parts included only once.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
Storing a proof in a database means keeping it small and quick to read back. This defines a compact binary shape for a single transaction's proof, aimed at storage rather than transmission.
Different proof formats each solved part of the problem, leaving processors and clients converting between them. This defines one format that is cheap for a transaction processor to produce and convenient for a client to check.
A proof spanning a whole block is larger than needed when the transactions of interest sit close together. This encodes the path within a subtree instead, which is smaller for that common case.
A single key is a single point of failure: lose it and everything is gone, and copying it multiplies the chance of theft. This splits it into pieces where a chosen number of them rebuild it and any fewer reveal nothing.
The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.
The full micropayment framework is more than a small service needs to charge for a single endpoint. This is the short version: a price and an identity key in the refusal, a payment in the retry.
Sharing where to send a payment usually means copying a long key and hoping it survived the paste. This packs the recipient and an optional amount into a single link that can be sent, tapped or turned into a QR code.
Token schemes tend to accumulate rules until they are hard to implement twice the same way. This keeps issuing, transferring, recovering and redeeming a token as small as it can reasonably be.
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.
Two people who want to transact need each other's public key, and sending it over a channel someone could tamper with is a real risk. This uses a short code shared out of band to confirm the key really came from the right person.
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.
Reaching someone online means knowing which service they are on, which stops being true the moment they move. This gives each person a readable handle that resolves wherever they actually are.
Every chat-style client invents its own commands, so what you learn in one is useless in the next. This fixes a common set of verbs that behave the same way everywhere.
Search standards by number, title, author or topic