As described in the first part of this thesis, non-simulated shared ownership of any scarce asset, but especially of a libre sound money is a groundbreaking achievement. With this new technology at our disposal, there are countless new solutions to known problems, and probably even more solutions to unknown unknowns. The following list is mere an early compilation of interesting use cases, and not at all exhaustive. It is up to individual entrepreneurs to evaluate client problems, judge possible solution and build the services desired. These use cases might serve as inspiration for peers to evaluate the means available and which possible ends they could serve. As non-scarce knowledge they will be copied, adapted for unique needs and manifested through human action to remove uneasiness.
Alice and Bob have a joint account used for every day spending of petty cash. The signature of either one of them is sufficient to send the coin, thus no collaboration or communication between the two is necessary. Any one of them can at any time, for any reason, spend all the bitcoin locked in this script. This is very convenient for every day transactions, but it requires a large amount of trust, since both of them could turn rogue and run away with the money, and there is no defense against this. Further, if only one of them gets compromised by a malicious hacker, he can equally steal the funds without recourse.
Alice and Bob have a joint account used for long term savings. Both signatures are required to spend the funds, this requires coordination and communication for the signing ceremony. If either one of them is unavailable, the funds cannot be spend. This is thus true shared ownership of the bitcoin, since two separate individuals need to give their explicit consent to transact. This approval process might not be convenient for recurring payments, and thus it is more intended for long hodling of the coins. Since even the loss of one private key leads to indispensability, it is very much recommended to keep several backups in diverse secure locations. In the case of a malicious hacker gaining access to one of these keys, the funds are still secure, and there might be enough time to move them to a new script with fresh keys.
In order to protect against the leaking of one non-scarce private key and to increase the redundancy and security, Alice can require a second factor signature from another private key in a 2-of-2 multisig. Alice alone generates two private keys, she generates and stores one on her phone and the other on her hardware wallet. Now she requires access to both devices in order to spend the funds, thus an attacker needs to compromise both at the same time. In the case that a malicious actor gains undue access to only one of her devices containing the private key, this is not enough to spend the coins. The chance that a hacker is breaking both of her devices is several orders of magnitude more difficult. This also highly increases the defense against a malicious hardware provider, since two independent manufacturers need to collude. However, in the case that Alice looses only one of her devices and private key, she looses access to the bitcoin which would rightfully be hers. It is as impossible for her to spend the UTXO with only one key, as it is for a malicious actor. There is no redundancy to protect against key loss.
Thus, n-of-n second factor authentication is a valid defense against the leaking of private keys to unwanted malicious actors. They need to gain access to n private keys in order to have full control over the UTXO, the difficulty exponentially increases as n increases. Especially when Alice stores the private keys in different devices, in different location and with different protocols. However, the n-of-n script does not protect in the case where Alice herself looses access to even only one of the private keys. She can lock herself out of her own money, and this risk increases, as n increases. Although, this is also the case for a single signature script, once that one key is lost, the money is locked indefinitely. The trade off for the n-of-n scheme is thus the number of n in relation to the attackers sophistication to break all n security protocols, and the likelihood of Alice herself to loose only one of n keys.
Alice and Bob are the parents of Charlie, and they have a child savings account where all three have one key. The parents would like to pass on with “warm hands” some of their wealth to their heir and to teach him the importance of decreased time preference through savings. Charlie alone cannot spend the funds, but he requires the approval of either one of his parents. In the same manner, one of the malicious parents or a hacker cannot alone spend the funds, but they always require approval of either their son or partner. The parents are protected against unwise spending of their son, and Charlie is protected against attempted theft of one of his parents. In the case of loss of one private key, the other two can still collaborate to produce a valid signature script and spend the coin into a fresh multisig with a new key setup.
Alice wants to purchase a good from Bob, but they wanted to protect against the first-mover disadvantage. Charlie can be as the trust less escrow of a 2-of-3 multisig. Every one of them generates a unique private public key pair, one signature alone cannot validate the script, it always requires the collaboration of two signers. Alice sends the amount of bitcoin agreed upon previously to an UTXO with this redeem script. Bob will wait until these funds are confirmed and verify on his full node. He now has absolute proof that Alice has the bitcoin, and is willing to spend them. Even further, he now has shared ownership in this coin, requiring only the collaboration of one of the peers to gain the full control over it. Bob will now give Alice the good she desires and he will build and sign a transaction spending the multisig coin and generates his own singlesig UTXO. Only when Alice has a secured control over the good and verified its quality will she also sign that proposed transaction and broadcast it to the Bitcoin network. In this collaborative case, Charlie as trust-reduced escrow is not needed, he might not even know that he was part of the scheme. But when malicious Bob does not hand over the good, Alice will call on the judge and request his analysis of the case. Charlie will verification that Bob is indeed malicious, and then co-sign with Alice a transaction giving the bitcoin back to her. On the other hand, if Bob has given malicious Alice the good, but she refuses to pay, Bob can appeal to Charlie who will judge in his favor and co-sign a transaction paying Bob. In order to protect against denial-of-service attacks an upfront escrow from Alice and Bob might be added to the multisig address. In the case of attempted fraud, the judge will release that deposit to the victim. To ensure Charlie’s honesty Alice and Bob might also require a security bond from him. Charlie himself alone cannot steal the funds. The decentralized and self-hosted bisq exchange [1] has been successfully using this smart contract to secure millions of trades.
It would also be possible to include a time out condition that the bitcoin can be spend by the original owner, after a certain time window has passed. This can further reduce the need for collaboration with the third party arbitrator, because in the malicious off-line case, the victim can simply wait for the time out to pass, and then spend the funds without anyone else’s interaction.
Redeem Script for time locked escrow:
IF
IF
2
ELSE
<1000 blocks> CHECKSEQUENCEVERIFY DROP
<Public Key 1> CHECKSIGVERIFY
1
ENDIF
<Public Key 2> <Public Key 3> <Public Key 4> 3 CHECKMULTISIG
ELSE
<3000 blocks> CHECKSEQUENCEVERIFY DROP
<Public Key 1> CHECKSIGVERIFY
ENDIFThe main risk of n-of-n multisig is that the loss of only one key leads to a complete loss of funds. Although this is very secure against malicious actors trying to steal money, it does not protect Alice from herself loosing access to one single key. A m-of-n script can provide further benefits that neither single, nor n-of-n multisig have.
In order to secure hot wallet funds Alice can generate two private keys, generating and storing one on her hot hardware and the other one as a cold storage. The security specialist Bob will have the third key on a hot wallet. Alice can assign a `2-of-3v multisig script to a UTXO, such that she can only spend the coin with a total of 2 signatures. Every time Alice wants to make a payment she builds the transaction with the multisig as input and signs it with her hot key. Then she sends the partially signed Bitcoin transaction to Bob who will only sign the transaction if some predetermined conditions are met. This can be some two-factor authentication, or in-person verification, or a white listed and blacklisted addresses, or some maximum value in a given time period. Only when all of the agreements are met will Bob sign this transaction with his hot wallet key. If Bob realizes that Alice has been compromised then he will refuse to sign the transaction. It is important to note that the spending conditions are not only simulated and rely on the trust in an honest Bob.
If Bob becomes unavailable, or fails to uphold his promise to co-sign, then Alice can get her second key out of cold storage and sign the transaction all by herself. She does not need to cooperate with Bob in order to spend her money, without any other party, she has full control over that coin. Bob alone cannot spend the money, he does never has full control over the coin, and thus no property rights in it. A 2-of-3 multisig has the same anti theft protection as a 2-of-2 multisig. The attacker needs to gain access to both Alice’s phone and hardware wallet, or one of them in addition to the cold storage. However, in the case that Alice looses one of her every day keys, let’s assume her hot wallet, she can get her second key out of cold storage, and use it together with Bob’s hot key. She can decrease the risk of loss of private keys drastically with such a script.
The m-of-n multisig script provides simultaneous protection against theft and loss of private keys. The malicious actor needs to gain access to m, not n, private keys in order to generate a valid spending transaction. This provides the same level of protection as a m-of-m multisig script would. However, contrarily to n-of-n scripts, Alice can afford to loose n-m private keys before she herself looses access to the UTXO. She can have m convenient and easy to use keys, like mobile and hardware wallets, which she can interact with for every day spending. For redundancy however, she also has n-m cold storage keys, which are difficult to access, for example a paper wallet hidden in a remote safe. She only needs to reveal these keys in the case where she looses access to some of the every day keys. However, the UTXO is locked when she m private keys are lost, same as with a m-of-m multisig script.
The five peers Alice Bob Charlie David and Eve work on the same project and have a low trust 3-of-5 multisig. Each of them holds one key and they need collaboration of any of the three peers in order to spend the bitcoin. This reduces the threat of embezzlement, hacking and loss of two keys. Since it is provable on the time chain which private keys have signed the transaction, there is accountability after the fact. [2] This is especially useful for decentralized and non-hierarchical projects where peers have a the convenience of collaboration without full consensus for every transaction. This setup retains spend-ability for up to the loss of two keys, yet it is also secure for up to two malicious peers.
Alice wants to pay 10 different peers, yet the current transaction fee level is high, and she estimates it will decrease in the future. She wants to commit to the payment now, yet pay the fee for the final transaction at a later point in time. Alice requests the public keys of all 10 receivers and builds a large 10-of-10 multi signature script. She builds an unsigned and unbroadcasted setup transaction, with her own UTXO in the input, and the 10-of-10 multisig and her change output. The value of the multisig coin is the total sum of all the 10 payments she is sending. Then, she creates a distribution transaction, which spends the multisig UTXO and creates the 10 different UTXOs with the individual public keys of the receivers. Alice then requests each of the receivers to sign the distribution transaction, and she ensures that each co-signer has a valid signature of all the peers. Only then does she sign and broadcast the setup transaction, to get confirmation with a relatively low fee. The receivers are now certain that at any time one of them can broadcast the signed distribution transaction to receive the money. Yet they can delay the distribution transaction until the fee for block space has decreased.
Setup transaction [signed after distribution tx]
[i] Alice signature | [o] 10-of-10 multisig
| Alice shangeDistribution transaction [signed first, broadcasted later]
[i] 10 signatures | [o] Bob pubkey
| Charlie pubkey
| ...
| Kai pubkey