Name: Kevin Loaec and Antoine Poinsot

Topic: Revault - A Multiparty Vault Architecture

Location: London Bitcoin Devs (online)

Date: May 26th 2020

Video: https://www.youtube.com/watch?v=7CE4aiFxh10

Kevin slides: https://www.dropbox.com/s/rj45ebnic2m0q2m/kevin%20loaec%20revault%20slides.pdf?dl=0

Antoine slides: https://www.dropbox.com/s/xaoior0goo37247/Antoine%20Poinsot%20Revault%20slides.odp?dl=0

Intro (Michael Folkson)

This is London Bitcoin Devs. This is on Zoom and live-streaming on YouTube. Last week we had a Socratic Seminar on vaults, covenants and CHECKTEMPLATEVERIFY. There is a video up for that. There is also a transcript, \@btctranscripts on Twitter. Regarding questions Kevin and Antoine are going to pause during the presentation for questions and comments. We are not going to have interruptions so we will let them speak until they pass. There will be a Q&A afterwards. Kevin will start from basics, foundation level so don’t ask advanced technical questions at the beginning. He will cover the more advanced, technical stuff in the middle and the end. Apart from that I just need to introduce Kevin and Antoine. Kevin Loaec I know from Breaking Bitcoin, Building on Bitcoin conferences which were amazing. Hackathons, conferences and all the events around that. Also Kevin works at Chainsmiths and is building a growing Bitcoin community in Lisbon. Antoine (Poinsot) spoke at London Bitcoin Devs in person a couple of months ago on c-lightning plugins. Watch that presentation on YouTube, that was really good. Today he is going to talk about vaults specifically the vault design “Revault”.

Revault - A Multiparty Vault Architecture (Kevin Loaec)

Thanks for the intro. I am going to try to make my part of the presentation about 40 minutes long. Then Antoine will go through the hardcore discussion on deep technical details after that. It is going to be long. I will try to make some pauses for you to ask questions but don’t hesitate to ping me. We are going to talk about Revault. Revault is a vault architecture that Antoine and I have been working on for the past 5 months now, since December. As you will see it is targeted towards institutions so not people as such. This presentation will talk about everything from the basics of how we do security today on Bitcoin for individuals and institutions. Then I will look at the different propositions we can do with Bitcoin today for individuals and institutions. Then I go directly into Revault, what we have built. What we have and how it works. Then Antoine will talk about very specific details about the architecture. If you are really into Bitcoin development you might have some questions or you might have not considered the attacks possible. Antoine will cover a lot of those. It is really interesting. The longer it goes the more technical it will be. If it is too simple for you at the beginning that is normal. It will get increasingly more advanced. If you are a beginner, at some point if you drop out expect the rest to be even more technical. I am trying to do my best to not lose anybody at the beginning. Hopefully it will not be too simple either.

Ownership model

The first thing I want to talk about is how we do Bitcoin today. We have ownership, how do we own Bitcoin? We have the question that is who controls the keys? This is the first part of how you can protect your Bitcoin. You have three choices here. You can deal with a third party custodian. Let’s say you leave your coins on an exchange. You don’t control the keys. It is not really your Bitcoin. That is one way of doing it. The other way is self-control of your keys. If you own all of your keys then you really own your Bitcoin. Nobody can block them or steal them away from you if they don’t have your private keys. Then you also have the mixed model where you and another party have keys to move the coins. This is about control. A mixed example could be the Blockstream Green wallet. It has two signatures, you sign one then you send the transaction to them and they co-sign it. Even if your key is lost that is fine because nobody can steal your funds without having the key from Green.

Key Management

The second question on ownership is about key management. The first slide was about who has these keys but the second one is about how these keys are secured. You have different approaches again. One popular one is called cold storage. You might have heard about that from exchanges from example. Cold storage is an address or a set of keys that you are not supposed to ever touch. Those are the ones that have been generated offline, have never touched a computer connected online and are never supposed to used until you need to move the coins. Think of that as like burying a treasure chest in your garden. A second one could be having hardware or offline wallets. An offline wallet could be a laptop that you removed all the connectivity from. You removed the wifi chip, you removed all networking capability and you generate your keys on this thing. This will never touch the internet. This is a little bit different than cold storage. This is supposed to be used to spend your coins. The private key itself will never touch a computer connected online. This is probably what most people use. Back in the day it was a paper wallet like cold storage. You would have the ones that you never use and then you would have a small wallet on your phone or computer that you would use for transactions. Now most people are using hardware wallets. Then you can go yolo, meaning you have all your funds on your phone or all your funds on your computer. This is extremely risky of course because the threat model is extremely high. Your computer could be stolen, malware could be installed on your computer, you have a lot of risk there. Don’t ever put all your funds on a laptop or on your phone. Then you can also play around with multisig. You could have multiple hardware wallets. You could have one key on a hardware wallet, one key on your phone, one key on your computer. In that case even if one or multiple keys leak that is alright depending on how the multisig is designed. Out of these two slides, the first one who controls the keys and the second one how they are kept defines every way of storing Bitcoin today. As far as I know that is 99.9 percent of how coins are secured. Your own Bitcoin are probably behind one of these solutions or a mix of two. This is not good enough. This is really not good enough. This is just about securing keys, we are not talking about securing the Bitcoin itself. As soon as the keys are leaked your Bitcoin are gone. Vaults are talking about that. When we say we are dealing with a vault we are not dealing with just a key solution. We are dealing with a way to restrict how Bitcoin can move. That is the main point I want to cover here.

Threat model

Then you have threat models to discuss. Threat models are quite complex to list because they depend on each person or each group of people. The main one up until now was the online threat. How malware can steal your keys. That is why your keys should never be on your computer or on your phone. This is the main threat we have today. Then you have a physical attack. Somebody coming to you and threatening you to give them the Bitcoin. As you can already think if I come to you and I start breaking your fingers you probably will dig up this cold storage wallet you have in your garden. Being a garden doesn’t mean you can’t access it. If I really force you to do it you will give it to me. That is not enough as a security model. Then you have third party risk. Of course if you give all your Bitcoin to Coinbase then you are protected from the random guy coming to you but Coinbase now can steal your Bitcoin. You are creating other risks in solving the first one. Then for multiparty solutions you also have the insider attacks. When it is only your Bitcoin you are fine. If it is a company it is a little bit harder. How do you deal with your co-founder in a startup going away with the coins? How do you deal with your IT guy having access to your private keys on the exchange and stealing them? That is another problem that we have to think of. When you are designing security solutions around keys you are trying to think about that. When you are designing vaults you really are trying to figure out all the different types of attacks that can happen. If they can happen they will happen especially for big players like exchanges.

What we want

What we want, this slide is about what we are trying to achieve here. A perfect solution for vaults would look like this. We would be able to restrict where the funds can go. That’s saying if your address is not in the whitelist your UTXO cannot move to it. This is impossible to do today with Bitcoin. We would like to restrict how much Bitcoin can move, maybe per day or per week. Let’s say you are super rich and you have 100 Bitcoin somewhere and you want to protect yourself by allowing you to only spend 1 Bitcoin a month, right now that cannot be done. The Bitcoin network doesn’t care how many of your Bitcoin you are spending. A vault or a covenant could be interesting for doing that. If you know you are not supposed more than a Bitcoin a month can we somehow enforce this at a protocol level or on a second layer? Then you also have the when. That could be for example during business hours if you are a business. The funds should not move during the night because your employees are only there during the day. Could we enforce that? Or as an individual it could only be during the hours that you are awake. You know a theft if even it is malware it wouldn’t be able to move your funds during the night. This is a restriction we want in a vault. As we discussed before most of the solutions we can think of add risk. Let’s say the where here, if I only allow myself to send my coins to Kraken what happens if Kraken disappears? All my coins are locked forever because Kraken exists don’t anymore? This is really difficult. Or make it unusable. Unusability is interesting as well. In security you have this principle that if your system is too hard to use or too annoying to use people are not going to use it. It might be secure but just because it is annoying to use it on a day-to-day basis people are going to bypass it. Your security is defeated because it was unusable or too hard to use. This is very important when we design security solutions.

