- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
โ HOW DOES IT WORK? โ
The challenge kicks off the week of January 12
๐๏ธ 30 days to complete a series of code-based technical challenges
๐ฃ๏ธ 2 additional months for anyone willing to continue the adventure
If you are willing to do the work, we'll give you what you need to get to where you want to go.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
๐งโ๐คโ๐ง LEARNING IS BETTER WITH FRIENDS ๐งโ๐คโ๐ง
Thatโs why weโre delighted to announce โฟOSS Challenge partnerships with:
- @Btrust
- @bitshala
- @La Librerรญa de Satoshi
- @BOBSpace_BKK
- @Code Orange Dev School
- zzmjxy in China
- My Satoshis in Burundi
๐ Live in one of these regions? Reach out to connect with others doing the โฟOSS Challenge!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Funding for bitcoin open source development is earned by demonstrating proof of work. There is no cheat code.
๐งก Come do the work and good things will happen. ๐งก
The โฟOSS Challenge gives you structure while fostering the proactive, self-starter spirit that is required in open-source.
Join the challenge.
See how far you will go.
Change your life in 2026.
โฐ Applications close: December 31
๐ฏ Program begins: January 12
๐ Open to everyone. Totally free.
Application: bosschallenge.xyz
#bitcoin
For the last few years you have trusted the Bitcoin Dev Project (BDP) to bring high quality, open-source tools and education to the developer community.
Today, as a symbol of our ongoing commitment to this mission, we are proud to reveal a fresh look.
๐ฟ ๐ฟ ๐ฟ
Letโs start with the pangolin in the room
Yes, that is a pangolin. Is this unexpected? Yes. Is it intentional? Very much.
Pangolins are solitary, curious creatures known for their armour-like scales and quiet determination. Like the best open-source contributors, they build, explore, and protect what matters. To us, they represent the kind of thoughtful, persistent energy we see in the bitcoin dev community every day.
๐ฟ ๐ฟ ๐ฟ
How it began
In 2023, BDP was born from a desire to build for the developer ecosystem. We created efficiency boosting tools like Bitcoin Search and ChatBTC. From there, a suite of educational products and even games emerged with things like Decoding Bitcoin and Saving Satoshi. This past year we rounded our offerings out with the Common Application which helps contributors apply for funding.
BDP has been lovingly designed to serve the developer community in a way that is approachable and encouraging, yet without compromising the hard work and discipline required of bitcoin development.
There is much more to bitcoin tech than what is seen at the surface. That is why we created BDP to be a place where you can grow your technical skills without the noise.
Anyone in the world should be able to participate in bitcoin development. If you do the work, BDP is there to help you reach your goals.
๐ฟ ๐ฟ ๐ฟ
A reimagined website
Youโve seen the logo but thatโs not all. This makeover goes far beyond that. Instead, the BDP website has been completely reimagined to deliver more moments of delight, improved navigation, and easy access to our tools and resources.
The new illustrations, icons, and vibrant color palette are all inspired by the pangolinโs natural habitat. With an earthy, nature-inspired theme, the website is warm and inviting, reflecting BDPโs goal of being a welcoming entry point into bitcoin development.
Despite all the changes, youโll still find the things you have come to expect from BDP: learning material, developer tools, and funding guidance. BDP provides new opportunities for you to explore and take meaningful steps toward becoming a bitcoin developer.
๐ฟ ๐ฟ ๐ฟ
Design secrets
For more on how the logo and website came to life, check out this blog post by our amazing designer Sanya.
https://medium.com/@bitcoindevs/glow-up-95008146d653
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!๐
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: @0tuedon , Jamal (https://github.com/jrakibi), Emmanuel (https://github.com/Emmanuel-Develops), @Theophilus
- Data & architecture: Andreas (https://www.kouloumos.com/), Urvish (https://github.com/urvishp80)
- Vision: @Jonas
- Design: Tobi (https://x.com/Adeoye_G), Khush (https://x.com/ikhushh7), @Stephen DeLorme
- Product: @art assoiants
- Inspiration: Bryan Bishop (https://heybryan.org/)
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
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, @Bitcoin Dev Project for more content like this.
Thanks for reading!
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, @Bitcoin Dev Project !
This material is from Decoding Bitcoin, your go-to resource for understanding #bitcoin, privacy, and decentralization.
Visit 
UTXOs are unspent transaction outputs. They can be used as inputs for new transactions.
Think of them as "coins" in a wallet, waiting to be spent.
Alice checks her wallet and finds two UTXOs:
To create a transaction, Alice has to specify exactly which UTXOs to spend.
A UTXO is identified by the transaction it came from, specifically
- the transaction ID and
- an index that says where the UTXO is in the list of transaction outputs
Wallets usually store this information for you but you can also look it up on the blockchain.
Alice's wallet shows these available UTXOs:
- UTXO #1: 4 BTC (from Transaction 1, Output Index 1)
- UTXO #2: 2 BTC (from Transaction 2, Output Index 0)
Together, they provide enough funds (4 BTC + 2 BTC = 6 BTC) for the payment and any transaction fees.
Now Alice has everything she needs to identify her UTXOs. As she adds them to the transaction, she saves space for the signatures she will make later. These signatures authorize the spending of the UTXOs.
Now that the transaction inputs have been taken care of, itโs time to look at the outputs!
Alice needs to create two outputs:
- 5 BTC to Bob (the payment amount)
- 0.99 BTC back to Alice as change (there is a 0.01 BTC transaction fee)
Why do we have to make a separate output for change?
UTXOs must be spent in their entirety. You cannot partially spend a UTXO. Instead, you create a new output that sends the excess amount back to yourself as change.
Looks good! The transaction structure is now complete, but itโs not yet valid. Alice must sign it to prove she owns the inputs. Weโll cover that in a future lesson ๐
Follow us @Bitcoin Dev Project to stay updated!
This material is from Decoding Bitcoin, your go-to resource for understanding #bitcoin, privacy, and decentralization.
If you enjoyed it, visit
Here's how to calculate the fee for this transaction: 
Fees incentivise miners to include transactions in blocks. Without fees, miners would have little reason to put transactions into blocks!
In addition to fees, miners also receive a block reward.
Total miner revenue = fees + block reward
How do miners decide what transactions go into a block?
The short answer is miners will usually maximize revenue by prioritizing transactions with the highest fee rate (we've got a whole lesson fee rates coming!)
While miners can choose which transactions to include based on fees, there's a minimum threshold, a "minimum relay fee" that must be met just for a transaction to be relayed through the network.
Transactions below this threshold are rejected by nodes. It helps prevent spam and DoS attacks on the network
This brings us to an important question: What happens if you submit a transaction with a fee rate above the minimum but still too low for current network conditions?
That transaction could sit in the mempool for hours because the fee rate is too low for the high level of network activity. Even if you met the minimum, there can still be plenty of transactions with higher fee rates than yours, ones that miners will choose first.
At this point, you have two main ways to "unstick" it:
1. RBF (Replace-by-Fee)
2. CPFP (Child Pays for Parent)
--------------------------------
That's all for now! We'll dive deeper into fee rates, RBF, and CPFP in a future post.
This material is from Decoding Bitcoin, your go-to resource for understanding #bitcoin, privacy, and decentralization.
If you enjoyed it, visit
The account model is like your bank statement. Simple to understand and works well with smart contracts. The downside is it's less private and can be vulnerable to replay attacks.
The UTXO model is like bills in a wallet. UTXOs (unspent transaction outputs) can only be spent once. Each transaction creates new UTXOs, and your balance is the sum of all your unspent UTXOs
This model has better privacy, prevents double spending, and allows for parallel transaction processing. The cons are it's more difficult to understand, is harder for complex applications, and requires UTXO management.
Here's a comparison chart of the two models:
This material is from Decoding Bitcoin, your go-to resource for understanding #bitcoin, privacy, and decentralization.
If you enjoyed it, visit
