Dashboards / Analysis
TxStats - Latest stats on Bitcoin transaction types
Johoe’s Bitcoin Mempool Statistics
Bitcoin Optech Dashboards
Bitcoin Monitoring - P2P
UTXO Stats
Mempool Observer
Network Monitoring
History
Bitcoin’s Academic Pedigree
b10c’s Incomplete History of Bitcoin Development
History of segwit activation
History of P2SH
How to Activate a New Soft Fork
Bitcoin Core
Bitcoin Core daily coverage reports
fanquake’s Core Review
Debugging Bitcoin Core
Userspace, Statically Defined Tracing support for Bitcoin Core
core review tools
overview of arch
Security
Everything is Broken
Bitcoin is Improving
Identifying Key Leakage in Bitcoin
ECDSA Private Key Recovery
Nonce Reuse
Stealing Bitcoin With Math
List of Hardware Wallet Hacks
Remote MultiSig Theft Attack on Coldcard
Key Exfiltration
Wallets
wallet dev presentation by John Newbery
HD Wallets
There are 2^31 child keys and 2^31 hardened child keys. The distinction is very important.
- private parent key → private child key = computes a child extended private key from the parent extended private key
- public parent key → public child key = computes a child extended public key from the parent extended public key. It is only defined for non-hardened child keys.
- private parent key → public child key = computes the extended public key corresponding to an extended private key (the “neutered” version, as it removes the ability to sign transactions).
- public parent key → private child key = not possible
Deep Dive on Extended Keys
A Formal Treatment of Deterministic Wallets
BIP39 Tool (for testing)
Alternative BIP32 Tool (for testing)
BIP-43
BIP-44
BIP-45
SegWit wallet dev guide
Covenants & Vaults
A covenant is a bitcoin script that restricts the type of transaction that can spend a coin.
Greg Maxwell’s Bitcoin Talk thread on covenants
OP_CAT and Schnorr - Part 1
OP_CAT and Schnorr - Part 2
Vaults without Covenantsmore by bishop
Proof of Reserves by bBlockstream
Making Bitcoin Exchanges Transparent
BIP-127 proposes a standard way to do proof of reserves using a PSBT extension.link to bip
There’s rust implementation of a Proof-of-Reserves Client. link to reserves
custody protocols using bitcoin vaults
Coin Selection
Challenges of coin selection by Lopp
Coin Selection with Leverage
IOHK on Coin Selection
What is Coin Selection?
Murch transcript at Scaling
Edge++ Coin Selection transcript
The naive approach would be to simply look for the smallest output that is larger than the amount you want to spend and use it, otherwise start adding the next largest outputs until you have enough outputs to meet the spend target. However, this leads to fracturing of outputs until the wallet becomes littered with unspendable “dust.”
”Dust” refers to transaction outputs that are less valuable than three times the mininum transaction fee and are therefore expensive to spend.
utxo mgmt for enterprise wallets
General
Some changes to the Bitcoin Core wallet: Wallet Class Structure Changes
Sipa describing wallet changes
Wallet Architecture transcripts
What’s Coming to Bitcoin Core Wallet in 2021
Descriptor Wallets MD
Bitcoin Issue 17190 Electrum on Descriptors Descriptors Overview coredev talk
Implementations… HWI Bitcoin #16528 Bitcoin Core parsing Bitcoin #15764
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final.
Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:
- SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it’s only the scripts that are not. Intuitively, it means “I agree to put my money in, if everyone puts their money in and the outputs are this”.
- SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate “I agree to put my money in, as long as everyone puts their money in, but I don’t care what’s done with the output”. This mode allows others to update the transaction by changing their inputs sequence numbers.
- SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate “I agree, as long as my output is what I want; I don’t care about the others”.
There are two general patterns for safely creating contracts:
- Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.
- Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.
This is to ensure that people always know what they are agreeing to. Together, these features let us build interesting new financial tools on top of the block chain.
It may even be that people find themselves working for the programs because they need the money, rather than programs working for the people.
old oracle services…https://docs.oraclize.it/#homehttp://orisi.org/http://earlytemple.com/https://en.bitcoin.it/wiki/Contract#Example_4:_Using_external_state
SuredBits’ blog on scriptless scripts
Fees
John Newbery’s intro to Bitcoin Core Fee Estimation pt2
High level desc of Bitcoin Core’s fee estimation algorithmcode
https://github.com/kallewoof/mff
Privacy
Misc
Dark Leaks
IBLTs, Invertible Bloom Lookup Table, offer set reconciliation between mempool transactions and blocks.
Taproot
Slides from Sipa’s talk at SF Bitcoin Devs
Taproot Workshop
Taproot Review
immediate benefit of taproot: “if you lose this key, your funds are gone” to “if you lose this key, you’ll have to recover 3 of your 5 backup keys that you sent to trusted friends, and pay a little more, but you won’t have lost your funds”” - anthony towns
Why only x-pubkey?
The issues with Bitcoin’s x-only key approach.
Schnorr
SuredBits’ intro to Schnorr
security of blind discrete log signatures
generalized bday problem
x-only pubkeys
[lattice attacks against weak ECDSA](https://eprint.iacr.org/2019/023.pdf
BitcionOps explains MuSig2
MuSig2
Half-aggregation of BIP340signatures allows for non-interactive signing.
Why does signature half aggregation break adaptor signatures?
An adaptor signature is a normal Schnorr signature with an added secret tweak. This tweak is the secret we want to hide and only reveal upon revealing the signature.
Adaptor signatures (also called signature adaptors) are auxiliary signature data that commit to a hidden value. When an adaptor is combined with a corresponding signature, it reveals the hidden value. Alternatively, when combined with the hidden value, the adaptor reveals the signature. Other people may create secondary adaptors that reuse the commitment even if they don’t know the hidden value. This makes adaptors a powerful tool for implementing locking in bitcoin contracts.