Theory is cool but…

What I wanted to cover here is that Bitcoin is in theory pretty cool but the practical Bitcoin we have today is a very limited set of blocks. We cannot do whatever we want with it so we have a specific set of tools we can play with. We can probably build anything with it but we have to be really smart about how we do it. We cannot just ask the Bitcoin Core developer to implement a new covenant opcode “Can you please do it?” Everything takes ages to be added and modified in Bitcoin because that is the way Bitcoin is designed. I am really happy with that. I am ok to have a Bitcoin that is pretty restricted for security reasons but that also means I need to play within the rules. I have to use whatever basic blocks I have and build with them. I cannot just expect Bitcoin to change to fit my needs. That’s why today vaults are not available on the market. Nobody is giving vaults-as-a-service today. We don’t have software to do that. Most of the software you can get today on Bitcoin, the most advanced one would be multisig. We want to go further than that.

What we have

What we have today on Bitcoin are these basic blocks. These are probably the two we can use at the protocol level. We can use multisig. That is having multiple keys required to sign to be able to spend a transaction. That could be multiple people or not. That could be multiple devices whatever. We also have timelocks, I am going to cover timelocks after that. Lastly we can also imagine that we have tamper-proof hardware. That could be a hardware wallet, maybe one that is more programmable. A Coldcard or something like that where you would put some of the restriction on the hardware itself to emulate having this third party checking for your rules to be ok. What we don’t have again is covenants. What is a covenant? To explain what Bitcoin can do today we have the outputs in every transaction. The output defines how the funds can then be spent. The output has conditions on how the next person or the next spend will be able to spend them but that is only from the inputs. You cannot have a restriction on the outputs of the child transaction. Meaning that if I send Bitcoin to Michael, I can put some restriction on this. I could say “Michael will not be able to spend this transaction before December 1st through a timelock.” I could do that. Or I could do “I will send these coins to Michael but I also need to co-sign. I need a multisig with him.” What I cannot do is put on a restriction on how the output of the spending transaction will be. I cannot say “The coins I’m sending to Michael can only go to Kraken afterwards.” There is no way of doing that today. That is what we call a covenant. We do not have covenants on Bitcoin today. There are a lot of proposals and I think Antoine is going to talk about them later. Also the meetup we had last week about CHECKTEMPLATEVERIFY, that is one of those. With CHECKTEMPLATEVERIFY you can enforce a restriction on the outputs of a child transaction. Today we don’t have that in Bitcoin. Revault is not using this covenant thing. We are trying to emulate it with the tools we have today.

Timelocks

The timelocks we have, in Bitcoin you have four of them. You have Locktime and Sequence that you can do at the time of crafting a transaction. When you are spending a transaction you can add a locktime or add a sequence. The Locktime is about putting a date, time in blocks but let’s say a date e.g. December 1st. This transaction will not be able to be mined before this date is reached. This is pretty cool. Sequence is relative. Sequence is about how long ago was the parent you are spending, the UTXO you are spending from, how long ago it was mined. If you sign a transaction with a Sequence of one week it means that you need to wait one week before the UTXO you are spending from has been mined. It is just a delay between the UTXO you are using and the transaction you are spending from. These two are interesting when you are creating the transactions but sometimes they are not enough. If you have the private key you can double spend them. You can do another transaction spending the same outputs and remove the Locktime from your own transaction. It is not really a restriction, it is somewhat restrictive but you can bypass it if you want. An attacker having your keys doesn’t care about your Locktime and Sequence. That is why these two opcodes OP_CLTV and OP_CSV were created. CheckLockTimeVerify and CheckSequenceVerify. This is put on the outputs of a transaction. That forces the one that will use this output later, the child transaction, to have a Locktime or Sequence that corresponds to whatever is restricted here. I could have a deposit address where when I send funds to it it enforces a delay of like 3 hours before I can spend them again using a CSV. This is cool. Now we are starting to talk about interesting things that we can use in weird vault designs. I just wanted to show you the different timelocks we have. Maybe you can start thinking about how we can use these together to build some of the restrictions we were trying to do earlier. As a note here Bitcoin doesn’t have an idea of time or at least it is not clear. You can do time from when a transaction was mined because mining is consensus. You cannot do time since a transaction has been seen in the mempool. The mempool is not consensus, at least not everybody has the same mempool. We cannot do timelocks from the time of signing. This is somewhat annoying because we would like that in vault systems. For example, if we had something that let me have a lock from the time of signing I could say “I can sign a transaction but I know while signing it I need to wait one day before it can be mined.” This is not possible today. That is annoying and we have to play around that.

Single party advanced mitigation

The title here is probably not right. I wanted to start talking about how we can do advanced mitigations, things we are not using today, to emulate these restrictions where, how and when. The most basic one you can do is adding annoying processes. For example you have a 2-of-2 and you put one of these two keys in a bank vault. You cannot spend during the night because the banks are closed at night. That is enabling your covenant on when you can spend from it. You can also have a notary that will make sure that the key you are spending to is one of your whitelist keys. This is cool but it creates other problems. What if the bank loses your vault? What if the notary cheats or doesn’t want to sign any transaction? That is one tool we could use but it is not great.

Timelock

We have timelocks as we just talked about. Timelocks are more interesting in terms of vaults or at least covenants that you can do yourself. If you deposit to a OP_CLTV saying December 1st you know that you cannot even if you try spend this transaction or this output before December 1st. This is great if you really know you don’t want to be able to spend your funds before a certain date. If you want to hold or you want to do a gift to somebody and you tell them “You can’t use it before you are 18 years old” you could enforce that in the Bitcoin transaction itself. That is starting to be interesting now. OP_CSV is the same thing but from the time the deposit was made. It is maybe a little more flexible because you could say “I’m going to do some dollar cost averaging on Bitcoin and every time I purchase Bitcoin I want to only be able to spend them in 2 years.” Every time you do a transaction it will move forward 2 years for this specific output. This is cool but even you cannot spend from it. It is not only against an attacker it is a real covenant that nobody can spend from these funds before date has been reached.

Key deletion

Then we have key deletion. This is more interesting now. We are starting to get into the ideas that are not really obvious. This has been proposed many times on Bitcoin, it is not new. But it is not something you would think of while looking at Bitcoin and what you can do with transactions. Key deletion is a great way to enforce that something will happen. You can sign a transaction from a deposit UTXO, you receive some money. You can sign a transaction spending from it and then you delete the private key. You are broadcasting the transaction yet, you are just signing it and keeping it. You delete the private key. That means that nobody not even you now can move these funds in another way than the way you already signed and kept in your backup. You don’t have the private key to change this. This is a way of creating a covenant where you could choose how much is moving, where it is moving. You can put timelocks if you want, you can do a lot of things. The major risk you have here again is that you don’t have the private key. If anything is wrong with it it is too late. Even if you lose this pre-signed transaction because you don’t have a private key now the funds are gone. It is a risky one but you can try to play around and make cool things.

