AnyHedge - safe boundaries for contracts

21 575
Avatar for GeneralProtocols
3 years ago (Last updated: 2 years ago)

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.

31
$ 9.20
$ 5.00 from @MarcDeMesel
$ 2.00 from @molecular
$ 1.00 from @BitcoinOutLoud
+ 7
Avatar for GeneralProtocols
3 years ago (Last updated: 2 years ago)

Comments

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

$ 0.00
3 years ago

Good work bro.. it's informative.. keep writing more interesting article likenthis

$ 0.00
3 years ago

Thanks for this information. Good to see attention is being paid to "little details" like this that could have tremendous impact of over looked.

$ 0.00
3 years ago

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

$ 0.00
3 years ago

Thanks for sharing this information.

$ 0.00
3 years ago

Thanks for this sharing information.

$ 0.00
3 years ago

Nice workdone... Bravo

$ 0.00
3 years ago

çok ayrıntılara takılıp kalmanın anlamı yok bence bazen ayrıntılar can sıkar

$ 0.00
3 years ago

Thanks for the information Nice

$ 0.00
3 years ago

Excellent article. Thanks for sharing this article.

$ 0.00
3 years ago

Great article 👍

$ 0.00
3 years ago

That is Great Article for me!

$ 0.00
3 years ago

Very complicated not easy to understand though but will go over again. I don't love calculations at all by will try my best to go over again

$ 0.00
3 years ago

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.

$ 0.00
3 years ago

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

$ 0.00
3 years ago

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.

$ 0.00
3 years ago

OK thanks for the explanation

$ 0.00
3 years ago

Good working brother.i really appreciated for your great effort.keep doing it.good to see attention is being paid to"little details"like this.

$ 0.00
3 years ago

good to see attention is being paid to "little details" like this that could have tremendous impact of overlooked

$ 0.20
3 years ago

good to see attention is being paid to "little details"

the attention to detail definitely shows to the caliber of this team

$ 0.00
3 years ago

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!!
❤️👏👍🤩

$ 0.10
3 years ago