path: root/35/848620da97a9ba957158881afa694f216dacf9

Return-Path: <aymeric@peersm.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 492B9C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 11:15:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1668C60E8E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 11:15:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1668C60E8E
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham 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 Pg1C7uTRYOCU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 11:15:19 +0000 (UTC)
X-Greylist: delayed 18:52:24 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BDA7160E80
Received: from 10.mo548.mail-out.ovh.net (10.mo548.mail-out.ovh.net
 [46.105.77.235])
 by smtp3.osuosl.org (Postfix) with ESMTPS id BDA7160E80
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Feb 2023 11:15:18 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.1.249])
 by mo548.mail-out.ovh.net (Postfix) with ESMTPS id D58762072E;
 Fri,  3 Feb 2023 11:15:15 +0000 (UTC)
Received: from peersm.com (37.59.142.98) by DAG6EX2.mxp6.local (172.16.2.52)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Fri, 3 Feb
 2023 12:15:15 +0100
Authentication-Results: garm.ovh; auth=pass
 (GARM-98R002ffc7227f-4d00-4bd2-b32c-32d69bbd2ccc,
 A2436E74214F979D91697A3B0C45FD96AA6F71C7) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.177
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
X-Originating-IP: [37.59.142.98]
X-ClientProxiedBy: DAG7EX2.mxp6.local (172.16.2.62) To DAG6EX2.mxp6.local
 (172.16.2.52)
X-Ovh-Tracer-GUID: bb5670a1-1d81-478e-b34d-f2cf4d9a7a2d
X-Ovh-Tracer-Id: 17060479813458617242
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudegtddgvddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgihesthhqredttdefjeenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepieevgffgffegffetffevfeeuudduveegjeduhfdvleeihefhjeeiteevlefgieevnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddrleeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepuddvjedrtddrtddruddpmhgrihhlfhhrohhmpeeorgihmhgvrhhitgesphgvvghrshhmrdgtohhmqedpnhgspghrtghpthhtohepuddprhgtphhtthhopegsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhrohhtudefmhgrgihisehprhhothhonhhmrghilhdrtghomhdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht
X-Mailman-Approved-At: Fri, 03 Feb 2023 11:51:56 +0000
Subject: Re: [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: Fri, 03 Feb 2023 11:15:21 -0000

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