Co-signer (secure hardware)

Then you have a co-signer. A co-signer can take different forms. It could be a secure hardware where you enforce checking the rules, maybe checking a whitelist or whatever. It could also be a third party if you want to use Casa or BitGo or whatever. In that case you would do a 2-of-2 you would need a co-signer to approve every transaction you do. You sign your transaction first, you send to the co-signer and if the spending conditions are not met, maybe you spent too much this month, then it is not supposed to sign. This is another thing that could be fun. You can automate things, you can build it at home. If you know it is secure hardware and it is not easy to modify that could be a good way to ensure your transactions are not completely unchecked or too easy to spend.

Clawback

Now let’s go to the fun stuff. This is an idea from 2013 which is a clawback. This is also where the name Revault comes from. It is about sending back a transaction to a vault. Doing this is quite interesting. It looks quite heavy so I am going to explain this. You start with a transaction. Let’s call it the vaulting transaction where you have an output that you will use to be spent with a pre-signed transaction that has two different exit points. Either you use your hot wallet key like any hot wallet on your phone plus a CheckSequenceVerify of a few hours. The other way of spending from it is to use the clawback transaction that is sending into a vault. The key is deleted here. Now what it means is that we are back to the key deletion slide that I had before. This vault transaction can only be spent by this transaction because we deleted the private key. If you want to use the funds either you use your hot wallet key and you have to wait for the delay of the CSV or you can also trigger a clawback which instantly without the delay can put these funds back into a vault. Giving back the same protection. Sending them to a different set of keys no matter what. You can choose this at the time of crafting your clawback. Because the clawback doesn’t have the OP_CSV here you also need to delete the key for signing this clawback. You have to delete the key for the unvaulting transaction and you have to delete the key for the clawback transaction. You don’t have to do it this way but the good way of doing it is that the clawback itself is also a vaulting transaction. You are doing a kind of loop here. You need to also have deleted the key of the unvaulting at the bottom here. That means you also need another clawback here that also needs to be deleted. To build such a transaction you can do that with SegWit because now we have more stability in the txid. But the problem is that you should already pre-sign and delete all your keys before doing the first transaction in it. In this type of vault because the amount would change the txid you have to know the exact amount before you are able to craft the transaction here, sign it and delete the key. Same here, you need to know the amount you are spending from because otherwise the txid would change. When you do a vault with a clawback you need to know how much money you are receiving in it. If somebody reuses the address that you have in your output here of the vaulting transaction and sends no matter what amount of funds the txid would have changed so you would have no way of spending from it because the private key has been deleted. It works but you have to be extremely careful because once you have deleted your private keys it is too late. If you do any mistake it is gone. Another thing is that if you lose the pre-signed transaction your funds are gone as well. You need to do backups of all of that. That is what Bryan Bishop proposed to the mailing list with his implementation recently. The first time it was discussed was probably in 2013. Also Bob McElrath has written a paper at some point on this, maybe 2015. A lot of people have thought about such a protection mechanism. I think it is pretty cool. We are not using this in Revault but this is the most advanced thing you can do right now although no one has it in production anywhere.

Bob McElrath: Two little points. One is that you discussed having the ability to do a timelock from the time of signing. It is cryptographically possible using timelock puzzles or verifiable delay functions but I think this is very far from anything people would want to use it right now. For those that are interested in crypto something to keep an eye on. Secondly somebody asks in the chat how do you prove the private key was deleted? Generally you can’t. An alternative is to use ECDSA key recovery but that cannot be used with Bitcoin today because the txid commits to the pubkey which you don’t know at the time you do the key recovery.

For single party it is fine you can somewhat prove to yourself that you deleted your private key. In multiparty it is much harder because you cannot prove to someone else that you did.

Bob McElrath: It is a little bit worse than that. You have some hardware that generated a key and you want it to delete the key. You should ask questions about did that hardware delete the key? If you’re using Linux and it has a swap file and memory paging this key could exist in multiple places. It is not just that I ran it on my computer, you have to get down to the hardware level and lock the memory and overwrite the memory. Then you can ask questions about things like Rowhammer, could I pull that out in some other way? It is very, very hard if not impossible to prove you deleted a key even to yourself.

You could imagine some way but sure. This is not easy to do.

Institutional mitigation

Let’s talk about institutional mitigation which is a little bit different because usually it is multiparty. Also the impact on operations is somewhat important. Of course it depends on who you are dealing with. For example if it is an exchange they need to access their cold storage quite often. That defeats the purpose entirely. A cold storage should never be used. We need to have ways that can be used without breaking the security too much. This is one of the focuses of Revault. Another thing with institutions we have another risk which is insider risk. Of course when you are alone you are not scared of yourself stealing your own Bitcoin. Bitcoin is very similar to cash in the sense that if you have a business and a till with banknotes in it it becomes really hard to secure this. If you want to have normal operations you need people to be able to take cash within this cash till but you don’t necessarily want every stakeholder in the business to be there with a multi key thing to open the till every time. How can we somewhat not have a heavy impact on operations while being able to emulate some enforcement of things that a covenant would enable. The incentive to attack is higher for businesses because usually businesses have much more money than individuals. When we are talking about an exchange we are talking about some having cold storage with more than a billion dollars of Bitcoin behind a single private key. This is insane. This is what we have today in terms of security. You would be really surprised how bad security is in Bitcoin today, at least in key management today.

What most people use today is multisig. Let’s say 2-of-3, m-of-n. Usually you don’t have n-of-n because that would mean if one party loses their key the entire fund is locked. That is a big problem. You have ways to mitigate that with proper backups and things like this. What you mostly see in businesses is a multisig m-of-n. That can be done in house like some exchanges do or that can be done with a third party like BitGo for example. Then you also have the cold storage with frequent access which kinds of defeats the purpose of cold storage. Most of these are often delegated to a third party. You have a lot of businesses today that exist just to provide custodial solutions for other businesses in Bitcoin. They charge a lot of money for that. At the end of the day these custodians also need to secure the keys somehow. We are back to the same problem. How are they keeping the keys? Is it just a multisig? What size of multisig? Is it just a cold storage? How is it kept? You always have a problem there. They would say they have insurance but insurance is not a security solution here.

Revault

Let’s start talking about Revault. In Revault we are trying to solve a lot of things at the same time. It started with a hedge fund contacting us. This hedge fund wanted to be capable of self hosting their own custody without impacting their operations. They also have this interesting thing that they have only a subset of active traders while the other ones are the partners in the fund. They wanted some security that would enable having the maximum security possible without impacting their operations. Revault covers up to N-1 participants being compromised. This is pretty cool. Compared to for example a BitGo 2-of-3, in a 2-of-3 you cannot sustain N-1 because you only need 2 keys to spend the funds. Revault is still secure until you have every single key being compromised. We also have physical threat mitigation. If somebody were to threaten all the participants in our scheme at the same time we still have things to partially protect the funds, a small part of it could be stolen. But we still have a partial mitigation even with N keys being compromised which is quite interesting I think. We also have a very low operational overhead. I will show you how. In Revault it is approve by default. Every spend is approved by default but can be cancelled. Instead of having to ask agreement every time to all the stakeholders. There is a bypass possible in case of emergency. That means for example you see the price of Bitcoin mooning or crashing and you need to move the funds right now. You don’t want to enforce the timelocks we have which would be a few hours. If all the participants want to and they are not under threat then they can move the funds without being encumbered by the timelocks we have. This is very interesting for the hedge fund for example. Then we have the panic button that sends the funds into the Emergency Deep Vault. As you will see later in the slides the Emergency Deep Vault is basically a different address that is more secure than the most secure address we have in our vault system. In our case we have a N-of-N. The Emergency Deep Vault should be harder than that to spend. That could be N-of-N plus a long timelock, separate the keys into different geographical locations, N being bigger than the original N. A lot of things like that. This is a way to escape the architecture if anything goes wrong. To avoid sending back the funds to the vault it goes to a completely different security solution. Another thing different from other models and other proposals out there is that the funds are secure from the time of deposit in Revault. We don’t have an intermediary wallet that needs to put the funds in the vault. For us deposit equals secure. The deposit is a 4-of-4, N-of-N as you will see.

