Learning Objectives:
-
Master digital signature applications in blockchain
-
Understand multi-signature schemes
-
Analyze threshold signatures and their uses
2.3.1: Digital Signatures in Blockchain
Core Functions:
Digital Signature Functions: 1. Transaction Authorization: - Proves ownership of funds - Prevents unauthorized spending - Enables non-repudiation 2. Block Validation: - Verifies miner identity - Ensures block integrity - Prevents tampering 3. Smart Contract Signatures: - Authorizes contract execution - Multi-sig requirements - Meta-transactions 4. Identity Verification: - Proves identity on-chain - Verifiable credentials - DID (Decentralized Identity)
2.3.2: Transaction Signing
Bitcoin Transaction Signing:
Bitcoin Signature Process: 1. Transaction Creation: - Inputs (UTXOs to spend) - Outputs (destinations) - Fees 2. Signature Hash: - Hash of transaction data - SIGHASH flags (type) - SegWit modifications 3. ECDSA Signing: - Sign hash with private key - Generate signature (r, s) 4. Script: - <sig> <pubkey> - OP_CHECKSIG 5. Verification: - Signature verification - Script execution - Transaction validation
SIGHASH Flags:
SIGHASH Types: 1. SIGHASH_ALL (0x01): - Signs all inputs and outputs - Most common - Full transaction commitment 2. SIGHASH_NONE (0x02): - Signs all inputs - Signs no outputs - Allows output modification 3. SIGHASH_SINGLE (0x03): - Signs one input and output - Pair-specific signing - Used in some protocols 4. SIGHASH_ANYONECANPAY (0x80): - Can be combined with above - Signs only one input - Allows additional inputs
2.3.3: Multi-Signature Schemes
M-of-N Multi-Sig:
Multi-Signature Definition: - M signatures required out of N possible - M ≤ N (threshold) - Example: 2-of-3, 3-of-5 Multi-Sig Address: - Pay-to-Script-Hash (P2SH) - Redeem script contains M and N - Address derived from script hash Multi-Sig Benefits: - Shared control - Security (multiple keys) - Recovery (key loss) - Governance (voting) Multi-Sig Script (2-of-3): OP_2 <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG Validation: 1. Verify M signatures 2. Check against N public keys 3. All signatures must be valid
2.3.4: Threshold Signatures
Definition:
A threshold signature scheme allows any subset of t participants from a group of n to sign a message.
Properties:
Threshold Signature Properties: 1. t-of-n: Any t signers can sign 2. Less than t cannot sign 3. Distributed key generation 4. No single point of failure Applications: 1. Cold wallet protection 2. Corporate governance 3. Exchange security 4. DAO voting Schemes: 1. Shamir Secret Sharing (SSS) 2. Feldman Verifiable Secret Sharing (VSS) 3. Distributed Key Generation (DKG) 4. Threshold ECDSA (GG18, GG20)
Shamir Secret Sharing:
Shamir Secret Sharing:
Polynomial:
f(x) = a₀ + a₁x + a₂x² + ... + a_{t-1}x^{t-1}
Where:
- a₀ = Secret (to be shared)
- a₁, a₂, ... = Random coefficients
Shares:
sᵢ = f(i) for i = 1, 2, ..., n
Reconstruction (t shares):
Lagrange Interpolation:
f(0) = Σ sᵢ × Lᵢ(0)
Where:
Lᵢ(0) = ∏_{j≠i} (0 - j) / (i - j)
Security:
- t-1 shares reveal nothing
- t shares reconstruct secret
2.3.5: Schnorr Multi-Signatures
Schnorr Key Aggregation:
Key Aggregation: 1. Individual public keys: pk₁, pk₂, ..., pkₙ 2. Aggregated key: pk_agg = Σ pkᵢ Signing (3-of-3): 1. Each signer chooses random nonce: rᵢ 2. Aggregate nonce: R = Σ rᵢ × G 3. Compute challenge: c = H(R || message) 4. Each signer computes: sᵢ = rᵢ + c × skᵢ 5. Aggregate signature: s = Σ sᵢ Verification: 1. Compute R' = s × G - c × pk_agg 2. Verify R' = R Advantages: 1. Single signature (n signatures → 1) 2. Smaller transactions 3. More privacy 4. Faster verification
MuSig (Musig2):
MuSig Features: 1. Multi-signature aggregation 2. Non-interactive 3. Security proof MuSig vs Standard Schnorr: - Standard: Requires interaction - MuSig: One round - MuSig2: Two rounds (non-interactive) MuSig Security: - Resists rogue key attack - Proof of possession - Random nonce generation
2.3.6: Blind Signatures and Privacy
Blind Signatures:
Blind Signature Process: 1. User generates message m 2. User blinds m: m' = blind(m, r) 3. User sends m' to signer 4. Signer signs m': s' = sign(m') 5. User unblinds s': s = unblind(s', r) 6. Result: Signature s for original m Properties: - Signer doesn't know what they signed - User gets valid signature - Privacy-preserving Applications: 1. Digital cash 2. Anonymous voting 3. Privacy coins (e.g., Zcash) 4. Blind auction Implementation: 1. RSA blind signatures (RSA) 2. Schnorr blind signatures 3. BLS blind signatures
2.3.7: Aggregate Signatures
Aggregate Signatures:
Aggregate Signatures: 1. n signatures → 1 signature 2. n public keys → 1 public key 3. Verification: O(1) Properties: 1. Compression: n signatures to 1 2. Verification: Single verification 3. Same security as individual BLS Aggregation: 1. Each signer: σᵢ = H(m) × skᵢ 2. Aggregate: σ = Σ σᵢ 3. Verification: e(σ, G) = e(H(m), pk_agg) Applications: 1. Blockchain scalability 2. Certificate transparency 3. Voting systems 4. Optimistic rollups
ADDITIONAL DEEP TECHNICAL NOTES:
1. Script Execution in Bitcoin
Bitcoin Script Stack:
Script Execution Example (P2PKH): Script: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG Stack Operations: 1. OP_DUP: Duplicate top item 2. OP_HASH160: Hash top item 3. <pubkey_hash>: Push hash 4. OP_EQUALVERIFY: Check equality 5. OP_CHECKSIG: Verify signature Result: 1 (success) or 0 (failure)
Common Script Patterns:
| Pattern | Script | Example |
|---|---|---|
| P2PKH | OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG | Standard payments |
| P2SH | OP_HASH160 <script_hash> OP_EQUAL | Multi-sig, SegWit |
| P2PK | <pubkey> OP_CHECKSIG | Legacy (rare) |
| OP_RETURN | OP_RETURN <data> | Data storage |
| Time Lock | <time> OP_CHECKLOCKTIMEVERIFY | Locked payments |
2. Multi-Sig Security
Security Considerations:
Multi-Sig Threats: 1. Key theft: Multiple keys needed 2. Stolen key: Need M keys for spending 3. Key loss: N - M keys can be lost 4. Collusion: M signers can collude Best Practices: 1. Geographic distribution of keys 2. Different custody methods 3. Regular key rotation 4. Hardware security modules Key Management: - M-of-N for recovery - 2-of-3 for business - 3-of-5 for corporate - 5-of-7 for institutions
3. Schnorr Signature Implementations
Schnorr vs ECDSA Comparison:
| Feature | ECDSA | Schnorr |
|---|---|---|
| Signing Speed | Fast | Fast |
| Verification | Fast | Faster |
| Signature Size | 72 bytes | 64 bytes |
| Aggregation | No | Yes |
| Batch Verification | No | Yes |
| Security Proof | Heuristic | Provable |
| Patent Status | Free | Free |
Taproot (Bitcoin):
Taproot Upgrades: 1. Schnorr signatures 2. MAST (Merklized Abstract Syntax Tree) 3. Key aggregation 4. Privacy improvements MAST Benefits: 1. Only reveal executed condition 2. Smaller transactions 3. More privacy 4. More complex conditions
4. Threshold ECDSA Protocols
GG18 Protocol:
GG18 Threshold ECDSA: 1. Distributed Key Generation 2. Share private key 3. t-of-n signature Key Generation: 1. Each party generates shares 2. Verify shares (Feldman) 3. Compute public key Signing: 1. Generate random nonces 2. Compute R = r × G 3. Compute signature shares 4. Combine shares → signature Security: - Holds with up to n-t parties - Cryptographic proof - Malicious participants tolerated