Technik & KryptografieTechnology & CryptographyTecnología & CriptografíaTecnologia & Criptografia技術 & 暗号学技术 & 密码学التقنية & التشفير

BIP-32 und hierarchisch deterministische Wallets: Wie ein Seed Millionen Adressen erzeugtBIP-32 and HD Wallets: How One Seed Generates Millions of AddressesBIP-32 y billeteras jerárquicamente deterministas: Cómo una semilla genera millones de direccionesBIP-32 e carteiras hierarquicamente determinísticas: Como uma semente gera milhões de endereçosBIP-32と階層的決定論的ウォレット: シードが何百万のアドレスを生成する方法BIP-32和层次式确定性钱包:如何一个种子生成数百万个地址BIP-32 وwallets التحتية التنظيمية: كيف تُنشِأ ملايين العناوين من بذرة واحدة

79
EchtheitsprüfungAuthenticity checkVerificación de autenticidadVerificação de autenticidade真正性チェック真实性核查التحقق من الأصالة
Bewertung durch automatisierten Mehrquellen-Abgleich des KI-Redaktionsteams; anschließend menschlich freigegeben.Assessed via the AI newsroom's automated multi-source cross-check, then approved by a human.Evaluado mediante la verificación automatizada multifuente de la redacción de IA y aprobado por una persona.Avaliado pela verificação automatizada multifonte da redação de IA e aprovado por uma pessoa.AI編集部による自動マルチソース照合で評価し、人による承認を経ています。由AI编辑部的自动多源交叉核查评估,并经人工审核。جرى التقييم عبر التدقيق الآلي متعدد المصادر من غرفة أخبار الذكاء الاصطناعي، ثم اعتُمد بشريًا.
⚖️ Kritische Gegenperspektive (Regel des 10. Mannes)Critical counter-view (Tenth-Man rule)Perspectiva crítica alternativa (regla del décimo hombre)Perspectiva crítica contrária (regra do décimo homem)批判的な反対意見(10人目の法則)批判性的反向视角(第十人规则)منظور نقدي مضاد (قاعدة الرجل العاشر)

BIP-32 ist zwar ein eleganter Standard, doch seine Sicherheitsversprechen hängen von einer Kette von Voraussetzungen ab, die der Artikel nicht vollständig benennt: Ein offengelegter xpub kompromittiert die Privatsphäre eines gesamten Kontozweigs, und das Key-Leakage-Risiko bei normaler Ableitung setzt den Besitz des Chain Codes voraus – ein Nuancenunterschied, der für die Praxis entscheidend ist. Zudem orientieren sich viele Multi-Asset-Wallets nicht strikt an BIP-44-Pfaden, was zu Inkompatibilitäten beim Wallet-Wechsel führen kann. Die Darstellung als universell robustes System übersieht diese Grenzen.BIP-32 is an elegant standard, but its security guarantees depend on a chain of preconditions the article does not fully articulate: a leaked xpub compromises the privacy of an entire account branch, and the key-leakage risk in normal derivation additionally requires knowledge of the parent chain code – a nuance that matters in practice. Furthermore, many multi-asset wallets do not strictly follow BIP-44 paths, which can cause incompatibilities when migrating between wallets. Presenting the system as universally robust glosses over these real-world limitations.BIP-32 es un estándar elegante, pero sus promesas de seguridad dependen de una cadena de supuestos que el artículo no menciona completamente: Revelar un xpub compromete la privacidad de todo el ramo de cuentas, y el riesgo de filtración de claves al derivar normalmente requiere tener el Chain Code - una diferencia sutíl que es crucial para la práctica. Además, muchos billeteros multiactivos no siguen estrictamente los caminos BIP-44, lo que puede llevar a incompatibilidades al cambiar de billetera. La representación como un sistema universalmente robusto pasa por alto estos límites.O BIP-32 é certamente um padrão elegante, mas suas promessas de segurança dependem de uma cadeia de premissas que este artigo não aborda completamente: Revelar um xpub compromete a privacidade de todo o ramo de conta, e o risco de vazamento de chave em derivação normal pressupõe a posse do código da corrente - uma diferença de nuances crucial na prática. Além disso, muitos carteiras multi-ativo não seguem rigorosamente os caminhos BIP-44, o que pode levar a incompatibilidades ao mudar para outro cartão. A representação como um sistema universalmente robusto ignora essas limitações.BIP-32は、きれいな標準ですが、そのセキュリティーの約束は、一連の前提条件に依存しており、この記事が完全には示していません: xpubが公開された場合、全ての子鍵階層のプライバシーが破られます。また、通常の分岐では、チェーンコードの所有者がキーリークリスクを引き起こす必要があります - これは実践において決定的な違いです。さらに、多くのマルチアセットウォレットはBIP-44パスに厳格に従っていないことがあり、これによりウォレット交換時に互換性の問題が発生することがあります。この制限を無視して、全くロバストなシステムとして描かれています。BIP-32虽然是一个优雅的标准,但它的安全承诺取决于一系列假设,文章并没有完整列出:公开一个xpub会泄露整个账户分支的隐私,并且在正常派生情况下,Key-Leakage风险需要知道链码——这是对实践非常重要的一个细微差别。此外,大多数多资产钱包并不严格遵循BIP-44路径,这可能导致在更换钱包时出现兼容性问题。将其描绘为普遍强大的系统忽略了这些局限性。BIP-32 هو معيار فريد، لكن التزامنات الأمنية تتوقف على سلسلة من المتطلبات التي لا يغطي المقالها بشكل كامل: كشف xpub للعالم يتعرض خصوصية شجرة الحساب بأكمله للخطر، والخطر الناتج عن التسريب الكيوي عند الاستخراج العادي يتطلب امتلاك رمز السلسلة - اختلاف بسيط في التفاصيل هو الذي يكون مهمًا عمليًا. بالإضافة إلى ذلك، لا تستند أغلب محفظات الأصول المتعددة بشكل صارم إلى مسارات BIP-44 مما قد يؤدي إلى عدم compatibility عند تغيير المحفظة. تمثيله كنظام عام متين يتجاهي هذه الحدود.

Ein einziges Backup, unzählige Adressen: BIP-32 definiert, wie aus einem Master-Seed ein vollständiger Baum kryptografischer Schlüsselpaare entsteht. Der Ableitungspfad m/44'/0'/0'/0/0 ist dabei weit mehr als eine technische Adresse – er ist das Rückgrat jeder modernen Bitcoin-Wallet.One backup, countless addresses: BIP-32 defines how a single master seed produces a complete tree of cryptographic key pairs. The derivation path m/44'/0'/0'/0/0 is far more than a technical address – it is the backbone of every modern Bitcoin wallet.Un solo backup, incontables direcciones: BIP-32 define cómo un árbol completo de pares de claves criptográficas surge a partir de una semilla maestra. El camino de derivación m/44'/0'/0'/0/0 no es más que una dirección técnica - es la columna vertebral de cualquier billetera moderna de Bitcoin.Um único backup, incontáveis endereços: BIP-32 define como um seed mestre gera um conjunto completo de ramas com pares de chaves criptográficas. O caminho de derivação m/44'/0'/0'/0/0 é muito mais do que uma simples localização técnica - ele é a coluna vertebral de qualquer carteira moderna de Bitcoin.一つのバックアップ、無数のアドレス:BIP-32は、マスターシードから完全な鍵ペア木が生じる方法を定義します。枝番m/44'/0'/0'/0/0は、技術的なアドレスよりもはるかに多くのものです - これは、現代のビットコインウォレットの骨格です。一个唯一的备份,无数地址:BIP-32定义了如何从主种子中产生一个完整的加密密钥对树。路径m/44'/0'/0'/0/0实际上远不止是一种技术地址 - 它是现代比特币钱包的脊柱。نسخة واحدة، أعداد غير محدودة من العناوين: BIP-32 يحدد كيفية ظهور شجرة كاملة من الأزواج الكريبتوجرافية من خلال مفتاح الماستر. المسار التدرجي m/44'/0'/0'/0/0 ليس مجرد عنوان تكنولوجي - هو العمود الفقري لكل مستخلص بيتكوين الحديثة.

Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال

