{"id":19606,"date":"2019-08-08T02:54:59","date_gmt":"2019-08-08T02:54:59","guid":{"rendered":"http:\/\/ci027cfe78e0102697"},"modified":"2025-01-27T21:34:37","modified_gmt":"2025-01-27T21:34:37","slug":"revamped-idea-bitcoin-vaults-may-end-exchange-hacks-good","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/revamped-idea-bitcoin-vaults-may-end-exchange-hacks-good","title":{"rendered":"This Revamped Idea for \u201cBitcoin Vaults\u201d May End Exchange Hacks for Good"},"content":{"rendered":"
<\/div>
<\/figure>\n

Storing private keys securely can be challenging. This is of course true for ordinary users, but it can be just as true for large-scale custodians: The thousands of bitcoin stashed on exchanges present a juicy mark for hackers, and the seemingly endless list of multimillion-dollar thefts is a painful testament to the risks that come with this solution.<\/p>\n

But a technical measure to counter heists could be on the way. Today, Bitcoin Core contributor Bryan Bishop published<\/a> a revamped proposal for \u201cBitcoin Vaults,\u201d an idea first proposed in 2016. Through a clever smart-contract setup, Vault users could react to a theft by reclaiming the funds, hopefully disincentivizing theft in the first place. What\u2019s more: None of this requires any changes to the Bitcoin protocol.<\/p>\n

\u201cWhat\u2019s exciting about this to me \u2014 and we still need to evaluate this and test it \u2014 is that this might be a reliable way to limit losses from theft,\u201d Bishop told Bitcoin Magazine<\/em>. \u201cI think this could go a long way toward changing the landscape in Bitcoin for exchange hacks and personal bitcoin storage.\u201d<\/p>\n

The Bitcoin Vaults Backstory<\/h3>\n

The concept of Bitcoin Vaults dates back to at least 2016, when researchers from the University of M\u00fcnster (Malte M\u00f6ser) and Cornell University (Ittay Eyal and Emin G\u00fcn Sirer) proposed<\/a> a solution to lock up coins in such a way that a theft could temporarily be reversed.<\/p>\n

In simplified terms, M\u00f6ser, Eyal and Sirer\u2019s Bitcoin Vaults were designed with special Bitcoin addresses that would have two private keys attributed to them: one \u201cVault Key\u201d and one \u201cRecovery Key.\u201d The Vault Key would be used to spend coins, while the Recovery Key could be used to reverse the transaction for some specified period of time.<\/p>\n

If an attacker were to steal the Vault Key, they wouldn\u2019t be able to get away with the money. Assuming the Vault creator still has access to (a copy of) the Recovery Key, they would have, say, a day to reclaim the funds to the special Bitcoin address after the attacker tried to move the coins.<\/p>\n

Even in a worst-case scenario, in which the attacker steals both the Vault Key and the Recovery Key, they wouldn\u2019t be able to steal the funds: These could be reclaimed indefinitely. Unfortunately, in that case, the Vault creator would be unable to get the coins out of the Vault as well, since the attacker could block this, too. Neither would get the funds.<\/p>\n

Still, the inability of the attacker to walk away with a big payday would be a strong disincentive for them to even try and steal coins, M\u00f6ser, Eyal and Sirer argued.<\/p>\n

\u201cAn attacker who knows that he will not be able to get away with theft is less likely to attack in the first place, compared to current Bitcoin attackers who are guaranteed that their hacking efforts will be handsomely rewarded,\u201d they wrote.<\/p>\n

M\u00f6ser, Eyal and Sirer\u2019s solution did have a big drawback, however: It required changes to the Bitcoin protocol. Their Vaults were designed around \u201ccovenants,\u201d a proposed update to Bitcoin\u2019s code that would enable the return of funds. It\u2019s difficult to get such consensus-level upgrades adopted \u2014 and so far this one hasn\u2019t been.<\/p>\n

Bishop\u2019s Vaults: A Step-by-Step Explanation<\/h3>\n

The idea behind Bishop\u2019s Vault solution shares functional similarities with the earlier Vault proposal, but importantly it doesn\u2019t require any changes to the Bitcoin protocol.<\/p>\n

To understand how it works, it\u2019s best to look at how Bishop\u2019s Vault solution is set up in three steps.<\/p>\n

As the first step, at least three transactions are created but not yet broadcast to the Bitcoin network.<\/p>\n

The first transaction is called the \u201cVault Transaction.\u201d The Vault Transaction will \u201clock up\u201d the coins in such a way that it can be \u201cunlocked\u201d only with a specific private key.<\/p>\n

This specific private key is then immediately used to create and sign the second transaction, which is called the \u201cDelayed-Spend Transaction.\u201d There are several strategies behind constructing this Delayed-Spend Transaction. But as a general example, it would allow the coins to be spent in two ways. First, the coins could be spent with a \u201cregular\u201d private key, but only after, say, a day has passed. This regular private key is controlled by the Vault creator in their \u201chot\u201d (not particularly secure, but practical) wallet. Or the coins could be spent immediately, but only with another private key.<\/p>\n

This other private key is, in turn, immediately used to create and sign the third transaction, which is called the \u201cRe-Vaulting Transaction.\u201d The Re-Vaulting Transaction sends the coins to a backup address or to a new Vault.<\/p>\n

The backup address can also be set up in a number of ways, but it is preferably extra secure, even if that means it\u2019s less practical to use. For example, its private key could be generated on a different computer and stored in a physical safe somewhere. It could also be a multisignature address of which the keys are dispersed over different locations or perhaps shared between multiple people trusted by the Vault creator.<\/p>\n

Whichever setup is chosen, it can also be constructed as a new (potentially more complex) Vault. And this new Vault, in turn, could also be designed to have an \u201cemergency exit\u201d through a new Vault. And so forth.<\/p>\n

In the second step of the setup process, the private keys used to create the Delayed-Spend Transaction and Re-Vaulting Transaction are deleted altogether. This means that the private keys cannot be stolen any longer \u2014 not even by the most sophisticated hacker: They no longer exist. As a result, the coins in the Vault Transaction can only ever be unlocked with the Delayed-Spend Transaction. The coins in the Delayed-Spend Transaction, in turn, can only ever be unlocked with the regular private key after a day, or with the Re-Vaulting Transaction, sending it to the backup address or new Vault.<\/p>\n

In the third and final step of the setup, the Vault Transaction is broadcast to the Bitcoin network. The coins are now in the Vault, and the Vault creator should guard his Delayed-Spend Transaction and Re-Vaulting Transaction as if they were private keys.<\/p>\n

If the Vault creator wants to spend the coins, they need to broadcast the Delayed-Spend Transaction. Then, they just need to wait a day before they can spend the funds with his regular private key in his hot wallet.<\/p>\n

\u201cIn my proposal, the user has to store more data and make sure they have that data available in the long-term, otherwise they lose access to their Vault,\u201d Bishop said. \u201cBut this is sort of similar to \u2018if you lose your key then you lose your coins\u2019 anyway.\u201d<\/p>\n

The Attacks<\/h3>\n

The Vault creator still has sensitive data that could potentially be stolen. This includes his regular private key, as well as the Delayed-Spend Transaction and Re-Vaulting Transaction. Yet, even if a hacker gets his hands on all of these, they won\u2019t be able to spend the funds.<\/p>\n

Let\u2019s see why.<\/p>\n

If the attacker steals the regular private key alone, they cannot access the coins, as they are still locked up in the Vault Transaction. Getting the coins out of the Vault Transaction requires the Delayed-Spend Transaction.<\/p>\n

But even if the attacker does manage to get their hands on both the regular private key and the Delayed-Spend Transaction, they won\u2019t be able to steal the coins \u2014 assuming the Vault creator is paying attention. (The Vault creator could also make use of a \u201cWatchtower\u201d service that pays attention for them.) If the attacker broadcasts the Delayed-Spend Transaction, they\u2019d have to wait a day to spend the coins with the regular private key.<\/p>\n

In the meantime, the Vault creator can broadcast the Re-Vaulting Transaction, which would send the coins to a backup address or a new Vault. If the attacker hasn\u2019t also compromised the keys to the backup address or the new Vault, the funds are secure again \u2014 though perhaps stored in a less-convenient manner now (like a multisig address).<\/p>\n

Even if the attacker also compromises a potential new Vault, it won\u2019t help them much. The same events would play out, and the Vault creator would once again send the coins to their backup address or new Vault. The sequence of backup Vaults can be as long as the Vault creator wants, with all types of complex setups to prevent the attacker from compromising them all.<\/p>\n

If the attacker were to steal the Re-Vaulting Transaction \u2014 either in combination with the regular private key and the Delayed-Spend Transaction, or not \u2014 they also couldn\u2019t steal funds. The Re-Vaulting Transaction can only be used to block withdrawals. However, depending on the setup, the attacker could, in this case, sometimes stop the Vault creator from spending the funds, too. <\/p>\n

In some worst-case scenarios, in which all the Vault creator\u2019s sensitive data stolen, the Vault creator and the attacker could end up in loop where they keep trying to block each other’s withdrawal attempts. (This could be resolved with a “self-destruct” feature, more on this below.)<\/p>\n

Remaining Weaknesses<\/h3>\n

While Bishop\u2019s Vault design could be a big step forward for security, it\u2019s still not 100 percent foolproof against thefts or losses. Some of the remaining weaknesses can be resolved, either partly or entirely \u2014 but it would come with a trade-off.<\/p>\n

Perhaps the most obvious design trade-off is that creating more backup Vaults also means creating more sensitive data. The Vault creator needs to safeguard more keys and transactions, perhaps in more places, increasing the risk that they\u2019ll lose some of it. On the flipside, if they create less backup data, or don\u2019t store it in as many places, it increases the risk that the attacker gets their hands on all of it, letting them block withdrawals.<\/p>\n

\u201cThe problem with using unique keys [for each backup Vault] is, where are you going to store this data? If you store it all together then you might as well use identical keys,\u201d Bishop explained. \u201cBut if you store it in multiple places (one per unique key) then you\u2019re going to run out of secret spots to store your data.\u201d<\/p>\n

As a sub-optimal solution to this problem, the Vault creator could build a \u201cself-destruct\u201d feature into their Vault. After some number of new backup Vaults \u2014 maybe 3, maybe 100 \u2014 the last Re-Vaulting Transaction wouldn\u2019t actually send the funds to a new Vault. Instead, it would send the coins to a \u201cburn address\u201d with no private key. This locks up the coins forever, so neither the Vault creator nor the attacker nor anyone else would ever have access to it again. Per M\u00f6ser, Eyal and Sirer: Building in a self-destruct feature would be a strong disincentive for a potential attacker to even try and hack the Vault.<\/p>\n

A very different problem<\/a> is that a hacker could steal the regular private key \u2014 but not do anything with it until the Vault creator gets their funds out of the Vault with their Delayed-Spend Transaction. While both the Vault creator and the attacker would then have to wait a day to spend the funds, the attacker could still get the money if, after this timeout, they\u2019re faster to react than the Vault creator.<\/p>\n

This problem can probably be solved as well \u2014 at least partially. For example, the Vault creator could design a \u201cstaging\u201d system in which no more than, say, 1 percent of funds can be withdrawn from the Vault per day, either through a series of timelocks or a series of new Vaults. If a batch of 1 percent is stolen, the Vault creator knows they need to use the more secure backup address to get their funds out. Alternatively, the regular private key could be funded with some bitcoin as \u201cbait.\u201d If those coins are stolen, the Vault creator also knows to use a backup address or a new Vault to get their funds out.<\/p>\n

Lastly, it\u2019s worth noting that the proposal has only just been published, and peer review is ongoing. Bitcoin Magazine<\/em> discovered this last weakness today, in the course of writing this article. Further potential weaknesses might still surface.<\/p>\n

\u201cThat\u2019s the value of getting proposals peer reviewed,\u201d Bishop said. \u201cIt only makes them stronger, points out problems, etcetera.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"

The potential to reclaim stolen funds.<\/p>\n","protected":false},"author":2509,"featured_media":7568,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[227,2373,2606,1428],"class_list":{"0":"post-19606","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-core","9":"tag-bryan-bishop","10":"tag-hacks","11":"tag-protocols"},"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/latest-vault-idea-may-end-bitcoin-exchange-hacks.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19606","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=19606"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19606\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/7568"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=19606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=19606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=19606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}