<p>From Bitcoin Core's <a href="https://github.com/bitcoin/bitcoin/blob/v0.13.1rc2/src/primitives/transaction.h#L275" rel="noreferrer">primitive/transaction.h</a>:</p>

<pre><code>/**
 * Basic transaction serialization format:
 * - int32_t nVersion
 * - std::vector&lt;CTxIn&gt; vin
 * - std::vector&lt;CTxOut&gt; vout
 * - uint32_t nLockTime
 *
 * Extended transaction serialization format:
 * - int32_t nVersion
 * - unsigned char dummy = 0x00
 * - unsigned char flags (!= 0)
 * - std::vector&lt;CTxIn&gt; vin
 * - std::vector&lt;CTxOut&gt; vout
 * - if (flags &amp; 1):
 *   - CTxWitness wit;
 * - uint32_t nLockTime
 */
</code></pre>

<p>In other words, before the txin count, there is a <code>0x00 0x01</code> sequence (which would otherwise be interpreted as a transaction with 0 inputs and 1 output, which cannot be valid), and before the locktime there is a witness record for each input (the txin count is not repeated, it's implicitly assumed to be equal to the txin count given before).</p>

CC BY-SA 3.0
2016-10-20T18:22:20.830Z
Thank you, Pieter. Is there a specific version number that will be used to identify SegWit transactions?
inersha
CC BY-SA 3.0
2016-10-20T18:24:01.150Z
No, that's not possible. The version number is part of the serialized data. If we used that to identify the type of serialization itself, a new node wouldn't understand transactions passed by old nodes (which would have the new version number, but the old serialization).
Pieter Wuille
CC BY-SA 3.0
2017-03-24T18:44:57.723Z
@PieterWuille Is there any change to the BLOCK serialization? For example, are ALL tx witnesses appended to the end of an otherwise backwards-compatible block? Or do all the witnesses remain where they normally occur in each `tx`, but are stripped out before serializing for a non-SW node? Do the `dummy` and `flags` bytes need to be stripped out as well for non-SW nodes?
pinhead
CC BY-SA 3.0
2017-03-24T19:01:21.813Z
A witness block is serialized as a normal block, but with witness serialization for the transactions. So the dummy and flags need to be stripped before relay to old nodes, indeed.
Pieter Wuille
CC BY-SA 3.0
2017-03-24T22:10:55.700Z
@PieterWuille got it thanks. And the dummy byte - that makes SW transactions individually NOT backwards compatible? Are there any network-layer consequences of this? Will old nodes ban SW nodes or anything like that?
pinhead
CC BY-SA 3.0
2017-03-24T22:15:35.533Z
The _serialization_ of SW transactions is not compatible. The transactions are. See http://bitcoin.stackexchange.com/questions/52152/how-is-segwit-a-soft-fork/52153#52153
Pieter Wuille
CC BY-SA 4.0
2016-10-20T18:15:02.840Z
2018-05-17T17:34:33.130Z
2018-05-17T17:34:33.130Z
Pieter Wuille
<p>I'd like to learn how <strong>segregated witness</strong> works, and I thought the <em>raw transaction data</em> would be a good place to start</p>

<p>If this is the structure of current transactions:</p>

<pre><code>version | [inputcount] {[txid] [vin] [signature] [sequence]} | [outputcount] {value} {varint} {lockingscript} | [locktime]
</code></pre>

<p>What does a segregated witness transaction look like?</p>

<raw-transaction><segregated-witness>
What does a segregated witness transaction look like?
inersha
# What does a segregated witness transaction look like?

(Asked by: username_0 on 2016-10-20)

I'd like to learn how **segregated witness** works, and I thought the *raw transaction data* would be a good place to start

If this is the structure of current transactions:

```
version | [inputcount] {[txid] [vin] [signature] [sequence]} | [outputcount] {value} {varint} {lockingscript} | [locktime]

```

What does a segregated witness transaction look like?

**Tags:** raw-transaction, segregated-witness


---

## 1 answers

### Answer by username_1 on 2016-10-20. Score: 12 | Accepted answer

From Bitcoin Core's [primitive/transaction.h](https://github.com/bitcoin/bitcoin/blob/v0.13.1rc2/src/primitives/transaction.h#L275):

```
/**
 * Basic transaction serialization format:
 * - int32_t nVersion
 * - std::vector<CTxIn> vin
 * - std::vector<CTxOut> vout
 * - uint32_t nLockTime
 *
 * Extended transaction serialization format:
 * - int32_t nVersion
 * - unsigned char dummy = 0x00
 * - unsigned char flags (!= 0)
 * - std::vector<CTxIn> vin
 * - std::vector<CTxOut> vout
 * - if (flags & 1):
 *   - CTxWitness wit;
 * - uint32_t nLockTime
 */

```

In other words, before the txin count, there is a `0x00 0x01` sequence (which would otherwise be interpreted as a transaction with 0 inputs and 1 output, which cannot be valid), and before the locktime there is a witness record for each input (the txin count is not repeated, it's implicitly assumed to be equal to the txin count given before).

> **Comments:**
> **username_0**: Thank you, username_1. Is there a specific version number that will be used to identify SegWit transactions?  
> **username_1**: No, that's not possible. The version number is part of the serialized data. If we used that to identify the type of serialization itself, a new node wouldn't understand transactions passed by old nodes (which would have the new version number, but the old serialization).  
> **username_2**: @username_1 Is there any change to the BLOCK serialization? For example, are ALL tx witnesses appended to the end of an otherwise backwards-compatible block? Or do all the witnesses remain where they normally occur in each `tx`, but are stripped out before serializing for a non-SW node? Do the `dummy` and `flags` bytes need to be stripped out as well for non-SW nodes?  
> **username_1**: A witness block is serialized as a normal block, but with witness serialization for the transactions. So the dummy and flags need to be stripped before relay to old nodes, indeed.  
> **username_2**: @username_1 got it thanks. And the dummy byte - that makes SW transactions individually NOT backwards compatible? Are there any network-layer consequences of this? Will old nodes ban SW nodes or anything like that?  
> **username_1**: The _serialization_ of SW transactions is not compatible. The transactions are. See http://bitcoin.stackexchange.com/questions/52152/how-is-segwit-a-soft-fork/52153#52153  

---

