Date: Mon, 25 Apr 2022 05:36:48 +0000
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <tBEO_7gKqAlgiRpjC1OCLMBcLddK0ffNlbdU65VhXnXqZQiDCTDNOw8sfTXqNXZxVA8wA0uodTLvptt7Iy5O3D_6hkiVVfLegOrg9C1Snkg=@protonmail.com>
In-Reply-To: <B037C028-EB25-4197-A0F1-48838D1AD30F@petertodd.org>
References: <RyYBRY3MJP_0b2YkCEUFBdP8u1A_cGSEEkDbzKK9k-rkINZrBaOL70L96iHR11bJhmkhAzuN6uZ1X8PQgz2wa8Us3-2OpNa4RbhSSprw_WE=@protonmail.com>
 <CALeFGL1=4PrA_ziTsoS9sUjGjfLr54AiMfM99uDV-Bau5Ab_eQ@mail.gmail.com>
 <CAJ4-pEADrHf_YR5ZBfJW+eefKrp1iEj4wAi72UrwRSi9gaVP+w@mail.gmail.com>
 <B037C028-EB25-4197-A0F1-48838D1AD30F@petertodd.org>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Precedence: list

Good morning Peter,

>
> On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev bi=
tcoin-dev@lists.linuxfoundation.org wrote:
>
> > I like the maxim of Peter Todd: any change of Bitcoin must benefit all
> > users. This means that every change must have well-defined and transpar=
ent
> > benefits. Personally I believe that the only additions to the protocol =
that
> > would still be acceptable are those that clearly benefit layer 2 soluti=
ons
> > such as LN and do not carry the dangerous potential of getting abused b=
y
> > freeloaders selling commercial services on top of =E2=80=9Cfree=
=E2=80=9D eternal storage on
> > the blockchain.
>
>
> To strengthen your point: benefiting "all users" can only be done by bene=
fiting layer 2 solutions in some way, because it's inevitable that the vast=
 majority of users will use layer 2 because that's the only known way that =
Bitcoin can scale.

I would like to point out that CTV is usable in LN.
In particular, instead of hosting all outputs (remote, local, and all the H=
TLCs) directly on the commitment transaction, the commitment transaction in=
stead outputs to a CTV-guarded SCRIPT that defers the "real" outputs.

This is beneficial since a common cause of unilateral closes is that one of=
 the HTLCs on the channel has timed out.
However, only *that* particular HTLC has to be exposed onchain *right now*,=
 and the use of CTV allows only that failing HTLC, plus O(log N) other txes=
, to be published.
The CTV-tree can even be rearranged so that HTLCs with closer timeouts are =
nearer to the root of the CTV-tree.
This allows the rest of the unilateral close to be resolved later, if right=
 now there is block space congestion (we only really need to deal with the =
sole HTLC that is timing out right now, the rest can be done later when blo=
ck space is less tight).

This is arguably minimal (unilateral closes are rare, though they *do* have=
 massive effects on the network, since a single timed-out channel can, duri=
ng short-term block congestion, cause other channels to also time out, whic=
h worsen the block congestion and leading to cascades of channel closures).

So this objection seems, to me, at least mitigated: CTV *can* benefit layer=
 2 users, which is why I switched from vaguely apathetic to CTV, to vaguely=
 supportive of it.

Regards,
ZmnSCPxj