GM. Timelocks are cool.

How quantum computing affects Bitcoiners, Part II The second part of our summary of Chaincode Labs' excellent paper on Bitcoin and quantum resistance. Migration strategies and the burn vs steal debate. Bitcoins that are locked in addresses with publicly-revealed public keys are most vulnerable to theft from future quantum computers: - Satoshi's coins - Other early coins that may be lost - Reused addresses Researchers estimate that there are 6 million such vulnerable bitcoin It's not just Satoshi's coins and coins with lost keys that are vulnerable Some prominent examples of addresses with exposed public keys are yellow highlighted in this image from @Jameson Lopp 's article on quantum resistance:

Cypherpunk Cogitations

Against Allowing Quantum Recovery of Bitcoin

An argument in favor of burning bitcoin in vulnerable addresses to prevent funds from being taken by those who win the quantum computing race.

Ideally, we come up with a way to make all coins safe from quantum attack All quantum resistance proposals currently require that users send their coins to new, quantum resistant addresses There are ~190 million UTXOs The good folks at Chaincode Labs pulled together research on how long it might take to migrate everyone's bitcoin to quantum resistant addresses Estimates vary between 140 and 560 days This is one very strong reason to start working on this problem long before it becomes a problem There are a number of proposals for how this migration could work: But all of them first require a soft fork or hard fork to introduce new quantum resistant address types Commit-Delay-Reveal (CDR) has users create a quantum-resistant tx with an op-return that references the public key of their vulnerable coins A soft fork then enforces a time delay before the coins can be moved by a 2nd tx that is signed by the original key and the op-return key Quantum Resistant Address Migration Protocol (QRAMP) proposes a hard fork that enforces a flag day beyond which coins in quantum vulnerable addresses can no longer be spent QRAMP could be used in combination with proposed BIP 360: pay to quantum resistant hash addresses Hourglass strategy A soft fork enforces a new rule that only a certain number of txs spending from quantum vulnerable addresses may be included in any one block This slows the rate at which such coins could be stolen (or spent) Might also generate a lot of fees for miners In addition to the question of how Bitcoin achieves quantum resistance, there is also this: What happens to the coins to which nobody has the keys? Some proposals permanently freeze them while others leave them up for quantum theft. Burn or steal? The burn argument goes like this: Sure we don't want to prevent anyone from spending their coins, but this is a clear vulnerability: coins that the protocol guarantees as safe can be stolen. Therefore, permanently freezing the lost coins best maintains Bitcoin's rules The steal argument goes like this: Bitcoin is built on enforcing the sovereignty of key-owners. Changing the protocol to freeze some coins violates this important value. Bitcoin should never change its rules such that we risk preventing a user from spending their coins. Where does this leave us? Making Bitcoin quantum resistant requires 1. A soft fork 2. Migrating all coins to new addresses 3. Tough decisions about what to do with coins that can't migrate Bitcoin has so many stakeholders at this point that such an undertaking will clearly be slow Even if you think that quantum computing is far overhyped, we really should start moving on it. The best thing you can do is educate yourself. Read Chaincode Labs' paper here: https://chaincode.com/bitcoin-post-quantum.pdf Huge props to Clara Shik and @deadmanoz for their work!

GM. Ask somebody to pay you in Bitcoin today.

