Non-integer spec and multi-sig edits #837
Conversation
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Outdated
Show resolved
Hide resolved
| exact way using rational numbers and arbitrary precision integers which are | ||
| available in most programming languages or via external libraries.~\footnote{The | ||
| The Shelley ledger specification~\cite{shelley_spec}\khcomment{I'd prefer a reference format that was shorter e.g. [G\"ud19], and made it clearer what were internal, public, published etc. documents} and the Ouroboros | ||
| protocol~\cite{ouroboros} use non-integral calculations in a few places. Most of these can be |
There was a problem hiding this comment.
could that be achieved by changing the bibstyle and resorting to a standardized way to format bibentries ?
There was a problem hiding this comment.
Yes, I think so. Best with the alpha or similar style. Custom labels are probably the easy way. They could conceivably be auto-generated (e.g. on a per-biblio basis), but this might need some bibstyle hacking. http://www.math.cmu.edu/~gautam/sj/blog/20171208-bibtex-custom-label.html
There was a problem hiding this comment.
I'd also suggested cross-referencing to @polinavino, where we are e.g. referring to a section/subsection of a document. Easier for the reader, but needs to be kept in sync (maybe using imported LaTeX refs using toc entries - I've done this before on a complex document).
There was a problem hiding this comment.
I've applied a suggested format. Needs @kantp to agree on it or something else.
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Outdated
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Outdated
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Outdated
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Show resolved
Hide resolved
shelley/chain-and-ledger/dependencies/non-integer/doc/non-integer-calculations.tex
Outdated
Show resolved
Hide resolved
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
kevinhammond
changed the title
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
…ledger-specs into khedits Some git wierdness...
…ledger-specs into khedits Some git wierdness...
…ledger-specs into khedits Some github strangeness.
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
Signed-off-by: Kevin Hammond <12563287+kevinhammond@users.noreply.github.com>
| and~\ref{sec:native-script-interp} for details. | ||
| sub-types $\AddrVKey$ and $\AddrScr$. Key addresses, of type $\AddrVKey$, are | ||
| used as in the original specification; script addresses contain the hash\khcomment{Is this enough - two scripts could conceivably have the same hash, couldn't they?} | ||
| of the validator script, and are used to lookup the script. |
There was a problem hiding this comment.
yes, just like hash keys
There was a problem hiding this comment.
If you're using a hash, then equivalent hashes do not mean equivalent scripts (unless you have a unique hash [which I would consider a signature]). For the keys you presumably accept a low probability of clashing. Here you accept some possibility of incorrect validation (which could perhaps cause a runtime error).
| (Figure~\ref{fig:types-scripts}) sub-type of $\Addr$ carries the necessary | ||
| information and can therefore be part of a transaction output that consists of a | ||
| corresponding validator script. The output can only be spent if the matching script is | ||
| provided\khcomment{?} and validates its input. The necessary information is carried by the |
There was a problem hiding this comment.
what is the question here? Effectively, if an output requires a script, then one has to provide a script that hashes to the value in the address and validates the input it receives (in the case of MSig the set of signatures)
There was a problem hiding this comment.
Is the word "provided" correct
| of a script address. The domain of the accessor function $\fun{paymentHK}$ is | ||
| changed to pubkey addresses. The domains of the accessor functions | ||
| changed to public key\khcomment{?} addresses. The domains of the accessor functions |
There was a problem hiding this comment.
the return value of paymentHK is the key hash, so we either need to restrict the function domain or make the codomain an option type
There was a problem hiding this comment.
The question was whether pubkey should expand to "public key"
| as defined in the formal ledger specification~\cite{shelley_spec} to carry an additional witness | ||
| type. This is achieved by explicitly defining $\TxWitness$ to be | ||
| a pair of a public key witness and a script witness.\khcomment{I don't understand the difference between a tuple and a $\times$ type.} | ||
| The accessor function |
There was a problem hiding this comment.
this is meant to be a product type. Should we make this TxWitness = VKey |-> Sig x ScriptHash |-> Script ?
There was a problem hiding this comment.
Something to check notationally across all the docs
| \begin{enumerate} | ||
| \item equality of the hashed script with the hash that is stored in the output to spent; | ||
| \item that the script validates the transaction; and | ||
| \item that it is precisely\khcomment{or includes? - made a change in the figure} the set of the scripts required for the transaction (as |
There was a problem hiding this comment.
here we do not allow more script witnesses than necessary.
There was a problem hiding this comment.
Is that part of the design?
| Figure~\ref{fig:functions-witnesses}. Figure~\ref{fig:functions-witnesses} also shows the function | ||
| $\fun{scriptNeeded}$ that computes the required script hashes from the set of | ||
| spent inputs that are locked by scripts and the consumed withdrawals that are locked by scripts. | ||
| \khcomment{witsVKeyNeeded is identical to the original, presumably?}\khcomment{Figure overflows to the left} |
| can be added to the transaction fees or as gas cost. The scripts can be realized | ||
| with only limited requirements on functionality on the script language. | ||
|
|
||
| can be added to the transaction fees or as gas cost. \khcomment{Assumes transactions are independent.} |
There was a problem hiding this comment.
I don't understand this. The creator of the transaction knows how many signatures are present and knows the script, which means that the creator can statically check for how long the script can run (actually for MSig, how many reduction steps are required for False / True). How is this influenced by other transactions ?
There was a problem hiding this comment.
If there was a dependency between transactions. It may be that by design this can't happen.
Remove todo notes where comment is taken care of.
This broke the `inference` rules rendering for whatever reason
for the discussion, see #837
| range of \emph{real numbers}. | ||
| These include the exponential function | ||
| $e^{x}, x \in \mathbb{R}$, which is used to calculate how refunds decay over time, and general non-integral exponentiation | ||
| $x^{y}, x, y \in \mathbb{R}$, which is used to \khcomment{MG, please fix!}. |
There was a problem hiding this comment.
@kevinhammond what is here to fix ? In a commit, you removed " ... calculate how refunds decay over time, and general non-integral exponentiation" why ?
There was a problem hiding this comment.
To make it clear to the reader why these are needed.
There was a problem hiding this comment.
You can expand if you think this is needed.
|
|
||
| There exist two main approaches for approximation: Taylor / MacLaurin series and | ||
| Other than basic arithmetic (addition, multiplication, subtraction, and division\khcomment{check for uses of division in the algorithms -- I spotted some | ||
| uses, but it might be possible to remove them using e.g. rotation/scaling.}), |
There was a problem hiding this comment.
any further ideas here? I think the divisions we are talking about here are mostly tied to the rewards scheme and more or less fixed in the design spec. So we would need equivalent calculations with fewer divisions ?
There was a problem hiding this comment.
We should discuss this. If division is not needed, then this can either make things more efficient, or sometimes simplify proof/error checks (by avoiding divide-by-zero, for example). But I'd be inclined to think we've done enough for now in terms of optimisation.
| convergence speed, in particular for the natural logarithm. | ||
| Our experimental results have shown that continued fractions converge faster, in particular for the natural logarithm. | ||
|
|
||
| \khcomment{Give captions for the plots. Combine the plots from Figs. 1 and 2 into a single figure (one above the other?). Do the same for Figs. 3 and 4.} |
There was a problem hiding this comment.
The problem with this is that the vastly different y-axis will make one almost invisible, visually close to indistinguishable from the x-axis
There was a problem hiding this comment.
I meant one figure, with two plots... Keep the actual plots as-is :)
subfigure sometimes works for this, but you may not need that.
for discussion, see #837
for the discussion, see #837
Suggested changes to the non-integer spec document.