Welcome to the first edition of Ben's Bytes!
This is benthecarman's mommy blog on all things bitcoin development. Here we are gonna talk about work being done in the space, my experience developing, and highlight projects and efforts that don't get as much as attention as they deserve. The plan is to keep this technical; I'll define things the first time they come up in the newsletter, but I don't want to have to explain something like Taproot every time, so make sure you study up.
I don't plan to be like Bitcoin Optech where I give you a holistic update on the developments in Bitcoin. This is a mommy blog; it will be biased towards things I find interesting and things I am working on/with. I highly recommend you do subscribe to Optech as I will be stealing things from them from time to time.
I plan to release these every other Monday so please subscribe if you want to stay up to date on all things Ben's Bytes.
Taproot recently happened so this is gonna be a huge dump of things that are happening because of it!
Taproot is one of the latest developments in Bitcoin. Being a decentralized protocol, we don't have lots of things that are ready for it yet. Most wallets have not yet implemented support for it and second layer protocols (Lightning, DLCs) are just starting to talk about how to use Taproot in the respective protocols.
One of the major things that Taproot allows us to do is MuSig. MuSig is enabled by Schnorr signatures and lets us make multi-sig look like a normal single sig output. This has huge block space savings and privacy implications. One of the first steps needed for this is getting the actual cryptographic functions implemented. This was merged
recently! This is in the secp256k1-zkp library which is the sister of the normal secp256k1 library. It has fancier stuff in it like MuSig among other things (eg adaptor signatures). I have heard that MuSig will be eventually ported to the secp256k1 library once it is more standardized. However, if someone is using secp256k1 it will be trivial to switch to secp256k1-zkp if they want to use MuSig. I am hoping we can start seeing libraries hook into this and see real MuSig adoption.
MuSig actually doesn't do what a lot of people expect it to do. Normally when people talk about multi-sig in Bitcoin they are referring to a signature threshold for m-of-n keys (ie 2-of-3). In cryptography this isn't actually the correct terminology; normally multi-sig means a m-of-m (ie 3-of-3) share of keys. This isn't as useful for Bitcoin because people typically use multi-sig to add redundancy. What most people use is normally referred to as a threshold. MuSig can't do thresholds, but luckily there is something called FROST. FROST lets us do MuSig like things but for a threshold of signers. This is hugely important as otherwise we need to use a script to get a threshold of signers with MuSig, and this wouldn't give us all the fancy block space and privacy savings that we want. So shout out to Jesse Posner who is working on an implementation for FROST. This is still heavily a work in progress, but I am glad someone is pushing it forward. Last I heard, there is still no formal proof that FROST is truly secure, so hopefully an implementation will help drive that work. Don't be scared though, proving its security is mostly against other signers, the core of it, schnorr signatures, do have a security proof.
Bitcoin Core does some things for activated soft forks that you might not expect. There are two PRs to Core that alter whether to validate the Taproot consensus rules.
The first is to always treat Taproot as active for the mempool policy.
Before this PR, Taproot was considered activated the block before activation (so you could broadcast Taproot transactions for the actual activation block). Changing it to always active shouldn't be a concern. To deactivate Taproot is basically impossible now, and if you were able to pull off such a large reorg, it is just the mempool policy.
The second PR is making Taproot active whenever segwit is active for the actual consensus rules. From the PR description it says:
Now that Taproot is active, it makes sense to enforce its rules on all blocks, even historic ones, regardless of the deployment status.
Intuitively this might sound incorrect, but it is actually pretty standard practice in Core. This is done because like the policy PR, it is near impossible to deactivate the soft fork now, so we can just enforce the rules on the previous blocks and not need to be constantly checking if it is activated or not. The only caveat is that there are some actual Taproot transactions prior to activation that are invalid under the Taproot rules. You can see that MarcoFalke adds an exception for the block this happens in so nodes can still sync:
I found one block which fails verification with the flags applied, so I added a TaprootException, similar to the BIP16Exception.
I've always found it interesting how Core handles these things as technically it is not enforcing the rules as people would expect; it takes some assumptions (that there won't be a one-year block reorg) to make the code more maintainable, which is a very good tradeoff in my opinion.
Funnily enough, the centralized network, Liquid, had a harder time activating Taproot than Bitcoin. I am guessing this is because there isn't as big of an economic incentive to activate because of how block production works for Liquid.
However, Liquid did activate Taproot plus some other neat opcodes.
I don't fully understand the implications of all the stuff Liquid did on top of Taproot, but it's advertised as a way to bring about "covenants, AMMs, and other exciting use cases", which I think is pretty damn cool. These are things that aren't as heavily researched in Bitcoin and hopefully people can trial-run some things on there. If legitimate use-cases are found, maybe we can eventually bring it to mainnet Bitcoin.
There were some oopsies that happened with Taproot.
No, there aren't any critical consensus bugs that we know of, but there was a bug found in bitcoin-s that led to people finding errors in other projects as well.
Chris Stewart outlined how he found the bug in a blog post. He tells how the bitcoin-s node could not sync block 718448 because it was failing to read one of the outputs. The problem was this was a witness v1 output, but the 32 byte public key in the output was not actually a valid schnorr public key. This caused bitcoin-s to fail to parse to the output because it was enforcing that the public key in the output must be valid.
Sadly, the person that sent these funds did in fact burn them because Taproot defines that the 32 byte key must be valid in order to spend it. It is a shame because it's possible the sender believed this was a valid Taproot address. It was later found that Bitcoin Core's address validator marked this address as valid.
theStack created a PR to try and make these kind of outputs non-standard, so if it happened again the transaction would not be relayed by nodes. In the pull request, Pieter Wuille actually gave a NACK for this saying it should be the last thing done after a lot of other work is completed first, which makes sense.
If this was made non-standard without lots of prior notice, other libraries make the same mistake and try to send to these addresses and the transaction won't be able to be relayed. This might sound like the desired outcome, but it can become a DoS vector for something like an exchange that does batched withdrawals. A malicious user could withdraw the minimum amount to an invalid Taproot address and cause the entire batch withdrawal to not go through. This can have serious implications if the exchange doesn't handle this properly (and it is hard to handle this case properly).
Hope you enjoyed the first iteration of Ben's Bytes. Feel free to reach out to me by replying to this email or messaging me on any platform if you have any comments or questions. I love talking about this stuff, so don't hesitate to ask!
A friend told me to try out Pharmacy Burger saying it was the best burger he had ever had. I got the White Oak BaconBurger. It was a good burger but nothing to write home about. I'd give it a solid 7.2/10, I'm not quite sure what my friend was thinking. I won't be taking restaurant recommendations from him anymore.
Favorite Thing This Week
One of my friends bought me this mug. I love it.