Trust Model
Understanding the security assumptions and trust relationships in BSV TypeScript SDK applications.
Core Trust Principles
The SDK is designed around minimizing trust requirements:
Trustless Verification
- Cryptographic Proofs: Verify transactions mathematically
- SPV Security: Validate without trusting third parties
- Self-Sovereign: Users control their own keys and data
Minimized Dependencies
- Zero External Dependencies: Reduces attack surface
- Self-Contained: All cryptographic operations built-in
- Auditable: Open source and transparent implementation
Trust Relationships
User Trust
Users must trust:
- The SDK Code: Open source and auditable
- Their Wallet: Manages private keys securely
- Their Device: Secure execution environment
Network Trust
Applications rely on:
- Bitcoin Network: Honest majority of miners
- Chain Trackers: Provide accurate blockchain data
- SPV Assumptions: Valid merkle proofs and headers
Service Trust
Optional trust relationships:
- Wallet Providers: If using hosted wallets
- ARC Services: For transaction broadcasting
- Overlay Services: For additional functionality
Security Assumptions
Cryptographic Security
- secp256k1: Elliptic curve is secure
- SHA-256: Hash function is collision-resistant
- ECDSA: Digital signature scheme is unforgeable
- Random Number Generation: Entropy source is secure
Network Security
- Proof of Work: Mining provides security
- Longest Chain: Honest chain has most work
- Block Finality: Deep confirmations prevent reorganization
- Network Connectivity: Access to honest nodes
Risk Mitigation
Key Management
// Minimize private key exposure
const wallet = new WalletClient() // Keys stay in wallet
// Avoid direct key handling
// const privateKey = PrivateKey.fromString() // Higher risk
Transaction Verification
// Always verify important transactions
const isValid = await transaction.verify(chainTracker, {
merkleProof: proof,
blockHeader: header
})
Multiple Sources
// Use multiple chain trackers
const config = {
chainTracker: {
primary: 'WhatsOnChain',
fallbacks: ['GorillaPool', 'TAAL']
}
}
Threat Model
Attacks to Consider
- Private Key Compromise: Secure key storage
- Man-in-the-Middle: Use HTTPS and verify certificates
- Service Downtime: Implement fallback mechanisms
- Double Spending: Wait for confirmations
- Replay Attacks: Use unique transaction IDs
Application Design
Security-First Design
// Validate all inputs
function processTransaction(txHex: string) {
if (!isValidHex(txHex)) {
throw new Error('Invalid transaction hex')
}
const tx = Transaction.fromHex(txHex)
// Process verified transaction
}
Error Handling
// Handle trust failures gracefully
try {
const result = await chainTracker.getTransaction(txid)
} catch (error) {
// Fallback to alternative source
const backup = await fallbackTracker.getTransaction(txid)
}
Next Steps