How quantum computing affects Bitcoiners 🧵 Summarizing Chaincode Labs' excellent recent paper on the topic tl;dr 😅 Quantum computers do not pose a threat to Bitcoin today 😰 But many researchers agree they will in the next 5 - 10 years 🧐️ Bitcoiners should start working on mitigations Here's how quantum computers could threaten Bitcoin: An everyday computer can derive a public key from a Bitcoin private key in a few microseconds But the reverse is much more difficult: Today's supercomputers would take ~100 quadrillion years to find the private key for a known public key Quantum computers could theoretically derive a Bitcoin private key from a known public key in just a few hours So the primary risk quantum computing poses to Bitcoiners is for situations where the public key to your coins has been exposed How might that have happened? Long-range quantum attacks: Some address types expose their public key: Pay to public key Pay to multisig Pay to Taproot Since these public keys are exposed as soon as the address receives coins, quantum computers may be used to derive their private keys and steal the coins Short-range quantum attacks: When you spend bitcoin, you reveal the public key for the coins in your transaction A quantum computer may be used to derive their private key and spend them in a new transaction with a higher fee before your transaction is included in a block Address reuse: Coins that reuse an address from which other coins have already been spent may also be vulnerable to theft because the previous spends revealed the address's public key A quantum computer may be used to derive private keys to any coins still at a reused address Exposed xpubs: Many services request that Bitcoiners provide an extended public key (xpub) used to generate addresses If such an xpub is leaked, all addresses generated by that xpub may become vulnerable to having their private keys derived by a quantum computer Advances in quantum computing could also affect mining: Quantum computers may slightly weaken the security of the SHA256 hash function used in mining, but it is unlikely they could break it This means Proof of Work is probably still reliable in a quantum computing future However, quantum miners may be subject to much stronger centralization pressures: the best quantum hardware "would gain a disproportionate speedup, eliminating the incentive for less powerful quantum miners - as well as those who lack quantum computers - to participate" Quantum resistance Fortunately, there are a number of feasible proposals for how Bitcoin could become resistant to quantum attacks Unfortunately, most of them involve using much larger signatures (read: quantum resistant spending might mean you pay a lot more in mining fees) Tomorrow, we'll look at the second half of Chaincode's paper: Migration strategies and the big question facing Bitcoiners: burn or steal? Read the full Chaincode report at: https://chaincode.com/bitcoin-post-quantum.pdf And be sure to follow the report's authors: Clara Shik & ozdeadman

Want to learn more about timelocked recovery keys and how they can change the security trade-offs for your backups? We wrote an article about it. Check it out 👇

Wizardsardine - a team of bitcoiners with a passion for security

What is a Bitcoin recovery key?

Finding a durable and secure way to store your Bitcoin keys can be challenging. Using a wallet with a recovery key gives you an interesting new set...

GM. We're cooking away here: Liana v11 should be out soon!

Nacho Bitcoin - the music video Feat. Blackrock, Coinbase & Friends Sound up 🔊

GM. Tired of pizza? How about nachos... Nacho Bitcoin (the music video) feat. Blackrock, Coinbase & Friends

GM. Your money is headed for extinction. Learn how to use money that isn't: #Bitcoin

GM. You can start holding your own #Bitcoin keys with just a few dollars worth of bitcoin.

GM. Today is a good day to hold your own keys.

GM. Have you spent more time reading/talking about op_return limits than you have setting up an inheritance plan and teaching your family how to recover your coins?

It seems we are sticking with a space theme today...

Not today, little do-gooder hobbit! Use timelocked recovery keys for your coins and prevent destructive halflings from ruining your day.

GM. Not your keys, not your coins.

