So there's one person on the stage here that is not up there. Why? Hi, everyone. My name is Nifty. I'm going to be moderating this panel today. We're here to talk about CISA, I think, cross-input signature aggregation. And 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. Really appreciate it. Great. So we're excited to be talking to you guys about this. I think it'd be great maybe to start off hearing a little bit more about who's on our panel today. So if panelists, you could tell the audience about the project that you're working on and where you first heard about CISA from. That makes sense. So Craig, do you want to start? So 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 was going to be shipped as part of the taproot upgrade. And obviously we know that that didn't happen. So 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 will hear, cross-input signature aggregation really provides an interesting basis for being able to do that with more economic benefits. So that was the first time that I really started to look at it was from the privacy angle. Yeah, I primarily work on Bitcoin Core. And I can't really remember a specific time when I heard about it for the first time. The time between the secrete soft fork and the taproot soft fork was really when I got deeper into Bitcoin and started contributing to Bitcoin Core. And somehow it was always there. And only when I started researching on CISA and going deeper into it over the last couple of months, I saw also that historically it was a topic that was brought up and that was discussed to be part of the taproot soft fork. But then at some point it was cut basically to keep the scope smaller. And so I guess at some point around the time I saw it and then it was removed and I never really paid much mind to it around the time. And when I reviewed the taproot soft fork, it was not in there. So I kind of forgot about it for probably one or two years. But it kept popping up on taproot. Also like Craig said, more privacy-minded people. And that triggered me to look deeper into it. I'm Jameson Lopp. I work on Casa where we help people get into highly distributed, secure, multi-signature, self-custody setups. And I could be misremembering because it's been several years, but I think the first time that I heard about CISA was an Andrew Poelstra talk. And I mostly remember being blown away by the vision that he painted of basically a future in which we were all financially incentivized to participate in CoinJoin transactions for everything that we transacted and basically breaking a lot of the potential for chain surveillance to be watching everything that we're doing. Because I think if we're all honest with each other, Bitcoin has some pretty poor privacy characteristics. That's a great point. Wow, yeah. Okay, so I think now that we've kind of had an intro into how each of you came to hear about it, maybe some of the things that 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 what CISA is and what those letters stand for. Does anyone have a good explanation of how it works? I can sort of. So it's really already all in the name. Cross-Input Signature Aggregation. So if you think of a Bitcoin transaction as it looks today, you have sometimes one but often multiple inputs. And with each of the input, usually a signature is associated. And what the linearity property of short signatures allows you to do is to aggregate these signatures. And you can aggregate them across the different inputs that you have in a transaction. And so that means that in the future, we could have transactions that have multiple inputs. If you think specifically about transactions that have a lot of inputs like coins, for example, as we just mentioned, these could have just one signature then. And depending on what technique you use, these can be just as big as one single signature before. And 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. I have a quick question about that. So whenever you say you can do cross-input signature aggregations like 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 kind of the general idea is that on that same one signature, instead of having a couple of them, you kind of be able to roll them all up and just have a single signature. Is that a good summary of what you're explaining? Yeah, I would say so. Okay. Yeah, so there's two major ways to do this. The one is what we call a half signature aggregation or half ag as we abbreviate it. And that's basically where you don't have any kind of need for 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 a slightly bigger one. In fact, that size is determined by the number of inputs that you have. So that's one way to do it. And then there's a more comprehensive way to do it which is called full signature aggregation. That gets you really like a much more compact signature which is the aggregate of all of the other ones. Unfortunately, the downside of that is that you have to do this interaction while you sign. And the problem with that is that interaction is always contains a lot of complexity. So unless you own all of the inputs, you are going to have to interact with all of your, everyone else who's adding an input to that transaction. And that creates obviously a much more difficult process in terms of signing. And as a result, we generally, at least 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. Cool. So it sounds like we're taking signature data and it's all the same signature data in like a single transaction, right? You wouldn't have multiple transactions that you're doing. It's like on a single transaction level. Well, there's also full block aggregation, right? This is going really far down the rabbit hole and I think that it's not even something that is on the table once again because there's too many additional edge cases, I guess, that come up, especially when you start thinking about like reorganizations of the blockchain. And my understanding is you would basically have to have like this other mem pool to keep track of things that were not sufficiently buried enough in the blockchain that they could be reorganized because 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 and put it back into the mem pool and start over again. Great. Cool. So it sounds like you're saying there's a couple of different ways we could do signature aggregation. We could do it at the transaction level. We could have a proposal to be able to do it at the block level. But again, there's some trade-offs there. So one of the nice things if you were able to take basically signature aggregation at the block level would mean that you take all the signatures anywhere in any transaction inside a block and for that you'd create like maybe a single signature object, right? Maybe it's not exactly a signature, but something similar to that. Why is one reason that you would want to even do this? It sounds complicated, but... Yeah, well, so there's the privacy characteristics improvements, but also, you know, I think it's interesting whenever we're talking about incentivizing people economically. So if anyone was around and paying attention in 2016, 2017, when we were talking about segregated witness, there was this concept of a witness discount. It was basically put in place to help incentivize people to help rebalance the cost between creating a UTXO and spending a UTXO. Basically, you run into some problems where if you're receiving a lot of transactions, you're basically 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 and this inevitably catches a lot of people by surprise if they haven't been through like a full market cycle before. So I think this is another potential interesting aspect of aggregation is that once again, we would 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. Maybe to expand on that. So there is a financial incentive then for people to participate in coin drawings and that gives them additional privacy and the nice effect of that also is that hopefully this would lead to also like wider adoption of coin drawing, which means that when more people are coin drawing, that's a higher anonymity set that benefits everyone that is after this anonymity property but also everyone that participates in this coin drawing can also use this as a plausible deniability even if they are doing it primarily for the privacy aspect but they can also always say like, hey, I'm saving fees here. So that's my primary motivation and hopefully a further trickle down effect would be that like when people are more asking for this, when this becomes more wide stream adopted, then also more and more wallets adopt this, easier to use wallets, complexity gets hidden and it becomes more of a mainstream feature. Yeah, I mean we have to think about the incentives, right? You know, I consider myself a cipherpunk, I'm a big privacy advocate, I would assume we all are but the reality of the situation is and this is pessimistic, most people don't care about privacy or they don't care until it's too late and so we can stand up here and we can talk about how awesome it is to have really strong privacy and like why you should be using all of these insane tools that are very niche right now 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 should be going out and basically asking their wallet providers or other software developers to please 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 you could be using this technology that you know it happens to enhance privacy but it's actually saving me money. Yeah, so you might be wondering at this stage what are the savings actually look like and 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 so you can immediately think that that's going to reduce the average fee level for any point in time people submitting transactions to the mem pool to be included in a block you can now fit 20% more average size transactions into that block and that obviously is a big advantage. Now the actual effect on a particular transaction because of the witness discount that James had mentioned earlier is actually less so there you've got like a 7% to 8% but remember that the average fee rate is going to be lower because again we're fitting more transactions into a block which just means there's less pressure on block space so that's how I would encourage you to think about it from the start like for me the efficiency in terms of block space is a good reason to do this anyway regardless of whether we get privacy benefits it's almost like 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. I think now that we've sort of talked about how great this is we're going to get more transactions in a block we're going to save money, we're going to get better privacy I'd be really interested to hear why it didn't make it into Taproot originally like is there any opposition to this proposal what was it about Taproot or like the Taproot process where this proposal didn't quite make it over the line? So I mean I was not in the room when this... I don't think any of us were in the room but I mean I've read all of the transcripts that were available from when these things were discussed and what I can say like I think there was no direct opposition also I think the primary motivator was to keep Taproot manageable in terms of review effort and just keep the scope smaller and I mean the only thing that I could see really between the lines what Greg already kind of mentioned is that if you just look at the pure fee savings numbers the numbers of weight units that you save if you just throw that over to somebody that it's for half aggregation in the single digits then people are often a bit disappointed as a first reaction and you have to really discuss it and fill it a bit more with this understanding and I think that made it also have turned off some people and like why maybe also developers felt like this would be the easiest thing to chop off but that people wouldn't miss as much Yeah so I think in terms of the whatever pushback I have heard so far is what Fabian was saying that it doesn't do enough I think that there's a general perception that we can only ever push for one soft fork at a time so all the soft forks have to compete to be the one which is an interesting point of view It's interesting because I was in the room in Hong Kong when Peter Willa announced that we were changing the flagging system so that we could do like 32 soft forks in parallel and of course we have not yet taken advantage of that Yeah so you know we're in a very different space from that now I think you know something to bear in mind if you're thinking about it from that point of view is that and I heard Brandon Black actually was here earlier today talking about Opcat is that I think Caesar is probably the most low risk soft fork that we could imagine and I'm talking about here about the well understood half signature aggregate form of it you know it's really from a security model point of view the cryptographers tell us that there is no risk effectively or very low risk to doing this it really takes very well understood properties of Schnorr which is really just adding these signatures up and uses that so in terms of risk of doing the soft fork it's not really enabling other things that Bitcoin can do it's not going to be some kind of ungrounded it's really just compressing and 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 have compressed the signature size down so maybe it opens up the space for other soft forks if we do a soft fork which has such low risk to it that it actually gets across the line I think it's also worth noting that this is by no means the only signature aggregation scheme that's even happening in Bitcoin right is that like with the taproot soft fork a few years ago we did get the theoretical ability to do Schnorr signatures but that has been an ongoing process right so as far as I'm aware off the top of my head there's a pretty limited amount of adoption of Schnorr so far because I think Musig 2 is the main production ready standard that people are using and that can only do an N of N like a 2 of 2 or a 3 of 3 type of scheme so it's kind of limited in its flexibility and 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 of multi-sig and that evolution that research is still ongoing we're continuing to see like new iterations of Frost come out and so we do expect that we will start to see more adoption of aggregated signatures across the ecosystem but the ultimate end goal would be something where like there's only one signature per block like the final form of SIGAG as we go all the way to the block level so we only have a few minutes left maybe we can spend a little bit of time talking about okay so we almost had it, we didn't get it what would it take, like what's left from here to get it to the point where we could soft fork it in there's still quite a few things to hammer out in terms of all of the details defining a spec so for the half arc there's BIP draft but it's not a pull request on BIP repository but it's, they're just minded to do like test vectors there that are open however for the full aggregation we still need to develop the signature scheme so that requires quite a bit of effort from people reversed in cryptography and specifically on the side of the interactivity and we will also want to have a security proof for that scheme that comes out on the other hand that means people with very specific talents and experience in that area will also be needed in process so these I think are the big to-dos that we have and the people that can do this stuff need to come together and work on it personally I spend quite a bit of time on it right now but maybe something to everyone watching this or in the audience if you want to get involved let us know Call your local developer and demand signature aggregation today Yeah and just to that point Fabian has developed a great site where you can learn more so if the concepts that we've talked about here today make sense if you want to understand them better you go to CISAResearch.org at C-I-S-A Research.org you can really learn much more about it it's very easy to read, it's not going to be overly technical and I think it gives a good grounding in these things and then largely the way that 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 so as far as I'm aware this is the first panel we've had which talks about it, it is still even though it's an old concept and it's a simple concept we don't really have a lot of discussion about it right now so talk about it try and develop an understanding of what it is that it's trying to do and see whether you want to have it in Bitcoin or not I don't know, do you want to save money? it should be an easy question