Hello Devs,
I am Praveen and I am the inventor of CoinVault, a new second layer protocol and technology that makes Bitcoin and other similar altcoins `Unstealable and Unlosable` for all practical purposes. Tall claim, but I will get to the details in a bit.
Before that, here is a little context to set the perspective…
I was introduced to Bitcoin by a friend in 2017 and realized how late I was to the party.
Bitcoin Cash's block size debate was a hot topic then and so were many hacks and heists affecting various cryptocurrency exchanges across the world.
I personally did not like the idea of increasing block size to accommodate more transactions and also thought that Cold Storage and Multi-Sig security for Hot Wallets (BitGo) is just the beginning.
We thought micro and high frequency transactions should ideally be handled by intermediaries who settle balances periodically, while larger transactions and settlements happen directly on Blockchain. Even if Lightning Network handles all micro-transactions, we cannot completely rule out all intermediaries and we still need exchanges, etc. to interface with the offline world. This felt like a healthy compromise while preserving the spirit of Bitcoin.
But given the security requirements and concerns surrounding Bitcoin and other cryptocurrencies, any kind of pooling in the hands of any intermediary such as an exchange, wallet, escrow, etc., makes it a hot target for hackers.
To mitigate this problem, me and my fellow compatriots set out to create a safer way to store cryptocurrencies both for individuals and enterprises.
After nearly two years of brainstorming and toiling we have come up with CoinVault, a second layer technology, that can ensure the safety and security of Bitcoin and other cryptocurrencies for both large and small entities.
Any and every feedback will help us iterate and serve the ecosystem better. We are all ears for your comments and suggestions.
-----------------~~~~~~~~~~~~~~~-----------------
Dr. Praveen Baratam
Background:
Cryptocurrencies in general are both acquired and traded on an electronic exchange that lists different cryptocurrencies/crypto-assets often with other assets such as fiat currencies issued by central banks of various countries and enables trading between them. Most of these exchanges are custodial in nature and act as trusted third parties where trading parties transfer both cryptocurrencies and other assets in their control/possession to the exchange controlled addresses/accounts and get notional limits on the exchange to trade. All this works well as long as there is no security breach on the exchange.
Since most cryptocurrencies are secured by public-key encryption which is knowledge based, any security breach on the exchange’s systems can be disastrous. And any adversary gaining access to exchange’s private-keys can irreversibly steal the cryptocurrencies in its custody leading to huge loss of wealth for trading parties and loss of trust within the ecosystem. We have seen this scenario playout with many cryptocurrency exchanges all over the world at some point or the other and approximately 15 Billion USD worth cryptocurrencies were stolen from them as of Dec 2017. This has become the Achilles heel of the cryptocurrency world off late.
Over time cryptocurrency exchanges have evolved several strategies such as Hot-Wallets coupled with Cold/Offline Storage, Multi-Signature arrangements with third-parties that serve as gatekeepers to enforce limits on transactions, insurance for hot funds, etc. But most of these strategies have proved inadequate and/or were circumvented over the past few years by increasingly sophisticated attacks. eg: BitFinex lost $71 Million USD worth of Bitcoin in spite of Multi-Signature arrangements with BitGo.
The same is true for Custodial Cryptocurrency Wallet Services, hereafter referred to as Cryptocurrency Wallets, that store users’ funds/tokens with them and allow their users to make transactions like a bank. They then settle these transactions on their users’ behalf. Most Cryptocurrency Exchanges also double up as Cryptocurrency Wallets for their users allowing transacting parties to pay/accept in cryptocurrencies/assets of their choice and managing the conversion for them when necessary.
There is an urgent need for securing cryptocurrency exchanges and wallets to prevent further losses and bolster general faith in the cryptocurrency ecosystem.
Solution:
The following describes an arrangement and method, in its simplest form, between two parties (First Party and Second Party where the Second Party is acting as Secure Cryptocurrency Exchange and/or Wallet for the First Party) participating in a cryptocurrency network/system to effectively reduce the probability of loss or theft of the First Party’s funds/tokens while guaranteeing settlement between trading/transacting parties by the Second Party. Hereafter, the term Cryptocurrency Exchange, shall also imply Cryptocurrency Wallet wherever relevant.
The method presumes that unrecoverable hardware wallets (or rendered unrecoverable by not-recording / discarding the backup/seed) without any provision for recovery of the private-keys/secrets stored inside it in case of loss or malfunction of the device, hereafter referred to as hardware tokens, and time-locks for transaction outputs are available for the crypto-currency system of interest. Relative time-locks (CheckSequenceVerify) similar to the one described in Bitcoin Improvement Proposal 112 are more desirable than absolute time-locks (CheckLockTimeVerify) similar to the one described in Bitcoin Improvement Proposal 65. The subsequent discussion assumes relative time-locks are available for the cryptocurrency of interest even though similar functionality can be devised using absolute time-locks too.
The method and arrangement proceeds as follows:
At inception, the First Party creates a transaction similar to the one depicted in Figure 1, hereafter called the Deposit Transaction, in which the First Party transfers an arbitrary sum of funds/tokens in its control to a multi-signature address but does not yet sign or broadcast it. The multi-signature address in the Deposit Transaction requires the following signatures to authenticate and spend/transfer from it:
First Party’s Private Key generated Signature
First Party’s Hardware Token generated Signature
Second Party’s Private Key generated Signature
Then, the First Party creates a second transaction, hereafter referred to as Provisional Transaction, as depicted in Figure 2, spending all the funds/tokens sent to the multi-signature address in the Deposit Transaction, and sends a copy of the Provisional Transaction without any signed inputs or signatures, to the Second Party. Please note that the Provisional transaction is spending from an unconfirmed Deposit Transaction.
Then, the Second Party adds its Private Key generated signature to the unsigned Provisional Transaction received from the First Party and then sends the partially signed Provisional Transaction back to the First Party.
In the meantime, the First Party also adds its Private Key generated signature and the signature generated by the hardware token in its possession to the unsigned copy of the Provisional Transaction it created and sends the partially signed Provisional Transaction to the Second Party.
Note: The signatures used in this scheme sign the transaction similar to SIGHASH_ALL or SIGHASH_SINGLE in BitCoin protocol where the corresponding output of the transaction cannot be modified once signed.
At this point in time, the First Party is in possession of the partially signed Provisional Transaction with Second Party’s Private Key generated signature added to it and the Second Party is in possession of the partially signed Provisional Transaction with First Party’s Private Key generated signature and the signature generated by the hardware token in First Party’s possession added to it.
Then, the First Party signs and broadcasts the Deposit Transaction it created to the cryptocurrency network/system completing the setup process. The whole process in outlined in Figure 3.
Once the Deposit Transaction is confirmed, both First Party and Second Party start monitoring the Cryptocurrency network directly and/or using third party services for transactions referencing the Multi-Signature output address described above from the Deposit Transaction to detect any breach of security or foul play.
Subsequently, the First Party, at its discretion, can add its Private Key generated signature and the signature generated by the hardware token in its possession to the partially signed Provisional Transaction with the Second Party’s Private Key generated signature and broadcast the fully signed Provisional Transaction to the cryptocurrency network/system when necessary.
Similarly, the Second Party can add its Private Key generated signature to the partially signed Provisional Transaction with the First Party’s Private Key generated signature and the signature generated by the hardware token in possession of the First Party and broadcast the fully signed Provisional Transaction to the cryptocurrency network/system when necessary.
To sum it up, either parties can add missing signatures to the partially signed Provisional Transaction in their possession and broadcast them when necessary.
As soon as the Provisional Transaction is broadcasted, the cryptocurrency monitoring systems prompt both parties to initiate recovery if it is not broadcasted by them to begin with. Either ways First Party or the Second Party in coordination with the other or optionally unilaterally create and broadcast a transaction using the respective options of the Provisional Transaction transferring the funds/tokens to a desired address terminating the arrangement.
Description
Cryptocurrency Exchanges act as custodial escrow agents for the trading entities participating on their platforms to minimize counter party risk and guarantee settlement. However, this escrow mechanism, with respect to cryptocurrencies, creates a new problem of keeping third party funds/tokens in their custody safe and secure. A security breach on the respective Cryptocurrency Exchanges’ systems can compromise the private-keys securing the funds in its custody and lead to loss/theft of respective funds/tokens.
In the proposed scheme/arrangement a Cryptocurrency Exchange can enforce settlement albeit with a predefined delay and does not need exclusive custody of the said funds/tokens beforehand to guarantee settlement. Moreover, in the event of a security breach on one or both sides, there are remedial steps that the Cryptocurrency Exchange and/or First Party can take to prevent loss or theft of respective funds/tokens.
Generally, First Party will cooperate with Second Party in the settlement process and in situations where it disagrees or refuses to cooperate, the Cryptocurrency Exchange (Second Party) can get exclusive custody of the respective funds/tokens and enforce settlements as per the terms of the contractual service agreement with the First Party.
For instance, when the First Party is in disagreement with a proposed settlement for a trade, the Cryptocurrency Exchange (Second Party) can use the Option 2 as depicted in Figure 2 and take exclusive custody of the respective funds/tokens to enforce settlement. This option allows the Cryptocurrency Exchange to function as a regular custodial escrow between trading parties as is the case with most exchanges and in general.
In another instance, if a Cryptocurrency Exchange suffers a security breach and its private-keys are compromised/stolen, it can use Option 1, 2, 3, 7 or 8 depicted in Figure 2 to transfer the funds/tokens to another secure address or back to the First Party as may be desired. Cryptocurrency Exchanges can even prevent loss/theft using Option 7 depicted in Figure 2 and transfer the respective funds/tokens away from the compromised address even when its hardware tokens are lost/stolen in the above described situation.
Also, the Cryptocurrency Exchange (Second Party) can use Option 2 depicted in Figure 2 and transfer the respective funds/tokens to a secure address when First Party’s private-key and/or hardware token are compromised/lost/stolen.
The Confusion Matrix in Figure 4 enumerates the options available and outcomes of situations where private-keys and/or hardware tokens of First Party and/or Second Party are compromised or stolen. It also enumerates situations where respective private-keys are lost by First Party but not Second Party.
Since Second Party is an organized entity that can employ data-safety measures such as multi-site replication, offline storage, etc. this method does not explicitly specify the process and enumerate options available when Second Party’s private-keys are lost for simplicity and brevity. This method can be analogously extended to this scenario and more or simplified if desired by reordering,adding or removing options in the Provisional Transaction accordingly when planning and accounting for certain contingencies are deemed necessary or unnecessary. Also the timelocks mentioned in the Provisional Transaction are one of the many possible values for them exemplifying a particular order and can be adjusted as necessary to suit a particular arrangement.
It should be noted here that the Second Party always gets first claim on the respective funds/tokens as it is accepting a liability on First Party’s behalf and can steal First Party’s funds/tokens but will not do so because such unilateral actions will result in loss of trust/business from other parties as well as legal proceedings by the First Party. Hence, the incentive and motive to cheat the First Party of its funds/tokens by Second Party is non-existent. But if First Party and/or Second Party are compromised either by an internal or external adversary, they still have recourse and can reconcile the situation by taking remedial steps available.
Finally, even if Hardware Tokens are not available and we have to rely on relative/absolute timelocks only, the method and scheme described above can be scaled down as depicted in Figure 5 and still offer better protection than currently practiced multi-signature arrangements.
https://www.youtube.com/watch?v=yDvLqTv1FDg