To: Kostas Karasavvas <kkarasavvas@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>, Christopher Allen
 <ChristopherA@lifewithalacrity.com>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
 <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com>
 <57f780b1-f262-9394-036c-70084320e9cf@peersm.com>
 <CACrqygCNf3Gv8+VjhyqS4GTb3Epo8qXEKGtQB6sqyR6ib44-fA@mail.gmail.com>
 <CABE6yHtM2Dqc63_eURSr7dMirJti5sYnqvHj7vQ_Ab9FC_d04g@mail.gmail.com>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <3d00aacb-585d-f875-784d-34352860d725@peersm.com>
Date: Sat, 4 Feb 2023 18:01:20 +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: <CABE6yHtM2Dqc63_eURSr7dMirJti5sYnqvHj7vQ_Ab9FC_d04g@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------8C4BD7752612BCCB5F7A2904"
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE
 OP_IF OP_PUSH
Precedence: list

--------------8C4BD7752612BCCB5F7A2904
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

I don't get very well where all the current (other threats) discussions
are going, storing on-chain is absurd

It's absurd also to flood bitcoin with several useless transactions to
store in witness or others, looks like ethereum messy stuff

What is not absurd is to store the proofs that can be checked using a
notorious third party/sidechain but you need more than 80B

What is the official bitcoin channel to request the OP_RETURN size
change? (press often mentions that ethereum is good to manage changes
and bitcoin a complete zero)

As a very bad solution, I think I would be willing to store data in
addresses, with one single transaction, as people did in the past, then
burning bitcoins but still not expensive, or less than several txs,
because schemes involving several transactions do not work very well

In any case, we see the problem, then people will invent something and
most likely it will not comply at all with bitcoin good practices


Le 04/02/2023 =E0 15:11, Kostas Karasavvas via bitcoin-dev a =E9crit :
>
>
> On Fri, Feb 3, 2023 at 10:17 PM Christopher Allen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     On Fri, Feb 3, 2023 at 3:52 AM Aymeric Vitte via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>         I think the right way so people don't invent deviant things is =
to
>         increase the size of OP_RETURN, I don't get this number of
>         80B, you can
>         hardly store a signature (of what?) in there and not the
>         "what" if the
>         "what" is a hash for example
>
>
>     Updating the size of OP_RETURN to support a hash (or two), a
>     signature, and maybe a few more bytes for metadata, would be very
>     helpful in a number of scenarios. It is still a limit but a
>     reasonable one. Otherwise, I think we'll have a lot more
>     inscription-style scenarios.
>
>
> I wouldn't be against an increase in OP_RETURN but I don't think it
> will make any difference in how often inscription-style use cases will
> be used. They will be used primarily for much larger datasets than,
> say 120 bytes, and they also have the segwit discount.
>
>
> _______________________________________________
> 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


--------------8C4BD7752612BCCB5F7A2904
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>I don't get very well where all the current (other threats)
      discussions are going, storing on-chain is absurd</p>
    <p>It's absurd also to flood bitcoin with several useless
      transactions to store in witness or others, looks like ethereum
      messy stuff<br>
    </p>
    <p>What is not absurd is to store the proofs that can be checked
      using a notorious third party/sidechain but you need more than 80B<br>
    </p>
    <p>What is the official bitcoin channel to request the OP_RETURN
      size change? (press often mentions that ethereum is good to manage
      changes and bitcoin a complete zero)</p>
    <p>As a very bad solution, I think I would be willing to store data
      in addresses, with one single transaction, as people did in the
      past, then burning bitcoins but still not expensive, or less than
      several txs, because schemes involving several transactions do not
      work very well</p>
    <p>In any case, we see the problem, then people will invent
      something and most likely it will not comply at all with bitcoin
      good practices<br>
    </p>
    <br>
    <div class="moz-cite-prefix">Le 04/02/2023 � 15:11, Kostas
      Karasavvas via bitcoin-dev a �crit�:<br>
    </div>
    <blockquote
cite="mid:CABE6yHtM2Dqc63_eURSr7dMirJti5sYnqvHj7vQ_Ab9FC_d04g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Feb 3, 2023 at 10:17
            PM Christopher Allen via bitcoin-dev &lt;<a
              moz-do-not-send="true"
              href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">
              <div dir="ltr">On Fri, Feb 3, 2023 at 3:52 AM Aymeric
                Vitte via bitcoin-dev &lt;<a moz-do-not-send="true"
                  href="mailto:bitcoin-dev@lists.linuxfoundation.org"
                  target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
                wrote:<br>
              </div>
              <div class="gmail_quote">
                <blockquote class="gmail_quote" style="margin:0px 0px
                  0px 0.8ex;border-left:1px solid
                  rgb(204,204,204);padding-left:1ex">I think the right
                  way so people don't invent deviant things is to<br>
                  increase the size of OP_RETURN, I don't get this
                  number of 80B, you can<br>
                  hardly store a signature (of what?) in there and not
                  the "what" if the<br>
                  "what" is a hash for example<br>
                </blockquote>
                <div><br>
                </div>
                <div>Updating the size of OP_RETURN to support a hash
                  (or two), a signature, and maybe a few more bytes for
                  metadata, would be very helpful in a number of
                  scenarios. It is still a limit but a reasonable one.
                  Otherwise, I think we'll have a lot more
                  inscription-style scenarios.</div>
              </div>
            </div>
          </blockquote>
          <div><br>
          </div>
          I wouldn't be against an increase in OP_RETURN but I don't
          think it will make any difference in how often
          inscription-style use cases will be used. They will be used
          primarily for much larger datasets than, say 120 bytes, and
          they also have the segwit discount.<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>

--------------8C4BD7752612BCCB5F7A2904--