From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A5528C002B for ; Wed, 1 Feb 2023 02:07:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7544060D61 for ; Wed, 1 Feb 2023 02:07:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7544060D61 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=S9d3J6XX X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 w489kxGPoq6y for ; Wed, 1 Feb 2023 02:07:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 00BC660A9B Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by smtp3.osuosl.org (Postfix) with ESMTPS id 00BC660A9B for ; Wed, 1 Feb 2023 02:07:19 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6C9305C0126; Tue, 31 Jan 2023 21:07:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 31 Jan 2023 21:07:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1675217237; x=1675303637; bh=e Z4oyliyffnoUeaOz42UTtNmKBn2dPkJm6kNXT0GwYg=; b=S9d3J6XXfbRl1d9nn czr00swsTyODii3AjP9sSwussOQE/haxHp4Zcwy82cIDgHLwh/wUlvzfCSKKYxwx Tf3rZaACwjBv7I1rZSxNSFEUR2mfaStLxVsDqh1YnQvXMOnJxqzZrbMNUy++qJXC +fcBA5sQuNK5HA/HzyWSKATyLkIrfto0a68mxkOsEwNeR9vrRz2ofxe+WUY/dkSl bcBYlFrirrpqTbUTzsuluhwtHA3oTALNk6MHY6cttCd/CjT7dNP6V344+WZdRGbP 6FvInWSERuUpB7Ry6yTkqTc6t+nEjjdNY8FktCEjaEyR7l94TQDyZ86a+Oivr8+C bcazg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefhedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffufggjfhfkgggtgfesthhqmhdttderjeenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpefhteeuleffvddujeejteejjefgjeefleeiieejudeiiedvueegffefueeglefg ueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvg htvgesphgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 31 Jan 2023 21:07:16 -0500 (EST) Date: Tue, 31 Jan 2023 21:07:16 -0500 From: Peter Todd To: Christopher Allen , Bitcoin Protocol Discussion , Christopher Allen via bitcoin-dev User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH 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, 01 Feb 2023 02:07:21 -0000 On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev wrote: >All other things being equal, which is better if you need to place a >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent >taproot transaction such as: > >OP_FALSE >OP_IF >OP_PUSH my64bytes >OP_ENDIF What's wrong with OpPush OpDrop? >I know that the anti-OP_RETURN folk would say =E2=80=9Cneither=2E=E2=80= =9D But if there was >no other choice for a particular protocol, such as a timestamp or a >commitment, which is better? Or is there a safer place to put 64 bytes th= at >is more uncensorable but also does not clog UTXO space, only spent >transaction `-txindex` space? > >My best guess was that the taproot method is better, but I suspect there >might be some who disagree=2E I'd love to hear all sides=2E An important consideration with using taproot is that you need to have the= data you are committing too to be able to to spend the txout in the future= =2E OpReturn doesn't have that problem, meaning that in a situation like a = hard drive failure, you can still recover the funds from a wallet seed=2E Also, it is incorrect to say that OpReturn outputs "clog UTXO space"=2E Th= e whole point of OpReturn is to standardize a way to keep such outputs out = of the UTXO set=2E There is the 75% discount to using witness space=2E But = considering the size of a transaction as a whole using taproot instead of O= pReturn doesn't save much=2E Finally, _64_ bytes is more than a mere 32 byte commitment=2E What specifi= c use case do you actually have in mind here? Are you actually publishing d= ata, or simply committing to data? If the latter, you can use ECC commitmen= ts and have no extra space at all=2E