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 1 person
20 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.
Wallet users end up locked into one backup method forever. If your wallet was set up with a written-down word phrase, you cannot later split your backup into shares you hand to trusted people, and if it was set up with shares, you cannot get a word phrase out of it. Someone switching wallets or wanting both options at once has been stuck picking one at creation time.
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.
Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.
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.
Right now if a wallet app wants to fetch a stored message or look up something on an overlay network, it usually has to trust one single server. If that server is slow, offline, or just decides to drop the data, the app has no backup and no way to reward whoever actually helps fastest. This makes it possible to have many independent servers compete to answer the same request, with the quickest and most honest ones getting paid automatically.
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.
If you sell access to a piece of content online, you either trust a server to keep hiding it forever, or you rely on an app just refusing to show the "restricted" part while the actual data sits in plain sight for anyone who looks. Buyers can't check what they're getting before they pay, and once the seller or platform disappears, so does access. This describes a way to encrypt the content once, publish it openly, and hand out the unlocking key only to people who actually paid or qualify, so access outlives the platform and can be checked in advance.
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