From: Anthony Towns <aj@erisian•com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Swift Activation - CTV
Date: Wed, 3 Jan 2024 18:36:02 +1000 [thread overview]
Message-ID: <ZZUcckQkd7K9wIka@erisian.com.au> (raw)
In-Reply-To: <7NGPxdCD3faagkDFsyhVnjyXGu_BF3PfRW86QjZxP-nsDY-EvNGlyxXSEA7nf0SYzm5Ql45sA7gDGjKNpqWQoALLUz-MROUZTGjEFtzTdm8=@protonmail.com>
On Sat, Dec 30, 2023 at 01:54:04PM +0000, Michael Folkson via bitcoin-dev wrote:
> > > But "target fixation" [0] is a thing too: maybe "CTV" (and/or "APO") were just a bad approach from the start.
> It is hard to discuss APO in a vacuum when this is going on the background but I'm interested in you grouping APO with CTV in this statement. ... But APO does seem to be the optimal design and have broad consensus in the Lightning community for enabling eltoo/LN-Symmetry. Any other use cases APO enables would be an additional benefit.
I guess I'm really just reiterating/expanding on Russell's thoughts from
two years ago:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
CTV and APO both take the approach of delineating a small, precise piece
of functionality that is thought to be useful in known ways, and making
that available for use within Bitcoin. But doing incremental consensus
changes every time we discover new features that we'd like to add to
wallet/L2 software is kind of clumsy, and perhaps we should be looking
at more general approaches that allow more things at once.
Beyond that, APO also follows the design of satoshi's ANYONECANPAY,
which allows attaching other inputs. There's a decent argument to be
made that that's a bad design choice (and was perhaps a bad choice
for ANYONECANPAY as well as APO), and that committing to the number of
inputs would still be a valable thing to do (in that it minimises how
much third parties can manipulate your tx, and reduces the potential for
rbf pinning). A consequence of that is that once if you fix the number
of inputs to one and already know the input you're spending, you avoid
txid malleability. See https://github.com/bitcoin/bips/pull/1472 eg.
Cheers,
aj
prev parent reply other threads:[~2024-01-03 8:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 1:44 alicexbt
2023-12-22 1:05 ` Luke Dashjr
2023-12-22 1:56 ` alicexbt
2023-12-22 22:34 ` alicexbt
2023-12-30 8:05 ` Anthony Towns
2023-12-30 8:59 ` Erik Aronesty
2024-01-01 16:37 ` Michael Folkson
2024-01-01 17:11 ` Erik Aronesty
2024-01-02 13:52 ` Michael Folkson
2024-01-02 14:32 ` Erik Aronesty
2024-01-02 16:24 ` Ryan Breen
2024-01-02 16:43 ` alicexbt
2023-12-30 13:54 ` Michael Folkson
2024-01-03 8:36 ` Anthony Towns [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZZUcckQkd7K9wIka@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox