+Return-Path: <aymeric@peersm.com>

+Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id AB82DC002B

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <bitcoin-dev@lists.linuxfoundation.org>;

+ 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 <ChristopherA@lifewithalacrity.com>, Bitcoin Protocol

+ Discussion <bitcoin-dev@lists.linuxfoundation.org>

+References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>

+From: Aymeric Vitte <aymeric@peersm.com>

+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: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>

+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 <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

+

+<html>

+ <head>

+ <meta content="text/html; charset=windows-1252"

+ http-equiv="Content-Type">

+ </head>

+ <body bgcolor="#FFFFFF" text="#000000">

+ <p>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?</p>

+ <p>Then the debate can be to store in witness indeed<br>

+ </p>

+ <p>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<br>

+ </p>

+ <p>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)</p>

+ <p>Storage is the main difference between bitcoin and other systems

+ (ethereum), without it, repeating myself here again the future of

+ bitcoin is very limited<br>

+ </p>

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

+ timestamp proofs<br>

+ <br>

+ <div class="moz-cite-prefix">Le 01/02/2023 � 01:46, Christopher

+ Allen via bitcoin-dev a �crit�:<br>

+ </div>

+ <blockquote

+cite="mid:CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com"

+ type="cite">

+ <meta http-equiv="Content-Type" content="text/html;

+ charset=windows-1252">

+ <div dir="ltr">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:

+ <div><br>

+ OP_FALSE</div>

+ <div>OP_IF�</div>

+ <div>OP_PUSH my64bytes</div>

+ <div>OP_ENDIF<br>

+ <br>

+ </div>

+ <div>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?<br>

+ </div>

+ <div><br>

+ </div>

+ <div>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.</div>

+ <div><br>

+ </div>

+ <div>-- Christopher Allen</div>

+ <div><br>

+ </div>

+ </div>

+ <br>

+ <fieldset class="mimeAttachmentHeader"></fieldset>

+ <br>

+ <pre wrap="">_______________________________________________

+bitcoin-dev mailing list

+<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>

+<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>

+</pre>

+ </blockquote>

+ <br>

+ <pre class="moz-signature" cols="72">--

+Sophia-Antipolis, France

+CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a>

+LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a>

+GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a>

+A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a>

+A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a>

+Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>

+Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>

+torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>

+node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>

+Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a>

+Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre>

+ </body>

+</html>

+

+--------------430033E3BED810211D22EE08--

+