Inside Iceberg: The (Secret) Leap Forward in Bitcoin's Cryptography w/ Nadav Kohen

**Nadav Kohen** (0:00)
The goal is that a Taproot, a Schnorr key could itself represent a multi-sig or a threshold sig. When I started, I kind of had specifically the Lightning Network in mind. You basically have this hot wallet with all of your funds on it, and it would be great if you could somehow work towards thresholdizing that operation so that it's not just a single device somewhere, having some secret information that you can use to take all of your funds, but rather split that across multiple devices, do other kinds of key management.

**Shinobi** (0:42)
Hello, everybody. I'm Shinobi from Bitcoin Magazine, joined today by Nadav Kohen from Chaincode Labs. And we are going to talk a little bit today about math.
So, Nadav has been working on security proofs to show that you can nest a taproot, new sig, N of N, specifically just that kind of multi sig inside of another one, and prove that this is safe, which is the real important thing when we're playing around with cryptography, isn't it?

**Nadav Kohen** (1:19)
Generally, one doesn't want it to be possible for their money to be spent without their approval, which is kind of the goal that we want to guarantee.

**Shinobi** (1:31)
So, I guess, do you want to tell us a little bit about what kind of drew you into this project and why you started working on this proof in the first place?

**Nadav Kohen** (1:40)
For Nested Music? Yeah, so, I mean, it kind of started by being interested in trying to nest something more like Frost, which is a threshold signature, lets you do the T event, two of three, as opposed to just N event, which is what Music Accomplishes, where everybody has to sign, and nesting a threshold inside of Music. When I started, I kind of had specifically the Lightning Network in mind, where the Lightning Network is a two of two contracts between two channel counterparties, each side of the channel.
They both have to sign in order for their channel funds to be spent, but Lightning requires liveness and some other things, so you basically have this hot wallet with all of your funds on it, and it would be great if you could somehow work towards thresholdizing that operation so that it's not just a single device somewhere, having some secret information that you can use to take all of your funds, but rather split that across multiple devices, do other kinds of key management in that setting. But this applies more broadly.
Most ways of contracting using Bitcoin involve all parties involved pooling their funds into a transaction that requires all of them to sign, and they have some pre-signed transactions ahead of time, that they've all signed before they put the money into this pool that execute the contract. And all of these kind of have this multi-sig layer at the top, and then it would be nice in many of these instances if you could have some kind of thresholds for individual participants. But you don't necessarily want to introduce all of that complexity into the actual protocols where they're going to be used. That is kind of just like a lot to deal with. And so kind of the goal is that a taproot, a shnor key could itself represent a multi-sig or a threshold sig. And then, like for example, Lightning is moving towards using MuSig instead of having a two of two on chain script that has these two keys they both have to sign. We're moving towards just having a single key, which is the combination of the two keys in a special way. And basically you can ask, well, each side of that channel, like a single participant in this MuSig, generates partial signatures that then get added together. Could you do something similar one layer down, where a bunch of nodes work together to generate a single partial signature? So kind of nesting inside of that. And the reason that I studied nesting MuSig inside of MuSig, it has a couple of direct use cases if we want to talk about that. But kind of my focus has been more so as that being kind of a testing ground to move towards doing thresholds inside of MuSig.
And there was kind of a specific idea that Tim Ruffing and Janek Surin kind of planted in my head of using replicated secret sharing on top of MuSig in order to accomplish this, which is why I specifically spent so much time on nested MuSig.

**Shinobi** (5:09)
Yeah, we could get into some of the direct use cases if you want.

**Nadav Kohen** (5:12)
Oh, okay. So nested MuSig without worrying about thresholds. There aren't that many, but there are a couple of things. So one is, say that you're in a situation like ARK, where there's a multi-sig between the operator, kind of whatever the operation is, it might be multiple people, whatever, and the user, so operator and user. But in reality, the operator might be multiple people, the user is for some VTXO, which could itself maybe be like a discrete log contract, or a lightning channel, or something that is itself a MuSig. So we want it to be secure to nest a MuSig and a MuSig, so that you don't have to program all of these conditions, all of these possibilities into something like ARK, but rather you can just be like, here's my key, and it's actually representing multiple people, and you want that to be secure.