For a more technical background on the current filter/mempool policy debate, check out this by Antoine Poinsot:
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.
GM. bitcoin on your keys > bitcoin on your balance sheet
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 nostr:nprofile1qyvhwue69uhkyat8d4skutndva6hjtnwv46r5dpcxsuqz9nhwden5te0vfjhgcfwdehhxarjd9kzucmpd5qzqxvfqd89dw8kqmrjfaz6zt8gfggcg93p4tm3s2slv4jrszuugfmt74rjkj tutorial:
How to get Taproot privacy benefits for your Bitcoin today π§΅
π₯οΈ Taproot has been live since block 709632 (three years ago)
π₯Έ It can improve your onchain privacy
π°οΈ It can save you money
But how the f*ck do you start using it?
First: you need a wallet app that supports Taproot.
Second: you have to receive coins to addresses generated by this wallet (Taproot addresses start with bc1p...).
And now you're using Taproot!
...so what?
Before Taproot, spending a coin revealed all spending paths. So if you had a timelocked inheritance key, spending with the primary key showed everybody you also had an inheritance key. In Taproot, you only show the path you use to spend.
Here's another example:
Before Taproot, if you have a 2 of 2 multisig with a 3rd recovery key, spending coins from your wallet revealed that you had a third recovery key. With Taproot, people only learn about your recovery key when it is used.
Also: Schnorr pubkeys and signatures are smaller than ECDSA (ECDSA is the signature scheme non-Taproot Bitcoin uses), so Taproot signatures often take up less blockspace. This means spending Taproot coins is cheaper.
So: tl;dr to start using Taproot:
π±οΈ You DON'T need a new seed phrase
π₯οΈ You DO need wallet software that supports taproot
ποΈ You DO need to create a new wallet
β¬οΈ You DO need to receive coins to Taproot addresses
In Liana Wallet, it's as easy as selecting Taproot addresses from a dropdown menu on installation. If you want to start Taproot maxing, give it a download here
ποΈ https://wizardsardine.com/liana
GM! Don't know the difference between Regtest, Testnet, and Signet?
tl;dr: they are all kinds of Bitcoin testing networks where coins have no value
Regtest: local sandbox
Testnet: difficulty resets frequently
Signet: permissioned mining
Test networks are handy for testing:
- potential consensus rule changes
- new software products that interact with Bitcoin
- network dynamics and mining
- lots more!
The closer they are to real Bitcoin the better
Regtest is the most basic Bitcoin testing network:
- you mine blocks w/ a `generate` command
- you choose the peers
It lets you test how software interacts with consensus rules
But it doesn't model a permissionless public network very well
Testnet was created to model almost all the same attributes as the real Bitcoin network
- anyone can join the network
- anyone can mine on it
- no one controls it
sounds great, right?
Mining difficulty only adjusts every 2016 blocks
If someone with a lot of miners comes to Testnet to try something out and then leaves..
Everyone else might be in for a long wait before they can mine blocks
Not ideal.
So Testnet also got this rule: if no block is mined for 20 minutes, difficulty resets to minimum.
Sounds good but it leads to a lot of problems:
- Block production is highly volatile
- Reorgs are common
- It can be hard to get new coins
Bitcoiners have been looking for a stable testnet model for quite a while.
2010: First public testnet
2011: Testnet2
2012: Testnet3
2024: Testnet4
It's hard to make a network where coins are free but mining still takes real resources
People get frustrated with Testnet...
(Not all people though: that fabulous Bitcoin troubadour nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcqyqsc8628tpyp6rcjf77e83tve2j9ulj5tnht34fgfrucy5l5j7uh2r2aejt took his name from testnet3...and superman)
...so Signet (BIP325) was proposed in 2019, and merged into Bitcoin Core v21.
What is Signet?
A centralized Bitcoin testing network where
- mining still takes PoW
- but blocks also need a signature from network operator
This makes Signet reliable and stable, much better for most testing applications
The default Signet targets a block interval of 10 minutes, just like Bitcoin mainnet
Check it out: https://mempool.space/signet
But anyone can start their own Signet
Mutinynet targets a block interval of 30 seconds
If you are Signet poor, here are some faucets we tested where you can stack some Signet sats!
- https://bitcoinsignetfaucet.com/
- https://signet25.bublina.eu.org/
Some great resources for learning more the different Bitcoin testing networks can be found here:
ποΈ https://bitcoinops.org/en/topics/testnet/
ποΈ https://bitcoinops.org/en/topics/signet/
ποΈ https://blog.lopp.net/griefing-bitcoin-testnet/
Following along with @lopp's testnet adventures is an excellent way to get a crash course in bitcoin testing.
You can use Liana with Regtest, Testnet (still testnet3), Signet, and Mainnet.
If you just want to play around with it, give it a whirl on Signet and tell us what you think!
ποΈ Download: https://wizardsardine.com/liana/
GM. Bitcoin is more than send and receive. Learn how to use timelocks to set up inheritance keys for your heirs. 
Learn how to use Bitcoin's script capabilities. 
GM. Don't know much about Liana?
Check out these features:
π± Open source
π± Bitcoin-only
π± Singlesig
π± Multisig
π± Miniscript
π± Onchain timelocks
π± One-click node
π± Taproot
π± Coin control
π± Labels
π± No KYC
π± Easy to use
π± Dark mode only
π± Compatible w/ Ledger, Jade, ColdCard, BitBox, SpecterDIY, Krux
π¨οΈ LAST CHANCE to enter our Satoshi Birthday free Liana Box drawing!π¨οΈ
π Liana Wallet is dark-mode only...just like the Batman.
ποΈ Follow us
ποΈ Repost this post
ποΈ Comment below your favorite thing that is dark-mode only
Drawing is tomorrow!
GM. Self custody is a lifestyle.
Self custody is a lifestyle.
For some reason our wallet has a coin labeled "surfboard for houseplants"...
Anyhow, we love labels and BIP329!
Want to enter our Satoshi Birthday free Liana Box drawing?
π Give us a follow
π Comment below the best label in your wallet
What is a Liana Box you ask? Check it out here: https://cryptosteel.com/product/liana-box-starter-pack/
GM. multisig != too complicated
You can use bitcoin script to make a wallet that locks coins with a primary spending key and a recovery key that only becomes active if the primary key isn't used for a year.
GM. Today's a great day to live like you hold your own keys. 
It's a relative timelock, using the nSequence field, so it's currently limited to ~15 months. You can send your coins to yourself to renew the timelock.
Use a timelocked recovery key so you don't have to trust an executor to give your kids your #Bitcoin.
Single points of failure can be easy to overlook. Help us find them!
ποΈ Comment an often missed single point of failure in #Bitcoin cold storage setups
ποΈ Top 5 get entered in our Satoshi birthday giveaway drawing to win a free Liana Box