Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id E0919C002D for ; Sat, 20 Aug 2022 03:04:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A7E6E606AA for ; Sat, 20 Aug 2022 03:04:03 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A7E6E606AA Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=uLcRhhK5 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 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 WcLX8Avk3wLr for ; Sat, 20 Aug 2022 03:04:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5ABDA6064D Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5ABDA6064D for ; Sat, 20 Aug 2022 03:04:02 +0000 (UTC) Date: Sat, 20 Aug 2022 03:03:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1660964639; x=1661223839; bh=LILD4t94Sy6MdRa9ZhDKBuQPUGq/7NLUOyTHJJ4SbDI=; 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=uLcRhhK5Zc7M5Iy5Smv5LkMVDpqOpIN4eNPzoVhJzyoH6+InTDfOfpk9KRylELj0T Yi7EvpeMloBAU0IEs2oNqN8154QsqkCYvzQUiMj69e8SLktXB3P+b3vscdk4CZSEQw FhzPLedmadzSntqiTdt/52tpT1XhUh9t5WANemObRmDMVg76f+omVfnAwIV4+/wLcy enlyoeV8B0mINRdIMfvzV5BfD6cQ38mYYhODiZJFdbodPpa83HwPg/bUr/Y04MrxxK TT6Ew7TbQVIBn/utGllUO7iWvoJ+CXZfu7HR2pRe0AumHHY57oufwQwa2Nel3OUieH oJwSxAEVTeR8g== To: Greg Sanders , 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] More uses 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: Sat, 20 Aug 2022 03:04:04 -0000 Good morning Greg, > Hi James, > Could you elaborate on a L2 contract where speedy > settlement of the "first part" can be done, while having the rest > take their time? I'm more thinking about time-out based protocols. >=20 > Naturally my mind drifts to LN, where getting the proper commitment > transaction confirmed in a timely fashion is required to get the proper > balances back. The one hitch is that for HTLCs you still need speedy > resolution otherwise theft can occur. And given today's "layered > commitment" style transaction where HTLCs are decoupled from > the balance output timeouts, I'm not sure this can save much. As I understand it, layered commitments can be modified to use `OP_CTV`, wh= ich would be slightly smaller (need only to reveal a 32-byte `OP_CTV` hash = on the witness instead of a 64-byte Taproot signature, or 73-byte classical= pre-Taproot ECDSA signature), and is in fact precisely an example of the s= peedy settlement style. > CTV style commitments have popped up in a couple places in my > work on eltoo(emulated via APO sig-in-script), but mostly in the > context of reducing interactivity in protocols, not in byte savings per s= e. In many offchain cases, all channel participants would agree to some pre-de= termined set of UTXOs, which would be implemented as a transaction spending= some single UTXO and outputting the pre-determined set of UTXOs. The single UTXO can be an n-of-n of all participants, so that all agree by = contributing their signatures: * Assuming Taproot, the output address itself is 33 bytes (x4 weight). * The n-of-n multisignature is 64 witness bytes (x1 weight).=20 Alternatly the single UTXO can be a P2WSH that reveals an `OP_CTV`: * The P2WSH is 33 bytes (x4 weight) --- no savings here. * The revelation of the ` OP_CTV` is 33 witness bytes (x1 weight). Thus, as I understand it, `OP_CTV` can (almost?) always translate to a smal= l weight reduction for such "everyone agrees to this set of UTXOs" for all = offchain protocols that would require it. Regards, ZmnSCPxj