From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6EC6DC000B for ; Fri, 28 Jan 2022 15:14:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4A29141616 for ; Fri, 28 Jan 2022 15:14:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWu97-AMPzVa for ; Fri, 28 Jan 2022 15:14:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by smtp4.osuosl.org (Postfix) with ESMTPS id 7A6F8408E4 for ; Fri, 28 Jan 2022 15:14:24 +0000 (UTC) Received: by mail-yb1-xb2d.google.com with SMTP id j2so6145454ybu.0 for ; Fri, 28 Jan 2022 07:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dLn4mmBPPANTQ++qcPuaqL3wKBYl7dKmDu25KLHRQMA=; b=pb3eGPFQWTHFk8NBaD6awYHBqzIeQDAjfeakQ58ye9jnY5YqP9O505sOL+BoZy1MGc qmtCglDcawG+4eEtI6Fkcv5IpnADFMmD3rObo9I5dMOxfk5NWekWo2fdCfxgJXrLKn0V KQV+OD/3li35/bnGtEbMVEmBOQMSNgSf2NbOqb3HJ4C90LJl1fq2buHsiKLJFM9JXfnt nSw07VVMxSzHncRYPFdfKrS2LWUGy7oZe6Rrq1iip5m4vVxlOonOr29hgDKvDrGujAfC R005ldsEHQtnr6Zqk29054GOt944ESocCZ5RO9vpVe3Ep0zUQHuW95eLSwxyrlEoPTUR yDew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dLn4mmBPPANTQ++qcPuaqL3wKBYl7dKmDu25KLHRQMA=; b=VVtjK8VwfzhhC76K7Q+iUtnPC57E2/A35bK+fpfLGls1DcQF3g3fIK4FNPaMkuWtkp 0jUTQNJpMMjGu/4Ze0bPLOfhuvOqkfZJCzfK0DaN57rOiE3x7hT7e+RmFO4wh8WCjpPQ 00zcgA3RheKFm02Kr2I35kO981Ti1woLmxmJO/xVII+Qr2nne68ppzbwD34fgG7zAHlk xlO7UvkZJEE1gcfkkO0WB4aAfuLGlMgcImjLCf1JOpRlarCgTa3ndULZu3qdGm3O51ko mQaeN/zRfCZw03wd67hYV9boWDEi+sRHCGFb1clAXKpTk2Knh9oKtZxl7OI58i8y7WuH NAKQ== X-Gm-Message-State: AOAM533f7gM+rM7QC1k3JMVDwOkcExghdyCXlmBtx9dVS2Ju6wZXkROV vDREsOWhEj4qm1MNAUMWJE++t/gtlOwUz9TLNrI= X-Google-Smtp-Source: ABdhPJwGo7dCm6Pqcugj4ZwYY+V7jU0VsoDHPj7ZK0rBeuqhbLYmqO3U7m1CjYTlszyZuCpZUC6rMfBjFnC61s+qXsQ= X-Received: by 2002:a25:7382:: with SMTP id o124mr12742555ybc.318.1643382863288; Fri, 28 Jan 2022 07:14:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "James O'Beirne" Date: Fri, 28 Jan 2022 10:14:12 -0500 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000cbdf5905d6a5e3ca" X-Mailman-Approved-At: Fri, 28 Jan 2022 15:40:30 +0000 Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT 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: Fri, 28 Jan 2022 15:14:27 -0000 --000000000000cbdf5905d6a5e3ca Content-Type: text/plain; charset="UTF-8" > Technical debt isn't a measure of weight of transactions. Sorry, my original sentence was a little unclear. I meant to say that the notion that CTV is just a subpar waypoint en route to a more general covenant system may not be accurate if it is a more efficient way (in terms of chainstate/weight) to express highly useful patterns like vaults. In that case, characterizing CTV as technical debt wouldn't be right. > Our only option here is to be mindful of the long term implications of the design choices we are making today. Your points are well taken - I don't think anyone is arguing against thinking hard about consensus changes. But I have yet to see a proposal for covenants that is as efficient on-chain and easy to reason about as CTV is. I also think there's some value in "legging into" covenants by deploying a simple, non-recursive construction like CTV that services some very important uses, and then taking as much time as necessary to think about how to solve more existential problems, like UTXO scalability, that likely require a recursive covenant construction. There doesn't have to be mutual exclusion in the approaches, especially when the maintenance burden of CTV seems to be so low. If we end up deploying something that requires a wider variety of in-script hashing, it seems likely that CTV's hash will be able to "free ride" on whatever more general sighash cache structure we come up with. --000000000000cbdf5905d6a5e3ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Technical debt isn't a measure o= f weight of transactions.

Sorry, = my original sentence was a little unclear. I meant to say that the notion t= hat CTV is just a subpar waypoint en route to a more general covenant syste= m may not be accurate if it is a more efficient way (in terms of chainstate= /weight) to express highly useful patterns like vaults. In that case, chara= cterizing CTV as technical debt wouldn't be right.

> Our only option here is to be mindful of the long term implic= ations of the design choices we are making today.

= Your points are well taken - I don't think anyone is arguing against th= inking hard about consensus changes. But I have yet to see a proposal for c= ovenants that is as efficient on-chain and easy to reason about as CTV is. =

I also think there's some value in "= legging into" covenants by deploying a simple, non-recursive construct= ion like CTV that services some very important uses, and then taking as muc= h time as necessary to think about how to solve more existential problems, = like UTXO scalability, that likely require a recursive covenant constructio= n.

There doesn't have to be mutual exclusion = in the approaches, especially when the maintenance burden of CTV seems to b= e so low. If we end up deploying something that requires a wider variety of= in-script hashing, it seems likely that CTV's hash will be able to &qu= ot;free ride" on whatever more general sighash cache structure we come= up with.
--000000000000cbdf5905d6a5e3ca--