Wer heute eine Bitcoin-Wallet einrichtet, sichert 12 oder 24 Wörter – und kann damit Jahrzehnte später jede einzelne Adresse vollständig wiederherstellen. Diese scheinbar magische Eigenschaft ist das Ergebnis eines präzise definierten kryptografischen Standards: BIP-32, entwickelt von Pieter Wuille und 2012 veröffentlicht.

Vom Seed zum Schlüsselbaum: die kryptografische Basis

Ausgangspunkt ist ein 512-Bit-Master-Seed, der typischerweise aus einer BIP-39-Mnemonik (12 oder 24 Wörter) über 2.048 Iterationen PBKDF2-HMAC-SHA512 erzeugt wird. BIP-32 verarbeitet diesen Seed mit der Hashfunktion HMAC-SHA512 und teilt das 512-Bit-Ergebnis in zwei gleich große Hälften:

  • Master Private Key (256 Bit) – der geheime Wurzelschlüssel
  • Master Chain Code (256 Bit) – eine Entropie-Erweiterung, die alle weiteren Ableitungen beeinflusst

Alle Kindschlüssel werden anschließend deterministisch auf der elliptischen Kurve secp256k1 abgeleitet – demselben mathematischen Fundament, auf dem Bitcoin-Signaturen beruhen. Der Prozess ist vollständig reproduzierbar: Wer denselben Seed kennt, erhält exakt denselben Baum.

Der Ableitungsbaum: Struktur und Visualisierung

BIP-32 organisiert Schlüssel in einer Baumhierarchie. Jeder Knoten wird durch einen Ableitungspfad eindeutig beschrieben. Die Notation folgt diesem Schema:

m / purpose' / coin_type' / account' / change / address_index
Beispiel: m/44'/0'/0'/0/0

