@GeneralProtocols 30 May 2020 edited

AnyHedge - safe boundaries for contracts

Due to the way math works in Bitcoin Cash script, the results of some types of calculation are not perfectly accurate. "Anyhedge Numerical Error Analysis", by Karol Trzeszczkowski, describes how AnyHedge provides safe boundaries so that accuracy will not be a problem in contracts. https://anyhedge.com/downloads/AnyHedge%20Numerical%20Analysis.pdf https://github.com/KarolTrzeszczkowski What are the safe boundaries?

Skipping to the conclusion, the figures at the end of Karol's paper provide a good summary. All of the figures have different information, but Figure 1. has the most critical boundaries. The figure assumes that we want to have at least 99.85% accuracy (0.15% worst case error) in the outcome of the contract compared to the ideal world where we get perfect accuracy. The white area shows settings where a contract cannot guarantee the accuracy. The shaded area shows where a contract can guarantee the accuracy. Let's put some specific numbers on it: `hedge_value` is in arbitrary units. Let's say US cents. `start_price` uses the same units so we would have US cents per BCH. Then on this graph it means that we get excellent accuracy as long as we ensure: Contract value is greater than about 140 US Cents ($1.40 USD) Start price is less than 10,000,000 US Cents/BCH ($100,000 USD/BCH) When you use General Protocol's API for AnyHedge, you can be sure that the contracts will always be inside a safe range. Bitcoin Cash script, AnyHedge, and accuracy In the AnyHedge whitepaper there is a high level simulation of how the contract works. Then at the bottom of the paper there is a reference to "A detailed example execution of AnyHedge". If you compare the two, you will see that the detailed execution is much longer and more complicated than the high level one. https://gitlab.com/GeneralProtocols/anyhedge/whitepaper/-/blob/master/anyhedge.md#6-high-level-execution-of-anyhedge https://gitlab.com/GeneralProtocols/anyhedge/whitepaper/-/blob/master/anyhedge-supplement.md The reason for the complexity is mostly related to helping AnyHedge retain calculation accuracy given the current limitations of Bitcoin Cash script. The two sources of error that it corrects for are **integer division** and **truncation**. Integer division with no decimal places "Integer" roughly means numbers like `0`, `1`, `2`, `3`. Numbers with decimal points like `0.5` and `1.2` are not integers. Bitcoin Cash script works with integers and has no native concept of decimal points. Integer calculations works well for: **addition**: `1` + `3` = `4` **subtraction**: `1` - `3` = `-2` **multiplication**: `1` x `3` = `3` (Actually, Bitcoin and Bitcoin Cash script both do not have multiplication. Bitcoin Cash will almost certainly get it in a future upgrade.) Integer calculations work well for **division** in some cases: `4000` / `2` = `2000` But here is where the problems appear: `4000` / `6` = `666.66...`? Not in script. The result is `666` (not `667`). In this case, the impact is not large. 0.66 is only 0.01% of the larger value. However in other cases, it can cause a large problem with correctness of the calculations. This is one of the sources of inaccuracy that Karol's boundaries handle. `4` / `6` = `0` If you are famliar with the `modulo` operator, we also use that to recover some accuracy, which you can read about in the paper. Truncation of big numbers In Bitcoin script, BCH is measured in Satoshis. The numbers can be very big. For example you might know already that `1` BCH = `100,000,000` Satoshis. Bitcoin Cash transactions can handle any amount of Satoshis, but ***calculations*** in script have a limited number size. Positive numbers are limited to `(2^31)-1` = `2,147,483,647`. Therefore normal Bitcoin Cash contract scripts are limited to about `21` BCH, at today's prices, about $5,000 USD. However, due to the type of calculations required in AnyHedge contracts, the numbers are much larger than just Satoshi amounts. The result is that without using special techniques, contracts like AnyHedge are limited to very small BCH values. At today's prices, the limit is about $10 USD. In general programming, there are well established techniques to get around this type of limitation. Tobias Ruck adapted one of those techniques to create "Big Mul" , a type of synthetic multiplication. General Protocols may apply BigMul to AnyHedge in the future. https://gitlab.com/GeneralProtocols/research/-/blob/master/bigmul/bigmul.ipynb Currently AnyHedge uses another technique called truncation. Conceptually, it works like this: `48,000,000,000` is too big to fit in Bitcoin Script calculations. `480,000,000` is a very similar number and fits with no problem. There is a bit of math behind it, but let's just chop off those two zeroes `00` , do calculations and then glue the zeroes back on at the end. Here is an example: `48,000,000,000` / `600` = `80,000,000` but this cannot be calculated directly so... `480,000,000` / `600` = `800,000` and then glue on our remaining `00` --> `80,000,000` This example has perfect accuracy, but if we chop off anything but `00...`, it introduces some inaccuracy to the overall process. Karol's boundaries also take this issue into account so that the contract will have high accuracy AnyHedge API is coming AnyHedge is an accurate, low cost, peer to peer stability and speculation instrument that will work for any asset with an oracle price feed. We will release the public API soon and we look forward to seeing how everyone will use it. We would love to talk with you about AnyHedge, the whitepaper, the detailed execution or Karol's analysis. Please feel free to join us on the AnyHedge Telegram group. https://gitlab.com/GeneralProtocols/anyhedge/whitepaper/-/blob/master/anyhedge.md https://gitlab.com/GeneralProtocols/anyhedge/whitepaper/-/blob/master/anyhedge-supplement.md https://anyhedge.com/downloads/AnyHedge%20Numerical%20Analysis.pdf https://t.me/AnyHedge ****General Protocols Blog**** This article forms part of the **General Protocols Blog**, a collection of cross-platform links showcasing our team's community activity, Bitcoin Cash projects, UTXO development, and general crypto musings. https://blog.generalprotocols.com/

https://blog.generalprotocols.com