Beersy

Darren Kellenschwiler

Beered by 1 person

24 standards · 8 topics

x.com/deggenAlso credited as [Deggen], Deggen

What Darren writes about

Wallet

2
  • 185

    Wallet Substrate Discovery, Selection, and Encrypted Mobile Connections

    Right now if you run two wallet-enabled apps on the same computer, or try to use your phone's wallet from a desktop browser, things break: one app grabs the only expected port, or whichever wallet loads last wins and silently takes over. There was no agreed way for an app to see what wallets are available, let the user pick one, and keep that choice stable without accidentally scrambling which wallet handles which connection.

    Ty Everett2026
  • 212

    Compact Wallet Feature Flags in `getVersion`

    A wallet reporting its version to an app used to need one chunky piece of text for every single feature it wanted to advertise, like "offline payments supported" or "color module supported". Stack up a dozen features and the version string blows past old length limits that some apps still enforce, so the wallet either hides capabilities or risks crashing the app. There was no cheap way to say "I support these twelve things" in the same space it used to take to say "I support this one thing".

    2026

Transactions

6
  • 58

    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.

    2023
  • 61

    Compound Merkle Path Format

    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.

    Damian Orzepowski2023
  • 71

    Merkle Path Binary Format

    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.

    2023
  • 74

    BSV Unified Merkle Path (BUMP) Format

    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.

    Tone Engel, Ty Everett +22023

Key derivation

2
  • 140

    Threshold Key Sharing and Backup via Shamir's Secret Sharing Scheme

    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.

    2026
  • 157

    Entropy-Rooted Backup and Recovery with Mnemonics and Backup Shares

    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.

    2026

Payments

6
  • 70

    Paymail BEEF Transaction

    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.

    2023
  • 121

    Simple 402 Payments

    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.

    2026
  • 125

    PeerPay URI Scheme for BRC-29 Payments

    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.

    2026
  • 175

    1Color Offline Peer-to-Peer Payments

    Paying someone with a digital token normally means checking in with an online service at the exact moment of payment, which fails in a shop with bad signal, on a train, or at a market stall. Cash does not have this problem. This describes a way for a payment to be handed over and trusted on the spot, with the online check happening later instead of during the handoff.

    2026
  • 228

    Unlinkable Payments under the Identity Paradigm

    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.

    Siggi Oskarsson2026
  • 235

    Paymail Public Profile Lookup

    A wallet that wants to pay someone usually has just a long string of random-looking characters, a public key, with no way to know if it really belongs to the person named by an email-like address such as alice@example.com. Flipping it around is just as broken: a wallet that just received a payment has no name to show for the sender, only that string of characters. There was no safe way to look a name up and get back a key you could trust, or to look up a key and get back a name.

    2026

Tokens

1
  • 92

    Mandala Token Protocol (Withdrawn)Withdrawn by the author.

    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.

    2024

Overlay services

2
  • 178

    Race-Settled Collection Markets for Overlay Lookups and Message Boxes

    Right now, if an app relies on a single server to hold and deliver messages or lookup results, that one server becomes the weak point: if it goes down, delays, or drops something, there is no backup and no way to reward anyone else for stepping in. This approach lets several independent hosts race to answer the same request, with the fastest honest ones getting paid automatically, so no single operator can quietly become a bottleneck or single point of failure.

    2026

Peer to peer

4
  • 85

    Proven Identity Key Exchange (PIKE)

    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.

    Damian Orzepowski2026
  • 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.

    2026
  • 369

    Keyed Content and Conditional Key Release

    Imagine selling a locked box online, but the "lock" is really just a sign that says "please don't look inside" while the contents sit in plain view for anyone who peeks at the underlying data. That's how paid content has actually been built on this chain: the restriction is a polite fiction, not a real barrier. This makes it possible to actually encrypt content once, publish it openly, and hand out the key only to people who paid or otherwise qualify, so access is real, survives the seller going offline, and gets more reliable the more people buy it.

    Crumbs, Elon Moist +12026

Applications

1

Search Beersy

Search standards by number, title, author or topic