Reminder that there is still time to apply for the Bitcoin Scholarship!
Contribute to bitcoin and get a full year of your college tuition covered in return. Open to applicants anywhere in the world.
Sound too good to be true? Meet the 2025 winner, Ishaana Misra.
Ishaana taught herself C++ in high school and became the youngest contributor to Bitcoin Core in the process. She is now a freshman at MIT and president of the MIT Bitcoin Club.
Congrats Ishaana! Her story shows that even as a student you can make meaningful contributions to bitcoin.
Ready to apply for the scholarship? Click the link below!๐
Ishaana taught herself C++ in high school and became the youngest contributor to Bitcoin Core in the process. She is now a freshman at MIT and president of the MIT Bitcoin Club.
Congrats Ishaana! Her story shows that even as a student you can make meaningful contributions to bitcoin.
Ready to apply for the scholarship? Click the link below!๐
The Bitcoin Scholarship
100% of college tuition covered to encourage the brightest minds to contribute to bitcoin open source development
If youโre already subscribed to the mailing lists but feel overwhelmed, try out the Bitcoin TLDR newsletter. Itโs got weekly summaries of all the latest activity, providing a manageable way for you to stay on top of it all.
How Does It Work?
- The Scraper Repo
This scrapes through Delving Bitcoin and the Bitcoin Dev Mailing List, fetches mailing list pages, and stores them locally.
A parser processes those files to extract clean metadata and message content.
Finally, an indexer pushes the structured documents into an index in Elasticsearch for search and analysis.
- The Summarizer
The summarizer repo has two main parts. First, it makes sure Elasticsearch always has the latest full thread data by syncing the combined XML files. Second, it adds short AI summaries to posts that donโt have one yet. This way, Elasticsearch stores both the complete thread summaries, and individual post.
Third, it creates AI summaries for the full thread, creating a combined summary.
- The TLDR Frontend
This renders summaries for each thread and post, and displays them with a beautiful UI.
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bitcoin TLDR is completely free and open-source. Itโs designed to help more people engage with high signal bitcoin and lightning tech discussions. Give it a try and let us know what you think!
โก๏ธ tldr.bitcoinsearch.xyz
๐ 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.
๐ 
Many thanks to our contributors:
- Dev: 
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, 