To: Rijndael <rot13maxi@protonmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
 <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <57f780b1-f262-9394-036c-70084320e9cf@peersm.com>
Date: Fri, 3 Feb 2023 12:15:14 +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: <ca8622cb-445e-4258-bbac-b3ee1ce95f4c@protonmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE
 OP_IF OP_PUSH
Precedence: list

Indeed the witness envelope is more costly and less easy to use (or
read/track)

But let's take a standard P2PKH or P2WPKH output,  what prevents me from
adding in the beginning of scriptSig or witness while spending it:
OP_PUSH <data> OP_DROP ? Non standard ? This one makes one transaction on=
ly

There are probably plenty of ways to store data, another one would be to
use a dummy 1 of N multisig where only 1 corresponds to a pubkey and the
rest is data, but again several transactions...

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


Le 02/02/2023 =C3=A0 14:25, Rijndael via bitcoin-dev a =C3=A9crit :
> 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 tha=
t
> 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 it=
s
> 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 mone=
y
> 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 =E2=80=9Cneither.=E2=80=9D=
 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
>>
> _______________________________________________
> 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