Skip to content

Instantly share code, notes, and snippets.

@instagibbs

instagibbs/eltoo_pinning.txt Secret

Created May 5, 2022 19:28
Show Gist options
  • Save instagibbs/60264606e181451e977e439a49f69fe1 to your computer and use it in GitHub Desktop.
Save instagibbs/60264606e181451e977e439a49f69fe1 to your computer and use it in GitHub Desktop.
Download ZIP
eltoo pinning fun and pictures
Raw
eltoo_pinning.txt
Hello LN devs,
I, along with a number of others, have been sketching out what a successful eltoo architecture would look like, especially within the context of Lightning Network usage.
There's been a number of issues that have cropped up:
1) "Vanilla" eltoo(~what was in the original paper) means that cltv_expiry_delta values are going to be quite large to account for the coupling of the channel and HTLC timeouts. Which leads to
2) "Layered commitments" style eltoo, which decouples the timeouts, at the cost of moderate complexity, and additional unknowns
3) How are fees paid for either variant?
4) How does (total)fee pinning play into this?
5) Suggested modifications in light of (4)
-------------------------------
1) To recap vanilla eltoo at a very high level:
Vanilla eltoo
REBIND UPDATE TXS
--------------------------------------------------------------------------------------
- - -
(small boxes are outputs) - - -
+---+ - | |
| | +-----------------+ - +-----------------+ v+------ -----+ v+-----------------+
+---+ | | +--+ | | +--+ | | +--+ | |
| +------->| funding tx +--------+ +------>| update tx +------->| +------>| ......... +------->| +------>| update tx |
+---+ | | ++-+ | | ++-+ | | ++-+ | |
| | +-----------------+ | +-----------------+ | +------ -----+ | +-----------------+
+---+ | | |
SHARED | DELAY SHARED | DELAY SHARED | DELAY
| | |
| +-----------------+ | +-----------------+ | +-----------------+
| | | | | | | | |
+-------->| settle tx | +-------->| settle tx | +-------->| settle tx |
| | | | | |
+-+-----+-------+---+ +-+-----+-------+---+ +-+-----+-------+---+
| | |cltv_expiry_delta | | |cltv_expiry_delta | | |cltv_expiry_delta
v v v v v v v v v
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A | | B | |H/P| | A | | B | |H/P| | A | | B | |H/P|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
BALANCES & {H,P}TLCs BALANCES & {H,P}TLCs BALANCES & {H,P}TLCs
As you can see, to time out an HTLC, you must first wait the channel-wide SHARED_DELAY after the latest update tx is posted before cltv_expiry_delta can be "played", so they're chosen in a coupled fashion.
Maybe that's fine, maybe it's not. I won't delve into the debate here.
-------------------------------
2) Layered commitments variant at high level (LINK). Any misunderstandings can be attributed to me, or to AJ's writing skills, you get to choose!:
"Layered commitments" eltoo
(for simplicity, all *TLCs are offered by Alice)
+---------------------------------------------------------------------------------------+
| |
| UPDATE-SPENDABLE OUTPUTS +-----------------+ |
| | | | +---+
| | settlement +------------+---------------------------------------->| A |
| | tx | | +---+
| +-------^---------+ |
+---+ | +---+ SHARED DELAY | |
| A +-------+ | +--------->| A +----------------+ |
+---+ | | | +---+ |
>+-----------------+ | +-----------------+ +-----------------+ | +-----------------+
+---+ | | | +---+ | | +---+PREIMAGE| revocable | +---+ | SHARED DELAY | | +---+
| B +------->| funding tx +--+-->|A+B+----->| update tx +--------->|H/P+------->| claim tx +----->| +-+--------------->| settlement +----->| B |
+---+ | | | +---+ | | +-+-+ | (SUCCESS) | +---+ | | tx | +---+
^+-----------------+ | +-----------------+ | +-----------------+ | +-----------------+
+---+ | | | | |
| A +-------+ | | | |
+---+ | | | +-----------------+ | +-----------------+
| | | CLTV EXP | revocable | +---+ | SHARED DELAY | | +---+
| | +--------->| claim tx +----->| +-+--------------->| settlement +----->| A |
| | DELTA | (TIMEOUT) | +---+ | | tx | +---+
| | +-----------------+ | +-----------------+
| | |
| | |
| | +---+ |
| +--------->| B +---------------+ |
| +---+ SHARED DELAY | |
| +-------v---------+ |
| | | | +---+
| | settlement +-------------+---------------------------------------->| B |
| | tx | | +---+
| +-----------------+ |
| |
+---------------------------------------------------+-----------------------------------+
- | +-----------------+
- | | |
- | | settlement +-----------
- +----+ | tx |
- SPEND | +-------^---------+
- | +---+ SHARED DELAY |
- | +--------->| A +----------------+
- v | +---+
- +-----------------+ +-----------------+
- | | +---+PREIMAGE| revocable | +---+
- | update tx +--------->|H/P+------->| claim tx +----->| |
- | | +-+-+ | (SUCCESS) | +---+
- +-----------------+ | +-----------------+
- | | ........
- | |
- | | +-----------------+
- | | CLTV EXP | revocable | +---+
- | +--------->| claim tx +----->| |
- | DELTA | (TIMEOUT) | +---+
- | +-----------------+
- |
- |
- | +---+
- +--------->| B +---------------+
REBIND - +---+ SHARED DELAY |
- +-------v---------+
- | |
- | settlement +------------
- | tx |
- +-----------------+
-
-
- (..... A FEW THOUSAND DAYS LATER.....)
-
-
-
-
-
-
- | +-----------------+
- | | |
- | | settlement +-----------
- +----+ | tx |
- SPEND | +-------^---------+
- | +---+ SHARED DELAY |
- | +--------->| A +----------------+
- v | +---+
- +-----------------+ +-----------------+
- | | +---+PREIMAGE| revocable | +---+
------------------->| update tx +--------->|H/P+------->| claim tx +----->| |
| | +-+-+ | (SUCCESS) | +---+
+-----------------+ | +-----------------+
| | ........
| |
| | +-----------------+
| | CLTV EXP | revocable | +---+
| +--------->| claim tx +----->| |
| DELTA | (TIMEOUT) | +---+
| +-----------------+
|
|
| +---+
+--------->| B +---------------+
+---+ SHARED DELAY |
+-------v---------+
| |
| settlement +------------
| tx |
+-----------------+
Easiest way to think about the update step is basically that the APOAS|SIGHASH_ALL signature allows you to rebind to any number of inputs from previous update txs that may be posted to the blockchain, while still committing to the outputs of the "latest" state you are posting.
-------------------------------
3) FEES
Vanilla:
update txs were proposed to be done via APO|SIGHASH_SINGLE for the first input/output pair, and users would bring their own fees on input/ouputs(s) 1, 2, 3, whatever.
Settlement txs have balance outputs directly spendable, and HTLCs that have perhaps been fufilled/timed out, making them CPFP-able. Due to multiple outputs, only SIGHASH_SINGLE(or GROUP-ish future changes) can be used, disallowing naive RBFs. AM I MISSING PINNING VECTORS HERE, ALA ANCHORS?
Layered eltoo:
update txs fees, using today's + BIP118's sighashes, would essentially require a user to send another utxo to the "UPDATE-SPENDABLE OUTPUTS" set, and completely spent to fees, since we're commiting to all outputs via SIGHASH_ALL. It's a bit wasteful having to make a utxo just in time to fund the transaction, but these are the cases that are "never" supposed to happen, so perhaps we shouldn't focus too much on that. Let's call these <NICKNAME>
Revocable/settlement txs are using SIGHASH_SINGLE at each step, so it stands to reason that the same strategy as vanilla update txs can be used here to bring your own fees.
-------------------------------
4) The real problem here seems to be that for each case I've elaborated on, the counterparty can replay old states at low feerates, for essentially free.
Alice can take an old, or even current update tx to chain, inflated with as many inputs/outputs as they want, of any size at a low feerate making RBF and CPFP prohibitively expensive. If you successfully RBF it, they end up paying nothing for the privelage of taxing you. This can cause HTLC theft, and just general denial of service headaches at potentially extremely low cost to the attacker.
BIP125's requirement to replace total fees of replaced transactions rears its ugly head again.
-------------------------------
5) Proposed modifications to APO(AS):
None unless we fixup mempool or put powerful transaction introspection opcodes into bitcoin like OP_TXWEIGHT, OP_INSPECTNUMOUTPUTS, OP_INSPECTOUTPUTSCRIPTPUBKEY, et al.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment