BitShares Forum
Main => General Discussion => Topic started by: Fox on April 03, 2019, 02:05:23 pm
-
TO: BitShares Committee
FROM: BitShares Core Team
REFERENCE: https://github.com/bitshares/bitshares-core/issues/1694
RE: Core Team Recommendations for HTLC Parameters
This post is intended to be an open letter from the Core Team to the Committee to provide recommendations and explanations for consideration when setting the required values to activate HTLC functionality included in the BitShares 3.0.0 Protocol Upgrade Release on 23 APR 2019. Implementation of BSIP44 introduces the following Committee-controlled chain parameters and fees [1]. The Core Team intentionally left the fees and parameters blank in the code. Only the Committee may set (and modify as needed) these protocol parameters. The Core Team offers recommendations denominated in USD, allowing the Committee to convert to BTS using their established process.
Chain Parameters for HTLC:
max_timeout_secs
This is the maximum time the HTLC my live before the funds revert to the sender. In Bitcoin, this can be any time in the future. For BitShares, we recommend 2592000 seconds (30 Days).
While active, these contracts remain in RAM. Allowing an indefinite lifetime to the contract somewhat defeats the purpose of an HTLC and unnecessarily uses a valuable system resource. It is believed that most HTLCs will live around 6 hours. It is believed that 30 days will easily cover most known use cases.
max_preimage_size
If the contract is redeemed by providing the preimage, the contract is no longer in RAM. However, the preimage is stored in the blockchain. This parameter limits the size of the preimage that can be used to redeem an HTLC.
It is believed that the vast majority of preimages will be 256 bytes or 512 bytes which provide sufficient entropy for security. We recommend 10kb initially.
Note: Higher per-kilobyte fees should help mitigate the use of large preimages. Preimage size is a tiered calculation where bytes 1-1024 are included in the minimum fee of 1 kilobyte and a preimage of 1025 bytes would calculate in the second tier of 2 kilobytes.
Fees for HTLC:
htlc_create_operation::fee
Creating an HTLC has two component fees: a fixed fee to execute the operation and a variable daily fee to store the contract in RAM. Our recommendation is to keep the total cost of a single day HTLC near the cost to execute the transfer operation.
We recommend setting this fee to $0.001 USD (a tenth of a cent) as the fixed component and using the fee_per_day below to equate to near the transfer operation fee for a single day HTLC.
htlc_create_operation::fee_per_day
These contracts sit in RAM until they are redeemed by either party. Memory is a limited resource, and should be considered when setting fees for HTLC. It is envisioned that the typical HTLC will be less than 1 day and thus pay the minimum cost of one fee_per_day. To encourage adoption of this technology we feel $1 USD/month to hold open an HTLC is sufficient. We recommend $0.033 USD per day.
htlc_redeem_operation::fee
The redeem operation also has a pair of related fees: operation fee and fee_per_kilobyte. Similarly, we recommend these fees be nominal for the fixed component and quite large for the variable component, as this requires permanent storage space within the blockchain to retain the preimage.
We recommend setting this fee to $0.001 USD (a tenth of a cent) as the fixed component and using the fee_per_kb below to encourage appropriate use of the blockchain resources.
htlc_redeem_operation::fee_per_kb
The preimage size is known up-front, so a redeemer can calculate their total cost of redemption before the preimage is known. Hence, if redemption cost is a deciding factor as to whether to perform the transaction, the total cost can be calculated.
We expect most HTLC transactions can be secured with a preimage well under 1kb, the current minimum fee tier. 512 bits or even 256 bits provide adequate entropy. If large preimages are desired, a large fee will be charged. We recommend $0.10 USD as the initial fee per kilobyte.
htlc_extend_operation::fee
This operation allows the HTLC to be extended to up to the maximum_timeout_seconds defined above. Allowing indefinite length contracts. It is recommended to match the fixed creation fee defined above.
htlc_extend_operation::fee_per_day
Similarly, we recommend to match the create fee_per_day defined above.
[1] https://github.com/bitshares/bsips/blob/master/bsip-0044.md (https://github.com/bitshares/bsips/blob/master/bsip-0044.md)
-
[EDITS]
April 04, 2019, 01:12:10 am : Changed create/redeem fixed component fees to $0.001 USD (from 0.1 BTS) to remain consistent with intent of 1) denominating in USD and 2) keeping the fixed fee nominal to allow using the variable per day/kb fee as the majority cost component of the respective operation.
-
Why some denominated in USD terms and others in BTS terms?
-
We decided to leave the fixed operation fees as BTS to allow the Committee to adjust the variable component fee per day or fee per kilobyte in USD terms. They can also be converted to USD fees. The recommendation is the fixed component in nominal.
-
Thanks for the heads up fox. I think the committee should follow your recommendations and test how it'll work out.
-
I like all of those default values as I don't have better proof to change.
-
We decided to leave the fixed operation fees as BTS to allow the Committee to adjust the variable component fee per day or fee per kilobyte in USD terms. They can also be converted to USD fees. The recommendation is the fixed component in nominal.
The fees look good, thus denoting them in different basis seems also weird to me. Anyways, thanks for the initiative!
-
April 04, 2019, 01:12:10 am : Changed create/redeem fixed component fees to $0.001 USD (from 0.1 BTS) to remain consistent with intent of 1) denominating in USD and 2) keeping the fixed fee nominal to allow using the variable per day/kb fee as the majority cost component of the respective operation.