read.cash is a platform where you could earn money (total earned by users so far: $ 826,779.09).
You could get tips for writing articles and comments, which are paid in Bitcoin Cash (BCH) cryptocurrency,
which can be spent on the Internet or converted to your local money.

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.

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.

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.

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" 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.

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.

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 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.

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.

ومع ذلك ، نظرًا لنوع العمليات الحسابية المطلوبة في عقود AnyHedge ، فإن الأرقام أكبر بكثير من مجرد مبالغ Satoshi. والنتيجة هي أنه بدون استخدام تقنيات خاصة ، فإن العقود مثل AnyH مقالة رائعة😊

first off, Karol's math really made my head hurt, which I didn't appreciate 😣 .. but then you broke it down into layman's and it totally made sense, which I must say seemed impossible given my aching head.. this is all really very fascinating stuff, including Tobias' "BigMul", which thankfully wasn't painful to get a basic understanding..

You are right that the paper is not easy to digest. Let me know if you have any specific questions. You can join us on the telegram channel too if you want to ask there.

I will but how did you come out with this calculations cause I don't like calculations at all but I will read over and get back to you. By the way thanks for the article

These calculations were created to model the reality of how the contract works. Then they were used to explore what kind of inputs are safe. The contract was designed over time based on experience and basic mathematical modeling.

first off, Karol's math really made my head hurt, which I didn't appreciate 😣 .. but then you broke it down into layman's and it totally made sense, which I must say seemed impossible given my aching head.. this is all really very fascinating stuff, including Tobias' "BigMul", which thankfully wasn't painful to get a basic understanding..

I'm overly impressed with what y'all doin up in GenProto!!
❤️👏👍🤩

ومع ذلك ، نظرًا لنوع العمليات الحسابية المطلوبة في عقود AnyHedge ، فإن الأرقام أكبر بكثير من مجرد مبالغ Satoshi. والنتيجة هي أنه بدون استخدام تقنيات خاصة ، فإن العقود مثل AnyH مقالة رائعة😊