We are not covering an insider locking the funds, refusing to sign. This is something that is possible. If they don’t sign the funds cannot move. That is fair. The only way to bypass somebody not signing would mean we cannot have the N-1 participant compromise here. Maybe the one not signing is the only guy that is not compromised. We cannot bypass that. We have partial mitigation though. It doesn’t mean the funds would be locked forever, it is only a limited amount of the funds that would be locked. Then a little harder would be an insider burning funds, deleting their private key and deleting all backups of their private key. Deleting the Emergency Deep Vault keys, this could happen if somebody got really mad they could delete every single key and backup of keys they have. Depending on how the vault is designed the funds might be lost forever. This is something to have in mind when deploying such an architecture.

This is a graph that we have of what it looks like. I will try to explain it slowly. I know it is a lot, it is quite heavy. I will do my best. We have deposit transactions that create outputs. These outputs are already vaults. As I said before the funds are secure from the time of deposit. These deposits, let’s say you are getting money from an exchange or a client is sending you money, the address you are giving them is already encumbered by a N-of-N multisig. That will be what we call the V, the vault UTXO. To spend from this UTXO you would need a transaction that we call the Unvault transaction or you would need the N participants agreeing and sending the funds out of the vault. That is what I called the bypass before. If there is an operational emergency where the funds need to move right now without a timelock the N participants can use it and spend the funds. That would not be possible if we had key deletion but we do not have key deletion right now in Revault. When you have a deposit, when you receive funds in a vault we need the N participants to pre-sign a set of transactions. Typically they would do that once a day. In the morning they come to the office and every one of these N participants in his routine would have to check if there had been any deposits. If there has been then he should pre-sign the transaction for that. The transactions to be pre-signed are the two emergency transactions, one from the vault directly and one from the transaction that we spent from the vault. He also needs to sign a Cancel transaction which is a transaction that spends from the Unvault transaction and sends it back to a vault. I know it is quite weird if you have never seen vaults before. This is now quite common, it is a clawback. If you have never seen something like that before I know it is kind of weird. We are pre-signing these 3 transactions, the 2 red ones and the orange one. After that we sign the blue one here, the Unvault transaction. Then we keep these 4 pre-signed transactions somewhere safe. If somebody wants to spend funds, let’s say the traders or whoever is authorized to spend funds, he crafts a normal transaction that we call the Spend transaction. This transaction is actually timelocked because it can only spend from the output of the Unvault which enforces a timelock. The only difference in operations is that when the person authorized to spend is doing his transaction he will have to wait a few blocks to have his transaction mined. In the meantime, during this timelock we can have a watchtower or one of the participants triggering a Revault transaction, a transaction coming back to a vault. Or an emergency transaction sending all the funds to the Emergency Deep Vault. The thing that is out of the architecture if something really goes wrong.

Just to clarify what it looks like. These vaults are encumbered by N-of-N. You need all the participants to sign to move them. This is what we use to actually pre-sign the transaction. They use this path. The emergency that goes down here is pre-signed with these N keys. This Unvault transaction is pre-signed with these N keys. This Unvault transaction also looks like this. It is pre-signed and it has two conditions. Either M out of N, M can be anything from 1 to N, that’s the authorized people. Then you have co-signing servers that Antoine will talk about to fix a specific attack against our architecture. And OP_CSV that enforces the timelock. Either we have this subset of authorized people that need to wait for a timelock or we have all the participants agreeing. This N-of-N is not really to used by people. It is just to trigger the pre-signed Cancel and Unvault transactions that are using these N signatures. I think that is as far as I can go in explaining this. Lastly the Emergency Deep Vault (EDV), the conditions to spend from it are just strictly harder than M-of-N. This is the only condition we have. The obscurity in this is important. An attacker from the outside trying to steal your money while scheduling an attack. It is already pretty hard to steal from this but if on top of it he doesn’t any idea of how hard the EDV is to spend from, maybe it will require even more than the N participants, this is a very strong deterrent against an attack.

This looks very complicated but most of it is automated. You don’t have to manually do all of this. The process looks like this. You receive a deposit. This is already protected behind a N-of-N. You are fine even if you don’t sign it it is ok, nobody can steal these funds. At some point all stakeholders will need to pre-sign the Emergency, Cancel and Unvault transaction. That would be maybe done every morning. That makes the funds spendable. It is like confirming that they have been deposited. From this list of UTXOs that are pre-signed now any authorized person can create a spending transaction. It looks like a normal transaction. They can spend it wherever they want. It is just that they will have a timelock that will let any of N stakeholders or watchtowers they control in case there is something wrong with the spending transaction, it will let them Cancel or Emergency Deep Vault the transaction. That is what the process looks like. Funds are deposited, nobody can spend them until all stakeholders have seen it. Once they have been pre-signed it looks like a normal wallet that has a timelock on top of it for the spender to be able to spend.

It is cool for multiple reasons. It is cool because we don’t need to know any amounts in advance. There is no deletion of private keys here. We can reuse addresses, if it happens it is not a problem. Pretty much anything is possible. It doesn’t prevent us from receiving deposits even if there is no pre-signed transaction made in advance. This is different from any of the key deletion proposals because you would need to pre-sign the whole tree before depositing money in it. You would need to put the exact amount as a deposit because that would change the txid otherwise. We don’t have this problem. We can backup seeds. We don’t have to backup transactions as such. Even if one of our pre-signed transactions is lost we can still resign it with the keys. The backups we need are only for seeds for these different private keys. We don’t delete private keys. That is pretty easy to safe keep today. The proposal with the key deletion would have to have a backup every time they pre-sign a transaction. Otherwise losing the pre-signed transaction is losing the funds. Day-to-day operations are only impacted by a delay. The only difference for the normal person to use this architecture is that the funds are not going to be confirmed before x amount of blocks. We are trying to reach the security level of N-of-N although only a subset of these would be the person creating the spending transaction. To emulate that everybody is still agreeing we have watchtowers and things like this. Antoine will cover that later. Also we have the extra Emergency Deep Vault in case a lot of these keys are compromised. We can still move all the funds outside. Lastly it is open source which is pretty cool I think. There is no third party risk because there is no third party. Everything should be self-hosted. If you want to deal with third parties it is only to add security on top like using watchtowers.

Bob McElrath: Antoine was just clarifying for me where the timelocks are. The Unvault transaction has a CSV on it. The Spend transaction has a CSV. The Deposit transactions do not correct?

Only the Unvault has a CSV. The Spend is only delayed by this OP_CSV. The Spend transaction is just going out. Out is a UTXO, it is not a transaction. The timelock is enforced by the CSV. The Sequence is in the Spend tx.