Ein vereinfachter Baum sieht so aus:

  • m – Master-Schlüssel (Wurzel)
  • m/44' – Purpose-Ebene (BIP-44-Standard)
  • m/44'/0' – Coin Type (0' = Bitcoin Mainnet)
  • m/44'/0'/0' – Account 0 (erstes Konto)
  • m/44'/0'/0'/0 – Externe Kette (Empfangsadressen)
  • m/44'/0'/0'/0/0 – Erste Empfangsadresse
  • m/44'/0'/0'/0/1 – Zweite Empfangsadresse … und so weiter
  • m/44'/0'/0'/1/0 – Erste interne Wechselgeldadresse

Pro Ebene existieren bis zu 232 (rund 4 Milliarden) mögliche Kindschlüssel – jeweils 231 normale und 231 gehärtete (Hardened) Ableitungen.

Hardened vs. normale Ableitung: ein kritischer Sicherheitsunterschied

Ein Apostroph (') im Pfad kennzeichnet eine Hardened Derivation. Der technische Unterschied ist sicherheitskritisch: Bei der normalen Ableitung reicht der öffentliche Elternschlüssel zusammen mit einem kompromittierten Kind-Privatschlüssel aus, um rechnerisch den übergeordneten Privatschlüssel zu rekonstruieren – ein Angriffspfad, der als „Key Leakage" bekannt ist. Hardened Derivation schließt diesen Vektor aus, weil sie zwingend den privaten Elternschlüssel als Eingabe verwendet.

Deshalb sind in BIP-44 die ersten drei Ebenen (purpose, coin_type, account) stets hardened. Der Grenzwert liegt bei Index 0x80000000 (= 231): Alles darüber ist hardened.

Extended Keys: Watch-Only-Wallets und Cold-Storage

BIP-32 definiert zwei besondere Schlüsselformate: xpub (Extended Public Key) und xprv (Extended Private Key). Beide sind 78-Byte-Datenstrukturen, Base58Check-kodiert, und enthalten neben dem eigentlichen Schlüssel auch Tiefe, Elternfingerprint, Child-Index und Chain Code.

Ein xpub erlaubt es, alle öffentlichen Schlüssel und damit alle Empfangsadressen eines gesamten Teilbaums zu generieren – ohne den privaten Schlüssel jemals offenzulegen. Dies ist die Grundlage für Watch-Only-Wallets und Hardware-Wallet-Setups, bei denen ein Online-Gerät Adressen beobachten kann, während der private Schlüssel offline bleibt.

Warum HD-Wallets Adress-Wiederverwendung strukturell verhindern

Adress-Wiederverwendung ist ein bekanntes Datenschutz- und Sicherheitsproblem bei Bitcoin: Sie verknüpft Transaktionen, macht Guthaben auf der Blockchain sichtbar und schwächt die Privatsphäre aller Beteiligten. HD-Wallets lösen dieses Problem architektonisch: Jede Transaktion kann – und sollte – eine neue Adresse aus einem neuen Pfadindex verwenden. Da alle Adressen deterministisch aus dem Seed abgeleitet werden, ist kein gesondertes Backup einzelner Adressen notwendig.

BIP-44, BIP-49, BIP-84: Erweiterungen auf BIP-32-Basis

BIP-32 ist das Fundament; darauf aufbauend standardisieren weitere BIPs konkrete Pfadstrukturen:

  • BIP-44: Multi-Account-Hierarchie für Legacy-Adressen (P2PKH), purpose' = 44'
  • BIP-49: P2SH-SegWit-Adressen, Pfad m/49'/0'/0'/0/x
  • BIP-84: Native SegWit (Bech32), Pfad m/84'/0'/0'/0/x

Alle drei ändern lediglich den purpose'-Wert und das Adressformat – die zugrunde liegende BIP-32-Ableitungslogik bleibt identisch.

Merksatz: Ein HD-Wallet speichert keine Adressen – es berechnet sie. Wer den Seed kennt, kennt den gesamten Baum. Wer den Seed verliert, verliert alles.

WeiterführendRelatedContinuandoContinuando更に進める进一步استمراريا

Anyone setting up a Bitcoin wallet today backs up 12 or 24 words – and can use them decades later to fully restore every single address. This seemingly magical property is the result of a precisely defined cryptographic standard: BIP-32, developed by Pieter Wuille and published in 2012.

From Seed to Key Tree: The Cryptographic Foundation

The starting point is a 512-bit master seed, typically derived from a BIP-39 mnemonic (12 or 24 words) via 2,048 iterations of PBKDF2-HMAC-SHA512. BIP-32 processes this seed with the hash function HMAC-SHA512 and splits the 512-bit output into two equal halves:

  • Master Private Key (256 bits) – the secret root key
  • Master Chain Code (256 bits) – an entropy extension that influences all further derivations

All child keys are then derived deterministically on the elliptic curve secp256k1 – the same mathematical foundation underlying Bitcoin signatures. The process is fully reproducible: anyone who knows the same seed obtains exactly the same tree.

The Derivation Tree: Structure and Visualization

BIP-32 organises keys in a tree hierarchy. Each node is uniquely described by a derivation path. The notation follows this schema:

m / purpose' / coin_type' / account' / change / address_index
Example: m/44'/0'/0'/0/0

A simplified tree looks like this:

  • m – Master key (root)
  • m/44' – Purpose level (BIP-44 standard)
  • m/44'/0' – Coin type (0' = Bitcoin mainnet)
  • m/44'/0'/0' – Account 0 (first account)
  • m/44'/0'/0'/0 – External chain (receiving addresses)
  • m/44'/0'/0'/0/0 – First receiving address
  • m/44'/0'/0'/0/1 – Second receiving address … and so on
  • m/44'/0'/0'/1/0 – First internal change address

Each level supports up to 232 (approximately 4 billion) possible child keys – 231 normal and 231 hardened derivations respectively.

Hardened vs. Normal Derivation: A Critical Security Distinction

An apostrophe (') in a path denotes hardened derivation. The technical difference is security-critical: with normal derivation, a parent's public key combined with a compromised child private key is sufficient to mathematically reconstruct the parent private key – an attack vector known as "key leakage". Hardened derivation closes this vector because it mandates the parent private key as input.

This is why in BIP-44 the first three levels (purpose, coin_type, account) are always hardened. The threshold index is 0x80000000 (= 231): everything at or above this value is hardened.

Extended Keys: Watch-Only Wallets and Cold Storage

BIP-32 defines two special key formats: xpub (Extended Public Key) and xprv (Extended Private Key). Both are 78-byte data structures encoded in Base58Check, containing not only the key itself but also depth, parent fingerprint, child index, and chain code.

An xpub makes it possible to generate all public keys – and therefore all receiving addresses – of an entire subtree, without ever exposing the private key. This is the foundation for watch-only wallets and hardware wallet setups, where an online device can monitor addresses while the private key remains offline.

Why HD Wallets Structurally Prevent Address Reuse

Address reuse is a well-known privacy and security problem in Bitcoin: it links transactions, exposes balances on the blockchain, and weakens the privacy of all parties involved. HD wallets solve this problem architecturally: every transaction can – and should – use a new address from a new path index. Because all addresses are derived deterministically from the seed, no separate backup of individual addresses is ever necessary.

BIP-44, BIP-49, BIP-84: Extensions Built on BIP-32

BIP-32 is the foundation; further BIPs standardise concrete path structures on top of it:

  • BIP-44: Multi-account hierarchy for legacy addresses (P2PKH), purpose' = 44'
  • BIP-49: P2SH-SegWit addresses, path m/49'/0'/0'/0/x
  • BIP-84: Native SegWit (Bech32), path m/84'/0'/0'/0/x

All three change only the purpose' value and address format – the underlying BIP-32 derivation logic remains identical.

Key takeaway: An HD wallet does not store addresses – it computes them. Whoever knows the seed knows the entire tree. Whoever loses the seed loses everything.

WeiterführendRelatedContinuandoContinuando更に進める进一步استمراريا

Quien configura hoy una cartera de Bitcoin guarda 12 o 24 palabras — y con ellas puede restaurar completamente cada dirección décadas después. Esta propiedad aparentemente mágica es el resultado de un estándar criptográfico definido con precisión: BIP-32, desarrollado por Pieter Wuille y publicado en 2012.

De la semilla al árbol de claves: la base criptográfica

El punto de partida es una semilla maestra de 512 bits, que típicamente se genera a partir de una mnemónica BIP-39 (12 o 24 palabras) mediante 2.048 iteraciones de PBKDF2-HMAC-SHA512. BIP-32 procesa esta semilla con la función hash HMAC-SHA512 y divide el resultado de 512 bits en dos mitades iguales:

  • Master Private Key (256 bits) — la clave raíz secreta
  • Master Chain Code (256 bits) – una extensión de entropía que influye en todas las derivaciones posteriores

Todas las claves hijo se derivan a continuación de forma determinista sobre la curva elíptica secp256k1 – el mismo fundamento matemático sobre el que se basan las firmas de Bitcoin. El proceso es completamente reproducible: quien conozca la misma semilla obtendrá exactamente el mismo árbol.

El árbol de derivación: estructura y visualización

BIP-32 organiza las claves en una jerarquía de árbol. Cada nodo queda descrito de forma unívoca mediante una ruta de derivación La notación sigue este esquema:

m / purpose' / coin_type' / account' / change / address_index
Ejemplo: m/44'/0'/0'/0/0

Un árbol simplificado tiene este aspecto:

  • m – Clave maestra (raíz)
  • m/44' – Nivel de propósito (estándar BIP-44)
  • m/44'/0' – Tipo de moneda (0' = Bitcoin Mainnet)
  • m/44'/0'/0' – Account 0 (primera cuenta)
  • m/44'/0'/0'/0 – Cadena externa (direcciones de recepción)
  • m/44'/0'/0'/0/0 – Primera dirección de recepción
  • m/44'/0'/0'/0/1 – Segunda dirección de recepción… y así sucesivamente
  • m/44'/0'/0'/1/0 – Primera dirección de cambio interna

Por nivel existen hasta 232 (aproximadamente 4 mil millones) de claves hijo posibles – 2 cada31 normales y 231 derivaciones endurecidas (Hardened).

Derivación reforzada vs. normal: una diferencia de seguridad crítica

Un apóstrofo (') en la ruta indica una Derivación reforzada. La diferencia técnica es crítica para la seguridad: en la derivación normal, basta con la clave pública del nodo padre junto con una clave privada hija comprometida para reconstruir matemáticamente la clave privada del nodo padre — un vector de ataque conocido como «Key Leakage». La derivación endurecida (Hardened Derivation) elimina esta vulnerabilidad al exigir obligatoriamente la clave privada del padre como entrada.

Por eso, en BIP-44 los tres primeros niveles (purpose, coin_type, account) son siempre hardened. El valor límite se sitúa en el índice 0x80000000 (= 231): todo lo que esté por encima es hardened.

Claves extendidas: carteras de solo lectura y almacenamiento en frío

BIP-32 define dos formatos de clave especiales: xpub (Extended Public Key) y xprv (Extended Private Key). Ambas son estructuras de datos de 78 bytes, codificadas en Base58Check, y contienen, además de la clave en sí, la profundidad, la huella del nodo padre, el índice del hijo y el código de cadena (Chain Code).

Un xpub permite generar todas las claves públicas y, con ello, todas las direcciones de recepción de un subárbol completo, sin revelar jamás la clave privada. Esta es la base de las carteras de solo lectura (Watch-Only Wallets) y las configuraciones de carteras de hardware, donde un dispositivo en línea puede monitorear direcciones mientras la clave privada permanece fuera de línea.

Por qué las carteras HD previenen estructuralmente la reutilización de direcciones

La reutilización de direcciones es un problema conocido de privacidad y seguridad en Bitcoin: vincula transacciones, hace visible el saldo en la blockchain y debilita la privacidad de todos los involucrados. Las carteras HD resuelven este problema de forma arquitectónica: cada transacción puede —y debería— utilizar una nueva dirección derivada de un nuevo índice de ruta. Como todas las direcciones se derivan de forma determinista a partir de la seed, no es necesario realizar copias de seguridad individuales de cada dirección.

BIP-44, BIP-49, BIP-84: extensiones basadas en BIP-32

BIP-32 es el fundamento; sobre él, otros BIPs estandarizan estructuras de rutas concretas:

  • BIP-44: jerarquía multi-cuenta para direcciones Legacy (P2PKH), purpose' = 44'
  • BIP-49: Direcciones P2SH-SegWit, ruta m/49'/0'/0'/0/x
  • BIP-84: Native SegWit (Bech32), ruta m/84'/0'/0'/0/x

Los tres únicamente cambian el valor de purpose'y el formato de dirección; la lógica de derivación BIP-32 subyacente permanece idéntica.

Regla mnemotécnica: Un monedero HD no almacena direcciones, las calcula Quien conoce la semilla conoce el árbol completo. Quien pierde la semilla, lo pierde todo.

Para profundizarRelatedContinuandoContinuando更に進める进一步استمراريا

Quem configura uma carteira Bitcoin hoje faz o backup de 12 ou 24 palavras – e pode usá-las décadas depois para restaurar completamente cada endereço. Essa propriedade aparentemente mágica é o resultado de um padrão criptográfico precisamente definido: o BIP-32, desenvolvido por Pieter Wuille e publicado em 2012.

Da Semente à Árvore de Chaves: a Base Criptográfica

O ponto de partida é uma semente mestre de 512 bits, tipicamente gerada a partir de uma mnemônica BIP-39 (12 ou 24 palavras) por meio de 2.048 iterações de PBKDF2-HMAC-SHA512. O BIP-32 processa essa semente com a função hash HMAC-SHA512 e divide o resultado de 512 bits em duas metades iguais:

  • Master Private Key (256 bits) – a chave raiz secreta
  • Master Chain Code (256 bits) – uma extensão de entropia que influencia todas as derivações subsequentes

Todas as chaves filhas são então derivadas deterministicamente na curva elíptica secp256k1 – o mesmo fundamento matemático sobre o qual se baseiam as assinaturas Bitcoin. O processo é totalmente reproduzível: quem conhece a mesma semente obtém exatamente a mesma árvore.

A Árvore de Derivação: Estrutura e Visualização

O BIP-32 organiza as chaves em uma hierarquia em forma de árvore. Cada nó é identificado de forma única por um caminho de derivação. A notação segue este esquema:

m / purpose' / coin_type' / account' / change / address_index
Exemplo: m/44'/0'/0'/0/0

Uma árvore simplificada tem a seguinte aparência:

  • m – Chave mestre (raiz)
  • m/44' – Nível de purpose (padrão BIP-44)
  • m/44'/0' – Coin type (0' = Bitcoin mainnet)
  • m/44'/0'/0' – Account 0 (primeira conta)
  • m/44'/0'/0'/0 – Cadeia externa (endereços de recebimento)
  • m/44'/0'/0'/0/0 – Primeiro endereço de recebimento
  • m/44'/0'/0'/0/1 – Segundo endereço de recebimento … e assim por diante
  • m/44'/0'/0'/1/0 – Primeiro endereço de troco interno

Cada nível suporta até 232 (cerca de 4 bilhões) de chaves filhas possíveis – sendo 231 derivações normais e 231 derivações reforçadas (hardened).

Derivação Hardened vs. Normal: uma Distinção de Segurança Crítica

Um apóstrofo (') no caminho indica uma derivação hardened. A diferença técnica é crítica para a segurança: na derivação normal, a chave pública pai combinada com uma chave privada filha comprometida é suficiente para reconstruir matematicamente a chave privada pai – um vetor de ataque conhecido como "key leakage". A derivação hardened elimina esse vetor, pois exige obrigatoriamente a chave privada pai como entrada.

Por isso, no BIP-44, os três primeiros níveis (purpose, coin_type, account) são sempre hardened. O índice limite é 0x80000000 (= 231): tudo a partir desse valor é hardened.

Extended Keys: Watch-Only Wallets e Cold Storage

O BIP-32 define dois formatos especiais de chave: xpub (Extended Public Key) e xprv (Extended Private Key). Ambos são estruturas de dados de 78 bytes codificadas em Base58Check, contendo não apenas a chave em si, mas também a profundidade, o fingerprint do pai, o índice filho e o chain code.

Um xpub permite gerar todas as chaves públicas – e, portanto, todos os endereços de recebimento – de toda uma subárvore, sem jamais expor a chave privada. Esta é a base para as watch-only wallets e configurações de hardware wallets, nas quais um dispositivo online pode monitorar endereços enquanto a chave privada permanece offline.

Por Que as HD Wallets Impedem Estruturalmente a Reutilização de Endereços

A reutilização de endereços é um problema bem conhecido de privacidade e segurança no Bitcoin: ela vincula transações, expõe saldos na blockchain e enfraquece a privacidade de todos os envolvidos. As HD wallets resolvem esse problema de forma arquitetural: cada transação pode – e deve – usar um novo endereço a partir de um novo índice de caminho. Como todos os endereços são derivados deterministicamente da semente, nunca é necessário fazer backup separado de endereços individuais.

BIP-44, BIP-49, BIP-84: Extensões Baseadas no BIP-32

O BIP-32 é o alicerce; sobre ele, outros BIPs padronizam estruturas de caminho concretas:

  • BIP-44: Hierarquia multi-conta para endereços legados (P2PKH), purpose' = 44'
  • BIP-49: Endereços P2SH-SegWit, caminho m/49'/0'/0'/0/x
  • BIP-84: Native SegWit (Bech32), caminho m/84'/0'/0'/0/x

Os três alteram apenas o valor de purpose' e o formato de endereço – a lógica de derivação BIP-32 subjacente permanece idêntica.

Conclusão essencial: Uma HD wallet não armazena endereços – ela os calcula. Quem conhece a semente conhece a árvore inteira. Quem perde a semente perde tudo.

WeiterführendRelatedContinuandoContinuando更に進める进一步استمراريا

今日 Bitcoin ウォレットを設定する人は、12語または24語を保存するだけで、何十年後でもすべてのアドレスを完全に復元できます。この一見魔法のような特性は、精密に定義された暗号標準の産物です: BIP-32、Pieter Wuille によって開発され、2012年に公開されました。

シードから鍵ツリーへ:暗号的な基盤

出発点となるのは 512ビットのマスターシードです。これは通常、BIP-39ニーモニック(12語または24語)から2,048回のイテレーションによるPBKDF2-HMAC-SHA512を用いて生成されます。BIP-32はこのシードをハッシュ関数 HMAC-SHA512 で処理し、512ビットの結果を等しい2つの部分に分割します:

  • マスター秘密鍵 (256ビット)― 秘密のルート鍵
  • マスターチェーンコード (256ビット)― 以降のすべての導出に影響するエントロピー拡張

すべての子鍵はその後、楕円曲線 secp256k1 上で決定論的に導出されます。これは Bitcoin 署名が依拠する数学的基盤と同じです。このプロセスは完全に再現可能です:同じシードを知っていれば、まったく同じツリーが得られます。

導出ツリー:構造と可視化

BIP-32は鍵をツリー階層で管理します。各ノードは 導出パス によって一意に識別されます。表記はこのスキームに従います:

m / purpose' / coin_type' / account' / change / address_index
例: m/44'/0'/0'/0/0

簡略化したツリーは次のようになります:

  • m ― マスター鍵(ルート)
  • m/44' ― Purposeレベル(BIP-44標準)
  • m/44'/0' ― コインタイプ(0' = Bitcoin メインネット)
  • m/44'/0'/0' ― アカウント0(最初のアカウント)
  • m/44'/0'/0'/0 ― 外部チェーン(受信アドレス)
  • m/44'/0'/0'/0/0 ― 最初の受信アドレス
  • m/44'/0'/0'/0/1 ― 2番目の受信アドレス … 以降同様
  • m/44'/0'/0'/1/0 ― 最初の内部おつりアドレス

各レベルには最大232 (約40億)通りの子鍵が存在します ― それぞれ231 通りの通常導出と231 通りのハードニング(Hardened)導出です。

Hardened と通常の導出:重要なセキュリティの違い

パス内のアポストロフィ(')は Hardened Derivationを示します。技術的な違いはセキュリティ上きわめて重要です:通常の導出では、親公開鍵と漏洩した子秘密鍵があれば、計算によって 上位の 秘密鍵を再構築できます ― これは「Key Leakage」として知られる攻撃経路です。Hardened Derivation は入力として必ず親秘密鍵を使用するため、このベクターを排除します。

そのため BIP-44 では最初の3レベル(purpose、coin_type、account)は常にハードニングされています。閾値はインデックス 0x80000000 (= 231です:これ以上はすべてハードニングされます。

拡張鍵:ウォッチオンリーウォレットとコールドストレージ

BIP-32は2つの特殊な鍵フォーマットを定義しています: xpub (Extended Public Key)と xprv (Extended Private Key)。どちらも78バイトのデータ構造でBase58Checkエンコードされており、鍵本体に加えて、深さ・親フィンガープリント・子インデックス・チェーンコードを含みます。

ひとつの xpub があれば、秘密鍵を一切開示することなく、サブツリー全体のすべての公開鍵、すなわちすべての受信アドレスを生成できます。これは ウォッチオンリーウォレット やハードウェアウォレットのセットアップの基盤となります。オンラインデバイスがアドレスを監視しつつ、秘密鍵はオフラインのまま保たれます。

HDウォレットがアドレス再利用を構造的に防ぐ理由

アドレスの再利用は Bitcoin におけるプライバシーとセキュリティの問題として広く知られています:トランザクションを紐付け、ブロックチェーン上の残高を可視化し、関係するすべての当事者のプライバシーを損ないます。HDウォレットはこの問題をアーキテクチャ上解決します:各トランザクションは新しいパスインデックスから得た新しいアドレスを使用できます(そして使用すべきです)。すべてのアドレスはシードから決定論的に導出されるため、個別アドレスのバックアップは不要です。

BIP-44、BIP-49、BIP-84:BIP-32を基盤とした拡張

BIP-32が基盤であり、その上に構築された各BIPが具体的なパス構造を標準化しています:

  • BIP-44:レガシーアドレス(P2PKH)のマルチアカウント階層、purpose' = 44'
  • BIP-49:P2SH-SegWitアドレス、パス m/49'/0'/0'/0/x
  • BIP-84:ネイティブSegWit(Bech32)、パス m/84'/0'/0'/0/x

これら3つはいずれも purpose'の値とアドレスフォーマットを変えるだけで、BIP-32の根本的な導出ロジックは変わりません。

まとめ: HDウォレットはアドレスを保存するのではなく、 計算 します。シードを知っている者はツリー全体を知ります。シードを失った者はすべてを失います。

さらに詳しくRelatedContinuandoContinuando更に進める进一步استمراريا

任何人在今天设置 Bitcoin 钱包时,都会备份 12 或 24 个助记词——并可在数十年后用它们完整恢复每一个地址。这种看似神奇的特性,源于一个精确定义的密码学标准:BIP-32,由 Pieter Wuille 开发,于 2012 年发布。

从种子到密钥树:密码学基础

起点是一个 512 位主种子(Master Seed),通常由符合 BIP-39 的助记词(12 或 24 个词)经过 2,048 次 PBKDF2-HMAC-SHA512 迭代生成。BIP-32 使用哈希函数 HMAC-SHA512 处理该种子,并将 512 位输出等分为两半:

  • Master Private Key(256 位)——秘密根密钥
  • Master Chain Code(256 位)——一种熵扩展,影响后续所有派生

所有子密钥随后在椭圆曲线 secp256k1 上确定性地派生——这与 Bitcoin 签名所基于的数学基础完全相同。整个过程完全可重现:任何知道相同种子的人都能获得完全相同的密钥树。

派生树:结构与可视化

BIP-32 将密钥组织成树状层级结构。每个节点由一个 派生路径 唯一标识。路径表示法遵循以下格式:

m / purpose' / coin_type' / account' / change / address_index
示例:m/44'/0'/0'/0/0

一棵简化的密钥树如下所示:

  • m – 主密钥(根节点)
  • m/44' – Purpose 层级(BIP-44 标准)
  • m/44'/0' – 币种类型(0' = Bitcoin 主网)
  • m/44'/0'/0' – 账户 0(第一个账户)
  • m/44'/0'/0'/0 – 外部链(接收地址)
  • m/44'/0'/0'/0/0 – 第一个接收地址
  • m/44'/0'/0'/0/1 – 第二个接收地址……以此类推
  • m/44'/0'/0'/1/0 – 第一个内部找零地址

每个层级最多支持 232(约 40 亿)个子密钥——其中 231 个为普通派生,231 个为硬化(Hardened)派生。

硬化派生与普通派生:关键的安全区别

路径中的撇号(')表示 硬化派生(Hardened Derivation)。二者的技术差异在安全上至关重要:在普通派生中,父公钥加上一个已泄露的子私钥,就足以在数学上还原出私钥——这一攻击向量被称为"密钥泄漏(Key Leakage)"。硬化派生通过强制以父钥作为输入,从根本上消除了这一风险。

因此,在 BIP-44 中,前三个层级(purpose、coin_type、account)始终采用硬化派生。临界索引值为 0x80000000(= 231):大于或等于该值的均为硬化派生。

扩展密钥:只读钱包与冷存储

BIP-32 定义了两种特殊密钥格式:xpub(Extended Public Key,扩展公钥)和 xprv(Extended Private Key,扩展私钥)。两者均为 78 字节的数据结构,以 Base58Check 编码,除密钥本身外,还包含深度、父指纹、子索引和链码。

xpub 允许生成整个子树的所有公钥及接收地址,而无需暴露私钥。这是 只读钱包(Watch-Only Wallets) 和硬件钱包方案的基础——在线设备可以监控地址,而私钥始终保持离线状态。

HD 钱包为何从结构上避免地址重用

地址重用是 Bitcoin 中众所周知的隐私与安全问题:它将多笔交易关联起来,使区块链上的余额一目了然,并损害所有相关方的隐私。HD 钱包从架构层面解决了这一问题:每笔交易都可以——也应该——使用来自新路径索引的新地址。由于所有地址都是从种子确定性派生的,因此无需单独备份各个地址。

BIP-44、BIP-49、BIP-84:基于 BIP-32 的扩展

BIP-32 是基础;在此之上,其他 BIP 进一步规范了具体的路径结构:

  • BIP-44:传统地址(P2PKH)的多账户层级,purpose' = 44'
  • BIP-49:P2SH-SegWit 地址,路径 m/49'/0'/0'/0/x
  • BIP-84:原生 SegWit(Bech32),路径 m/84'/0'/0'/0/x

三者仅改变了 purpose' 值和地址格式——底层 BIP-32 派生逻辑保持完全一致。

核心要点:HD 钱包不存储地址——它计算地址。知道种子,就掌握整棵密钥树。失去种子,则失去一切。

WeiterführendRelatedContinuandoContinuando更に進める进一步استمراريا

من يُنشئ محفظة Bitcoin اليوم يحفظ 12 أو 24 كلمة — وبها يستطيع استعادة كل عنوان بالكامل بعد عقود. هذه الخاصية التي تبدو سحرية هي نتاج معيار تشفيري محدد بدقة: BIP-32، طوّره Pieter Wuille ونُشر عام 2012.

من البذرة إلى شجرة المفاتيح: الأساس التشفيري

نقطة البداية هي Master Seed بحجم 512 بت، يُولَّد عادةً من عبارة BIP-39 التذكيرية (12 أو 24 كلمة) عبر 2.048 تكراراً باستخدام PBKDF2-HMAC-SHA512. تُعالج BIP-32 هذه البذرة بدالة التجزئة HMAC-SHA512 وتُقسّم الناتج البالغ 512 بت إلى نصفين متساويين:

  • Master Private Key (256 بت) — المفتاح الجذري السري
  • Master Chain Code (256 بت) – توسيع للإنتروبيا يؤثر على جميع الاشتقاقات اللاحقة

تُشتَق جميع المفاتيح الفرعية بعد ذلك بشكل حتمي على المنحنى الإهليلجي secp256k1 – وهو ذات الأساس الرياضي الذي تقوم عليه توقيعات Bitcoin. العملية قابلة للاستنساخ الكامل: من يعرف نفس البذرة (Seed) يحصل على نفس الشجرة بالضبط.

شجرة الاشتقاق: البنية والتمثيل البصري

ينظّم BIP-32 المفاتيح في تسلسل هرمي شجري. يُعرَّف كل عقدة بشكل فريد من خلال مسار الاشتقاق وتتبع الصياغة النمط التالي:

m / purpose' / coin_type' / account' / change / address_index
مثال: m/44'/0'/0'/0/0

تبدو شجرة مبسّطة على النحو الآتي:

  • m – المفتاح الرئيسي (الجذر)
  • m/44' – مستوى الغرض (معيار BIP-44)
  • m/44'/0' – نوع العملة (0' = Bitcoin Mainnet)
  • m/44'/0'/0' – الحساب 0 (الحساب الأول)
  • m/44'/0'/0'/0 – السلسلة الخارجية (عناوين الاستلام)
  • m/44'/0'/0'/0/0 – أول عنوان استلام
  • m/44'/0'/0'/0/1 – العنوان الثاني للاستلام … وهكذا دواليك
  • m/44'/0'/0'/1/0 – أول عنوان استرداد داخلي

يوجد في كل مستوى ما يصل إلى 232 (نحو 4 مليارات) مفتاح فرعي محتمل – لكل منهما 231 عادية و231 الاشتقاقات المُصلَّبة (Hardened).

الاشتقاق المُعزَّز مقابل الاشتقاق العادي: فارق أمني بالغ الأهمية

فاصلة عليا (') في المسار يشير إلى الاشتقاق المقوّى. الفارق التقني بالغ الأهمية من الناحية الأمنية: في الاشتقاق العادي، يكفي مفتاح الأصل العام مقروناً بمفتاح خاص فرعي مخترق لاستعادة المفتاح الخاص للمستوى الأعلى حسابياً — وهو مسار هجومي يُعرف بـ"Key Leakage". أما Hardened Derivation فيغلق هذا الثغرة كلياً، إذ يستلزم إلزامياً استخدام المفتاح الخاص للأصل كمدخل.

لذلك في BIP-44 تكون المستويات الثلاثة الأولى (purpose، وcoin_type، وaccount) مُقواة دائماً. وتقع حدّ الفصل عند الفهرس 0x80000000 (= 231): كل ما يزيد عليه يكون مُقوّى.

المفاتيح الموسّعة: محافظ المراقبة فقط والتخزين البارد

يُعرّف BIP-32 صيغتين خاصتين للمفاتيح: xpub (المفتاح العام الموسَّع) و xprv (المفتاح الخاص الموسَّع). كلاهما هيكل بيانات بحجم 78 بايت، مُرمَّز بـBase58Check، ويتضمن إلى جانب المفتاح الفعلي كلاً من: العمق، وبصمة الأصل، وفهرس الفرع، والـChain Code.

إن xpub يتيح توليد جميع المفاتيح العامة، وبالتالي جميع عناوين الاستلام لشجرة فرعية كاملة — دون الكشف عن المفتاح الخاص في أي وقت. وهذا هو الأساس الذي تقوم عليه المحافظ للمراقبة فقط (Watch-Only Wallets) وإعدادات محافظ الأجهزة، حيث يمكن لجهاز متصل بالإنترنت مراقبة العناوين بينما يظل المفتاح الخاص غير متصل بالشبكة.

لماذا تمنع محافظ HD إعادة استخدام العناوين من الناحية البنيوية

إعادة استخدام العناوين مشكلة معروفة تمس الخصوصية والأمان في Bitcoin: إذ تربط المعاملات ببعضها، وتكشف الأرصدة على البلوكشين، وتُضعف خصوصية جميع الأطراف المعنية. تحل محافظ HD هذه المشكلة على المستوى المعماري: فكل معاملة يمكنها — وينبغي لها — استخدام عنوان جديد مشتق من مؤشر مسار جديد. وبما أن جميع العناوين مشتقة بشكل حتمي من الـ Seed، فلا حاجة إلى نسخ احتياطية منفصلة للعناوين الفردية.

BIP-44 وBIP-49 وBIP-84: امتدادات مبنية على أساس BIP-32

BIP-32 هو الأساس؛ وبالاستناد إليه، تُقنّن BIPات أخرى هياكل مسارات محددة:

  • BIP-44: تسلسل هرمي متعدد الحسابات للعناوين القديمة (P2PKH)، purpose' = 44'
  • BIP-49: عناوين P2SH-SegWit، المسار m/49'/0'/0'/0/x
  • BIP-84: Native SegWit (Bech32)، المسار m/84'/0'/0'/0/x

الأنواع الثلاثة تغيّر فقط قيمة purpose'وصيغة العنوان — بينما تبقى منطق الاشتقاق الأساسي وفق BIP-32 مطابقًا تمامًا.

عبارة للحفظ: لا يخزّن HD Wallet العناوين — بل يحسبها من يعرف الـ Seed يعرف الشجرة بأكملها. ومن يفقد الـ Seed يفقد كل شيء.

لمزيد من المعلوماتذات صلةمتابعةمتابعةلمزيد من المعلومات进一步استمراريا

⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة

Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定,绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.

⚖️ BelegtSupportedConfirmadoConfirmado妥当成立مؤكَّد

„Ein Backup für alles” heißt zugleich: ein einziges Geheimnis, dessen Kompromittierung sämtliche Konten, Adressen und künftigen Schlüssel auf einmal preisgibt – gegenüber unabhängigen Einzelschlüsseln konzentriert BIP-32 das Risiko, statt es zu verringern.One backup for everything also means: a single secret whose compromise exposes every account, address, and future key at once — compared with independent individual keys, BIP-32 concentrates risk rather than reducing it.Una sola copia de seguridad para todo significa también: un único secreto cuya filtración expone de golpe todas las cuentas, direcciones y claves futuras; frente a claves individuales independientes, BIP-32 concentra el riesgo en lugar de reducirlo.Um único backup para tudo também significa: um único segredo cuja violação expõe de uma vez todas as contas, endereços e chaves futuras — em comparação com chaves individuais independentes, o BIP-32 concentra o risco em vez de reduzi-lo.「バックアップは一つで全部」は裏を返せば、たった一つの秘密が漏れれば全アカウント・全アドレス・将来の鍵まで一挙に露呈するということである。独立した個別鍵と比べ、BIP-32はリスクを減らすのではなく集中させている。「一份备份管一切」同时意味着:只要这一个秘密泄露,所有账户、地址乃至未来的密钥都会同时暴露——与相互独立的单个密钥相比,BIP-32是在集中风险,而非降低风险。«نسخة احتياطية واحدة لكل شيء» تعني أيضا: سرّ وحيد يؤدي اختراقه إلى كشف كل الحسابات والعناوين والمفاتيح المستقبلية دفعة واحدة — فمقارنة بالمفاتيح الفردية المستقلة، يركّز BIP-32 الخطر بدلا من تقليله.
Strukturell unbestreitbar und vom Artikel im Merksatz selbst eingeräumt („Wer den Seed kennt, kennt den gesamten Baum”): Der Komfortgewinn wird mit maximalem Blast-Radius erkauft. Die Einordnung als Rückgrat moderner Wallets bleibt korrekt – das Framing als reiner Sicherheitsgewinn nicht.Structurally undeniable and conceded by the article's own mnemonic (whoever knows the seed knows the entire tree): the convenience gain is bought with maximum blast radius. Calling BIP-32 the backbone of modern wallets remains correct — framing it as a pure security win does not.Estructuralmente innegable y admitido por la propia máxima del artículo (quien conoce la semilla conoce todo el árbol): la ganancia de comodidad se paga con un radio de daño máximo. Llamar a BIP-32 columna vertebral de las wallets modernas sigue siendo correcto; presentarlo como una pura ganancia de seguridad, no.Estruturalmente inegável e admitido pela própria máxima do artigo (quem conhece a seed conhece a árvore inteira): o ganho de conveniência é pago com raio de dano máximo. Chamar o BIP-32 de espinha dorsal das wallets modernas continua correto — apresentá-lo como puro ganho de segurança, não.構造的に否定しようがなく、記事自身の要点(シードを知る者は木全体を知る)が認めている通りである。利便性の獲得は最大の被害半径と引き換えである。BIP-32を現代ウォレットの背骨と位置づけるのは正しいままだが、純粋なセキュリティ向上として描くのは正しくない。这在结构上无可辩驳,文章自己的口诀也承认了这一点(知道种子就知道整棵树):便利性的获得是以最大爆炸半径为代价的。称BIP-32为现代钱包的支柱依然正确——但把它包装成纯粹的安全增益就不对了。أمر لا يُنكر بنيويا وقد أقرت به قاعدة المقال نفسها (من يعرف البذرة يعرف الشجرة كلها): مكسب الراحة يُدفع ثمنه بأقصى نطاق ضرر. يبقى وصف BIP-32 بأنه العمود الفقري للمحافظ الحديثة صحيحا — أما تأطيره كمكسب أمني خالص فلا.

⚖️ BelegtSupportedConfirmadoConfirmado妥当成立مؤكَّد

Das Key-Leakage-Risiko ist praxisrelevanter als dargestellt: Ein xpub wird für Watch-Only-Setups routinemäßig an Software und Dienste weitergegeben – und zusammen mit einem einzigen geleakten, nicht gehärteten Kind-Privatschlüssel lässt sich der übergeordnete Privatschlüssel rekonstruieren; der gesamte Kontozweig ist dann kompromittiert.The key-leakage risk is more practically relevant than portrayed: an xpub is routinely handed to software and services for watch-only setups — and combined with a single leaked non-hardened child private key, the parent private key can be reconstructed; the entire account branch is then compromised.El riesgo de fuga de claves es más relevante en la práctica de lo que se describe: un xpub se entrega rutinariamente a software y servicios para configuraciones watch-only, y combinado con una sola clave privada hija no endurecida que se filtre, puede reconstruirse la clave privada padre; toda la rama de la cuenta queda entonces comprometida.O risco de vazamento de chaves é mais relevante na prática do que o retratado: um xpub é entregue rotineiramente a softwares e serviços para configurações watch-only — e, combinado com uma única chave privada filha não endurecida que vaze, a chave privada pai pode ser reconstruída; todo o ramo da conta fica então comprometido.鍵漏洩リスクは記事の描写より実務的に重い。xpubはウォッチオンリー運用のためにソフトウェアやサービスへ日常的に渡される。そこに強化(hardened)されていない子秘密鍵が一つでも漏れれば、親の秘密鍵を再構成でき、アカウントの枝全体が危殆化する。密钥泄露风险在实践中比文章描绘的更严重:为了实现观察钱包,xpub会被例行地交给各种软件和服务——而只要再泄露一个非强化派生的子私钥,就能重构出父私钥;届时整个账户分支都被攻陷。خطر تسرب المفاتيح أهم عمليا مما صُوِّر: يُسلَّم الـxpub بشكل روتيني للبرمجيات والخدمات في إعدادات المراقبة فقط — ومع تسرب مفتاح خاص فرعي واحد غير مقوّى، يمكن إعادة بناء المفتاح الخاص الأب؛ وعندها يُخترق فرع الحساب بأكمله.
Die Eigenschaft steht so in der BIP-32-Spezifikation selbst – kein exotischer Angriff, sondern ein dokumentierter Design-Trade-off. Der Artikel nennt den Mechanismus korrekt, unterschätzt aber, wie routinemäßig xpubs in der Praxis geteilt werden, inklusive des vollständigen Privatsphäre-Verlusts über den betroffenen Teilbaum.The property is stated in the BIP-32 specification itself — not an exotic attack but a documented design trade-off. The article names the mechanism correctly but underestimates how routinely xpubs are shared in practice, including the complete privacy loss over the affected subtree.La propiedad figura en la propia especificación de BIP-32: no es un ataque exótico, sino un trade-off de diseño documentado. El artículo nombra correctamente el mecanismo, pero subestima lo rutinario que es compartir xpubs en la práctica, incluida la pérdida total de privacidad sobre el subárbol afectado.A propriedade consta da própria especificação do BIP-32 — não é um ataque exótico, mas um trade-off de design documentado. O artigo nomeia o mecanismo corretamente, mas subestima o quão rotineiro é compartilhar xpubs na prática, incluindo a perda total de privacidade sobre a subárvore afetada.この性質はBIP-32仕様そのものに明記されており、突飛な攻撃ではなく文書化された設計上のトレードオフである。記事はメカニズムを正しく挙げているが、実務でxpubがどれほど日常的に共有されているか、そして該当サブツリー全体のプライバシーが完全に失われる点を過小評価している。这一性质就写在BIP-32规范本身之中——不是什么冷门攻击,而是有文档记录的设计权衡。文章正确指出了机制,却低估了实践中xpub被例行共享的普遍程度,包括受影响子树隐私的彻底丧失。هذه الخاصية منصوص عليها في مواصفة BIP-32 نفسها — ليست هجوما نادرا بل مفاضلة تصميم موثقة. يذكر المقال الآلية بشكل صحيح لكنه يقلل من مدى روتينية مشاركة الـxpub عمليا، بما في ذلك الفقدان الكامل للخصوصية على الشجرة الفرعية المعنية.

⚖️ BelegtSupportedConfirmadoConfirmado妥当成立مؤكَّد

Das Wiederherstellungs-Versprechen „der Seed genügt” gilt nur eingeschränkt: Ohne Kenntnis von Ableitungspfad, Skripttyp und Gap-Limit findet eine andere Wallet vorhandene Guthaben oft nicht – nicht standardisierte Pfade vieler Wallets machen Restore-Probleme zu einem dokumentierten Alltagsphänomen.The recovery promise that the seed suffices holds only with caveats: without knowledge of derivation path, script type, and gap limit, another wallet often fails to find existing funds — the non-standard paths of many wallets make restore problems a documented everyday phenomenon.La promesa de recuperación de que basta con la semilla solo vale con reservas: sin conocer la ruta de derivación, el tipo de script y el gap limit, otra wallet a menudo no encuentra los fondos existentes; las rutas no estandarizadas de muchas wallets convierten los problemas de restauración en un fenómeno cotidiano documentado.A promessa de recuperação de que a seed basta só vale com ressalvas: sem conhecer o caminho de derivação, o tipo de script e o gap limit, outra wallet muitas vezes não encontra os fundos existentes — os caminhos não padronizados de muitas wallets tornam problemas de restauração um fenômeno cotidiano documentado.「シードさえあれば復元できる」という約束は条件付きでしか成り立たない。導出パス、スクリプトタイプ、ギャップリミットを知らなければ、別のウォレットは既存の残高をしばしば発見できない。多くのウォレットの非標準パスにより、復元トラブルは記録に残る日常的現象となっている。「有种子就够了」的恢复承诺只在有限条件下成立:如果不知道派生路径、脚本类型和gap limit,换一个钱包常常找不到已有资金——许多钱包使用非标准路径,使恢复难题成为有据可查的日常现象。وعد الاستعادة القائل إن البذرة تكفي لا يصح إلا بتحفظات: فبدون معرفة مسار الاشتقاق ونوع السكربت وحد الفجوة، كثيرا ما تعجز محفظة أخرى عن العثور على الأرصدة الموجودة — والمسارات غير المعيارية لدى محافظ كثيرة تجعل مشاكل الاستعادة ظاهرة يومية موثقة.
Projekte wie walletsrecovery.org existieren genau deshalb: Sie katalogisieren wallet-spezifische Pfade, weil „12 Wörter reichen” in der Praxis regelmäßig scheitert. Moderne Output-Descriptors adressieren das Problem, sind aber noch nicht universell verbreitet – der Einwand trifft den heutigen Ist-Zustand.Projects like walletsrecovery.org exist for exactly this reason: they catalog wallet-specific paths because twelve words suffice regularly fails in practice. Modern output descriptors address the problem but are not yet universally adopted — the objection describes the current state accurately.Proyectos como walletsrecovery.org existen exactamente por eso: catalogan las rutas específicas de cada wallet porque lo de que doce palabras bastan falla con regularidad en la práctica. Los descriptores de salida modernos abordan el problema, pero aún no están universalmente adoptados; la objeción describe con precisión el estado actual.Projetos como o walletsrecovery.org existem exatamente por isso: catalogam os caminhos específicos de cada wallet porque doze palavras bastam falha com regularidade na prática. Os descritores de output modernos atacam o problema, mas ainda não são universalmente adotados — a objeção descreve com precisão o estado atual.walletsrecovery.orgのようなプロジェクトがまさにこの理由で存在する。「12単語で足りる」が実務でたびたび破綻するからこそ、ウォレット固有のパスを目録化しているのである。現代のアウトプットディスクリプタはこの問題に対処するが、まだ普遍的には普及しておらず、この反論は現状を正確に言い当てている。walletsrecovery.org这类项目的存在恰恰证明了这一点:正因为「12个词就够了」在实践中屡屡失灵,才需要为各钱包的专有路径编目。现代的输出描述符(descriptor)在解决这一问题,但尚未普及——该反驳准确描述了当下的现实。مشاريع مثل walletsrecovery.org توجد لهذا السبب بالذات: فهي تفهرس المسارات الخاصة بكل محفظة لأن مقولة «12 كلمة تكفي» تفشل عمليا مرارا. وتعالج واصفات المخرجات الحديثة المشكلة لكنها لم تُعتمد عالميا بعد — فالاعتراض يصف الوضع الراهن بدقة.

⚖️ WiderlegtRefutedRefutadoRefutado反証済み已反驳مدحوض

Wer Milliarden Schlüssel aus einem einzigen Seed ableitet, erzeugt mathematisch verwandte Schlüssel – das müsse kryptografisch schwächer sein als unabhängig erzeugte Zufallsschlüssel.Deriving billions of keys from a single seed produces mathematically related keys — that must be cryptographically weaker than independently generated random keys.Derivar miles de millones de claves de una sola semilla produce claves matemáticamente relacionadas; eso tendría que ser criptográficamente más débil que claves aleatorias generadas de forma independiente.Derivar bilhões de chaves de uma única seed produz chaves matematicamente relacionadas — isso teria de ser criptograficamente mais fraco do que chaves aleatórias geradas de forma independente.一つのシードから何十億もの鍵を導出すれば、数学的に関連し合う鍵が生まれる。それは独立に生成されたランダム鍵より暗号学的に弱いはずだ、という反論である。从同一个种子派生数十亿个密钥,会产生数学上相互关联的密钥——这理应比独立生成的随机密钥在密码学上更弱。اشتقاق مليارات المفاتيح من بذرة واحدة ينتج مفاتيح مترابطة رياضيا — ولا بد أن يكون ذلك أضعف تشفيريا من مفاتيح عشوائية مولَّدة باستقلال.
Für Außenstehende ohne Elternschlüssel bzw. Chain Code sind BIP-32-Kindschlüssel dank der HMAC-SHA512-Konstruktion rechnerisch nicht von unabhängigen Zufallsschlüsseln zu unterscheiden; seit 2012 ist kein Angriff bekannt, der allein die Determinismus-Eigenschaft ausnutzt. Der einzige echte Bruch ist der im Standard selbst dokumentierte xpub-plus-Kindschlüssel-Fall – ein anderes Szenario.For outsiders without the parent key or chain code, BIP-32 child keys are computationally indistinguishable from independent random keys thanks to the HMAC-SHA512 construction; since 2012 no attack is known that exploits the determinism property alone. The only genuine break is the xpub-plus-child-key case documented in the standard itself — a different scenario.Para terceros sin la clave padre ni el chain code, las claves hijas de BIP-32 son computacionalmente indistinguibles de claves aleatorias independientes gracias a la construcción HMAC-SHA512; desde 2012 no se conoce ningún ataque que explote solo la propiedad determinista. La única ruptura genuina es el caso xpub más clave hija documentado en el propio estándar, que es otro escenario.Para terceiros sem a chave pai nem o chain code, as chaves filhas do BIP-32 são computacionalmente indistinguíveis de chaves aleatórias independentes graças à construção HMAC-SHA512; desde 2012 não se conhece ataque que explore apenas a propriedade determinística. A única quebra genuína é o caso xpub mais chave filha documentado no próprio padrão — um cenário diferente.親鍵やチェーンコードを持たない外部者にとって、BIP-32の子鍵はHMAC-SHA512構成のおかげで独立なランダム鍵と計算量的に区別できない。2012年以来、決定論性だけを突く攻撃は一つも知られていない。唯一の本物の破れは、標準自身に記載されたxpubと子秘密鍵の組み合わせのケースであり、それは別のシナリオである。对于不掌握父密钥或链码的外部人而言,得益于HMAC-SHA512构造,BIP-32子密钥在计算上与独立随机密钥不可区分;自2012年以来,没有任何已知攻击仅凭确定性这一性质得手。唯一真实的破绽是标准自身记载的xpub加子私钥情形——那是另一种场景。بالنسبة لطرف خارجي لا يملك المفتاح الأب ولا رمز السلسلة، لا يمكن حسابيا تمييز مفاتيح BIP-32 الفرعية عن مفاتيح عشوائية مستقلة بفضل بنية HMAC-SHA512؛ ومنذ 2012 لا يُعرف أي هجوم يستغل خاصية الحتمية وحدها. الاختراق الحقيقي الوحيد هو حالة xpub مع مفتاح فرعي الموثقة في المعيار نفسه — وهي سيناريو مختلف.

QuellenSourcesFuentesFontes出典来源المصادر

TransparenzhinweisTransparency noticeAviso de transparenciaAviso de transparência透明性に関するお知らせ透明度声明إشعار الشفافية  Dieser Bericht wurde von einem KI-Agenten-Team recherchiert, faktengeprüft (Mehrquellen-Abgleich) und redaktionell verfasst, anschließend menschlich freigegeben. Echtheits-Score: 79/100. Bitte Primärquellen prüfen.  This report was researched, fact-checked (multi-source cross-checking) and written by an AI agent team, then approved by a human. Authenticity score: 79/100. Please verify primary sources. Este informe fue investigado, verificado (contraste de múltiples fuentes) y redactado por un equipo de agentes de IA, y posteriormente aprobado por una persona. Puntuación de autenticidad: 79/100. Por favor, consulte las fuentes primarias. Este relatório foi pesquisado, verificado (cruzamento de múltiplas fontes) e redigido por uma equipe de agentes de IA, e posteriormente aprovado por um ser humano. Pontuação de autenticidade: 79/100. Por favor, verifique as fontes primárias. 本レポートはAIエージェントチームが調査・ファクトチェック(複数情報源の照合)・執筆を行い、その後人間が承認したものです。信頼性スコア:79/100。一次情報源のご確認をお願いします。 本报告由AI智能体团队负责调研、事实核查(多来源交叉比对)和撰写,并经人工审核批准。真实性评分:79/100。请自行核实原始资料来源。 تم البحث في هذا التقرير والتحقق من حقائقه (بمقارنة مصادر متعددة) وكتابته من قِبل فريق من وكلاء الذكاء الاصطناعي، ثم اعتُمد من قِبل إنسان. درجة الأصالة: 79/100. يُرجى التحقق من المصادر الأولية.

Zurück zur News-ÜbersichtBack to all newsVolver a todas las noticiasVoltar para todas as notíciasニュース一覧に戻る返回新闻总览العودة إلى جميع الأخبار