1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1017FC0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jan 2024 08:36:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id CCC7281F65
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jan 2024 08:36:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org CCC7281F65
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pqiQNJgPnuj3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jan 2024 08:36:14 +0000 (UTC)
Received: from cerulean.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp1.osuosl.org (Postfix) with ESMTPS id B6D2F8200C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jan 2024 08:36:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B6D2F8200C
Received: from aj@azure.erisian.com.au
by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
(envelope-from <aj@erisian.com.au>) id 1rKwjP-0001Vv-70
for bitcoin-dev@lists.linuxfoundation.org; Wed, 03 Jan 2024 18:36:11 +1000
Received: by email (sSMTP sendmail emulation); Wed, 03 Jan 2024 18:36:02 +1000
Date: Wed, 3 Jan 2024 18:36:02 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZZUcckQkd7K9wIka@erisian.com.au>
References: <39ecOLU7GJPGc0zWZmGuaj-a4ANySfoRjwxoUoxP480kfRRc_fsPl9MvZDC-0vSfrO3jYraHVUyxWpcg7AFHRJkEJUERYdHZlzimOwql1j0=@protonmail.com>
<2e113332-2cfd-73ec-0368-136728ceb31a@dashjr.org>
<Tp6LkEd_YZUe-0sI-EXRmGTaq4Om2RSKIOUsXS0GIsYW5z_MFnicWPz2hB1KZYJ1mihv0KrJT8DmnuDr1RCcIpFM9jCOy82BvRJySkO7Im8=@protonmail.com>
<fcOFuPPZB9Cn6nuIkAcvbECmYqISZQ-5O2hQGli-F8FOK68etbaGNlrMT4OuPSBFI9VjaBe_izZEgezy8KZbjeBIaO_QPNfwrF61IorSP44=@protonmail.com>
<ZY/PYiO2Yg3FNiYV@erisian.com.au>
<7NGPxdCD3faagkDFsyhVnjyXGu_BF3PfRW86QjZxP-nsDY-EvNGlyxXSEA7nf0SYzm5Ql45sA7gDGjKNpqWQoALLUz-MROUZTGjEFtzTdm8=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7NGPxdCD3faagkDFsyhVnjyXGu_BF3PfRW86QjZxP-nsDY-EvNGlyxXSEA7nf0SYzm5Ql45sA7gDGjKNpqWQoALLUz-MROUZTGjEFtzTdm8=@protonmail.com>
X-Spam_score: -0.0
X-Spam_bar: /
Subject: Re: [bitcoin-dev] Swift Activation - CTV
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jan 2024 08:36:16 -0000
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
|
