Beersy

RexStarBSV

Beered by 0 people

11 standards · 7 topics

What RexStarBSV writes about

Wallet

3
  • 179

    Signed Capability Manifest for Wallet and Tool-Server Method Exposure

    A wallet or AI-agent tool server ends up with a long list of callable methods, and once a new method is registered it is simply live, with no signed record of exactly what was turned on and no way for anyone reviewing the build afterward to tell whether the exposed surface quietly grew. This makes it hard to trust that a wallet used by autonomous software, where a rogue or newly-added method could move funds or sign things, has actually been reviewed and locked down rather than just shipped.

    2026
  • 181

    Wallet-Enforced Autonomous-Agent Spend Policy

    An AI agent or automated script that holds a wallet's keys can be tricked or malfunction into sending money to the wrong place, and the usual safeguard, a human approving every transaction, defeats the whole point of letting software act on its own. Before this, a wallet could only grant a monthly spending ceiling to an app, which limits how much but says nothing about to whom, how fast, or under what conditions, so a single bad request could still drain the budget to an attacker.

    2026
  • 221

    Deterministic, Order-Independent Coin Selection for Privacy Wallets

    A wallet does not pick its own order for the spendable outputs it knows about; some outside source hands them over in whatever order that source chooses. If a privacy-focused wallet's logic for choosing which outputs to spend secretly depends on that order, the source can quietly steer which of the holder's keys get linked together in a payment, and rebuilding the "same" payment later can spend a different set of outputs than before, exposing both attempts to an observer.

    2026

Transactions

1
  • 237

    Payment Evidence Statements for BREAD and BEEF

    Two different wallets checking the same unconfirmed payment describe what they verified in totally different ways, so there is no way to compare "three hops back to a confirmed block" against "a valid BEEF" or to let an app set one acceptance rule that works regardless of which wallet it is talking to. This leaves users and apps guessing what was actually checked before goods change hands, with no shared way to say it.

    2026

Scripts

1
  • 215

    Block-Height Deadline Covenant Templates (OP_PUSH_TX)

    On BSV, the usual "spend after a certain block height" protections in Bitcoin scripts have been turned off, so there was no safe way to give one person a key that works right away and another person a key that only works after a deadline. Anyone trying to build this by hand could accidentally create a lock that looks safe but can actually be spent immediately, or one that can be used to jam the other party's ability to act before the deadline.

    2026

Tokens

2
  • 217

    Authenticated 1Sat Inscription

    If you inscribe content onto a Bitcoin satoshi, anyone can copy the exact bytes into a new output and claim they made it, because the inscription itself proves content existed but not who put it there. Meanwhile, naive ways of adding a signature or label to that output can accidentally make the coin permanently unspendable, freezing the token forever. This standard fixes the layout so you can prove authorship and still move the token.

    2026
  • 370

    Sealed 1Sat Ordinal Reveal

    A 1Sat Ordinal normally has its content sitting in plain view on the blockchain forever, which is useless for anything meant to stay private until a chosen moment or a chosen person, like an unopened collectible, a licensed file, or a credential. Before this, there was no agreed way to publish such content as encrypted data on that ordinal and later unlock it, either for everyone or for one named recipient, without putting the content back on chain again. This closes that gap so an owner can seal an ordinal once and decide later, and separately, whether the world or one person gets to read it.

    2026

Overlay services

1
  • 211

    Signed On-Chain Reachability Manifest

    A service can get cut off from its users when a domain registrar suspends a name, a host is seized, or an app store delists it, even though the service itself is still running fine. Normally there is no way for a client to find a service again once the one path it knew about disappears, short of shipping a brand new app update. This gives a client a way to rediscover the service through a record nobody can take down, because it lives on the blockchain.

    2026

Peer to peer

1

Applications

2
  • 216

    Dead-Man Timed Reveal of a Sealed Secret

    Sometimes a document should stay secret while its owner is alive and active, but come out automatically if that owner goes silent, like a journalist's files or a will. Before this, whoever held the decryption key could open the file whenever they liked, or lose it, and there was no way to tie "open it now" to a believable signal that the owner had actually stopped checking in. This makes it possible to split that trust across several people and have the release depend on an on-chain pattern of activity rather than on one person's word.

    2026

Search Beersy

Search standards by number, title, author or topic