From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3971C000B for ; Wed, 9 Mar 2022 14:30:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B20E460C29 for ; Wed, 9 Mar 2022 14:30:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Lt_f8prqnZJH for ; Wed, 9 Mar 2022 14:30:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp3.osuosl.org (Postfix) with ESMTPS id CDE2A60B75 for ; Wed, 9 Mar 2022 14:30:43 +0000 (UTC) Date: Wed, 09 Mar 2022 14:30:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646836241; bh=XAjVX9ANet064ktBRK7aVqbku9A1TMrAVfbqbBpmDAM=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=eOziOZGnSMDKr8TQXyYfXMt42WTORMQ3wXf1lI+Nh+XCgSwjbx79wnfojFlx37f9+ CID1BpBn41q9WYllfB4pOlUD/35bTcPaLwZl5M1WoU/3dl8hR98sNJ8U0ePEV8xhCI wRimvL6RxZHpex6f1NUv/7f4EuwWcxu5O451QSSJFORVjQipPawM4dLYlajDVrCiVW 0IjEXg6iriovH5nyscV6MPQGS4fYdTgyUntQeVPeP44g0mATxCbDGwcGZwi5u6t9EL d/epUYq8EKWjQE3ycVF6TUSAFOQ4SGJ04xpqR0Cgr3iAYaLsh1GSisLTENdUKgF7zq Gp+qHJGSwE60A== To: Bram Cohen From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <20220308012719.GA6992@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , Anthony Towns Subject: Re: [bitcoin-dev] bitcoin scripting and lisp 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: Wed, 09 Mar 2022 14:30:44 -0000 Good morning Bram, > On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj wrote: > > > But cross-input signature aggregation is a nice-to-have we want for Bit= coin, and, to me, cross-input sigagg is not much different from cross-input= puzzle/solution compression. > > Cross-input signature aggregation has a lot of headaches unless you're us= ing BLS signatures, in which case you always aggregate everything all the t= ime because it can be done after the fact noninteractively. In that case it= makes sense to have a special aggregated signature which always comes with= a transaction or block. But it might be a bit much to bundle both lisp and= BLS support into one big glop. You misunderstand my point. I am not saying "we should add sigagg and lisp together!" I am pointing out that: * We want to save bytes by having multiple inputs of a transaction use the = same single signature (i.e. sigagg). is not much different from: * We want to save bytes by having multiple inputs of a transaction use the = same `scriptPubKey` template. > > For example you might have multiple HTLCs, with mostly the same code ex= cept for details like who the acceptor and offerrer are, exact hash, and ti= melock, and you could claim multiple HTLCs in a single tx and feed the deta= ils separately but the code for the HTLC is common to all of the HTLCs. > > You do not even need to come from the same protocol if multiple protoco= ls use the same code for implementing HTLC. > > HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them. Li= ke, so little that there's almost nothing to compress. In Bitcoin at least an HTLC has, if you remove the `OP_PUSH`es, by my count= , 13 bytes. If you have a bunch of HTLCs you want to claim, you can reduce your witness= data by 13 bytes minus whatever number of bytes you need to indicate this. That amounts to about 3 vbytes per HTLC, which can be significant enough to= be worth it (consider that Taproot moving away from encoded signatures sav= es only 9 weight units per signature, i.e. about 2 vbytes). Do note that PTLCs remain more space-efficient though, so forget about HTLC= s and just use PTLCs. > > > This does not apply to current Bitcoin since we no longer accept a SCRI= PT from the spender, we now have a witness stack. > > My mental model of Bitcoin is to pretend that segwit was always there and= the separation of different sections of data is a semantic quibble. This is not a semantic quibble --- `witness` contains only the equivalent o= f `OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH` opcode= s. xref. `1 RETURN`. As-is, with SegWit the spender no longer is able to provide any SCRIPT at a= ll, but new opcodes may allow the spender to effectively inject any SCRIPT = they want, once again, because `witness` data may now become code. > But if they're fully baked into the scriptpubkey then they're opted into = by the recipient and there aren't any weird surprises. This is really what I kinda object to. Yes, "buyer beware", but consider that as the covenant complexity increases= , the probability of bugs, intentional or not, sneaking in, increases as we= ll. And a bug is really "a weird surprise" --- xref TheDAO incident. This makes me kinda wary of using such covenant features at all, and if stu= ff like `SIGHASH_ANYPREVOUT` or `OP_CHECKTEMPLATEVERIFY` are not added but = must be reimplemented via a covenant feature, I would be saddened, as I now= have to contend with the complexity of covenant features and carefully che= ck that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented corr= ectly. True I also still have to check the C++ source code if they are implemented= directly as opcodes, but I can read C++ better than frikkin Bitcoin SCRIPT= . Not to mention that I now have to review both the (more complicated due to = more general) covenant feature implementation, *and* the implementation of = `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` in terms of the covenant feat= ure. Regards, ZmnSCPxj