-
Notifications
You must be signed in to change notification settings - Fork 35
Background
There are degrees of trustlessness:
- Trustless Distributed - requires no intermediary
- Trustless Centralised - requires an untrusted intermediary
- Trusted Centralised - requires a trusted intermediary
There are at least three types of transactions:
- Contingency lock - A perform X if B does Y
- Atomic Swap - A and B swap X and Y
- Transfer - Ownership of X is transferred from A to B
Two methods of withdrawing from Plasma chain:
-
provide proof of UXTO, timeout period for proof of forgery
- requires 1 merkle proof to update balance
- requires constant monitoring to provide proof of forgery
- DoS attack - spending many UXTOs / providing proof of forgery, costs both parties an equal amount of money
-
proof of liveness, actions can only be performed if it exists in the most recently published block
- must be trustless so relayer can't insert spends or roll-back state machines
Currently there are two HTLC implementations:
- HTLC.sol
- IonLock.sol
Example:
- Alice opens a payment channel to Bob, and Bob opens a payment channel to Charlie.
- Alice wants to buy something from Charlie for 1000 satoshis.
- Charlie generates a random number and generates its SHA256 hash. Charlie gives that hash to Alice.
- Alice uses her payment channel to Bob to pay him 1,000 satoshis, but she adds the hash Charlie gave her to the payment along with an extra condition: in order for Bob to claim the payment, he has to provide the data which was used to produce that hash.
- Bob uses his payment channel to Charlie to pay Charlie 1,000 satoshis, and Bob adds a copy of the same condition that Alice put on the payment she gave Bob.
- Charlie has the original data that was used to produce the hash (called a pre-image), so Charlie can use it to finalize his payment and fully receive the payment from Bob. By doing so, Charlie necessarily makes the pre-image available to Bob.
- Bob uses the pre-image to finalize his payment from Alice
As with the hash pre-image reveal, except the secret is the discrete logarithm of a curve point.
Basically completely inappropriate for Ion.
This lock type requires you to lock your funds in a way which a third party must verify you have completed the precondition, if you have it will provide a signed token that can be given to the smart-contract to release the funds. The smart contract can be programmed in a way which provides the third party no advantage or ability to steal funds even if it is malicious.
This is like putting the funds into a single-use multi-signature wallet, which has a timeout after which the funds will be withdrawable by the original depositor.
This lock type requires both parties to use a trusted but unbiased third-party who publishes metadata about transactions and events on different chains. Smart-contracts must be be programmed to rely on this third-party when verifying if an action can be performed.
The advantage of a merkle-proof versus a third-party signature is that the third-party doesn't need to be actively involved in every transaction. The disadvantage is that every action requiring a merkle proof may be very expensive on Ethereum due to the Gas overhead of storing additional words of data (20,000 Gas per 256 bit word).
For example, smart-contract B is programmed to send its funds to an address if (on another chain) another user has sent funds to an address, research was made into the failure conditions and possible attack scenarios, which include:
- Funds on chain A are never sent
- Funds on chain B are never deposited
- Either person A or B is malicious
- Inability to submit transactions, unlucky timeouts
There are two methods which use third-party merkle proofs:
- Optimistic deposit, with timeout
- Lock-step with cancellation
The first method is optimistic, the seller locks their funds for trade with a specific buyer, when the buyer sends the seller a specific transaction on another chain this provides them with evidence they can provide to the lock contract to release the funds to them.
This requires three on-chain transactions and one merkle proof:
- Person A: Deposit & lock
- Person B: Send Funds
- Person B: Proof for unlock
The lock-step method accounts for all failure conditions, but the penalty is in the overhead and number of on-chain transactions required.
In the best scenario it requires six on-chain transactions and two merkle proofs; effort was made to reduce the first step to a pre-image reveal, however an edge-case was discovered which could allow one party to cheat unless strict timeouts/cooling-off periods were enforced.
Clearmatics :D