pull down to refresh

Can someone explain the debate of CTV vs APO

3 sats \ 7 comments \ @jp 3 Jan 2022 bitcoin

Recently it appears there is some debate about BIP-119 and ANYPREVOUT.

Most of my searching leads to overly technical articles (i.e. https://bitcoin.stackexchange.com/questions/111497/how-do-eltoo-channel-constructions-using-anyprevout-compare-to-those-using-ctv-a) that are beyond my smooth-brain's ability to comprehend.

Can someone ELI5 the current debate between CTV and APO?

view all related items

2 sats \ 5 replies \ @k00b 3 Jan 2022

AFAIK The debate is mostly over which soft fork should be activated "next" while they both do different things. Hopefully, we'll see both get implemented.

ANYPREVOUT

Allows for the Lightning protocol to move to another channel update mechanism (the way parties agree on the channel balance after payments in the channel) called eltoo. This channel update mechanism is desirable because the current update mechanism has a variety of drawbacks:

it requires storing data from all past channel updates
requires harsh penalties to work (you sweep all my funds if I use old state from (1) regardless of whether it was in error or not)

ANYPREVOUT fixes these:

you only have to maintain the current state at anytime, i.e. if there have been N channel balance updates between us, we each only need to store 1 tx
there isn't a penalty - if I broadcast an old channel balance, you can simply broadcast a newer one that takes precedence

CTV

My understanding is relatively weak, mind you ...

It's a covenant mechanism; that is, it provides a way to restrict the way utxos can be spent. AFAIK there have been many such proposals but CTV has the most work/promotion done on it and it has the most support.

The applications of CTV are numerous as Rubin lays out frequently on his blog.

Counter-intuitively (I think) restricting the way coins can be spent increases the utility of the coins. They are a lot like human contracts; they bind the coins to behave in particular ways in the future. We can currently restrict spending with existing op codes but we don't have many ways to express restrictions.

1 sat \ 2 replies \ @jp OP 4 Jan 2022

For APO#2 what securities are in place to prevent users from repeatedly pushing channel updates that contradict each other?

0 sats \ 1 reply \ @k00b 4 Jan 2022

I assume you mean pushing (ie broadcasting) on chain. If you push an old state, say one where you have more Bitcoin than you actually do, all your channel partner needs to do is broadcast the correct version. That’s what ANYPREVOUT does - it allows you to commit/sign a transaction that isn’t bound to any particular previous output, it can be any output. In the this case, the any output it’s binding to is the old (bad) state you pushed.

1 sat \ 0 replies \ @jp OP 4 Jan 2022

Ah got it - thank you for clarifying

0 sats \ 1 reply \ @earonesty 25 Apr 2022 freebie

FWICT:

almost anything you can do with APO you can do with CTV... but at big losses in efficiency depending on the construction
some uses for lightning are cheaper with APO
some uses for vaults are cheaper with CTV
CTV has more prep work done
APO is a smaller, and seemingly less controversial, code change

0 sats \ 0 replies \ @nout 4 Jan 2022

Some further useful context and arguments are in this thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019730.html (see parents and ancestors)