From 92ec7deee731df6ea7ac69d94d85e1d103912ef9 Mon Sep 17 00:00:00 2001 From: abitmore Date: Tue, 21 Aug 2018 18:59:24 -0400 Subject: [PATCH 01/36] BSIP41: Reduce MSSR of bitCNY from 1.1 to 1.05 --- README.md | 1 + bsip-0041.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+) create mode 100644 bsip-0041.md diff --git a/README.md b/README.md index 5b3a9eb..314fdf2 100644 --- a/README.md +++ b/README.md @@ -48,3 +48,4 @@ Number | Title | [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 +[41](bsip-0041.md) | Reduce MSSR of bitCNY from 1.1 to 1.05 | Jerry Liu | Protocol | Draft diff --git a/bsip-0041.md b/bsip-0041.md new file mode 100644 index 0000000..9898d9e --- /dev/null +++ b/bsip-0041.md @@ -0,0 +1,43 @@ +BSIP: +Title: Reduce MSSR of bitCNY from 1.1 to 1.05 +Authors: Jerry Liu +Status: Draft +Type: Protocol +Created: 2018-08-17 +Discussion: https://bitsharestalk.org/index.php?topic=26928.0 +Worker: no + +### **Abstract** +We here propose to reduce the Maximum short squeeze ratio (MSSR) of bitCNY from 1.1 to 1.05, to lower the shorting incentive. + +### **Motivation** +Bitshares is a financial system with leverage, here in the traders there are BTS longers and shorters, surely the traders are finding their chance to make profit in trading, if shorters can always find chance to make big profit by shorting BTS, that’s not a good news to BTS ecosystem, from the perspective of the whole BTS ecosystem consisted of DEX and smartcoin, we need to review the rules continually, while guaranteeing fairness and the risks always be released in time, we also need to try optimize the rules to encourage BTS longers, to provide enough incentive to make BTS ecosystem to grow up. + + +### **Rationale** +Currently there are 2 key smartcoin parameters which are maintained by witnesses, they are MCR(Maintenance collateral ratio ) and MSSR(Maximum short squeeze ratio) , now MCR=1.75 and MSSR=1.1. + +When a debt position is margin called, the placed sell orders is at price feed price/MSSR, so MSSR determine the discount of collateral force selling the higher MSSR, the bigger the discount. + +So high MSSR benefits the filling of margin call sell orders and help to release risks rapidly, however at the same time, high MSSR means buying margin call orders is with big discount, so it encourage BTS shorters to accumulate smartcoins and wait or even try to make margin call happen and get cheaper collateral. This does not do good to the ecosystem grow up. + +We need to release risks rapidly while margin call happen, we also need to try to lower the shorting incentive, so we need a balance, what a MSSR is appropriate depend on the liquidity of the market and also some other factors. + +bitCNY have a very good liquidity, BTS/bitCNY pair in DEX is the pair with highest BTS volume on the earth, after in 19th July the hard fork activated the target CR feature, the sell pressure comes from margin called orders decreased greatly, we are sure that the for bitCNY black swan has very very little chance to happen, it’s the time to reduce MSSR to push bitCNY ecosysm move forward. + + + +### **Specification** +witnesses adjust the MSSR from 1.1 to 1.05 while publishing feed price. +Discussion +Will this change be implemented to bitUSD and other smartcoins? +this time No, bitUSD and other smartcoins has a much lower liquidity than bitCNY, a high MSSR need to be kept to guarantee the rapid settlement of margin called dept positions. +How to make sure a strong consensus is reached? +China community has discussed about this change for years, however, target CR feature + good bitCNY liquidity make current time the good time to do the change, in the forum thread, about 70% of the voters support this change, if necessary, a opinion survey worker proposal will be created to collect stake based opinion. +As MSSR comes from witness publishing, so when BTS community reach a strong consensus to do the change, we need witnesses to apply the change based on the community consensus + +### **Summary for Shareholders** +Reduce shorting incentive while guaranteeing fairness and safe is an important logic for the ecosystem to evolve. + +### **Copyright** +This document is placed in the public domain. From 438b5ed6ad4f5eb7c365304c4dfb0715343eff08 Mon Sep 17 00:00:00 2001 From: abitmore Date: Tue, 21 Aug 2018 19:03:00 -0400 Subject: [PATCH 02/36] Update format --- bsip-0041.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/bsip-0041.md b/bsip-0041.md index 9898d9e..953985b 100644 --- a/bsip-0041.md +++ b/bsip-0041.md @@ -1,11 +1,11 @@ -BSIP: -Title: Reduce MSSR of bitCNY from 1.1 to 1.05 -Authors: Jerry Liu -Status: Draft -Type: Protocol -Created: 2018-08-17 -Discussion: https://bitsharestalk.org/index.php?topic=26928.0 -Worker: no + BSIP: 0041 + Title: Reduce MSSR of bitCNY from 1.1 to 1.05 + Authors: Jerry Liu + Status: Draft + Type: Protocol + Created: 2018-08-17 + Discussion: https://bitsharestalk.org/index.php?topic=26928.0 + Worker: no ### **Abstract** We here propose to reduce the Maximum short squeeze ratio (MSSR) of bitCNY from 1.1 to 1.05, to lower the shorting incentive. From 21b7f0f8eea84b68f7e35faf6f6ac6930ebb1a73 Mon Sep 17 00:00:00 2001 From: Abit Date: Wed, 22 Aug 2018 01:16:52 +0200 Subject: [PATCH 03/36] Fix typo --- bsip-0041.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bsip-0041.md b/bsip-0041.md index 953985b..b0b8e9d 100644 --- a/bsip-0041.md +++ b/bsip-0041.md @@ -1,6 +1,6 @@ BSIP: 0041 Title: Reduce MSSR of bitCNY from 1.1 to 1.05 - Authors: Jerry Liu + Author: Jerry Liu Status: Draft Type: Protocol Created: 2018-08-17 @@ -11,7 +11,7 @@ We here propose to reduce the Maximum short squeeze ratio (MSSR) of bitCNY from 1.1 to 1.05, to lower the shorting incentive. ### **Motivation** -Bitshares is a financial system with leverage, here in the traders there are BTS longers and shorters, surely the traders are finding their chance to make profit in trading, if shorters can always find chance to make big profit by shorting BTS, that’s not a good news to BTS ecosystem, from the perspective of the whole BTS ecosystem consisted of DEX and smartcoin, we need to review the rules continually, while guaranteeing fairness and the risks always be released in time, we also need to try optimize the rules to encourage BTS longers, to provide enough incentive to make BTS ecosystem to grow up. +BitShares is a financial system with leverage, here in the traders there are BTS longers and shorters, surely the traders are finding their chance to make profit in trading, if shorters can always find chance to make big profit by shorting BTS, that’s not a good news to BTS ecosystem, from the perspective of the whole BTS ecosystem consisted of DEX and smartcoin, we need to review the rules continually, while guaranteeing fairness and the risks always be released in time, we also need to try optimize the rules to encourage BTS longers, to provide enough incentive to make BTS ecosystem to grow up. ### **Rationale** From dca7c12861c0dfeff9196727aee75a63143a127a Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Wed, 22 Aug 2018 15:58:20 -0400 Subject: [PATCH 04/36] Hashed Time-Lock Contract --- bsip-0000.md | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 bsip-0000.md diff --git a/bsip-0000.md b/bsip-0000.md new file mode 100644 index 0000000..9d9d315 --- /dev/null +++ b/bsip-0000.md @@ -0,0 +1,175 @@ +BSIP: xxxx +Title: Hashed Time-Lock Contract +Authors: John M. Jones, Ryan R. Fox, taconator +Status: Draft +Type: Informational +Created: 2018-08-22 +Discussion: TBD + +# **Abstract** + +This BSIP describes an implementation of a Hashed Time-Locked Contract (HTLC) operation. + +# **Motivation** + +The ability to securely hold tokenized assets within a Hashed Time-Locked Contract (HTLC) on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. No third-party escrow agent is required, rather the HTLC operation enforces execution through the BitShares consensus protocol. + +# **Rational** + +## **Elements of an HTLC** + +An HTLC is defined to have the following components: + +* Parties to the HTLC + + * The depositor + + * The recipient + +* Escrow Asset + + * Asset symbol + + * Asset quantity + +* Conditions + + * Hash lock + + * Preimage (the secret) + + * Preimage hash (hash of the preimage) + + * Length of the preimage hash + + * Time lock + + * Timeout threshold (expiry) + +* Condition Evaluators + +* Fee + +### **Parties** + +Two parties must be defined for an HTLC: one `depositor`, and one `recipient`. Note that a proposal transaction may be used for tasks such as multi-signature, but the end result at approval is still one `depositor` and one `recipient`. + +### **Escrow Asset** + +An HTLC involves a conditional transfer of ownership of a `quantity` of an `asset` from a designated party (the "`depositor`") to the second party (the "`recipient`"). The HTLC holds the designated `escrow 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 are both the `preimage hash` and its `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`. + +### **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 shared and stored within the HTLC at creation. + +Upon presentation of a `preimage`, the HTLC `condition evaluator` validates: + +1. That the `timeout threshold` has not yet occurred. + +2. That the `preimage length` matches the specified `length`. + +3. That the `hash of the preimage` matches 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`. + +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`. + +### **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. + +### **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. + +**TODO:** Consider adding an `Update_HTLC` operation to allow `depositor` to extend the `timeout threshold` + +### **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`. + +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. + +### **Fee** + +Creating and fulfillment are two operations that add data to the blockchain. The fees for these operations are based on the standards set for blocks, and are similar to costs of other items stored on-chain. + +**TODO:** Discuss fees may be variable it is possible to store variable length preimage hash. + +## **Existing Escrow Proposals** + +The 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. + +**TODO:** Elaborate Interledger + +## **Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing** + +### **BitShares Escrow** + +A separate BSIP 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. + +### **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. + +### **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** + +## **Possible Concepts to Implement** + +The following will describe possible concepts that could be implemented in BitShares. + +### **Set-Price Swap** + +Two parties may agree on an asset swap at a set price, without using the exchange. Two HTLC contracts with the same hash can provide a trustless exchange of assets + +#### **Business Approach** + +Party A (Alice) generates an HTLC with a preimage of her choice. The contract stipulates that she will deposit 100 bitUSD into the account of Party B (Bob), if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the contract identifier with Bob. + +Bob examines the contract Alice created, being sure to examine that the receiving account, the amount, and the timeout agrees with his desires. He then generates another HTLC that will deposit 10,000 bitshares into the account of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the contract identifier with Alice. + +Alice now examines the contract Bob created, being sure to examine that the receiving account, the amount, and the timeout agrees with her desires. She also verifies that the hash matches the hash of her contract. She now uses her preimage to "unlock" Bob's contract, which puts 10,000 bitshares into her account. This also posts the preimage on the BitShares blockchain. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created. + +Bob can now see the preimage that Alice used to receive her bitshares, and he can use the same preimage to "unlock" the contract Alice created, and receive the 100 bitUSD. NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created. + +### **Cross-Chain Swap** + +The set-price swap mentioned above works the same across chains that support HTLC. Bitcoin, as an example, supports HTLC. + +#### **Business Approach** + +Alice generates an HTLC on the BitShares blockchain with a preimage of her choice. The contract stipulates that she will deposit 1 bitBTC into the account of Bob, if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the contract identifier with Bob. + +Bob examines the contract Alice created, being sure to examine that the receiving account, the amount, and the timeout agrees with his desires. He then generates an HTLC that will deposit 1 BTC into the Bitcoin address of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the Bitcoin transaction identifier with Alice. + +Alice now examines the contract Bob created, being sure to examine that the receiving account, the amount, and the timeout agrees with her desires. She also verifies that the hash matches the hash of her contract. She now uses her preimage to "unlock" Bob's contract, which puts 1 BTC into her Bitcoin wallet. This also posts the preimage on the Bitcoin blockchain. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created. + +Bob can now see the preimage that Alice used to receive her Bitcoin, and he can use the same preimage to "unlock" the contract Alice created, and receive the 1 bitBTC. NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created. + +# **Discussion** + +# **Summary for Shareholders** + +TBD + +# **Copyright** + +This document is placed in the public domain. + +# **See Also** + +A description of [Hashed Timelock Contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) From 58eff4b6332aec0b4fd48f25cf3588a69ad96e4d Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Wed, 22 Aug 2018 16:04:37 -0400 Subject: [PATCH 05/36] Fixup: header --- bsip-0000.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/bsip-0000.md b/bsip-0000.md index 9d9d315..e2112af 100644 --- a/bsip-0000.md +++ b/bsip-0000.md @@ -1,10 +1,10 @@ -BSIP: xxxx -Title: Hashed Time-Lock Contract -Authors: John M. Jones, Ryan R. Fox, taconator -Status: Draft -Type: Informational -Created: 2018-08-22 -Discussion: TBD +BSIP: xxxx\ +Title: Hashed Time-Lock Contract\ +Authors: John M. Jones, Ryan R. Fox, taconator\ +Status: Draft\ +Type: Informational\ +Created: 2018-08-22\ +Discussion: TBD\ # **Abstract** From 85faf7dadcd0a57333a9597c2917e7019afabcd2 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Wed, 22 Aug 2018 23:49:41 -0400 Subject: [PATCH 06/36] Fixup: HTLC --- bsip-0000.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/bsip-0000.md b/bsip-0000.md index e2112af..8f00126 100644 --- a/bsip-0000.md +++ b/bsip-0000.md @@ -1,10 +1,10 @@ BSIP: xxxx\ -Title: Hashed Time-Lock Contract\ +Title: Hashed Time-Locked Contract\ Authors: John M. Jones, Ryan R. Fox, taconator\ Status: Draft\ Type: Informational\ Created: 2018-08-22\ -Discussion: TBD\ +Discussion: TBD # **Abstract** @@ -12,11 +12,11 @@ This BSIP describes an implementation of a Hashed Time-Locked Contract (HTLC) op # **Motivation** -The ability to securely hold tokenized assets within a Hashed Time-Locked Contract (HTLC) on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. No third-party escrow agent is required, rather the HTLC operation enforces execution through the BitShares consensus protocol. +The ability to securely hold tokenized assets within a hashed time-locked contract on the BitShares blockchain is a desirable feature that could be used by many persons, services, and businesses to mitigate risks between participants during asset transfer. HTLC implement conditional transfers, whereby a designated party (the "recipient") will reveal the preimage of a hash in order to execute the asset transfers from a second party (the "depositor"), else after time lock expiry "depositor" may retrieve their assets. No third-party escrow agent is required, rather the HTLC operation enforces conditions, evaluations and transfers through the BitShares consensus protocol. # **Rational** -## **Elements of an HTLC** +## **Elements of a Hashed Time-Locked Contract (HTLC)** An HTLC is defined to have the following components: @@ -40,7 +40,7 @@ An HTLC is defined to have the following components: * Preimage hash (hash of the preimage) - * Length of the preimage hash + * Length of the preimage * Time lock @@ -52,29 +52,29 @@ An HTLC is defined to have the following components: ### **Parties** -Two parties must be defined for an HTLC: one `depositor`, and one `recipient`. Note that a proposal transaction may be used for tasks such as multi-signature, but the end result at approval is still one `depositor` and one `recipient`. +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`. ### **Escrow Asset** -An HTLC involves a conditional transfer of ownership of a `quantity` of an `asset` from a designated party (the "`depositor`") to the second party (the "`recipient`"). The HTLC holds the 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 `assest 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. ### **Conditions** There are two competing conditions within an HTLC, the `hash lock` and the `time lock`. -The HTLC contains a `hash lock` condition, which are both the `preimage hash` and its `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 `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`. 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`. ### **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 shared and stored within the HTLC at creation. +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. Upon presentation of a `preimage`, the HTLC `condition evaluator` validates: 1. That the `timeout threshold` has not yet occurred. -2. That the `preimage length` matches the specified `length`. +2. That the length of the `preimage` matches the specified `preimage length`. 3. That the `hash of the preimage` matches the specified `preimage hash`. @@ -100,13 +100,13 @@ Code _could_ be added to automate the return of funds. This could be part of blo ### **Fee** -Creating and fulfillment are two operations that add data to the blockchain. The fees for these operations are based on the standards set for blocks, and are similar to costs of other items stored on-chain. +Creating and fulfillment are two operations that add data to the blockchain. The `fee` for each operations is based on the standards set for blocks, and is similar to costs of other items stored on-chain. **TODO:** Discuss fees may be variable it is possible to store variable length preimage hash. ## **Existing Escrow Proposals** -The 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. +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. **TODO:** Elaborate Interledger @@ -114,7 +114,7 @@ The section describes various escrow concepts that have been proposed either for ### **BitShares Escrow** -A separate BSIP 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. +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. @@ -134,13 +134,13 @@ The following will describe possible concepts that could be implemented in BitSh ### **Set-Price Swap** -Two parties may agree on an asset swap at a set price, without using the exchange. Two HTLC contracts with the same hash can provide a trustless exchange of assets +Two parties may agree on an asset swap at a set price, without using the exchange. Two HTLC contracts with the same hash can provide a trustless exchange of assets. #### **Business Approach** -Party A (Alice) generates an HTLC with a preimage of her choice. The contract stipulates that she will deposit 100 bitUSD into the account of Party B (Bob), if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the contract identifier with Bob. +Alice (the `depositor`) generates an HTLC with a preimage of her choosing. The contract stipulates that she will deposit 100 bitUSD into the account of Bob (the `recipient`), if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the contract identifier with Bob. -Bob examines the contract Alice created, being sure to examine that the receiving account, the amount, and the timeout agrees with his desires. He then generates another HTLC that will deposit 10,000 bitshares into the account of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the contract identifier with Alice. +Bob examines the contract Alice created, being sure to examine that it contains his desired receiving account, asset symbol, asset quantity, preimage length, and the timelock threshold agrees with his desires. He then generates another HTLC that will deposit 10,000 bitshares into the account of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the contract identifier with Alice. Alice now examines the contract Bob created, being sure to examine that the receiving account, the amount, and the timeout agrees with her desires. She also verifies that the hash matches the hash of her contract. She now uses her preimage to "unlock" Bob's contract, which puts 10,000 bitshares into her account. This also posts the preimage on the BitShares blockchain. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created. From dc97097f941d8fc6d86a18a8ff3db3075f49a552 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Sun, 26 Aug 2018 17:10:20 -0400 Subject: [PATCH 07/36] Fixup: Specification --- bsip-0000.md | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/bsip-0000.md b/bsip-0000.md index 8f00126..59355e7 100644 --- a/bsip-0000.md +++ b/bsip-0000.md @@ -56,7 +56,7 @@ Two parties must be defined within each HTLC: the `depositor` and the `recipient ### **Escrow Asset** -An HTLC involves a conditional transfer of the defined `asset symbol` in the amount of `assest 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 `escrow assets` from `depositor` on the blockchain and will continue to enforce the specified `conditions` until one is satisfied. ### **Conditions** @@ -100,9 +100,9 @@ Code _could_ be added to automate the return of funds. This could be part of blo ### **Fee** -Creating and fulfillment are two operations that add data to the blockchain. The `fee` for each operations is based on the standards set for blocks, and is similar to costs of other items stored on-chain. +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. -**TODO:** Discuss fees may be variable it is possible to store variable length preimage hash. +**TODO:** Discuss fees may be variable, as it is possible to store a variable length preimage hash. ## **Existing Escrow Proposals** @@ -114,7 +114,7 @@ This section describes various escrow concepts that have been proposed either fo ### **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. +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. @@ -130,35 +130,37 @@ One of the existing features of BitShares is the ability to have a proposal that ## **Possible Concepts to Implement** -The following will describe possible concepts that could be implemented in BitShares. +The following will describe possible concepts that could be implemented within the BitShares protocol. ### **Set-Price Swap** -Two parties may agree on an asset swap at a set price, without using the exchange. Two HTLC contracts with the same hash can provide a trustless exchange of assets. +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. #### **Business Approach** -Alice (the `depositor`) generates an HTLC with a preimage of her choosing. The contract stipulates that she will deposit 100 bitUSD into the account of Bob (the `recipient`), if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the 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 `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. -Bob examines the contract Alice created, being sure to examine that it contains his desired receiving account, asset symbol, asset quantity, preimage length, and the timelock threshold agrees with his desires. He then generates another HTLC that will deposit 10,000 bitshares into the account of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the contract identifier with Alice. +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. -Alice now examines the contract Bob created, being sure to examine that the receiving account, the amount, and the timeout agrees with her desires. She also verifies that the hash matches the hash of her contract. She now uses her preimage to "unlock" Bob's contract, which puts 10,000 bitshares into her account. This also posts the preimage on the BitShares blockchain. 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 `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. -Bob can now see the preimage that Alice used to receive her bitshares, and he can use the same preimage to "unlock" the contract Alice created, and receive the 100 bitUSD. 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 `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. ### **Cross-Chain Swap** -The set-price swap mentioned above works the same across chains that support HTLC. Bitcoin, as an example, supports HTLC. +Similar to the set-price swap mentioned above, two parties may exchange tokens between distinct blockchains when both implement HTLC support. Bitcoin, Litecoin and many others support HTLC [cite]. #### **Business Approach** -Alice generates an HTLC on the BitShares blockchain with a preimage of her choice. The contract stipulates that she will deposit 1 bitBTC into the account of Bob, if he provides the preimage that generates the stored hash before 10AM tomorrow. She then shares the contract identifier with Bob. +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. -Bob examines the contract Alice created, being sure to examine that the receiving account, the amount, and the timeout agrees with his desires. He then generates an HTLC that will deposit 1 BTC into the Bitcoin address of Alice, if she provides the preimage that generates the same hash before 5pm today. He then shares the Bitcoin transaction identifier with Alice. +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 now examines the contract Bob created, being sure to examine that the receiving account, the amount, and the timeout agrees with her desires. She also verifies that the hash matches the hash of her contract. She now uses her preimage to "unlock" Bob's contract, which puts 1 BTC into her Bitcoin wallet. This also posts the preimage on the Bitcoin blockchain. NOTE: She must do this before 5PM. Otherwise, Bob may (and should) reclaim the funds in the contract he created. +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. -Bob can now see the preimage that Alice used to receive her Bitcoin, and he can use the same preimage to "unlock" the contract Alice created, and receive the 1 bitBTC. NOTE: He must do this before 10AM tomorrow. Otherwise, Alice may (and should) reclaim the funds in the contract she created. +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. # **Discussion** From a1d16d3cdd589f44fc5d41b20c2127cdeda1dea5 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Tue, 28 Aug 2018 09:45:50 -0400 Subject: [PATCH 08/36] BSIP44: Hashed Timelock Contracts --- README.md | 3 ++- bsip-0000.md => bsip-0044.md | 14 +++++--------- 2 files changed, 7 insertions(+), 10 deletions(-) rename bsip-0000.md => bsip-0044.md (97%) diff --git a/README.md b/README.md index 2d23357..1626bfa 100644 --- a/README.md +++ b/README.md @@ -47,5 +47,6 @@ Number | Title | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 +[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 diff --git a/bsip-0000.md b/bsip-0044.md similarity index 97% rename from bsip-0000.md rename to bsip-0044.md index 59355e7..c7a5f29 100644 --- a/bsip-0000.md +++ b/bsip-0044.md @@ -1,8 +1,8 @@ -BSIP: xxxx\ +BSIP: 0044\ Title: Hashed Time-Locked Contract\ -Authors: John M. Jones, Ryan R. Fox, taconator\ +Authors: Ryan R. Fox, John M. Jones, taconator\ Status: Draft\ -Type: Informational\ +Type: Protocol\ Created: 2018-08-22\ Discussion: TBD @@ -90,8 +90,6 @@ The `timeout threshold` of the contract is defined by `depositor` within the HTL 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. -**TODO:** Consider adding an `Update_HTLC` operation to allow `depositor` to extend the `timeout threshold` - ### **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`. @@ -102,14 +100,10 @@ Code _could_ be added to automate the return of funds. This could be part of blo 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. -**TODO:** Discuss fees may be variable, as it is possible to store a variable length preimage hash. - ## **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. -**TODO:** Elaborate Interledger - ## **Existing Graphene Features that are Similar to What is Needed for Blockchain Escrowing** ### **BitShares Escrow** @@ -164,6 +158,8 @@ Bob has now observed the `preimage` Alice used to "unlock" his HTLC, and he will # **Discussion** +TBD + # **Summary for Shareholders** TBD From c2971903a3b184cf9bf32d8f1d0509be3fa38c0c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Wed, 29 Aug 2018 08:34:00 +0200 Subject: [PATCH 09/36] Completion of this BSIP from a formal standpoint and inclustion of a clear accepted/rejected state --- bsip-0042.md | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/bsip-0042.md b/bsip-0042.md index 2b5c2b0..8daae1e 100644 --- a/bsip-0042.md +++ b/bsip-0042.md @@ -1,12 +1,9 @@ BSIP: 0042 Title: Adjust price feed to influence trading price of SmartCoins Author: Abit More - Status: Draft + Status: Up for voting Type: Protocol Created: 2018-08-22 - Discussions: https://bitsharestalk.org/index.php?topic=26948.0 - https://bitsharestalk.org/index.php?topic=26315.0 - https://bitsharestalk.org/index.php?topic=26966.0 Workers: 1.14.118 (pro), 1.14.119 (con) # Abstract @@ -14,6 +11,8 @@ We here propose to dynamically adjust price feed in order to influence trading price of smart coins to achieve tighter peg. +This BSIP is constantly evaluated in terms of being accepted or rejected,see the last section *Constant voting evaluation* for details. + # Motivation To get mass adoption, it's better that the SmartCoins can peg to targets more @@ -156,11 +155,27 @@ by bugs. # Discussion -[To be added] +- https://bitsharestalk.org/index.php?topic=26948.0 +- https://bitsharestalk.org/index.php?topic=26315.0 +- https://bitsharestalk.org/index.php?topic=26966.0 # Summary for Shareholders -[To be added] +The peg of SmartCoin to the underlying asset is crucial to create trust for SmartCoin holders, in combination with a force settlement offset that is considered fair. This BSIP seeks to adress the issue of volatility with respect to the peg by allowing the witnesses to implement (within boundaries) their own price feed strategy that is targeted to uphold the peg and provide a fair force settlement offset. + +This is a crucial intrusion into the open market mechanics and is thus not a strict directive to the witnesses, furthermore this BSIP is constantly evaluated, and if it becomes rejected (see the next section), witnesses are bound to return to the former price feed mechanisms. + +# Constant voting evaluation + +This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected. + +- **Accepted**: +The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker. + +- **Rejected**: +The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected. + +The earliest that this worker can become active is 7th September 2018. # Copyright From d673e668a196eb105f4b489d73b2bba6770f122e Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Wed, 29 Aug 2018 12:35:51 +0300 Subject: [PATCH 10/36] bsip#43 Market fee sharing --- README.md | 1 + bsip-0043.md | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+) create mode 100644 bsip-0043.md diff --git a/README.md b/README.md index 2d23357..309680f 100644 --- a/README.md +++ b/README.md @@ -49,3 +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 +[43](bsip-0043.md) | Market fee sharing | OpenLedgerApp | Protocol | Draft diff --git a/bsip-0043.md b/bsip-0043.md new file mode 100644 index 0000000..fd26906 --- /dev/null +++ b/bsip-0043.md @@ -0,0 +1,96 @@ + BSIP: 0043 + Title: Market fee sharing + Authors: OpenLedgerApp + Status: Draft + Type: Protocol + Created: 2018-08-23 + Discussion: https://github.com/bitshares/bsips/issues/102 + Worker: + + +# Abstract + +When creating a new asset, the asset issuer is the only beneficiary of the market fees in the current implementation. And the only way to affect the asset community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset issuer might get a bigger profit during to increasing the trade volume with this asset. + +However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. +The workflow may be as following: + +An asset issuer defines the market_fee_reward_percent - what percentage of the market fee he wants to share with the registrar in asset options. Registrar defines reward_percent for the referrer for each user(using the already existing BitShares mechanism). +Market fee reward is accumulated on the user account. The user decides when they want to claim the market fee reward and move it to their active balance. There is another operation created asset_claim_reward_operation. Each user pays network fee to call this operation. + +# Motivation + +To make promoting BitShares and bringing new users much more attractive to registrars and referrers by sharing UIAs and MPAs market fees with them. + +# Rationale +When 'fill_order_operation' executing at the moment of market fee calculation there will be calculate the reward for the registrar used the parameter market_fee_reward_percent. Then this market_fee_reward_percent of the market fee is split between the registrar and referrer according to the referrer_rewards_percentage, which is set up during the new account registration by registrar (please see the parameters for register_account). + +# Specifications + +## market_fee_reward_percent asset option +Percent of market fee that will be paid to buyer's registrar. Set by UIA issuer. + +## market_sharing_whitelist asset option +An optional list of accounts (configurable by the UIA Issuer) could provide increased control over who is eligible to get market rewards. + +## New database and wallet api methods +**get_account_reward(account, asset_symbol)** - Returns information about the reward amount for specific asset. +**list_account_rewards(account)** - Returns information about the reward amount in various assets +**claim_reward(account, asset_symbol, amount)** - Claim account's reward for the given asset. + +## account_reward_object +A new BitShares object type in implementation space impl_account_reward_object_type = 2.18.X that tracks the rewards of a single account/asset pair +``` +account_reward_object { +owner_account, +asset_type, +reward_amount +} +``` +## account_reward_index +A new index that stores objects of account_reward_object-type in graphene::database and allow random fast access to objects by given criteria +``` +account_reward_index multi-index of account_reward_objects +indexed_by +[id] +[owner_account, asset_type] +[asset_type, reward_amount desc, owner_account] +``` +## asset_claim_reward_operation +A new operation used to transfer reward to the account's balance. +``` +asset_claim_reward_operation { +fee +claiming_account +amount_to_claim +} +``` + +## graphene::chain::database new methods +**get_reward(owner_account, asset_id)** - Retrieve a particular account's reward in a given asset +**adjust_reward(account, delta)** - Adjust a particular account's reward in a given asset by a delta + +## graphene::chain::database modifications +**pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset issuer fee, registrar fee and referrer fee. If the registrar is not in the market_sharing_whitelist, split_pay will not happen and the entire fee goes to Asset issuer. +**calculate_market_fee(trade_asset, trade_amount)** - Calculate value for previous function. +**fill_limit_order(order, pays, receives, cull_if_small, fill_price, is_maker)** - Append hardfork (HARDFORK_REWARD_TIME) check. Use old or new version of pay_market_fees() function. + +## asset_create_evaluator, asset_update_evaluator modifications +Append hardfork (HARDFORK_REWARD_TIME) check. Validate additional asset options. Apply additional asset options (market_fee_reward_percent, market_sharing_whitelist) + +## Unit tests + +Add: reward_tests.cpp (asset_rewards_test, asset_claim_reward_test) + +Modified: fee_tests.cpp, uia_tests.cpp + +# Description + +# Summary for Shareholders +The new modification - market fee sharing - will allow to bring in new clients for BitShares by making it financially lucrative for registrars and referrers. This modification is interesting mostly so asset issuers and registrars/referrers. + +# Copyright +This document is placed in the public domain. + +# See Also +https://github.com/bitshares/bitshares-core/issues/1268 \ No newline at end of file From b2dca448421d5f59df8baa8e0189322814ee0594 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Wed, 29 Aug 2018 13:09:34 +0200 Subject: [PATCH 11/36] add bitcrabs comment --- bsip-0042.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/bsip-0042.md b/bsip-0042.md index 8daae1e..3852a7a 100644 --- a/bsip-0042.md +++ b/bsip-0042.md @@ -153,6 +153,10 @@ Witnesses should make their own decisions on whether to set a hard limit and how much should it be if need to set one, generally, to reduce impacts caused by bugs. +It will be good to apply the change to bitCNY first, which has much better liquidity +than other smartcoins. After witnesses and community learned enough in the process +it can be also applied to bitUSD. + # Discussion - https://bitsharestalk.org/index.php?topic=26948.0 From 1961fb9c0030cec20a7e4efde7b419903a0aa3c9 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Wed, 29 Aug 2018 16:40:48 -0400 Subject: [PATCH 12/36] Fixup: Specifications --- bsip-0044.md | 137 ++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 120 insertions(+), 17 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index c7a5f29..452b7ba 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -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. + +### **Fees** -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. +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. -### **Fee** +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`. -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 "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** From 9f36ae2ad04c90e7070fc4abaa2a09c42b64ede4 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Thu, 30 Aug 2018 11:22:28 -0400 Subject: [PATCH 13/36] Change: Secured Assets, Fixup: Specification --- README.md | 2 +- bsip-0044.md | 58 ++++++++++++++++++++++++++++------------------------ 2 files changed, 32 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index 1626bfa..22d0ea0 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/bsip-0044.md b/bsip-0044.md index 452b7ba..3bdc25e 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -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) From 492851edfc1196cbb8487510a7c54dea9fa4a4a3 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Fri, 31 Aug 2018 10:49:53 -0400 Subject: [PATCH 14/36] Fixup: HTLC Object --- bsip-0044.md | 31 ++++++++++++++----------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index 3bdc25e..6f30e4f 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -174,23 +174,20 @@ Bob has now observed the `preimage` Alice used to "unlock" his HTLC, and he will ## **Objects** ``` -htlc_obj - id // int - depositor // account object - 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 - timeout_threshold // datetime - - // Constructor - Set: id = next available - Initialize other fields = NULL - - return contract + class htlc_object : public graphene::db::abstract_object { + public: + static const uint8_t space_id = implementation_ids; + static const uint8_t type_id = impl_htlc_object_type; + + account_id_type depositor; + account_id_type recipient; + asset amount; + fc::time_point_sec expiration; + asset pending_fee; + vector preimage_hash; + uint16_t preimage_size; + transaction_id_type preimage_tx_id; + }; ``` ## **Operations** From d14fad500b975c125039aa3258b8586f9c582fc2 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Thu, 6 Sep 2018 16:42:59 -0400 Subject: [PATCH 15/36] Fixup: API and Operations --- bsip-0044.md | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index 6f30e4f..e9beda7 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -223,9 +223,9 @@ transaction_obj htlc_redeem(fee_paying_account, id, preimage, htlc_redemption_fe Validate: transaction signed by requisite `authority` for `fee_paying_account` // any account may attempt to redeem Get: get_htlc(id) Validate: `fee_paying_account` account has requisite `quantity` of BTS for `htlc_redeem_fee` and `htlc_kb_fee` + Update: balance of `fee_paying_account` based on total fees // Evaluate: timelock if now() < `timeout_threshold` then return error // "timeout exceeded" - 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) @@ -234,6 +234,8 @@ transaction_obj htlc_redeem(fee_paying_account, id, preimage, htlc_redemption_fe Add: transaction to mempool Set: `id.preimage_tx_id` = `transaction_id` Cleanup: memory allocated to this htlc + Virtual Operation: Update account history for `depositor` to reflect redemption as by default the above operation will only appear for `redeemer` + return: results ``` @@ -241,7 +243,7 @@ transaction_obj htlc_redeem(fee_paying_account, id, preimage, htlc_redemption_fe ``` transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extention_fee) - Validate: transaction signed by requisite `authority` for `depositor` account + Validate: 'depositor' = get_htlc(id).depositor 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` @@ -250,9 +252,16 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent return results ``` -## **APIs** +### **At Expiry** -### **get_htlc** +``` + Get: get_htlc(id) + Update: balance of `depositor` add asset `id.symbol` of quantity `id.quantity` + Cleanup: memory allocated to this htlc + Virtual Operation: Update account history for `depositor` to reflect expiry without redemption. +``` + +## **cli_wallet APIs** ### **htlc_prepare** @@ -260,6 +269,10 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent ### **htlc_extend_expiry** +## **witness_node APIs** + +### **get_htlc** + # **Discussion** https://github.com/bitshares/bsips/pull/104 @@ -274,4 +287,4 @@ This document is placed in the public domain. # **See Also** -A description of [Hashed Timelock Contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) +A description of [Hashed Timelock Contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) \ No newline at end of file From 5f64cb0877ddc284dbee55aaa88a0c2bec77ab62 Mon Sep 17 00:00:00 2001 From: jmjatlanta Date: Fri, 21 Sep 2018 00:57:27 +0200 Subject: [PATCH 16/36] Added summary for tokenholders --- bsip-0044.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index e9beda7..6b9c687 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -277,9 +277,11 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent https://github.com/bitshares/bsips/pull/104 -# **Summary for Shareholders** +# **Summary for Tokenholders** -TBD +Hashed Timelock Contracts (HTLCs) allow account holders to transfer funds from their account (sender) to another account (receiver) before a certain time, only if the receiver knows the preimage (a.k.a. password). If used, the preimage is then published on the blockchain. If the transfer is not claimed before expiry, the funds return to the original account holder. + +Creating these contracts in pairs allow users to do a trustless exchange, even across blockchains. The typical scenario is that Account holder A agrees to make a transfer Account holder B on the Bitshares blockchain, and Account Holder B agrees to make a transfer to Account holder A on a foreign blockchain. Account holder A creates an HTLC on Bitshares, that includes a hash (an encrypted form of the preimage). Account holder B can view the HTLC, and decide to agree by creating an HTLC on the foreign blockchain, using the same hash. Account holder A then uses their preimage to receive the funds on the foreign blockchain, and in the process exposes the preimage. Account holder B can now use that preimage to receive the funds on the Bitshares blockchain. # **Copyright** From 3d4383bf93867350030c4db6ef72726e723cb426 Mon Sep 17 00:00:00 2001 From: "Ryan R. Fox" Date: Fri, 21 Sep 2018 04:34:46 -0400 Subject: [PATCH 17/36] Refine Summary for Tokenholders --- bsip-0044.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index 6b9c687..1f6cd62 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -279,9 +279,9 @@ https://github.com/bitshares/bsips/pull/104 # **Summary for Tokenholders** -Hashed Timelock Contracts (HTLCs) allow account holders to transfer funds from their account (sender) to another account (receiver) before a certain time, only if the receiver knows the preimage (a.k.a. password). If used, the preimage is then published on the blockchain. If the transfer is not claimed before expiry, the funds return to the original account holder. +Hashed Timelock Contracts (HTLCs) enable conditional transfers, whereby distinct account holders may transfer tokens from one account (`sender`) to a second account (`receiver`) before a defined expiry (`timelock`), only if the `preimage` (a.k.a. password) is revealed (`hashlock`) on the blockchain. If the `hashlock` condition is not satisfied prior to the `timelock` the tokens are return to the `sender`. -Creating these contracts in pairs allow users to do a trustless exchange, even across blockchains. The typical scenario is that Account holder A agrees to make a transfer Account holder B on the Bitshares blockchain, and Account Holder B agrees to make a transfer to Account holder A on a foreign blockchain. Account holder A creates an HTLC on Bitshares, that includes a hash (an encrypted form of the preimage). Account holder B can view the HTLC, and decide to agree by creating an HTLC on the foreign blockchain, using the same hash. Account holder A then uses their preimage to receive the funds on the foreign blockchain, and in the process exposes the preimage. Account holder B can now use that preimage to receive the funds on the Bitshares blockchain. +A typical scenario involves “Alice” and “Bob” each having accounts on the BitShares Network and addresses on the Bitcoin Network willing to trade their tokens. Alice will begin by creating an HTLC on BitShares to transfer BTS tokens from account `alice` to account `bob` with conditions set for hash of preimage (`hashlock`) and contract expiry (`timelock`). Bob will review her HTLC, if acceptable he will create an HTLC on the Bitcoin Network to transfer BTC from `his address` to `her address` with conditions set to the same `hashlock` value and a `timelock` value approximately half that specified by Alice. Next, Alice will review Bob’s HTLC for correctness and if acceptable, will redeem the BTC therein by publishing her `preimage` to satisfy the `hashlock` prior to the `timelock` expiry. Finally, Bob will observe the revealed `preimage` and use it to redeem Alice’s HTLC on the BitShares Network resulting in the BTS transferring to his account. Alice and Bob successfully exchanged native BTS and BTC at their agreed to ratio without any intermediaries. # **Copyright** @@ -289,4 +289,4 @@ This document is placed in the public domain. # **See Also** -A description of [Hashed Timelock Contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) \ No newline at end of file +A description of [Hashed Timelock Contracts](https://en.bitcoinwiki.org/wiki/Hashed_Timelock_Contracts) From ed2ff08a5c72742be72c1780cda6c0bd98263ef1 Mon Sep 17 00:00:00 2001 From: "John M. Jones" Date: Fri, 28 Sep 2018 13:06:09 -0500 Subject: [PATCH 18/36] Edits based on comments Removed outdated paragraph about user requesting refund after timeout (it is now automatic). Added method to retrieve all HTLC contracts by account. --- bsip-0044.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsip-0044.md b/bsip-0044.md index 1f6cd62..e0ae2e2 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -88,8 +88,6 @@ Upon presentation of a `preimage`, the HTLC `condition evaluator` validates: 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 `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 `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. @@ -252,7 +250,7 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent return results ``` -### **At Expiry** +### **At Expiry** (evaluated at each block commit) ``` Get: get_htlc(id) @@ -273,6 +271,8 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent ### **get_htlc** +### **get_htlcs_by_account** + # **Discussion** https://github.com/bitshares/bsips/pull/104 From 79b73409da285b3039f98bed98239e1bc48fa38e Mon Sep 17 00:00:00 2001 From: "John M. Jones" Date: Fri, 28 Sep 2018 13:12:53 -0500 Subject: [PATCH 19/36] Fixed method name for consistency --- bsip-0044.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsip-0044.md b/bsip-0044.md index e0ae2e2..994e243 100644 --- a/bsip-0044.md +++ b/bsip-0044.md @@ -271,7 +271,7 @@ transaction_obj htlc_extend_expiry(depositor, id, timeout_threshold, htlc_extent ### **get_htlc** -### **get_htlcs_by_account** +### **get_htlcs_for_account** # **Discussion** From d84c73428fba5a4c7e4bb86c49b3640097875a6c Mon Sep 17 00:00:00 2001 From: Denis Sokolov Date: Fri, 5 Oct 2018 19:00:40 +0300 Subject: [PATCH 20/36] Updated according to the discussions with community members --- bsip-0043.md | 43 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index fd26906..6f32c7a 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -4,19 +4,31 @@ Status: Draft Type: Protocol Created: 2018-08-23 + Updated: 2018-10-05 Discussion: https://github.com/bitshares/bsips/issues/102 Worker: # Abstract -When creating a new asset, the asset issuer is the only beneficiary of the market fees in the current implementation. And the only way to affect the asset community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset issuer might get a bigger profit during to increasing the trade volume with this asset. +When creating a new asset, the asset owner is the only beneficiary of the market fees in the current implementation. And one of the ways to increase the community growth is the market fee percentage. For example, one can decrease the market fee and it will result in somewhat larger number of trades with this asset. In this way the asset owner might get a bigger profit during to increasing the trade volume with this asset. However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. -The workflow may be as following: -An asset issuer defines the market_fee_reward_percent - what percentage of the market fee he wants to share with the registrar in asset options. Registrar defines reward_percent for the referrer for each user(using the already existing BitShares mechanism). -Market fee reward is accumulated on the user account. The user decides when they want to claim the market fee reward and move it to their active balance. There is another operation created asset_claim_reward_operation. Each user pays network fee to call this operation. +The workflow may be as follows. It is copied from vesting balance mechanism and got simplified. + +An asset owner defines the **market_fee_reward_percent** in asset options - what percentage of the market fee he wants to share with the registrar. +market_fee* market_fee_reward_percent goes the registar's fee pool. +market_fee*(1 - market_fee_reward_percent) goes to the asset owner. + + +Registrar defines **reward_percent** - for the referrer for each user(using the already existing BitShares mechanism). + +Market fee reward is accumulated on the user account. + +Each user decides when they want to claim the market fee reward and move it to their active balance. +There is another operation created asset_claim_reward_operation for this. +And each user pays network fee to call this operation. # Motivation @@ -27,11 +39,21 @@ When 'fill_order_operation' executing at the moment of market fee calculation th # Specifications +##Design decisions. +There has been a discussion going on about which way to implement distribution of the market fees for referrers. +Direct transfer and using vesting balance mechanism are some of the alternatives. +In our approach there has been decided to repicate the current functionality (to use the current vesting balance mechanism). +There is also an option to simplify the current design decisions specified below. +However, it requires that the related bitshares/bitshares-core#1276 is already implemented. If #1276 is implemented before BSIP-43, than BSIP-43 can be changed to accomodate #1276 changes. + + ## market_fee_reward_percent asset option -Percent of market fee that will be paid to buyer's registrar. Set by UIA issuer. +Percent of market fee that will be paid to buyer's registrar. Set by asset owner. +if market_fee_reward_percent = 0 or absent - the old mechanism is used. Market fees are accumulated in the asset and can be claimed. ## market_sharing_whitelist asset option -An optional list of accounts (configurable by the UIA Issuer) could provide increased control over who is eligible to get market rewards. +An optional list of accounts (configurable by the asset owner) could provide increased control over who is eligible to get market rewards. +If whitelist empty or absent - there is no filtering. This means that everyone is in the whitelist by default if it is empty. ## New database and wallet api methods **get_account_reward(account, asset_symbol)** - Returns information about the reward amount for specific asset. @@ -39,7 +61,9 @@ An optional list of accounts (configurable by the UIA Issuer) could provide incr **claim_reward(account, asset_symbol, amount)** - Claim account's reward for the given asset. ## account_reward_object -A new BitShares object type in implementation space impl_account_reward_object_type = 2.18.X that tracks the rewards of a single account/asset pair +A new BitShares object type in implementation space impl_account_reward_object_type = 2.18.X that tracks the rewards of a single account/asset pair. +Usually, vesting_balance_object receives fees from all kinds of transactions. +In this case, a user can't find out how much profit is received from market fee sharing. So a new object account_reward_object is created in order to track profits from market fee sharing only. ``` account_reward_object { owner_account, @@ -58,6 +82,7 @@ indexed_by ``` ## asset_claim_reward_operation A new operation used to transfer reward to the account's balance. +The purpose of this operation is to track profits from market fee sharing. ``` asset_claim_reward_operation { fee @@ -71,7 +96,7 @@ amount_to_claim **adjust_reward(account, delta)** - Adjust a particular account's reward in a given asset by a delta ## graphene::chain::database modifications -**pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset issuer fee, registrar fee and referrer fee. If the registrar is not in the market_sharing_whitelist, split_pay will not happen and the entire fee goes to Asset issuer. +**pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset owner fee, registrar fee and referrer fee. If the registrar is not in the market_sharing_whitelist, split_pay will not happen and the entire fee goes to Asset owner. **calculate_market_fee(trade_asset, trade_amount)** - Calculate value for previous function. **fill_limit_order(order, pays, receives, cull_if_small, fill_price, is_maker)** - Append hardfork (HARDFORK_REWARD_TIME) check. Use old or new version of pay_market_fees() function. @@ -87,7 +112,7 @@ Modified: fee_tests.cpp, uia_tests.cpp # Description # Summary for Shareholders -The new modification - market fee sharing - will allow to bring in new clients for BitShares by making it financially lucrative for registrars and referrers. This modification is interesting mostly so asset issuers and registrars/referrers. +The new modification - market fee sharing - will allow to bring in new clients for BitShares by making it financially lucrative for registrars and referrers. This modification is interesting mostly so asset owners and registrars/referrers. # Copyright This document is placed in the public domain. From 6aa3df5ff19d639271d581725e0c6a4b8fff3d45 Mon Sep 17 00:00:00 2001 From: CM Date: Sun, 7 Oct 2018 14:52:55 +0100 Subject: [PATCH 21/36] Create bsip 45 --- bsip-0045.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 bsip-0045.md diff --git a/bsip-0045.md b/bsip-0045.md new file mode 100644 index 0000000..b9f6b0d --- /dev/null +++ b/bsip-0045.md @@ -0,0 +1,85 @@ +BSIP: 45 +Title: Introduce 'allow use as bitasset backing collateral' flag/permission to assets +Authors: @grctest +Status: Draft +Type: Protocol +Created: 07/10/2018 +Discussion: https://github.com/bitshares/bsips/issues/80 +Replaces: N/A +Superseded-By: N/A +Worker: N/A + +--- + +# Abstract + +It's currently possible to impose new asset settings through MPA encapsulation without the permission of the backing asset's 'asset owner'. + +This BSIP proposes to introduce a new asset permission/flag which enables the asset owner to enable|prevent MPA encapsulation. + +# Motivation + +By encapsulating an asset (UIA/EBA|MPA) within a new MPA, you can impose new asset settings upon the underlying asset, to the possible detriment of the backing asset's 'asset owner'. + +# Rational + +By providing asset owners this functionality, we can improve asset owner confidence in the finality of their configured asset settings. + +# Specifications + +## Create new 'allow use as backing collateral' flag/permission + +Rather than create a system of inheriting permissions from backing collateral, a new flag/permission for 'allow use as MPA backing collateral' could simply prevent MPA encapsulation entirely at the discretion of the asset owner. + +Existing assets which are currently configured as an bitasset's backing collateral would require this flag to be set default enabled (allowed). This couldn't be changed unless the bitasset reconfigured to an alternative backing collateral - impossible if supply is greater than 0. + +Non applicable assets (PM & twice nested MPA) would prevent the flag from being enabled. + +Existing assets currently not used as backing collateral could be set to disabled by default. + +# Discussion + +## Consequences of MPA encapsulation + +* Removal/Bypassing of market fees (if enabled) +* Re-implementation of confidential transfers (if disabled) +* Evasion of whitelist/blacklist (both user & market lists) +* Preventing the issuer from transfering the asset back to themselves (Can't transfer backing collateral back to yourself) +* Remove backing asset issuer from transfer approval provess. + +## Committee configuration + +Should all smartcoins be allowed as bitasset backing collateral? Given that XCD already does this with bitUSD, I think it's appropriate. That said, not all committee owned bitassets are in a stable state (bitGOLD for example is in global settlement state right now). + +## Enabling the flag grants permisson for all + +Currently you can perform MPA encapsulation without involving the asset owner, this could introduce conflict between the two asset owners. + +If the flag is enabled, that's an indication that the asset owner accepts any bitasset use case - you wouldn't need to seek explicit permission prior to creating experimental bitassets on the BTS DEX. + +If it's disabled, that's a clear indication that the asset owner doesn't want it used as backing collateral. + +## How to configure assets held by null-account? + +It's possible that bitassets may be owned by null-account but remain operational, configuring default disabled would burn the possibility of encapsulation - if these assets exist then if possible should be set to enabled? + +## Proposed UI changes + +This flag could only work as long as no MPA has already selected the asset as its backing collateral; setting this as default disabled (not allowed) for newly created assets in the asset creation form could help prevent the asset being used as backing collateral without the user's knowledge. + +--- + +# Summary for Shareholders + +* Would likely require a hard fork. +* Introduces new asset owner permissions. +* Helps mitigate negative MPA encapsulation consequences, improving gateway regulatory compliance capability? +* Given enabled flags could constitute advanced permission for MPA use case, there may be UIA backed MPA created which would contribute BTS fees to the reserve pool. + +# Copyright + +This document is placed in the public domain, 100% open source & should be considered MIT licensed. + +# See Also + +N/A From c454764eb0579781cca2171818a662ad8c4f4bfb Mon Sep 17 00:00:00 2001 From: CM Date: Sun, 7 Oct 2018 14:53:48 +0100 Subject: [PATCH 22/36] bsip 45 added to readme --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 2d23357..9ed4b19 100644 --- a/README.md +++ b/README.md @@ -49,3 +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 +[45](bsip-0045.md) | Introduce 'allow use as bitasset backing collateral' flag/permission to assets | Customminer | Protocol | Draft From 2a4c2b7e9ab3122e9b0ed008b8ae74cc5f784ace Mon Sep 17 00:00:00 2001 From: CM Date: Sun, 7 Oct 2018 14:54:21 +0100 Subject: [PATCH 23/36] Fixed formatting --- bsip-0045.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bsip-0045.md b/bsip-0045.md index b9f6b0d..2e3c530 100644 --- a/bsip-0045.md +++ b/bsip-0045.md @@ -1,3 +1,4 @@ +``` BSIP: 45 Title: Introduce 'allow use as bitasset backing collateral' flag/permission to assets Authors: @grctest @@ -8,7 +9,7 @@ Discussion: https://github.com/bitshares/bsips/issues/80 Replaces: N/A Superseded-By: N/A Worker: N/A - +``` --- # Abstract From f03f4ce7ab1d66c6aecd4157aa3fcf25c513d222 Mon Sep 17 00:00:00 2001 From: CM Date: Mon, 8 Oct 2018 16:41:32 +0100 Subject: [PATCH 24/36] Update bsip-0045.md --- bsip-0045.md | 1 - 1 file changed, 1 deletion(-) diff --git a/bsip-0045.md b/bsip-0045.md index 2e3c530..46d76d6 100644 --- a/bsip-0045.md +++ b/bsip-0045.md @@ -72,7 +72,6 @@ This flag could only work as long as no MPA has already selected the asset as it # Summary for Shareholders -* Would likely require a hard fork. * Introduces new asset owner permissions. * Helps mitigate negative MPA encapsulation consequences, improving gateway regulatory compliance capability? * Given enabled flags could constitute advanced permission for MPA use case, there may be UIA backed MPA created which would contribute BTS fees to the reserve pool. From ee9ec4cd45b1294e72fad5424495861a2cbbbc8c Mon Sep 17 00:00:00 2001 From: grcgrc Date: Wed, 10 Oct 2018 13:57:51 +0100 Subject: [PATCH 25/36] License change MIT -> PD --- bsip-0021.md | 2 +- bsip-0022.md | 2 +- bsip-0023.md | 2 +- bsip-0024.md | 2 +- bsip-0045.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/bsip-0021.md b/bsip-0021.md index ee77bdf..703f9fb 100644 --- a/bsip-0021.md +++ b/bsip-0021.md @@ -107,7 +107,7 @@ for each asset_holder in coin_age_hashmap { # Copyright -N/A - Consider this BSIP entirely open-source/MIT-licensed, I am not the originator of the concept of 'coin-age' (several proof-of-stake cryptocurrencies make use of coin-age for finding stakable coins). +This document is placed in the public domain. # See Also * [List account balances - Graphene documentation](http://docs.bitshares.org/api/database.html#id8) diff --git a/bsip-0022.md b/bsip-0022.md index 9cfa195..7b149ce 100644 --- a/bsip-0022.md +++ b/bsip-0022.md @@ -119,7 +119,7 @@ Please do raise your concerns, propose improvements and engage in the BSIP creat # Copyright -This document is placed in the public domain, 100% open source & should be considered MIT licensed. +This document is placed in the public domain. # See Also diff --git a/bsip-0023.md b/bsip-0023.md index f71ad1e..5209283 100644 --- a/bsip-0023.md +++ b/bsip-0023.md @@ -651,7 +651,7 @@ The Bitshares starship drops out of hyperspace in planet Bitcoin's orbit, the cr # Copyright -This document is placed in the public domain, 100% open source & should be considered MIT licensed. +This document is placed in the public domain. # See Also diff --git a/bsip-0024.md b/bsip-0024.md index 3169c6c..cd6b76e 100644 --- a/bsip-0024.md +++ b/bsip-0024.md @@ -62,7 +62,7 @@ Would there even be a difference in voting behaviour betwen the two? Perhaps it # Copyright -This document is placed in the public domain, 100% open source & should be considered MIT licensed. +This document is placed in the public domain. # See Also diff --git a/bsip-0045.md b/bsip-0045.md index 46d76d6..b6ffd77 100644 --- a/bsip-0045.md +++ b/bsip-0045.md @@ -78,7 +78,7 @@ This flag could only work as long as no MPA has already selected the asset as it # Copyright -This document is placed in the public domain, 100% open source & should be considered MIT licensed. +This document is placed in the public domain. # See Also From b9a2774df95c8daaf3c9830cd5b7ff133d5fed8f Mon Sep 17 00:00:00 2001 From: OpenLedgerApp Date: Fri, 19 Oct 2018 18:20:52 +0300 Subject: [PATCH 26/36] rewards issue --- bsip-0043.md | 87 +++++++++------------------------------------------- 1 file changed, 15 insertions(+), 72 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index 6f32c7a..8c48369 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -4,7 +4,7 @@ Status: Draft Type: Protocol Created: 2018-08-23 - Updated: 2018-10-05 + Updated: 2018-10-19 Discussion: https://github.com/bitshares/bsips/issues/102 Worker: @@ -15,99 +15,42 @@ When creating a new asset, the asset owner is the only beneficiary of the market However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. -The workflow may be as follows. It is copied from vesting balance mechanism and got simplified. +An asset owner defines the **market_fee_reward_percent** in asset options - what percentage of the market fee he wants to share with the registrar. +**market_fee** * **market_fee_reward_percent** goes the registar's fee pool. +**market_fee** * (1 - **market_fee_reward_percent**) goes to the asset owner. -An asset owner defines the **market_fee_reward_percent** in asset options - what percentage of the market fee he wants to share with the registrar. -market_fee* market_fee_reward_percent goes the registar's fee pool. -market_fee*(1 - market_fee_reward_percent) goes to the asset owner. +Registrar defines **reward_percent** - for the referrer for each user (using the already existing BitShares mechanism). -Registrar defines **reward_percent** - for the referrer for each user(using the already existing BitShares mechanism). +Market fee reward is accumulated on the user account. -Market fee reward is accumulated on the user account. - -Each user decides when they want to claim the market fee reward and move it to their active balance. -There is another operation created asset_claim_reward_operation for this. -And each user pays network fee to call this operation. +Each user decides when he wants to claim the market fee reward and move it to their active balance. # Motivation To make promoting BitShares and bringing new users much more attractive to registrars and referrers by sharing UIAs and MPAs market fees with them. # Rationale -When 'fill_order_operation' executing at the moment of market fee calculation there will be calculate the reward for the registrar used the parameter market_fee_reward_percent. Then this market_fee_reward_percent of the market fee is split between the registrar and referrer according to the referrer_rewards_percentage, which is set up during the new account registration by registrar (please see the parameters for register_account). +When *fill_order_operation* executing at the moment of market fee calculation there will be calculate the reward for the registrar used the parameter **market_fee_reward_percent**. Then this **market_fee_reward_percent** of the market fee is split between the registrar and referrer according to the referrer_rewards_percentage, which is set up during the new account registration by registrar (please see the parameters for *register_account*). # Specifications +Market fee rewards accumulated on special vesting balances. -##Design decisions. -There has been a discussion going on about which way to implement distribution of the market fees for referrers. -Direct transfer and using vesting balance mechanism are some of the alternatives. -In our approach there has been decided to repicate the current functionality (to use the current vesting balance mechanism). -There is also an option to simplify the current design decisions specified below. -However, it requires that the related bitshares/bitshares-core#1276 is already implemented. If #1276 is implemented before BSIP-43, than BSIP-43 can be changed to accomodate #1276 changes. - - -## market_fee_reward_percent asset option +## **market_fee_reward_percent** asset option Percent of market fee that will be paid to buyer's registrar. Set by asset owner. -if market_fee_reward_percent = 0 or absent - the old mechanism is used. Market fees are accumulated in the asset and can be claimed. +if **market_fee_reward_percent** = 0 or absent - the old mechanism is used. Market fees are accumulated in the asset and can be claimed. -## market_sharing_whitelist asset option +## **market_sharing_whitelist** asset option An optional list of accounts (configurable by the asset owner) could provide increased control over who is eligible to get market rewards. If whitelist empty or absent - there is no filtering. This means that everyone is in the whitelist by default if it is empty. -## New database and wallet api methods -**get_account_reward(account, asset_symbol)** - Returns information about the reward amount for specific asset. -**list_account_rewards(account)** - Returns information about the reward amount in various assets -**claim_reward(account, asset_symbol, amount)** - Claim account's reward for the given asset. - -## account_reward_object -A new BitShares object type in implementation space impl_account_reward_object_type = 2.18.X that tracks the rewards of a single account/asset pair. -Usually, vesting_balance_object receives fees from all kinds of transactions. -In this case, a user can't find out how much profit is received from market fee sharing. So a new object account_reward_object is created in order to track profits from market fee sharing only. -``` -account_reward_object { -owner_account, -asset_type, -reward_amount -} -``` -## account_reward_index -A new index that stores objects of account_reward_object-type in graphene::database and allow random fast access to objects by given criteria -``` -account_reward_index multi-index of account_reward_objects -indexed_by -[id] -[owner_account, asset_type] -[asset_type, reward_amount desc, owner_account] -``` -## asset_claim_reward_operation -A new operation used to transfer reward to the account's balance. -The purpose of this operation is to track profits from market fee sharing. -``` -asset_claim_reward_operation { -fee -claiming_account -amount_to_claim -} -``` - -## graphene::chain::database new methods -**get_reward(owner_account, asset_id)** - Retrieve a particular account's reward in a given asset -**adjust_reward(account, delta)** - Adjust a particular account's reward in a given asset by a delta - ## graphene::chain::database modifications -**pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset owner fee, registrar fee and referrer fee. If the registrar is not in the market_sharing_whitelist, split_pay will not happen and the entire fee goes to Asset owner. +**pay_market_fees(seller, recv_asset_object, receives_amount)** - Split pay to asset owner fee, registrar fee and referrer fee. If the registrar is not in the **market_sharing_whitelist**, *split_pay* will not happen and the entire fee goes to Asset owner. **calculate_market_fee(trade_asset, trade_amount)** - Calculate value for previous function. -**fill_limit_order(order, pays, receives, cull_if_small, fill_price, is_maker)** - Append hardfork (HARDFORK_REWARD_TIME) check. Use old or new version of pay_market_fees() function. +**fill_limit_order(order, pays, receives, cull_if_small, fill_price, is_maker)** - Append hardfork (HARDFORK_REWARD_TIME) check. Use old or new version of *pay_market_fees()* function. ## asset_create_evaluator, asset_update_evaluator modifications -Append hardfork (HARDFORK_REWARD_TIME) check. Validate additional asset options. Apply additional asset options (market_fee_reward_percent, market_sharing_whitelist) - -## Unit tests - -Add: reward_tests.cpp (asset_rewards_test, asset_claim_reward_test) - -Modified: fee_tests.cpp, uia_tests.cpp +Append hardfork (HARDFORK_REWARD_TIME) check. Validate additional asset options. Apply additional asset options (**market_fee_reward_percent**, **market_sharing_whitelist**) # Description From 298a9a9ad52bc412739e77a913dc22fdfa15d642 Mon Sep 17 00:00:00 2001 From: OpenLedgerApps Date: Mon, 22 Oct 2018 10:42:36 +0300 Subject: [PATCH 27/36] updated wording --- bsip-0043.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bsip-0043.md b/bsip-0043.md index 8c48369..7c5e328 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -16,11 +16,11 @@ When creating a new asset, the asset owner is the only beneficiary of the market However, there might be another opportunity to promote the asset and stimulate the trading - use native Bitshares referral program. At this time unfortunately an assets owner is not able to share market fees with registrars and referrers to stimulate them to market the asset trading, so we suggest to add this possibility. Furthermore, enabling this feature for MPAs (e.g. bitCNY or bitUSD) can provide additional bounty for Bitshares registrars and referrals which can lead to more traders joining to the ecosystem. An asset owner defines the **market_fee_reward_percent** in asset options - what percentage of the market fee he wants to share with the registrar. -**market_fee** * **market_fee_reward_percent** goes the registar's fee pool. +**market_fee** * **market_fee_reward_percent** goes the registrar. **market_fee** * (1 - **market_fee_reward_percent**) goes to the asset owner. - -Registrar defines **reward_percent** - for the referrer for each user (using the already existing BitShares mechanism). +Registrar splits the reward between itself and its referrers by defining **reward_percent**, which defines referrer's percentage. +It is defined per each other using the already existing BitShares mechanism. Market fee reward is accumulated on the user account. From f79cc75b157c08539af87b7d473157626a05af8c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Fri, 26 Oct 2018 09:50:14 +0200 Subject: [PATCH 28/36] update bsip40 status --- bsip-0040.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bsip-0040.md b/bsip-0040.md index 9332eaf..19615ad 100644 --- a/bsip-0040.md +++ b/bsip-0040.md @@ -7,11 +7,11 @@ Fabian Schuh Abit Peter Conrad - Status: Draft + Status: Milestone 1 accepted, other Milestones postponed Type: Protocol Created: 2018-07-25 Discussion: https://github.com/bitshares/bitshares-core/issues/1061 - Worker: + Worker: 1.14.120 # Abstract From 47ef860eafb3125798a343a83113570f14099fbe Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Fri, 26 Oct 2018 13:26:54 -0400 Subject: [PATCH 29/36] Update: Available BSIPs Table --- README.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7690dde..0ec3e6c 100644 --- a/README.md +++ b/README.md @@ -47,8 +47,17 @@ Number | Title | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 +[40](bsip-0040.md) | Custom Active Permission | Stefan Schießl | Protocol | Accepted [42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft -[43](bsip-0043.md) | Market fee sharing | OpenLedgerApp | Protocol | Draft -[44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Draft -[45](bsip-0045.md) | Introduce 'allow use as bitasset backing collateral' flag/permission to assets | Customminer | Protocol | Draft +[43](bsip-0043.md) | Market Fee Sharing | OpenLedgerApp | Protocol | Accepted +[44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Accepted +[45](bsip-0045.md) | Add bitAsset Backing Collateral flag/permission | Customminer | Protocol | Draft +[46](https://github.com/bitshares/bsips/pull/111) | Escrow Concepts | Taconator | Informational | Draft +[47](https://github.com/bitshares/bsips/pull/114) | An Explicit Voting Operation | Fabian Schuh | Protocol | Draft +[48](https://github.com/bitshares/bsips/pull/115) | Add Flad to Asset to Prevent Manipulating Max Supply | Fabian Schuh | Protocol | Draft +[50](https://github.com/bitshares/bsips/pull/) | Stealth development, Phase II | Chris Sanborn | Informational | Draft +[51](https://github.com/bitshares/bsips/pull/) | New operations for Confidential Asset (CA) transactions | Chris Sanborn | Protocol | Draft +[52](https://github.com/bitshares/bsips/pull/) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol | Draft +[53](https://github.com/bitshares/bsips/pull/116) | Blockchain scanning for inbound Stealth transactions | Chris Sanborn | Protocol | Draft +[54](https://github.com/bitshares/bsips/pull/) | Deterministic addresses for Stealth wallets | Chris Sanborn | Informational | Draft +[55](https://github.com/bitshares/bsips/pull/) | Metadata hiding via Garlic Routing and other means | Chris Sanborn | Informational | Draft From 203f66fd6f87dfb7215031b729eeae5cc475f7f2 Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Sun, 28 Oct 2018 20:26:01 -0400 Subject: [PATCH 30/36] Update 40 w M1 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0ec3e6c..59ffd7a 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,7 @@ Number | Title | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 | Accepted +[40](bsip-0040.md) | Custom Active Permission | Stefan Schießl | Protocol | Milestone 1 Accepted [42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft [43](bsip-0043.md) | Market Fee Sharing | OpenLedgerApp | Protocol | Accepted [44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Accepted From 71427c91d89650060c492435d2a45df3a25aeb36 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Mon, 29 Oct 2018 08:19:29 +0100 Subject: [PATCH 31/36] readme status to accepteed --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7690dde..9ef8cfa 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,7 @@ Number | Title | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 +[40](bsip-0040.md) | Custom active permission | Stefan Schießl | Protocol | Accepted [42](bsip-0042.md) | Adjust price feed to influence trading price of SmartCoins | Abit More | Protocol | Draft [43](bsip-0043.md) | Market fee sharing | OpenLedgerApp | Protocol | Draft [44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Draft From 7adf9b090786aa43f5bec34aec4881563fa6b23e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20Schie=C3=9Fl?= Date: Tue, 30 Oct 2018 14:20:44 +0100 Subject: [PATCH 32/36] rollback --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9ef8cfa..7690dde 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,7 @@ Number | Title | [37](bsip-0037.md) | Allow new asset name to end with a number | oxarbitrage | Protocol | Installed [38](bsip-0038.md) | Add target collateral ratio option to short positions | Abit More | Protocol | Installed [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 | Accepted +[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 [43](bsip-0043.md) | Market fee sharing | OpenLedgerApp | Protocol | Draft [44](bsip-0044.md) | Hashed Time-Locked Contract | Ryan R. Fox | Protocol | Draft From 8b8cf94b8e96d1fbb6a16722b3d11365a00fb0db Mon Sep 17 00:00:00 2001 From: ryanRfox Date: Thu, 1 Nov 2018 09:35:13 -0400 Subject: [PATCH 33/36] Fixup: Typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 59ffd7a..424f80d 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,7 @@ Number | Title | [45](bsip-0045.md) | Add bitAsset Backing Collateral flag/permission | Customminer | Protocol | Draft [46](https://github.com/bitshares/bsips/pull/111) | Escrow Concepts | Taconator | Informational | Draft [47](https://github.com/bitshares/bsips/pull/114) | An Explicit Voting Operation | Fabian Schuh | Protocol | Draft -[48](https://github.com/bitshares/bsips/pull/115) | Add Flad to Asset to Prevent Manipulating Max Supply | Fabian Schuh | Protocol | Draft +[48](https://github.com/bitshares/bsips/pull/115) | Add Flag to Asset to Prevent Manipulating Max Supply | Fabian Schuh | Protocol | Draft [50](https://github.com/bitshares/bsips/pull/) | Stealth development, Phase II | Chris Sanborn | Informational | Draft [51](https://github.com/bitshares/bsips/pull/) | New operations for Confidential Asset (CA) transactions | Chris Sanborn | Protocol | Draft [52](https://github.com/bitshares/bsips/pull/) | Ring signatures for untraceability of Stealth transactions | Chris Sanborn | Protocol | Draft From 185d4b3af42cf386173d43a173ea81d3318e91f0 Mon Sep 17 00:00:00 2001 From: Alfredo Garcia Date: Thu, 8 Nov 2018 08:52:14 -0300 Subject: [PATCH 34/36] add pull request link --- bsip-0043.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bsip-0043.md b/bsip-0043.md index 7c5e328..c9ec77a 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -61,4 +61,5 @@ The new modification - market fee sharing - will allow to bring in new clients f This document is placed in the public domain. # See Also -https://github.com/bitshares/bitshares-core/issues/1268 \ No newline at end of file +https://github.com/bitshares/bitshares-core/issues/1268 +https://github.com/bitshares/bitshares-core/pull/1419 From c4bd215aede0905f52f5fca850f89fec80c82c86 Mon Sep 17 00:00:00 2001 From: Alfredo Garcia Date: Thu, 8 Nov 2018 11:24:44 -0300 Subject: [PATCH 35/36] add newline to link sorry, need a newline at the link or will look wrong(in the same line) --- bsip-0043.md | 1 + 1 file changed, 1 insertion(+) diff --git a/bsip-0043.md b/bsip-0043.md index c9ec77a..90bd660 100644 --- a/bsip-0043.md +++ b/bsip-0043.md @@ -62,4 +62,5 @@ This document is placed in the public domain. # See Also https://github.com/bitshares/bitshares-core/issues/1268 + https://github.com/bitshares/bitshares-core/pull/1419 From c245a4c86ae90a1d4a84026ed419729e93cdfc44 Mon Sep 17 00:00:00 2001 From: Fabian Schuh Date: Tue, 18 Dec 2018 10:49:32 +0100 Subject: [PATCH 36/36] Minor markdown fixes --- bsip-0041.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/bsip-0041.md b/bsip-0041.md index b0b8e9d..a0ac282 100644 --- a/bsip-0041.md +++ b/bsip-0041.md @@ -25,14 +25,14 @@ We need to release risks rapidly while margin call happen, we also need to try t bitCNY have a very good liquidity, BTS/bitCNY pair in DEX is the pair with highest BTS volume on the earth, after in 19th July the hard fork activated the target CR feature, the sell pressure comes from margin called orders decreased greatly, we are sure that the for bitCNY black swan has very very little chance to happen, it’s the time to reduce MSSR to push bitCNY ecosysm move forward. +### **Specification** +Witnesses adjust the MSSR of bitCNY from 1.1 to 1.05 while publishing feed price. +### Discussion +#### Will this change be implemented to bitUSD and other smartcoins? +This time, no! bitUSD and other smartcoins has a much lower liquidity than bitCNY, a high MSSR need to be kept to guarantee the rapid settlement of margin called dept positions. -### **Specification** -witnesses adjust the MSSR from 1.1 to 1.05 while publishing feed price. -Discussion -Will this change be implemented to bitUSD and other smartcoins? -this time No, bitUSD and other smartcoins has a much lower liquidity than bitCNY, a high MSSR need to be kept to guarantee the rapid settlement of margin called dept positions. -How to make sure a strong consensus is reached? +#### How to make sure a strong consensus is reached? China community has discussed about this change for years, however, target CR feature + good bitCNY liquidity make current time the good time to do the change, in the forum thread, about 70% of the voters support this change, if necessary, a opinion survey worker proposal will be created to collect stake based opinion. As MSSR comes from witness publishing, so when BTS community reach a strong consensus to do the change, we need witnesses to apply the change based on the community consensus