From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 492B9C002B for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion References: From: Aymeric Vitte 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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