Contracts
Contracts are transactions that leverage the decentralized BitcoinEvo platform to enforce financial agreements. These contracts are often structured to reduce reliance on third parties, such as the legal system, thus significantly lowering the risk associated with engaging in financial deals with unknown individuals.Introduction
The following subsections will describe a variety of BitcoinEvo contracts already in use. Because contracts deal with real people, not just transactions, they are framed below in story format.Escrow And Arbitration
Charlie-the-customer wants to buy a product from Bob-the-businessman, but neither of them trusts the other person, so they use a contract to help ensure Charlie gets his merchandise and Bob gets his payment.A simple contract could say that Charlie will spend satoshis to an output which can only be spent if Charlie and Bob both sign the input spending it. That means Bob won’t get paid unless Charlie gets his merchandise, but Charlie can’t get the merchandise and keep his payment.
This simple contract isn’t much help if there’s a dispute, so Bob and Charlie enlist the help of Alice-the-arbitrator to create an escrow contract. Charlie spends his satoshis to an output which can only be spent if two of the three people sign the input. Now Charlie can pay Bob if everything is ok, Bob can refund Charlie’s money if there’s a problem, or Alice can arbitrate and decide who should get the satoshis if there’s a dispute.
To create a multiple-signature (multisig) output, they each give the others a public key. Then Bob creates the following P2SH multisig redeem script:
OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG(Opcodes for pushing public keys onto the stack are not displayed.)
OP_3 specifies that three public keys (unhashed) are being provided. This is a 2-of-3 multisignature (multisig) pubkey script, more broadly referred to as an m-of-n pubkey script (where m is the minimum number of required signatures and n is the total number of public keys included).
Bob shares the redeem script with Charlie, who verifies that both his own and Alice’s public keys are part of it. After verifying, he hashes the redeem script to create a P2SH redeem script and makes the payment to it in satoshis. Bob observes the payment being recorded in the blockchain and then sends the merchandise.
Unfortunately, the product arrives with minor damage. Charlie demands a full refund, while Bob insists that a 10% refund is adequate. They both turn to Alice to mediate the disagreement. Alice requests photo evidence from Charlie, along with the redeem script that Bob prepared and Charlie approved.
After reviewing the evidence, Alice concludes that a 40% refund is fair. She then creates and signs a transaction with two outputs: one that sends 60% of the satoshis to Bob’s public key and the other that transfers the remaining 40% to Charlie’s public key.
In the signature script, Alice includes her signature and a copy of the unhashed serialized redeem script that Bob initially created. She sends an incomplete version of the transaction to both Bob and Charlie. Either one of them can finalize it by adding his own signature, resulting in the following signature script:
OP_0 [A's signature] [B's or C's signature] [serialized redeem script]OP_0 [A’s signature] [B’s or C’s signature] [serialized redeem script]
(Opcodes for pushing the signatures and redeem script onto the stack are not shown. OP_0 is used to handle an off-by-one error from the original implementation, which must be preserved for compatibility. The signature script must present signatures in the same order as the corresponding public keys appear in the redeem script. Refer to the “OP_CHECKMULTISIG” section for more information.)
When the transaction is broadcast on the network, each peer verifies the signature script against the P2SH output that Charlie initially funded, ensuring that the redeem script matches the previously provided hash. The redeem script is then evaluated, using the two signatures as inputs. If valid, the two transaction outputs become available as spendable balances in Bob’s and Charlie’s wallets.
However, if Alice were to create and sign a transaction that neither Bob nor Charlie agreed with — such as one sending all the satoshis to herself — they could simply choose a new arbitrator. They would sign a transaction that moves the funds to another 2-of-3 multisig redeem script, which would include the public key of the new arbitrator. This ensures that Bob and Charlie never have to worry about their arbitrator taking their funds.
Micropayment Channel
Alice also works part-time moderating posts on Bob’s forum. Every time a post is submitted to Bob’s busy platform, Alice reviews it to ensure it isn’t spam or offensive content. Unfortunately, Bob often forgets to compensate her, so Alice insists on being paid immediately after each post she approves or rejects. Bob argues that making numerous small payments would lead to high transaction fees, costing him thousands of satoshis, so Alice proposes using a micropayment channel to avoid this problem.Bob requests Alice’s public key and sets up two transactions. The first one allocates 100 millibitcoinevos to a P2SH output, which requires both Alice’s and Bob’s signatures in a 2-of-2 multisig redeem script. This is known as the bond transaction. Broadcasting this transaction would give Alice control over the millibitcoinevos, so Bob keeps this transaction private for the time being and moves on to the second transaction.
The second transaction sends all the millibitcoinevos from the first transaction (minus the transaction fee) back to Bob, with a 24-hour delay enforced by locktime. This transaction is referred to as the refund transaction. Bob is unable to sign the refund transaction by himself, so he sends it to Alice for her signature, as shown in the illustration below.
Now, when Alice completes a task worth 1 millibitcoinevo, she requests Bob to create and sign an updated version of the refund transaction. This second version sends 1 millibitcoinevo to Alice and returns the remaining 99 millibitcoinevos to Bob. It does not include a locktime, allowing Alice to sign and spend it whenever she chooses. However, she doesn’t spend it immediately.
Alice and Bob continue this process, repeating the work-and-pay cycle, until Alice finishes her work for the day or the time lock approaches expiration. Alice then signs and broadcasts the final version of the refund transaction, paying herself and returning any leftover balance to Bob. The next day, when Alice resumes her work, they can set up a new micropayment channel.
If Alice fails to broadcast a refund transaction before the time lock expires, Bob can broadcast the initial version and receive a full refund. This is one reason why micropayment channels are most suitable for small payments — if Alice’s internet connection goes down near the time lock’s expiration, she risks losing her payment.
Another concern, as discussed earlier in the Transactions section, is transaction malleability. If someone exploits transaction malleability to disrupt the link between the two transactions, Alice could end up holding Bob’s 100 millibitcoinevos hostage even if no work was completed.
For larger payments, the transaction fees on BitcoinEvo are already quite low relative to the total transaction value, so using immediately-broadcast separate transactions is a more secure way to protect such payments.
CoinJoin
Alice is concerned about maintaining her privacy. She knows that every transaction is recorded on the public blockchain, meaning when Bob and Charlie pay her, they can easily track the movement of those satoshis. They could potentially find out which BitcoinEvo addresses she sends funds to, how much she spends, and even estimate how many satoshis she has left.Alice isn’t doing anything illegal; she simply wants plausible deniability regarding her spending patterns and remaining balance. To enhance her privacy, she activates the Tor anonymity service on her computer and logs into an IRC chatroom under the pseudonym “AnonGirl”.
In the chatroom, she meets two other users, “Nemo” and “Neminem”. They all agree to mix their satoshis together to prevent outsiders from identifying who controls which funds. However, they face a challenge: who will transfer their satoshis first without risking theft? The CoinJoin-style contract, illustrated below, provides the solution: they create a single transaction that spends all their satoshis simultaneously, ensuring none of them can steal from the others.
AnonGirl signs her inputs using SIGHASH_ALL, ensuring that no one can alter the input or output details. She then sends the partially-signed transaction to Nemo, who signs his inputs in the same manner before passing it to Neminem. Neminem adds his signature and broadcasts the completed transaction to the BitcoinEvo peer-to-peer network, effectively mixing all the millibitcoinevos in a single transaction.
As demonstrated in the illustration, no one besides AnonGirl, Nemo, and Neminem can determine with certainty who received which output. This allows each of them to spend their outputs with plausible deniability.
Now, when Bob or Charlie attempt to trace Alice’s transactions on the blockchain, they will also see transactions made by Nemo and Neminem. If Alice participates in a few more CoinJoin transactions, Bob and Charlie would have to guess among dozens or even hundreds of potential transactions which ones were actually made by Alice.
Although the full transaction history of Alice’s satoshis is still available on the blockchain, a determined investigator might attempt to contact the other CoinJoin participants to trace the origin of Alice’s funds and potentially reveal her as AnonGirl. However, for casual observers browsing the blockchain, Alice has gained plausible deniability.
The CoinJoin method described above incurs a small cost for the participants in the form of transaction fees. An alternative approach, known as “purchaser CoinJoin,” can save participants satoshis while also improving privacy.
AnonGirl waits in the IRC chatroom until she is ready to make a purchase. She announces her intention to spend satoshis and waits for someone else who also wants to make a purchase, but from a different vendor. They then combine their inputs as before, but this time, they direct the outputs to their respective merchants’ addresses. As a result, no one can determine, purely from blockchain history, who purchased what from the merchants.
Since they would have had to pay a transaction fee to make their purchases anyway, AnonGirl and her co-spenders don’t incur any additional costs. In fact, by consolidating their transactions and reducing overhead, they use fewer bytes, which might allow them to pay a lower total transaction fee, saving each participant a small amount of satoshis.