Bob McElrath: The purpose of the timelock on the Spend transaction should have been to send that Spend transaction back to the emergency vault. But there is no second branch there on the Spend transaction?

For us the Spend transaction is exactly like here. The delay is between the Unvaulting and the Spending. The clawback happens at the time of the Unvaulting being published. The reason for that is we enforce through the co-signing servers that the Unvault transaction is not pushed if the co-signers have not seen a Spend transaction child before. That means that we emulate that the distance between these two transactions is OP_CSV because if an Unvault transaction has been mined without the participants knowing about the Spend transaction that will spend from it then we trigger automatically a Cancel transaction. It is to enforce that we have the full delay to cancel the spending if needed.

Bob McElrath: What I would have called the receiving wallet on the left, the Deposit transactions, this is a standard N-of-N wallet. There are not timelocks there, no scripts. I believe in our paper we call this is a “Receiving wallet” because everything else that is happening here is part of a protocol. The participants need to know what are the steps, what is going on there. In order to start the protocol you have to have full control. You can’t expect someone to deposit into a timelocked vaulted scripted transaction very easily. What have you done allows you to construct the Unvault transactions in the way you want. There are some interesting properties here. Those Unvault transactions can be for instance tranched. Let’s say you want to make ten Bitcoin tranches for different traders or something like that.

We could. In our design, although I don’t fully remember what yours is made of, we considered that each vault is a completely different thing. Different UTXO, different address, different everything. But yes we could branch out in the Unvault. I don’t think it is something we really want to do because we can have change going back to a vault or anything if needed. At least at the script level here we are not enforcing amounts. We leave that to watchtowers looking at the protocol or even the co-signers if they have some restrictions on the co-signing.

Antoine Poinsot: This is one point of using the co-signing servers. To leave the maximum flexibility for the Spend transactions to not have to commit to the amounts or the addresses so it can change. We don’t need to change the Unvault transaction.

The first one, the N-of-N here is a normal N-of-N. There is no other restriction on it. But we consider this to be the highest level of security in the architecture because the N is not the normal amount of people required to spend they money. The Spend transaction here would usually be M-of-N. The N-of-N is a lot of people, much more than would be used in a normal multisignature because they don’t have to do any special work. In the morning they have this deposit process happening and they just need to pre-sign the things. A normal company using a normal multisig for this would be using M-of-N for the spenders. We are just trying to add new signatures on top going back to N even if they are not part of the usual spending people. Increasing the security to a bigger multisig.

N-of-N doesn’t allow for any redundancy. Have your clients been happy with that? Do they want to insert a threshold there in the first step?

The N-of-N doesn’t have redundancy here because they should have proper backups and key management in place. In the M-of-N for this spending our original client asked to have a subset of traders and only 2 out of 3 traders should be required to spend the money. Just in case one of them is unavailable. We have done more complex than this generalization.

Q - Which exchanges are best? This is referring to one of your earlier comments about the exchanges’ cold storage set ups not being great at the moment. Do you have any insight into what those set ups actually are because obviously they are shrouded in secrecy because there are hundreds of millions of dollars?

Secrecy is a big part of it. Also it is very hard to know even if it is a single key securing your funds. It could be just a single key but you don’t know how it is secure. It could be secured in a HSM, hardware security module, where no one can extract the key. Having a single key is not necessarily a bad thing if it is properly secured. You can go to the other extreme “I am a company and I am using BitGo, I have 2-of-3 I am very secure.” Not really because you have 2 out of the 3 keys yourself. You have your normal key and you have your backup key in case BitGo goes offline for example. In that case you are a single point of failure. Anybody can come to you and get these 2 keys quite easily. It is really hard to say that more keys is more secure. It really depends on how you manage those keys.

Bitcoin fun Revaulted (Antoine Poinsot)

I am going to talk about some fun we had while designing it and challenges encountered. Specific things about why we ended up with this architecture.

Pre-signed transactions fun

The first challenge we encountered is a very common one which we have been discussing a lot for the Lightning Network. How to get pre-signed transactions confirmed in a timely manner for multiparty contracts. Our security models on our Revault transactions to be enforceable at any time. We need to find a way for transactions to pay the right fees according the fee market when we want to broadcast them. We could use something like the update_fee message currently used in the Lightning Network protocol which asks our peer to sign a new commitment transaction with us as the current fee rate increases or a new one when the fee rate decreases. We can’t trust the other parties to sign the transaction. Firstly, because they might be part of the attack. With vault we are talking bid only so they have a strong incentive to take the vault money and act badly and refuse to sign a Revault transaction. Secondly even if they are honest it would just require an attacker to compromise one party to prevent a Revault transaction being executed. Finally they may not be able to sign it in the first place. They may have their HSM available. In addition it would require them to draw their HSM each time there is a fee rate bump. This is just not practical. We are left with either using anchor outputs, what has been planned for the Lightning Network or letting each party attach inputs to the transactions aka bring your own fees. We went for the second one.

At first we leverage the fact that emergency transactions have just one input and one output. We use SIGHASH_SINGLE safely because if there is a difference between the number we may encounter the SIGHASH_SINGLE bug. This allows any party to bump the fee rate by adding an input and output to the transaction. Or if the transaction already has fees at the time of broadcast just replace a SINGLE ANYONECANPAY with a SIGHASH_ALL signature before broadcasting. Unfortunately this opens up a possibility for transaction pinning as we allow any stakeholder to attach a new output paying to themselves. This will allow them to decrease the CANCEL transaction fee rate while we want them to add a high input and a low output. They just could add a high output and low input to take all the fees of the transaction and keep it above the minimum relay fees. They could also pin the transaction in the mempool as the output is just paying to themselves according to BIP 125 rules. We went for SIGHASH_ALL ANYONECANPAY signatures to be exchanged between the stakeholders because they would commit to all the outputs and thus would not allow any party to add an output paying only to themselves. They cannot anymore pin the Revault transaction itself in the mempool. Nor can they decrease the transaction fee. This adds a burden on the fee bumper because they need to create a transaction if the input is too big and they want a change output. They need a fee bump transaction to attach as inputs of the Revault transaction. The worst case here is that the fee bump transactions can still be pinned by a change output from an attacker. By the second rule of the RBF BIP the unconfirmed input would not be replaced in the Revault transaction. Even in this worst case scenario the party bumping the fee rate could create either a high fee rate fee bump transaction and wait for it to be confirmed in the next two blocks. We can expect the Unvault transaction to have a CSV of 15 at least. It will be confirmed and then the BIP 125 second rule will not apply anymore. I have described it more in detail in my mailing list post.

Optimization / standardness fun

Revault is very customizable. We wanted to study the maximum number of participants for all the transactions to still be standard. The response is of course it depends. It depends mainly on the Unvault script as it is very customizable and the policy can be different depending on the use case of each user. For the Vault script the best one I could come up is this one which would allow 100 participants before meeting the max standard script size for the pay-to-witness-script-hash (P2WSH). This is a standardness limit on the script which is hashed in the witness program version zero P2WSH. It is applied on the inputs when you want to pay to the P2WSH.

Then for the Unvault script as there are too many combinations I arbitrarily took the number of subset members, the traders, to be half of the number of the participants overall. With such a script which the co-signing servers for the N parties who don’t sign the transactions still sign, the maximum number was 68. With other combinations we could also hit a limit on the number of push opcodes. Then on the onchain footprint I had a script which would make raw approximations on how it would cost to use the architecture. If I remember correctly it was about 1000 weight units for 3 traders and 6 overall participants. That is quite reasonable. Unfortunately I don’t have a graphic of all the values but it is on the GitHub on another branch.

