Return-Path: <christophera@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B5EBDC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:47:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 90C9260DB7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:47:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 90C9260DB7
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=lifewithalacrity-com.20210112.gappssmtp.com
 header.i=@lifewithalacrity-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=SkYJQIGB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 Dj-r5TdDIt50
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:47:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6181E60D91
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6181E60D91
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  1 Feb 2023 00:47:12 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id u12so16373608lfq.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Jan 2023 16:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=lifewithalacrity-com.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=A1mdRAX1rY8dEeXsRRkOlPPXly8souQq5sgwhqEWzCk=;
 b=SkYJQIGBcpXBNkJOAXCPJ9StSKE3vpAJTs5W/7Ya2Vs2E3Hwu3U87ECuTi57hEtZZW
 y6nC9ZBeV+L61BDeQWVXPl1WcTdZRoLopXOYaGLUGd3HDaihho9il+t/rE5JomvkE2cO
 ju0GJElimfqY9TwBBKf2dVKb8wNbs/oJhyMf0Bd84bHgQZZM+oahbTS5pECIHpHOHrlr
 1/vaf5W9huga3WtfD3KRKbzRbft2viH+Of42C5p3vMlTWtvI44hfu7uXctsne9I95FVb
 K89EjMu8oRRcQxt2/r7ghOxmOm3V2a7t7XF8DLbVhsYxQ2Gw+oXYjpXf7B6XqHjdi/91
 WGAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=A1mdRAX1rY8dEeXsRRkOlPPXly8souQq5sgwhqEWzCk=;
 b=D6Wfvt+lERyJHAcbu9B+4Q9Y/82iYluIhNLCBRMUhRmnym1DJTFupOWZ2T1IR/W3fz
 TNzmQCU7u/YLJsGB14V+KE4BG24bHaHHo3DIQtAxUN5UwrEjf3y/boyPwZY97hG8M46c
 mnuIAxIdA2lVCHLB2BOPGCvJ5GtWaXzQf6xFOqVcQ49N48i1BlE4B5rDSDmFJEs23syw
 RzFsWgukdp7eUJcwZe3iPM1A7VOerHBiBg8eufCTEPRvG1AYru3McUwWR1/eLRtFaspq
 tScgf65DEMRN0Ywowe0Yv+kKswiTWwUo8NrJNFCvngWhfLAZC9WHFFmw0LeVKEnLp2OI
 m20Q==
X-Gm-Message-State: AO0yUKVu508KSNuPaX3i5iK+w/C4pb+P8vbT6w0dYmUCPFmIMREu59V8
 qRCq0883L0nwf7wJmRDiiOuDYc0bFt5A/VHpocNuqSV31OxM9w==
X-Google-Smtp-Source: AK7set+0GILDBe+K8s35SAWbmWvbnWiwRpfiotrw2jB1KVX+tcKg7kDydzw91hVb58qoHFOsyglnV6E867Vn8CMhhCA=
X-Received: by 2002:a19:ae0d:0:b0:4d0:7b7:65dc with SMTP id
 f13-20020a19ae0d000000b004d007b765dcmr32986lfc.122.1675212429520; Tue, 31 Jan
 2023 16:47:09 -0800 (PST)
MIME-Version: 1.0
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Tue, 31 Jan 2023 16:46:32 -0800
Message-ID: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c8f74905f398c905"
X-Mailman-Approved-At: Wed, 01 Feb 2023 01:23:24 +0000
Subject: [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 00:47:13 -0000

--000000000000c8f74905f398c905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=9Cneither.=E2=80=9D Bu=
t 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

--000000000000c8f74905f398c905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">All other things being equal, which is better if you need =
to place a 64-bytes into the Bitcoin blockchain? A traditional=C2=A0OP_RETU=
RN=C2=A0or a spent taproot transaction such as:<div><br>OP_FALSE</div><div>=
OP_IF=C2=A0</div><div>OP_PUSH my64bytes</div><div>OP_ENDIF<br><br></div><di=
v>I know that the anti-OP_RETURN folk would say =E2=80=9Cneither.=E2=80=9D =
But if there was no other choice for a particular protocol, such as a times=
tamp 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 spe=
nt 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 w=
ho disagree. I&#39;d love to hear all sides.</div><div><br></div><div>-- Ch=
ristopher Allen</div><div><br></div></div>

--000000000000c8f74905f398c905--