You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

2165 lines
43 KiB

#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\begin_preamble
% for subfigures/subtables
\usepackage[caption=false,font=footnotesize]{subfig}
\end_preamble
\options journal
\use_default_options false
\maintain_unincluded_children false
\language english
\language_package none
\inputencoding default
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command bibtex
\index_command default
\float_placement H
\paperfontsize default
\spacing single
\use_hyperref true
\pdf_title "Your Title"
\pdf_author "Your Name"
\pdf_bookmarks true
\pdf_bookmarksnumbered true
\pdf_bookmarksopen true
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder true
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle false
\pdf_quoted_options "pdfpagelayout=OneColumn, pdfnewwindow=true, pdfstartview=XYZ, plainpages=false"
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 0
\use_package esint 0
\use_package mathdots 1
\use_package mathtools 0
\use_package mhchem 1
\use_package stackrel 0
\use_package stmaryrd 0
\use_package undertilde 0
\cite_engine basic
\cite_engine_type default
\biblio_style ieeetr
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 0
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header
\begin_body
\begin_layout Title
Reaching The Ground With Lightning (draft 0.2)
\end_layout
\begin_layout Author
Rusty Russell <rusty@blockstream.com>
\end_layout
\begin_layout Abstract
The Lightning Network (as proposed by Joseph Poon and Thaddeus Dryja
\begin_inset CommandInset citation
LatexCommand cite
key "Poon2015Lightning"
\end_inset
) requires some new sighash modes in order to work with Bitcoin.
This paper proposes a simplified variant which requires only modifications
which are already proposed for bitcoin, and slightly simplifies the revocation
of existing contracts.
\end_layout
\begin_layout Abstract
Keywords: bitcoin, lightning, revocation hash, HTLC, BIP62, BIP65, BIP68
\end_layout
\begin_layout Section
Introduction
\end_layout
\begin_layout Standard
The Bitcoin network
\begin_inset CommandInset citation
LatexCommand cite
key "nakamoto2008bitcoin"
\end_inset
allows the transfer of value between peers using
\emph on
transactions.
\emph default
Each bitcoin transaction consists of one or more
\emph on
outputs
\emph default
(typically specifying the hash of the recipient's key), and one or more
\emph on
inputs
\emph default
(typically containing the recipient's key and a signature of the transaction).
Thus one transfers value to another peer by creating a transaction which
\emph on
spends
\emph default
9 years ago
one or more outputs and creates an output which the recipient can spend
using their private key.
\end_layout
\begin_layout Standard
While such cryptographic transfer of value is near-instantaneous, ensuring
that the transaction has been included in the consensus of the shared ledger
(aka.
\emph on
blockchain
\emph default
) creates delays ranging from a few minutes to hours, depending on the level
of reliability required.
Inclusion in the blockchain is performed by miners, who preferentially
include transactions paying greatest fee per byte.
\end_layout
\begin_layout Standard
Thus using the blockchain directly is slow, and too expensive for genuinely
small transfers (typical fees are a few cents).
\end_layout
\begin_layout Section
Previous Work
\end_layout
\begin_layout Standard
To work around the bitcoin network's delays and fees, several forms of
\emph on
off-chain
\emph default
transaction patterns have been developed, where series of transactions
are sent directly between two parties, with only the initial opening transactio
n and final redemption transaction being included in the bitcoin blockchain.
\end_layout
\begin_layout Standard
The Lightning Network paper proposed a solution, but at the cost of introducing
new signature variants (sighash ops).
Adding a new signature opcode would allow many other improvements
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Schnorr signatures offer faster batch validation, according to https://github.com
/ElementsProject/elementsproject.github.io#schnorr-signature-validation
\end_layout
\end_inset
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
DER encoding adds unnecessary bytes and is a cause of malleability
\end_layout
\end_inset
but that is precisely why it's a matter for longer term research and unlikely
to be deployed in Bitcoin in the immediate future.
\end_layout
\begin_layout Subsection
Payment Channels
\end_layout
\begin_layout Standard
The concept of
\emph on
payment channels
\emph default
(sometimes called micropayment channels) has existed in various forms for
several years
\begin_inset CommandInset citation
LatexCommand cite
key "BitcoinChannels"
\end_inset
.
The simplest form is as follows, and allows A to quickly and cheaply pay
B a stream of slightly increasing amounts:
\end_layout
\begin_layout Enumerate
A creates an
\emph on
anchor
\emph default
transaction to
\emph on
open the channel
\emph default
which:
\end_layout
\begin_deeper
\begin_layout Enumerate
Outputs $1,
\end_layout
\begin_layout Enumerate
Requires the signatures of both A and B to redeem.
\end_layout
\end_deeper
\begin_layout Enumerate
A sends the transaction ID of the anchor, which output to spend, and the
amount of that output to B.
\end_layout
\begin_layout Enumerate
B signs a
\begin_inset Quotes eld
\end_inset
refund
\begin_inset Quotes erd
\end_inset
transaction which:
\end_layout
\begin_deeper
\begin_layout Enumerate
spends that anchor output,
\end_layout
\begin_layout Enumerate
outputs the $1 to an address controlled by A, and
\end_layout
\begin_layout Enumerate
can only be spent in 24 hours (using the
\emph on
locktime
\emph default
field)
\end_layout
\end_deeper
\begin_layout Enumerate
B sends A the refund transaction.
\end_layout
\begin_layout Enumerate
A broadcasts the anchor transaction, knowing she can get the funds back
in 24 hours using the refund if B vanishes.
\end_layout
\begin_layout Standard
A can now pay B 1 cent by signing a new
\emph on
commitment
\emph default
transaction to send to B, which spends the anchor output and has two outputs:
one pays A 99c, and the other pays B 1 cent.
A can later pay B another cent by signing another transaction (
\begin_inset Quotes eld
\end_inset
updating the commitment
\begin_inset Quotes erd
\end_inset
) for B which pays A 98c and B 2c, etc.
\end_layout
\begin_layout Standard
At any point, B can
\begin_inset Quotes eld
\end_inset
close the channel
\begin_inset Quotes erd
\end_inset
by signing and broadcasting the latest commitment transaction to collect
the money.
B should do this before 24 hours pass, otherwise A can use the refund transacti
on.
\end_layout
\begin_layout Subsubsection
Limitations Of Simple Payment Channels
\end_layout
\begin_layout Standard
Simple channels have several limitations:
\end_layout
\begin_layout Description
Single
\begin_inset space ~
\end_inset
recipient.
A new recipient requires a new channel, which must wait for consensus on
the anchor transaction.
\end_layout
\begin_layout Description
One
\begin_inset space ~
\end_inset
way.
They cannot be reversed: A can sign a transaction which pays B less money
than the last, but B could still broadcast the older transaction.
\end_layout
\begin_layout Description
Vulnerable
\begin_inset space ~
\end_inset
to
\begin_inset space ~
\end_inset
malleability.
The anchor transaction could be altered in several ways (without invaliding
it completely) before inclusion in the blockchain: this alters its transaction
id and thus makes the refund transaction unusable.
\end_layout
\begin_layout Standard
This last issue is a common one with complex bitcoin transactions, and BIP62
\begin_inset CommandInset citation
LatexCommand cite
key "BIP62"
\end_inset
is proposed to prevent non-signing parties from being able to malleate
transactions.
\end_layout
\begin_layout Subsection
Generalized Payment Channels Using Revocable Transactions
\end_layout
\begin_layout Standard
The Lightning network introduced generalized, bi-directional payment channels,
referred to here as
\emph on
Poon-Dryja channels
\emph default
.
These use a mutual anchor, which both create to provide the channel funding,
and a symmetrical
\emph on
pair
\emph default
of updatable commitment
\emph on
\emph default
transactions rather than the single transaction used in the one-way channel
case, as shown in figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Figure-1-from"
\end_inset
\begin_inset Foot
status collapsed
\begin_layout Plain Layout
Note: this diagram has been corrected since: Commitment Close Tx 1A (CC1b)
-- should be CC1a, and vice-versa
\end_layout
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename ln-draft-fig1.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Figure 1 from the Lightning Network Draft 0.5
\begin_inset CommandInset label
LatexCommand label
name "fig:Figure-1-from"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
To update the commitment, A sends B a signature for B's new commitment transacti
on, and B sends A a signature for A's new commitment transaction.
\end_layout
\begin_layout Standard
As before, each commitment transaction contains two outputs, one for A and
one for B; but A's commitment transaction output to itself is encumbered
by an additional restriction (as is B's output to itself).
Instead of paying A directly, A's output needs both A and B's signature.
B provides such a signature, but on a
\begin_inset Quotes eld
\end_inset
commitment refund
\begin_inset Quotes erd
\end_inset
transaction which can only be spent after a delay (40 days in the paper).
Thus if A closes the channel by signing and broadcasting its commitment
transaction, B can collect its output immediately, but A must wait 40 days.
\end_layout
\begin_layout Standard
This delay encumbering the output is what makes the commitment transaction
\emph on
revocable;
\emph default
once an updated commitment transaction is agreed upon, the previous commitment
transaction pair is revoked by sharing the private keys needed to redeem
those encumbered outputs.
Thus, A shares its (throwaway) private key, and B shares its throwaway
private key.
If A were to sign and broadcast a revoked commitment transaction, B could
not only immediately spend its own output, but it has both A's key and
its own to generate a transaction which can spend the output which would
normally go to A after a delay.
\end_layout
\begin_layout Subsection
Hashed Timelock Contracts (HTLCs)
\end_layout
\begin_layout Standard
The Lightning Network paper used a set of 4 transactions to implement a
\emph on
hashed timelock contract,
\emph default
which guarantees payment of a given amount on presentation of a secret value
\emph on
R
\emph default
within a certain timespan.
Any number of these could be active within a generalized channel, and this
is what allows a network to form: Node A offers node B $1 for the secret
within 2 days, node B offers node C 99c for the secret within 1 day, etc.
\end_layout
\begin_layout Standard
This arrangement for one side of a single node is shown in figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Figure-2-from"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename ln-draft-fig2.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Figure 2 from the Lightning Network Draft 0.5
\begin_inset CommandInset label
LatexCommand label
name "fig:Figure-2-from"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Section
Enhancements To Lightning
\end_layout
\begin_layout Standard
This paper proposes various modifications.
\end_layout
\begin_layout Subsection
Poon-Dryja Generalized Payment Channel Modifications
\end_layout
\begin_layout Standard
This paper proposes three changes to the commitment transactions.
\end_layout
\begin_layout Subsubsection
Placing Timeout in Output Script
\end_layout
\begin_layout Standard
Rather than using a separate transaction to enforce the delay, BIP65
\begin_inset CommandInset citation
LatexCommand cite
key "BIP65"
\end_inset
proposes an OP_CHECKLOCKTIMEVERIFY which allows an output to specify the
minimum time at which it can be spent.
With this enhancement, we no longer need a separate
\begin_inset Quotes eld
\end_inset
commitment refund
\begin_inset Quotes erd
\end_inset
transaction.
The commitment transaction to-self output script would be a little more
complex:
\end_layout
\begin_layout Itemize
A and B's signature, OR
\end_layout
\begin_layout Itemize
A's signature and OP_CHECKLOCKTIMEVERIFY <40 days>
\end_layout
\begin_layout Standard
As of Nov.
13, 2015, BIP65 has been deployed and is in the process of being activated.
\end_layout
\begin_layout Subsubsection
Using Relative Locktime
\end_layout
\begin_layout Standard
The Poon-Dryja channel uses a 40 day locktime, because transaction locktime
is absolute.
Before 40 days the channel must be closed, otherwise spending a revoked
transaction and immediately following it with the commit refund transaction
is possible.
\end_layout
\begin_layout Standard
BIP112[#BIP112] proposes OP_CHECKSEQUENCEVERIFY, an opcode which allows
an output to specify a minimum
\emph on
relative
\emph default
time before the output can be spent
\begin_inset CommandInset citation
LatexCommand cite
key "friedenbach_bitcoin-development_2015,BIP112"
\end_inset
can reduce this timeout (say, to 1 day) and avoid placing a lifetime limit
on the channel, like so:
\end_layout
\begin_layout Itemize
A and B's signature, OR
\end_layout
\begin_layout Itemize
A's signature and OP_CHECKSEQUENCEVERIFY <1 day>
\end_layout
\begin_layout Standard
As of Nov.
13, 2015, BIP112 has not been deployed.
\end_layout
\begin_layout Subsubsection
Using Revocation Preimages Instead of Private Keys
\end_layout
\begin_layout Standard
There's a slightly more intuitive and more efficient method than exchanging
private keys, which is to reuse a technique of hash preimages which is
already needed for HTLCs (as we see later).
\end_layout
\begin_layout Standard
Instead of using a private key, B uses knowledge of a hash preimage as well
as its signature to steal funds from a revoked commitment transaction.
Thus, to create a commitment transaction each side provides a hash value;
to revoke a commitment transaction it provides the prehash image.
\end_layout
\begin_layout Standard
The resulting commitment transaction to-self output now looks like:
\end_layout
\begin_layout Itemize
B's signature and a preimage which hashes to <revocation-hash>, OR
\end_layout
\begin_layout Itemize
A's signature and OP_CHECKSEQUENCEVERIFY <1 day>
\end_layout
\begin_layout Standard
This can be expressed fairly easily in bitcoin's script-based scripting
language, as annotated in
\begin_inset CommandInset ref
LatexCommand nameref
reference "sub:Commitment-Outputs-For"
\end_inset
.
The final pair of commitment transaction outputs is shown in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Commitment-Transaction-Outputs"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename commit-tx.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Commitment Transaction Outputs
\begin_inset CommandInset label
LatexCommand label
name "fig:Commitment-Transaction-Outputs"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Subsection
Channel Opening Modifications
\end_layout
\begin_layout Standard
The method of creating the first commitment transaction before signing the
anchor transaction (as proposed in the paper) presents two problems in
practice:
\end_layout
\begin_layout Enumerate
The anchor transaction id required for the commitment input will only be
known once the anchor is signed, and
\end_layout
\begin_layout Enumerate
The anchor transaction can be malleated by either party before entering
the blockchain, rendering the commitment input unusable.
\end_layout
\begin_layout Standard
The last of these is particularly pernicious, as BIP62 doesn't solve it:
signatories can always re-sign a transaction, hence altering its transaction
ID.
The paper proposes new SIGHASH flags which mitigate this problem, but we
are attempting to avoid that.
\end_layout
\begin_layout Standard
Our approach is to only have one-sided anchors.
These can be later balanced by the lightning network itself, or an atomic-swap
to an on-chain bitcoin transaction
\begin_inset CommandInset citation
LatexCommand cite
key "go1111111_single_anchor"
\end_inset
.
Any bitcoin transaction fees are initially funded by that anchor, but the
implementation splits fees where possible and never allows either side
to spend funds in the channel if they would no longer be able to pay their
share.
\end_layout
\begin_layout Subsection
Hashed Timelock Contract (HTLC) Modification
\end_layout
\begin_layout Standard
Using the same techniques used above, we can condense each HTLC into a single
output script on the commitment transaction.
This output is spendable under three conditions:
\end_layout
\begin_layout Enumerate
Recipient knows the R value (funds go to recipient), or
\end_layout
\begin_layout Enumerate
The HTLC has timed out (funds return to sender), or
\end_layout
\begin_layout Enumerate
9 years ago
The Commit transaction has been revoked (funds go to other side).
\end_layout
\begin_layout Standard
Unlike the original paper, we use revocation preimages instead of sharing
temporary private keys.
If we also use OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY it is
fairly simple to express these conditions in a single output script.
\end_layout
\begin_layout Standard
For each direction the HTLC could transfer funds, there are two scripts
required; one for A's commitment transaction and one for B's commitment
transaction.
It's also a requirement that the conditions which allow payment to oneself
be delayed, to give the other side an opportunity to take the funds in
case of revocation.
This is shown (omitting the HTLC to-self delays, which depend on the orientatio
n of payer/payee with respect to A and B) in figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:HTLC-Using-Revocation"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename htlc.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
HTLC Using Revocation Preimages, OP_CLTV and OP_CSV (simplified)
\begin_inset CommandInset label
LatexCommand label
name "fig:HTLC-Using-Revocation"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The scripts for this can be found in
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Appendix-A:-Scripts"
\end_inset
.
\end_layout
\begin_layout Section
Conclusions
\end_layout
\begin_layout Standard
Secret preimages can replace exposure of temporary private keys in the Lightning
Network constructs with no loss of generality, and a slight gain in simplicity.
\end_layout
\begin_layout Standard
The use of script conditionals to enforce timeouts instead of using separate
pre-signed transactions reduces an HTLC from a set of four dual-signed
transactions to a single (more complex) output script, and additionally
avoids any requirement for new CHECKSIG flags for HTLCs.
\end_layout
\begin_layout Standard
By using a rebalanced single anchor, channel establishment can also avoid
new CHECKSIG flags, though it loses the important ability to outsource
the enforcement of channel contract terms.
\end_layout
\begin_layout Section*
Acknowlegments
\end_layout
\begin_layout Standard
Thanks to mmeijeri on Reddit's r/Bitcoin for pointing out a flaw in escape
transactions reusing the same A and B keys as the commitment transaction
in
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Appendix-B:-Dual"
\end_inset
\begin_inset Foot
status open
\begin_layout Plain Layout
https://www.reddit.com/r/Bitcoin/comments/3dlxw4/reaching_the_ground_with_lightnin
g_lightning/ct80xpp
\end_layout
\end_inset
.
Thanks to John Newbery for multiple formatting and typing corrections.
\end_layout
\begin_layout Standard
Thanks to Joseph Poon for designing the escape/fast-escape dual-anchor method,
as well as finding a flaw in my original formulation of the dual anchor
construct and reviewing an earlier draft of this paper.
Also thanks to him and Thaddeus Dryja for the initial eye-opening Lightning
Network paper.
\end_layout
\begin_layout Standard
\begin_inset CommandInset bibtex
LatexCommand bibtex
bibfiles "bitcoin"
options "bibtotoc,plain"
\end_inset
\end_layout
\begin_layout Section*
Appendix A: Transaction Scripts
\begin_inset CommandInset label
LatexCommand label
name "sec:Appendix-A:-Scripts"
\end_inset
\end_layout
\begin_layout Standard
All outputs are expressed as pay-to-scripthash outputs, where the redeeming
input provides the redeemscript.
Where a redeem-hash value is optional, it is generally supplied: for example,
if we want to pay to A if a preimage is supplied and B if no preimage is
supplied, we expect the input scriptsig to provide two arguments in both
cases (generally a zero in the second case).
This saves an extra test (of form
\begin_inset Quotes eld
\end_inset
OP_DEPTH <N> OP_EQUAL
\begin_inset Quotes erd
\end_inset
), at cost of a single byte in the input script.
\end_layout
\begin_layout Subsection*
Anchor Transaction
\end_layout
\begin_layout Standard
The anchor inputs are whatever the node chooses.
\end_layout
\begin_layout Subsubsection*
Anchor Output Redeemscript
\end_layout
\begin_layout Standard
The anchor output is a pay to script hash, with a redeemscript as follows:
\end_layout
\begin_layout Description
OP_HASH
\begin_inset space ~
\end_inset
<SECRET-A-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL If the secret is supplied,
\end_layout
\begin_layout Description
OP_IF
\end_layout
\begin_deeper
\begin_layout Description
<KEY-B'> Should be signed by B's escape key.
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE
\end_layout
\begin_deeper
\begin_layout Description
<KEY-B> Should be signed by B's commitment key.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
2
\begin_inset space ~
\end_inset
OP_SWAP Put 2 before B's key on the stack.
\end_layout
\begin_layout Description
<KEY-A>
\begin_inset space ~
\end_inset
2
\begin_inset space ~
\end_inset
OP_CHECKMULTISIG Make sure A and B have signed.
\end_layout
\begin_layout Subsection*
Commitment Transactions For Generalized Channels
\begin_inset CommandInset label
LatexCommand label
name "sub:Commitment-Outputs-For"
\end_inset
\end_layout
\begin_layout Standard
These examples are for A's Commitment Transaction; switch A and B to get
B's commitment transaction.
\end_layout
\begin_layout Subsubsection*
Commitment Input Script
\end_layout
\begin_layout Standard
The commitment transaction has two inputs; one which spends each anchor
output.
The zero after the signature indicates it is not revealing the secret:
\end_layout
\begin_layout Description
0
\begin_inset space ~
\end_inset
<SIG-B>
\begin_inset space ~
\end_inset
<SIG-A>
\begin_inset space ~
\end_inset
0
\begin_inset space ~
\end_inset
{<ANCHOR-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsubsection*
Commitment Transaction Output Redeemscripts
\end_layout
\begin_layout Standard
One output pays B's funds to B as normal (eg.
pay to scripthash
\begin_inset Quotes eld
\end_inset
<KEY-B> OP_CHECKSIG
\begin_inset Quotes erd
\end_inset
).
The other output pays A's funds: either to B if they supply the revocation
preimage, or to A after a delay.
This is the redeemscript:
\end_layout
\begin_layout Description
OP_HASH160
\begin_inset space ~
\end_inset
<COMMIT-REVOCATION-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL Did they supply revocation preimage?
\end_layout
\begin_layout Description
OP_IF
\end_layout
\begin_deeper
\begin_layout Description
<B-KEY> To B.
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE
\end_layout
\begin_deeper
\begin_layout Description
<LOCKTIME>
\begin_inset space ~
\end_inset
OP_CHECKSEQUENCEVERIFY
\begin_inset space ~
\end_inset
OP_DROP Spending transaction must be after timeout
\end_layout
\begin_layout Description
<A-KEY> To A.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
OP_CHECKSIG Signature must be correct.
\end_layout
\begin_layout Subsubsection*
Spending Commitment Output
\end_layout
\begin_layout Standard
Either B using a revocation preimage:
\end_layout
\begin_layout Description
<SIG-B>
\begin_inset space ~
\end_inset
<COMMIT-REVOCATION-IMAGE-A>
\begin_inset space ~
\end_inset
{<COMMITMENT-REDEEMSCRIPT>}
\end_layout
\begin_layout Standard
Or A using after a timeout:
\end_layout
\begin_layout Description
<SIG-A>
\begin_inset space ~
\end_inset
0
\begin_inset space ~
\end_inset
{<COMMITMENT-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsection*
Hash Locked Transaction Commitments
\end_layout
\begin_layout Standard
There are two styles of commitment transaction outputs for HTLCs: a
\begin_inset Quotes eld
\end_inset
sender
\begin_inset Quotes erd
\end_inset
and
\begin_inset Quotes eld
\end_inset
receiver
\begin_inset Quotes erd
\end_inset
case.
The output is a pay-to-script-hash, so the redeemscripts are shown below.
\end_layout
\begin_layout Standard
These scripts show A as the sender, and B as the receiver: exchange A and
B for the reverse.
\end_layout
\begin_layout Subsubsection*
HTLC Sender Redeemscript
\end_layout
\begin_layout Description
OP_HASH160
\begin_inset space ~
\end_inset
OP_DUP Replace top element with two copies of its hash
\end_layout
\begin_layout Description
<R-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL Test if they supplied the HTLC R value
\end_layout
\begin_layout Description
OP_SWAP
\begin_inset space ~
\end_inset
<COMMIT-REVOCATION-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL
\begin_inset space ~
\end_inset
OP_ADD Or the commitment revocation hash
\end_layout
\begin_layout Description
OP_IF If any hash matched.
\end_layout
\begin_deeper
\begin_layout Description
<KEY-B> Pay to B.
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE Must be A, after HTLC has timed out.
\end_layout
\begin_deeper
\begin_layout Description
<HTLC-TIMEOUT>
\begin_inset space ~
\end_inset
OP_CHECKLOCKTIMEVERIFY Ensure (absolute) time has passed.
\end_layout
\begin_layout Description
<DELAY>
\begin_inset space ~
\end_inset
OP_CHECKSEQUENCEVERIFY Delay gives B enough time to use revocation if it
has it.
\end_layout
\begin_layout Description
OP_2DROP Drop the delay and htlc-timeout from the stack.
\end_layout
\begin_layout Description
<KEY-A> Pay to A.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
OP_CHECKSIG Verify A or B's signature is correct.
\end_layout
\begin_layout Subsubsection*
HTLC Receiver Redeemscript
\end_layout
\begin_layout Description
OP_HASH160
\begin_inset space ~
\end_inset
OP_DUP Replace top element with two copies of its hash
\end_layout
\begin_layout Description
<R-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL B redeeming the contract, using R preimage?
\end_layout
\begin_layout Description
OP_IF
\end_layout
\begin_deeper
\begin_layout Description
<DELAY>
\begin_inset space ~
\end_inset
OP_CHECKSEQUENCEVERIFY Delay gives A enough time to use revocation if it
has it.
\end_layout
\begin_layout Description
OP_2DROP Drop extra hash and delay from the stack
\end_layout
\begin_layout Description
<KEY-B> Pay to B
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE
\end_layout
\begin_deeper
\begin_layout Description
<COMMIT-REVOCATION-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL If the commit has been revoked.
\end_layout
\begin_layout Description
OP_NOTIF If not, you need to wait for timeout.
\end_layout
\begin_deeper
\begin_layout Description
<HTLC-TIMEOUT>
\begin_inset space ~
\end_inset
OP_CHECKLOCKTIMEVERIFY
\begin_inset space ~
\end_inset
OP_DROP Ensure (absolute) time has passed.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
<KEY-A> Pay to A
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
OP_CHECKSIG Verify A or B's signature is correct.
\end_layout
\begin_layout Subsubsection*
Redeeming A HTLC Output
\end_layout
\begin_layout Standard
To redeem an HTLC, the recipient one provides the preimage R, and their
signature.
In our example above, B can redeem the HTLC:
\end_layout
\begin_layout Description
<SIG-B>
\begin_inset space ~
\end_inset
<HTLC-R-VALUE>
\begin_inset space ~
\end_inset
{<HTLC-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsubsection*
Claiming a Timed-out HTLC
\end_layout
\begin_layout Standard
To claim a timed-out HTLC, the sender supplies a zero value (which is nice
and short, but fails to hash to any of the revocation hashes), and their
signature.
In our example above, A can claim the timed-out HTLC:
\end_layout
\begin_layout Description
<SIG-A>
\begin_inset space ~
\end_inset
0
\begin_inset space ~
\end_inset
{<HTLC-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsubsection*
Claiming A HTLC Output For A Revoked Commitment Transaction
\end_layout
\begin_layout Standard
If either side publishes a commitment transaction which has been revoked,
we can use the revocation preimage they supplied to spend all the outputs.
This example shows A claiming the HTLC output if B broadcasts a revoked
commitment transaction:
\end_layout
\begin_layout Description
<SIG-A>
\begin_inset space ~
\end_inset
<COMMIT-REVOCATION>
\begin_inset space ~
\end_inset
{<HTLC-REDEEMSCRIPT>}
\end_layout
\begin_layout Section*
Appendix B: Dual Anchors With Escape Transactions
\begin_inset CommandInset label
LatexCommand label
name "sec:Appendix-B:-Dual"
\end_inset
\end_layout
\begin_layout Standard
This appendix presents a dual-input anchor solution which doesn't require
additional bitcoin signature flags.
It is not being proposed currently, as it seems that a single-sided anchor
is probably sufficient.
\end_layout
\begin_layout Subsection
Separate Anchor Transactions
\end_layout
\begin_layout Standard
To avoid the problem of needing all anchor signatures to derive the anchor
transaction ID to create the commitment transaction input, we split the
anchor into two transactions; thus A knows its anchor transaction ID, and
B knows its anchor transaction ID as shown in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Simplistic-Dual-Anchor"
\end_inset
.
\end_layout
\begin_layout Standard
\align center
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename dual-anchor-diag1.eps
scale 50
\end_inset
\begin_inset Caption Standard
\begin_layout Plain Layout
Simplistic Dual Anchor Design
\begin_inset CommandInset label
LatexCommand label
name "fig:Simplistic-Dual-Anchor"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
This form allows A and B to create commitment transactions which spends
the anchors outputs by exchanging anchor transaction IDs.
It has the problem that if the other party does not then broadcast its
anchor transaction, we cannot spend the commitment transaction, and our
own anchor funds are stuck.
\end_layout
\begin_layout Standard
Thus we introduce an
\emph on
escape
\emph default
transaction, which lets us regain our anchor funds in that case, as shown
in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Dual-Anchor2"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename dual-anchor-diag2.eps
scale 50
\end_inset
\begin_inset Caption Standard
\begin_layout Plain Layout
Dual Anchor With Simple Escape Transactions
\begin_inset CommandInset label
LatexCommand label
name "fig:Dual-Anchor2"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
However, this escape transaction would let either side remove its funds
from the channel at any time, which would make the channel insecure.
Thus, after the commitment transactions have been established, we want
to revoke the escape transactions.
We can do the same way we did for the commitment transaction revocation;
by placing restrictions on the
\begin_inset Quotes eld
\end_inset
to-me
\begin_inset Quotes erd
\end_inset
output.
In particular, adding a delay if paying back to the anchor owner, and allowing
it to be spent by the other party immediately if they possess the revocation
preimage, as shown in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Anchor-revoc-escape"
\end_inset
.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename dual-anchor-diag3.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Dual Anchors With Revocable Escape Transactions
\begin_inset CommandInset label
LatexCommand label
name "fig:Anchor-revoc-escape"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Unfortunately, this revocation is not a complete solution; if B uses its
escape transaction, A can collect B's anchor funds, but it has no way of
collecting its own! The commitment transaction cannot be used, as one of
its inputs has been spent by B's escape transaction.
A's own escape transaction has been revoked, so B would simply steal the
funds.
\end_layout
\begin_layout Standard
Thus we need an additional construction, such that using one escape transaction
immediately unlocks the other anchor funds for its owner.
To do this, we ensure that the escape transaction is forced to reveal a
secret, which is a fairly well-established technique
\begin_inset CommandInset citation
LatexCommand cite
key "nolan_alt"
\end_inset
.
The anchor transaction is modified to either require both signatures (for
the commitment transaction), or both signatures and the secret (for the
escape transaction), as shown in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Secret-Revelation-by"
\end_inset
.
Note that this requires the other party to provide an alternate key (denoted
here using A' and B'), otherwise there is no way to force the escape transactio
n to provide the secret.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename dual-anchor-diag4.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Secret Revelation by Escape Transactions
\begin_inset CommandInset label
LatexCommand label
name "fig:Secret-Revelation-by"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
That revealed secret can be used with the other alternative: the
\emph on
fast escape transaction.
\emph default
This reveals the secret just like the escape transaction, but its output
is immediately usable if one knows the other side's secret.
This is shown in Figure
\begin_inset CommandInset ref
LatexCommand ref
reference "fig:Final-Dual-Anchor"
\end_inset
.
Thus, if B broadcasts its escape transaction after it has been revoked,
A can (after ensuring escape B is sufficiently deep in the block chain)
broadcast its fast escape transaction and use B's secret to immediately
spend the output.
\end_layout
\begin_layout Standard
On the other hand, if B broadcasts its fast escape transaction without knowing
A's secret, A can simply wait for the timeout and spend the fast escape
output, then use its own fast escape transaction and B's secret to recover
its own anchor funds as well.
\end_layout
\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open
\begin_layout Plain Layout
\align center
\begin_inset Graphics
filename dual-anchor-final.eps
scale 50
\end_inset
\end_layout
\begin_layout Plain Layout
\begin_inset Caption Standard
\begin_layout Plain Layout
Final Dual Anchor Design
\begin_inset CommandInset label
LatexCommand label
name "fig:Final-Dual-Anchor"
\end_inset
\end_layout
\end_inset
\end_layout
\end_inset
\end_layout
\begin_layout Standard
The final scripts are shown in
\begin_inset CommandInset ref
LatexCommand nameref
reference "sec:Appendix-A:-Scripts"
\end_inset
.
\end_layout
\begin_layout Subsection
Disadvantages of The Dual Anchor Approach
\end_layout
\begin_layout Standard
Unlike the mutual anchor approach, use of escape transactions is not outsourcabl
e: you cannot have an untrusted third party which can monitor the network
for the other sides' revoked escape transaction and respond with your own
escape transaction.
If you were to provide a third party with your fast escape transaction,
you would necessarily provide it with the secret, which it could give to
B.
\end_layout
\begin_layout Subsection
Script Definitions for Escape Transactions
\end_layout
\begin_layout Subsection*
Escape Transaction
\end_layout
\begin_layout Standard
The escape transaction for A spends A's anchor output and reveals A's secret.
Similarly for B.
\end_layout
\begin_layout Subsubsection*
Escape Input Script
\end_layout
\begin_layout Standard
The extra 0 at the start is due to the OP_CHECKMULTISIG out-by-one-bug.
\end_layout
\begin_layout Description
0
\begin_inset space ~
\end_inset
<SIG-B'>
\begin_inset space ~
\end_inset
<SIG-A>
\begin_inset space ~
\end_inset
<SECRET-A>
\begin_inset space ~
\end_inset
{<ANCHOR-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsubsection*
Escape Output Redeemscript
\end_layout
\begin_layout Standard
This allows two paths: one for the other side to use the revocation image,
and one for this side to get their funds back after a delay.
This show's A's script, but B's is the same with A and B exchanged.
\end_layout
\begin_layout Description
OP_HASH160
\begin_inset space ~
\end_inset
<RHASH-A>
\begin_inset space ~
\end_inset
OP_EQUAL Check if the top of the stack contains the revocation image.
\end_layout
\begin_layout Description
OP_IF
\end_layout
\begin_deeper
\begin_layout Description
<KEY-B> Funds for B.
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE It's A getting their funds back
\end_layout
\begin_deeper
\begin_layout Description
<DELAYTIME>
\begin_inset space ~
\end_inset
OP_CHECKSEQUENCEVERIFY
\begin_inset space ~
\end_inset
OP_DROP Ensure delay.
\end_layout
\begin_layout Description
<KEY-A> Needs to be signed by A.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
OP_CHECKSIG Make sure it's signed correctly.
\end_layout
\begin_layout Subsubsection*
Spending The Escape Output
\end_layout
\begin_layout Standard
Either B using a revocation preimage:
\end_layout
\begin_layout Description
<SIG-B>
\begin_inset space ~
\end_inset
<REVOCATION-IMAGE-A>
\begin_inset space ~
\end_inset
{<ESCAPE-REDEEMSCRIPT>}
\end_layout
\begin_layout Standard
Or A using after a timeout:
\end_layout
\begin_layout Description
<SIG-A>
\begin_inset space ~
\end_inset
0
\begin_inset space ~
\end_inset
{<ESCAPE-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsection*
Fast-Escape Transaction
\end_layout
\begin_layout Subsubsection*
Fast-Escape Input Script
\end_layout
\begin_layout Standard
This is identical to the normal escape input script.
\end_layout
\begin_layout Description
0
\begin_inset space ~
\end_inset
<SIG-B'>
\begin_inset space ~
\end_inset
<SIG-A>
\begin_inset space ~
\end_inset
<SECRET-A>
\begin_inset space ~
\end_inset
{<ANCHOR-REDEEMSCRIPT>}
\end_layout
\begin_layout Subsubsection*
Fast-Escape Output Redeemscript
\end_layout
\begin_layout Standard
This allows two paths: one for this side to use the other side's secret
(revealed by them using an escape transaction), and one for the other side
to claim this side's anchor funds after a delay.
This shows A's script, but B's is the same with A and B exchanged.
\end_layout
\begin_layout Description
OP_HASH
\begin_inset space ~
\end_inset
<SECRET-B-HASH>
\begin_inset space ~
\end_inset
OP_EQUAL If top argument is B's secret
\end_layout
\begin_layout Description
OP_IF
\end_layout
\begin_deeper
\begin_layout Description
<KEY-A> For A
\end_layout
\end_deeper
\begin_layout Description
OP_ELSE B gets it if A doesn't know the secret.
\end_layout
\begin_deeper
\begin_layout Description
<DELAYTIME>
\begin_inset space ~
\end_inset
OP_CHECKSEQUENCEVERIFY
\begin_inset space ~
\end_inset
OP_DROP Ensure delay.
\end_layout
\begin_layout Description
<KEY-B> Needs to be signed by B.
\end_layout
\end_deeper
\begin_layout Description
OP_ENDIF
\end_layout
\begin_layout Description
OP_CHECKSIG Make sure it's signed correctly.
\end_layout
\begin_layout Subsubsection*
Spending The Fast-Escape Output
\end_layout
\begin_layout Standard
Either A using B's secret revealed by B using its own escape transaction:
\end_layout
\begin_layout Description
<SIG-A>
\begin_inset space ~
\end_inset
<SECRET-B>
\begin_inset space ~
\end_inset
{<FAST-ESCAPE-REDEEMSCRIPT>}
\end_layout
\begin_layout Standard
Or B using after a timeout:
\end_layout
\begin_layout Description
<SIG-B>
\begin_inset space ~
\end_inset
0
\begin_inset space ~
\end_inset
{<FAST-ESCAPE-REDEEMSCRIPT>}
\end_layout
\end_body
\end_document