GlcoinCore/pool
1
0
Fork 0
mirror of https://github.com/lightninglabs/pool.git synced 2026-08-16 13:00:39 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

paper: edits for section 6-7.1.1

Browse source
This commit is contained in:
Oliver Gugger 2020-10-29 11:27:08 +01:00 • committed by Olaoluwa Osuntokun
parent dd762a2841
commit 923f13be08
1 changed files with 19 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

46
docs/paper/liquidity.tex
View file

@ -1663,11 +1663,13 @@ extend the main chain where:
\item $B_S = (T_{xn}, \{\phi_{U_0}, \cdots, \phi_{U_N}\}, \Delta_{f},
\{\phi_{U_0}^\prime, \cdots, \phi_{U_N}^\prime\}, U_{A})$, is the
shadowchain block itself, which is composed of the application-specific
transaction format, input Lifted UTXOs, the resulting output UTXOs
after applying the set of state transition functions, and $U_{A}$ any
new application-specific UTXOs produced as a result of the state
transition function.
shadowchain block itself, which is composed of the set of application
transaction, input Lifted UTXOs, the resulting output UTXOs after
applying the set of state transition functions, and $U_{A}$ any new
application-specific UTXOs produced as a result of the state transition
function. Lifted UTXOs can be consumed fully by the state transitions,
therefore |\{\phi_{U_0}, \cdots, \phi_{U_N}\}| \geq
|\{\phi_{U_0}^\prime, \cdots, \phi_{U_N}^\prime\}| must be given.
\end{itemize}
Once a block has been constructed, the operator of the shadowchain now must
@ -1689,7 +1691,7 @@ we can now proceed to the execution and block commitment phase.
\textbf{Chain Execution}
\end{center}
Once the operator has esatblished a stable set of participants which accept the
Once the operator has established a stable set of participants which accept the
proposed shadowchain block, it can execute the block and commit it in the base
Bitcoin blockchain: \\
@ -1804,11 +1806,6 @@ block before finally attempting to commit the new block within the chain.
\t \t if b==1 \\
\t \t \t (b^\prime, TX_{id}) \gets \texttt{CommitBlock($B_{S}$)} \\
}
\procedure [linenumbering, mode=text ]{ Oracle $O$}{
some code \\
more code
}
\end{pchstack}
@ -1834,11 +1831,6 @@ new block proposal by the orchestrator.
\t\t if b^\prime == 1 \\
\t\t \t \texttt{localCommitBlock()}
}
\procedure [linenumbering, mode=text ]{ Oracle $O$}{
some code \\
more code
}
\end{pchstack}
% lift utxo if non empty
@ -1853,8 +1845,8 @@ new block proposal by the orchestrator.
In this section, we build upon the prior sections outlining the abstract
\texttt{Channel Lease Marketplace} definition, as well as shadowchain
operation, and construct out \textbf{Lightning Pool} implementation at a
low-level. We first being by detailing our implementation of the \texttt{CLM}
operation, and construct our \textbf{Lightning Pool} implementation at a
low-level. We first begin by detailing our implementation of the \texttt{CLM}
algorithms, as well as our choice of certain free parameters. With this
concrete structure in place, we'll then go up a layer of abstraction to
demonstrate how Lightning Pool can be operated as a shadowchain on Bitcoin
@ -1869,13 +1861,13 @@ today, without any further modifications enhancements.
\end{center}
Before an instance of Lightning Pool can be used by willing agents, the system
must first be initialized. This operation can be performed only by by the
Orchestrator of the auctioneer. Within the system, we'll utilize incremented
must first be initialized. This operation can be performed only by the
Orchestrator of the auctioneer. Within the system, we'll utilize an incremented
Elliptic Curve point which we refer to as the \texttt{batchID} for several
operations. The \texttt{batchID} serves to uniquely identified a given batch,
and is incremented after each successful batch. \\
The \texttt{batchID} itself is a nothing up my sleeve (NUMs) point which has
The \texttt{batchID} itself is a nothing up my sleeve (NUMS) point which has
been generated in a manner that no one, not even the auctioneer knows the
discrete log to. The raw serialized \texttt{batchID} (for the very first batch)
within the \textbf{Lightning Pool} system can be expressed in the following
@ -1923,12 +1915,12 @@ all account scripts within the system, as well as the auctioneer's main
account. \\
First, we define a helper function for deriving the auctioneer's current key
parameterized by the current \texttt{batchID}. As noted above, the
\texttt{batchID} serves as both a public key within the system as well as a
counter. The \texttt{batchID} may be expressed as a normal compressed public
key, or as an integer $N_{b}$ which denotes the scalar multiple off-set from
the starting batch key $B_{k_0}$: $[B_{k_0}]N_{b}$. We define the
\texttt{auctioneerScript} as follows:
A_{pk_i} from the static auctioneer account key A_{pk} parameterized by the
current \texttt{batchID}. As noted above, the \texttt{batchID} serves as both a
public key within the system as well as a counter. The \texttt{batchID} may be
expressed as a normal compressed public key, or as an integer $N_{b}$ which
denotes the scalar multiple off-set from the starting batch key $B_{k_0}$:
$[B_{k_0}]N_{b}$. We define the \texttt{auctioneerScript} as follows:
\begin{pcvstack}[boxed,center, space=1em]
\procedure[linenumbering, syntaxhighlight=auto]{\texttt{auctioneerScript($A_{pk}, B_{k_i}$)}}{