Oracle fun

Then there are the co-signing servers. In my opinion co-signing servers are one of the biggest trade-offs of the architecture. They are a trusted oracle and you need one for each party not signing the spend transaction. Otherwise this party is just trusting the member managing the funds or the other co-signing servers. It is costly and it is online. It is costly because it adds signatures. Even in the worst case scenario where all co-signing servers are compromised and all the M parties the spending transactions still allow a race because the spending transaction is forced to signal for RBF because of the CSV. The big question was how to get rid of them?

We thought of a way to eliminate the co-signing servers without the obvious one which is N=M, all the day-to-day participants are managers so you don’t need co-signing servers. Otherwise you can pre-sign pinned transactions but you can’t always because you need the set of addresses to exist, be known in advance and to be small enough. For each destination you need to know the set of amounts you want to send in advance. That is really not practical in general but still can be applied in specific cases.

We thought about covenants in the Unvault transaction so it can only be spent by a Spend transaction. In any way it is spent by a Spend transaction but all covenants would commit to the amount and destination, either with CHECKTEMPLATEVERIFY or SIGHASH_NOINPUT. It would commit to the amount in the Unvault output at the time of signing. It would commit in advance and that is just not practical. We thought about key deletion but as we discussed you can’t prove that you deleted keys.

Covenant fun (BIP 119 way)

We thought about covenants. We can use a covenant like CHECKTEMPLATEVERIFY to have the Vault transaction commit to the Unvault transaction. This would really be a vault as the vault output could just be spent by an Unvault transaction and could not be bypassed. Maybe Kevin could argue that is not a feature because sometimes it is nice to have a multisig and be able to bypass the architecture. But it is a bit more secure. Unfortunately we can’t use CHECKTEMPLATEVERIFY to get rid of the co-signing servers.

Covenant fun (BIP 118 way)

For SIGHASH_NOINPUT’s covenants it is the same. I didn’t explain in the last slide but to have a covenant with SIGHASH_NOINPUT there is a nice scheme in which you pay to a signature. In the vault script there is a pay-to-witness-script-hash which is paying to a signature that is only valid for an Unvault transaction. Since this a SIGHASH_NOINPUT only the outputs of the transactions will be hashed. This forces the transaction spending the Deposit transaction to specify an output such as the Unvault. It is really nice. It is more flexible than CHECKTEMPLATEVERIFY. It is a a little bit less efficient but it is the same principle. Like CHECKTEMPLATEVERIFY it could be used for the Vault transaction but not for the Spend transactions. It would not eliminate the need for signing servers. For both CHECKTEMPLATEVERIFY and NOINPUT covenants we need a new step at set up. We can’t expose addresses with covenants such as CHECKTEMPLATEVERIFY to the public because the address will be reused no matter what we hope. If they are used with an amount less than the previous one for CHECKTEMPLATEVERIFY or SIGHASH_NOINPUT covenant the Bitcoin would be lost. If it is reused for a higher amount all the Bitcoin more than the amount would go to fees.

Covenant fun (key deletion)

We also talked about key deletion with Jacob Swambo and Bob McElrath. Kevin was interested in the Bryan Bishop architecture that uses key deletion. It isn’t provable to the other parties. You don’t care if the output pays to a N-of-N multisig. This is what Jacob came up with when we were talking with him. If this is for N-of-N outputs like the Vault script if you just delete your key you know it won’t be spendable anymore. The pre-signed transactions are effectively a covenant.

It is possible to apply this to Revault but unfortunately it adds a lot of complexity. For example you can’t have a Cancel transaction anymore or you have to sign a lot of pre-signed transaction sets. If the keys for the Vault outputs are deleted and the only way to spend from the Vault is the Unvault transaction the obvious way would be to have the stakeholders broadcast the Vault, have it cancelled and a new output with non-deleted keys appeared. To resolve this you could have deleted these keys and created the signatures for all the next transactions but this adds complexity. We want it to be really practical and we are not convinced of the feasibility of having key deletion for a practical protocol.

BIP fun

Finally Revault is not the only proposal. There are further proposals, CHECKTEMPLATEVERIFY and SIGHASH_NOINPUT, ANYPREVOUT, you can do covenants without key deletion. This is less costly. But it is not required at all for Revault. There are BIPs for Taproot and Tapscript which would bring strong cost optimization and would hide the Cancel transaction path because it is a 4-of-4 but unfortunately not the Spend path because the Spend is not pre-signed so you have to enforce the locktime in the Unvault output script. It has to be revealed in order to spend from the Unvault. We are more eager to see progress in reducing mining centralization such as Stratum version 2. It is at the base of all security assumptions, to have a Revault transaction that confirms. That is why we have complicated schemes to pay honest fees but we need to account for miners as attackers in our architecture. We need to account for miner censorship. If it is too centralized it can be censored.

Is Revault good?

Is Revault good? It is really simple in appearance. It is designed for practical use and for people using Bitcoin today to use something more secure. It is not good but it is better than what is used today. For example it would allow higher threshold multisig at the root of the architecture for the Vault script. Without the flexibility, without this co-signing server stuff we would have lower threshold multisig at the root. Some stakeholders don’t want to have the burden of signing all Spend transactions.

Q&A

Bob McElrath: Since you mentioned NOINPUT there is a way to do deleted keys in a safe way if you have NOINPUT. That is by using ECDSA key recovery. Basically the idea is you generate the signature first and from that you compute the pubkey. You can only do that if you have NOINPUT. There is a mechanism there that could be used with NOINPUT. This is how you prove that you deleted a key. You provide a hash preimage of the signature itself as a binary string. This is now the nothing up my sleeve signature. Unless I can break the hash function or break the elliptic curve discrete log problem I could not have generated that signature even if I had the private key. However this doesn’t work, the NOINPUT/ANYPREVOUT proposal puts the ANYPREVOUT in a Taproot script. This additionally commits to the pubkey at signing time. As the proposal stands now this won’t work. If you do have NOINPUT generally there is a way to prove you deleted keys.

Antoine Poinsot: That is very interesting. I thought a lot about how to make the spenders commit to the amount in the address at spending time. This would create a cyclic hash.

Bob McElrath: That’s exactly the problem. It creates a cyclic hash. That is why you need NOINPUT because the cyclicality comes from the txid committing to the addresses on the previous output which are functions of the pubkey. That is why it doesn’t work.

Michael Folkson: Kevin said that if you were to set up a watchtower for this Revault design the watchtower would potentially be broadcasting either a Revault transaction or an Emergency transaction. Is that right?

Kevin Loaec: That is right but it is being discussed. I don’t agree with Antoine on this. In my vision the watchtower should only broadcast the Revault transaction and they should not have an Emergency transaction. My standpoint for that is the Emergency transaction is such a burden. In our architecture we assume that if one Emergency transaction is broadcast then all the other ones should also be broadcast. All the funds within the architecture should move at the same time to the Emergency Deep Vault wallet. To me that is a problem because the watchtowers should be trustless. We have this problem that if somebody starts triggering one Emergency transaction it completely breaks the system at least for a few weeks or months. I don’t know how difficult it would be to recover from the Emergency Deep Vault. That would be a massive denial of service type attack. If any of the Emergency transactions can be stolen then you force everybody to go dig up their emergency keys. You need to wait however long the timelocks are. It could be a very strong attack against us if an Emergency transaction is out in the wild. While the Cancel transaction is not really a problem. It is just go back to a Vault. The next step is to Unvault which is fine.

