This document evaluates BIP-110 using principles associated with IETF rough consensus and engineering review.
It does not assess any particular activation mechanism, signaling threshold, deployment schedule, or political campaign. Its scope is limited to the technical problem identified by BIP-110, the proposed restrictions, and the substantive objections that have been raised.
Bitcoin Core v30 and later relay, index, and expose up to 100,000 bytes of arbitrary OP_RETURN data by default. When an attacker embeds a self-rendering Data URI (e.g., data:image/*;base64,…) inside an OP_RETURN output, Bitcoin Core stores the content and makes it accessible through standard JSON-RPC and REST interfaces. Any client retrieving the transaction through these interfaces receives the Data URI in cleartext, which can be immediately rendered by a web browser or other HTTP-capable software without specialized tooling.
This behavior may unintentionally cause node operators to store, retrieve, or serve content that is harmful, illegal, or high-risk, creating operational, security, and legal exposure for downstream systems.
The Hyper Agent Protocol (HAP) is a new, simplified standard for how software "agents" (or any automated services and capabilities) communicate with each other over the web. Imagine a universal way for different software components to discover what other components can do and then ask them to do it, all using standard web technologies.
The goal of HAP is to make it much easier to build flexible, interoperable systems where different services, tools, or AI agents can work together seamlessly, regardless of how they are built internally.
This document outlines the key functionalities of the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol, derived from their respective JSON schema definitions (schema.json for MCP, dated 2025-03-26, and a2a.json for A2A). It then presents a comparative table to identify common and unique functionalities and analyze interoperability.
Derived from schema.json. MCP facilitates interactions between a "client" (e.g., an LLM-hosting environment or agent framework) and a "server" (providing tools, resources, or prompts).
initialize: Client initiates connection with the server, exchanging capabilities (ClientCapabilities, ServerCapabilities), protocol versions, and implementation information.ping: Client sends to server to check liveness and ensure the connection is active.resources/list: Client requests a list of available data resources from the server.
A call for autonomy, dignity, and trust in the age of intelligent agents.
Agents are extensions of human will—not proxies for corporations. They must act in the user’s interest, not in the interest of advertisers, platforms, or centralized authorities.
Introducing Nostr Ricardian Contracts
Nostr Ricardian Contracts combine the clarity of human-readable, legally enforceable agreements with the cryptographic certainty and decentralization of smart contracts on Bitcoin layers. This innovative approach leverages Nostr, a decentralized messaging protocol, to publish signed human-readable legal agreements that accompany traditional smart contract logic running on Bitcoin-based layers such as RGB, Discreet Log Contracts (DLC), Liquid, or Lightning Network.
Human-Readable Clarity: Each contract includes a clearly written, legally interpretable text detailing the contractual terms, signed and timestamped as a Nostr note.
Cryptographic Certainty:
Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.
15-minute talk summarizing the protocol
Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.
| nip | TBD |
|---|---|
| title | Linked Subkeys for Multi-Device Nostr Usage |
| status | Draft |
| author | Melvin Carvalho |
| created | 26-02-2025 |
| discussions-to | nostr-protocol/nips#1810 |