Numeric Outcome DLCs #110
Numeric Outcome DLCs #110
Conversation
nkohen
added
enhancement
NumericOutcome.md
Outdated
| Lastly, if both grouping optimizations can be made, `w = 0` and `W = B-1` then a **total optimization** can be made and the | ||
| whole range can be represented using only a single CET corresponding to `(prefix)____`. | ||
|
|
||
| ### Algorithms |
There was a problem hiding this comment.
The functions in these should probably be written in a more universal language like python or just psdueo code
There was a problem hiding this comment.
Curious to see what people who code in non-scala think about the readability, please leave comments here!
There was a problem hiding this comment.
I agree with @benthecarman. Tbh it's fine by me since I got a little bit used to read Scala by now, but it definitely adds to the complexity of something that is already not that easy. I think Python would probably be better. I'm not sure for pseudo code, personally I often find it harder to read than actual code. Also still good to link to your implementation.
There was a problem hiding this comment.
As C# guy I can understand the code, we have very similar constructs.
But I think if Scala is chosen, at the very least it should not use fancy constructions.
|
I must say I have a hard time understanding it from the Example part, but this is probably not your fault, I am bad at understanding when things are too abstract. I would suggest, instead of using abstraction, just assuming B=10 and take a real, concrete example of range. |
NumericOutcome.md
Outdated
| generated in both the front and back groupings of length at most `B-1 ` which corresponds to the coefficient in the order bound. | ||
| This counting shows us that base 2 is the optimal base to be using in general cases as it will outperform all larger bases | ||
| in both large and small ranges in general. | ||
|
|
There was a problem hiding this comment.
The number of CETs can be further reduced by selecting (B^ n-1) or (B ^ n) for start and end.
There was a problem hiding this comment.
So while this is true, I'm not sure that it is particularly practical?
There was a problem hiding this comment.
This idea is valid in both decimal and binary numbers, so I think it is practical. As a more practical description, it may be better to add the description like below to the #optimizations chapter.
Choosing a value closer to (B ^ n) for start and end will reduce the number of CETs.
Great idea, I've added a concrete example before the general abstract one |
NumericOutcome.md
Outdated
| When an outcome can be any of a large range of numbers, then using a simple enumeration of | ||
| all possible numbers in this range is unwieldy. | ||
| We optimize by using numeric decomposition in which the oracle signs each digit of the outcome | ||
| individually so that many possible outcomes can be compressed into a single CET by ignoring certain signatures. | ||
| There will be as many nonces as there are possible digits required and CETs are claimed using | ||
| some number of these signatures, not necessarily all of them. | ||
| If not all signatures are used, then this CET corresponds to all events which agree on the digits for which | ||
| signatures are used and may have any value at all other digits for which signatures are ignored. |
There was a problem hiding this comment.
IMHO this paragraph is very hard to read and the concept is already explained in the oracle spec that is under PR (and for which @Christewart is even adding more detailed example), so I would just remove that and reference the oracle spec.
There was a problem hiding this comment.
To be completely honest I think that it doesn't make much sense for these kinds of concerns to be included in the oracle spec for anything other than motivation whereas here they are necessary so I think it should be the other way around.
That said, I am more than happy to re-do the paragraph to make it more readable!
NumericOutcome.md
Outdated
| Lastly, if both grouping optimizations can be made, `w = 0` and `W = B-1` then a **total optimization** can be made and the | ||
| whole range can be represented using only a single CET corresponding to `(prefix)____`. | ||
|
|
||
| ### Algorithms |
There was a problem hiding this comment.
I agree with @benthecarman. Tbh it's fine by me since I got a little bit used to read Scala by now, but it definitely adds to the complexity of something that is already not that easy. I think Python would probably be better. I'm not sure for pseudo code, personally I often find it harder to read than actual code. Also still good to link to your implementation.
NumericOutcome.md
Outdated
| } | ||
| ``` | ||
|
|
||
| ## General Payout Curves |
There was a problem hiding this comment.
If you want to have something merge in the not so distant future, I would take that in a different PR. It's going to be difficult to give you feedback on that without actually trying to implement it myself I feel.
|
Removed my comments. |
Just pushed an attempt to make the optimizations more clear. |
|
Ugh, and as I did that I realized that there are actually some optimizations I missed and that all of the optimizations including the ones I've missed can be stated cleverly as a single optimization, I will be pushing this change up shortly |
NumericOutcome.md
Outdated
| Note that this `payout_function` is from the offerer's point of view. | ||
| To evaluate the accepter's `payout_function`, you must evaluate the offerer's `payout_function` at a given | ||
| `event_outcome` and subtract the resulting payout from `total_collateral`. | ||
| It is important that you do NOT construct the accepter's `payout_function` by replacing all `outcome_payout`s in the |
There was a problem hiding this comment.
It's probably worth bolding this text and maybe making it it's own paragraph.
…ial evaluation optimizations when precision is not 1
| This is accomplished through the use of digit decomposition where oracles attesting to | ||
| numeric outcomes sign each digit of the outcome individually. | ||
| There are as many nonces as there are possible digits required and CETs are claimed using | ||
| only some of these signatures, not necessarily all of them. |
There was a problem hiding this comment.
Maybe mention primairly using base 2 here
There was a problem hiding this comment.
I'm not sure this is the best place for this
|
|
||
| We will first need a function to decompose any number into its digits in a given base. | ||
|
|
||
| ```scala |
There was a problem hiding this comment.
These still should be written in something like python
This introduces a new document which specifies how to construct and execute DLCs based on (multi-nonce) numeric outcomes.
This includes CET compression optimizations as well as an implementation of general payout curve support, which are combined to describe a (nearly) deterministic CET computation algorithm which is approximately minimal. (I am open to splitting this up into many files if people want).
Remaining TODOs:
And lastly I intend to create test vectors as I have almost all of this implemented in a branch on bitcoin-s but these tests shouldn't block this PR being discussed and merged as they will be added in a subsequent PR.
Fixes #65