Antoine Poinsot: We argue but it is ok, we will agree later. My point on this is that Revault differs from a normal N-of-N multisig due to the Emergency transaction which is a significant deterrent against threats. To keep this deterrent you need to have all the parties including the external watchtowers to be able to broadcast the Emergency. The network watchtowers of each stakeholder might be known while the external watchtowers might not be. We need this to ensure some specific attacks don’t succeed.

Michael Folkson: You haven’t built out a prototype watchtower for this design because you are still finalizing exactly what the watchtower would need to look out for?

Antoine Poinsot: We don’t agree yet but we don’t have an implementation either. We just have a demo, in the demo there are just the network watchtowers. It was just a proof of concept for running functional tests.

Michael Folkson: I think Bryan (Bishop) said last week in the Socratic that he was in the same boat. He hadn’t really thought about the watchtower component.

Kevin Loaec: On the topic of the watchtower I would like to add something that maybe wasn’t explained clearly. The Unvault transaction, the one coming after the Vault, should not be broadcast before the participants of the co-signers have seen the Spend transaction first. First we need to know where the funds are going and then we are releasing the parent of the Spend transaction. That is also part of the job of the watchtowers. If they see on the Bitcoin network there is an Unvault transaction being mined but they are not aware of what the Spend transaction looks like this might be an attack. If we don’t where the Spend transaction is going to then we should trigger a Cancel transaction. Part of the job of the watchtowers is also to look at the network and see that if there is an Unvault that is broadcast without knowing where the Spend transaction is going to bring the funds, then automatically we should trigger a Revault transaction by default. It is not too heavy on the process because there is no timelock in there. It is going back to the vault and we just need to pre-sign the Unvault again. That could be done in one block if needed. The protection it brings is really high. The role of the co-signer like Antoine said is that we have an attack that is possible and is also possible in Bryan’s design that he published. Assuming we know where the Spend transaction is going to go the Unvault transaction is mined, at the exact block where we lapse the CSV there could be a race condition between the Spend transaction and an attacker’s Spend transaction if he has all the M of N keys. That’s why we needed to add the co-signers. We wanted to a very dumb automated server that signs only once per UTXO. That avoids a double spend at the exact time of expiration of the locktime. That is why we added the co-signing server. The solution that Bryan has is deleting the keys and putting a maximum percentage of funds you can spend each cycle. For us it is a different compromise. As of today we haven’t found an alternative to co-signing servers sadly but they do serve a real purpose.

Michael Folkson: I saw some very big numbers in terms of multisigs. This is for designs other than your first client where potentially they would want 50, 60, 70 signers? It seems weird to me that you would want to set up a vault with so many signers rather than just the key board members.

Antoine Poinsot: This was just something I measured so I wanted to talk about. Maybe someone would want to do this but no I don’t expect someone to use 68 party vaults. Technically they can on Bitcoin and have their transactions be relayed.

Kevin Loaec: It is important to look at the modularity of the architecture because we are targeting institutions but two companies don’t have the same requirements. From an exchange to a hedge fund to a company we have very different need of liquidity and security. Some companies have very few stakeholders and one guy doing the finances. If it is about moving the cold storage of a few billion dollars maybe you want to have a very big set of keys. We just wanted to study how big it could get. Not that we want necessarily to implement it at that size but at least we know the theoretical limits. It is just a number. Even for that Antoine had to make some assumptions as he said in his slides. He is taking M of N, M being half the size of N. That could be anything from 1 to N. That could even be different participants. The size is pretty irrelevant depending on how many people, co-signing servers, different participants we want to have. It is very modular and we just want to study how big it could get. The reason for that is that the Unvault transaction, you have two branches and depending on how we implement it the branch for cancelling a transaction is heavier in terms of signatures than the first branch. If we have less co-signing servers than participants for example. Let’s imagine we only have one person that needs to sign a transaction to spend it and we only need one co-signing server that is going to be two signatures. That is fine. It goes through Bitcoin. What if the transaction we pre-sign for the Revault or Emergency has 120 signers? Then this a non-standard transaction so we can never recover the funds. That would be quite problematic. We could sign a transaction that would not be accepted by the network. It is very important for us to know what are the theoretical limits of the network because if the network doesn’t relay our Emergency transaction, too bad.

Antoine Poinsot: The limit I was talking about was policy and not consensus.

Michael Folkson: You said “heavier branch”. An alarm went off in my head, Miniscript. Have you been using Miniscript to get the optimal script by using the weights of the different branches.

Kevin Loaec: Yes and no. I started doing it and then the requirements for our client didn’t work out with Miniscript. Miniscript doesn’t factorize the same keys. If you have M-of-N it works. But if you start having different branches with the same key in different branches Miniscript doesn’t optimize on that. Manually it was much easier to reduce the size and the cost of the transactions by looking at alternative ways that what can be described in the Miniscript language. We were stuck because Miniscript doesn’t realize that if you put A A A as three different public keys it doesn’t realize that it is the same public key. It is not trying to optimize the weight of the transaction for that which is annoying.

Michael Folkson: It can’t identify that the pubkey that has been repeated is the same. That’s the only thing that Miniscript didn’t have that forced you to not take advantage of Miniscript?

Kevin Loaec: I think so.

Bob McElrath: This is relayed from my collaborator Jacob Swambo. Can you talk about your development roadmap for the various components and how other people in the ecosystem could participate? I know you guys have a GitHub with your Revault demo but there are other pieces here like watchtowers, management of pre-signed transactions etc. Can you talk about your development roadmap, what the moving parts are and what needs to be developed?

Kevin Loaec: I will let Antoine answer that but just to start. There are different things there. Watchtowers in my opinion should be as generalized as possible. We shouldn’t just have one implementation of watchtowers in my opinion. The way watchtowers are designed, it is not required to be all the same implementation. Everything else is open source.

Antoine Poinsot: We need to hire other people and raise some funds in order to create a company. We expect it to be a year to create a first product. We expect to achieve that but we don’t know if we will be able to raise funds.

Michael Folkson: In the Socratic last week we talked about transaction pinning problems. Jeremy Rubin was saying that a lot of the problems are unlikely to be solved in the short term because there needs to be a total rearchitecting of the mempool in Bitcoin Core. Any views on that? How much understanding do you have on the mempool in Core and how much is that going to be a problem going forward?

Antoine Poinsot: I don’t want to make strong statements about it because I haven’t been contributing much to Core. I know the inner workings of the mempool and a complete refactoring as Jeremy said last week would be great for all off-chain protocols actually. There are other attacks and transaction pinning for Lightning Network that was found about two weeks ago. I don’t know. It is hard. I think I understand the position of the developers of Bitcoin Core, you need to keep it stable and refactoring the whole thing out is a strong choice to make. We try to use the tools we have today. I think the ANYONECANPAY is not that bad. I think it is pretty workable because there is only one restriction which is really low, the second rule from the RBF BIP. I think we can work it out without refactoring for us. But for the network it would be great.

Michael Folkson: It is interesting that there is transaction pinning and watchtowers, quite a few parallels in terms of the challenges posed to Lightning and vaults. I suppose you are well placed Antoine to be working on both.

