Austin Bitcoin Developers
Socratic Seminar 27
https://austinbitdevs.com/2022-04-21-socratic-seminar-27
Alright, we're about to start. Please find your seats. There's a lot going on in bitcoin, and we have to get through all of it before we get to BBQ. Manny of us were also in Miami and many of you are traveling from out of town, but this is the bitcoin conference. All three letters, THE. It's also the bitcoin capital of the world.
We'd like to get a show of hands, how many of you in this room is this your first ever bitcoin socratic seminar? Alright. Wow. That's amazing. How many people came from out of town and are not from Austin? In the past 6 months, who moved here to Texas or in the process of moving? Great. Justin Moon started this meetup 4 years ago now, with like 5 people in the public library. No, 3 people? I don't remember. One guy was lost. When I moved to Austin about 3 years ago, and the meetup had 15-20 people and it was just cool to see... people would drive from Houston, Dallas, San Antonio to just hang out and talk bitcoin in Austin. We kept growing and we became the only in person meetup in the world for bitcoin and then everyone from all over the world is coming here. It's a lot of fun. Glad to have you here.
For those of you who have not done a socratic seminar, normally socratic seminars are a little bit smaller. The idea is to foster conversation. This is a space for ideas where want to discuss ideas, understand things better, challenge ideas. It's not as simple as people make it out to be in the bitcoin space. A lot of complex topics going on. There might be someone else in the audience with the same question. Also challenge the ideas, that's what makes bitcoin anti-fragile. If we just assume that the experts are going to solve this, then we're all doomed. The hosts are not the experts; we are facilitators. We draw knowledge out of the crowd. The crowd is where the intelligence is here. If you'd like to add something, raise your hand and add it. We have a roaming mic.
Announcements
There's a conference coming up this week. I'm a partner with the beef initiative... we're goirng to talk about our conference and what we're doing this weekend. It's been a real pleasure for me because through this introduction into the bitcoin community, I can change my business model by just being a rancher and fully integrate my entire process. Not only do I raise all of my own beef, but in 5 weeks I'm going to open a USDA processing plant. With that, a few years ago I had this crazy vision: there's so many middle guys touching the food that gets to your plate. I don't want my ass handed to me and they are taking my earnings away. Just before COVID hit, I was on the commercial side of the cattle business which means I'm selling all these corporate guys.... I'm at the mercy of what they tell me my product is worth, and the consumer pays a heavy price, and I get screwed. Bitcoin was the perfect mesh for me. It encouraged me to fully integrate. I started a cattle company, I have a ranch in Austin, I work with developers buying land, I get AG exemptions, I raise cattle on it. I decided to take this a step forward and do our own distribution. If you order from us, we ship directly to your door, and I serve 20 restaurants in the Austin metro plex. I raise the animals, process them, and distribute the meat to your family. With that, we had this vision and dream and it all aligned with what Texas Slim is doing. I'll let him talk about the conference this weekend and how we integrate bitcoin into a broader spectrum.
Hey guys. Everyone in this room, raise your hand if you know who produced your food today. Alright. When I got into this, I was in food intelligence, and it led to the beef initiative. A lot of the other ranchers across the United States, we find corruption and manipulation of our food, the over-processed sludge that a lot of us are consuming on a daily basis and we don't have market access to anything else. It's by design and happened over the last 50 years, like because of giant corps like Tyson and others. 85% of your food comes from that list of companies right there. We don't eat food unless it's approved by a chemical company. The corruption is vast. There's a rabbit hole here of food. The way out is bitcoin and decentralization. This is an opportunity for us to understand that we're going to bring new market access that is decentralized to pure animal protein, starting here in Austin, Texas, and starting in Texas. We will have four national conferences this year. The first one is Saturday. We're kicking this off. At the end of the year, we're going to be a health initiative for US ranchers and they will be leading a health initiative and it will be led by bitcoiners who understand a new sound monetary system. It's going to be people like everyone in this room who are intentional and we understand what's going on in the world. Without sound money, you don't have nutrition. It's coming fast and furious. The more our dollar gets de-based, then the food gets de-based along with it. The conference is going to be educational. There's a good chance that it will be livestreamed; if you want to go, see beefinitiative.com and we're selling beef that you can purchase with bitcoin or fiat.
Most of you are probably wondering what you're trying.. this is a cut called the terris major. It's one of the cheapest cuts on the cow. Our chef is a master on the pit and smoking. We'll hang around; we have a lot of cuts if you want to do a taste test. With raw steaks and different things, if you want to buy that, you can take it home. We're going to start doing catering for events and you'll be able to pay with bitcoin. Drop by and meet our chef. Thank you again.
Do you want a job in bitcoin? Check out bitcoiner jobs. If you're running a bitcoin company and you're looking to hire, raise your hands. Anyone looking for a job, see who has their hands up.
There's so much going on in bitcoin in Austin. The next announcement is from Christopher Calicott about the Texas Work Group on Blockchain Matters. We're doing some work on policy for Texas that is pro-bitcoin. We passed the bitcoin bill; the lt governor appointed me to this working group. Pardon the name, we're working on that. Sometime in January I mentioned there would be an opportunity to come and testify at the state capital, and I'm going to tell you when to do that. If you're creating jobs and economic impact in the State of Texas, or if you're a bitcoiner and you would like to say why bitcoin is where Texas has an outsized opportunity to lose, then we need as many bitcoiners to show up and testify that day. If you're an early riser, it's even better. May 20th, which is a Friday, starting at 9am. The trick is that we want bitcoiners to always be educated and prepared. Show up at 830, and there's kiosks where you register to make sure you get your 2-3 minutes at a minimum to speak that it's important that bitcoin is focused on by Texas. On this committee, there are people still talking about enterprise blockchain and we need the bitcoin voice to be heard loud. Have you ever testified at the state capital before? If that seems intimidating, it's not. Show up 830am, register on a kiosk on Friday May 20th. The day after the next bitdevs.
Sidd is going to bitcoin meetups on a motorcycle. The impetus behind this trip is that, I've been out of the country for 2 years, and I wanted to come back and meet people from bitcoin twitter and meet all these people who I share values with. I wanted to hear stories from people with very different backgrounds- ranching, finance, and people who wouldn't have otherwise talked but thanks to bitcoin. I'm working with Unchained, Swan Bitcoin, Bitcoin Magazine, and Upstream Data to put these stories into a video series so that you and your family can hear why the plumber in Ohio started buying bitcoin and why it makes sense to them, pull out the analogies and experiences between different ways of life and bitcoin ethos. I brought the saddle bag from the bike, if you want to sign it, I'm taking it to each meetup. I'll raffle off hat #4 of the series, I only have 21 of them.
There's a new addition to the Austin meetup scene. Ben Woosley will be hosting a lightning developers meetup. I ran the lightning developers meetup in the Bay Area, and now I moved here. There's much to learn. It will be monthly, hosted by myself and Lisa Neigut. I look forward to it. Join us on meetup.com. The first one will be on May 11th.
Next we have a conference coming up for developers called bitcoin++. This is what I love about bitcoin, it's such a big tent with so many skills and interests. I am representing base58 here; I am hosting a 4-day technical bitcoin conference to frontrun Consensus 2022. The first two days will be Tuesday, Wednesday June 7-8th with talks and workshops. There will be speakers here in the audience that will be speaking at the unconference, and then a hackathon at the backend of it hosted by Plebfi and Bitcoin Commons on the last 2 days.
We need a little help next month. We have a github issue page here. Next month, post anything you find interesting and we want to draw some interesting topics from the crowd. Hope we can get a whole bunch new content for next month. It'd be cool if someone in the community accomplishes something, just stick it in here and we'll do a shout out.
Chatham House rules: don't attribute statements to who said it. You should be free to speak your mind, as free as you can be with 200 people in the room. No video or pictures. We don't know who doesn't want their picture out there on the internet...
I'm running "The Bitcoin Company". I was working at Visa a few years ago. It fucking sucked ass, they hate bitcoin. I really like bitcoin and I wanted to do some bitcoin shit. So I tried to start a 501c3 charity to help bitcoin developers to sustain the ecosystem that funds itself. If you don't know, weirdly a lot of people don't, bitcoin is maintained by volunteers who are mostly not paid except for a handful of grants. The smartest people in the world leave to go work at Facebook and Visa. We need to support the people that continue to build on top of bitcoin, not just developers but researchers and designers and everyone. Opensats was approved for 501c3 status, it's supporting all free and open-source contributors. It's live now. Just like HRF, Brink, MIT DCI, those are great initiatives; I got really annoyed that they don't give everything back, and charities in general take a lot off the top. For opensats, you come in and donate to the general fund and then there's a group of people that will try our best to allocate the funds. We also have a bunch of individual projects that you can specifically earmark your donation for. You can donate in bitcoin or in fiat, if you donate in fiat then we're incidentally going to buy bitcoin because fuck fiat. We only distribute money in bitcoin. Instead of paying your taxes, come here and pay bitcoin contributors. If you want a tax write-off, we will send you a receipt. We need someone to run the organization. We have a little over 1 bitcoin for someone to do grants and manage it. Please talk with me if you're interested.
Security
We're going to start with a few infosec topics. There was a Google Chrome 0day where someone found an exploit in Chrome that would let you put any javascript in someone's browser. They were using this to hack Metamask which is a shitcoin wallet. Make sure you update your browsers. Safari is not Chromium, no.
Java 15 through 18 has a bad vulnerability where they reimplemented the ECDSA signature checks, and they forgot to check that a value is not zero because if you multiply by zero it makes everything valid. They weren't checking that the nonces were zero, so you can feed it arbitrary signatures. Thankfully, the java ecosystem doesn't use anything past java 11, so not too many things were effected. Java 15 came out a while ago, and things could have been broken.... The broader implication is that, one, it's mentioned in this twitter thread, don't write your own crypto because it's hard and dangerous and it's very important work. If you re-implement something, there's risk for bugs to come in. Risks with doing something in crypto can also be with using it wrong or using it when you don't need to, and it can introduce a false sense of security and other vulnerabilities. One of the points in this twitter thread was that not only was it implemented incorrectly, but it was used in a place that didn't need it. Even if you're using a trusted crypto library, there's still the risk that you are not using it correctly. Most people are using libsecp or bouncy castle, so basically everything was safe in the bitcoin world. It's interesting to see these things happening in the broader software ecosystem.
Who here has reviewed java's crypto libraries?
Miniscript is a tool that makes it easier to work with bitcoin's script language for contracts to lock a bitcoin. If you want to express something more complicated, it's difficult to write it out by hand. Miniscript is a tool that makes it easier. Andrew Poelstra published a security advisory where, in rust-miniscript... this is the one that is used. Miniscript is used by BDK, and BDK is used in Foundation Wallet, Sensei Lightning node implementation... so there was one way that you could construct one of these contracts that was basically anyone can spend it I think. It was very specific and they did an analysis to check if it happened yet, and it hadn't, so nobody lost money to this. It talks to the danger of having many layers of abstractions to make it simpler to work with bitcoin. Every one of these layers could have something going wrong. Any thoughts on this one?
I might be one of the largest users of miniscript at this point, so for me this was very scary. In general one of the things making me re-evaluate is that I wanted to use miniscript as a compiler or do I only want to use it as a verifier for scripts written by hand? There's both a compilation path, but also a verification path. If you solve it by hand, you might see that something was off.
The risk of extra layers of abstraction... when you reimplement something, that's where bugs can be introduced. We often take it for granted that bitcoin just works, but it's really early and there's a lot of things that bitcoin is going to need to be able to do. If we don't create the right tooling and do the right review process, then people will build things anyway and it's best that those things are built correctly, have more eyes, get more reviewers, more accountability.
If I remember correclty, when they came out with miniscript they were saying that we're 99.99% sure that this particular subset of the script was safe, so they just happened to find one of the edge cases that was not safe? The issue is that bitcoin has consensus rules, and also policy rules. When they were checking was what would be policy-wise invalid, and this bug is not something that an average user could exploit, a miner would have to be involved. Policy is just the commonly enforced rules for whether something can get into the mempool, for example, like transactions aren't allowed to be more than 100 kb in size, but blocks can have transactions bigger than 100 kb. For consensus rules, that's interpreted and evaluated at the time that a block is processed. If you treat a policy like a consensus rule, then you might be insecure because it might pass policy but be consensus-stealable.
MuSig2
There is now a draft BIP for MuSig2. MuSig lets you hide that you're doing multisig. You do it off-chain with fancy cryptography where you end up with a single public key.
What's the difference between multisig and threshold signatures? This only allows k-of-k multisig. You can't do k-of-n. FROST lets you do it. There's a draft BIP for MuSig2.... it has some nice properties. The one downside is that when you go to redeem the 3-of-5 and exercise these paths, you leak more information about your setup. The idea of MuSig2 is that multisig looks like single sig, so everything looks the same on-chain. But with 3-of-5, when you do a spend, then it won't look like that anymore.
Multisig in a taproot world is not how we thought about it before now. Multisig before now was OP_CHECKMULTISIG and you could do these thresholds. Multisig is now the technical understanding interepretation is multiple keys but not threshold. If you're going to do multisig as we have understood up until now, it's not private. Taproot adds more privacy, but not if you do the threshold revelation by revealing certain paths. But the k-of-k looks like a single sig signature which is worth it. In lightning, those are 2-of-2 and you get benefits from a cooperative close.
MuSig2 is not a consensus change. It's a protocol. If you do this naively, you can have your money stolen. You could setup a linear equation to setup this and subtract a private key, so they setup a crytpographic procedure to protect against this. The first version of multisig had like 3 rounds of communication. This was a research project, and now it's moving to a BIP. Also, lnd is working on implementing it. A lightning channel could have a multisig output using MuSig2 that hides a little bit about what's going on there in the output. There's a 50 page paper where they did a security proof under some assumption. This was a sticking point before it was implemented.... we needed Schnorr signatures, which lets you do signature aggregation. Once we had that, we didn't have a formal proof about how to do that protocol securely because there are these interactions that are required. Before anyone implemented it, we wanted proofs, and now we have that. The protocol is for how do you exchange this information.
FROST formal specification
There's a draft document on IETF about FROST which is a more complex thing to let you do 3-of-5 in a single signature because you can't just add everything together; so they do a shamir secret sharing of signatures which is really complex. It's not a total security proof.
Multisig was hard before we had PSBT because if you're not doing multisig with just yourself, you need a way to coordinate the signatures between people. To have to coordinate it, and doing multiple rounds or too many rounds it becomes infeasible for a customer to do that because of the amount of coordination required.
There is a security proof for FROST in the paper. Just like for MuSig2.
The pain around coordination is that the .... the challenge is that you need to have users exchange nonces as part of the signature aggregation process. You need people logging in and out to get that information collected. MuSig2 simplifies the number of rounds; FROST is more complex but enables some cool threshold signatures. It's particularly bad if you're geographically distributed... imagine having to travel to different cities to get your keys, and then having to go back just to continue completing the same transaction.
This is almost a layer two protocol in a sense, to construct a schnorr signature. It's separate from bitcoin but usable on bitcoin. Is it true that instead of two rounds you can do some preparation to do one round? It's like one and a half round where you pre-generate a million of these commitments, store them, and then when you sign you just say ok we're using commitment 17. It's true with MuSig2 but.... but they talk about commitments here, not just nonces, so I don't know what the commitment is committing to. There's a third proposal, for MuSig not for FROST... for MuSig there's deterministic nonce where you can avoid the coordination because the nonce generation is deterministic and everyone would know what would be generated based off of certain criteria, but it's less secure and more computationally expensive.
The 2-of-2 multisigs that would be used in DLCs or lightning, they are getting close to where we can move it over to the taproot native version with MuSig2. But you won't be doing your 3-of-5 cold storage in taproot; you can mock it where... most spends from Unchained, and I think we have a post about this.. the other thing that we have to worry about is the interaction with hardware devices so we need hardware device support. One of the things we're thinking about is that if there is MuSig support, then in most spending cases, we have 2-3 vaults... users are going to be spending with their own 2 keys so you can do that as a MuSig keypath spend, and then to mimic the 2-of-3 then in the scriptpath spend, you would have the CHECKSIG checks happen and it would still be 2-of-2 but you have different paths to 2-of-2. Once we have hardware support for MuSig2, it will be possible to do this. We don't need to wait for FROST which is nice. If you don't do the common spend which would be the 2-of-2, then it wouldn't be private, and it would be more in fees because you have to reveal the path. That's only for an emergency though where you lost a key, and it's still less fees than today.
Taro
MuSig and FROST are both kind of new applications or protocols built on top of the taproot upgrade. A couple weeks ago, Lightning Labs announced a new protocol built on top of taproot. TARO stands for taproot asset representation overlay. It uses a new data structure that taproot introduced called a merkleized abstract syntax tree (MAST) which is just a tree of spending conditions. What Taro does is that it uses that same tree structure where instead of embedding spending instructions in the UTXO, you add commitments to arbitrary off-chain data to represents assets like stablecoins or beefbucks.
Why do we need taproot for this? What are the costs that we needed taproot for? The most important thing is that Taro is an overlay network just like lightning is. Normal bitcoin fullnode operators can continue to operate and have no idea that Taro exists at all, it doesn't increase the burden on bitcoin operators.
The double spend protection is on bitcoin because everything is anchored to a bitcoin UTXO. So you get double spending protection for free by using bitcoin here.
Say we want to represent a dollar in this system.. how is the asset created and how is it transferred? We use a merkle sum sparse merkle tree. A difficult thing to do is a proof of non-inclusion. Merkle trees do provide for efficient proofs of inclusion, though.
I want to understand some of the more adversarial aspects to Taro. What is issuance tied to? Is it channel open? It's totally off-chain. You are fundamentally trusting the issuer. There's some possible stuff with programmatic issuance that could happen with covenants. But right now you're trusting the issuer. You could show that your private key is the only one controlling the output, but that's it. You're trusting some arbitrary issuer off-chain thing to value these assets.
The Taro Universe component is the set of all the genesis outpoints for issuance. You need at minimum the initial genesis outpoint to be logged somewhere. What a Taro Universe is, it's kind of like a sidechain but it's just a UTXO owned by the issuer where each time they issue an output, they commit into that outpoint the new genesis outpoint information. The other thing is that you want proof of non-inflation, where there is a leaf amount called a sum associated with that leaf and you can prove the supply. The data doesn't live on the chain, but you can commit that. It's part of the merkle root.
There's a linear growth in the size of the Taro transactions. Ruben Somsen brought this up on the mailing list. For bitcoin, figuring out provenance is difficult because it might have 3 ancestors 1 hop back, 10 ancestors 2 hops back, and then 500 ancestors just 5 hops back. If you have a lot of transfers on taro, the size of the metadata grows very quickly. For the size problem, because to be clear about the trust model- these assets are all trusted and you have to trust the issuer to redeem them.... so the issuer can take your heavy dollar bill with all the signatures, send it to us, we will burn it and issue an equivalent one that doesn't have the history attached to it.
This is a protocol to do what the Strike app does, basically. Bitcoin is necessary for this because each of these when you're changing the state and someone is sending 10 bucks, that's still, to change that state you still need to pay for the state change in bitcoin because you're moving from one utxo to another utxo. The miner processes the state change of that utxo transfer and those fees need to be paid in bitcoin. The processing of these state changes happens at the bitcoin layer, which means it's backed by proof-of-work and all the state changes can be managed outside. All the processing is moved out to the users, the bitcoin network doesn't need to be dealing with this. The nodes only really care about the base layer. My understanding is that this was a big design goal for Taro.
If this is operating on lightning, does every link in the chain transferring from A to .... do they all need to understand taro? No, only the sender and the receiver.
Decentralized identifiers
There's a problem with payment protocols and all the various ways to pay someone, like bitcoin addresses which you shouldn't reuse. There's BOLT11, BOLT12, lnurl... there's this decentralized identifier stuff, like Microsoft Ion, a way to do identity stuff on top of bitcoin. When there's too many standards, you create a new standard. We abstracted payment protocols so that you could list all the different payment protocols you're willing to support, maybe you have multiple lightning nodes, maybe you delegate a custodian like Strike or something... What does it mean to pay a person on the internet?
Silent payments
Last month, supertestnet talked about his protocol called whisper addresses. Ruben Somsen in response released this silent payments proposal which is... bitcoin has this problem where if I want to post an address, and if I post it, then I have address reuse and it's bad privacy and it might be blacklisted at some point. Negotiating an address is hard because both users need to be online. But it would be better to just put something on the profile and leave it forever.
Silent payments would be where you tweak addresses in a way where unbenknowst to the user, they would have to do some re-scanning to find it. You need to do a lot of re-scanning and doing all this computation against the UTXO set to try to find your UTXOs. Someone made an implementation of this for Bitcoin Core. It's interesting to see people working on address reuse privacy problems in bitcoin.
bip119: OP_CHECKTEMPLATEVERIFY (CTV)
Jeremy, do you want to share some thoughts about your blog post here? There's a lot of discussion around this. There's some technical considerations involved like how should we be activating and signalling for soft-forks involved in this proposal, and then there's also some not quite politics but how do you do open-source development in a decentralized setting? There's some interesting aspects of this proposal and some of the arguments and debates around this that highlight this is a difficult problem. We could solve these issues if we had a supreme leader who would just make a decision. The result is chaos. I think chaos is good and is reflective of a healthy, vibrant community with a lot of different ideas. The way to resolve disagreements in a decentralized community is by making posts like this.
When is a proposal ready? how do we determine if something has been reviewed enough or if it's secure? Does enough of a community want a feature? How do you measure something like that? There's a question of literally technically how can we determine that? Jeremy has been putting forward a proposal that one of the ways we do that is by putting code out and seeing if people run it because that's really the only way to see what people want. It's an interesting thing about measuring readiness, measuring level of review, I participated in a bitcoin developer mailing list thread recently where they were asking was taproot even reviewed enough? Some prominent core developers were saying it probably wasn't. Maybe CTV is raising the bar for the level required, but we don't have a good way to measure it right now.
The post is a meditation on what the jobs are in this. Jeremy is saying my job is to write code and put it out there. So this post is introducing an activation period using Speedy Trial starting in 2 weeks and he says that's his job, that's where it stops, and it's up to everyone else whether they want to run the software. He talks about his experience trying to figure out what does it take to merge his code into Bitcoin Core? He didn't get a clear answer. That's kind of by design, core developers don't want to abuse their position. There are people who review, and then there are people with merge permissions, and there's currently 4 people who determine what code goes into Bitcoin Core.... there's 5 today. Wladimir posted about how he wants to step down; if there's anything that gives the appearance of politics in some of these things... like someone not merging it, it doesn't mean it's not accepted, ... we want to be anti-fragile.
I think it's interesting that if Bitcoin Core merges something, then that's what we would all run. If Bitcoin Core refused to merge something, then we would also refuse to run that thing.
I don't want to bore people or get too political. There's this notion and I've been talking on twitter- what is technical consensus? There's a few different things to keep in mind. What is technical consensus? What is product consensus? What is technical preference? What is technical consensus? Preference is that if you were the dictator of Bitcoin Core, then what would you implement? If you had a gigachad brain, maybe you would write the correct code straight away. Once consensus gets involved, is there an equilibrium where nobody is...... one thing I ask is that if CTV gets merged, then would you sell all your bitcoin? If you're not at that point, then maybe it's not that offensive to you. That's a bright line. People felt that way about big blocks, too. Taproot got merged in long before it was activated; it's possible that we would have had taproot code in core that would never have been activated.
In Jan13 in bitcoin-core-dev where I ask the maintainers, I asked here is how I would maintain the patch set and I would prefer that it is merged, but I could maintain it as a separate patchset and I would be happy to do that which could later be brought into core as a backport. If it's too difficult to talk about it with something that has been proposed, then talk about OP_FOOBAR or something instead. The maintainers in this meeting, I got no response. Just tell me, if I even think like the minimal thing of discussion... I think Core as a project is moving to a regime where the maintainers of it really want to be so far removed from any sort of political seeming decision that even weighing in on how a patchset is maintained for proposed consensus upgrades is outside the wheelhouse of what they want to weigh in on. I'm trying to navigate that complexity. The final point is that people are feeling anxious; nobody should lose sleep. The most likely result is that if a lot of people don't want it, it will fail. It won't end bitcoin as we know it. It's a process, and does not represent some final thing where if you don't go nuts tomorrow then everything breaks. I am eager to get feedback from everyone and incorporate that into my work.
There's a bug bounty program and then a URSF... and there's a python code if someone was willing to do that, it looks like you put everything out there to explore whatever decision they feel based on this post. If you find a big problem, you could claim all 5 BTC. If you find a moderate issue, it's like 1 BTC or 0.25 BTC... but if you do a strong review where you detail all the tests you ran and how you reviewed it, then there's a bounty for that as well. This is going to be part of a Lincoln 501c3 organization where this would be a permanent system for creating these bip-bounties for whatever purposes people want, so maybe in the future this is how we can do community funded way to do bug bounties. I might fall into the camp that taproot has not been reviewed enough... With 40 lines of python, you can configure Bitcoin Core to reject any bit version signaling that you don't write. I wrote it because Jorge Timon told me it had to be done because I had my "secret" "agenda" or something.
Pricing liquidity for lightning wallets
We have about 5 minutes left. Let's move on to a nice little topic here on "Pricing liquidity for lightning wallets".