bitcoin_devs

bitcoin


# P2PK - Pay To Public Key

- *We're starting a series of posts to teach you about Bitcoin development. We'll be sharing them here. Tell us how we can make it better!*
- *If you prefer reading on the website, check 👉 https://bitcoindevs.xyz/decoding/p2pk*


![](https://m.stacker.news/65026)  


The first payment on the Bitcoin network was a P2PK transaction in [block 170](https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16), where Satoshi Nakamoto sent 10 BTC to Hal Finney.

We will explore this transaction in detail to understand how P2PK works, from its creation to its validation.   

Understanding P2PK z as an ideal foundation for more complex scripts.

**TL;DR:** P2PK allows bitcoins to be sent directly to a _public key_. To spend the bitcoins, the recipient must provide a _valid signature_.

> **NOTE:** Despite being simple, P2PK is not as widely used as P2PKH. We'll cover why this is the case later on.

---

## How Does It Work?

The ability to lock and unlock coins is the mechanism by which we transfer bitcoin.

- **Locking:** Giving bitcoins to someone.
![](https://m.stacker.news/65028)

- **Unlocking:** Spending bitcoins you have received.
![](https://m.stacker.news/65027)

---

### 1. Locking (ScriptPubKey)

![](https://m.stacker.news/65029)

When creating this P2PK transaction, Satoshi specifies **Finney's public key in the ScriptPubKey**.  
This script specifies the conditions that must be met to spend the bitcoins in the future, and it's placed within the output of a transaction.

**ScriptPubKey:** A P2PK locking script looks like this:

`<Public key Finney> OP_CHECKSIG`

![](https://m.stacker.news/65033)

- **OP_PUSHBYTES_65:** (41 in Hex) Length of the uncompressed public key (65 bytes).
- **04ae1a...6cd84c:** Represents Hal Finney's uncompressed public key.
- **OP_CHECKSIG:** (0xac in Hex) Verifies the signature for the provided public key. It returns TRUE (1) if valid, otherwise FALSE (0).

> **Why Did Satoshi Use an Uncompressed Public Key (65 Bytes)?**  
> Some have [speculated](https://bitcoin.stackexchange.com/a/5960) that Satoshi was unaware of public key compression.  
> Compressed public keys are smaller, leading to smaller transactions and saving block space.



---

### 2. Unlocking (ScriptSig)

![](https://m.stacker.news/65030)

To spend the bitcoins Satoshi sent, Finney must provide a valid signature corresponding to the public key.  
This signature proves that Finney has the private key corresponding to the public key specified in the ScriptPubKey.

**ScriptSig:** A P2PK unlocking script looks like this:

`<Signature Finney>`

![](https://m.stacker.news/65031)

- ** OP_PUSHBYTES_71:** (47 in Hex) Length of the signature (71 bytes).
- **30442 ... 914f01:** Signature followed by SigHash byte
---

### 3. Validation

Bitcoin uses **Script**, a stack-based scripting language, to validate transactions.  
It processes commands from left to right and is intentionally designed to be non-Turing complete, lacking features like loops.

When validating a transaction, the ScriptSig and ScriptPubKey are combined. This concatenated script looks something like this:

`<signature Finney> <public key Finney> OP_CHECKSIG`

The combined script will validate if the signature is valid, but fail if the signature is invalid.

> **NOTE:** For the script to be valid, the top element of the stack must be non-zero after evaluation.

You can play with this tool below to see step by step how we evaluate P2PK the stack by visiting https://bitcoindevs.xyz/decoding/p2pk


![](https://m.stacker.news/65036)




Decoding #3: P2PK explained simply

# 📬 TLDR: Stay Updated with Bitcoin Development!


- *The Bitcoin TLDR Newsletter keeps you informed about key discussions from the **bitcoin-dev**, **lightning-dev**, and **delving bitcoin** mailing lists.*

- [Subscribe and get our weekly newsletter on what matters in bitcoin.](https://bitcoindevs.xyz/decoding/newsletter)

![](https://m.stacker.news/64723)

---

## 🗞️ TLDR Newsletter: Nov 18 - Nov 25

---

#### **Consensus Cleanup: Prevent Duplicate Coinbase Transactions**
***Author:** Antoine Poinsot*
***Date:** November 22*
- Antoine Poinsot has launched a discussion on the Consensus Cleanup proposal.
- The proposal aims to prevent duplicate Bitcoin coinbase transactions.
- Feedback from engineers and stakeholders in the mining industry is sought.

---

#### **Slashing Covenants**
***Author:** Ethan Heilman*
***Date:** November 24*
- Slashing covenants offer a novel way to enforce Bitcoin rules, penalizing rule violations with fund slashing.
- They utilize existing Bitcoin scripts and Lamport signatures to prove signature identity without direct comparison.
- While designed for Bitcoin, the protocol could be easier to implement on Ethereum, suggesting broader blockchain applicability.


---

### 🗞️ **Active Discussions**

---

#### **LNhance BIPs and Implementation**  
**Author:** moonsettler | **Source:** Delving Bitcoin | **Replies:** 18  
- LN-Symmetry in blockchain can be achieved using `CTV` and `CSFS` opcodes.  
- Tools like `IKEY` and `PC` complement these opcodes for LN-Symmetry.  
- LNhance is highlighted as the best solution for blockchain data availability issues.  

**Other contributors:** reardencode, michaelfolkson +7 others

---

#### **CHECKSIGFROMSTACK (VERIFY/ADD)**  
**Author:** moonsettler | **Source:** Bitcoin-dev | **Replies:** 4  
- Discusses removing `OP_CHECKSIGFROMSTACKVERIFY` from LNhance and CSFS BIP.  
- Suggests combining `OP_CSFS` with `OP_VERIFY` to streamline the codebase.  
- Elimination justified by limited use cases and potential tapscript backporting.

**Other contributors:** Antoine Poinsot, Brandon Black +1 other

---

#### **OP_PAIRCOMMIT for LNhance**  
**Author:** moonsettler | **Source:** Delving Bitcoin | **Replies:** 12  
- LNhance integrates `CTV` and `CSFS` with `IKEY` for contract efficiency and cooperative closes.  
- Tackles challenges like "data availability" and controversies around `OP_CAT`.  
- Future upgrades with `OP_CHECKCONTRACTVERIFY` or `OP_VAULT/RECOVER` could improve vault flexibility.  

**Other contributors:** 1440000bytes, ajtowns

---

#### **CTV, APO, CAT Activity on Signet**  
**Author:** vostrnad | **Source:** Delving Bitcoin | **Replies:** 3  
- A tool was developed to simplify Bitcoin Inquisition transaction analysis.  
- Inspired by past investigations; feedback is welcomed for further improvement.  

**Other contributors:** 1440000bytes, AdamISZ +1 other

---

#### **Updates to Gossip 1.75 Proposal**  
**Author:** t-bast | **Source:** Delving Bitcoin | **Replies:** 2  
- Highlights unsigned TLV format in SPV proof as an innovative approach.  
- Suggests adding outpoints in signed fields for better support of `txindex` nodes.  
- Collaboration opportunities open with the eclair team.  

**Other contributors:** ellemouton, harding

---

#### **Channel Depletion and LN Topology**  
**Author:** sorukumar | **Source:** Delving Bitcoin | **Replies:** 5  
- Critiques current models as oversimplified for dynamic network operations.  
- Highlights the importance of fee management and liquidity modeling.  
- Calls for further investigation into network liquidity and topology.  

**Other contributors:** ajtowns, renepickhardt +1 other

---

#### **Multi-Byte Opcodes**  
**Author:** Garlo Nicon | **Source:** Bitcoin-dev | **Replies:** 5  
- Discusses new OPs, including `OP_CHECKSIGADD`.  
- Reflects on Bitcoin’s adaptability with OP code evolution introduced by Satoshi.  
- Showcases Bitcoin’s ability to evolve without disrupting existing functionalities.  

**Other contributors:** Brandon Black, Ethan Heilman +2 others

---

💡 **Subscribe now for more updates like these:**  
[🔗 Click here to subscribe!](https://bitcoindevs.xyz/decoding/newsletter)

![](https://m.stacker.news/64724)


Bitcoin TLDR Newsletter (Nov 18 - Nov 25)

## Decoding #2: Locking & Unlocking Scripts 🔒🔓

- *We're starting a series of posts to teach you about Bitcoin development. We'll be sharing them here. Tell us how we can make it better!*
- *If you prefer reading on the website, check 👉 https://bitcoindevs.xyz/decoding/locking-unlocking*

Locking and Unlocking Scripts define how transactions can be spent.


### **1- Locking Script**  
A script that specifies spending conditions for a transaction output.

![](https://m.stacker.news/64531)

Example:  
`OP_2 OP_ADD OP_4 OP_EQUAL`

Condition: Add 2, check if it equals 4.

### **2- Unlocking Script**  
A script that provides the data to satisfy the conditions in the locking script.

![](https://m.stacker.news/64532)

Example:  
`OP_2`  

Value: 2 satisfies the locking script condition above.

### **3- Execution**  
- Unlocking script runs first, followed by locking script.  
- If the stack contains `TRUE (1)`, the transaction is valid.

![](https://m.stacker.news/64535)

---
To see how this works in an interactive way, visit https://bitcoindevs.xyz/decoding/locking-unlocking

![](https://m.stacker.news/64533)

Decoding #2: Locking & Unlocking Scripts 🔒🔓

#1: What's difference between Standard & Non-Standard Scripts

what specific part should I expand on? Relaying non-standard txs or smth else

This is our first post

If ppl find this series of posts valuable, we’ll continue sharing more content here

  
 
 

## Decoding #1: Standard VS non-Standard Scripts

- *We're starting a series of posts to teach you about Bitcoin development. We'll be sharing them here. Tell us how we can make it better!*
- *If you prefer reading on the website, check 👉 https://bitcoindevs.xyz/decoding/standard-nonstandard*


## 1- Standard Script

Standard scripts are predefined and widely accepted transaction scripts in Bitcoin.

- **Key Features**:
  - Predefined templates (e.g., P2PKH, P2SH).
  - Well-tested and quickly verified by nodes.
  - Widely relayed and accepted on the network.  


Below is a timeline of different output script types before and after SegWit.  

![](https://m.stacker.news/63717)

### NOTE: Relay Policy

Bitcoin Core will only relay transactions by default that pass the [`IsStandardTx()`](https://github.com/bitcoin/bitcoin/blob/de1d1895346ed27f471386011d7ff64508f8b39c/src/policy/policy.cpp#L94) check. However, miners are still free to include (valid!) non-standard transactions in their blocks.

---

## 2- Non-Standard Scripts

- Non-standard scripts deviate from commonly used templates for transaction.

- Standard scripts, such as P2PKH and P2SH, are widely recognized and accepted by nodes. Any script that deviates from these templates is considered non-standard and will not be relayed by the network.

- They are valid but are not relayed by most nodes for safety reasons.

*Remember this pls => Non-standard scripts are still *VALID**

![](https://m.stacker.news/63719)

### Question: What if I want my Non-Standard Transaction Relayed and Mined?

 find the answer here 👉 https://bitcoindevs.xyz/decoding/standard-nonstandard


@78631371f1's bio


# MuSig: Three-Round Multiparty Schnorr Signature

![](https://m.stacker.news/63630)

By the end of this article, you will learn how Alice, Bob, and Carol can collaboratively sign a transaction using MuSig.

We’ll guide you through the process step by step, combining theory with practical code examples. Your ultimate goal will be to write 

By the end, you’ll be able to write the code for generating this signature

## 1. Theory

To make this article simple to follow, we will answer three important questions that will help you understand the concept: **What? Why? How?**

### What is MuSig?

MuSig is simply a protocol for aggregating public keys and signatures.

![](https://m.stacker.news/63624)


### Why do we need MuSig?

The reasons we use MuSig are:

-   **Transaction Size/Fees:** MuSig makes multi-sig look like single-sig. This means you pay the same fees whether one person or ten people sign.

-   **Privacy:** Nobody can tell if a transaction used multiple signers or just one. Your multi-sig setup stays private, as it looks identical to a regular transaction.

![](https://m.stacker.news/63626)

### How does MuSig work?

Now we need your focus here, please. Grab a coffee, and let's dive in.

Alice, Bob, and Carol want to create an aggregated signature such as:

**s_agg = s_a + s_b + s_c**

To create this signature, we need to go through three main steps:

1. Aggregating public keys.
2. Aggregating nonces.
3. Aggregating the signature.

Some of these steps require rounds of communication between participants:

-   Aggregating public keys does **not** require communication.
-   Aggregating nonces and signatures requires **three rounds of communication** (MuSig2 optimizes this to **two rounds**).

![](https://m.stacker.news/63627)



---

## Step 1: Public Key Aggregation (Offline Process)

A naive way to do public key aggregation is by summing up each participant's public key:

**P_agg = P_a + P_b + P_c**

However, this approach is vulnerable to a **key cancellation attack.**

Continue reading on https://bitcoindevs.xyz/decoding/musig

🔑 MuSig | Write Your First Signature Step-by-Step

Bitcoin Dev Project is the go-to resource for developers to get inspired by and learn bitcoin and related technologies to kickstart and grow their career in Free and Open Source Software.

bitcoin + FOSS = ₿OSS
https://bitcoindevs.xyz