๐งฐ Too much bitcoin tech knowledge is trapped in videos and podcasts
If only there was an easy way to unearth those insights and gemsโฆ ๐ค
We wondered that too, so we redesigned Bitcoin Transcripts! ๐
๐ Bitcoin Transcripts is a filterable library of transcripts from:
โข dev meetups
โข conferences
โข podcasts
โข panels
Skim talks, quote insights, and search by keyword.
All in one place.
๐ 
โ๏ธ Missed a workshop or podcast episode?
No worries.
You can now quickly search by keyword or topic and read the conversation in minutes instead of watching hours of video,
Accelerating your speed to insights.
๐งโ๐ซ Bitcoin Transcripts is perfect for:
- bitcoin devs digging into prior research
- educators creating content
- researchers analyzing protocol history or
- enthusiasts who prefer reading over listening
Taproot workshops, Lightning panels, itโs all in there.
Open-source and built by the community ๐งก
This project stands on the shoulders of contributors like Bryan Bishop (
) who manually transcribed hundreds of talks.
Now, with modern tools, we can scale that effort for the whole community.
Many thanks to our contributors:
- Dev: @npub1madm...4djz , Jamal (
), Emmanuel (
), @npub1w484...lvz2
- Data & architecture: Andreas (), Urvish (
)
- Vision: @npub1dq94...2pg8
- Design: Tobi (
), Khush (
), @Stephen DeLorme
- Product: @art assoiants
- Inspiration: Bryan Bishop ()
Whatโs next?
Weโll keep adding transcripts from upcoming events and backfill any important historic talks we missed. ๐
Would love your help editing transcripts as well.
Dive in, explore, and let us know what you think! ๐
btctranscripts.com
๐ Bitcoin Transcripts is a filterable library of transcripts from:
โข dev meetups
โข conferences
โข podcasts
โข panels
Skim talks, quote insights, and search by keyword.
All in one place.
๐ Bitcoin Transcripts
A collection of technical bitcoin and lightning transcripts
Bryan Bishop (kanzure)
Bryan Bishop
internet anomaly of code, hardware, and biology
Many thanks to our contributors:
- Dev: @npub1madm...4djz , Jamal (GitHub
jrakibi - Overview
Bitcoiner. jrakibi has 70 repositories available. Follow their code on GitHub.
GitHub
Emmanuel-Develops - Overview
Frontend Developer. Emmanuel-Develops has 59 repositories available. Follow their code on GitHub.
up to the bitcoin hill
Low time preference dev pushing to work on the foundations of the new monetary system.
GitHub
urvishp80 - Overview
ML/AI engineer | Kaggle Competitions Master
. urvishp80 has 66 repositories available. Follow their code on GitHub.
X (formerly Twitter)
Afolabi Oluwatobiloba. (@Adeoye_G) on X
Bitcoin Product Designer and I love food ๐ฅบ
X (formerly Twitter)
Khush (@ikhushh7) on X
Strategic Design - Web3
Bryan Bishop (kanzure)
Bryan Bishop
internet anomaly of code, hardware, and biology
We'll also have weโll have additional prizes for Warnet track winners that are able to join in person. These gorgeous coasters by A+ Engrave are just one example! ๐คฉ
This track is for hackers with some level of coding skill, & the ability to use the command line interface (CLI). Familiarity with Bitcoin Core, esp. the JSON-RPC interface is useful. A general understanding of how blockchains and distributed networks work will come in handy.
Who's ready to win? Sign up below! ๐
๐๐๐ก๐: ๐กโ๐๐ ๐๐ฅ๐๐๐๐๐ ๐๐ ๐๐๐ ๐ ๐ ๐๐๐ค๐๐ก ๐ฃ0 ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐ ๐ ๐ ๐๐๐ ๐๐ ๐กโ๐ ๐ ๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐ก ๐๐๐ ๐๐๐๐๐๐ฆ ๐๐๐ ๐ก๐๐๐๐๐๐ก (๐ ๐๐๐ค๐๐ก ๐ฃ1) ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ . ๐ป๐๐ค๐๐ฃ๐๐, ๐กโ๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐๐๐ก๐ ๐๐๐ ๐ ๐ก๐๐๐ ๐กโ๐ ๐ ๐๐๐!
The transaction we'll be working with has two inputs. The first is a legacy P2PK inputโwe wonโt be covering that today.
Instead, weโre going to focus on the second input, the P2WPKH (native segwit) one.
Since this example came from one of the BIP-143 test vectors, we know what the final, signed transaction looks like. The goal is to recreate this:
First, we create the base transaction, the transaction without any signatures.
Weโll start with the
- version number
- marker & flag fields (to indicate the tx is segwit)
- locktime
๐ด ๐๐๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก ๐ฃ๐ . ๐๐๐๐๐๐ฆ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ : ๐ต๐๐๐๐ข๐ ๐ ๐๐ก ๐๐๐๐ ๐ก ๐๐๐ ๐๐ ๐กโ๐ ๐๐๐๐ข๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก (๐๐๐ก๐๐ฃ๐ ๐๐ ๐ค๐๐๐๐๐๐), ๐กโ๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐๐๐ ๐ ๐๐๐๐ ๐๐๐๐๐๐ ๐ ๐๐๐ค๐๐ก.
Hereโs what we have so far:
Letโs add inputs! Recall that all inputs come from existing transactions. That means for each input, we need to find the transaction it came from and get:
1. that transactionโs ID
2. the output index
๐๐ก๐๐ญโ๐ฌ ๐๐ง ๐จ๐ฎ๐ญ๐ฉ๐ฎ๐ญ ๐ข๐ง๐๐๐ฑ?
Every transaction has a list of outputs. The โoutput indexโ is a way to reference a specific output from the list.
We need to ask, "from a transactionโs list of outputs, which one corresponds to the input I care about?โ
For each input, two more things are needed: the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐ข๐ (placeholder for data required to spend the input), and a ๐ฌ๐๐ช๐ฎ๐๐ง๐๐ ๐ง๐ฎ๐ฆ๐๐๐ซ (usually 0xFFFFFFFF)
After adding all the inputs, the transaction looks like this:
Remember when we said the scriptSig would be a placeholder? Hereโs why those fields are currently empty:
Time to add outputs! For each output, we include the
- amount (in satoshis)
- scriptPubKey: the locking script that defines the rules for how the output can be spent
Things are starting to come together!
A few more things are needed before we can get to signing. First is setting up the ๐ฐ๐ข๐ญ๐ง๐๐ฌ๐ฌ field.
This is where the signature and corresponding public key go for segwit transactions.
The witness field starts off empty. This is different from legacy transactions where signatures are placed directly in the scriptSig field.
The next thing thatโs needed is the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐.
The scriptCode for a P2WPKH (pay-to-witness-public-key-hash) input is:
๐โ๐๐กโ๐ ๐กโ๐๐ก 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ?
๐ธ๐๐๐๐๐๐ ๐ค๐ ๐ ๐๐ค ๐๐๐โ ๐๐ข๐ก๐๐ข๐ก โ๐๐ ๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ (๐๐ข๐๐๐ ๐๐๐ โ๐๐ค ๐ก๐ ๐ ๐๐๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก). ๐ด๐๐ ๐, ๐๐๐๐๐๐ ๐กโ๐๐ก ๐กโ๐ ๐๐๐๐ข๐ก ๐ก๐ ๐๐๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก ๐๐๐๐ ๐๐๐๐กโ๐๐.
๐โ๐ 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ ๐๐ ๐๐ฅ๐ก๐๐๐๐ก๐๐ ๐๐๐๐ ๐กโ๐ ๐๐๐๐๐๐ ๐๐๐๐๐๐๐ ๐๐ข๐ก๐๐ข๐ก'๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ.
Hereโs the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐ for the example weโre working on:
Lastly, three important hashes are required.
The first is ๐ก๐๐ฌ๐ก๐๐ซ๐๐ฏ๐จ๐ฎ๐ญ๐ฌ. Itโs the double SHA256 hash of all input outpoints (outpoint = the transaction id + output index)
The second is ๐ก๐๐ฌ๐ก๐๐๐ช๐ฎ๐๐ง๐๐, the double SHA256 hash of all input sequence numbers.
The third is ๐ก๐๐ฌ๐ก๐๐ฎ๐ญ๐ฉ๐ฎ๐ญ๐ฌ, the double SHA256 hash of all outputs.
Thatโs everything (finally!). Letโs put it all together into something that can be signed!
When signing a transaction, the spender actually signs a hash of the transaction data, not the entire transaction itself. This hash is called the ๐ฌ๐ข๐ ๐ก๐๐ฌ๐ก.
The data used to create the sighash is called the ๐ฉ๐ซ๐๐ข๐ฆ๐๐ ๐.
For a transaction input, the preimage is made of these items:
The sighash_type indicates which parts of the transaction the signature is committing to.
After hashing the preimage twice with SHA-256, weโre left with the sighash.
At last! Itโs time to do some signing!
There are a few steps for signing a segwit (v0) transaction.
First, the signerโs private key is used to create an ECDSA signature for the sighash.
The resulting signature has two parts, ๐ and ๐ .
In ECDSA, there are actually two valid s values for every signature: a "high" value and a "low" value.
Both are mathematically valid, but bitcoin requires using the low s value to prevent transaction malleability (that means altering a transaction's ID!)
After selecting the low s value, the signature must be encoded into DER format. This is how itโs structured:
And hereโs what the DER encoded signature looks like for our example:
The last step is to add a byte at the end for the sighash type. If we look back at the preimage made earlier we see this example is using SIGHASH_ALL (0x01).
The full code for the signing step looks like this:
Remember the transaction witness field we set space aside for? Itโs now time to put the signature in it ๐
This is how the witness field is structured:
Which works out to be this for our example:
With the completion of the witness field, the transaction is now signed!
This is what the final signed transaction hex looks like broken down:
Bonus: You can use the Bitcoin Core CLI decoderawtransaction command to examine all the parts of the raw transaction hex
* ~ * ~ * ~ * ~ * ~ * ~
If you made it to the end, give yourself a pat on the back. If you enjoyed it, be sure to like this post so we know to make more like it!
* ~ * ~ * ~ * ~ * ~ * ~
This material is from Decoding Bitcoin, your go-to resource for understanding bitcoin, #privacy, and #decentralization.
You can visit 
Hope you learned something new about transaction signing. If you enjoyed this, share it with a friend and donโt forget to follow us, 
Similarly, computers have two ways to store data:
1. ๐๐ข๐ -๐๐ง๐๐ข๐๐ง (BE): Most significant byte first
2. ๐๐ข๐ญ๐ญ๐ฅ๐-๐๐ง๐๐ข๐๐ง (LE): Least significant byte first
When computers with different byte orders try to communicate, they can misread each other. Itโs like two people reading numbers from opposite directions.
๐๐ข๐ -๐๐ง๐๐ข๐๐ง ๐ฌ๐ญ๐จ๐ซ๐๐ฌ ๐ญ๐ก๐ ๐ฆ๐จ๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ ๐๐ข๐ซ๐ฌ๐ญ. This is similar to how humans read numbers and Hex in most cases: starting with the most important information.
Suppose we want to store the number 12345678 (hexadecimal: 0x00BC614E) in memory. In big-endian, the bytes are stored in this order:
00 BC 61 4E
Observe that:
- The ๐ฆ๐จ๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ (00) is stored at the ๐ฅ๐จ๐ฐ๐๐ฌ๐ญ ๐ฆ๐๐ฆ๐จ๐ซ๐ฒ ๐๐๐๐ซ๐๐ฌ๐ฌ (00).
- The ๐ฅ๐๐๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ (4E) is stored at the ๐ก๐ข๐ ๐ก๐๐ฌ๐ญ ๐๐๐๐ซ๐๐ฌ๐ฌ (03).
Big-endian is considered more "human-readable" because the data is stored in the order we naturally read it.
๐๐ข๐ญ๐ญ๐ฅ๐-๐๐ง๐๐ข๐๐ง ๐ฌ๐ญ๐จ๐ซ๐๐ฌ ๐ญ๐ก๐ ๐ฅ๐๐๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ ๐๐ข๐ซ๐ฌ๐ญ. This might feel counter intuitive to humans but is more efficient for modern processors.
Using the same number 12345678 (0x00BC614E), here's how it looks in little-endian:
4E 61 BC 00
This time, the ๐ฅ๐๐๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ (4E) is stored at the ๐ฅ๐จ๐ฐ๐๐ฌ๐ญ ๐ฆ๐๐ฆ๐จ๐ซ๐ฒ ๐๐๐๐ซ๐๐ฌ๐ฌ (00).
The ๐ฆ๐จ๐ฌ๐ญ ๐ฌ๐ข๐ ๐ง๐ข๐๐ข๐๐๐ง๐ญ ๐๐ฒ๐ญ๐ (00) is stored at the ๐ก๐ข๐ ๐ก๐๐ฌ๐ญ ๐๐๐๐ซ๐๐ฌ๐ฌ (03).
This "reversal" of bytes is common in the Bitcoin Core codebase.
In bitcoin, most data like transaction IDs, block headers, and amounts are all in little-endian format or with the bytes reversed.
๐๐๐ก๐: ๐ธ๐๐๐๐๐๐๐๐ ๐ ๐๐๐๐ฆ ๐๐๐๐๐๐๐ ๐ก๐ ๐๐๐ก๐๐๐๐๐ . ๐ผ๐ก ๐๐ ๐๐๐ก ๐๐๐๐๐๐๐ก ๐ก๐ ๐ ๐๐ฆ ๐ โ๐๐ โ ๐๐ ๐๐๐ก๐ก๐๐-๐๐๐๐๐๐. ๐๐๐๐๐ ๐กโ๐๐๐โ๐ ๐๐ ๐๐๐๐๐๐๐๐ ๐ก๐๐๐ ๐๐๐ ๐กโ๐๐ ๐ค๐ ๐ ๐๐ฆ โ๐๐ฆ๐ก๐ ๐ ๐ค๐๐๐๐๐โ ๐๐ โ๐๐๐ฃ๐๐๐ ๐ ๐๐ฆ๐ก๐๐ โ.
For readability, the bytes are swapped back to the style of big-endian when this data is displayed to humans. A block explorer is one example of where you can see this.
Bitcoin Coreโs JSON-RPC interface was the first time block hashes were printed for human consumption. That was when someone decided to reverse the ordering of hash so that it looked like a human readable integer.
It turns out the real block hash, the actual sha256 value you get if you compute the hash yourself, is:
e4b1d56439d46d9070e58c4368cccc97596fa908daf101000000000000000000
The zeros are actually on the right! At first glance it looks like this is a very large number, but we know the integer value of a block hash actually gets smaller as the difficulty increases.
It's clear that the bytes are reversed and in the style of little-endian. But why? We can thank Satoshi for that. Satoshi decided to interpret the block hash as a little-endian integer. The more zeroes there are on the right side, the smaller the (little-endian) integer.
Since most modern CPUs are little-endian, bitcoin uses it to optimize performance.
However, network protocols typically use big-endian, creating a mismatch ๐
Big-endian is used for network communication (network byte order). Little-endian is used for bitcoinโs internal storage.
This duality requires developers to frequently, and sometimes frustratingly, convert between the two formats when working with bitcoin data.
Have you been the victim of an endianness oversight when writing bitcoin code? It's a common source of pain for developers new to bitcoin (and even the seasoned ones!)
As covered by the transaction ID example earlier, byte order confusion can be common.
Another gotcha is length specification. When converting to little-endian, always specify the correct byte length:
Hope you learned something new about endianness today. If you enjoyed this, share it with a friend and donโt forget to follow us, 
