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"
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE
 OP_IF OP_PUSH
Precedence: list

--------------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--