bitcoin

Activity

Stars and mentions · Last 30 days, Oct 6 – Nov 4

GitHub stars330
Mentions93
08162432Oct 6Oct 20Nov 4
UTC days · repositories bitcoin owns3 repositories

Top repositories

bitcoin’s repositories ranked by new stars, as on trending.

Loading

Contributes to

Repositories outside bitcoin’s account where bitcoin opened or reviewed pull requests in the past 365 days.

Who noticed bitcoin

Everyone who starred or forked bitcoin’s repositories since the archive began in 2011.

Notable accounts

Ordered by the stars their own repositories have received.

Biggest fans

Accounts that starred the most of these repositories.

Breakout weeks

Each repository’s best week of new stars, with the release published around it.

Mentions

86posts
Nov 51 post
  1. BIP54 updates from the last several months of Consensus Cleanup work Implementation progress: Bitcoin Core: bitcoin#35793 (open) implements BIP54's rules without mainnet activation. Needs reviewers. libbitcoin: libbitcoin-system#2149 (merged) rbitcoin: rbitcoin#1173 (draft, signet) btcd: btcd#2537 (draft) Research: Pieter Wuille published a proof, machine-checked in Lean, that BIP54's two timestamp rules together bound chain length for a given amount of work. delvingbitcoin.org 64-byte txs: Jeremy Rubin argued they may have legitimate uses (groups.google.com) and wrote up an alternative that invalidates merkle internal nodes instead (groups.google.com). BIP54's rationale now acknowledges that option but still prefers the simple ban. BIP54 tracker for forward-compatibility for miner coinbase locktimes: mainnet.observer Other discussions: Antoine Riard's response to Mark Friedenbach's objection that fixing timewarp forecloses forward blocks groups.google.com An idea to split BIP54 into one BIP per fix, which the authors declined bips#2175 Testnet5 (BIP95): enforces BIP54 from block 1 groups.google.com bip54.org is updated to reflect these.

    21 likes · 7 reposts · 1,096 views
  2. Reddit · · r/SoloSatoshi · u/XGod0fWarX · bitcoin/bips

    Why seed phrases are 12 or 24 words: the BIP39 math in plain English Most wallets hand you 12 or 24 words, and the reason is a standard called BIP39. - The English word list has exactly 2,048 words. 2,048 is 2^11, so each word stands for 11 bits. - A 12-word phrase is 128 bits of randomness plus a 4-bit checksum. That's 132 bits, or 12 x 11. - A 24-word phrase is 256 bits of randomness plus an 8-bit checksum. That's 264 bits, or 24 x 11. - Because of that checksum, a random list of valid words usually won't add up to a valid phrase. Part of the last word has to match. - The list was built so the first four letters are enough to tell every word apart. The spec itself is short and worth a read: github.com/bitcoin/bips/blob/master/bip-0039.medi…

    1 point
  3. How many guesses is a seed phrase? BIP39 entropy and PBKDF2 cost, measured in Node.js In July 2026, attackers rebuilt Bitcoin wallets created on Coldcard hardware wallets without touching the devices. A firmware configuration mistake dating back to 2021 meant the devices skipped their hardware random number generator when creating seeds, and Coinkite, the maker, estimates the affected seeds carried about 40 bits of entropy on the Mk2 and Mk3 and about 72 bits on the Mk4, Mk5 and Q. A BIP39 seed is designed for 128. Galaxy Research counted 1,778 BTC stolen by August 14. On November 1, Trezor raised its maximum wallet passphrase length from 50 to 128 characters and cited those attacks. This post works through the numbers behind both events with one Node script that has no dependencies: what a seed is made of, what one guess costs, how big 40, 72 and 128 bits are at that cost, and what a passphrase adds. Everything here ran on Node 24 on a laptop. What a BIP39 seed is made of A 12-word mnemonic encodes 128 bits of entropy plus a 4-bit checksum, split into twelve 11-bit indexes into a 2,048-word list. A 24-word mnemonic encodes 256 bits. The words are only an encoding. Their strength is exactly the strength of the random number behind them, which is why a broken generator produces normal-looking words. The wallet never uses the words directly. BIP39 turns them into a 64-byte seed with PBKDF2: import { pbkdf2Sync } from 'node:crypto'; // salt = "mnemonic" + passphrase, 2048 rounds of HMAC-SHA512, 64 bytes out const seedFrom = (mnemonic, passphrase = '') => pbkdf2Sync(mnemonic.normalize('NFKD'), ('mnemonic' + passphrase).normalize('NFKD'), 2048, 64, 'sha512'); Two details matter for the rest of the post. The 2,048 rounds make every guess deliberately slow. And the passphrase is part of the salt, so a different passphrase gives a completely different seed, and every passphrase an attacker tries costs a full derivation of its own. Check it against the test vector first Timing a function that computes the wrong thing tells you nothing, so the script starts with the first official test vector, the all-zero entropy mnemonic with the passphrase TREZOR: const VECTOR = { mnemonic: 'abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about', passphrase: 'TREZOR', seed: 'c55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04', }; const ok = seedFrom(VECTOR.mnemonic, VECTOR.passphrase).toString('hex') === VECTOR.seed; console.log(`BIP39 test vector: ${ok ? 'match' : 'MISMATCH'}`); if (!ok) process.exit(1); BIP39 test vector: match Timing one guess Any attack on a weak seed has to run this derivation once per candidate. The script warms up, then takes the median of three runs of 300 derivations on a single thread: const rate = (n) => { const start = process.hrtime.bigint(); for (let i = 0; i < n; i++) seedFrom(VECTOR.mnemonic, String(i)); return n / (Number(process.hrtime.bigint() - start) / 1e9); }; rate(100); const perSecond = [rate(300), rate(300), rate(300)].sort((a, b) => a - b)[1]; PBKDF2 seeds per second, one core of Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz: 375 About 2.7 ms per guess. Your machine will give a different number, and a GPU will give a much bigger one. A real attack also has to derive keys from each seed and check the resulting addresses against the chain, which adds work per guess. So read the next table for its orders of magnitude, not its exact values. What 40, 72 and 128 bits mean at that rate Full search at the measured rate (one core, then 10,000 cores like it): 40.0 bits Coldcard Mk2/Mk3 seed, Coinkite estimate 92.9 years 3.39 days 72.0 bits Coldcard Mk4/Mk5/Q seed, Coinkite estimate 3.99e+11 years 3.99e+7 years 128.0 bits 12-word BIP39 seed, as designed 2.88e+28 years 2.88e+24 years 65.8 bits 40-bit seed + two random words from a 7,776-word list 5.62e+9 years 5.62e+5 years 117.5 bits 40-bit seed + six random words from a 7,776-word list 2.05e+25 years 2.05e+21 years 129.2 bits 50 private die rolls on their own 6.83e+28 years 6.83e+24 years The 40-bit row is the one that matters. About a trillion candidates is a long job for one laptop core and a short one for a rented cluster, and the July thefts show someone ran it. On average an attacker finds a given seed halfway through the space, and an attacker scanning for any weak wallet with funds collects every hit along the way. The 72-bit row looks safe in this table, and Coinkite still tells owners of affected Mk4, Mk5 and Q seeds to migrate. Casa's write-up mentions an independent analysis that puts the worst case for a targeted attacker much lower. An entropy estimate for a broken generator depends on what the attacker knows about the device's state, and "about 72 bits" is a best case. What a passphrase adds Because the passphrase is in the salt, a passphrase with p bits of entropy multiplies the search by 2^p. The script's rows for a 40-bit seed show the effect. Two words drawn at random from the EFF large wordlist (7,776 words, about 12.9 bits each) take the search to about 66 bits. Six random words take it to about 118. The key word is random. Coinkite's security page says a passphrase "does not repair a seed generated on affected firmware", while it "can add a barrier", and Casa mentions a reported loss from a Mk3 with a two-word passphrase. Two words a person picks have far less entropy than two words from dice, because attackers try common words and phrases first. The table's numbers assume words drawn uniformly at random. The passphrase length limit decides how much of that randomness fits: const PRINTABLE = 94; // ASCII 33-126 const AVG_WORD = 6.99 + 1; // EFF large wordlist: 6.99 letters on average, plus a space for (const limit of [50, 128]) { const words = Math.floor((limit + 1) / AVG_WORD); console.log(`${limit}-character limit: ${(limit * Math.log2(PRINTABLE)).toFixed(0)} bits of random printable characters, or about ${words} random words (${(words * Math.log2(7776)).toFixed(0)} bits)`); } 50-character limit: 328 bits of random printable characters, or about 6 random words (78 bits) 128-character limit: 839 bits of random printable characters, or about 16 random words (207 bits) Fifty characters were always enough for random characters. They were tight for word-based passphrases, which are the kind people can actually remember and type on a small screen. That is the case Trezor's new 128-character limit helps. Dice rolls Coinkite's exception for affected seeds is a seed created with at least 50 fair, private dice rolls that were never recorded. A six-sided die gives log2(6), about 2.585 bits per roll, so 50 rolls give about 129.2 bits, the last row of the table, and 99 rolls give about 256. User-supplied entropy works because it doesn't depend on the device's generator being right. Coinkite's newer firmware now requires it for every new seed: at least 65 key presses, 50 die rolls or 128 coin flips, mixed with the device's own sources. Limits of this estimate - One CPU core is a floor for attacker speed, not a forecast. GPUs and many machines change the per-second numbers by orders of magnitude, in the attacker's favor. - Key derivation and address lookups add per-guess cost that this script leaves out. - The bit counts for the Coldcard seeds are Coinkite's estimates, not measurements. - A passphrase's entropy is a property of how it was chosen. No script can measure that from the passphrase itself. The full script // How expensive is one guess at a BIP39 wallet, and how many guesses do weak and strong setups allow? // Node 18+, no dependencies: node seed-math.mjs import { pbkdf2Sync } from 'node:crypto'; import { cpus } from 'node:os'; // BIP39: the seed is PBKDF2-HMAC-SHA512 over the mnemonic, salted with "mnemonic" + passphrase, 2048 rounds. const seedFrom = (mnemonic, passphrase = '') => pbkdf2Sync(mnemonic.normalize('NFKD'), ('mnemonic' + passphrase).normalize('NFKD'), 2048, 64, 'sha512'); // 1. Check the function against the first official BIP39 test vector before trusting any timing. const VECTOR = { mnemonic: 'abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about', passphrase: 'TREZOR', seed: 'c55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04', }; const ok = seedFrom(VECTOR.mnemonic, VECTOR.passphrase).toString('hex') === VECTOR.seed; console.log(`BIP39 test vector: ${ok ? 'match' : 'MISMATCH'}`); if (!ok) process.exit(1); // 2. Time one guess on this machine, single thread: warm up, then take the median of three runs. // A real attack also derives keys and checks addresses, which adds work per guess, and usually runs // on GPUs, which does far more guesses per second. Read the results as orders of magnitude. const rate = (n) => { const start = process.hrtime.bigint(); for (let i = 0; i < n; i++) seedFrom(VECTOR.mnemonic, String(i)); return n / (Number(process.hrtime.bigint() - start) / 1e9); }; rate(100); const perSecond = [rate(300), rate(300), rate(300)].sort((a, b) => a - b)[1]; console.log(`PBKDF2 seeds per second, one core of ${cpus()[0].model.trim()}: ${perSecond.toFixed(0)}`); // 3. Search spaces in bits, and how long a full search takes. const human = (s) => { const units = [['years', 31557600], ['days', 86400], ['hours', 3600], ['minutes', 60], ['seconds', 1]]; for (const [name, size] of units) if (s >= size) return `${(s / size).toPrecision(3)} ${name}`; return `${s.toPrecision(3)} seconds`; }; const bits = (n) => Math.log2(n); const SPACES = [ ['Coldcard Mk2/Mk3 seed, Coinkite estimate', 40], ['Coldcard Mk4/Mk5/Q seed, Coinkite estimate', 72], ['12-word BIP39 seed, as designed', 128], ['40-bit seed + two random words from a 7,776-word list', 40 + 2 * bits(7776)], ['40-bit seed + six random words from a 7,776-word list', 40 + 6 * bits(7776)], ['50 private die rolls on their own', 50 * bits(6)], ]; const CORES = 10000; console.log(`\nFull search at the measured rate (one core, then ${CORES.toLocaleString('en-US')} cores like it):`); for (const [name, b] of SPACES) { const total = 2 ** b / perSecond; console.log(` ${b.toFixed(1).padStart(6)} bits ${name.padEnd(56)} ${human(total).padStart(16)} ${human(total / CORES).padStart(16)}`); } // 4. What fits under a passphrase length limit: random characters versus words. const PRINTABLE = 94; // ASCII 33-126 const AVG_WORD = 6.99 + 1; // EFF large wordlist (7,776 words): 6.99 letters on average, plus a space for (const limit of [50, 128]) { const words = Math.floor((limit + 1) / AVG_WORD); console.log(`\n${limit}-character limit: ${(limit * bits(PRINTABLE)).toFixed(0)} bits of random printable characters, or about ${words} random words (${(words * bits(7776)).toFixed(0)} bits)`); } References - BIP39 specification - Coinkite: COLDCARD security status - Cointelegraph: Coldcard strengthens seed generation with firmware update - Privacy Guides: Nearly 1,400 Bitcoin hacked from Coldcard wallets - Casa: The Coldcard vulnerability, explained - Cointelegraph: Trezor raises wallet passphrase limit to 128 characters - EFF dice-generated passphrases and wordlists

  4. My first contribution to Bitcoin Core was a small documentation fix. After a few rejected attempts, I finally got my PR merged. Small change, but a meaningful milestone for me. PR #35047: bitcoin#35047

    1 like
  5. Cold Storage Best Practices: Setting Up a Long-Term Crypto Vault AI disclosure: drafted by Basis Desk's AI newsroom and machine-checked against the primary sources listed below — how we use AI. Originally published on Basis Desk. > A guide to securing digital assets offline, detailing hardware wallet setup, on-device verification, geographically separated backups, and routine maintenance. Key points - Hardware wallets isolate private keys in a secure element, preventing internet exposure. - True air-gapped wallets use QR codes or microSD cards to transfer data without physical or wireless connections. - Seed phrases act as the ultimate backup and should be stored offline on durable materials like metal. - Verifying the receive address on the device screen prevents malware-induced misdirection. - Test transactions and test recoveries confirm control before securing significant capital. Cold storage involves holding the cryptographic keys to digital assets offline, isolating them from internet-connected threats. A properly configured long-term vault relies on dedicated hardware, strict verification procedures, and resilient physical backups. Setting up this infrastructure requires deliberate steps to ensure funds remain accessible to the owner while strictly inaccessible to unauthorized actors. The architecture of cold storage Digital assets do not exist inside a physical device. Instead, a wallet manages a private key, a cryptographic string that grants control over assets recorded on a public blockchain. If a private key touches an internet-connected computer or smartphone, it is considered a "hot" wallet, which carries risks of malware, keyloggers, and remote extraction. Cold storage mitigates these risks by generating and storing the private key completely offline. The most common method for achieving this is a hardware wallet. Hardware wallets isolate the private key within a specialized microchip called a secure element. Many models connect to internet-enabled devices via USB or Bluetooth to transmit signed transactions. While this connection relies on the secure element to prevent the key from leaving the device, it is not strictly air-gapped. True air-gapped operation requires eliminating all physical and wireless data connections, relying instead on optical interfaces like QR codes or physical media like microSD cards to pass unsigned and signed transaction data back and forth. For more context on wallet architectures, see Crypto Wallets Explained: Custodial, Hot, Cold, and Hardware. Seed phrase generation and physical backups When a hardware wallet is initialized, it uses a random number generator to create a master private key. This key is represented as a seed phrase, typically a sequence of 12 or 24 standardized words defined by the BIP-39 protocol. This phrase acts as the ultimate backup; if the hardware device is lost, destroyed, or reset, the seed phrase can restore access to the assets on a new device. Securing the seed phrase is the most critical element of a long-term vault. Writing the phrase on paper introduces risks of fire, water damage, and degradation over time. Stamping or engraving the words into high-grade stainless steel or titanium plates provides resilience against extreme temperatures and environmental damage. The backup must never be photographed, typed into a digital document, or stored in a cloud service. Geographic separation of backups protects against localized disasters. However, simply cutting a seed phrase in half and storing the pieces in different locations creates severe risks. If one piece is lost, the entire wallet becomes unrecoverable, and if an attacker finds one half, the mathematical difficulty of brute-forcing the remaining words is drastically reduced. Instead, geographic redundancy should be achieved either by storing full steel backups in multiple highly secure locations (such as separate bank safety deposit boxes) or by utilizing multisignature (multisig) architectures and Shamir's Secret Sharing schemes, which mathematically distribute the key across multiple shards. Verification and test transactions A secure vault setup is incomplete without rigorous verification. Before transferring significant capital to a new cold storage address, the user must ensure the device functions correctly and that they fully control the associated keys. The first step is verifying the receive address on the device itself. Malware on an internet-connected computer can alter the address displayed on the monitor, tricking the user into sending funds to an attacker's wallet. To prevent this, the user must compare the address shown on the hardware wallet's physical screen character-by-character with the address displayed on the computer monitor. The device screen is isolated from the computer and represents the true address generated by the secure element. Once the address is verified, a test transaction confirms the end-to-end functionality of the vault. For example, assume a user intends to secure 5 Bitcoin ($BTC) in cold storage. Instead of sending the full amount immediately, they send a small fraction, such as 0.001 BTC. The network fee required for this transaction fluctuates based on blockchain congestion. If the transaction fee mechanism demands 0.0001 BTC, the user spends 0.0011 BTC in total. After the transaction confirms on the blockchain, the user then wipes the hardware wallet by intentionally resetting it to factory settings. They then recover the wallet using their physical seed phrase backup. If the 0.001 BTC is present and the wallet can successfully sign a transaction to send a small portion back out, the user has proven their backup works and they possess complete control over the funds. Only then is the remaining 4.999 BTC transferred to the vault. Ongoing maintenance and firmware checks A long-term vault is not entirely "set and forget." Hardware and software protocols evolve, necessitating periodic maintenance. Hardware wallet manufacturers release firmware updates to patch security vulnerabilities, improve compatibility, and add features. Updating firmware carries inherent risks, as a failed update can occasionally wipe the device. Therefore, a user must always verify they possess the physical seed phrase before initiating an update. Furthermore, firmware updates should only be downloaded through the manufacturer's official software interface. Phishing campaigns frequently target hardware wallet users with fake emails or malicious software prompting them to download emergency updates or enter their seed phrase. Periodic recovery checks ensure the physical backups remain legible and accessible. Once a year, users verify their access to the safe deposit boxes or hidden locations where their steel plates reside. The physical condition of the backup is inspected, and the operational status of the hardware device is confirmed. Some users employ specialized software tools to check their UTXO (Unspent Transaction Output) set and balance without exposing their private keys. Common misconceptions Several misunderstandings persist regarding cold storage mechanics. Tokens live on the device: Digital assets exist exclusively on the blockchain ledger. The hardware wallet merely holds the keys to authorize movements of those assets. If a device is destroyed in a fire, the assets remain safe on the blockchain, accessible via the seed phrase. Air-gapped operation removes all risk: While air-gapping eliminates physical and wireless attack vectors during transaction signing, it does not protect against physical theft, extortion, or the loss of the seed phrase. Furthermore, users can still be victims of phishing if they willingly sign a malicious smart contract transaction, regardless of the air-gap. Batteries are required for long-term storage: Many hardware wallets feature internal batteries. If a device sits in a vault for five years, the battery may degrade and fail. However, the secure element containing the private key relies on non-volatile memory. Powering the device via a USB cable will still allow access to the keys and the ability to sign transactions, even if the internal battery is dead. What to watch The infrastructure surrounding cold storage continues to mature as both individuals and institutions seek robust self-custody solutions. Hardware manufacturers are exploring biometric authentication modules integrated directly into devices, adding a physical layer of security before the secure element will sign a transaction. Additionally, the cryptographic landscape is preparing for the potential advent of quantum computing. Current elliptic curve cryptography used in major blockchains could theoretically be broken by advanced quantum computers in the future. As discussed in Bitcoin Developers Propose BIP 360 to Mitigate Long-Exposure Quantum Vulnerabilities, protocol-level upgrades are actively being researched to transition networks to quantum-resistant signature schemes. Long-term vault operators will need to monitor these developments, as upgrading a cold storage setup to quantum-resistant standards may eventually require moving assets to new addresses generated with updated cryptographic algorithms. FAQ What happens if my hardware wallet is destroyed? Your funds remain secure on the blockchain. You can restore access to your assets by entering your seed phrase into a new hardware wallet. Can a hardware wallet be hacked if plugged into a computer? The private keys never leave the secure element. However, malware on the computer can trick the user into authorizing a fraudulent transaction by displaying a fake address. Is an air-gapped wallet better than a USB wallet? Air-gapped wallets eliminate the physical connection to an internet-enabled device, reducing certain attack vectors, though both designs rely on isolating keys within a secure element. Sources 1. Securing Your Wallet — Bitcoin.org 2. BIP 39: Mnemonic code for generating deterministic keys — Bitcoin Core Developers 3. NIST Special Publication 800-38F: Recommendation for Block Cipher Modes of Operation — National Institute of Standards and Technology --- Basis Desk is a source-verified crypto newsroom. Market data, a free MCP server for AI agents and JSON APIs: basisdesk.news. Not investment advice.

    1 reaction
  6. Reddit · · r/btc · u/lexicon_riot · bitcoin/bips

    Bitcoin's subtle approach to privacy is underrated Functional privacy in today's world depends on one's ability to remain private, while simultaneously blending in. You can't just walk into a bank wearing a ski mask and a trench coat without bringing even more attention to yourself. While onchain Bitcoin is transparent, the breadth of privacy tooling has substantially matured in the past couple of years, and they allow for you to transact privately without telling the whole world that you're transacting privately: - PayJoin (BIP 78, payjoin.org) breaks the common-input-ownership heuristic. In a normal transaction, chain analysis assumes every input belongs to one wallet. PayJoin has the recipient add an input of their own, so the transaction has inputs from two parties and the heuristic fails. The recipient's input also shifts the apparent amount, which hides the real payment value. From outside, it looks like an ordinary payment. - Silent payments (BIP 352, silentpayments.xyz) give you one static address that produces a unique output for each sender, derived from the sender's inputs and your public keys. You scan the chain privately with a scan key to find your payments. The outputs look like normal taproot outputs, and two payments to the same person share no on-chain link. No address reuse and no interaction. - Lightning (BOLT 12 offers) routes payments through off-chain channels, so the individual payment never reaches the public chain. Only channel opens and closes are on-chain, which removes most transaction data from the ledger. - Chaumian ecash (Cashu, Fedimint) uses blind signatures. The mint signs a blinded token at issuance and later sees a different unblinded token at redemption, so it cannot link the two. That gives deposit and withdrawal unlinkability inside a mint. The caveat here is Cashu mints are custodial and Fedimint splits custody across a federation with threshold signatures. The custodial tradeoff however (which is getting more and more trust-minimized with every protocol upgrade), creates some of the best privacy you could ever hope for. Zcash has strong cryptography while funds sit in a shielded pool, since zk-SNARKs hide sender, receiver, and amount. Two practical points get overlooked however: 1. The transaction type is public, so a recipient can tell whether funds arrived from a transparent or shielded address. They know a mask was worn, even if they cannot see who is behind it. 2. Viewing keys are voluntary disclosure. An exchange can require one before accepting a shielded deposit, and you can refuse, but then they can decline the deposit. They cannot extract it without your cooperation. Most large exchanges avoid the problem by only supporting transparent addresses. Monero's mandatory privacy is strong for the default user, at the cost of XMR itself being a massive privacy signal. Seeing XMR tells a counterparty that a privacy tool is in use, the way a single VPN exit IP tells a website that a proxy is in use. A merchant can easily be compelled to refuse XMR wholesale, the same way a site can block one data center IP that serves millions. The end result of all this, is that a Bitcoin user can look like a normal user rather than a person announcing a privacy tool. It's like you're drinking polyjuice potion to be some random guy who isn't you, instead of wearing a mask, which everyone can clearly see.

    33 comments
  7. How to Unstick a Bitcoin Transaction: RBF and CPFP Explained AI disclosure: drafted by Basis Desk's AI newsroom and machine-checked against the primary sources listed below — how we use AI. Originally published on Basis Desk. > A technical guide to resolving delayed $BTC transfers using Replace-by-Fee (BIP-125) and Child-Pays-for-Parent mechanisms. Key points - Replace-by-Fee (RBF) allows a sender to overwrite an unconfirmed transaction with a new one paying a higher fee. - Child-Pays-for-Parent (CPFP) allows anyone receiving an output to spend it with a high fee, forcing miners to confirm both. - RBF is generally cheaper and more efficient, but only available to the sender. - CPFP requires broadcasting a second transaction, consuming more block space. When a $BTC transaction is broadcast to the network with a fee that is too low, it can remain unconfirmed in the mempool indefinitely. Senders and receivers can resolve this by increasing the economic incentive for miners to process the transfer. The two primary mechanisms for unsticking a transaction are Replace-by-Fee (RBF) and Child-Pays-for-Parent (CPFP). The Mempool and Transaction Fees Bitcoin nodes hold unconfirmed transactions in a staging area called the mempool. Miners select transactions from the mempool to include in the next block, prioritizing those that offer the highest fee rate. Fee rates are calculated in satoshis per virtual byte (sats/vByte), matching the transaction's physical data size against the miner's financial reward [1]. If network congestion increases after a transaction is broadcast, the prevailing fee rate rises. Transactions with previously acceptable fee rates get pushed down the priority queue. If the fee rate is significantly lower than the current clearing rate, the transaction stalls. It remains valid but unconfirmed until congestion clears or it is dropped from node mempools entirely [2]. Replace-by-Fee (RBF) Explained Replace-by-Fee (RBF) is a protocol mechanism that allows a sender to replace an unconfirmed transaction with a new version that pays a higher fee [3]. Under the opt-in RBF standard formalized in BIP-125, the sender flags the initial transaction to indicate it can be replaced. When a transaction is stuck, the sender crafts a new transaction using the same inputs but directs a larger portion of the funds to miner fees, reducing the change output. The sender then broadcasts this replacement. Because the new transaction conflicts with the original by spending the same inputs, nodes accept the new one and discard the old one, provided the new transaction pays a higher absolute fee and a higher fee rate [3]. RBF is highly efficient because it does not require additional block space. It merely swaps a low-fee transaction for a high-fee equivalent. However, RBF can only be executed by the sender, as it requires the private keys associated with the transaction's inputs. Child-Pays-for-Parent (CPFP) Explained Child-Pays-for-Parent (CPFP) is an alternative method used when RBF is unavailable or when the receiver wants to expedite the transaction. CPFP relies on the fundamental rule of Bitcoin UTXOs: a transaction cannot be confirmed unless all its parent transactions are also confirmed [1]. In a CPFP scenario, the receiver (or the sender, if they received a change output) takes the unconfirmed output from the stuck transaction and uses it as an input in a brand-new transaction. This new "child" transaction includes an exceptionally high fee. Miners evaluating the mempool will see the high-fee child, but protocol rules dictate they must also mine the low-fee "parent" to claim the child's fee [2]. Miners calculate the combined fee rate of the parent and child transactions, known as the package fee rate, and mine both simultaneously if the package rate is competitive. CPFP consumes more block space than RBF because it requires broadcasting a second, entirely separate transaction. Consequently, it is generally more expensive than RBF, but it offers flexibility by allowing receivers to unstick incoming funds. Worked Example: Calculating a CPFP Fee Executing CPFP requires calculating the effective fee rate across two transactions. Assume a parent transaction is stuck in the mempool. It has a size of 250 vBytes and pays a fee of 2,500 satoshis, resulting in a fee rate of 10 sats/vByte. Due to network congestion, the current clearing rate for the next block is 50 sats/vByte. To unstick the parent, the child transaction must pay enough to raise the average of both transactions to 50 sats/vByte. Assume the new child transaction will be 150 vBytes in size. The total size of the package (parent + child) is 400 vBytes. To achieve a package rate of 50 sats/vByte, the total fee for the package must be: 400 vBytes * 50 sats/vByte = 20,000 satoshis. The parent transaction already pays 2,500 satoshis. Therefore, the child transaction must pay the remainder: 20,000 satoshis - 2,500 satoshis = 17,500 satoshis. The child transaction's individual fee rate will be artificially high (17,500 / 150 = 116.6 sats/vByte) to subsidize the parent's low rate. RBF vs. CPFP: Which to Choose? The choice between RBF and CPFP depends on network conditions, wallet software, and participant roles. Senders should generally use RBF if their wallet supports it and the original transaction was flagged as replaceable. RBF is cheaper and does not clutter the blockchain with extra transactions. Receivers must use CPFP. If a merchant or individual is waiting on a slow inbound payment, they can spend the unconfirmed output to themselves, attaching a high fee to force the confirmation. Senders can also use CPFP if they forgot to enable opt-in RBF, provided the stuck transaction included a change output directed back to their wallet. Common Misconceptions - Stuck transactions mean lost funds. A transaction pending in the mempool has not transferred any funds. If it never confirms, the nodes eventually drop it, and the funds remain freely spendable in the sender's wallet. - RBF is a double-spend attack. While RBF creates a conflicting transaction, it operates within strict protocol rules designed to prevent fraud. It is a legitimate fee-bumping mechanism, not a malicious exploit. - Miners process transactions sequentially by time. Miners prioritize profitability, not the timestamp of the broadcast. A transaction broadcast seconds ago with a high fee will be mined before a transaction that has sat in the mempool for days with a low fee. What to Watch Wallet developers increasingly automate fee management to shield users from manual RBF or CPFP calculations. As block space demand fluctuates, modern infrastructure defaults to opt-in RBF and provides simple "bump fee" buttons. Institutional custodians and exchanges heavily rely on CPFP to sweep user deposits efficiently during high-fee environments, batching multiple unconfirmed parents into a single high-fee child to optimize operational costs. FAQ What happens if I do nothing with a stuck transaction? If a transaction fee is too low to ever be mined, nodes will eventually drop it from their mempools, returning the funds to the sender's control. Can a receiver use RBF? No. RBF requires the private keys of the original sender to authorize a replacement transaction. Why would someone use CPFP instead of RBF? A receiver waiting for funds uses CPFP because they cannot initiate RBF. A sender might use CPFP if they failed to flag the original transaction for opt-in RBF. Sources 1. Bitcoin Developer Reference: Block Chain and Mempool — Bitcoin.org 2. Transaction Fees — Bitcoin.org 3. BIP 125: Opt-in Full Replace-by-Fee Signaling — Bitcoin Improvement Proposals --- Basis Desk is a source-verified crypto newsroom. Market data, a free MCP server for AI agents and JSON APIs: basisdesk.news. Not investment advice.

    1 reaction
  8. Bitcoin Address Types Explained: Legacy, SegWit, and Taproot AI disclosure: drafted by Basis Desk's AI newsroom and machine-checked against the primary sources listed below — how we use AI. Originally published on Basis Desk. > An overview of Bitcoin address formats, detailing how encoding and script types dictate transaction fees, privacy features, and wallet compatibility. Key points - Legacy addresses begin with '1' and require the most data, resulting in higher transaction fees. - P2SH addresses begin with '3' and allow for complex scripts, including multisig and nested SegWit. - Native SegWit (bc1q) separates signature data, offering roughly a 38% fee reduction over Legacy. - Taproot (bc1p) uses Schnorr signatures to aggregate complex transactions, improving privacy and block efficiency. A Bitcoin address serves as an instruction manual for how funds are locked and subsequently unlocked on the network. Over time, the $BTC protocol introduced new address formats—spanning from original Legacy designs to SegWit and Taproot—to optimize block space, reduce transaction fees, and improve privacy. Users and institutions navigating these formats must weigh fee efficiency against software compatibility. Legacy Addresses: The Original Standard The first iteration of Bitcoin addresses, known as Legacy or Pay-to-Public-Key-Hash (P2PKH), begins with the number "1". This format was the default standard for the first several years of the network's existence. Legacy addresses use Base58Check encoding, which includes a checksum to prevent typographical errors but is case-sensitive, making it prone to human error during manual transcription. Transactions originating from Legacy addresses are the most data-intensive. When spending funds from a P2PKH address, the user must reveal their public key and a cryptographic signature within the transaction data. Because Bitcoin block space is strictly limited, the larger data footprint of Legacy transactions translates directly to higher network fees. Consequently, most modern wallet infrastructure has migrated away from generating new "1" addresses, though they remain fully supported by the consensus rules for receiving and sending funds. Pay-to-Script-Hash (P2SH): Enabling Complexity Addresses beginning with the number "3" rely on the Pay-to-Script-Hash (P2SH) standard. Introduced to shift the burden of data storage from the sender to the recipient, P2SH allows users to lock funds in a script that requires specific conditions to be met before the funds can be moved. Initially, P2SH addresses were predominantly used for multi-signature (multisig) wallets, where multiple private keys are required to authorize a transaction. Later, P2SH served a critical transitional role for the Segregated Witness (SegWit) upgrade. By nesting a SegWit script inside a P2SH address, developers created a backward-compatible format known as Nested SegWit. This allowed older wallets that did not understand native SegWit to send funds to SegWit-enabled wallets, reducing fees slightly compared to purely Legacy transactions while maintaining broad compatibility. Native SegWit: The Efficiency Upgrade Introduced in 2017, Native SegWit (Pay-to-Witness-Public-Key-Hash or P2WPKH) addresses begin with "bc1q". This upgrade fundamentally altered how transaction data is structured by separating, or segregating, the cryptographic signature (the witness data) from the transaction data. Native SegWit addresses utilize Bech32 encoding. Unlike Base58Check, Bech32 is exclusively lowercase, eliminating confusion between similar-looking characters like "O" and "0" or "I" and "l". The primary advantage of Native SegWit is cost reduction. Because witness data is weighed differently by the Bitcoin protocol—enjoying a 75% discount in terms of block weight—transactions originating from "bc1q" addresses require significantly lower fees. Taproot: Privacy and Advanced Scripting Activated in 2021, the Taproot upgrade introduced addresses beginning with "bc1p". This format uses a modified encoding scheme called Bech32m, designed to fix a minor vulnerability found in the original Bech32 standard. For further reading on the cryptographic mechanisms behind this upgrade, see Bitcoin Taproot, Explained: Schnorr Signatures and MAST. Taproot leverages Schnorr signatures, which allow for signature aggregation. In a standard multisig transaction using older address types, every participant's signature must be published to the blockchain, consuming block space and revealing the governance structure of the wallet. With Taproot, multiple signatures can be aggregated into a single signature. This makes complex transactions—such as lightning network channel openings or institutional multisig operations—look identical to standard, single-signature transactions on the public ledger. This upgrade improves both privacy and data efficiency for complex smart contracts on the Bitcoin network. Transaction Fees and Address Types The most tangible impact of address types for end-users is transaction pricing. Bitcoin miners prioritize transactions based on the fee paid per unit of data (measured in satoshis per virtual byte, or sat/vB). Because different address types require different amounts of data to unlock funds, the address type directly dictates the cost to send $BTC. Consider a standard transaction scenario: sending funds from a single input to two outputs (one destination address and one change address back to the sender). Assuming a network fee rate of 20 sat/vB: - A Legacy (P2PKH) transaction has a size of approximately 226 vBytes. The total fee would be 4,520 satoshis. - A Native SegWit (P2WPKH) transaction has a size of approximately 140.5 vBytes. The total fee would be 2,810 satoshis. In this example, utilizing Native SegWit results in a fee reduction of roughly 38% compared to Legacy infrastructure. As network congestion rises and fee rates increase, the absolute cost savings associated with efficient address types become significantly larger, driving institutional and retail migration toward "bc1q" and "bc1p" formats. Common misconceptions - Address formats dictate network isolation: It is a common misunderstanding that Native SegWit or Taproot addresses operate on a different network. All standard address types are cross-compatible at the protocol level; a Legacy address can send funds to a Taproot address, and vice versa. Compatibility issues only arise when a specific wallet or exchange software has not updated its user interface to recognize newer prefix formats. - Newer addresses are less secure: Some users assume that cryptographic discounts on witness data or new signature schemes compromise security. The security models for P2WPKH and P2TR are mathematically robust and have been rigorously vetted by the Bitcoin development community. - Reusing addresses is required: While addresses can technically receive multiple transactions, address reuse degrades privacy for both the sender and the receiver by linking financial histories. Modern hierarchical deterministic (HD) wallets generate a new address for every transaction automatically, regardless of whether they use Legacy or SegWit formats. How this connects to the market The adoption of efficient address types acts as a barometer for institutional infrastructure upgrades and network health. Exchanges and custodians processing thousands of daily withdrawals face immense operational costs during periods of high network congestion. By upgrading backend systems to Native SegWit or Taproot, institutions drastically reduce overhead, which often translates to lower withdrawal fees for retail clients. Furthermore, the proliferation of Taproot (bc1p) addresses is closely monitored by market analysts as a proxy for advanced network usage. Because Taproot enables more efficient multisignature setups and arbitrary data inscription, spikes in Taproot adoption often correlate with the deployment of new institutional custody arrangements or waves of activity in on-chain assets and protocols built atop the base layer. FAQ Can a Legacy address send Bitcoin to a Taproot address? Yes. All standard Bitcoin address types are cross-compatible on the blockchain. Any limitations are strictly due to the specific software or exchange being used, not the Bitcoin protocol itself. Why are Native SegWit addresses lowercased? Native SegWit addresses use Bech32 encoding, which relies on a specific 32-character alphabet consisting entirely of lowercase letters and numbers. This design eliminates visual ambiguity and reduces transcription errors. Do I need to migrate my old Bitcoin to a new address format? No action is strictly required. Funds held in Legacy addresses remain secure and spendable. However, moving them to a SegWit or Taproot address will lower the fees incurred when you eventually spend those funds in the future. Sources 1. Bitcoin Developer Reference: Transactions — Bitcoin.org 2. BIP 341: Taproot: SegWit version 1 spending rules — Bitcoin Improvement Proposals --- Basis Desk is a source-verified crypto newsroom. Market data, a free MCP server for AI agents and JSON APIs: basisdesk.news. Not investment advice.

    1 reaction
  9. Reddit · · r/SimpleSwap_io · u/SimpleSwap_community · bitcoin/bips

    The Landfill Fortune: The Biggest Bitcoin Fortunes Lost to Forgotten Keys Somewhere under a landfill in South Wales sits a hard drive worth more than half a billion dollars if anyone can read it. It has company: a USB stick with two password guesses left, a colleague-wiped laptop, a clicking drive left out with the rubbish in Sydney, and more than a million coins nobody will ever spend again. These are the biggest bitcoin fortunes lost to forgotten keys, and the one habit that would have saved most of them. Two identical drives, one wrong bin In February 2009, a month after the network went live, James Howells started mining bitcoin on a Dell laptop in Newport, Wales. By the time he stopped, he had thousands of coins: he put the figure at 7,500 when the story first broke in 2013 and has said 8,000 in recent years. In 2010 he spilled a drink on the laptop, removed the hard drive and kept it in a desk drawer. By 2013 the drawer held two identical drives. One was blank. The other held the only copy of the private key to all of it. During a clear-out in the summer of 2013, someone put the wrong drive in a bin bag and sent it to the Docksway landfill. By November that year, when the story first made headlines, the coins were worth about $7.5 million, and the drive was already under several months of other people’s rubbish. The years since have been one long request for permission. In 2021, Howells offered Newport City Council a share of the coins worth more than $70 million. He lined up around $11 million in venture funding for a search built on AI-trained sorting machines and a magnetic belt, aimed at a section of the site holding an estimated 100,000 tonnes of waste. The council said no every time, citing its environmental permits and the position that anything tipped into the landfill became its property on arrival. In January 2025, the High Court sided with the council and struck out the claim as having no realistic prospect of success; in March, the Court of Appeal refused to hear the matter further. The council planned to close the site in the 2025/26 financial year and holds planning permission to put a solar farm on part of it. Howells spent much of 2025 trying to buy the section of the landfill he believes holds the drive, then said in August that he was no longer pursuing the purchase and would try to tokenize his claim to the coins instead. At $80,000 per bitcoin, 8,000 BTC is about $640 million. Anyone can see the coins on the blockchain. Nobody can move them. The detail that matters most is also the oldest one: in 2009 there was no such thing as a seed phrase. A wallet was a file called wallet.dat, and the file lived on one disk. Two guesses left In 2011, a programmer named Stefan Thomas made an animated explainer called “What is Bitcoin?” and was given 7,002 BTC for the work. He stored the private keys on an IronKey, an encrypted USB drive designed to wipe itself after ten wrong passwords, and wrote the password on a piece of paper. The paper is gone. Eight of the ten guesses went with it. The drive now reportedly sits in a Swiss bank vault. In October 202,3 a recovery firm, Unciphered, said it had found a way around the IronKey’s guess counter and offered, in an open letter, to crack it. Thomas declined; he had already made agreements with two other teams. As of mid-2026, no recovery has been reported. Two attempts remain, and at $80,000 per coin they stand between him and roughly $560 million. Thomas posted his own conclusion in 2021, and it is the most useful sentence in this article: “Test your backups regularly to make sure they are still working.” Smaller fortunes, same mistake Not every lost key makes the national news. Campbell Simpson, an Australian technology journalist, bought 1,400 BTC in 2010 for about $25 and kept the wallet file on a portable drive. A couple of years later, the drive developed a click, so he threw it out with other aging hardware and only remembered the coins months afterward. At $80,000 per coin, that was a $112 million drive. Gabriel Abed, a Barbadian entrepreneur, lost 800 BTC in 2011 when a colleague reformatted the laptop that held his keys. That is about $64 million at current prices. He kept far more than he lost, and he told The New York Times that being his own bank was worth the freedom it bought. Then there is the near miss. In 2016, writer Mark Frauenfelder bought 7.4 BTC for about $3,000, moved them to a hardware wallet, and wrote both the PIN and the 24-word recovery phrase on one orange sheet of paper. In the spring of 2017, a cleaning service threw the sheet away, and when he went to move the coins, he found he had forgotten the PIN too. The device doubled its waiting time after every wrong attempt. He got back in that August only because a teenage security researcher found an exploitable flaw in the device’s firmware. The flaw has since been patched. The mistake is still available to everyone. How many bitcoin are gone for good? Nobody knows, and the honest answer starts there. The blockchain shows coins that sit still; it cannot show why. Analysts work backward from dormancy, and their totals depend on what they decide to count. Chainalysis’s 2017 study put lost coins at between 2.78 and 3.79 million, a figure that included the million-plus BTC attributed to Satoshi Nakamoto and never moved. River’s January 2025 analysis excluded Satoshi and weighted each dormant cohort by how likely it is to be truly gone. It arrived at about 1.6 million BTC lost through self-custody mistakes, more than the roughly 1.2 million lost in exchange collapses like Mt. Gox and FTX. Between those two estimates sits a range of 8% to 18% of all the bitcoin that will ever exist. Dormant is not the same as dead, which is why the range stays wide. On September 22, 2026, an address funded in July 2012 moved 600 BTC after 14.2 years of silence, according to Galaxy Research. Somebody kept a key safe for a decade and a half. This one transaction captures the whole lesson of this article. Why seed phrase storage matters Every case above broke at the same point, and it was never the cryptography. It was the one faculty no software can back up: human memory. Howells remembered where the drive was but couldn’t reach it. Thomas remembers the drive and not the password. Simpson forgot the drive existed. Frauenfelder kept everything on one sheet of paper. The modern fix for Howells’s wallet.dat problem is the seed phrase, standardized as BIP39 in 2013: 12 or 24 ordinary words from which a wallet regenerates every one of its keys. It turns a fragile file into something you can write down twice. It also concentrates the wallet’s entire security on one piece of paper, which is where the discipline comes in. - Write it down offline. Paper or metal. Not a screenshot, not a notes app, not an email draft, not a cloud folder. Malware that scans photo libraries for twelve-word grids exists; our Know the Scam series covers it. - Keep two copies in two places. One sheet in one drawer is the Howells setup. A second copy elsewhere survives the fire or the flood that takes the first. - Choose metal when the stakes justify it. Paper fails in water and in fire; a stamped steel plate is indifferent to both. - Test the recovery before you trust it. Restore the written phrase into a second wallet app or a spare device. Send a small amount in, then out again. Thomas’s two remaining guesses are what an untested backup looks like fifteen years on. - Never type it into anything that asks. No website, no form, no “support” chat, no wallet “verification” page. No legitimate service needs your seed phrase to help you, and SimpleSwap will never ask for it or for a private key. - Mind the clipboard and the screen. Clipboard hijackers swap addresses; screenshot malware reads phrases. Type the words by hand from the physical copy. - Plan for the day you are not there. Someone you trust should be able to reconstruct access without you, through a sealed copy or a split arrangement, so your coins do not end up as one more line in a lost-bitcoin estimate. Where this meets your swap Self-custody means you keep the keys at both ends of a transaction. A swap on SimpleSwap moves crypto from a wallet you control to another wallet you control, leaving no account balance on the platform afterward. This arrangement means nothing on our side can restore a key you have lost. The list above is the price of that arrangement. The stories above are the price of skipping it. FAQ How many bitcoins are lost forever? Estimates range from about 1.6 million (River, 2025, excluding Satoshi’s coins) to 3.79 million (Chainalysis, 2017, including them). The true number cannot be observed on-chain; it can only be inferred from how long coins have sat unmoved. Can lost bitcoin be recovered? Only if the key or the seed phrase still exists somewhere. Specialists can sometimes recover or crack a password on an intact drive; a key that was never backed up cannot be regenerated, and nobody can reissue the coins. What happened to James Howells’s hard drive? Howells believes it is still buried in the Docksway landfill in Newport, Wales; it has never been recovered. The High Court struck out his claim against the council in January 2025, and in August 2025 Howells said he was no longer pursuing a purchase of the site or an excavation. What is a seed phrase? A list of 12 or 24 words, defined by the BIP39 standard, from which a wallet regenerates all of its private keys. Whoever holds the words controls the funds, so store them offline and never share them. The information in this article is not a piece of financial advice or any other advice of any kind. The reader should be aware of the risks involved in trading cryptocurrencies and make their own informed decisions. SimpleSwap is not responsible for any losses incurred due to such risks. For details, please see our Terms of Service.

    1 point
  10. Bitcoin Core - over a trillion dollars worth fo value in this repository Security researchers can review the codebase on their own - will be a story to tell and finding something valuable means lots of glory, so you never know - keep hunting for bugs🫡 bitcoin/bitcoin

    42 likes · 2 reposts · 3,012 views

Achievements

Awards earned by the repositories bitcoin owns. Select an award to embed its badge.

Gold
51st place finishes
Silver
62nd place finishes
Bronze
93rd place finishes
Awarded repositories
1Owned by bitcoin now

Repositories

Ordered by gold, then silver, then bronze.

  1. bitcoinBest: 1st by forks, 170 forks569

Every award

Top-three finishes of these repositories in completed trending days and weeks, newest first.

  1. bitcoin
  2. bitcoin
  3. bitcoin
  4. bitcoin
  5. bitcoin
  6. bitcoin
  7. bitcoin
  8. bitcoin

A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.