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

Fixup: Specifications

bsip53
ryanRfox 2018-08-29 16:40:48 -04:00
parent a1d16d3cdd
commit 1961fb9c00
1 changed files with 120 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
bsip-0044.md
View File

@ -4,7 +4,7 @@ Authors: Ryan R. Fox, John M. Jones, taconator\
Status: Draft\
Type: Protocol\
Created: 2018-08-22\
Discussion: TBD
Discussion: https://github.com/bitshares/bsips/pull/104
# **Abstract**
@ -40,7 +40,7 @@ An HTLC is defined to have the following components:
* Preimage hash (hash of the preimage)
* Length of the preimage
* Preimage length
* Time lock
@ -48,7 +48,11 @@ An HTLC is defined to have the following components:
* Condition Evaluators
* Fee
* Fees
* Prepare operation fee
* Prepare duration fee
### **Parties**
@ -62,10 +66,12 @@ An HTLC involves a conditional transfer of the defined `asset symbol` in the amo
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 `length of the preimage`, 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 `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`.
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`.
**Note:** we recommend the Committee the set maximum allowable `preimage length` to ensure unreasonably large submissions are rejected.
### **Condition Evaluators**
The `preimage` can be thought of a secret key, that will eventually be shared with the `recipient`. This can be a word, a phrase, or even a random series of bytes. The `length` of the `preimage` must be specified within the HTLC at creation.
@ -76,7 +82,7 @@ Upon presentation of a `preimage`, the HTLC `condition evaluator` validates:
2. That the length of the `preimage` matches the specified `preimage length`.
3. That the `hash of the preimage` matches the specified `preimage hash`.
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`.
@ -86,41 +92,46 @@ Upon presentation of a request from the `depositor` for return of `escrow assets
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.
**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**
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. User protection from locking up funds for an extremely long period could be provided by the UI used to create the 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 **not** automatically be returned to `depositor`. A separate transaction must be initiated by the `depositor` to request `escrow assets` be transferred to `depositor`.
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.
Code _could_ be added to automate the return of funds. This could be part of block production or maintenance. However, this will cause extra load on those processes. Hence, it is felt that requiring action by the `depositor` is the best option.
### **Fees**
### **Fee**
We propose three (3) operations (see Specification) to implement the HTLC feature, each requiring distinct fees. All fees will be set and maintained by the Committee.
Creating and fulfillment are two operations that add data to the blockchain. The `fee` for each operation is based on the standards set for blocks, and is similar to costs of other items stored on-chain.
The "prepare" operation will store in-memory data on validation nodes until redeemed or expiry. We recommend the `htlc_preparation_fee` be comprised of two (2) components: `GRAPHENE_HTLC_PREPARE_FEE` which is flat and `GRAPHENE_HTLC_DAILY_FEE` which is variable based on the number of days until `timeout threshold`.
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.
## **Existing Escrow Proposals**
This section describes various escrow concepts that have been proposed either for BitShares or for other blockchains or services in terms of the elements that have been defined above. This is intended to provide some background and comparison to the concepts that follow.
## **Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing**
### **BitShares Escrow**
A separate BSIP [cite] is currently being discussed that provides a more traditional escrow service. This involves parties, agents, and a more complex evaluation. HTLC shares some similarities, and could be considered a thin subset of BitShares Escrow.
The smaller, well-defined nature of HTLC provides a major advantage for applications that want to attempt tasks such as cross chain atomic swaps.
### **Scorum Atomic Swap**
[cite]
### **BitShares Multi-Signature Account**
One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties [cite] and even hierarchical authorizations. Using this mechanism as a form of escrow is possible. But there are many limitations. More information on escrow and multi-signatures can be found in the BitShares Escrow BSIP.
One of the existing features of BitShares is the ability to have an account that requires multiples signatures by differently authorized parties [cite] and even hierarchical authorizations. Using this mechanism as a form of escrow is possible. But there are many limitations. More information on escrow and multi-signatures can be found in the BitShares Escrow BSIP [cite].
### **BitShares Proposals**
One of the existing features of BitShares is the ability to have a proposal that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures). If the required authorizations are not given by the proposal expiry then no transfer will occur. This feature also contains many limitations when compared to HTLC.
# **Specifications**
One of the existing features of BitShares is the ability to have a proposal that is recorded on the blockchain and awaits the authorization of the requisite parties (e.g. M-of-N signatures) to execute. However, the proposal does not "lock" any assets, so the transfer will fail if the sending account lacks sufficient funds during validation. If the required authorizations are not given by proposal expiry, then no transfer will occur. This feature also contains many limitations when compared to HTLC.
## **Possible Concepts to Implement**
@ -156,9 +167,101 @@ Alice now examines the HTLC Bob created on the Bitcoin Network, ensuring the `pr
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.
# **Specifications**
## **Objects**
```
htlc_obj
id // int
depositor // account object
quantity // int
symbol // string
recipient // account object
preimage_hash // string
preimage_length // int
preimage_tx_id // reference to transaction object containing the preimage used for htlc_redeem
timeout_threshold // datetime
// Constructor
Set: id = next available
Initialize other fields = NULL
return contract
```
## **Operations**
### **Prepare**
```
transaction_obj htlc_prepare(depositor, quantity, symbol, recipient, 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
Calculate: `required_fee` = GRAPHENE_HTLC_OPERATION_FEE + GRAPHENE_HTLC_DAILY_FEE * count((`timeout_threshold` - now()), days)
Validate: `depositor` account has requisite `quantity` of BTS for `required_fee`
Validate: `recipient` account exists
Validate: `preimage_length` does not exceed GRAPHENE_HTLC_MAXIMUM_PREIMAGE_LENGTH
Validate: `preimage_hash` well formed
Update: BTS balance of `depositor` based on `required_fee`)
contract = new htlc_obj
Set: `contract.depositor` = `depositor`
Set: `contract.recipient` = `recipient`
Set: `contract.preimage_hash` = `preimage_hash`
Set: `contract.preimage_length` = `preimage_length`
Set: `contract.timeout_treshold` = `timeout_threshold`
Transfer: from `depositor` account to `contract.quantity` of `contract.symbol`
return results
```
### **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
Get: get_htlc(id)
Validate: `redeemer` 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
// Evaluate: hashlock
if length(preimage) != `id.preimage_length` then return error // "preimage length mismatch"
Calculate: `preimage_hash` = hash(preimage)
if `preimage_hash` != `id.preimage_hash` then return error // "invalid preimage submitted"
Update: balance of `id.recipient` add asset `id.symbol` of quantity `id.quantity`
Add: transaction to mempool
Set: `id.preimage_tx_id` = `transaction_id`
Cleanup: memory allocated to this htlc
return: results
```
### **Extend Expiry**
```
transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extention_fee)
Validate: transaction signed by requisite `authority` for `depositor` account
Validate: `timeout_threshold` < now() + GRAPHENE_HTLC_MAXIMUM_DURRATION
Calculate: `required_fee` = GRAPHENE_HTLC_DAILY_FEE * count((`timeout_threshold` - now()), days)
Validate: `depositor` account has requisite `quantity` of BTS for `required_fee`
Update: BTS balance of `depositor` based on `required_fee`)
Set: `contract.timeout_treshold` = `timeout_threshold`
return results
```
## **APIs**
### **get_htlc**
### **htlc_prepare**
### **htlc_redeem**
### **htlc_extend_expiry**
# **Discussion**
TBD
https://github.com/bitshares/bsips/pull/104
# **Summary for Shareholders**