What is the difference between a filter and a bitcoin consensus rule? Recently, Peter Todd proposed removing Bitcoin Core's 83-byte limit on op_returns. Is this changing Bitcoin? The limit isn't a consensus rule, so it doesn't change what can go in blocks or what is in a valid transaction--which might make you wonder *Why are there Bitcoin rules that aren't consensus rules?* Turns out there is a big difference between consensus rules and mempool policies like these (also called standardness rules or transaction filters). Understanding the discussion around removing the op_return limit is a lot easier when we are clear on what this difference is. Let's start with the role nodes play in the Bitcoin network. 🖥️ A node is just a computer A node downloads blocks and runs the math to check that all the transactions follow the consensus rules of Bitcoin. While it may not sound like much, this plays a crucial role in keeping Bitcoin decentralized and free from any single party's control. Anyone can run a node (it doesn't take a special computer or very much technical experience). Running a node lets you see for yourself that the coins you receive are real and follow the rules as you understand them. It's kind of like having your own inhouse gold assayer, but for bitcoin. 🌐 Bitcoin really is a network Nodes also play another important role: they relay newly mined blocks and new transactions that haven't made it into blocks yet. All around the world, there are tens of thousands of computers sharing new blocks that have just been mined and new transactions that have just been broadcast. One of the reasons having a lot of nodes is important is so that a new miner can easily learn about new transactions that haven't been mined yet and try to collect their fees by mining them. Another reason is that having a robust network of nodes sharing transactions makes it more likely that the transactions you broadcast will make it to a lot of different miners, and thus be more likely to get mined. 🚫 We don't talk about Bruno (well, actually just certain kinds of transactions) Nodes *can* refuse to tell other nodes about transactions -- even if they are perfectly valid. It might seem like there's no good reason to do such a thing: that's censorship isn't it? Not necessarily. There are several very important reasons why nodes might want to refuse to relay certain transactions: ⚔️ DoS attacks An attacker could design a block full of special transactions that can take a lot of time to validate. While such transactions follow Bitcoin's rules, they don't serve much purpose other than to grief node runners and sabotage miner competition. 🪝 Upgrade hooks Most nodes also refuse to relay transactions that utilize certain generally unused fields, even though there's no rule in Bitcoin that says these fields can't be used. Developers are hoping to reserve these fields for future upgrades, but they will be a lot less useful if users put them to a smattering of different uses before a standard is set. 🧹 Dust limits You can create a transaction in Bitcoin with such a small value that it is guaranteed that whoever receives the coins will have to spend more money in fees than the coins are worth. Even though such transactions don't break Bitcoin's rules, most nodes won't relay them in an effort to prevent users from creating coins that aren't economically useful. 🙅 Deterring certain user behaviors People seem to enjoy putting arbitrary data into blocks. Because Bitcoin is a permissionless system, it is very difficult to prevent people from doing this. One common way this is achieved is by using a piece of Bitcoin Script called op_return. In an effort to incentivize the least costly (for noderunners) version of putting arbitrary data in blocks, nodes will generally relay transactions with op_return data. But most nodes won't relay a transaction that has more than one op_return output or if the op_return is larger than 83 bytes, even though the consensus rules do not have a limit (other than the transaction size) for op_return data. 📝 It's not censorship, it's policy! So now we are back to the op_return limit. The current mempool policy that nodes won't relay op_returns larger than 83-bytes was introduced in 2015. Since then, it has been pretty effective at preventing larger op_returns from ending up on the chain. What is the difference between such a policy and a policy that refuses to relay transactions that come from certain blacklisted addresses? While the purpose of the two policies may be wildly different (one aims to protect Bitcoin for financial uses while the other aims to censor it), the form of the two policies seems pretty similar. ⚒️ Proof of Work is designed to break filters Every Bitcoin transaction carries a fee. These fees pay for blockspace which miners provide by expending electricity. Energy sources are widely distributed around the world, so if some miners refuse to mine certain transactions, we hope the increased fees censored transactions are willing to pay incentivizes other miners to put them in blocks. Bitcoin uses Proof of Work to create censorship resistance. We all certainly hope that in the case of blacklists or other attempts at censorship, this mechanism will kick in and save the day. But the question is, why won't same dynamic won't play a similar role in the case of op_return limits? **Bitcoin only works if it is true that people can always get their transactions mined by paying more.** In the case of mempool policies, standardness rules, and transaction filters, paying more may mean something as simple as skipping the mempool and paying a higher fee via a mining pool's transaction accelerator. Miners have a strong incentive to figure out how to take the fees people want to pay them. Bitcoiners are counting on it. 🥤 Filters are not Consensus Lite There is a fundamental difference between how consensus rules and mempool policies function: - Different rules about what you accept into a block (consensus rules) will cause you to fork off. - Different rules about which transaction your node will relay (mempool policies) will **not** cause you to fork off. Consensus rules are known beforehand. When you accept a coin in payment you are agreeing to the rules that particular coin has followed (and you're able to dictate what those are by refusing to accept coins that don't follow the rules as you understand them). Mempool policies can be enacted by any node that wants them. You don't get any say about other node's policies and they can't tell you what yours should be. However, you *can* still accept coins that come from a transaction that is disallowed by other nodes policies. And once those coins are in a block, everyone else has to accept them as valid too (unless they want to fork). We must all agree on consensus rules if we want to use the same coin. We do not have to agree on mempool policies.

Excellent Persian language Liana tutorial from Ziya Sadr! Includes both simple inheritance and expanding multisig options. Check it out:

> Create Bitcoin > Achieve perfect opsec > Move on to other things Satoshi, 14 years ago today

If you've been looking for a step-by-step guide to set up Liana Wallet with - timelocked inheritance keys - multiple hardware signers - custom multisig You should definitely check out this @BTC Sessions tutorial: