 Hello, everyone, and welcome to this presentation. My name is Siya Vashriyayi, and today Andreas Ervig and I will present to you the paper, generalized channels from limited blockchain scripts and adapter signatures. This is a joint work with Lukas Aumair, Oguzan Erzoy, Andreas Ervig, Sebastian Faust, Kristina Hostakova, Matt Omafai, Pedro Moreno Sanchez, and me, Siya Vashriyayi. Before I start, let me give you a sneak peek into what we achieve in this paper. We present an efficient, application-less diagnostic, cheap, and interoperable off-chain solution for cryptocurrencies. Now let's start with some background and motivation. Blockchains were introduced as an infrastructure in order to enable parties to make payments or run applications in a decentralized manner. So if Alice wants to, for example, pay Bob some coins, let's say, she would simply send a transaction to the blockchain. However, the size of each block in the blockchain is fixed. And furthermore, the average time during which a block is produced is also fixed. This results in blockchains having limited throughput and parties having to pay a high transaction fees for their transactions to be actually included in the blockchain. In order to overcome this problem, off-chain protocols were introduced as scalability solutions. The most prominent off-chain solution to improve scalability of the blockchains is called payment channels. A payment channel executes in three or four phases. The first phase is creation. The second phase is update. The third phase is closing a channel and finally punishment if necessary. Let's go through them one at a time. In order to create a channel, parties first on-chain make some transactions in order to lock some coins. After a successful creation, these parties will now have an open channel and they can update it as many times as they want off-chain. Eventually, if they want to close their channel, they can send the latest state of the system of the channel to the blockchain and get their money back. But what prevents Bob from sending an older state which might be beneficial to him? Well, on more advanced blockchains, such as Ethereum, which allow execution of more complex programs, you can compare the state numbers and Alice can submit, for example, state SN and prove to the blockchain that there exists a newer state and they would be paid out based on the latest state. However, other blockchains, such as Bitcoin, do not support execution of applications which would allow such a comparison. In this case, a punishment mechanism is used in order to prevent a party here, Bob, to submit an older state. More specifically, the output of a state does not only specify the money payout to the parties, but it also includes a punishment section where Alice can use in order to punish Bob if he misbehaves. The most famous and actually widely used channel in practice are called Lightning Channels over Bitcoin. They were introduced in 2016 by Poon and Drija and I will here give you a simplified, high-level overview of how they work. In order to create the channel, parties first lock, let's say each of them 10 coins in a so-called funding channel on the blockch. Then each of the parties will have a commit transaction which specifies the payout here, 10 and 10, and a punishment payout where it can be used by the other party if they know the secret of the publishing party. So if Alice publishes her commitment transaction and Bob knows Alice's secret here, X1, Bob will be able to punish Alice. The same holds for Bob. I would like to emphasize that these two transactions are not posted on the blockchain. And both of these transactions must be signed by both Alice and Bob. Furthermore, note that parties cannot get the payout and punishment at the same time. In other words, either the payout would go through or the punishment. This is because there is simply not enough funds in the original channel to here pay 40 coins out instead of 20. Now, how would an update work? Well, first, parties would choose two different secrets here, X2 and Y2. Then they would generate a new commit transaction which now changes the payout conditions and also the punishment condition. So now the punishment condition would be for Bob to know X2 in order to punish Alice if she publishes commit two. And at this point, they exchange the previous secrets, X1 and Y1. So if now Alice publishes commit one onto the blockchain, Bob would be able to punish Alice. I would like to point out that this was a simplified explanation on how lighting works and in practice, lighting actually needs time locks and hash locks. This concept that I explained now can be generalized to allow the payout to be some application that will be run on the blockchain. So like the scripting language that is supported by the blockchain can now be also supported off-chain. Furthermore, we can run many applications off-chain in just one commit transaction. Note that this is just a naive generalization and there would be some problems with it. First, we are now having punish per application. I will later explain why this approach is not so efficient. Second, we have state duplication which in case of nested applications would be quite problematic. And I would like to point out that this generalization is not formally analyzed and I'm just mentioning it here to show that okay, lighting can be generalized but we must do better to be efficient. So let's see actually what is the problem with punish per application and state duplication. Punish per application significantly increases on-chain communication in case of disputes. Why? Because when a commit transaction is posted, you're actually repeating many punishment conditions which could have been actually simplified in one. Namely, a party has posted an outdated commit transaction. State duplication increases the off-chain overhead substantially with some applications need such as the virtual channels over Bitcoin paper by Almaya et al. What do I mean? How bad is it that the off-chain communication increases? Well, recall that we have two commit transactions and now opening applications on top of applications or having nested application will result in an exponential growth of the off-chain communication. In our work, we try to tackle these issues. We first formalize and give a definition of generalized channels in UC which does not require or does not have state duplication and punish per application. We provide efficient constructions based on a primitive called adapter signatures. In order to use adapter signatures, we for the first time give a formalization, a standalone formalization of this primitive and show how to instantiate them based on Schnorr and ECDSA. I would like to emphasize that Schnorr and ECDSA are the two main signature schemes used on virtually or more or less any blockchain that is used in practice. And therefore it is important that we show how adapter signatures are instantiated using these two signatures to be compatible with as many different blockchains as possible. We also implemented and evaluated our generalized channel protocol and we approved the generalized channel scheme to be secure in UC. Okay, the outline of this talk would be as follows. I by now gave you the motivation, the motivation behind our paper. I will continue with the definition of adapter signatures and constructions. Afterwards, Andreas Evig will show you our generalized channels definition and construction and we provide performance evaluation and applications. Okay, now let's see what are adapter signatures, how we can define them and how we can instantiate them. An adapter signature is defined based on an underlying signature in our case Schnorr or ECDSA but consists of four additional procedures. Pre-sign, which we show by P-sign, pre-verify, which we show by P-verify, adapt and extract. Let's see in a two-party scenario how adapter signatures can be used. We have on the left-hand side Alice and the right-hand side Bob. Bob is the party who has a secret and public keep for a signature scheme and Alice has a statement witness pair for a hard relation and a message for which she wants to receive a signature. By hard relation, I mean it is difficult given the statement to extract a witness. For example, this can be a delock relation due to the part of Y and Y. Alice sends a statement and message to Bob and Bob generates something called a pre-signature. Note that the pre-signature is an incomplete signature, namely if you run the original verify algorithm of the signature scheme on it, it will not verify. Bob sends this pre-signature back to Alice and Alice cannot check if the pre-signature is actually valid by running the P-verify algorithm. If so, she can adapt the pre-signature into a valid full signature given her witness. So now she has a complete signature which looks identical to a signature generated by Bob on message M using SK. She can at this point post the signature to the blockchain. We can assume that M is a transaction that will be supported by the blockchain, accepted by the blockchain. And upon this signature being accepted by the blockchain, Bob can read it and can extract a witness given the pre-signature, the full signature, and the statement such that the statement and this extractive witness are in relation. So as you can see, we have four additional algorithms for adapter signatures. The high level idea to build adapter signatures is to hide this witness W in the randomness used for signing. We will see this later when I show you the instantiation of adapter signatures from Schnorr signatures. But before that, let me give you the history of adapter signatures. Adapter signatures were first introduced in January 2017 by Paul Stra in a mailing list and he presented a construction based on Schnorr. A year later, Moreno Sanchez and Kate in a mailing list showed how we can actually build adapter signatures in a threshold setting from ECDSA. In 2019, Molovolta et al in their NDSS papers showed how one can build payment channels using the threshold variant of adapter signatures. In this work, we formalize a single-party adapter signature and show Schnorr and ECDSA-based constructions. Shortly after this work was put on online, Eskin and Tyree in two parallel works showed how one can produce two post-quantum secure adapter signatures from different underlying assumptions. And finally, in 2001, Ervig et al in their PKC paper showed how one can build two-party adapter signatures generically from identification scheme which satisfy some properties. Okay, now let's see what are the properties, security properties that adapter signatures need to satisfy. In short, there are four properties, correctness, existential unforgeability, pre-signature adaptability, and witness extractability. Let's start with correctness. Correctness simply states that if everybody behaves honestly, the algorithms behave as I described previously when I gave the overview of adapter signatures. More precisely, Alice sends a statement and message to Bob. Bob generates honestly a pre-signature. Alice can verify this pre-signature, so the verification returns one, the P-verify returns one. Alice can then adapt this pre-signature to a full signature, which is indeed valid so she can post it on the blockchain. And Bob, by seeing the full signature, can extract a witness, which is in relation with the original statement shared by Alice. Now let's continue to pre-signature adaptability. Pre-signature adaptability states that if Alice is honest and sends her statement message to the Bob, who is, in this case, malicious, and Bob somehow comes up with a pre-signature, we don't know how, but the point is that the pre-signature verifies. So the running pre-verify algorithm on the pre-signature would return one. If Alice now adapts this pre-signature, she would get a valid signature. In other words, if pre-verify returns one, regardless of the average strategy, Alice would be able to adapt this pre-signature to a full signature. The third property that I want to discuss is the existential affordability. This property states that we have Alice and Bob, for example, who are communicating and the adversary can see many pre-signatures on many different messages. Eventually, even if the adversary knows a pre-signature on a specific message of his choice, he will not be able to produce a full signature such that the signature is valid unless and without having seen previously a signature on M. In other words, even seeing a pre-signature on a fresh message M will not help the adversary to forge a signature. Finally, we have witness extractability. In this case, we have a malicious Alice who sends a statement message to Bob. Bob generates a pre-signature and Alice comes up somehow with a full signature. If the signature verifies, namely Alice can now publish this signature message pair to the blockchain, it should not be the case that Bob is not able to extract a valid witness. In other words, if this signature is published and this signature is valid, Bob will always be able to extract a valid witness. Okay, for more details regarding how these properties are defined formally, I would refer you to our paper. At this point, I would like to show how to transform Schnur signatures into adaptor Schnur signatures. Let's shortly recall how actually Schnur signatures work. First, we know that we have a cyclic group G of prime order Q and a hash function which maps messages to ZQ. The key generation works as follows. The secret key is a random element from ZQ and the public key is G to the power of the secret key. The signing algorithm chooses a random value R from ZQ and the public randomness would be G to the power of R. Then hash of G to the power of R connected with M is computed and S would be R plus H of X mod Q. The signature would be this hash value and S. To verify, we compute G to the power of S, the public key to the power of minus H, compute the public randomness and we check if the hash of this R prime connected with M is accompanied hash in the signature. Now, how can we transform this Schnur signature into adaptor Schnur signature? Well, the generation will stay the same and now what we have is a statement of witness pair. In this case, W and G to the power of W. All we need to do to build the pre-sign algorithm is to multiply the public randomness G to the power of R with G to the power of W, the statement. And that's it, the rest stays the same. And to verify, when computing R prime, we just multiply G to the power of W with G to the power of S times X to the power of minus H. What would this change actually do to the final result of the pre-sign algorithm? Well, what we get is S equal R plus H of G to the power of W, G to the power of R. This means that in order to adapt such an S into a full signature, we just need to add W to it. And then we would have a signature where the randomness, the private randomness is R plus W and the public randomness is G to the power of R plus W. As I said before, the high level idea is to hide W in the randomness used for signing. It is also easy to see that given the pre-signature and the other signature, W can be extracted. The witness can be extracted. Okay, let me now summarize our contribution with respect to adapter signatures. We get the first formal definition of adapter signatures and proved Schnur and ECDS adapter signatures in our model. I would like to point out that additional zero-knowledge proofs were required in order to make the ECDSA variant of adapter signatures secure. Therefore, one interesting open problem would be if we can remove these zero-knowledge proofs and still prove the ECDSA variant of the adapter signatures secure normal. For more details, please check out our full paper. Now I will hand it over to Andreas Ervig to give you our generalized channel definition and construction. Okay, so I will now talk about our generalized channel definition and I will also give a high level overview of our construction. Informally, what a generalized channel is, is it allows two parties to execute off-chain any two-party application that could otherwise be executed on the blockchain. So basically it allows two parties to lift the execution of a two-party application from the blockchain off-chain. For this, we of course require some properties and in fact, we have three security properties and one efficiency property. The first security property is consensus on creation. That means that if two parties have a generalized channel with each other, then both parties must have agreed to the creation of this channel. So it cannot be the case that a malicious party opens a generalized channel with an honest party without the honest party agreeing to it. The second property is very similar to the first one, which is consensus on update. So this means that a generalized channel can only be updated if both parties agreed to the update. Then we have the property of instant finality with punish, which on a high level says that an honest party in a generalized channel has to guarantee that the latest state of the generalized channel can always be enforced on the blockchain or if that's not the case because of some malicious behavior, then at least the honest party can always punish the malicious party for the malicious behavior. And then finally, we have an efficiency property, which we call optimistic update. And that says that if both parties are behaving honestly during an update procedure, then this procedure will terminate within a constant number of rounds. I will now give a high level overview of our construction of generalized channels. And for that, I would like to first recall that we pointed out two issues with lightning channels. And those two issues were that lightning channels required a punishment per application. And also lightning channels were based on state duplication. That means that lightning channels have two distinct commit transaction for each state. Now, our idea for constructing generalized channels is to improve these issues. So first we would like to decouple the punishment from the applications that are run in the generalized channel. And also we would like to use adapter signatures to remove the state application. And I'm first going to talk about this, decoupling of the punishment from the applications. So we introduce in our paper a paradigm that we call punished and split. As a reminder, this here is the transaction design of lightning channel. So we have a funding transaction. We have two commit transactions and the commit transactions hold all the applications and all the punishment outputs for these applications. And what we rather do for our generalized channels is that we have still a commit transaction but this commit transaction only has two outputs. One output for all the applications that run in the channel and one output for the punishment. And then we have a second transaction which we call split transaction and the split transaction spends the application output from the commit transaction and holds actually all the applications that run in the channel. So now if you consider the case that for example, Bob is cheating and he commits an old commit transaction then Alice can punish Bob by spending the punishment output. And by this Alice punishes all the applications that run in the channel at the same time. So with this we can decouple the punishment from the applications but we still have the state duplication. So right now we still have two distinct commit and split transactions. So this is the situation that we have right now. We have the funding transaction and two distinct commit transaction and we would like to remove the state duplication. So what we would actually like to have is a transaction design that looks more like this where we have one funding transaction, one commit transaction and one split transaction. But how can we achieve this? Well, our idea is to use adapter signatures and I will give a high level overview of how the update procedure of our generalized channel works. So as to explain to how we use adapter signatures to have only one commit transaction. So if we assume we have parties Alice and Bob and both of them have a key pair then in order to update a generalized channel between Alice and Bob as a first step both of them agree on a new commit transaction and a new split transaction. Then both of the parties sample a statement and witness pair from the adapter signature relation and they exchange the statements that they just sampled. As a next step, both of them create a pre-signature under their respective secret keys for the commit transaction and for the statement of the other party. So for example, Alice creates a pre-signature under her secret key for the commit transaction and for the statement that Bob sampled previously. And then finally, the two parties exchange the pre-signatures. So here I want to point out that now Alice for example can adapt Bob's pre-signature using her witness WA to a full signature and she can then use this full signature to spend the commit transaction and Bob can do the same thing with Alice's pre-signature. And then at the end of our update just like for Lightning channels we have the usual revocation where parties exchange their revocation secrets. And now the crucial point of this is that if Alice publishes now the commit transaction with the signature that she adapted from Bob then Bob can extract the witness WA from Alice. And we can use this observation to require only one commit transaction in our transaction design. So this is our actual transaction design for our construction. So we have one funding transaction one commit transaction, one split transaction. And now the commit transaction holds the punishment output which can be spent by either Alice or Bob. And this output can be spent under the condition that first both parties or either of the party knows the revocation secret of the other party and it has to know the witness of the other party. So for example, Alice if she wants to spend the punishment output of the commit transaction then she has to provide proof that she knows the revocation secret of Bob, YI and the witness of Bob, WB. YI indicates that the commit transaction is actually a revoked sort of an old commit transaction whereas WB indicates that Bob was actually the party that published the commit transaction. So Bob was the malicious party that published an old commit transaction. I want to note that this is an simplified transaction design of our construction. We actually require a little bit more than this so we require additionally time locks but that is all that we require. So our construction works for blockchains that support time locks and signature verification whereas lightning channels for example require additionally to these assumptions hash locks. As a summary for our generalized channels we developed the first bi-directional channel protocol for UTXO based blockchains that require only one commit transaction that does not require this punish per application mechanism but follows the punished and split paradigm and that only relies on minimal assumptions of the underlying blockchain that has signature verification and time locks. And for further details please go ahead and check our paper. I want to now talk about our performance evaluation and about some applications for generalized channels. So we implemented our generalized channel solution and we deployed it on the Bitcoin test net in order to be able to compare it to lightning channels. So what we wanted to see is how do generalized channels scale in comparison to lightning channels considering some number of applications that run in the channel. And as applications we chose hash time lock contracts because those are the most common applications that run in lightning channels. So as a first step we evaluated how much byte overhead is incurred during an update procedure that happens off chain in relation to the number of applications that run in the channel. So what we can see here in this graph is on the x-axis is the number of hash time lock contracts that run in the channel. And on the y-axis we see the byte overhead that has been incurred. And what we can see is that already for one hash time lock contract the byte overhead is better for generalized channels than for lightning channels. And this gap increases with an increasing number of hash time lock contracts running in the channel. And this is because for lightning channels there are two plus two M transactions required to be exchanged for an update where M is the number of hash time lock contracts whereas for generalized channels there are only two transactions that have to be exchanged. We then also looked at the pessimistic case that means the case where a punishment actually has to happen on the blockchain. So we looked at the on-chain course in bytes in comparison to the number of hash time lock contracts running in the channel. And what we can see is that for generalized channels the byte overhead is constant. So it's independent of the number of hash time lock contracts. And this is just because of the fact that generalized channels follow the punished and split paradigm. So more concretely for lightning channels we have two plus M transactions that have to be posted on the blockchain whereas for generalized channels we only have two transactions. I will now briefly talk also a little bit about applications for our generalized channels. So like I said before, in general, generalized channels can be used to execute any two-party application off-chain that could otherwise also be executed on the blockchain. And a little bit more concretely, generalized channels could be used for example to execute the fair two-party computation protocol that was introduced by Ben Tov and Kumadesan in crypto 2014 or it could be used to execute the channel splitting protocol that was introduced by Aga et al at CCS 2019 where a channel can be split into two or even multiple channels off-chain or it could be used for virtual channels where basically two generalized channels are used to build another channel, a so-called virtual channel off-chain. So with this I want to sum up in our work we presented an efficient application agnostic chief and interoperable channel solution that requires only one commit transaction has application agnostic punishment and requires only minimal assumptions from the underlying blockchain. Thank you for your attention and we are looking forward to your questions.