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.

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.

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.

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.

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.