Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5523C002D for ; Mon, 25 Apr 2022 05:36:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7FFE960AF2 for ; Mon, 25 Apr 2022 05:36:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPo6u_s38IQK for ; Mon, 25 Apr 2022 05:36:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4834160011 for ; Mon, 25 Apr 2022 05:36:56 +0000 (UTC) Date: Mon, 25 Apr 2022 05:36:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1650865013; bh=AQ2fZoSbcm0lvnAj6ozmJG8VTcLREKnJ57kMOQ/rGqw=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=0M8c9fBsT3fONRHONwoAOfbAlE8nwTTrU89xjKGpPyFG/sDH4ejEM9XT7oMhCAszS 4n40jqwRNq7zEJ1zxHhk5mThGETsfIU5/Ox4YHss0goBcSdMNOROhmfGTgDnklaWJ/ dVaZEVUAyNmed/BZWm58sWrH0qMlBS7TrZ/lNcoKxCaB3ISpQrdtes6n+p0Xy/5Ozl aG02JEdKaSVNwomN1yW/4soa2vOtNgC+pGZ54w2ZPGOoX3a9Jg82CBXZU51R+YbNUE m7lggHtEKV7ipDAJmKnAT3AGScl2xmwZWMLqpTEjlT+zYq/7W2IUkfKwsMwrltB9Y0 W+UJ5ENeHUWiQ== To: Peter Todd , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2022 05:36:57 -0000 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