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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
