From: Rijndael <rot13maxi@protonmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Date: Thu, 02 Feb 2023 13:25:41 +0000 [thread overview]
Message-ID: <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com> (raw)
In-Reply-To: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
Hello Christopher,
I think if the protocol that you were designing always had <80 bytes,
I'd prefer the OP_RETURN. I think the "witness envelope" has two major
disadvantages compared to the OP_RETURN method:
1. You need to first spend to he address that commits to the script that
encodes your data payload. So you have a two step process of first
spending to a "commitment" address and then a second spend to "reveal"
your payload. You can CPFP to get them both into the same block, but its
still two transactions, so more cost, etc.
2. Because of the two step process in (1), if for some reason you were
unable to get the "reveal" transaction into a block (for example there's
widespread censorship of transactions that match the format of the
"reveal" script), then you might have money that's stuck in the "commit"
stage of the protocol. The way out of this would be to get your money
out via the keypath or another tapleaf, but then you need to spend money
to cancel a step in your protocol. Of course there could be widespread
censorship of your OP_RETURNs too, but you don't have to spend funds on
the cancellation spends.
I think (2) is actually a pretty weak argument because as we saw in the
full-rbf discussion, as long as there's some threshold number of nodes
in the network that relay transactions to miners, you can probably find
a path to a miner (IIRC the number was on the order of 15% of the
network?). So I think the big reason to pick OP_RETURN over the witness
embedding is that you save a transaction and possibly some
failure-recovery/cancellation logic.
Obviously if your data is larger than 80 bytes, then you probably want
to do the witness-embedding method. If your data smaller, then a
pay-to-contract tweak probably the best thing from a space and
fingerprinting perspective.
- rijndael
On 1/31/23 7:46 PM, Christopher Allen via bitcoin-dev wrote:
> 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
>
next prev parent reply other threads:[~2023-02-02 13:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 0:46 Christopher Allen
2023-02-01 2:07 ` Peter Todd
2023-02-01 2:22 ` Christopher Allen
2023-02-01 8:36 ` Kostas Karasavvas
2023-02-01 12:51 ` Peter Todd
2023-02-01 14:02 ` Andrew Poelstra
2023-02-02 11:22 ` Peter Todd
2023-02-02 11:45 ` Aymeric Vitte
2023-02-02 11:49 ` Peter Todd
2023-02-02 12:24 ` Aymeric Vitte
2023-02-01 12:59 ` Aymeric Vitte
2023-02-02 13:25 ` Rijndael [this message]
2023-02-03 11:15 ` Aymeric Vitte
2023-02-03 18:47 ` Christopher Allen
2023-02-04 14:11 ` Kostas Karasavvas
2023-02-04 17:01 ` Aymeric Vitte
2023-02-04 18:54 ` Christopher Allen
2023-02-04 20:55 ` Aymeric Vitte
2023-02-04 22:18 ` Christopher Allen
2023-02-04 23:09 ` Aymeric Vitte
2023-02-05 0:04 ` Peter Todd
2023-02-05 11:40 ` Aymeric Vitte
2023-02-05 12:06 ` Peter Todd
2023-02-05 12:47 ` Aymeric Vitte
2023-02-05 0:11 ` Russell O'Connor
2023-02-05 2:01 ` Peter Todd
2023-02-05 18:12 ` Russell O'Connor
2023-02-12 16:23 ` Aymeric Vitte
2023-02-16 18:23 ` Aymeric Vitte
2023-02-16 19:59 ` Claus Ehrenberg
2023-02-17 10:56 ` Aymeric Vitte
2023-02-05 18:06 ` Andrew Poelstra
2023-02-17 12:49 ` Anthony Towns
2023-02-18 18:38 ` Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com \
--to=rot13maxi@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox