<p>What you're seeing is the extended transaction serialization format introduced in BIP144 (segregated witness). It adds a marker 0x0001 to indicate the presence of a witness after the version number, and a list of witness stack items after the transaction inputs.</p>

CC BY-SA 4.0
2021-06-13T03:39:33.407Z
oh thank you mysterious internet saint haha. I found https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki and it looks like it accounts for everything. Its so hard to learn this stuff when the official docs are out of date
noone392
CC BY-SA 4.0
2021-06-13T03:45:13.123Z
I'm afraid you'll need to learn that there is nothing "official" in Bitcoin.
Pieter Wuille
CC BY-SA 4.0
2021-06-13T03:47:11.843Z
yeah that is unfortunate. At this point I have decided just to run bitcoin core in debug mode and just watch what the code does and reverse engineer it. It appears to be easier then looking for information on the internet... unless there was someone I could pay to answer my questions LOL
noone392
CC BY-SA 4.0
2021-06-13T03:50:39.390Z
There is a great site, called https://bitcoin.stackexchange.com, where people are willing to answer certain questions for free though!
Pieter Wuille
CC BY-SA 4.0
2021-06-13T03:36:36.760Z
2021-06-13T03:36:36.760Z
Pieter Wuille
<p>I have become fairly familiar with constructing raw transaction. One thing I can't understand is after a raw transaction comes back from a signing, it doesn't look like it conforms to the transaction formatting. I was wondering if there was a different specification for signed raw transactions vs unsigned as shown here
<a href="https://developer.bitcoin.org/reference/transactions.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/transactions.html</a>
here is the original unsigned raw broken into its chunks</p>
<blockquote>
<p>02000000 01
5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
01000000 00 ffffffff 01 968601000000 00
00160014e874b2647cf1f47e7d360a0e9753045950910f8a 00000000</p>
</blockquote>
<p>the following is a signed raw transaction. I can see the parts that were added but the 0001 specifically should have the first byte be none zero sense it is a compactSize type. The bold areas were the data that was added. Obviously the second long hex is the signature/unlocking script of sorts but I can't find where to decode that either in the docs.</p>
<blockquote>
<p>02000000 <strong>0001</strong> 01
5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
01000000 00 ffffffff 01 9686010000000000 16
0014e874b2647cf1f47e7d360a0e9753045950910f8a
<strong>02473044022049ea695e1e7454be2e365142faa8258b8f5ce58b2c9cd9474085ce23df1b7e220220349da1acb0327a5025a0ed85dd88e9628703ed4086f4f8f4ac9b3c020a855bce012103773c3298e0ab8b000b48691c9262e774376239e23069370509e643217062010f</strong>
00000000</p>
</blockquote>
<p>Any help is greatly appreciated.</p>

<script><raw-transaction><signrawtransaction>
signed raw transaction does not conform?
noone392
# signed raw transaction does not conform?

(Asked by: username_0 on 2021-06-13)

I have become fairly familiar with constructing raw transaction. One thing I can't understand is after a raw transaction comes back from a signing, it doesn't look like it conforms to the transaction formatting. I was wondering if there was a different specification for signed raw transactions vs unsigned as shown here
<https://developer.bitcoin.org/reference/transactions.html>
here is the original unsigned raw broken into its chunks

> 02000000 01
> 5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
> 01000000 00 ffffffff 01 968601000000 00
> 00160014e874b2647cf1f47e7d360a0e9753045950910f8a 00000000

the following is a signed raw transaction. I can see the parts that were added but the 0001 specifically should have the first byte be none zero sense it is a compactSize type. The bold areas were the data that was added. Obviously the second long hex is the signature/unlocking script of sorts but I can't find where to decode that either in the docs.

> 02000000 **0001** 01
> 5aab7df5106f76ae87544058edf7768fcb4c8fcbe2906d7ef9721a261bf505d3
> 01000000 00 ffffffff 01 9686010000000000 16
> 0014e874b2647cf1f47e7d360a0e9753045950910f8a
> **02473044022049ea695e1e7454be2e365142faa8258b8f5ce58b2c9cd9474085ce23df1b7e220220349da1acb0327a5025a0ed85dd88e9628703ed4086f4f8f4ac9b3c020a855bce012103773c3298e0ab8b000b48691c9262e774376239e23069370509e643217062010f**
> 00000000

Any help is greatly appreciated.

**Tags:** script, raw-transaction, signrawtransaction


---

## 1 answers

### Answer by username_1 on 2021-06-13. Score: 3 | Accepted answer

What you're seeing is the extended transaction serialization format introduced in BIP144 (segregated witness). It adds a marker 0x0001 to indicate the presence of a witness after the version number, and a list of witness stack items after the transaction inputs.

> **Comments:**
> **username_0**: oh thank you mysterious internet saint haha. I found https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki and it looks like it accounts for everything. Its so hard to learn this stuff when the official docs are out of date  
> **username_1**: I'm afraid you'll need to learn that there is nothing "official" in Bitcoin.  
> **username_0**: yeah that is unfortunate. At this point I have decided just to run bitcoin core in debug mode and just watch what the code does and reverse engineer it. It appears to be easier then looking for information on the internet... unless there was someone I could pay to answer my questions LOL  
> **username_1**: There is a great site, called https://bitcoin.stackexchange.com, where people are willing to answer certain questions for free though!  

---

