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.
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_valueis in arbitrary units. Let's say US cents.
start_priceuses 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
3. Numbers with decimal points like
1.2 are not integers. Bitcoin Cash script works with integers and has no native concept of decimal points.
Integer calculations works well for:
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:
But here is where the problems appear:
666.66...? Not in script. The result is
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.
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,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,000is too big to fit in Bitcoin Script calculations.
480,000,000is 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:
80,000,000but this cannot be calculated directly so...
800,000and then glue on our remaining
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.
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.