agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Change: Secured Assets, Fixup: Specification

Browse source
This commit is contained in:
ryanRfox 2018-08-30 11:22:28 -04:00
parent 1961fb9c00
commit 9f36ae2ad0
2 changed files with 32 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -49,4 +49,4 @@ Number | Title |
[39](bsip-0039.md) | Automatically approve proposals by the proposer | Fabian Schuh | Protocol | Draft
[40](bsip-0040.md) | Custom active permission | Stefan Schießl | Protocol | Draft
[42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft
[44](bsip-0044.md) | Hashed Time-Locked Contract | Fox, Jones, taconator | Protocol | Draft
[44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Draft

58
bsip-0044.md
View file

@ -26,11 +26,11 @@ An HTLC is defined to have the following components:
* The recipient
* Escrow Asset
* Secured Asset
* Asset symbol
* Symbol
* Asset quantity
* Quantity
* Conditions
@ -54,21 +54,23 @@ An HTLC is defined to have the following components:
* Prepare duration fee
* Redeem operation fee
### **Parties**
Two parties must be defined within each HTLC: the `depositor` and the `recipient`. The `depositor` will escrow their assets within the HTLC and designate the `recipient` to receive them. Note that a proposal transaction may be used for tasks such as multi-signature, but the end result at approval remains a single `depositor` and a single `recipient`.
Two parties must be defined within each HTLC: the `depositor` and the `recipient`. The `depositor` will secure their assets within the HTLC and designate the `recipient` to receive them. Note that a proposal transaction may be used for tasks such as multi-signature, but the end result at approval remains a single `depositor` and a single `recipient`.
### **Escrow Asset**
### **Secured Asset**
An HTLC involves a conditional transfer of the defined `asset symbol` in the amount of `assets quantity` from the `depositor` to the `recipient`. The HTLC holds these designated `escrow assets` from `depositor` on the blockchain and will continue to enforce the specified `conditions` until one is satisfied.
An HTLC involves a conditional transfer of the defined `asset symbol` in the amount of `assets quantity` from the `depositor` to the `recipient`. The HTLC holds these designated `secured assets` from `depositor` on the blockchain and will continue to enforce the specified `conditions` until one is satisfied.
### **Conditions**
There are two competing conditions within an HTLC, the `hash lock` and the `time lock`.
The HTLC contains a `hash lock` condition, which comprise both the `preimage hash` and `preimage length`, barring the transfer of held `escrow assets` unless satisfied. If a `preimage` of requisite `length` is provided to the HTLC which generates a hash matching the `preimage hash`, the `preimage` is then stored within the blockchain, and the `escrow assets` are transferred to the `recipient`.
The HTLC contains a `hash lock` condition, which comprise both the `preimage hash` and `preimage length`, barring the transfer of held `secured assets` unless satisfied. If a `preimage` of requisite `length` is provided to the HTLC which generates a hash matching the `preimage hash`, the `preimage` is then stored within the blockchain, and the `secured assets` are transferred to the `recipient`.
If a satisfactory `preimage` is not provided to the HTLC before the stipulated `time lock` expires, the `depositor` may request the return of `escrow assets`. The HTLC will only evaluate transfer request from `depositor` and after `timeout threshold`, then return `escrow assets` to `depositor`.
If a satisfactory `preimage` is not provided to the HTLC before the stipulated `time lock` expires, the `depositor` may request the return of `secured assets`. The HTLC will only evaluate transfer request from `depositor` and after `timeout threshold`, then return `secured assets` to `depositor`.
**Note:** we recommend the Committee the set maximum allowable `preimage length` to ensure unreasonably large submissions are rejected.
@ -84,23 +86,23 @@ Upon presentation of a `preimage`, the HTLC `condition evaluator` validates:
3. That the hash of the `preimage` calculates to the specified `preimage hash`.
If all evaluations succeed, the `escrow assets` are transferred to the `recipient`. If any evaluation fails, nothing happens; the HTLC remains ready to evaluate the next `preimage`.
If all evaluations succeed, the `secured assets` are transferred to the `recipient`. If any evaluation fails, nothing happens; the HTLC remains ready to evaluate the next `preimage`.
Upon presentation of a request from the `depositor` for return of `escrow assets`, the HTLC `condition evaluator` validates that the `timeout threshold` is now in the past. It then returns the `escrow assts` to `depositor`.
Upon presentation of a request from the `depositor` for return of `secured assets`, the HTLC `condition evaluator` validates that the `timeout threshold` is now in the past. It then returns the `secured assets` to `depositor`.
### **Timing of Condition Evaluation**
The `timeout threshold` of the contract is defined by `depositor` within the HTLC at creation. It can be any time in the future and should allow enough time for `recipient` to review the HTLC and provide the `preimage`. Further, it should not be set too far into the future to mitigate against an unresponsive `recipient` impacting `depositor`, as their `escrow assets` will be locked until `timeout threshold` expiry. The accuracy is based on when the `condition evaluator` runs, and should be considered accurate ± 15 seconds.
The `timeout threshold` of the contract is defined by `depositor` within the HTLC at creation. It can be any time in the future and should allow enough time for `recipient` to review the HTLC and provide the `preimage`. Further, it should not be set too far into the future to mitigate against an unresponsive `recipient` impacting `depositor`, as their `secured assets` will be locked until `timeout threshold` expiry. The accuracy is based on when the `condition evaluator` runs, and should be considered accurate ± 15 seconds.
**Note:** we recommend the Committee set the maximum value for `timeout threshold` to limit the amount of time a contract may consume memory of validation nodes.
### **Early Termination of an Escrow Contract**
### **Early Termination of an HTLC**
To protect the `recipient`, early termination of an HTLC is not allowed by any party. Placing a `timeout threshold` far into the future is valid, up to the maximum defined by the Committee. User protection from locking up funds for an extremely long period could be provided by the UI used to create the HTLC.
### **Automatic Transfers Upon Expiry**
Upon expiry of the `timeout threshold`, the `escrow assets` held within the HTLC will be queued for return to `depositor`. No action is required by the `depositor` to receive their "locked" funds back from the contract after expiry.
Upon expiry of the `timeout threshold`, the `secured assets` held within the HTLC will be queued for return to `depositor`. From this time, the HTLC will no longer evaluate the `hash lock`, preventing `recipient` from receiving the `secured assets`. No action is required by the `depositor` to receive their "locked" funds back from the contract after expiry.
### **Fees**
@ -110,7 +112,7 @@ The "prepare" operation will store in-memory data on validation nodes until rede
The "redeem" operation frees most of the memory from the validation nodes and adds the `preimage` data into blockchain storage when the transaction is validated. We recommend the `htlc_redemption_fee` be comprised of two (2) components: `GRAPHEN_HTLC_REDEEM_FEE` which is may be quite low and `GRAPHENE_HTLC_KB_FEE` which is variable based on the total number of kilobytes of data committed to the blockchain.
The "extend expiry" operation will update the `timeout_threshold` to a future date. We recommend the `htlc_extend_expiry_fee` be calculated based on the number of additional days at the current `GRAPHENE_HTLC_DAILY_FEE` rate.
The "extend expiry" operation will update the `timeout_threshold` to a future date, extending in-memory resources on validation nodes. We recommend the `htlc_extend_expiry_fee` be comprised of two (2) components: `GRAPHENE_HTLC_EXTEND_EXPIRY_FEE` which is flat and `GRAPHENE_HTLC_DAILY_FEE` which is variable based on the number of additional days added to extend the `timeout_threshold` of the contract.
## **Existing Escrow Proposals**
@ -139,17 +141,17 @@ The following will describe possible concepts that could be implemented within t
### **Set-Price Swap**
Two parties may agree on a swap of two distinct `escrow assets` at a set price (defined exchange ratio), without using an exchange such as the BitShares DEX. This will require two (2) HTLC contracts containing the identical `preimage hash` within each to "link" them together and facilitate the execution of an "atomic swap" of these "locked" `escrow assets` between the party's accounts resulting in a trustless value exchange.
Two parties may agree on a swap of two distinct `secured assets` at a set price (defined exchange ratio), without using an exchange such as the BitShares DEX. This will require two (2) HTLC contracts containing the identical `preimage hash` within each to "link" them together and facilitate the execution of an "atomic swap" of these "locked" `secured assets` between the party's accounts resulting in a trustless value exchange.
#### **Business Approach**
Alice begins by generating a distinct `preimage` of her choosing, notes the `preimage length` and calculates the `preimage hash`. She retains the `preimage` in secret, then creates a new HTLC stipulating that the `depositor` account "alice" will transfer `quantity` "100" "bitUSD" `asset` into the `recipient` account "bob" if a `preimage` is presented matching the `preimage hash` before the `timelock threshold` of 10AM tomorrow. Upon consensus validation of the HTLC, the 100 bitUSD `escrow assets` are transferred from Alice's `depositor` account into the HTLC where they remain locked by the `preimage hash` and `timelock threshold`. She then shares the resulting `contract identifier` with Bob.
Alice begins by generating a distinct `preimage` of her choosing, notes the `preimage length` and calculates the `preimage hash`. She retains the `preimage` in secret, then creates a new HTLC stipulating that the `depositor` account "alice" will transfer `quantity` "100" "bitUSD" `asset` into the `recipient` account "bob" if a `preimage` is presented matching the `preimage hash` before the `timelock threshold` of 10AM tomorrow. Upon consensus validation of the HTLC, the 100 bitUSD `secured assets` are transferred from Alice's `depositor` account into the HTLC where they remain locked by the `preimage hash` and `timelock threshold`. She then shares the resulting `contract identifier` with Bob.
Bob queries the blockchain for the `contract identifier` Alice provided. He examines to ensure it contains his desired `recipient` account, `asset` symbol, asset `quantity`, `preimage length`, and `timelock threshold`. Bob now creates his own HTLC that will deposit `quantity` "10,000" "BTS" `symbol` into the `recipient` account "alice" from `depositor` account "bob", if a `preimage` that generates the `preimage hash` Bob copied from Alice's HTLC before the `timelock threshold` of 5pm today. Upon consensus validation of Bob's HTLC, his 10,000 BTS `escrow assets` are transferred from his `depositor` account and "locked" into the contract. He then shares the resulting `contract identifier` with Alice. Notice Bob specified a `timelock threshold` much shorter than Alice defined in her contract. This ensures Bob will have enough time to observe and use the `preimage` Alice will publish to the blockchain next.
Bob queries the blockchain for the `contract identifier` Alice provided. He examines to ensure it contains his desired `recipient` account, `asset` symbol, asset `quantity`, `preimage length`, and `timelock threshold`. Bob now creates his own HTLC that will deposit `quantity` "10,000" "BTS" `symbol` into the `recipient` account "alice" from `depositor` account "bob", if a `preimage` that generates the `preimage hash` Bob copied from Alice's HTLC before the `timelock threshold` of 5pm today. Upon consensus validation of Bob's HTLC, his 10,000 BTS `secured assets` are transferred from his `depositor` account and "locked" into the contract. He then shares the resulting `contract identifier` with Alice. Notice Bob specified a `timelock threshold` much shorter than Alice defined in her contract. This ensures Bob will have enough time to observe and use the `preimage` Alice will publish to the blockchain next.
Alice now examines the HTLC Bob created, ensuring the `preimage hash` and `preimage length` both match the original values she used within her contract. She also verifies her desired `recipient` account "alice", the `quantity`, `symbol`, and the `timelock threshold` agree with her intentions. She now uses her `preimage` to "unlock" Bob's contract. Once consensus validation occurs, the HTLC will transfer the `escrow assets` 10,000 BTS into her `recipient` account "alice". This reveals the `preimage` on the BitShares blockchain for Bob to use next. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created.
Alice now examines the HTLC Bob created, ensuring the `preimage hash` and `preimage length` both match the original values she used within her contract. She also verifies her desired `recipient` account "alice", the `quantity`, `symbol`, and the `timelock threshold` agree with her intentions. She now uses her `preimage` to "unlock" Bob's contract. Once consensus validation occurs, the HTLC will transfer the `secured assets` 10,000 BTS into her `recipient` account "alice". This reveals the `preimage` on the BitShares blockchain for Bob to use next. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created.
Bob can now observe the `preimage` Alice used to "unlock" his HTLC, and he will use it to "unlock" her HTLC to receive the 100 bitUSD `escrow assets` into his `recipient` account "bob". NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created.
Bob can now observe the `preimage` Alice used to "unlock" his HTLC, and he will use it to "unlock" her HTLC to receive the 100 bitUSD `secured assets` into his `recipient` account "bob". NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created.
### **Cross-Chain Swap**
@ -159,13 +161,13 @@ Similar to the set-price swap mentioned above, two parties may exchange tokens b
Alice and Bob intend to swap BTC (bitcoin token) and BTS (BitShares token). This will require both parties to define both a BTC deposit address and BTS deposit account. These addresses/accounts will be exchanged between the parties.
Alice will initiate the first leg of the swap on the BitShares Network with her HTLC and Bob will follow up on the Bitcoin Network with his HTLC. Allice generates a distinct `preimage` of her choosing, notes the `preimage length` and calculates the `preimage hash`. She retains the `preimage` in secret, then creates a new HTLC stipulating that the `depositor` account "alice" will transfer `quantity` "10,000" "bitUSD" `asset` into the `recipient` account "bob" if a `preimage` is presented matching the `preimage hash` before the `timelock threshold` of 10AM tomorrow. Upon consensus validation of the HTLC on the BitShares Network, the 10,000 bitUSD `escrow assets` are transferred from Alice's `depositor` account into the HTLC where they remain locked by the `preimage hash` and `timelock threshold`. She then shares the resulting `contract identifier` with Bob.
Alice will initiate the first leg of the swap on the BitShares Network with her HTLC and Bob will follow up on the Bitcoin Network with his HTLC. Allice generates a distinct `preimage` of her choosing, notes the `preimage length` and calculates the `preimage hash`. She retains the `preimage` in secret, then creates a new HTLC stipulating that the `depositor` account "alice" will transfer `quantity` "10,000" "bitUSD" `asset` into the `recipient` account "bob" if a `preimage` is presented matching the `preimage hash` before the `timelock threshold` of 10AM tomorrow. Upon consensus validation of the HTLC on the BitShares Network, the 10,000 bitUSD `secured assets` are transferred from Alice's `depositor` account into the HTLC where they remain locked by the `preimage hash` and `timelock threshold`. She then shares the resulting `contract identifier` with Bob.
Bob queries the BitShares Network for the `contract identifier` Alice provided. He examines to ensure it contains his desired `recipient` account, `asset` symbol, asset `quantity`, `preimage length`, and `timelock threshold`. Bob now creates and funds his own HTLC on the Bitcoin Network that will spend the `UTXO` of this contract to the `recipient address` Alice provided during their setup phase, of `amount` 1 BTC if a `preimage` that generates the `preimage hash` Bob copied from Alice's HTLC before the `timelock threshold` of 5pm today. Upon consensus validation of Bob's HTLC on the Bitcoin Network, 1 BTC he controlled are spent into the contract and "locked". He then shares the resulting `contract identifier` with Alice. Notice Bob specified a `timelock threshold` much shorter than Alice defined in her contract. This ensures Bob will have enough time to observe and use the `preimage` Alice will publish to the blockchain next.
Alice now examines the HTLC Bob created on the Bitcoin Network, ensuring the `preimage hash` and `preimage length` both match the original values she used within her contract. She also verifies her desired `recipient address`, `quantity`, and `timelock threshold` agree with her intentions. She now uses her `preimage` to "unlock" Bob's contract. Once consensus validation occurs on the Bitcoin Network, the HTLC will spend 1 BTC to Alice's `recipient address`. This reveals the `preimage` on the Bitcoin Network for Bob to use next. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created.
Bob has now observed the `preimage` Alice used to "unlock" his HTLC, and he will use it to "unlock" her HTLC to receive the 10,000 bitUSD `escrow assets` into his `recipient` account "bob". NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created.
Bob has now observed the `preimage` Alice used to "unlock" his HTLC, and he will use it to "unlock" her HTLC to receive the 10,000 bitUSD `secured assets` into his `recipient` account "bob". NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created.
# **Specifications**
@ -175,9 +177,10 @@ Bob has now observed the `preimage` Alice used to "unlock" his HTLC, and he will
htlc_obj
id // int
depositor // account object
quantity // int
quantity // int
symbol // string
recipient // account object
hash_algorithm // enum
preimage_hash // string
preimage_length // int
preimage_tx_id // reference to transaction object containing the preimage used for htlc_redeem
@ -195,7 +198,7 @@ htlc_obj
### **Prepare**
```
transaction_obj htlc_prepare(depositor, quantity, symbol, recipient, preimage_hash, preimage_length, timeout_threshold, htlc_preparation_fee)
transaction_obj htlc_prepare(depositor, quantity, symbol, recipient, hash_algorithm, preimage_hash, preimage_length, timeout_threshold, htlc_preparation_fee)
Validate: HTLC signed by requisite `authority` for `depositor` account
Validate: `depositor` account has requisite `quantity` of `symbol` asset for the `guarantee`
Validate: `timeout_threshold` < now() + GRAPHENE_HTLC_MAXIMUM_DURRATION
@ -208,6 +211,7 @@ transaction_obj htlc_prepare(depositor, quantity, symbol, recipient, preimage_ha
contract = new htlc_obj
Set: `contract.depositor` = `depositor`
Set: `contract.recipient` = `recipient`
Set: `contract.hash_algorithm` = `hash_algorithm`
Set: `contract.preimage_hash` = `preimage_hash`
Set: `contract.preimage_length` = `preimage_length`
Set: `contract.timeout_treshold` = `timeout_threshold`
@ -218,13 +222,13 @@ transaction_obj htlc_prepare(depositor, quantity, symbol, recipient, preimage_ha
### **Redeem**
```
transaction_obj htlc_redeem(redeemer, id, preimage, htlc_redemption_fee)
Validate: transaction signed by requisite `authority` for `redeemer` // any account may attempt to redeem
transaction_obj htlc_redeem(fee_paying_account, id, preimage, htlc_redemption_fee)
Validate: transaction signed by requisite `authority` for `fee_paying_account` // any account may attempt to redeem
Get: get_htlc(id)
Validate: `redeemer` account has requisite `quantity` of BTS for `htlc_redeem_fee` and `htlc_kb_fee`
Validate: `fee_paying_account` account has requisite `quantity` of BTS for `htlc_redeem_fee` and `htlc_kb_fee`
// Evaluate: timelock
if now() < `timeout_threshold` then return error // "timeout exceeded"
Update: balance of `redeemer` based on total fees
Update: balance of `fee_paying_account` based on total fees
// Evaluate: hashlock
if length(preimage) != `id.preimage_length` then return error // "preimage length mismatch"
Calculate: `preimage_hash` = hash(preimage)