@ ARVIN

**ORIGINAL PANEL TITLE:** MAKING BITCOIN MORE PRIVATE WITH CISA **SPEAKERS:** NIFTY NEI, CRAIG RAW, FABIAN JAHR, JAMESON LOPP **CONFERENCE:** BITCOIN NASHVILLE 2024 **ORIGINALLY PUBLISHED ON:** BITLYRICS.CO ## Introduction This edited transcription comes from a panel titled “Making Bitcoin More Private With CISA”, featuring an insightful discussion on cross-input signature aggregation ( [CISA](https://cisaresearch.org/faq)). Moderated by NiftyNei from [Base58](https://base58.info/), the panel includes Jameson Lopp from [Casa](https://casa.io/), Craig Raw from [Sparrow Wallet](https://sparrowwallet.com/), and Fabian Jahr from [Brink](https://brink.dev/). Recorded at the Bitcoin – Nashville 2024 conference, the panel explores how a Bitcoin CISA soft fork can enhance privacy and efficiency in Bitcoin transactions by aggregating signatures. The speakers share their personal experiences with CISA, its potential economic incentives, and the technical challenges it faces, while offering a clear explanation of its role in privacy-focused Bitcoin development. --- ### NiftyNei (Moderator): Hey everyone, my name is Nifty, and I’m going to be moderating this panel today. We’re here to talk about CISA (cross-input signature aggregation). Joining me today on the stage, I have Jameson Lopp from Casa, Craig Raw of Sparrow Wallet, and Fabian Jahr of Brink. So, welcome them to the stage. We’re excited to be talking to you guys about this. I think it’d be great to maybe start off by hearing a little bit more about who’s on our panel today. If the panelists could tell the audience about the project they’re working on and where they first heard about CISA. Craig, do you want to start? --- ### Craig Raw (Sparrow Wallet): I built Sparrow Wallet. It’s a security and privacy-focused wallet. The first time I heard about CISA was really from other privacy activists in the Bitcoin space who were talking about how they were really hoping that this cross-input signature aggregation would be shipped as part of the Taproot upgrade. Obviously, we know that didn’t happen. When you’re looking at things from a privacy point of view, you want to do things like create multi-party transactions, and as we’ll hear, cross-input signature aggregation provides an interesting basis for being able to do that more economically. So, that was the first time I really started to look at it from the privacy angle. --- ### Fabian Jahr (Brink): I primarily work on Bitcoin Core, and I can’t really remember a specific time when I first heard about it. Between the SegWit soft fork and the Taproot soft fork was when I really got deeper into Bitcoin and started contributing to Bitcoin Core. Somehow, CISA was always there, but I only started researching it and going deeper into it over the last couple of months. I saw that it was a topic brought up for the Taproot soft fork but was cut at some point to keep the scope smaller. I forgot about it for a year or two until it kept popping up in privacy discussions, as Craig mentioned, which triggered me to look deeper into it. --- ### Jameson Lopp (Casa): I’m Jameson Lopp. I work at Casa, where we help people with highly distributed, secure, multi-signature self-custody setups. I think the first time I heard about CISA was in an Andrew Poelstra talk. I mostly remember being blown away by the vision he painted of a future where we were all financially incentivized to participate in CoinJoin transactions for everything we transacted. This would break a lot of the potential for chain surveillance because, if we’re all honest, Bitcoin has pretty poor privacy characteristics. --- ### NiftyNei (Moderator): That’s a great point. Okay, so I think now that we’ve had an intro into how each of you came to hear about it, and maybe some of the things you thought were important or cool when you first heard about it, maybe we could take a little bit of time to explain a little bit more about what CISA is and what those letters stand for. Does anyone have a good explanation of how it works? --- ### Fabian Jahr (Brink): I can start off. So, it’s really already all in the name: cross-input signature aggregation. If you think of a Bitcoin transaction as it looks today, you have, sometimes, one but often multiple inputs, and with each input, usually, a signature is associated. What the linearity property of Schnorr signatures allows you to do is to aggregate these signatures. You can aggregate them across the different inputs that you have in a transaction. So, that means that in the future, we could have transactions with multiple inputs—if you think specifically about transactions that have a lot of inputs, like CoinJoins, for example, as we just mentioned—these could have just one signature. And depending on what technique you use, these can be just as big as one single signature before. Of course, that saves a lot of space, both on-chain and also in terms of the fees, because you take up less space in a block. That is the general idea. --- ### NiftyNei (Moderator): I have a quick question about that. So, whenever you say you can do cross-input signature aggregation on a transaction, usually, you’ll have a couple of things called inputs, and each of those inputs will have a signature on it, right? So, the general idea is that, on that same one signature, instead of having a couple of them, you’d be able to roll them all up and just have a single signature. Is that a good summary of what you’re explaining? --- ### Fabian Jahr (Brink): Yeah, I would say so. --- ### Craig Raw (Sparrow Wallet): So, there are two major ways to do this. One is what we call a half-signature aggregation, or half-SIG, as we abbreviate it. That’s where you don’t need an interactive process. Anybody can take all of the signatures that appear currently for every input in a transaction, and they can aggregate them into one. Now, the size of that one is unfortunately not the size of a normal signature—it’s slightly bigger. In fact, the size is determined by the number of inputs that you have. So, that’s one way to do it. Then there’s a more comprehensive way to do it, which is called full-signature aggregation. That gets you a much more compact signature, which is the aggregate of all the other ones. Unfortunately, the downside of that is that you have to do the interaction while you sign. The problem with that is that interaction always contains a lot of complexity, so unless you own all of the inputs, you are going to have to interact with everyone else who’s adding an input to that transaction, and that creates a much more difficult process in terms of signing. As a result, I personally am more excited about the kind of half-signature aggregation because it’s just so much easier to do and gets you a lot of the benefits, even though it’s not quite as efficient. --- ### NiftyNei (Moderator): Cool, so it sounds like we’re taking signature data, and it’s all the same signature data in a single transaction, right? You wouldn’t have multiple transactions that you’re doing—it’s like on a single transaction level? --- ### Jameson Lopp (Casa): Well, there’s also full-block aggregation, right? This is going really far down the rabbit hole, and I think it’s not even something that’s on the table. There are too many additional edge cases that come up, especially when you start thinking about blockchain reorganizations. My understanding is you would have to have this other mempool to keep track of things that weren’t sufficiently buried enough in the blockchain that they could be reorganized. If there was a reorg, it would not be as simple as how we do reorgs right now, where we just take every transaction out, put it back into the mempool, and start over again. --- ### NiftyNei (Moderator): So, it sounds like you’re saying there are a couple of different ways we could do signature aggregation. We could do it at the transaction level, and there’s a proposal to do it at the block level, but again, there are some trade-offs there. One of the nice things about taking signature aggregation at the block level is that you take all the signatures in any transaction inside a block, and you create maybe a single signature object, right? Maybe it’s not exactly a signature, but something similar to that. What is one reason you’d want to do this? It sounds complicated. --- ### Jameson Lopp (Casa): Well, there are the privacy characteristic improvements, but also, I think it’s interesting when we’re talking about incentivizing people economically. If anyone was around and paying attention in 2016 or 2017, when we were talking about Segregated Witness, there was this concept of a witness discount. It was basically put in place to help rebalance the cost between creating a UTXO and spending a UTXO. You run into problems where, if you’re receiving a lot of transactions, you’re creating a lot of unspent transaction outputs in your wallet. It becomes problematic if, at some point in the far future, you want to go spend them, and perhaps the fee rates in the market for block space have gone up a lot. It can become insanely expensive to spend your own money. This inevitably catches a lot of people by surprise if they haven’t been through a full market cycle before. So, I think this is another interesting aspect of aggregation—we’d be pushing the balance forward a bit to help incentivize people to clean up their UTXOs because we’re not penalizing them as much by making it really expensive to do so. --- ### Fabian Jahr (Brink): And maybe to expand on that, there is a financial incentive for people to participate in CoinJoins, and that gives them additional privacy. The nice effect of that is that hopefully, this would lead to wide adoption of CoinJoin, which means that when more people are CoinJoining, there’s a higher anonymity set that benefits everyone after this anonymity property. Everyone that participates in CoinJoin can also use this as plausible deniability, even if they are doing it primarily for the privacy aspect. They can always say, “Hey, I’m saving fees here, so that’s my primary motivation.” Hopefully, a further trickle-down effect would be that, as people ask for this and it becomes more widely adopted, more and more wallets will adopt it. Easier-to-use wallets, the complexity gets hidden, and it becomes more of a mainstream feature. --- ### Jameson Lopp (Casa): Yeah, we have to think about the incentives, right? I consider myself a cypherpunk; I’m a big privacy advocate. I assume we all are. But the reality of the situation, and this is pessimistic, is that most people don’t care about privacy or they don’t care until it’s too late. We can stand up here and talk about how awesome it is to have really strong privacy and why you should be using all of these niche tools, but if we actually want people to adopt privacy tools, we need to give them the financial incentive to do so. It should not be a situation where the average person has to go out and ask their wallet providers or software developers to bake in additional privacy tools and protections into the software. Really, it should be: why are you making me spend more of my money to use Bitcoin when I could be using this technology that happens to enhance privacy but is actually saving me money? --- ### Craig Raw (Sparrow): So you might be wondering at this stage what the savings actually look like. It turns out that if you apply what I was describing earlier—this half-signature aggregation technique—you can fit about 20% more average-size transactions into a block. You can immediately think that’s going to reduce the average fee level for any point in time when people are submitting transactions to the mempool to be included in a block. You can now fit 20% more average-size transactions into that block, and that’s obviously a big advantage. Now, the actual effect on a particular transaction, because of the witness discount that Jameson mentioned earlier, is less—it’s like 7 to 8%. But remember, the average fee rate is going to be lower because we’re fitting more transactions into a block, which means there’s less pressure on block space. So that’s how I would encourage you to think about it from the start. For me, the efficiency in terms of block space is a good reason to do this anyway, regardless of whether we get privacy benefits. The privacy benefits come along for the ride. We actually have this really restricted data space in the blockchain, and if we can apply a fairly simple and low-risk form of compression, I think it’s a serious thing to think about. --- ### NiftyNei (Moderator): I think, now that we’ve talked about how great this is, we’re going to get more transactions in a block, save money, and get better privacy. I’d be really interested to hear why it didn’t make it into Taproot originally. Was there opposition to this proposal? What was it about the Taproot process where this proposal didn’t make it over the line? --- ### Fabian Jahr (Brink): I wasn’t in the room when this was discussed, but I’ve read all of the transcripts available from when these things were discussed. From what I can see, I don’t think there was any direct opposition. The primary motivator was to keep Taproot manageable in terms of review effort and to keep the scope smaller. I mean, the only thing I can see reading between the lines, which Craig already kind of mentioned, is that if you just look at the pure fee savings numbers and the number of weight units you save, for half aggregation, it’s in the single digits. People are often a bit disappointed as a first reaction, and you have to really discuss it and fill it with understanding. I think that might have turned off some people, and maybe developers felt like this would be the easiest thing, to chop it off and people wouldn’t miss it as much. --- ### Craig Raw (Sparrow): Yeah, so in terms of the pushback I’ve heard so far, it’s what Fabian was saying—it doesn’t do enough. There’s a general perception that we can only push for one soft fork at a time, so all the soft forks have to compete to be “the one.” That’s an interesting point of view. --- ### Jameson Lopp (Casa): It’s interesting because I was in the room in Hong Kong when Pieter Wuille announced that we were changing the flagging system so that we could do 32 soft forks in parallel. Of course, we haven’t taken advantage of that yet. --- ### Craig Raw (Sparrow): Yeah, so we’re in a very different space now. Something to bear in mind if you’re thinking about it from that point of view is that, and I heard Brandon Black, who was here earlier today, talking about OP_CAT, I think CISA is probably the lowest-risk soft fork we could imagine. I’m talking about the well-understood half-signature aggregation form of it. From a security model point of view, the cryptographers tell us there is no risk, or very low risk, to doing this. It takes well-understood properties of Schnorr, which is just adding signatures up, and uses that. So, in terms of risk, it’s not really enabling other things that Bitcoin can do. It’s not going to be groundbreaking—it’s really just compressing. If you think about it, compression is a fairly bounded area. You’re not going to suddenly have people developing all kinds of perhaps unwanted things on top of Bitcoin just because you compressed the signature size down. So, maybe it opens up the space for other soft forks if we do a soft fork with such low risk that it actually gets across the line. --- ### Jameson Lopp (Casa): I think it’s also worth noting that this is by no means the only signature aggregation scheme happening in Bitcoin. With the Taproot soft fork a few years ago, we got the theoretical ability to do Schnorr signatures, but that’s been an ongoing process. As far as I’m aware, there’s been limited adoption of Schnorr so far. I think MuSig2 is the main production-ready standard people are using, but that can only do an “n of n,” like a 2-of-2 or 3-of-3 type of scheme, so it’s kind of limited in its flexibility. I care about this a lot, operating a multi-signature self-custody wallet. We’re waiting for the further evolution of threshold signature schemes like FROST that can do more arbitrary K-of-N type multi-signature. That evolution, that research, is still ongoing. We’re continuing to see new iterations of FROST come out. So, we do expect to see more adoption of aggregated signatures across the ecosystem, but the ultimate end goal would be something where there’s only one signature per block. --- ### NiftyNei (Moderator): So, we only have a few minutes left. Maybe we can spend a little bit of time talking about what it would take to get CISA to the point where we could soft fork it in. --- ### Fabian Jahr (Brink): There are still quite a few things to hammer out in terms of all the details, like defining a spec. For half-signature aggregation, there’s a BIP draft, but it’s not a pull request on the BIP repository—it’s just a draft, with test vectors that are open. However, for full aggregation, we still need to develop the signature scheme. That requires quite a bit of effort from people well-versed in cryptography, specifically on the side of interactivity. We will also want to have a security proof for that scheme. That means we’ll need people with specific talents and experience in that area to come together and work on it. I personally spend quite a bit of time on it right now. --- ### Jameson Lopp (Casa): Yeah, call your local developer and demand signature aggregation today. --- ### Craig Raw (Sparrow): Fabian has developed a great site where you can learn more. If the concepts we’ve talked about here today make sense and you want to understand them better, if you go to [CISAResearch.org](https://cisaresearch.org/), you can learn more about it. It’s very easy to read, not overly technical, and I think it gives a good grounding in these things. Largely, the way soft forks happen is that people need to express views about them, and ultimately, we need to develop some form of rough consensus around whether we want to do it or not. As far as I’m aware, this is the first panel we’ve had that talks about it. Even though it’s an old and simple concept, we don’t really have a lot of discussion about it right now. So, talk about it, try to develop an understanding of what it’s trying to do, and see whether you want to have it in Bitcoin or not. --- ### Jameson Lopp (Casa): I don’t know, do you want to save money? It should be an easy question. --- ### Fabian Jahr (Brink): And have better privacy. --- ### NiftyNei (Moderator): Great! Thanks y’all. --- **Follow the speakers: ** [NiftyNei](https://njump.me/npub1e0z776cpe0gllgktjk54fuzv8pdfxmq6smsmh8xd7t8s7n474n9smk0txy) – [Craig Raw](https://njump.me/npub1hea99yd4xt5tjx8jmjvpfz2g5v7nurdqw7ydwst0ww6vw520prnq6fg9v2) – [Jameson Lopp](https://njump.me/npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp) – [Fabian Jahr](https://github.com/fjahr) **Watch the original content: ** [Click here](https://www.youtube.com/watch?v=HvI7NPI_Pk0&list=PLe0djdakvnFYPDH8_rd4NsABQCODVZ-ru&index=107) **Also read: Build It Right: ** [Achieving Interoperability with Open Networks](https://bitlyrics.co/transcripts/interoperable-businesses-open-networks/) **Disclaimer: ** Transcripts provided on bitlyrics.co represents solely the opinion of the speaker and is not by any means financial/legal advice or an opinion of the website. The content has been transcribed with maximum accuracy. Repetitions and fill words have been amended in order to enhance the reading experience. The full text may not be confirmed by the speaker. Please, refer back to the above-provided source of content for more certainty. If you are a speaker and wish to confirm/amend your speech please [contact us](https://bitlyrics.co/contact/).