Technik & KryptografieTechnology & CryptographyTecnología & CriptografíaTecnologia & Criptografia技術 & 暗号学技术 & 密码学التقنية & التشفير
SegWit verstehen: Warum die Signatur-Trennung Bitcoin gerettet hatUnderstanding SegWit: Why Separating Signatures Saved BitcoinSegWit explicado: Por qué separar las firmas salvó a BitcoinEntendendo o SegWit: Por Que a Separação de Assinaturas Salvou o BitcoinSegWitを理解する：署名の分離がBitcoinを救った理由理解 SegWit：为何分离签名拯救了 Bitcoinفهم SegWit: لماذا أنقذ فصل التوقيعات Bitcoin
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编辑部的自动多源交叉核查评估，并经人工审核。جرى التقييم عبر التدقيق الآلي متعدد المصادر من غرفة أخبار الذكاء الاصطناعي، ثم اعتُمد بشريًا.
SegWit löste reale technische Probleme – doch der Artikel verschweigt, dass seine Aktivierung einen der größten Konflikte in Bitcoins Geschichte auslöste und letztlich zur BCH-Abspaltung führte. Die Darstellung von Transaction Malleability als zentralem Mt.-Gox-Faktor ist eine nachträgliche Vereinfachung: Regulatorische Versäumnisse, interne Kontrollschwächen und wahrscheinlicher interner Betrug spielten eine mindestens ebenso gewichtige Rolle. Zudem bleibt das Lightning Network trotz SegWit weit hinter dem ursprünglichen Versprechen skalierter Massenadoption zurück – was die Kausalbehauptung 'SegWit hat Bitcoin gerettet' im Titel dramatischer klingen lässt, als die Realität rechtfertigt.SegWit solved genuine technical problems — but the article omits that its activation triggered one of Bitcoin's biggest internal conflicts, ultimately resulting in the BCH hard fork. Framing transaction malleability as the central factor behind Mt. Gox's collapse is a retrospective oversimplification: regulatory failures, internal control breakdowns, and likely internal theft played an equally significant role. Furthermore, the Lightning Network continues to fall well short of its original promise of scaled mass adoption — which makes the headline claim that 'SegWit saved Bitcoin' sound more dramatic than the facts fully support.SegWit resolvió problemas técnicos reales, pero el artículo omite que su activación desencadenó uno de los mayores conflictos internos en la historia de Bitcoin, que terminó derivando en la bifurcación de BCH. Presentar la maleabilidad de transacciones como el factor central detrás del colapso de Mt. Gox es una simplificación retrospectiva: los fallos regulatorios, las debilidades en los controles internos y el probable fraude interno desempeñaron un papel igual de relevante. Además, la Lightning Network continúa quedándose muy por debajo de su promesa original de adopción masiva a escala, lo que hace que la afirmación del titular de que «SegWit salvó a Bitcoin» suene más dramática de lo que los hechos justifican realmente.SegWit resolveu problemas técnicos reais — mas o artigo omite que sua ativação desencadeou um dos maiores conflitos internos da história do Bitcoin, resultando, por fim, no hard fork do BCH. Enquadrar a maleabilidade de transações como o fator central por trás do colapso da Mt. Gox é uma simplificação retrospectiva: falhas regulatórias, deficiências nos controles internos e, muito provavelmente, fraude interna desempenharam um papel igualmente significativo. Além disso, a Lightning Network continua muito aquém da promessa original de adoção em massa em escala — o que faz com que a afirmação do título de que "SegWit salvou o Bitcoin" soe mais dramática do que os fatos efetivamente sustentam.SegWit は現実の技術的問題を解決したことは確かだが、その有効化が Bitcoin 史上最大級の内部対立の一つを引き起こし、最終的に BCH のハードフォークをもたらしたという事実を、この記事は伏せている。トランザクション・マリアビリティを Mt. Gox 崩壊の主因として位置づけるのは事後的な過度の単純化であり、規制上の不備、内部統制の欠如、そしておそらく内部不正もまた、少なくとも同等に重要な役割を果たしていた。さらに、Lightning Network は SegWit をもってしても、当初約束されたスケールでの大衆普及には依然として程遠い状況にある。これらの点を踏まえると、「SegWit が Bitcoin を救った」というタイトルの主張は、実態が正当化する以上に劇的な響きを持ちすぎている。SegWit 解决了真实存在的技术问题——但文章却回避了一个事实：其激活引发了 Bitcoin 历史上最大的内部争议之一，并最终导致 BCH 硬分叉的诞生。将交易延展性（Transaction Malleability）定性为 Mt. Gox 崩溃的核心原因，是一种事后的过度简化：监管层面的失职、内部控制的失效，以及极有可能存在的内部舞弊，所起的作用丝毫不亚于此。此外，Lightning Network 迄今仍远未兑现当初大规模普及的承诺——这使得标题中"SegWit 拯救了 Bitcoin"的论断听起来远比事实所能支撑的更加戏剧化。حلّ SegWit مشكلات تقنية حقيقية — غير أن المقال يتجاهل أن تفعيله أشعل فتيل أحد أكبر الصراعات الداخلية في تاريخ Bitcoin، وأفضى في نهاية المطاف إلى الانشقاق الذي أنتج BCH. أما تصوير قابلية تغيير المعاملات (Transaction Malleability) باعتبارها العامل المحوري وراء انهيار Mt. Gox فهو تبسيط مُتأخّر للحقيقة؛ إذ أدّت الإخفاقات التنظيمية، وضعف الضوابط الداخلية، والاختلاس الداخلي المحتمل، دوراً لا يقلّ أهميةً عن ذلك. فضلاً عن ذلك، لا يزال Lightning Network يخفق إخفاقاً واضحاً في الوفاء بوعده الأصلي بتحقيق تبنٍّ جماهيري واسع النطاق — مما يجعل الادعاء الوارد في العنوان بأن «SegWit أنقذ Bitcoin» يبدو أكثر إثارةً مما تسوّغه الوقائع فعلاً.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Am 24. August 2017 wurde auf Block 481.824 ein Upgrade aktiviert, das die Bitcoin-Architektur bis heute prägt: Segregated Witness, kurz SegWit. Definiert in BIP141, trennte es die Signaturdaten – den sogenannten „Witness" – vom eigentlichen Transaktionskörper. Diese scheinbar technische Detailentscheidung löste gleich zwei fundamentale Probleme auf einmal und legte das Fundament für das Lightning Network.
Das Problem: Transaction Malleability
Um SegWit zu verstehen, muss man zunächst das Problem begreifen, das es löste. Jede Bitcoin-Transaktion erhält eine eindeutige Kennung – die Transaction ID (TXID) –, die als Hash über die Transaktionsdaten berechnet wird. Vor SegWit enthielt dieser Hash auch die Signaturen der Inputs.
Hier lag die Schwachstelle: Signaturen im klassischen DER-Encoding lassen einen gewissen Spielraum. Ein Angreifer – oder sogar der Empfänger – konnte die Signatur einer noch unbestätigten Transaktion geringfügig so abwandeln, dass der TXID sich änderte, ohne die wirtschaftliche Bedeutung (Betrag, Absender, Empfänger) zu verändern. Dieses Phänomen nennt sich Transaction Malleability.
Transaction Malleability war kein theoretisches Problem. Es stand im Mittelpunkt des Mt.-Gox-Angriffsvektors von 2014: Durch manipulierte TXIDs konnten Auszahlungen als „nicht angekommen" gemeldet und erneut ausgelöst werden – mit verheerenden Folgen für die damals größte Bitcoin-Börse der Welt.
Für einfache On-Chain-Zahlungen war Malleability lästig, aber handhabbar. Für Protokolle, die auf der sicheren Referenzierbarkeit einer unbestätigten Transaktion aufbauen – wie Zahlungskanäle – war es ein absolutes Hindernis.
Die Lösung: Witness-Daten herausnehmen
SegWit löst das Problem mit einem eleganten strukturellen Eingriff: Signaturdaten (Witness) werden aus dem Datenblock entfernt, der zur Berechnung der TXID gehasht wird. Die TXID hängt fortan nur noch von Inputs, Outputs und Metadaten ab – nicht mehr von Signaturen, die nachträglich verändert werden könnten. Damit ist die TXID unveränderlich, sobald eine Transaktion konstruiert ist.
Die Witness-Daten existieren weiterhin und werden von Nodes validiert – sie werden lediglich in einem separaten Datenbereich der Transaktion gespeichert, der für die TXID-Berechnung ausgeblendet wird.
Block Weight Units: Das Ende des einfachen 1-MB-Limits
Gleichzeitig löste SegWit den Blockgrößen-Engpass – nicht durch eine simple Erhöhung des 1-MB-Limits, sondern durch ein neues Konzept: Block Weight Units (WU).
- Nicht-Witness-Daten (Inputs, Outputs, Header) kosten 4 WU pro Byte.
- Witness-Daten (Signaturen, Redeem Scripts) kosten nur 1 WU pro Byte.
- Das maximale Block-Limit beträgt 4.000.000 Weight Units.
Da native SegWit-Transaktionen einen Großteil ihrer Daten im Witness-Bereich ablegen, profitieren sie von einem erheblichen Gewichtsvorteil. Eine typische P2WPKH-Transaktion benötigt gegenüber einer klassischen P2PKH-Legacy-Transaktion ca. 60–65 % weniger Gewicht bei gleicher wirtschaftlicher Funktion. Für Nutzer bedeutet das: niedrigere Gebühren bei gleicher Blockauslastung.
„Blockgröße" ist nach SegWit kein einfaches Megabyte-Konzept mehr. Wer Transaktionsgrößen oder Gebühren vergleicht, muss zwischen Bytes und Weight Units unterscheiden – eine häufige Quelle der Verwirrung auch unter erfahrenen Nutzern.
Die kausale Kette: Warum SegWit Lightning möglich macht
Das Lightning Network basiert auf Zahlungskanälen, die durch eine sogenannte Funding Transaction on-chain geöffnet werden. Weitere Transaktionen innerhalb des Kanals referenzieren diese Funding-TX an ihrer TXID, ohne sie sofort zu bestätigen.
Genau hier liegt die kritische Abhängigkeit von SegWit: Wäre die TXID der Funding Transaction manipulierbar, könnten alle darauf aufbauenden Commitment-Transaktionen ungültig werden – der Kanal wäre unsicher. Die kausale Kette lautet:
- Malleability-Fix → TXIDs werden unveränderlich
- Unveränderliche TXIDs → Funding Transaction sicher referenzierbar
- Sichere Referenzierung → Commitment Transactions im Kanal valide
- Valide Commitment Transactions → Lightning Network als Protokoll implementierbar
Ohne SegWit wäre das Lightning Network in seiner heutigen Form nicht sicher implementierbar gewesen. Der Malleability-Fix war keine Nebenwirkung – er war eine notwendige Voraussetzung.
Adressformate: Die evolutionäre Linie
SegWit brachte neue Adresstypen mit sich, die heute den Standard bilden. Die Entwicklungslinie von Legacy zu Taproot:
- P2PKH – Legacy (
1…): Klassisches Format, keine SegWit-Vorteile, höchste Kompatibilität, aber teuerste Transaktionen. - P2SH-P2WPKH – Wrapped/Nested SegWit (
3…, BIP49): SegWit-Transaktion in P2SH-Hülle verpackt; ermöglicht Kompatibilität mit Wallets, die noch kein natives SegWit unterstützen. Moderate Gebührenersparnis. - P2WPKH – Native SegWit / Bech32 (
bc1q…, BIP84): Maximale Gewichtsersparnis, keine Wrapper-Overhead, menschenlesbareres Format durch Bech32-Encoding (BIP173). - P2TR – Taproot / Bech32m (
bc1p…, BIP86): Nutzt ebenfalls den Witness-Mechanismus, ergänzt ihn um Schnorr-Signaturen und MAST. Das aktuell modernste Adressformat.
Stand 2026 verwenden über 85 % aller Bitcoin-Transaktionen im Mainnet SegWit-Inputs – ein klares Signal, dass die Adoption nahezu abgeschlossen ist.
Der Soft-Fork-Charakter: Rückwärtskompatibilität durch Cleverness
SegWit wurde ohne Hard Fork durchgesetzt – ein technisch anspruchsvolles Kunststück. Alte Nodes, die BIP141 nicht kennen, sehen SegWit-Ausgaben als sogenannte „anyone-can-spend"-Transaktionen: Das Ausgabe-Script erscheint ihnen leer und damit grundsätzlich einlösbar. Upgraded Nodes hingegen validieren den Witness vollständig.
Dieses Design garantierte, dass das Netzwerk nicht gespalten wurde: Alte und neue Nodes blieben im selben Konsens, solange eine Mehrheit der Mining-Power upgraded war. SegWit demonstrierte damit, wie tiefgreifende Protokolländerungen in Bitcoin ohne erzwungene Migration aller Teilnehmer durchsetzbar sind.
Weiterführend
On August 24, 2017, an upgrade was activated at block 481,824 that continues to shape Bitcoin's architecture to this day: Segregated Witness, or SegWit for short. Defined in BIP141, it separated the signature data — the so-called "witness" — from the actual transaction body. This seemingly technical design decision solved two fundamental problems simultaneously and laid the foundation for the Lightning Network.
The Problem: Transaction Malleability
To understand SegWit, one must first grasp the problem it solved. Every Bitcoin transaction receives a unique identifier — the Transaction ID (TXID) — computed as a hash over the transaction data. Before SegWit, this hash also covered the input signatures.
Therein lay the vulnerability: signatures in the classical DER encoding allow a certain degree of flexibility. An attacker — or even the recipient — could slightly alter the signature of an unconfirmed transaction such that the TXID changed, without modifying the economic meaning (amount, sender, recipient). This phenomenon is known as transaction malleability.
Transaction malleability was not a theoretical problem. It was at the center of the Mt. Gox attack vector in 2014: by manipulating TXIDs, withdrawals could be reported as "not received" and re-triggered — with devastating consequences for what was then the world's largest Bitcoin exchange.
For simple on-chain payments, malleability was inconvenient but manageable. For protocols that rely on the safe referenceability of an unconfirmed transaction — such as payment channels — it was an absolute barrier.
The Solution: Moving Witness Data Out
SegWit solves the problem with an elegant structural intervention: signature data (the witness) is removed from the data block that is hashed to compute the TXID. From that point on, the TXID depends only on inputs, outputs, and metadata — no longer on signatures that could be altered after the fact. This makes the TXID immutable as soon as a transaction is constructed.
The witness data still exists and is validated by nodes — it is simply stored in a separate data area of the transaction that is excluded from TXID computation.
Block Weight Units: The End of the Simple 1 MB Limit
At the same time, SegWit addressed the block size bottleneck — not by simply raising the 1 MB limit, but by introducing a new concept: Block Weight Units (WU).
- Non-witness data (inputs, outputs, header) costs 4 WU per byte.
- Witness data (signatures, redeem scripts) costs only 1 WU per byte.
- The maximum block limit is 4,000,000 Weight Units.
Since native SegWit transactions store the bulk of their data in the witness area, they benefit from a significant weight advantage. A typical P2WPKH transaction requires approximately 60–65% less weight than a classical P2PKH legacy transaction for the same economic function. For users, this translates directly into lower fees at equal block utilization.
"Block size" is no longer a simple megabyte concept after SegWit. Anyone comparing transaction sizes or fees must distinguish between bytes and weight units — a frequent source of confusion even among experienced users.
The Causal Chain: Why SegWit Makes Lightning Possible
The Lightning Network is built on payment channels that are opened on-chain via a so-called funding transaction. Further transactions within the channel reference this funding TX by its TXID, without immediately confirming it.
This is precisely where the critical dependency on SegWit lies: if the TXID of the funding transaction were malleable, all commitment transactions built on top of it could be invalidated — the channel would be insecure. The causal chain reads:
- Malleability fix → TXIDs become immutable
- Immutable TXIDs → funding transaction safely referenceable
- Safe referencing → commitment transactions within the channel remain valid
- Valid commitment transactions → Lightning Network implementable as a protocol
Without SegWit, the Lightning Network in its current form could not have been safely implemented. The malleability fix was not a side effect — it was a necessary precondition.
Address Formats: The Evolutionary Line
SegWit introduced new address types that now represent the standard. The development line from legacy to Taproot:
- P2PKH – Legacy (
1…): Classic format, no SegWit advantages, highest compatibility, but most expensive transactions. - P2SH-P2WPKH – Wrapped/Nested SegWit (
3…, BIP49): SegWit transaction wrapped inside a P2SH envelope; enables compatibility with wallets that do not yet support native SegWit. Moderate fee savings. - P2WPKH – Native SegWit / Bech32 (
bc1q…, BIP84): Maximum weight savings, no wrapper overhead, more human-readable format through Bech32 encoding (BIP173). - P2TR – Taproot / Bech32m (
bc1p…, BIP86): Also uses the witness mechanism, augmenting it with Schnorr signatures and MAST. The most modern address format available today.
As of 2026, over 85% of all Bitcoin transactions on the mainnet use SegWit inputs — a clear signal that adoption is nearly complete.
The Soft Fork Nature: Backward Compatibility by Design
SegWit was deployed without a hard fork — a technically demanding feat. Old nodes that are unaware of BIP141 see SegWit outputs as so-called "anyone-can-spend" transactions: the output script appears empty to them and therefore spendable in principle. Upgraded nodes, however, fully validate the witness.
This design guaranteed that the network was not split: old and new nodes remained in the same consensus, as long as a majority of mining power had upgraded. SegWit thus demonstrated how deep protocol changes in Bitcoin can be enforced without forcing all participants to migrate simultaneously.
Related
El 24 de agosto de 2017 se activó en el bloque 481.824 una actualización que define la arquitectura de Bitcoin hasta hoy: Segregated Witness, abreviado SegWit. Definido en BIP141, separó los datos de firma — el llamado «Witness» — del cuerpo principal de la transacción. Esta decisión aparentemente técnica resolvió de golpe dos problemas fundamentales y sentó las bases del Lightning Network.
El problema: Transaction Malleability
Para entender SegWit, primero hay que comprender el problema que resolvió. Cada transacción de Bitcoin recibe un identificador único — el Transaction ID (TXID) —, que se calcula como un hash sobre los datos de la transacción. Antes de SegWit, ese hash incluía también las firmas de los inputs.
Aquí residía la vulnerabilidad: las firmas en la codificación DER clásica admiten cierto margen de variación. Un atacante — o incluso el destinatario — podía modificar levemente la firma de una transacción aún sin confirmar de modo que el TXID cambiara, sin alterar el significado económico (importe, remitente, destinatario). Este fenómeno se conoce como Transaction Malleability.
La Transaction Malleability no era un problema teórico. Estuvo en el centro del vector de ataque contra Mt. Gox en 2014: mediante TXIDs manipulados, los retiros podían reportarse como «no recibidos» y volver a ejecutarse, con consecuencias devastadoras para el que entonces era el mayor exchange de Bitcoin del mundo.
Para pagos simples en cadena, la Malleability era molesta, pero manejable. Para protocolos que dependen de poder referenciar de forma segura una transacción no confirmada — como los canales de pago — era un obstáculo absoluto.
La solución: extraer los datos del Witness
SegWit resuelve el problema mediante una intervención estructural elegante: los datos de firma (Witness) se extraen del bloque de datos que se hashea para calcular el TXID. A partir de entonces, el TXID depende únicamente de los inputs, outputs y metadatos, y no de las firmas, que podrían modificarse a posteriori. De este modo, el TXID es inmutable en cuanto se construye una transacción.
Los datos Witness siguen existiendo y son validados por los nodos; simplemente se almacenan en una zona de datos separada de la transacción que queda excluida del cálculo del TXID.
Block Weight Units: el fin del sencillo límite de 1 MB
Al mismo tiempo, SegWit resolvió el cuello de botella del tamaño de bloque, no mediante un simple aumento del límite de 1 MB, sino a través de un nuevo concepto: Block Weight Units (WU).
- Los datos que no son Witness (inputs, outputs, cabecera) cuestan 4 WU por byte.
- Los datos Witness (firmas, Redeem Scripts) cuestan solo 1 WU por byte.
- El límite máximo de bloque es de 4.000.000 Weight Units.
Dado que las transacciones SegWit nativas almacenan la mayor parte de sus datos en el área Witness, se benefician de una ventaja de peso considerable. Una transacción P2WPKH típica requiere aproximadamente un 60–65 % menos de peso que una transacción P2PKH Legacy clásica para la misma función económica. Para los usuarios, esto se traduce en comisiones más bajas con la misma ocupación de bloque.
«Tamaño de bloque» ya no es un concepto simple de megabytes tras SegWit. Quien compare tamaños de transacción o comisiones debe distinguir entre bytes y unidades de peso (Weight Units), una fuente habitual de confusión incluso entre usuarios experimentados.
La cadena causal: por qué SegWit hace posible Lightning
Lightning Network se basa en canales de pago que se abren on-chain mediante una llamada Funding Transaction Las transacciones posteriores dentro del canal hacen referencia a esta Funding TX por su TXID, sin confirmarla de inmediato.
Aquí reside precisamente la dependencia crítica de SegWit: si la TXID de la Funding Transaction fuera manipulable, todas las Commitment Transactions construidas sobre ella podrían quedar invalidadas, haciendo el canal inseguro. La cadena causal es la siguiente:
- Corrección de maleabilidad → Las TXID se vuelven inmutables
- TXID inmutables → La Funding Transaction puede referenciarse de forma segura
- Referenciación segura → Las Commitment Transactions en el canal son válidas
- Transacciones de compromiso válidas → Lightning Network implementable como protocolo
Sin SegWit, la Lightning Network no habría podido implementarse de forma segura tal como la conocemos hoy. La corrección de maleabilidad no fue un efecto secundario: fue un requisito indispensable.
Formatos de dirección: la línea evolutiva
SegWit introdujo nuevos tipos de dirección que hoy constituyen el estándar. La línea de desarrollo desde Legacy hasta Taproot:
- P2PKH – Legacy (
1…): Formato clásico, sin ventajas de SegWit, máxima compatibilidad, pero transacciones más costosas. - P2SH-P2WPKH – Wrapped/Nested SegWit (
3…, BIP49): Transacción SegWit envuelta en una capa P2SH; permite la compatibilidad con carteras que aún no admiten SegWit nativo. Ahorro moderado en comisiones. - P2WPKH – Native SegWit / Bech32 (
bc1q…, BIP84): Máximo ahorro en peso, sin sobrecarga de envoltura, formato más legible para humanos gracias a la codificación Bech32 (BIP173). - P2TR – Taproot / Bech32m (
bc1p…, BIP86): Utiliza igualmente el mecanismo Witness, al que añade firmas Schnorr y MAST. Es el formato de dirección más moderno disponible actualmente.
A fecha de 2026, más del 85 % de todas las transacciones de Bitcoin en la red principal utilizan inputs SegWit, una señal inequívoca de que la adopción está prácticamente completada.
El carácter del soft fork: compatibilidad retroactiva mediante ingenio
SegWit se implementó sin hard fork, una hazaña técnica de gran complejidad. Los nodos antiguos que desconocen BIP141 ven las salidas SegWit como las denominadas «anyone-can-spend»: el script de salida les parece vacío y, por tanto, esencialmente canjeable por cualquiera. Los nodos actualizados, en cambio, validan el Witness de forma completa.
Este diseño garantizó que la red no se fragmentara: los nodos antiguos y los nuevos permanecieron bajo el mismo consenso, siempre que la mayoría del poder de minería estuviera actualizada. SegWit demostró así cómo es posible introducir cambios profundos en el protocolo de Bitcoin sin forzar la migración de todos los participantes.
Más información
Em 24 de agosto de 2017, foi ativada no bloco 481.824 uma atualização que molda a arquitetura do Bitcoin até hoje: Segregated Witness, abreviado como SegWit. Definido no BIP141, ele separou os dados de assinatura — o chamado "witness" — do corpo da transação propriamente dito. Essa decisão de design aparentemente técnica resolveu dois problemas fundamentais ao mesmo tempo e lançou as bases para o Lightning Network.
O Problema: Transaction Malleability
Para entender o SegWit, é preciso primeiro compreender o problema que ele resolveu. Cada transação Bitcoin recebe um identificador único — o Transaction ID (TXID) —, calculado como um hash sobre os dados da transação. Antes do SegWit, esse hash também incluía as assinaturas dos inputs.
Aí residia a vulnerabilidade: assinaturas no encoding DER clássico permitem uma certa margem de flexibilidade. Um atacante — ou até mesmo o destinatário — podia alterar ligeiramente a assinatura de uma transação ainda não confirmada de modo que o TXID mudasse, sem alterar o significado econômico (valor, remetente, destinatário). Esse fenômeno é conhecido como Transaction Malleability.
A Transaction Malleability não era um problema teórico. Ela esteve no centro do vetor de ataque à Mt. Gox em 2014: manipulando TXIDs, saques podiam ser reportados como "não recebidos" e acionados novamente — com consequências devastadoras para a então maior exchange de Bitcoin do mundo.
Para pagamentos simples on-chain, a malleability era inconveniente, mas administrável. Para protocolos que dependem da referenciabilidade segura de uma transação não confirmada — como os canais de pagamento — ela representava um obstáculo absoluto.
A Solução: Remover os Dados do Witness
O SegWit resolve o problema com uma intervenção estrutural elegante: os dados de assinatura (witness) são removidos do bloco de dados que é submetido a hash para o cálculo do TXID. A partir daí, o TXID depende apenas de inputs, outputs e metadados — não mais de assinaturas que poderiam ser alteradas posteriormente. Com isso, o TXID torna-se imutável assim que uma transação é construída.
Os dados do witness continuam existindo e são validados pelos nodes — eles simplesmente são armazenados em uma área de dados separada da transação, que é excluída do cálculo do TXID.
Block Weight Units: O Fim do Limite Simples de 1 MB
Ao mesmo tempo, o SegWit solucionou o gargalo do tamanho dos blocos — não aumentando simplesmente o limite de 1 MB, mas introduzindo um novo conceito: Block Weight Units (WU).
- Dados não-witness (inputs, outputs, header) custam 4 WU por byte.
- Dados witness (assinaturas, redeem scripts) custam apenas 1 WU por byte.
- O limite máximo de bloco é de 4.000.000 Weight Units.
Como as transações SegWit nativas armazenam a maior parte dos seus dados na área witness, elas se beneficiam de uma vantagem de peso considerável. Uma transação P2WPKH típica requer aproximadamente 60–65% menos peso do que uma transação P2PKH legacy clássica para a mesma função econômica. Para os usuários, isso se traduz diretamente em taxas menores com a mesma utilização do bloco.
"Tamanho de bloco" já não é mais um conceito simples de megabytes após o SegWit. Quem compara tamanhos de transações ou taxas precisa distinguir entre bytes e weight units — uma fonte frequente de confusão mesmo entre usuários experientes.
A Cadeia Causal: Por Que o SegWit Torna o Lightning Possível
O Lightning Network é baseado em canais de pagamento abertos on-chain por meio de uma chamada funding transaction. As demais transações dentro do canal referenciam essa funding TX pelo seu TXID, sem confirmá-la imediatamente.
É exatamente aqui que reside a dependência crítica do SegWit: se o TXID da funding transaction fosse manipulável, todas as commitment transactions construídas sobre ela poderiam ser invalidadas — o canal ficaria inseguro. A cadeia causal é a seguinte:
- Correção da malleability → TXIDs tornam-se imutáveis
- TXIDs imutáveis → funding transaction pode ser referenciada com segurança
- Referenciamento seguro → commitment transactions no canal permanecem válidas
- Commitment transactions válidas → Lightning Network implementável como protocolo
Sem o SegWit, o Lightning Network na sua forma atual não poderia ter sido implementado com segurança. A correção da malleability não foi um efeito colateral — foi uma condição necessária.
Formatos de Endereço: A Linha Evolutiva
O SegWit trouxe novos tipos de endereço que hoje representam o padrão. A linha de evolução do legacy ao Taproot:
- P2PKH – Legacy (
1…): Formato clássico, sem as vantagens do SegWit, maior compatibilidade, mas as transações mais caras. - P2SH-P2WPKH – Wrapped/Nested SegWit (
3…, BIP49): Transação SegWit encapsulada em um envelope P2SH; permite compatibilidade com carteiras que ainda não suportam SegWit nativo. Economia moderada de taxas. - P2WPKH – Native SegWit / Bech32 (
bc1q…, BIP84): Máxima economia de peso, sem overhead de wrapper, formato mais legível por humanos graças ao encoding Bech32 (BIP173). - P2TR – Taproot / Bech32m (
bc1p…, BIP86): Também utiliza o mecanismo witness, complementando-o com assinaturas Schnorr e MAST. O formato de endereço mais moderno atualmente disponível.
Em 2026, mais de 85% de todas as transações Bitcoin na mainnet utilizam inputs SegWit — um sinal claro de que a adoção está praticamente concluída.
O Caráter de Soft Fork: Compatibilidade com Versões Anteriores por Design
O SegWit foi implementado sem um hard fork — uma façanha tecnicamente exigente. Nodes antigos que desconhecem o BIP141 enxergam os outputs SegWit como transações do tipo "anyone-can-spend": o script de saída lhes parece vazio e, portanto, fundamentalmente gastável. Nodes atualizados, por sua vez, validam o witness por completo.
Esse design garantiu que a rede não fosse dividida: nodes antigos e novos permaneceram no mesmo consenso, desde que a maioria do poder de mineração tivesse feito a atualização. O SegWit demonstrou, assim, como mudanças profundas de protocolo no Bitcoin podem ser implementadas sem forçar a migração simultânea de todos os participantes.
Mais informação
2017年8月24日、ブロック481,824においてアップグレードが有効化され、今日に至るまでBitcoinのアーキテクチャを形作っている：Segregated Witness、略してSegWitである。BIP141で定義されたこのアップグレードは、署名データ——いわゆる「Witness」——を実際のトランザクション本体から分離した。一見すると技術的な設計上の決定に過ぎないこの変更は、二つの根本的な問題を同時に解決し、Lightning Networkの基盤を築いた。
問題：Transaction Malleability
SegWitを理解するには、まずそれが解決した問題を把握する必要がある。すべてのBitcoinトランザクションには固有の識別子——Transaction ID（TXID）——が付与され、トランザクションデータのハッシュとして計算される。SegWit以前は、このハッシュにインプットの署名も含まれていた。
ここに脆弱性があった：古典的なDERエンコーディングによる署名には、一定の柔軟性が存在する。攻撃者——あるいは受取人でさえ——は未確認トランザクションの署名をわずかに改ざんし、経済的な意味（金額・送信者・受信者）を変えることなくTXIDを変化させることができた。この現象をTransaction Malleabilityと呼ぶ。
Transaction Malleabilityは理論上の問題ではなかった。2014年のMt. Gox攻撃の核心にあった問題である：TXIDを改ざんすることで出金を「未着」として報告し、再度引き出しを実行できた——当時世界最大のBitcoin取引所に壊滅的な結果をもたらした。
単純なオンチェーン決済においては、Malleabilityは厄介ではあっても対処可能だった。しかし、未確認トランザクションを安全に参照することに依存するプロトコル——ペイメントチャネルなど——にとっては、絶対的な障壁であった。
解決策：Witnessデータの分離
SegWitはエレガントな構造的介入によってこの問題を解決する：署名データ（Witness）は、TXIDの計算のためにハッシュされるデータブロックから除外される。これ以降、TXIDはインプット・アウトプット・メタデータのみに依存し、事後に改ざんされる可能性のある署名には依存しない。これにより、トランザクションが構築された時点でTXIDは不変となる。
Witnessデータは引き続き存在し、ノードによって検証される——ただし、TXID計算から除外されるトランザクション内の別個のデータ領域に格納されるだけである。
Block Weight Units：単純な1MBリミットの終焉
同時にSegWitは、ブロックサイズのボトルネックも解消した——1MBの上限を単純に引き上げるのではなく、新たな概念を導入することで：Block Weight Units（WU）。
- 非Witnessデータ（インプット・アウトプット・ヘッダー）は1バイトあたり4 WUのコストがかかる。
- Witnessデータ（署名・Redeemスクリプト）は1バイトあたり1 WUのコストしかかからない。
- ブロックの最大上限は4,000,000 Weight Unitsである。
ネイティブSegWitトランザクションはデータの大部分をWitness領域に格納するため、大幅な重量上の優位性を享受できる。典型的なP2WPKHトランザクションは、同等の経済的機能を持つ従来のP2PKH Legacyトランザクションと比べて、約60〜65%少ない重量しか必要としない。ユーザーにとっては、同じブロック使用率でより低い手数料を意味する。
SegWit以降、「ブロックサイズ」は単純なメガバイトの概念ではない。トランザクションサイズや手数料を比較する際には、バイトとWeight Unitsを区別しなければならない——これは経験豊富なユーザーの間でも混乱の多い点である。
因果の連鎖：SegWitがLightningを可能にする理由
Lightning Networkは、Funding Transactionと呼ばれるトランザクションによってオンチェーンで開設されるペイメントチャネルを基盤としている。チャネル内のその後のトランザクションは、このFunding TXをTXIDで参照するが、即座に確認はされない。
まさにここにSegWitへの重要な依存関係がある：Funding TransactionのTXIDが改ざん可能であれば、その上に構築されたすべてのCommitment Transactionが無効化される恐れがある——チャネルが安全でなくなる。因果の連鎖は以下の通りだ：
- Malleability修正 → TXIDが不変になる
- 不変のTXID → Funding Transactionを安全に参照可能
- 安全な参照 → チャネル内のCommitment Transactionが有効
- 有効なCommitment Transaction → Lightning Networkをプロトコルとして実装可能
SegWitがなければ、Lightning Networkは現在の形で安全に実装できなかったであろう。Malleabilityの修正は副次的な効果ではなく——必要不可欠な前提条件であった。
アドレス形式：進化の系譜
SegWitは現在の標準となっている新しいアドレスタイプをもたらした。LegacyからTaprootへの発展の系譜：
- P2PKH – Legacy（
1…）：クラシックな形式。SegWitの恩恵なし、最高の互換性を持つが、最もコストの高いトランザクション。 - P2SH-P2WPKH – Wrapped/Nested SegWit（
3…、BIP49）：P2SHのエンベロープにWrappedされたSegWitトランザクション。ネイティブSegWitに未対応のウォレットとの互換性を可能にする。手数料の節約は中程度。 - P2WPKH – Native SegWit / Bech32（
bc1q…、BIP84）：最大の重量節約、ラッパーのオーバーヘッドなし、Bech32エンコーディング（BIP173）による人間が読みやすい形式。 - P2TR – Taproot / Bech32m（
bc1p…、BIP86）：同様にWitnessメカニズムを使用しつつ、Schnorr署名とMASTで補強。現時点で最も最新のアドレス形式。
2026年時点で、メインネット上のすべてのBitcoinトランザクションの85%以上がSegWit インプットを使用しており——採用がほぼ完了したことを示す明確なシグナルである。
ソフトフォークの性質：設計による後方互換性
SegWitはハードフォークなしに展開された——技術的に高度な成果である。BIP141を知らない古いノードは、SegWitのアウトプットをいわゆる「anyone-can-spend」トランザクションとして認識する：アウトプットスクリプトが空に見えるため、原則として誰でも使用可能と判断する。一方、アップグレード済みのノードはWitnessを完全に検証する。
この設計によりネットワークが分断されないことが保証された：マイニングパワーの過半数がアップグレードしている限り、古いノードと新しいノードは同じコンセンサス上に留まり続けた。SegWitはこうして、Bitcoinにおける深いプロトコル変更が、すべての参加者に強制的な移行を求めることなく実施できることを実証した。
関連情報
2017年8月24日，在区块481,824处激活了一项升级，该升级至今仍深刻影响着Bitcoin的架构：隔离见证（Segregated Witness），简称SegWit。它在BIP141中定义，将签名数据——即所谓的"见证"（Witness）——从实际的交易体中分离出来。这个看似纯技术性的设计决策一举解决了两个根本性问题，并为Lightning Network奠定了基础。
问题：交易延展性
要理解SegWit，首先必须了解它所解决的问题。每笔Bitcoin交易都有一个唯一标识符——交易ID（TXID）——它是对交易数据进行哈希计算得出的。在SegWit之前，这个哈希值还涵盖了输入的签名。
漏洞正在于此：经典DER编码的签名存在一定的灵活空间。攻击者——甚至是接收方——可以对一笔尚未确认的交易的签名进行细微修改，使TXID发生变化，而不改变其经济含义（金额、发送方、接收方）。这种现象被称为交易延展性（Transaction Malleability）。
交易延展性并非理论上的问题。它是2014年Mt. Gox攻击向量的核心：通过篡改TXID，提款可以被标记为"未到账"并被重复触发——对当时全球最大的Bitcoin交易所造成了灾难性后果。
对于简单的链上支付而言，延展性虽然令人头疼，但尚在可控范围之内。而对于依赖未确认交易安全可引用性的协议——例如支付通道——它则是一道绝对的障碍。
解决方案：移除见证数据
SegWit通过一种优雅的结构性改造解决了这个问题：签名数据（Witness）被从用于计算TXID的数据块中移除。此后，TXID仅依赖于输入、输出和元数据，不再依赖于事后可能被修改的签名。这使得TXID在交易构建完成后即不可更改。
见证数据依然存在，并由节点进行验证——它只是被存储在交易的一个独立数据区域中，在计算TXID时被排除在外。
区块权重单位：简单1 MB限制的终结
与此同时，SegWit也解决了区块大小的瓶颈问题——并非通过简单地提高1 MB上限，而是引入了一个新概念：区块权重单位（Block Weight Units，WU）。
- 非见证数据（输入、输出、区块头）的权重为每字节4 WU。
- 见证数据（签名、赎回脚本）的权重仅为每字节1 WU。
- 区块的最大上限为4,000,000 Weight Units。
由于原生SegWit交易将大部分数据存储在见证区域，它们享有显著的权重优势。一笔典型的P2WPKH交易与经典的P2PKH Legacy交易相比，在实现相同经济功能的情况下，所需权重约减少60–65%。对用户而言，这意味着在相同区块利用率下手续费更低。
SegWit之后，"区块大小"不再是一个简单的兆字节概念。任何比较交易大小或手续费的人都必须区分字节与权重单位——这是即使在经验丰富的用户中也常见的混淆来源。
因果链：为什么SegWit使Lightning成为可能
Lightning Network建立在支付通道之上，这些通道通过一笔所谓的资金交易（Funding Transaction）在链上开启。通道内的后续交易通过TXID引用该资金交易，而无需立即确认它。
这正是对SegWit关键依赖所在：如果资金交易的TXID可被篡改，所有建立在其之上的承诺交易都可能失效——通道将变得不安全。因果链如下：
- 延展性修复 → TXID变为不可更改
- 不可更改的TXID → 资金交易可被安全引用
- 安全引用 → 通道内的承诺交易保持有效
- 有效的承诺交易 → Lightning Network可作为协议实现
没有SegWit，Lightning Network以其当前形态将无法被安全实现。延展性修复并非附带效果——它是必要的前提条件。
地址格式：演进路线
SegWit带来了新的地址类型，这些类型如今已成为标准。从Legacy到Taproot的发展脉络：
- P2PKH – Legacy（
1…）：经典格式，无SegWit优势，兼容性最高，但交易手续费最贵。 - P2SH-P2WPKH – 封装/嵌套SegWit（
3…，BIP49）：将SegWit交易包裹在P2SH外壳中；使尚不支持原生SegWit的钱包也能兼容。手续费节省适中。 - P2WPKH – 原生SegWit / Bech32（
bc1q…，BIP84）：权重节省最大，无封装开销，通过Bech32编码（BIP173）格式更易读。 - P2TR – Taproot / Bech32m（
bc1p…，BIP86）：同样使用见证机制，并在此基础上引入了Schnorr签名和MAST。目前最先进的地址格式。
截至2026年，主网上超过85%的Bitcoin交易使用SegWit输入——这清晰地表明采用率已近乎完成。
软分叉特性：向后兼容的巧妙设计
SegWit的部署未经硬分叉——这是一项技术上颇具难度的壮举。不了解BIP141的旧节点将SegWit输出视为所谓的"任何人均可花费（anyone-can-spend）"交易：输出脚本在它们看来是空的，因此原则上可以被任意花费。而升级后的节点则会对见证数据进行完整验证。
这一设计确保了网络不会分裂：只要大多数算力已完成升级，新旧节点便保持在同一共识之下。SegWit由此证明了Bitcoin中深层次的协议变更可以在不强迫所有参与者同步迁移的情况下得以推行。
延伸阅读
في 24 أغسطس 2017، جرى تفعيل ترقية على الكتلة 481,824 لا تزال تُشكّل بنية Bitcoin حتى اليوم: Segregated Witness، أو SegWit اختصارًا. كما هو مُعرَّف في BIP141، فصل هذا الترقية بيانات التوقيع — المعروفة بـ"Witness" — عن جسم المعاملة الأصلي. هذا القرار التقني الذي قد يبدو في ظاهره تفصيلًا ثانويًا حلَّ في آنٍ واحد مشكلتين جوهريتين، ووضع الأساس لشبكة Lightning Network.
المشكلة: قابلية تعديل المعاملات (Transaction Malleability)
لفهم SegWit، لا بدّ أولًا من استيعاب المشكلة التي جاء ليحلّها. تحصل كل معاملة Bitcoin على معرّف فريد هو معرّف المعاملة (TXID) ، يُحسب كقيمة تجزئة (Hash) على بيانات المعاملة. قبل SegWit، كانت هذه القيمة تشمل أيضًا توقيعات المدخلات (Inputs).
هنا كمنت نقطة الضعف: تترك التوقيعات المُشفَّرة بترميز DER الكلاسيكي هامشًا من المرونة. كان بإمكان مهاجم — أو حتى المستلم نفسه — تعديل توقيع معاملة لم تُؤكَّد بعد بشكل طفيف بحيث يتغيّر الـTXID دون أن تتأثر الدلالة الاقتصادية (المبلغ والمرسل والمستلم). يُعرف هذا الظاهرة بـ Transaction Malleability.
لم تكن Transaction Malleability مجرد مشكلة نظرية. فقد كانت في صميم ناقل الهجوم الذي تعرّضت له منصة Mt. Gox عام 2014: إذ أتاح التلاعب بالـTXIDs الإبلاغ عن عمليات السحب بوصفها "لم تصل" وإعادة إطلاقها، مما خلّف عواقب وخيمة على أكبر بورصة Bitcoin في العالم آنذاك.
بالنسبة لمدفوعات On-Chain البسيطة، كانت Malleability مزعجة لكن يمكن التعامل معها. أما بالنسبة للبروتوكولات التي تعتمد على إمكانية الإشارة الموثوقة إلى معاملة غير مؤكدة — كقنوات الدفع — فقد كانت عائقًا مطلقًا.
الحل: استخراج بيانات Witness
تعالج SegWit هذه المشكلة بتدخل هيكلي أنيق: إذ تُزال بيانات التوقيع (Witness) من كتلة البيانات التي يُجرى عليها التجزئة لحساب TXID. وبذلك لا تعتمد TXID بعد الآن إلا على المدخلات والمخرجات والبيانات الوصفية، دون التوقيعات القابلة للتعديل لاحقاً. ونتيجةً لذلك، تصبح TXID ثابتة وغير قابلة للتغيير فور بناء المعاملة.
تظل بيانات Witness موجودة ويتحقق منها العقد، غير أنها تُخزَّن في منطقة بيانات منفصلة داخل المعاملة، تُستثنى من حساب TXID.
وحدات وزن الكتلة: نهاية حد الـ 1 ميغابايت البسيط
في الوقت ذاته، عالجت SegWit عنق الزجاجة المتعلق بحجم الكتلة، لا عبر رفع بسيط لحد الـ 1 ميغابايت، بل من خلال مفهوم جديد: وحدات وزن الكتلة (WU).
- تكلّف البيانات غير الخاصة بـ Witness (المدخلات والمخرجات والترويسة) 4 WU لكل بايت.
- تكلّف بيانات Witness (التوقيعات ونصوص الاسترداد) فقط 1 WU لكل بايت.
- يبلغ الحد الأقصى لوزن الكتلة 4,000,000 وحدة وزن (Weight Units).
نظراً لأن معاملات SegWit الأصيلة تضع الجزء الأكبر من بياناتها في منطقة Witness، فإنها تستفيد من ميزة وزنية ملحوظة. إذ تحتاج معاملة P2WPKH النموذجية إلى ما يقل بنحو 60–65% من الوزن مقارنةً بمعاملة P2PKH الكلاسيكية (Legacy) عند أداء الوظيفة الاقتصادية ذاتها. وبالنسبة للمستخدمين، يعني ذلك: رسوم أقل عند نفس مستوى استخدام الكتلة.
«حجم الكتلة» لم يعد مفهوماً بسيطاً قائماً على الميغابايت منذ SegWit. فمن يريد مقارنة أحجام المعاملات أو الرسوم عليه التمييز بين البايت ووحدات الوزن (Weight Units) — وهذا مصدر ارتباك شائع حتى بين المستخدمين المتمرسين.
السلسلة السببية: كيف أتاح SegWit شبكة Lightning
تعتمد شبكة Lightning Network على قنوات دفع يتم فتحها على السلسلة (on-chain) من خلال ما يُعرف بـ Funding Transaction وتُشير المعاملات اللاحقة داخل القناة إلى هذه Funding TX عبر TXID الخاصة بها، دون أن تُؤكَّد فورياً.
وهنا تكمن الاعتمادية الحرجة على SegWit: فلو كانت TXID الخاصة بـ Funding Transaction قابلةً للتلاعب، لأمكن إبطال جميع معاملات الالتزام (Commitment Transactions) المبنية عليها — مما يجعل القناة غير آمنة. وتسير السلسلة السببية على النحو التالي:
- إصلاح قابلية التغيير (Malleability Fix) ← تصبح TXIDs غير قابلة للتغيير
- TXIDs غير قابلة للتغيير ← يمكن الإشارة إلى Funding Transaction بأمان
- الإشارة الآمنة ← تبقى Commitment Transactions داخل القناة صالحة
- معاملات الالتزام الصالحة → شبكة Lightning قابلة للتنفيذ كبروتوكول
بدون SegWit، لم يكن بالإمكان تنفيذ شبكة Lightning بشكلها الحالي بأمان. لم يكن إصلاح Malleability مجرد أثر جانبي — بل كان شرطاً ضرورياً لا غنى عنه.
تنسيقات العناوين: الخط التطوري
جلب SegWit معه أنواعاً جديدة من العناوين باتت تشكّل المعيار اليوم. خط التطور من Legacy إلى Taproot:
- P2PKH – Legacy (
1…): التنسيق الكلاسيكي، لا يستفيد من مزايا SegWit، يتمتع بأعلى مستوى من التوافق، لكنه الأكثر تكلفةً من حيث رسوم المعاملات. - P2SH-P2WPKH – Wrapped/Nested SegWit (
3…، BIP49): معاملة SegWit مغلّفة داخل قالب P2SH؛ تتيح التوافق مع المحافظ التي لا تدعم SegWit الأصلي بعد. توفير معتدل في الرسوم. - P2WPKH – Native SegWit / Bech32 (
bc1q…، BIP84): أقصى توفير في الوزن، لا حمل إضافي من الغلاف، تنسيق أكثر قابلية للقراءة البشرية عبر ترميز Bech32 (BIP173). - P2TR – Taproot / Bech32m (
bc1p…، BIP86): يستخدم أيضًا آلية Witness، ويُضيف إليها توقيعات Schnorr وMASTـ. يُعدّ هذا أحدث صيغة عناوين حتى الآن.
اعتبارًا من عام 2026، تستخدم أكثر من 85% من جميع معاملات Bitcoin على الشبكة الرئيسية مدخلات SegWit — وهو مؤشر واضح على أن اعتماده بات شبه مكتمل.
طابع الـ Soft Fork: التوافق مع الإصدارات السابقة عبر الذكاء التقني
جرى تفعيل SegWit دون الحاجة إلى Hard Fork — وهو إنجاز تقني بالغ الدقة والتعقيد. فالعُقَد القديمة التي لا تعرف BIP141 ترى مخرجات SegWit على أنها ما يُعرف بـ"anyone-can-spend": إذ يبدو لها سكريبت الإخراج فارغًا، ومن ثَمَّ قابلًا للصرف من حيث المبدأ. أما العُقَد المُحدَّثة فتتحقق من صحة الـ Witness بشكل كامل.
يضمن هذا التصميم ألّا ينقسم الشبكة: إذ ظلّت العُقَد القديمة والجديدة في إجماع واحد، طالما أن أغلبية قوة التعدين قد أجرت التحديث. وبذلك أثبت SegWit كيف يمكن تطبيق تعديلات بروتوكولية جوهرية في Bitcoin دون إلزام جميع المشاركين بالترحيل.
مزيد من المعلومات
⚖️ 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.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Die Darstellung, Transaction Malleability habe „im Mittelpunkt" des Mt.-Gox-Debakels gestanden, überzeichnet die Kausalität: Die peer-reviewte Messstudie von Decker und Wattenhofer (2014) kam zum Ergebnis, dass Malleability-Angriffe nur einen kleinen Bruchteil der behaupteten Verluste erklären können – die Hauptursachen lagen in Mt. Gox' interner Misswirtschaft.Portraying transaction malleability as "central" to the Mt. Gox debacle overstates the causality: the peer-reviewed measurement study by Decker and Wattenhofer (2014) concluded that malleability attacks can explain only a small fraction of the claimed losses — the main causes lay in Mt. Gox's internal mismanagement.Presentar la maleabilidad de transacciones como «el centro» del desastre de Mt. Gox exagera la causalidad: el estudio de medición revisado por pares de Decker y Wattenhofer (2014) concluyó que los ataques de maleabilidad solo pueden explicar una pequeña fracción de las pérdidas alegadas; las causas principales estaban en la mala gestión interna de Mt. Gox.Retratar a maleabilidade de transações como "o centro" do desastre da Mt. Gox exagera a causalidade: o estudo de medição revisado por pares de Decker e Wattenhofer (2014) concluiu que ataques de maleabilidade só podem explicar uma pequena fração das perdas alegadas — as causas principais estavam na má gestão interna da Mt. Gox.トランザクション・マリアビリティをMt. Gox崩壊の「中心」と描くのは因果関係の誇張だ。DeckerとWattenhoferによる査読済みの計測研究(2014年)は、マリアビリティ攻撃で説明できるのは主張された損失のごく一部にすぎないと結論づけた——主因はMt. Goxの内部の管理不全にあった。把交易延展性描绘为Mt. Gox崩溃的"核心"夸大了因果关系:Decker与Wattenhofer经同行评审的测量研究(2014年)得出结论,延展性攻击只能解释所称损失中的一小部分——主要原因在于Mt. Gox内部管理失当。تصوير قابلية تعديل المعاملات بوصفها «محور» كارثة Mt. Gox يبالغ في السببية: فدراسة القياس المحكمة لديكر وواتنهوفر (2014) خلصت إلى أن هجمات القابلية للتعديل لا تفسر إلا جزءا صغيرا من الخسائر المزعومة — إذ كانت الأسباب الرئيسية في سوء الإدارة الداخلية لدى Mt. Gox.
Die Studie ist die beste verfügbare empirische Quelle zum Thema und widerspricht der Gewichtung des Artikels direkt: Malleability war der von Mt. Gox öffentlich vorgeschobene Erklärungsversuch, nicht die messbar dominante Verlustursache. Korrekt bleibt, dass Malleability als Angriffsvektor real existierte und für Zahlungskanal-Protokolle tatsächlich prohibitiv war – aber die Mt.-Gox-Rahmung des Artikels übernimmt unkritisch die Selbstdarstellung der Börse.The study is the best available empirical source on the topic and directly contradicts the article's weighting: malleability was the explanation Mt. Gox publicly put forward, not the measurably dominant loss cause. It remains correct that malleability existed as a real attack vector and was genuinely prohibitive for payment-channel protocols — but the article's Mt. Gox framing uncritically adopts the exchange's own narrative.El estudio es la mejor fuente empírica disponible sobre el tema y contradice directamente la ponderación del artículo: la maleabilidad fue la explicación que Mt. Gox esgrimió públicamente, no la causa de pérdida mediblemente dominante. Sigue siendo correcto que la maleabilidad existía como vector de ataque real y que era genuinamente prohibitiva para los protocolos de canales de pago; pero el encuadre de Mt. Gox del artículo adopta sin crítica la narrativa de la propia bolsa.O estudo é a melhor fonte empírica disponível sobre o tema e contradiz diretamente a ponderação do artigo: a maleabilidade foi a explicação que a Mt. Gox apresentou publicamente, não a causa de perda mensuravelmente dominante. Permanece correto que a maleabilidade existia como vetor de ataque real e era genuinamente proibitiva para protocolos de canais de pagamento — mas o enquadramento de Mt. Gox no artigo adota acriticamente a narrativa da própria exchange.この研究は本件で入手できる最良の実証的資料であり、記事の重み付けを真っ向から否定する。マリアビリティはMt. Goxが公に持ち出した弁明であって、測定上の支配的な損失原因ではなかった。マリアビリティが現実の攻撃ベクトルとして存在し、ペイメントチャネル型プロトコルにとって本当に致命的だった点は正しいままだ——だが記事のMt. Goxの枠組みは、取引所自身の語りを無批判に引き継いでいる。该研究是这一问题上现有最好的实证来源,并直接反驳文章的权重分配:延展性是Mt. Gox公开抛出的辩解,而非可测量的主导损失原因。延展性作为真实攻击向量确实存在、并且对支付通道类协议确属致命障碍,这一点依然正确——但文章的Mt. Gox叙事不加批判地沿用了交易所自己的说法。هذه الدراسة أفضل مصدر تجريبي متاح في الموضوع وتناقض ترجيح المقال مباشرة: فالقابلية للتعديل كانت التفسير الذي روجته Mt. Gox علنا، لا سبب الخسارة المهيمن قياسا. يبقى صحيحا أن القابلية للتعديل وجدت كناقل هجوم حقيقي وكانت عائقا فعليا أمام بروتوكولات قنوات الدفع — لكن تأطير المقال لقضية Mt. Gox يتبنى رواية المنصة نفسها دون نقد.
Die Titelthese „SegWit hat Bitcoin gerettet" ist eine unprüfbare kontrafaktische Behauptung – und sie unterschlägt die Kosten: Die Aktivierung erzwang den schwersten Governance-Konflikt der Bitcoin-Geschichte samt Kettenspaltung (Bitcoin Cash, August 2017). Ob Bitcoin ohne SegWit „verloren" gewesen wäre, lässt sich nicht belegen.The title thesis "SegWit saved Bitcoin" is an untestable counterfactual claim — and it omits the costs: activation forced the most severe governance conflict in Bitcoin's history, including a chain split (Bitcoin Cash, August 2017). Whether Bitcoin would have been "lost" without SegWit cannot be substantiated.La tesis del titular, «SegWit salvó a Bitcoin», es una afirmación contrafáctica incomprobable, y omite los costes: la activación provocó el conflicto de gobernanza más grave de la historia de Bitcoin, incluida una escisión de la cadena (Bitcoin Cash, agosto de 2017). Que Bitcoin hubiera estado «perdido» sin SegWit no puede demostrarse.A tese do título, "o SegWit salvou o Bitcoin", é uma afirmação contrafactual intestável — e omite os custos: a ativação provocou o mais grave conflito de governança da história do Bitcoin, incluindo uma cisão da cadeia (Bitcoin Cash, agosto de 2017). Que o Bitcoin estaria "perdido" sem o SegWit não pode ser comprovado.「SegWitがBitcoinを救った」という表題の命題は検証不能な反実仮想であり、しかも代償を伏せている。その有効化はBitcoin史上最も深刻なガバナンス対立を引き起こし、チェーン分裂(Bitcoin Cash、2017年8月)にまで至った。SegWitなしでBitcoinが「失われていた」かどうかは立証できない。标题论点"SegWit拯救了比特币"是无法检验的反事实断言——而且略去了代价:其激活引发了比特币历史上最严重的治理冲突,乃至链分裂(Bitcoin Cash,2017年8月)。没有SegWit比特币是否就会"完蛋",无法证明。أطروحة العنوان «SegWit أنقذ Bitcoin» ادعاء افتراضي مضاد غير قابل للاختبار — وهي تغفل التكاليف: فقد فجر التفعيل أشد نزاعات الحوكمة في تاريخ Bitcoin بما في ذلك انقسام السلسلة (Bitcoin Cash، أغسطس 2017). وما إذا كان Bitcoin «سيضيع» من دون SegWit أمر لا يمكن إثباته.
Kontrafaktische Geschichtsschreibung ist prinzipiell nicht adjudizierbar: Die technischen Verdienste von SegWit (Malleability-Fix, Weight-System) sind belegt, die Blocksize-Alternative hätte andere Trade-offs gehabt – welcher Pfad Bitcoin „gerettet" oder geschadet hätte, bleibt Spekulation. Der Konflikt samt BCH-Fork ist dagegen Fakt und fehlt im Artikel; die dramatisierende Titelwahl ist journalistisch angreifbar, ohne dass die Sachdarstellung falsch wäre.Counterfactual history is in principle not adjudicable: SegWit's technical merits (malleability fix, weight system) are substantiated, and the big-block alternative would have carried different trade-offs — which path would have "saved" or harmed Bitcoin remains speculation. The conflict including the BCH fork, however, is fact and is missing from the article; the dramatizing title is journalistically assailable without the factual account being wrong.La historia contrafáctica no es, en principio, adjudicable: los méritos técnicos de SegWit (solución de la maleabilidad, sistema de pesos) están probados, y la alternativa de bloques grandes habría tenido otros compromisos; qué camino habría «salvado» o dañado a Bitcoin sigue siendo especulación. El conflicto, incluida la bifurcación de BCH, es en cambio un hecho y falta en el artículo; la elección dramatizante del titular es periodísticamente cuestionable sin que la exposición fáctica sea errónea.História contrafactual não é, em princípio, adjudicável: os méritos técnicos do SegWit (correção da maleabilidade, sistema de pesos) estão comprovados, e a alternativa de blocos grandes teria outros trade-offs — qual caminho teria "salvado" ou prejudicado o Bitcoin permanece especulação. O conflito, incluindo o fork do BCH, é porém fato e está ausente do artigo; a escolha dramatizante do título é jornalisticamente atacável sem que o relato factual esteja errado.反実仮想の歴史記述は原理的に裁定不能だ。SegWitの技術的功績(マリアビリティ修正、ウェイト制)は実証されており、大ブロック路線には別のトレードオフがあっただろう——どちらの道がBitcoinを「救った」か害したかは推測の域を出ない。一方、BCHフォークを含む対立は事実であり、記事には欠けている。劇的な表題の選択は報道倫理上批判し得るが、事実記述自体が誤りというわけではない。反事实的历史书写原则上无法裁决:SegWit的技术功绩(延展性修复、权重体系)有据可查,大区块替代方案则会带来另一组权衡——哪条路会"拯救"或伤害比特币,始终是推测。相反,包括BCH分叉在内的冲突是事实,却在文章中缺席;戏剧化的标题选择在新闻操守上可以指摘,但事实陈述本身并无错误。التأريخ الافتراضي المضاد غير قابل للفصل مبدئيا: فمزايا SegWit التقنية (إصلاح القابلية للتعديل، نظام الأوزان) ثابتة، وكان لبديل الكتل الكبيرة مقايضات مختلفة — وأي المسارين كان «سينقذ» Bitcoin أو يضره يظل تكهنا. أما النزاع بما فيه انشقاق BCH فحقيقة غائبة عن المقال؛ واختيار العنوان المسرحي قابل للنقد صحفيا دون أن يكون السرد الوقائعي خاطئا.
SegWit hat Bitcoins Kapazitätsproblem nicht gelöst, sondern nur gestreckt: Der effektive Durchsatzgewinn liegt bei grob dem Doppelten, und trotz einer SegWit-Nutzung von über 85 % kam es 2021 und erneut 2023/2024 (Ordinals/Inscriptions) zu massiven Gebührenspitzen – der Engpass besteht strukturell fort.SegWit did not solve Bitcoin's capacity problem, it merely stretched it: the effective throughput gain is roughly a doubling, and despite SegWit usage above 85%, massive fee spikes occurred in 2021 and again in 2023/2024 (Ordinals/Inscriptions) — the bottleneck persists structurally.SegWit no resolvió el problema de capacidad de Bitcoin, solo lo estiró: la ganancia efectiva de rendimiento es aproximadamente el doble y, pese a un uso de SegWit superior al 85 %, hubo picos masivos de comisiones en 2021 y de nuevo en 2023/2024 (Ordinals/Inscriptions); el cuello de botella persiste estructuralmente.O SegWit não resolveu o problema de capacidade do Bitcoin, apenas o esticou: o ganho efetivo de vazão é de aproximadamente o dobro e, apesar de um uso de SegWit acima de 85%, houve picos massivos de taxas em 2021 e novamente em 2023/2024 (Ordinals/Inscriptions) — o gargalo persiste estruturalmente.SegWitはBitcoinの容量問題を解決したのではなく、引き延ばしたにすぎない。実効スループットの向上はおおむね2倍程度で、SegWit利用率が85%を超えているにもかかわらず、2021年と2023/2024年(Ordinals/Inscriptions)に手数料の大高騰が再発した——ボトルネックは構造的に残っている。SegWit并未解决比特币的容量问题,只是延缓了它:有效吞吐量的提升大约是翻倍,而且尽管SegWit使用率超过85%,2021年以及2023/2024年(Ordinals/Inscriptions)仍出现了猛烈的手续费飙升——瓶颈在结构上依然存在。لم يحل SegWit مشكلة سعة Bitcoin بل مددها فحسب: فمكسب الإنتاجية الفعلي يقارب الضعف تقريبا، ورغم أن استخدام SegWit تجاوز 85% وقعت ذروات رسوم هائلة في 2021 ثم مجددا في 2023/2024 (Ordinals/Inscriptions) — فعنق الزجاجة قائم بنيويا.
Die Gebührenspitzen von 2021 und 2023/2024 sind on-chain dokumentiert und traten bei nahezu vollständiger SegWit-Adoption auf – der Kapazitätsgewinn war real, aber begrenzt und wurde von neuer Nachfrage (u. a. Inscriptions) absorbiert. Der Artikel behauptet allerdings nirgends, SegWit habe Skalierung final gelöst; der Einwand trifft die Grenze des im Titel suggerierten Erfolgs, nicht die technische Darstellung.The fee spikes of 2021 and 2023/2024 are documented on-chain and occurred at near-complete SegWit adoption — the capacity gain was real but bounded, and was absorbed by new demand (including Inscriptions). The article, however, nowhere claims SegWit finally solved scaling; the objection hits the limit of the success the title suggests, not the technical account.Los picos de comisiones de 2021 y 2023/2024 están documentados en la cadena y ocurrieron con una adopción de SegWit casi completa: la ganancia de capacidad fue real pero acotada, y fue absorbida por nueva demanda (incluidas las Inscriptions). El artículo, sin embargo, en ningún lugar afirma que SegWit haya resuelto definitivamente el escalado; la objeción alcanza el límite del éxito que sugiere el titular, no la exposición técnica.Os picos de taxas de 2021 e 2023/2024 estão documentados na cadeia e ocorreram com adoção quase completa do SegWit — o ganho de capacidade foi real, mas limitado, e foi absorvido por nova demanda (incluindo as Inscriptions). O artigo, porém, em nenhum lugar afirma que o SegWit resolveu definitivamente a escalabilidade; a objeção atinge o limite do sucesso sugerido pelo título, não o relato técnico.2021年と2023/2024年の手数料急騰はオンチェーンに記録されており、SegWit採用がほぼ完了した状態で起きた——容量増は実在したが限定的で、新たな需要(Inscriptionsなど)に吸収された。ただし記事はSegWitがスケーリングを最終解決したとはどこにも主張していない。この反論が突くのは表題が示唆する成功の限界であって、技術的記述そのものではない。2021年与2023/2024年的手续费飙升有链上记录,且发生在SegWit几乎全面普及之时——容量增益真实但有限,并被新需求(包括Inscriptions)吸收殆尽。不过文章从未声称SegWit彻底解决了扩容;该反驳击中的是标题暗示的成功之边界,而非技术叙述本身。ذروات الرسوم في 2021 و2023/2024 موثقة على السلسلة ووقعت مع تبن شبه كامل لـSegWit — كان مكسب السعة حقيقيا لكنه محدود، وامتصه طلب جديد (منه Inscriptions). غير أن المقال لا يدعي في أي موضع أن SegWit حل مسألة التوسع نهائيا؛ فالاعتراض يصيب حدود النجاح الذي يوحي به العنوان لا العرض التقني.