BIP 15 Bitcoin aliases explained as a closed proposal for human-readable payment identities, including discovery, authentication and substitution risks.
This guide explains BIP 15 Bitcoin aliases in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 15 Bitcoin aliases: BIP 15 did not become the deployed universal alias layer. Wallets should not interpret an arbitrary name according to this proposal or present it as native Bitcoin functionality.
A node operator is checking BIP 15 Bitcoin aliases. A perfectly valid Bitcoin transaction can still pay an attacker if name resolution was compromised. Usability improves only when the identity-to-address binding is authenticated and visible to the payer.
Readable identities can reduce copying errors and let a merchant update destination infrastructure without changing printed material. The resolver becomes a new trusted layer, however. A perfectly valid Bitcoin transaction can still pay an attacker if name resolution was compromised. Usability improves only when the identity-to-address binding is authenticated and visible to the payer.
BIP 15 considered using established internet naming and service discovery to locate payment information associated with an alias. Each DNS lookup, redirect and endpoint adds availability and substitution assumptions. Operators must distinguish authenticated records from transport that merely returned data, and they need a safe failure mode when discovery is unavailable or contradictory.
Certificate-backed responses can bind a domain or service endpoint under a public-key infrastructure, but the certificate proves control under that system, not the commercial truth of every payment request. Users still need a recognisable identity and amount confirmation. Expiry, revocation, compromised authorities and changed ownership must be part of the threat model.
A resolver can issue a fresh address per request, improving on public static reuse. It can also learn who requested payment details, at what time and from which network location. Logs link aliases to transaction activity. A privacy claim should state what the resolver, network observer, merchant and blockchain analyst can each see.
Retention periods, analytics tags and third-party DNS infrastructure belong in that assessment rather than being treated as unrelated web operations.
BIP 15 did not become the deployed universal alias layer. Wallets should not interpret an arbitrary name according to this proposal or present it as native Bitcoin functionality. Modern naming and payment protocols have their own specifications and trust models. Historical compatibility should be isolated and clearly labelled rather than silently guessed.
BIP 21 standardises payment URIs but does not turn a human name into an authenticated destination. Lightning offers use-case-specific invoice and offer mechanisms, while external naming systems can map identities under separate rules. Operators should compare authentication, privacy, revocation, replay and fallback instead of assuming every readable payment identifier provides equivalent assurance.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 15 Bitcoin aliases: BIP 15 did not become the deployed universal alias layer. Wallets should not interpret an arbitrary name according to this proposal or present it as native Bitcoin functionality.
Readable identities can reduce copying errors and let a merchant update destination infrastructure without changing printed material.
BIP 15 considered using established internet naming and service discovery to locate payment information associated with an alias.
Certificate-backed responses can bind a domain or service endpoint under a public-key infrastructure, but the certificate proves control under that system, not the commercial truth of every payment request.
BIP 15 anticipated the demand for readable Bitcoin payment identities, but it did not become a deployed standard. Any modern alias system must be evaluated as a separate authenticated resolver with explicit privacy, expiry, substitution and fallback controls.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 128 guide to Draft timelock-recovery plan storage, presigned transaction pairs, relative delay, checksums, monitoring, cancellation and reorg safety.
BIP 433 guide to Draft keyless Pay to Anchor outputs, CPFP fee bumping, standardness, ephemeral dust, TRUC anti-pinning and wallet safety.
What is BIP-110? Learn what Bitcoin’s reduced-data soft-fork proposal restricted, why it was controversial and why it later closed.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.