Kevin Loaec: That is why I went to Antoine in the first place. Just working on OP_CSV on Bitcoin is a nightmare today. It should be very simple because it was implemented in Core a long time ago but you can still not do your own CSV transactions with Core. It is really hard to find proper tools for that. When looking at Lightning developers every single one has been playing with this because it is a requirement for Lightning. To me the requirement was finding people who have experience working with CSV because it is really important.

Bob McElrath: One other topic I will bring up is the statechain conversation that has been going on the bitcoin-dev mailing list also needs watchtowers. I see a generalized watchtower concept coming. If people are interested in that it is something to work on. At least three different ways to use it: Lightning, vaults and statechains.

Kevin Loaec: Watchtowers are really great because if used properly they don’t add any risk. Using more of them, as many of them as you can, increasing your security without decreasing anything. This is quite exceptional. It is very rare in Bitcoin. Usually when you add security somewhere you are creating new risks. Watchtowers are I think the exception in Bitcoin which is really cool.

Michael Folkson: In an ideal world if you were to raise funds and you could spend more time on this and hire more people would you do a CHECKTEMPLATEVERIFY version of Revault?

Kevin Loaec: Today no because in my opinion you should not spend too much time developing a product that requires something that is not in Bitcoin today. This is really risky, you don’t know what will change. You don’t even know if it will be added to Bitcoin at any point in time. It is even valid for very big things like Schnorr. Some people were saying more than a year ago it will be in within 6 months. It wasn’t. Bitcoin takes time. If you developed a really cool multisig system on Schnorr, Taproot whatever great for you but this doesn’t work today. The risk is way too high. If you want to think about a business the risk is too high to use tools that don’t exist today. That is probably the main reason why we wouldn’t even work on a proper implementation that would be production ready before CTV or NOINPUT are added to Bitcoin.

Antoine Poinsot: In my talk when I talked about CHECKTEMPLATEVERIFY it was at a very high level. I didn’t tweak it or even test that it works. It seems to fit the need but I’m not sure, it was just high level.

Michael Folkson: I think Bryan said he had done a CTV prototype. Perhaps if you had the budget you would look at where the design would go in the future but spend most of your resources on what is in Bitcoin currently?

Kevin Loaec: Bitcoin is great for that. There might be different uses for the same thing. Watchtowers are one of them. There are already a few companies working on watchtowers. These companies should be some of the early targets to help us work on these problems. We can probably do everything in house but that is not the point if other people already are working on really cool stuff it is really good to help each other. Also I think it is starting to be more and more common that companies in Bitcoin do their product open source. Sadly in custody that is not the case. You are not going to find many tools open source outside multisig wallets basically. That is not great. When you are dealing hundreds of millions of dollars there is no backend that is open source today for securing that. That is not normal. Maybe vaults in general could help pave the way forward to start to have visibility on how it works at custodians.

Michael Folkson: I suppose it is whether you want security in obscurity or whether you want a battle tested open source solution?

Kevin Loaec: In Bitcoin and other open source projects we talk about obscurity being the enemy of security. That is ok for everything online. As soon as you work towards physical threats, obscurity is always stronger at least for now. This is a problem that we have in security in general. It is easier to protect yourself if people don’t know the layout of your house. It is easier to protect yourself if they don’t know whether you have a gun or not. This is also the case with hardware security modules. This is the big debate. Is Trezor better because it is open source or is Ledger because it is using a closed source thing? Attacking a device that is not open source is really hard because you need equipment that costs a lot of money. But has it been reviewed enough, is there a backdoor? It is always a compromise somewhere. Typically when it is about physical security obscurity is a great asset.

Michael Folkson: If someone is interested in learning more or contributing to Revault in the future what would you advise?

Kevin Loaec: It depends. If somebody really wants to move forward on just the idea of vaults I think right now it is good we know each other. Dealing with Bryan, Bob, Spencer, Jacob, it is a really small crowd. I think we are getting on well with each other. Hopefully we can keep moving forward in reviewing each other’s work and contributing to each other’s work. Every security product needs a lot of auditing and review. If you are putting millions of dollars on it you need to make sure it is working. As you have seen in this presentation there are a lot of edge cases, weird things around fees and transaction pinning. Things that people don’t look at usually. We need to keep digging because maybe we are missing a massive point. Miners as well are important. Usually we assume the mining is secure, we are only thinking about the script. But the script is not everything. Bitcoin still has human players and as Antoine was saying if the miner is the attacker what do we do? It is starting to be much harder. There are a lot of things that we need to look at. Not just on the development side it is also on the architecture side. For the architecture right now we are looking at building a Rust implementation. That could change. There are more and more people contributing to Rust as well which is good. Square Crypto is contributing a lot which is good as well. Maybe we will start seeing a bigger and bigger Rust community in Bitcoin. Reaching out to us would be good as well. Right now raising funds for us is a way to go because we really want to put that into production. There are a lot of vault proposals over the years but sadly none of them are available as a product. The best we can find today is a Python demo. This is cool but not something you would put your money on. At the very beginning at this project when I reached out to a few people my idea was to set up a non-profit foundation to sustain the development while the users, the exchanges and other companies should have a subscription with this non-profit. That could be a good way to go for the very long term. But in the short term the paperwork for that and figuring out who would be a subscriber is much more annoying than just generating normal revenue through invoicing. Invoicing is how can you customize Revault for us. That is a service we can provide. All work is done open source so we can release the software to everyone. For us that is the way to go right now. A private company and later we will see. But definitely everything is open source and no intellectual property as such behind it.

Michael Folkson: The sales pitch is that whenever we have a bull market there are going to be tonnes of smaller custodians that are going to need a solution like this. It is not just going to be the big exchanges.

Antoine Poinsot: We even thought about ATM operators. Even small players.

Kevin Loaec: Another thing I want to add is that I don’t understand why there are so few physical attacks in Bitcoin. The security of many businesses in Bitcoin is really low. I am not saying that people should do this but it is really impressive that there are still people going into your house to steal your TV which is much harder to resell rather than going to a Bitcoin business to steal their Bitcoin. We are very lucky that for eleven years we had only a few physical attacks. I don’t think it is sustainable. If there is another big bull market we will see more criminals entering the space. We need better security. Even if it is just better multisig, we need better security than we are using today. To me it is more that than just the price going up. It is the risk going up. This is not good. I don’t feel really safe even though I have good key management. I would like to have more options such as cancelling transactions even in a personal wallet. If I send Bitcoin to somebody how many times are you checking that the address is right? How many times are you checking that the amount is right? We put some pressure on us when we could have a button to allow us to claw it back in one hour or whatever. There are a lot of things I would like to see.

Michael Folkson: I don’t have any more insight than you but I have heard that exchanges have very complex cold storage solutions. It is complex physical security rather than complex software security or taking software security to its full potential. Bob can you answer Antoine’s question on what you think about miner censorship of revocation transactions? I also saw that you dropped a paper today. Perhaps you could summarize that you published with Bryan, Jacob and those guys.

Bob McElrath: Miner censorship of transactions like that is a 51 percent attack. It only works if they have 51 percent of the hashpower. If that is the case game over all around. There is really nothing you can do about that. As to our paper we dropped our paper today. This is the first of two papers. The second will focus more on the mechanisms for deleting keys. The first one is an architecture that is similar to Revault what uses deleted keys instead of the multisig. Happy to have this conversation continue and come up with some interesting solutions.

Michael Folkson: What were the key findings of the paper?

Bob McElrath: This paper is not so much a findings kind of paper, it is more of an engineering kind of paper where we describe an architecture and analyze some of its security properties.