Technik & KryptografieTechnology & CryptographyTecnología & CriptografíaTecnologia & Criptografia技術 & 暗号学技术 & 密码学التقنية & التشفير
Bitcoin-Transaktionen im Detail: Was vin, vout, Witness und Locktime wirklich bedeutenBitcoin Transactions in Detail: What vin, vout, Witness and Locktime Really MeanTransacciones Bitcoin en detalle: qué significan realmente vin, vout, Witness y LocktimeTransações Bitcoin em detalhe: o que vin, vout, Witness e Locktime realmente significamBitcoinトランザクションを詳しく解説：vin、vout、Witness、Locktimeが本当に意味するもの深入解析 Bitcoin 交易：vin、vout、Witness 和 Locktime 的真正含义معاملات Bitcoin بالتفصيل: ما الذي تعنيه vin وvout وWitness وLocktime فعلاً
Alle Kernfakten – Serialisierungsreihenfolge, Feldgrößen, SegWit-Marker, txid/wtxid-Trennung, Weight-Formel, Sequence-Werte – sind direkt durch BIP141, BIP143, BIP68 und BIP125 belegt und durch die Bitcoin Developer Reference bestätigt. Keine erfundenen Zahlen oder Zitate. Zeitabhängige Größen (vByte-Werte typischer Transaktionen) als Stand 2026 gekennzeichnet.Todos los datos fundamentales — orden de serialización, tamaños de campos, marcador SegWit, separación txid/wtxid, fórmula de weight, valores de Sequence — están respaldados directamente por BIP141, BIP143, BIP68 y BIP125, y confirmados por la Bitcoin Developer Reference. No se incluyen cifras ni citas inventadas. Los valores dependientes del tiempo (tamaños en vBytes de transacciones típicas) están indicados con referencia a 2026.Todos os fatos fundamentais — ordem de serialização, tamanhos de campos, marcador SegWit, separação txid/wtxid, fórmula de weight, valores de Sequence — são diretamente embasados por BIP141, BIP143, BIP68 e BIP125 e confirmados pela Bitcoin Developer Reference. Nenhum número ou citação inventados. Grandezas dependentes do tempo (valores em vByte de transações típicas) identificadas com referência a 2026.すべての核心的な事実（シリアライゼーションの順序、フィールドサイズ、SegWit マーカー、txid/wtxid の分離、Weight の計算式、Sequence 値）は、BIP141、BIP143、BIP68、および BIP125 によって直接裏付けられており、Bitcoin Developer Reference によって確認されています。架空の数値や引用は一切含まれていません。時間依存の値（代表的なトランザクションの vByte 値）は 2026 年時点のものとして明記されています。所有核心事实——序列化顺序、字段大小、SegWit 标记、txid/wtxid 区分、Weight 计算公式、Sequence 值——均直接来自 BIP141、BIP143、BIP68 和 BIP125，并经 Bitcoin Developer Reference 确认。无虚构数字或引用。时间相关数据（典型交易的 vByte 值）标注为截至 2026 年的数据。جميع الحقائق الجوهرية — ترتيب التسلسل، وأحجام الحقول، وعلامة SegWit، والفصل بين txid/wtxid، وصيغة Weight، وقيم Sequence — موثّقة مباشرةً من خلال BIP141 وBIP143 وBIP68 وBIP125، ومؤكَّدة عبر Bitcoin Developer Reference. لا أرقام ولا اقتباسات مخترَعة. المقادير الزمنية التابعة (قيم vByte للمعاملات النموذجية) مُعلَّمة بحسب وضع عام 2026.
Dieser Artikel ist solide protokolltechnisch fundiert und stützt sich ausschließlich auf kanonische BIP-Quellen – es gibt keine Zitaterfindungen oder Fehlzuschreibungen. Dennoch verdient er eine kritische Einordnung: Das technische Bild bleibt unvollständig, weil Taproot (BIP340/341/342) strukturell andere Witness-Stacks erzeugt, die für Entwickler 2026 praxisrelevant sind und im Artikel pauschal übergangen werden. Die Fokussierung auf P2WPKH als 'typisches' Beispiel ist nicht falsch, aber in einer Zielgruppe mit Protokollinteresse zunehmend unzureichend. Leser, die den Artikel als vollständige Referenz nutzen, könnten bei Taproot-Transaktionen scheitern.This article is solidly grounded in protocol detail and relies exclusively on canonical BIP sources – there are no invented quotes or misattributions. Nevertheless, it deserves a critical note: the technical picture remains incomplete because Taproot (BIP340/341/342) produces structurally different witness stacks that are practically relevant for developers in 2026 and are glossed over in the article. Framing P2WPKH as the 'typical' example is not wrong, but increasingly insufficient for an audience with protocol-level interest. Readers treating this article as a complete reference may find themselves at a loss when working with Taproot transactions.Este artículo está sólidamente fundamentado en los detalles del protocolo y se apoya exclusivamente en fuentes BIP canónicas – no hay citas inventadas ni atribuciones erróneas. No obstante, merece una nota crítica: el panorama técnico sigue siendo incompleto, porque Taproot (BIP340/341/342) genera witness stacks estructuralmente diferentes que son de relevancia práctica para los desarrolladores en 2026 y que el artículo pasa por alto de forma superficial. Presentar P2WPKH como el ejemplo «típico» no es incorrecto, pero resulta cada vez más insuficiente para un público con interés a nivel de protocolo. Los lectores que utilicen este artículo como referencia completa podrían encontrarse perdidos al trabajar con transacciones Taproot.Este artigo está solidamente fundamentado em detalhes de protocolo e baseia-se exclusivamente em fontes BIP canônicas – não há citações inventadas nem atribuições incorretas. No entanto, merece uma observação crítica: o quadro técnico permanece incompleto porque o Taproot (BIP340/341/342) produz witness stacks estruturalmente diferentes, que são praticamente relevantes para desenvolvedores em 2026 e são tratados superficialmente no artigo. Apresentar o P2WPKH como o exemplo "típico" não está errado, mas é cada vez mais insuficiente para um público com interesse em nível de protocolo. Leitores que utilizarem este artigo como referência completa podem encontrar dificuldades ao trabalhar com transações Taproot.この記事はプロトコルの詳細に関して確固たる根拠を持ち、正規のBIPソースのみに依拠しており、引用の捏造や誤った帰属は一切ない。それでもなお、批判的な指摘に値する点がある。Taproot（BIP340/341/342）は構造的に異なるwitnessスタックを生成し、2026年における開発者にとって実践的に重要であるにもかかわらず、本記事ではそれが大まかに読み飛ばされており、技術的な全体像が不完全なままとなっている。P2WPKHを「典型的な」例として位置づけることは誤りではないが、プロトコルレベルに関心を持つ読者層に対しては、ますます不十分になりつつある。この記事を完全なリファレンスとして扱う読者は、Taproot トランザクションを扱う際に行き詰まる可能性がある。本文在协议技术层面根基扎实，所引来源均为规范的 BIP 文献——不存在捏造引用或错误归属的情况。尽管如此，本文仍有值得批评指出之处：其技术描述并不完整，因为 Taproot（BIP340/341/342）会产生结构上截然不同的 witness 栈，这对 2026 年的开发者而言具有重要的实践意义，而文中对此一笔带过。将 P2WPKH 定位为"典型"示例并无不妥，但对于具有协议层兴趣的读者群体而言，这已日益显得不够充分。若读者将本文作为完整参考资料使用，在处理 Taproot 交易时可能会遭遇困境。هذا المقال مبني على أسس بروتوكولية متينة ويعتمد حصرًا على مصادر BIP الأصلية المعتمدة – فلا اقتباسات مخترعة ولا نسب خاطئ. بيد أنه يستحق ملاحظة نقدية: تبقى الصورة التقنية ناقصة، إذ ينتج Taproot (BIP340/341/342) مكدسات witness مختلفة هيكليًا، وهي ذات صلة عملية للمطورين في عام 2026، غير أن المقال يتجاوزها بإجمال دون تفصيل. تقديم P2WPKH باعتباره المثال 'النموذجي' ليس خاطئًا في حد ذاته، لكنه بات غير كافٍ بشكل متزايد لجمهور مهتم بتفاصيل البروتوكول. والقراء الذين يتعاملون مع هذا المقال كمرجع شامل قد يجدون أنفسهم في حيرة عند العمل مع معاملات Taproot.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Eine Bitcoin-Transaktion ist kein abstraktes Datenbankfeld – sie ist eine vollständig deterministische Bytesequenz, deren Reihenfolge und Interpretation durch Konsensregeln (vor allem BIP141 und BIP143) festgelegt sind. Wer Bitcoin auf Protokollebene verstehen will, muss jeden dieser Felder kennen.
Das Grundgerüst: Serialisierungsreihenfolge
Eine moderne (SegWit-fähige) Transaktion besteht in exakt dieser Reihenfolge aus: Version (4 Byte), Marker + Flag (2 Byte, nur bei Witness-Transaktionen), Input-Vektor (vin), Output-Vektor (vout), Witness-Stack pro Input und Locktime (4 Byte). Alle Mehrbytefelder werden im Little-Endian-Format (LE) kodiert – eine ständige Fehlerquelle beim manuellen Parsen.
Version: 4 Byte, die mehr sagen als man denkt
Das Versionsfeld bestimmt, welche Konsensregeln gelten. Version 1 (0x01000000 in LE) ist das klassische Format. Version 2 (0x02000000) signalisiert Unterstützung für relative Locktimes gemäß BIP68 – eine Voraussetzung für Sequence-basierte Zeitbedingungen. Nodes, die eine Transaktion validieren, lesen diesen Wert zuerst.
SegWit-Marker und Flag: 0x00 0x01
Enthält eine Transaktion Witness-Daten, folgen nach dem Versionsfeld zwei Bytes: 0x00 (Marker) und 0x01 (Flag). Dieser Zweibyte-Header unterscheidet das erweiterte Serialisierungsformat vom Legacy-Format. Legacy-Nodes, die 0x00 als Input-Anzahl sehen, interpretieren die Transaktion als ungültig – ein eleganter Rückwärtskompatibilitätsmechanismus.
Input-Vektor (vin): Woher kommt das Geld?
Jeder Input referenziert einen unverbrauchten Transaktionsausgang (UTXO) über zwei Felder: die txid (32 Byte) des vorherigen Transactions und den vout-Index (4 Byte). Wichtig: Die txid wird intern im Little-Endian gespeichert, in Block-Explorern aber reversed (Big-Endian) angezeigt. Diese Byteumkehr ist eine häufige Fehlerquelle.
Dazu kommt das ScriptSig-Feld: Bei Native-SegWit-Inputs (P2WPKH, P2WSH, P2TR) ist es leer (0x00) – die eigentliche Autorisierung befindet sich im Witness-Stack. Die Sequence-Nummer (4 Byte) steuert Locktime-Verhalten und RBF:
0xFFFFFFFF– finalisiert, Locktime deaktiviert0xFFFFFFFE– Locktime aktiv, kein RBF-Signal0xFFFFFFFD– RBF-Signal gemäß BIP125 (Replace-by-Fee)
Output-Vektor (vout): Wohin geht das Geld?
Jeder Output besteht aus dem Wert in Satoshi (8 Byte, signed int64 LE) und dem ScriptPubKey (variable Länge mit CompactSize-Präfix). Der Satoshi-Wert kodiert die exakte Menge – der Maximum-Supply von 21 Mio. BTC entspricht 2.100.000.000.000.000 Satoshi. Das ScriptPubKey bestimmt die Ausgabebedingung: P2PKH, P2SH, P2WPKH, P2WSH oder P2TR.
Längenfelder werden als CompactSize (VarInt) kodiert: Werte unter 0xFD benötigen 1 Byte; ab 0xFD folgen 3, 5 oder 9 Byte für größere Werte.
Witness-Daten: txid ≠ wtxid
Die Witness-Daten (BIP141) werden pro Input als Stack von Byte-Vektoren serialisiert – direkt nach dem letzten Output, vor der Locktime. Entscheidend: Die Legacy-txid wird als HASH256 der Serialisierung ohne Marker, Flag und Witness berechnet. Die wtxid hingegen umfasst das vollständige erweiterte Format inklusive Witness. Dadurch wird Transaction Malleability gelöst: Niemand kann den Witness manipulieren, ohne die wtxid zu ändern – die txid bleibt stabil.
txid = HASH256(Legacy-Serialisierung ohne Witness) — wtxid = HASH256(vollständige Witness-Serialisierung). Diese Trennung ist das Kernversprechen von SegWit und Grundlage für Layer-2-Protokolle wie das Lightning Network.
Locktime: Zeitschlösser auf Transaktionsebene
Die letzten 4 Byte einer Transaktion kodieren die nLockTime. Werte unter 500.000.000 werden als Blockhöhe interpretiert, Werte ab 500.000.000 als Unix-Timestamp. Locktime wirkt jedoch nur, wenn mindestens ein Input eine Sequence kleiner als 0xFFFFFFFE hat – andernfalls ignoriert das Netzwerk das Feld vollständig.
Weight Units und Gebühren: Warum jedes Byte zählt
Seit SegWit gilt ein zweigeteiltes Gewichtungsmodell. Das Transaktionsgewicht in Weight Units (WU) berechnet sich als:
Weight = (Nicht-Witness-Bytes) × 4 + (Witness-Bytes) × 1
Ein Block darf maximal 4.000.000 WU enthalten. Virtuelle Byte (vByte) = WU / 4; Gebühren werden in sat/vByte angegeben. Eine typische P2WPKH-Transaktion mit 1 Input und 2 Outputs wiegt rund 561 WU ≈ 141 vByte (Stand 2026). Witness-Daten sind damit günstiger als gleich viele Basis-Bytes – ein direkter Anreiz für SegWit-Adoption.
Weiterführend
A Bitcoin transaction is not an abstract database entry – it is a fully deterministic byte sequence whose order and interpretation are defined by consensus rules, primarily BIP141 and BIP143. Anyone seeking to understand Bitcoin at the protocol level must know each of these fields.
The Basic Structure: Serialization Order
A modern (SegWit-capable) transaction consists of exactly the following, in order: version (4 bytes), marker + flag (2 bytes, only for witness transactions), input vector (vin), output vector (vout), witness stack per input, and locktime (4 bytes). All multi-byte fields are encoded in little-endian (LE) format – a constant source of errors when parsing manually.
Version: 4 Bytes That Say More Than You Think
The version field determines which consensus rules apply. Version 1 (0x01000000 in LE) is the classic format. Version 2 (0x02000000) signals support for relative locktimes per BIP68 – a prerequisite for sequence-based time conditions. Nodes validating a transaction read this value first.
SegWit Marker and Flag: 0x00 0x01
If a transaction contains witness data, two bytes follow immediately after the version field: 0x00 (marker) and 0x01 (flag). This two-byte header distinguishes the extended serialization format from legacy format. Legacy nodes seeing 0x00 as an input count interpret the transaction as invalid – an elegant backward-compatibility mechanism.
Input Vector (vin): Where Does the Money Come From?
Each input references an unspent transaction output (UTXO) via two fields: the txid (32 bytes) of the previous transaction and the vout index (4 bytes). Important: the txid is stored internally in little-endian, but displayed reversed (big-endian) in block explorers. This byte reversal is a frequent source of confusion.
Additionally, the ScriptSig field: for native SegWit inputs (P2WPKH, P2WSH, P2TR), it is empty (0x00) – the actual authorization resides in the witness stack. The sequence number (4 bytes) governs locktime behavior and RBF:
0xFFFFFFFF– finalized, locktime disabled0xFFFFFFFE– locktime active, no RBF signal0xFFFFFFFD– RBF signal per BIP125 (Replace-by-Fee)
Output Vector (vout): Where Does the Money Go?
Each output consists of the value in satoshis (8 bytes, signed int64 LE) and the ScriptPubKey (variable length with CompactSize prefix). The satoshi value encodes the exact amount – Bitcoin's maximum supply of 21 million BTC equals 2,100,000,000,000,000 satoshis. The ScriptPubKey defines the spending condition: P2PKH, P2SH, P2WPKH, P2WSH, or P2TR.
Length fields are encoded as CompactSize (VarInt): values below 0xFD require 1 byte; from 0xFD onward, 3, 5, or 9 bytes are used for larger values.
Witness Data: txid ≠ wtxid
Witness data (BIP141) is serialized per input as a stack of byte vectors – directly after the last output, before the locktime. Crucially: the legacy txid is computed as HASH256 of the serialization without marker, flag, and witness data. The wtxid, by contrast, covers the complete extended format including witness. This resolves transaction malleability: no one can manipulate the witness without changing the wtxid – the txid remains stable.
txid = HASH256(legacy serialization without witness) — wtxid = HASH256(full witness serialization). This separation is SegWit's core promise and the foundation for Layer-2 protocols such as the Lightning Network.
Locktime: Time Locks at the Transaction Level
The final 4 bytes of a transaction encode the nLockTime. Values below 500,000,000 are interpreted as a block height; values from 500,000,000 onward as a Unix timestamp. However, locktime only takes effect if at least one input has a sequence number below 0xFFFFFFFE – otherwise the network ignores the field entirely.
Weight Units and Fees: Why Every Byte Matters
Since SegWit, a two-tier weighting model applies. Transaction weight in Weight Units (WU) is calculated as:
Weight = (non-witness bytes) × 4 + (witness bytes) × 1
A block may contain at most 4,000,000 WU. Virtual bytes (vByte) = WU / 4; fees are quoted in sat/vByte. A typical P2WPKH transaction with 1 input and 2 outputs weighs around 561 WU ≈ 141 vByte (as of 2026). Witness data is therefore cheaper than the same number of base bytes – a direct incentive for SegWit adoption.
Related
Una transacción Bitcoin no es un campo de base de datos abstracto: es una secuencia de bytes completamente determinista cuyo orden e interpretación están definidos por las reglas de consenso, principalmente BIP141 y BIP143. Quien desee entender Bitcoin a nivel de protocolo debe conocer cada uno de estos campos.
La estructura básica: orden de serialización
Una transacción moderna (compatible con SegWit) se compone exactamente en este orden: versión (4 bytes), marker + flag (2 bytes, solo en transacciones con witness), vector de inputs (vin), vector de outputs (vout), witness stack por input y locktime (4 bytes). Todos los campos de varios bytes se codifican en formato little-endian (LE), una fuente constante de errores al parsear manualmente.
Versión: 4 bytes que dicen más de lo que parece
El campo de versión determina qué reglas de consenso se aplican. La versión 1 (0x01000000 en LE) es el formato clásico. La versión 2 (0x02000000) señala compatibilidad con locktimes relativos según BIP68, un requisito previo para condiciones temporales basadas en sequence. Los nodos que validan una transacción leen este valor primero.
Marker y Flag de SegWit: 0x00 0x01
Si una transacción contiene datos witness, tras el campo de versión siguen dos bytes: 0x00 (marker) y 0x01 (flag). Este encabezado de dos bytes distingue el formato de serialización extendido del formato legacy. Los nodos legacy que ven 0x00 como número de inputs interpretan la transacción como inválida, un elegante mecanismo de compatibilidad hacia atrás.
Vector de inputs (vin): ¿De dónde viene el dinero?
Cada input referencia una salida de transacción no gastada (UTXO) mediante dos campos: la txid (32 bytes) de la transacción anterior y el índice vout (4 bytes). Importante: la txid se almacena internamente en little-endian, pero se muestra invertida (big-endian) en los exploradores de bloques. Esta inversión de bytes es una fuente habitual de confusión.
A esto se suma el campo ScriptSig: en inputs native SegWit (P2WPKH, P2WSH, P2TR) está vacío (0x00), ya que la autorización real reside en el witness stack. El número de sequence (4 bytes) controla el comportamiento del locktime y del RBF:
0xFFFFFFFF– finalizado, locktime desactivado0xFFFFFFFE– locktime activo, sin señal RBF0xFFFFFFFD– señal RBF según BIP125 (Replace-by-Fee)
Vector de outputs (vout): ¿Adónde va el dinero?
Cada output se compone del valor en satoshis (8 bytes, int64 con signo en LE) y el ScriptPubKey (longitud variable con prefijo CompactSize). El valor en satoshis codifica la cantidad exacta: el suministro máximo de 21 millones de BTC equivale a 2.100.000.000.000.000 satoshis. El ScriptPubKey define la condición de gasto: P2PKH, P2SH, P2WPKH, P2WSH o P2TR.
Los campos de longitud se codifican como CompactSize (VarInt): los valores inferiores a 0xFD requieren 1 byte; a partir de 0xFD se usan 3, 5 o 9 bytes para valores mayores.
Datos witness: txid ≠ wtxid
Los datos witness (BIP141) se serializan por input como una pila de vectores de bytes, directamente después del último output y antes del locktime. Lo fundamental: la txid legacy se calcula como HASH256 de la serialización sin marker, flag ni witness. La wtxid, en cambio, abarca el formato extendido completo incluyendo el witness. Esto resuelve la maleabilidad de transacciones: nadie puede manipular el witness sin cambiar la wtxid, mientras que la txid permanece estable.
txid = HASH256(serialización legacy sin witness) — wtxid = HASH256(serialización completa con witness). Esta separación es la promesa central de SegWit y la base de los protocolos de capa 2 como el Lightning Network.
Locktime: bloqueos temporales a nivel de transacción
Los últimos 4 bytes de una transacción codifican el nLockTime. Los valores inferiores a 500.000.000 se interpretan como altura de bloque; los valores a partir de 500.000.000 se interpretan como timestamp Unix. Sin embargo, el locktime solo tiene efecto si al menos un input tiene un número de sequence inferior a 0xFFFFFFFE; de lo contrario, la red ignora el campo por completo.
Weight Units y comisiones: por qué cada byte cuenta
Desde SegWit se aplica un modelo de ponderación en dos niveles. El peso de una transacción en Weight Units (WU) se calcula como:
Weight = (bytes no-witness) × 4 + (bytes witness) × 1
Un bloque puede contener como máximo 4.000.000 WU. Los bytes virtuales (vByte) = WU / 4; las comisiones se expresan en sat/vByte. Una transacción P2WPKH típica con 1 input y 2 outputs pesa alrededor de 561 WU ≈ 141 vByte (a partir de 2026). Los datos witness son por tanto más económicos que el mismo número de bytes base, un incentivo directo para la adopción de SegWit.
Más información
Uma transação Bitcoin não é um campo abstrato de banco de dados – é uma sequência de bytes totalmente determinística, cuja ordem e interpretação são definidas pelas regras de consenso, principalmente BIP141 e BIP143. Quem deseja compreender o Bitcoin em nível de protocolo precisa conhecer cada um desses campos.
A Estrutura Básica: Ordem de Serialização
Uma transação moderna (compatível com SegWit) é composta, exatamente nesta ordem, por: versão (4 bytes), marker + flag (2 bytes, apenas em transações com witness), vetor de inputs (vin), vetor de outputs (vout), witness stack por input e locktime (4 bytes). Todos os campos com múltiplos bytes são codificados no formato little-endian (LE) – uma fonte constante de erros ao fazer parsing manual.
Versão: 4 Bytes Que Dizem Mais do Que Parecem
O campo de versão determina quais regras de consenso se aplicam. A versão 1 (0x01000000 em LE) é o formato clássico. A versão 2 (0x02000000) sinaliza suporte a locktimes relativos conforme o BIP68 – um pré-requisito para condições de tempo baseadas em sequence. Os nós que validam uma transação leem esse valor primeiro.
Marker e Flag do SegWit: 0x00 0x01
Se uma transação contém dados witness, dois bytes são inseridos logo após o campo de versão: 0x00 (marker) e 0x01 (flag). Esse cabeçalho de dois bytes distingue o formato de serialização estendido do formato legado. Nós legados que leem 0x00 como contagem de inputs interpretam a transação como inválida – um elegante mecanismo de compatibilidade retroativa.
Vetor de Inputs (vin): De Onde Vem o Dinheiro?
Cada input referencia uma saída de transação não gasta (UTXO) por meio de dois campos: a txid (32 bytes) da transação anterior e o índice vout (4 bytes). Importante: a txid é armazenada internamente em little-endian, mas exibida de forma invertida (big-endian) nos exploradores de blocos. Essa inversão de bytes é uma fonte frequente de confusão.
Há ainda o campo ScriptSig: para inputs native SegWit (P2WPKH, P2WSH, P2TR), ele é vazio (0x00) – a autorização efetiva encontra-se no witness stack. O número de sequence (4 bytes) controla o comportamento do locktime e do RBF:
0xFFFFFFFF– finalizado, locktime desativado0xFFFFFFFE– locktime ativo, sem sinal RBF0xFFFFFFFD– sinal RBF conforme BIP125 (Replace-by-Fee)
Vetor de Outputs (vout): Para Onde Vai o Dinheiro?
Cada output é composto pelo valor em satoshis (8 bytes, int64 com sinal em LE) e pelo ScriptPubKey (comprimento variável com prefixo CompactSize). O valor em satoshis codifica a quantidade exata – o fornecimento máximo de 21 milhões de BTC corresponde a 2.100.000.000.000.000 satoshis. O ScriptPubKey define a condição de gasto: P2PKH, P2SH, P2WPKH, P2WSH ou P2TR.
Os campos de comprimento são codificados como CompactSize (VarInt): valores abaixo de 0xFD requerem 1 byte; a partir de 0xFD, utilizam-se 3, 5 ou 9 bytes para valores maiores.
Dados Witness: txid ≠ wtxid
Os dados witness (BIP141) são serializados por input como uma pilha de vetores de bytes – diretamente após o último output, antes do locktime. O ponto crucial: a txid legada é calculada como HASH256 da serialização sem marker, flag e dados witness. A wtxid, por sua vez, abrange o formato estendido completo, incluindo o witness. Isso resolve a maleabilidade de transações: ninguém pode manipular o witness sem alterar a wtxid – a txid permanece estável.
txid = HASH256(serialização legada sem witness) — wtxid = HASH256(serialização witness completa). Essa separação é a promessa central do SegWit e a base para protocolos de Layer 2 como o Lightning Network.
Locktime: Travas de Tempo no Nível da Transação
Os últimos 4 bytes de uma transação codificam o nLockTime. Valores abaixo de 500.000.000 são interpretados como altura de bloco; valores a partir de 500.000.000, como Unix timestamp. Porém, o locktime só entra em vigor se pelo menos um input tiver um número de sequence inferior a 0xFFFFFFFE – caso contrário, a rede ignora o campo completamente.
Weight Units e Taxas: Por Que Cada Byte Importa
Desde o SegWit, aplica-se um modelo de ponderação em duas camadas. O peso da transação em Weight Units (WU) é calculado como:
Weight = (bytes não-witness) × 4 + (bytes witness) × 1
Um bloco pode conter no máximo 4.000.000 WU. Bytes virtuais (vByte) = WU / 4; as taxas são expressas em sat/vByte. Uma transação P2WPKH típica com 1 input e 2 outputs pesa cerca de 561 WU ≈ 141 vByte (referência: 2026). Os dados witness são, portanto, mais baratos do que o mesmo número de bytes de base – um incentivo direto para a adoção do SegWit.
Mais informação
Bitcoin トランザクションは抽象的なデータベースフィールドではなく、完全に決定論的なバイト列であり、その順序と解釈はコンセンサスルール（主に BIP141 および BIP143）によって定められています。Bitcoin をプロトコルレベルで理解したいなら、これらのフィールドをすべて把握しておく必要があります。
基本構造：シリアライズの順序
現代的な（SegWit 対応の）トランザクションは、厳密に次の順序で構成されています： バージョン （4 バイト）、 マーカー + フラグ （2 バイト、Witness トランザクションのみ）、 インプットベクター (vin), アウトプットベクター (vout), Witness スタック （インプットごと）、および ロックタイム （4 バイト）。すべてのマルチバイトフィールドはリトルエンディアン形式（LE）でエンコードされており、手動でパースする際によくあるミスの原因となっています。
バージョン：4 バイトが語るもの
バージョンフィールドは、適用されるコンセンサスルールを決定します。バージョン 1（LE で0x01000000 ）はクラシックなフォーマットです。バージョン 2（0x02000000）は BIP68 に基づく相対ロックタイムのサポートを示しており、Sequence ベースの時間条件の前提条件となっています。トランザクションを検証するノードは、まずこの値を読み取ります。
SegWit マーカーとフラグ：0x00 0x01
トランザクションに Witness データが含まれる場合、バージョンフィールドの直後に 2 バイトが続きます： 0x00 （マーカー）と 0x01 （フラグ）です。この 2 バイトのヘッダーにより、拡張シリアライズフォーマットとレガシーフォーマットが区別されます。インプット数として 0x00 を認識したレガシーノードはトランザクションを無効と解釈するため、これは巧妙な後方互換性メカニズムとなっています。
インプットベクター (vin)：資金はどこから来るのか？
各インプットは、2 つのフィールドを通じて未使用のトランザクションアウトプット（UTXO）を参照します：前のトランザクションの txid （32 バイト）と vout インデックス （4 バイト）です。重要な点として、txid は内部ではリトルエンディアンで格納されますが、ブロックエクスプローラーでは逆順（ビッグエンディアン）で表示されます。このバイト反転はよくあるエラーの原因です。
さらに ScriptSigフィールドがあります：ネイティブ SegWit インプット（P2WPKH、P2WSH、P2TR）では空（0x00）であり、実際の承認は Witness スタックに格納されます。 Sequence 番号 （4 バイト）はロックタイムの動作と RBF を制御します：
0xFFFFFFFF– ファイナライズ済み、ロックタイム無効0xFFFFFFFE– ロックタイム有効、RBF シグナルなし0xFFFFFFFD– BIP125 に基づく RBF シグナル（Replace-by-Fee）
アウトプットベクター (vout)：資金はどこへ行くのか？
各アウトプットは Satoshi 単位の金額 （8 バイト、signed int64 LE）と ScriptPubKey （CompactSize プレフィックス付きの可変長）で構成されます。Satoshi 値は正確な金額をエンコードしており、2,100 万 BTC の最大供給量は 2,100,000,000,000,000 Satoshi に相当します。ScriptPubKey は支出条件を決定します：P2PKH、P2SH、P2WPKH、P2WSH、または P2TR。
長さフィールドは CompactSize (VarInt) としてエンコードされます： 0xFD 未満の値は 1 バイトで表され、 0xFD 以上の値には 3、5、または 9 バイトが続きます。
Witness データ：txid ≠ wtxid
Witness データ（BIP141）は、インプットごとにバイトベクターのスタックとしてシリアライズされ、最後のアウトプットの直後、ロックタイムの前に配置されます。重要なのは、レガシーのtxid は HASH256 を使って Witness を含まない シリアライズから計算されるという点です。一方、 wtxid は Witness を含む完全な拡張フォーマットを対象とします。これによりトランザクションマリアビリティが解決されます：Witness を改ざんしても wtxid しか変化せず、txid は安定したままです。
txid = HASH256（Witness を含まないレガシーシリアライズ） — wtxid = HASH256（完全な Witness シリアライズ）。この分離こそが SegWit の核心的な約束であり、Lightning Network のような Layer-2 プロトコルの基盤となっています。
ロックタイム：トランザクションレベルのタイムロック
トランザクションの末尾 4 バイトが nLockTimeをエンコードします。500,000,000 未満の値はブロック高として、500,000,000 以上の値は Unix タイムスタンプとして解釈されます。ただし、ロックタイムが有効になるのは、少なくとも 1 つのインプットの Sequence が 0xFFFFFFFE 未満である場合に限られます。そうでなければ、ネットワークはこのフィールドを完全に無視します。
Weight Unit と手数料：なぜすべてのバイトが重要なのか
SegWit 導入以降、二分化された重み付けモデルが採用されています。トランザクションの重みは Weight Units（WU）で次のように計算されます：
Weight = （非 Witness バイト数）× 4 +（Witness バイト数）× 1
1 ブロックには最大 4,000,000 WU を含めることができます。仮想バイト（vByte）= WU / 4 であり、手数料は sat/vByte 単位で表されます。1 インプット・2 アウトプットの典型的な P2WPKH トランザクションは約 561 WU ≈ 141 vByte（2026 年時点）です。Witness データは同量の基本バイトよりも安価であるため、SegWit 採用への直接的なインセンティブとなっています。
関連情報
Bitcoin 交易并非抽象的数据库字段，而是一段完全确定性的字节序列，其顺序和解析方式由共识规则（主要是 BIP141 和 BIP143）明确规定。凡是想从协议层面理解 Bitcoin 的人，都必须熟悉其中的每一个字段。
基本结构：序列化顺序
一笔现代（支持 SegWit 的）交易严格按照以下顺序组成： 版本号 （4 字节）， Marker + Flag （2 字节，仅出现在 Witness 交易中）， 输入向量（vin）, 输出向量（vout）, Witness 栈 每个输入对应一个，以及 锁定时间（Locktime） （4 字节）。所有多字节字段均以小端序（LE）编码——这是手动解析时最常见的错误根源。
版本号：4 字节，含义远比看起来丰富
版本字段决定了适用哪套共识规则。版本 1（0x01000000 ，小端序）是经典格式。版本 2（0x02000000）表示支持 BIP68 规定的相对锁定时间，这是基于 Sequence 的时间条件的前提。节点在验证交易时会首先读取该值。
SegWit Marker 与 Flag：0x00 0x01
若交易包含 Witness 数据，则在版本字段之后紧跟两个字节： 0x00 （Marker）和 0x01 （Flag）。这两个字节的头部将扩展序列化格式与传统格式区分开来。不支持 SegWit 的旧节点看到 0x00 作为输入数量时，会将该交易判定为无效——这是一种优雅的向后兼容机制。
输入向量（vin）：资金从哪里来？
每个输入通过两个字段引用一个未花费的交易输出（UTXO）：前一笔交易的 txid （32 字节）和 vout 索引 （4 字节）。需要注意的是：txid 在内部以小端序存储，但在区块浏览器中以大端序（反转字节序）显示。这种字节翻转是常见的错误根源。
此外还有 ScriptSig字段：对于原生 SegWit 输入（P2WPKH、P2WSH、P2TR），该字段为空（0x00）——实际的授权信息位于 Witness 栈中。 Sequence 号 （4 字节）控制锁定时间行为和 RBF：
0xFFFFFFFF——已终结，锁定时间禁用0xFFFFFFFE——锁定时间生效，无 RBF 信号0xFFFFFFFD——依据 BIP125 发出 RBF 信号（Replace-by-Fee）
输出向量（vout）：资金去向何处？
每个输出由 以聪（Satoshi）计的金额 （8 字节，有符号 int64 小端序）和 ScriptPubKey （可变长度，带 CompactSize 前缀）组成。聪的数值精确编码转账金额——Bitcoin 2100 万枚的最大供应量对应 2,100,000,000,000,000 聪。ScriptPubKey 决定花费条件，包括：P2PKH、P2SH、P2WPKH、P2WSH 或 P2TR。
长度字段使用 CompactSize（VarInt） 编码：小于 0xFD 的值占 1 字节；从 0xFD 起，根据数值大小分别使用 3、5 或 9 字节表示。
Witness 数据：txid ≠ wtxid
Witness 数据（BIP141）按输入逐一序列化为字节向量的栈——紧接在最后一个输出之后、锁定时间之前。关键在于：传统txid 是对 HASH256 序列化结果（ 不含 Marker、Flag 和 Witness）进行哈希计算得到的。而 wtxid 则涵盖包含 Witness 在内的完整扩展格式。由此解决了交易延展性问题：任何人篡改 Witness 都会改变 wtxid，而 txid 保持不变。
txid = HASH256（不含 Witness 的传统序列化）—— wtxid = HASH256（含 Witness 的完整序列化）。这种分离是 SegWit 的核心承诺，也是闪电网络等二层协议的基础。
锁定时间：交易级别的时间锁
交易末尾的 4 字节编码 nLockTime。小于 500,000,000 的值被解读为区块高度，大于等于 500,000,000 的值被解读为 Unix 时间戳。但锁定时间只有在至少一个输入的 Sequence 值小于 0xFFFFFFFE 时才会生效——否则网络将完全忽略该字段。
权重单位与手续费：为何每个字节都至关重要
自 SegWit 起，采用双重权重计算模型。交易权重（Weight Units，WU）的计算公式为：
Weight =（非 Witness 字节数）× 4 +（Witness 字节数）× 1
每个区块最多可包含 4,000,000 WU。虚拟字节（vByte）= WU / 4；手续费以 sat/vByte 为单位。一笔典型的 P2WPKH 交易（1 个输入、2 个输出）约重 561 WU ≈ 141 vByte（截至 2026 年）。Witness 数据的成本因此低于同等数量的基础字节，这直接激励了 SegWit 的推广采用。
延伸阅读
معاملة Bitcoin ليست مجرد حقل مجرد في قاعدة بيانات – بل هي تسلسل بايتات حتمي بالكامل، تحدد ترتيبه وتفسيره قواعد الإجماع، وفي مقدمتها BIP141 وBIP143. من يريد فهم Bitcoin على مستوى البروتوكول يجب أن يعرف كل حقل من هذه الحقول.
البنية الأساسية: ترتيب التسلسل
تتكون المعاملة الحديثة (القادرة على SegWit) بهذا الترتيب تحديداً من: الإصدار (Version) (4 بايت)، الماركر + العلَم (Marker + Flag) (2 بايت، لمعاملات Witness فقط)، متجه المدخلات (vin)، متجه المخرجات (vout)، مكدس Witness لكل مدخل، وLocktime (4 بايت). تُرمَّز جميع الحقول متعددة البايت بتنسيق Little-Endian (LE) – وهو مصدر دائم للأخطاء عند التحليل اليدوي.
الإصدار: 4 بايت تحمل أكثر مما تبدو
يحدد حقل الإصدار قواعد الإجماع المطبَّقة. الإصدار 1 (0x01000000 بتنسيق LE) هو الصيغة الكلاسيكية. أما الإصدار 2 (0x02000000) فيُشير إلى دعم Locktimes النسبية وفق BIP68 – وهو شرط مسبق للشروط الزمنية المستندة إلى Sequence. تقرأ العقد (Nodes) التي تتحقق من المعاملة هذه القيمة أولاً.
ماركر وعلَم SegWit: 0x00 0x01
إذا احتوت المعاملة على بيانات Witness، يتبع حقل الإصدار مباشرةً بايتان: 0x00 (الماركر) و0x01 (العلَم). يُميّز هذا الترويسة الثنائية تنسيق التسلسل الموسَّع عن التنسيق القديم (Legacy). العقد القديمة التي ترى 0x00 بوصفه عدد المدخلات تعتبر المعاملة غير صالحة – وهو آلية أنيقة للتوافق مع الإصدارات السابقة.
متجه المدخلات (vin): من أين يأتي المال؟
يُشير كل مدخل إلى مخرج معاملة غير منفَق (UTXO) عبر حقلين: txid (32 بايت) للمعاملة السابقة، وفهرس vout (4 بايت). مهم: تُخزَّن txid داخلياً بتنسيق Little-Endian، لكنها تُعرَض في مستعرضات الكتل بترتيب معكوس (Big-Endian). هذا العكس في البايتات مصدر شائع للأخطاء.
يُضاف إلى ذلك حقل ScriptSig: بالنسبة لمدخلات Native SegWit (P2WPKH وP2WSH وP2TR)، يكون فارغاً (0x00) – إذ تقع التفويضات الفعلية في مكدس Witness. أما رقم Sequence (4 بايت) فيتحكم في سلوك Locktime وRBF:
0xFFFFFFFF– منتهٍ، Locktime معطَّل0xFFFFFFFE– Locktime نشط، لا إشارة RBF0xFFFFFFFD– إشارة RBF وفق BIP125 (Replace-by-Fee)
متجه المخرجات (vout): إلى أين يذهب المال؟
يتكون كل مخرج من القيمة بالساتوشي (8 بايت، int64 موقَّع بتنسيق LE) وScriptPubKey (طول متغير مع بادئة CompactSize). تُرمِّز قيمة الساتوشي المبلغ الدقيق – إذ يعادل الحد الأقصى لعرض Bitcoin البالغ 21 مليون BTC ما مجموعه 2.100.000.000.000.000 ساتوشي. يحدد ScriptPubKey شرط الصرف: P2PKH أو P2SH أو P2WPKH أو P2WSH أو P2TR.
تُرمَّز حقول الطول بتنسيق CompactSize (VarInt): القيم دون 0xFD تتطلب بايتاً واحداً؛ ومن 0xFD فصاعداً تُستخدم 3 أو 5 أو 9 بايت للقيم الأكبر.
بيانات Witness: txid ≠ wtxid
تُسلسَل بيانات Witness (BIP141) لكل مدخل على شكل مكدس من متجهات البايت – مباشرةً بعد آخر مخرج وقبل Locktime. والأهم: تُحسَب txid القديمة (Legacy) كـHASH256 للتسلسل دون الماركر والعلَم وبيانات Witness. أما wtxid فتشمل التنسيق الموسَّع الكامل بما فيه Witness. بذلك يُحلّ مشكلة قابلية التلاعب بالمعاملات (Transaction Malleability): لا أحد يستطيع التلاعب ببيانات Witness دون تغيير wtxid – فتبقى txid ثابتة.
txid = HASH256(التسلسل القديم بدون Witness) — wtxid = HASH256(التسلسل الكامل مع Witness). هذا الفصل هو الوعد الجوهري لـSegWit وأساس بروتوكولات الطبقة الثانية كشبكة Lightning Network.
Locktime: أقفال زمنية على مستوى المعاملة
تُرمِّز آخر 4 بايت في المعاملة قيمة nLockTime. تُفسَّر القيم دون 500.000.000 على أنها ارتفاع كتلة (Block Height)، أما القيم من 500.000.000 فصاعداً فتُفسَّر كطابع زمني Unix. غير أن Locktime لا يسري إلا إذا كان لدى مدخل واحد على الأقل رقم Sequence أصغر من 0xFFFFFFFE – وإلا تجاهلت الشبكة هذا الحقل كلياً.
Weight Units والرسوم: لماذا يهم كل بايت
منذ SegWit، يُطبَّق نموذج وزن ثنائي المستوى. يُحسَب وزن المعاملة بوحدات Weight Units (WU) على النحو التالي:
Weight = (بايتات غير Witness) × 4 + (بايتات Witness) × 1
يجوز أن تحتوي الكتلة على 4.000.000 WU كحد أقصى. البايت الافتراضي (vByte) = WU / 4؛ وتُقاس الرسوم بوحدة sat/vByte. تزن معاملة P2WPKH نموذجية بمدخل واحد ومخرجين نحو 561 WU ≈ 141 vByte (اعتباراً من 2026). وهكذا تكون بيانات Witness أرخص تكلفةً من عدد مساوٍ من بايتات القاعدة – مما يُشكِّل حافزاً مباشراً لاعتماد SegWit.
مزيد من المعلومات
⚖️ 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.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Ein „Deep Dive" in die Transaktionsstruktur, der Taproot (BIP 340/341/342) komplett übergeht, ist Stand 2026 als Referenz unvollständig: P2TR-Outputs mit Schnorr-Signaturen, Key-Path- vs. Script-Path-Spending und Control Blocks erzeugen strukturell andere Witness-Stacks, an denen Leser mit dem hier vermittelten Wissen scheitern.A 'deep dive' into transaction structure that entirely skips Taproot (BIP 340/341/342) is incomplete as a 2026 reference: P2TR outputs with Schnorr signatures, key-path vs. script-path spending and control blocks produce structurally different witness stacks that readers equipped only with this article's knowledge will fail to parse.Un «análisis en profundidad» de la estructura de transacciones que omite por completo Taproot (BIP 340/341/342) es incompleto como referencia en 2026: los outputs P2TR con firmas Schnorr, el gasto por key path frente a script path y los control blocks producen pilas de witness estructuralmente distintas, ante las cuales fracasará un lector equipado solo con el conocimiento de este artículo.Um 'mergulho profundo' na estrutura de transações que omite completamente o Taproot (BIP 340/341/342) é incompleto como referência em 2026: outputs P2TR com assinaturas Schnorr, gasto por key path versus script path e control blocks produzem pilhas de witness estruturalmente diferentes, diante das quais um leitor munido apenas do conhecimento deste artigo falhará.Taproot(BIP 340/341/342)を完全に省略したトランザクション構造の「徹底解説」は、2026年のリファレンスとしては不完全である。Schnorr署名を用いるP2TRアウトプット、キーパスとスクリプトパスの使い分け、コントロールブロックは構造的に異なるWitnessスタックを生成し、本記事の知識だけを備えた読者は解析に失敗する。一篇完全跳过Taproot（BIP 340/341/342）的交易结构「深度解析」，作为2026年的参考资料是不完整的：使用Schnorr签名的P2TR输出、key path与script path花费方式、以及control block会产生结构上不同的witness栈，仅凭本文知识的读者将无法解析。"غوص عميق" في بنية المعاملات يتجاوز Taproot (BIP 340/341/342) كليا يعد مرجعا ناقصا في 2026: مخرجات P2TR بتوقيعات Schnorr، والإنفاق عبر مسار المفتاح مقابل مسار السكربت، وكتل التحكم تنتج مكدسات Witness مختلفة بنيويا سيفشل في تحليلها قارئ لا يملك سوى معرفة هذا المقال.
Taproot ist seit November 2021 aktiviert, und der P2TR-Anteil an Transaktionen und Outputs ist seither erheblich gewachsen – ein Protokoll-Grundlagenartikel des Jahrgangs 2026, der P2TR zwar als Output-Typ auflistet, dessen Witness-Struktur aber nicht erklärt, deckt einen relevanten Teil realer On-Chain-Daten nicht ab. Was der Artikel beschreibt, ist korrekt; als „Deep Dive" beworben ist die Lücke dennoch substanziell.Taproot has been active since November 2021, and the P2TR share of transactions and outputs has grown substantially since – a 2026 protocol fundamentals article that lists P2TR as an output type but never explains its witness structure fails to cover a relevant portion of real on-chain data. What the article does describe is correct; marketed as a 'deep dive', the gap is nonetheless substantial.Taproot está activo desde noviembre de 2021, y la proporción de P2TR en transacciones y outputs ha crecido sustancialmente desde entonces; un artículo de fundamentos del protocolo de 2026 que lista P2TR como tipo de output pero nunca explica su estructura de witness no cubre una parte relevante de los datos on-chain reales. Lo que el artículo describe es correcto; presentado como «análisis en profundidad», la laguna es no obstante sustancial.O Taproot está ativo desde novembro de 2021, e a participação de P2TR em transações e outputs cresceu substancialmente desde então – um artigo de fundamentos do protocolo de 2026 que lista P2TR como tipo de output mas nunca explica sua estrutura de witness deixa de cobrir uma parte relevante dos dados on-chain reais. O que o artigo descreve está correto; anunciado como 'mergulho profundo', a lacuna é ainda assim substancial.Taprootは2021年11月から有効であり、以来トランザクションとアウトプットに占めるP2TRの割合は大きく伸びている。P2TRをアウトプットタイプとして列挙しながらそのWitness構造を説明しない2026年のプロトコル基礎記事は、実際のオンチェーンデータの相当部分をカバーできていない。記事の記述自体は正確だが、「徹底解説」と銘打つ以上、この欠落は実質的である。Taproot自2021年11月起激活，此后P2TR在交易和输出中的占比大幅增长——一篇2026年的协议基础文章将P2TR列为输出类型却从未解释其witness结构，就未能覆盖真实链上数据中相当重要的一部分。文章所描述的内容本身正确；但既然以「深度解析」为名，这一缺口是实质性的。Taproot مفعل منذ نوفمبر 2021، ونمت حصة P2TR من المعاملات والمخرجات كثيرا منذئذ - مقال أساسيات بروتوكول من عام 2026 يذكر P2TR كنوع مخرجات لكنه لا يشرح بنية الـWitness الخاصة به يفشل في تغطية جزء معتبر من بيانات السلسلة الفعلية. ما يصفه المقال صحيح؛ لكن الفجوة جوهرية في نص يسوق نفسه "غوصا عميقا".
Die Aussage, mit txid/wtxid-Trennung werde „Transaction Malleability gelöst", gilt nur für SegWit-Inputs: Transaktionen, die Legacy-Inputs ausgeben, bleiben durch Signatur-Malleabilität weiterhin verformbar. Wer die Formulierung des Artikels wörtlich nimmt, unterschätzt das Restrisiko gemischter Transaktionen.The statement that the txid/wtxid separation 'solves transaction malleability' holds only for SegWit inputs: transactions spending legacy inputs remain malleable through signature malleability. Readers taking the article's wording literally will underestimate the residual risk of mixed transactions.La afirmación de que la separación txid/wtxid «resuelve la maleabilidad de las transacciones» solo vale para inputs SegWit: las transacciones que gastan inputs legacy siguen siendo maleables mediante la maleabilidad de firmas. Quien tome al pie de la letra la formulación del artículo subestimará el riesgo residual de las transacciones mixtas.A afirmação de que a separação txid/wtxid 'resolve a maleabilidade das transações' vale apenas para inputs SegWit: transações que gastam inputs legacy continuam maleáveis por meio da maleabilidade de assinaturas. Quem tomar ao pé da letra a formulação do artigo subestimará o risco residual de transações mistas.txid/wtxidの分離によって「トランザクション展性が解決された」という記述はSegWitインプットにのみ当てはまる。レガシーインプットを使用するトランザクションは、署名の展性によって依然として改変可能である。記事の表現を文字通りに受け取る読者は、混在トランザクションの残存リスクを過小評価することになる。「txid/wtxid分离解决了交易可延展性」的说法只适用于SegWit输入：花费legacy输入的交易仍可通过签名可延展性被改变。按字面理解文章表述的读者，会低估混合交易的残余风险。القول بأن فصل txid عن wtxid "حل مشكلة مرونة المعاملات" لا يصح إلا لمدخلات SegWit: المعاملات التي تنفق مدخلات قديمة تظل قابلة للتشويه عبر مرونة التوقيعات. من يأخذ صياغة المقال حرفيا سيقلل من تقدير الخطر المتبقي في المعاملات المختلطة.
BIP 141 selbst formuliert die Einschränkung: Nur wenn alle Inputs Witness-Programme ausgeben, ist die txid gegen Dritt-Malleabilität geschützt; Legacy-ScriptSig-Daten fließen weiterhin in die txid ein und sind über DER-Kodierungs- bzw. Signatur-Varianten manipulierbar. Für Layer-2-Konstruktionen (etwa Lightning-Funding) ist deshalb die Verwendung reiner SegWit-Inputs Voraussetzung – eine Präzisierung, die der Artikel schuldig bleibt.BIP 141 itself states the limitation: only when all inputs spend witness programs is the txid protected against third-party malleability; legacy scriptSig data still feeds into the txid and can be manipulated via DER-encoding or signature variants. This is why layer-2 constructions (such as Lightning funding) require pure SegWit inputs – a precision the article fails to provide.El propio BIP 141 formula la limitación: solo cuando todos los inputs gastan programas witness la txid queda protegida contra la maleabilidad de terceros; los datos legacy de scriptSig siguen entrando en la txid y pueden manipularse mediante variantes de codificación DER o de firma. Por eso las construcciones de capa 2 (como el funding de Lightning) exigen inputs puramente SegWit, una precisión que el artículo no ofrece.O próprio BIP 141 formula a limitação: só quando todos os inputs gastam programas witness a txid fica protegida contra maleabilidade de terceiros; dados legacy de scriptSig continuam entrando na txid e podem ser manipulados via variantes de codificação DER ou de assinatura. Por isso construções de camada 2 (como o funding da Lightning) exigem inputs puramente SegWit – uma precisão que o artigo não fornece.BIP 141自体がこの制限を明記している。すべてのインプットがWitnessプログラムを使用する場合にのみ、txidは第三者による展性から保護される。レガシーのscriptSigデータは依然としてtxidに含まれ、DERエンコーディングや署名のバリエーションを通じて操作可能である。だからこそLightningのファンディングのようなレイヤー2の構築には純粋なSegWitインプットが前提となる。記事はこの精密さを欠いている。BIP 141本身就写明了这一限制：只有当所有输入都花费witness程序时，txid才受到第三方可延展性的保护；legacy的scriptSig数据仍会计入txid，可通过DER编码或签名变体被操纵。正因如此，二层构建（如Lightning的资金交易）要求纯SegWit输入——文章欠缺的正是这一精确表述。ينص BIP 141 نفسه على هذا القيد: لا تكون txid محمية من تشويه الأطراف الثالثة إلا حين تنفق جميع المدخلات برامج Witness؛ بيانات scriptSig القديمة تظل تدخل في txid ويمكن التلاعب بها عبر متغيرات ترميز DER أو التوقيع. لهذا تشترط بنى الطبقة الثانية (مثل تمويل Lightning) مدخلات SegWit خالصة - وهي دقة لا يقدمها المقال.
Der Witness-Rabatt wird als eleganter Adoptionsanreiz präsentiert – seine Ökonomie ist jedoch umstritten: Der Faktor 4 verbilligt beliebige Daten im Witness-Bereich und machte die Inscription-Wellen ab 2023 erst wirtschaftlich, die Blockraum zeitweise dominierten. Was der Artikel als reine Effizienzmaßnahme rahmt, ist auch eine Subvention für Nicht-Zahlungsdaten.The witness discount is presented as an elegant adoption incentive – yet its economics are contested: the factor-4 discount makes arbitrary data in the witness area cheap, and it was precisely this that made the inscription waves from 2023 economical, at times dominating blockspace. What the article frames as a pure efficiency measure is also a subsidy for non-payment data.El descuento de witness se presenta como un elegante incentivo de adopción, pero su economía es discutida: el factor 4 abarata datos arbitrarios en el área witness, y fue precisamente eso lo que hizo económicas las olas de inscriptions desde 2023, que por momentos dominaron el espacio de bloque. Lo que el artículo enmarca como pura medida de eficiencia es también una subvención para datos ajenos a los pagos.O desconto de witness é apresentado como um elegante incentivo à adoção – mas sua economia é contestada: o fator 4 barateia dados arbitrários na área de witness, e foi exatamente isso que tornou econômicas as ondas de inscriptions a partir de 2023, que por vezes dominaram o espaço de bloco. O que o artigo enquadra como pura medida de eficiência é também um subsídio para dados que não são pagamentos.Witnessディスカウントは洗練された普及インセンティブとして提示されているが、その経済性には異論がある。4分の1という係数はWitness領域の任意データを安価にし、まさにそれが2023年以降のインスクリプションの波を経済的に成立させ、一時はブロックスペースを支配した。記事が純粋な効率化策として枠づけるものは、非決済データへの補助金でもある。witness折扣被描述为一种巧妙的采用激励——但其经济学存在争议：4倍折扣使witness区域中的任意数据变得廉价，正是这一点让2023年起的铭文热潮具备了经济可行性，一度主导区块空间。文章框定为纯粹效率措施的东西，同时也是对非支付数据的补贴。يقدم خصم الـWitness كحافز أنيق للتبني - لكن اقتصادياته محل خلاف: عامل الخصم 4 يجعل البيانات العشوائية في منطقة الـWitness رخيصة، وهذا بالذات ما جعل موجات الـInscriptions منذ 2023 مجدية اقتصاديا حتى هيمنت أحيانا على مساحة الكتل. ما يؤطره المقال كإجراء كفاءة محض هو أيضا دعم لبيانات ليست مدفوعات.
Der Mechanismus ist belegt – Inscriptions nutzen gezielt den rabattierten Witness-Raum, und die Gebühren-Spitzen 2023/2024 sind dokumentiert. Ob der Rabatt deshalb ein Designfehler ist, bleibt jedoch eine offene Wertungsfrage: Befürworter verweisen darauf, dass Witness-Daten für UTXO-Set und Netzwerklast tatsächlich billiger sind und der Rabatt korrekte Kosten widerspiegelt; Kritiker sehen eine Fehlallokation von Blockraum. Beide Positionen sind mit der Datenlage vereinbar.The mechanism is documented – inscriptions deliberately exploit discounted witness space, and the 2023/2024 fee spikes are on record. Whether the discount is therefore a design flaw remains an open evaluative question: proponents note that witness data genuinely costs less in terms of UTXO-set growth and network load, so the discount reflects true costs; critics see a misallocation of blockspace. Both positions are compatible with the evidence.El mecanismo está documentado: las inscriptions explotan deliberadamente el espacio witness con descuento, y los picos de comisiones de 2023/2024 están registrados. Si el descuento es por ello un defecto de diseño sigue siendo una cuestión valorativa abierta: los defensores señalan que los datos witness realmente cuestan menos en crecimiento del conjunto UTXO y carga de red, por lo que el descuento refleja costes reales; los críticos ven una mala asignación del espacio de bloque. Ambas posiciones son compatibles con los datos.O mecanismo está documentado – inscriptions exploram deliberadamente o espaço witness com desconto, e os picos de taxas de 2023/2024 estão registrados. Se o desconto é por isso um defeito de design permanece uma questão valorativa em aberto: defensores apontam que dados witness realmente custam menos em crescimento do conjunto UTXO e carga de rede, de modo que o desconto reflete custos reais; críticos veem uma má alocação de espaço de bloco. Ambas as posições são compatíveis com as evidências.メカニズム自体は立証されている。インスクリプションは割引されたWitness領域を意図的に利用しており、2023〜2024年の手数料急騰も記録されている。しかしこの割引が設計上の欠陥かどうかは未決の価値判断の問題である。擁護派はWitnessデータがUTXOセットの成長やネットワーク負荷の面で実際に低コストであり、割引は真のコストを反映していると指摘する。批判派はブロックスペースの誤配分と見る。どちらの立場もデータと両立する。该机制有据可查——铭文刻意利用打折的witness空间，2023/2024年的手续费飙升也有记录。但该折扣是否因此构成设计缺陷，仍是一个开放的价值判断问题：支持者指出witness数据在UTXO集增长和网络负载方面确实成本更低，折扣反映了真实成本；批评者则认为这是区块空间的错误配置。两种立场都与现有数据相容。الآلية موثقة - تستغل الـInscriptions عمدا مساحة الـWitness المخفضة، وذروات الرسوم في 2023 و2024 مسجلة. لكن هل الخصم لذلك عيب تصميمي؟ يبقى سؤالا تقييميا مفتوحا: يشير المؤيدون إلى أن بيانات الـWitness أقل كلفة فعلا من حيث نمو مجموعة UTXO وحمل الشبكة فيعكس الخصم التكاليف الحقيقية؛ ويرى المنتقدون سوء تخصيص لمساحة الكتل. كلا الموقفين متوافق مع البيانات.
QuellenSourcesFuentesFontes出典来源المصادر
- BIP141 – Segregated Witness (Consensus layer) (github.com)
- BIP143 – Transaction Signature Verification for SegWit (github.com)
- BIP68 – Relative lock-time using consensus-enforced sequence numbers (github.com)
- BIP125 – Opt-in Full Replace-by-Fee Signaling (github.com)
- Bitcoin Developer Reference – Transactions (developer.bitcoin.org)
- mempool.space – Transaction Explorer (mempool.space)