From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AB82DC002B for ; Wed, 1 Feb 2023 13:05:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6673D81E58 for ; Wed, 1 Feb 2023 13:05:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6673D81E58 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bphm3WHmXicx for ; Wed, 1 Feb 2023 13:05:07 +0000 (UTC) X-Greylist: delayed 18:28:36 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6C92A81E30 Received: from smtpout2.mo529.mail-out.ovh.net (smtpout2.mo529.mail-out.ovh.net [79.137.123.220]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6C92A81E30 for ; Wed, 1 Feb 2023 13:05:07 +0000 (UTC) Received: from mxplan6.mail.ovh.net (unknown [10.108.16.148]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 5F0492149A; Wed, 1 Feb 2023 12:59:38 +0000 (UTC) Received: from peersm.com (37.59.142.102) by DAG6EX2.mxp6.local (172.16.2.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Wed, 1 Feb 2023 13:59:37 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-102R0045db72702-ae84-4ad4-9653-9fb806f3d46b, 9CED2DE8798109C3417E59800AD64CD0B4D4E981) smtp.auth=aymeric@peersm.com X-OVh-ClientIp: 92.184.100.26 To: Christopher Allen , Bitcoin Protocol Discussion References: From: Aymeric Vitte Message-ID: <3e649ce0-f468-f4b4-d774-bc8d5a6ee0f8@peersm.com> Date: Wed, 1 Feb 2023 13:59:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------430033E3BED810211D22EE08" X-Originating-IP: [37.59.142.102] X-ClientProxiedBy: DAG5EX1.mxp6.local (172.16.2.41) To DAG6EX2.mxp6.local (172.16.2.52) X-Ovh-Tracer-GUID: 00eef9af-86fa-4704-92b9-cd47ebf38218 X-Ovh-Tracer-Id: 7077969766689825690 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefiedggeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveduhefgudefhffghfdvleetfffhiefhkeefvddtgedvhfdvffdvvdetuedtgeegnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpvehhrhhishhtohhphhgvrhetsehlihhfvgifihhthhgrlhgrtghrihhthidrtghomhdpoffvtefjohhsthepmhhohedvledpmhhouggvpehsmhhtphhouhht X-Mailman-Approved-At: Wed, 01 Feb 2023 14:08:38 +0000 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 13:05:09 -0000 --------------430033E3BED810211D22EE08 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Could someone clarify what is the standard for OP_RETURN? As far as I understand the data is limited to 80B and only one OP_RETURN is allowed in one transaction, if not the tx is non standard, correct? Then the debate can be to store in witness indeed Or you can store in output addresses (with super big size), then you will never be able to spend the dust and we have a utxo forever In any case there is a storage workaround, probably others exist, not sure why people are so opposed to a OP_RETURN bitcoin storage (I thought the max size was 512B, but apparently I am wrong, 80B is ridiculous, can't do anything with this, except bypassing this limit by other worse means) Storage is the main difference between bitcoin and other systems (ethereum), without it, repeating myself here again the future of bitcoin is very limited PS: I saw the answer of Peter, I am proposing something else for timestamp proofs Le 01/02/2023 =E0 01:46, Christopher Allen via bitcoin-dev a =E9crit : > 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=20 > OP_PUSH my64bytes > OP_ENDIF > > I know that the anti-OP_RETURN folk would say =93neither.=94 But if the= re > 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 that 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. I'd love to hear all sides. > > -- Christopher Allen > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=20 Sophia-Antipolis, France CV: https://www.peersm.com/CVAV.pdf LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 GitHub : https://www.github.com/Ayms A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ay= ms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b= eed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac= tions torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor Anti-spies and private torrents, dynamic blocklist: http://torrent-live.p= eersm.com Peersm : http://www.peersm.com --------------430033E3BED810211D22EE08 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit

Could someone clarify what is the standard for OP_RETURN? As far as I understand the data is limited to 80B and only one OP_RETURN is allowed in one transaction, if not the tx is non standard, correct?

Then the debate can be to store in witness indeed

Or you can store in output addresses (with super big size), then you will never be able to spend the dust and we have a utxo forever

In any case there is a storage workaround, probably others exist, not sure why people are so opposed to a OP_RETURN bitcoin storage (I thought the max size was 512B, but apparently I am wrong, 80B is ridiculous, can't do anything with this, except bypassing this limit by other worse means)

Storage is the main difference between bitcoin and other systems (ethereum), without it, repeating myself here again the future of bitcoin is very limited

PS: I saw the answer of Peter, I am proposing something else for timestamp proofs

Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit :
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

I know that the anti-OP_RETURN folk would say “neither.” 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 that 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. I'd love to hear all sides.

-- Christopher Allen



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


-- 
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
--------------430033E3BED810211D22EE08--