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 40229C002B for ; Thu, 2 Feb 2023 13:26:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1B62460BD7 for ; Thu, 2 Feb 2023 13:26:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1B62460BD7 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=lc6RZ+0J X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 EWwp-X1X4HRp for ; Thu, 2 Feb 2023 13:26:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 37F2F60B35 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp3.osuosl.org (Postfix) with ESMTPS id 37F2F60B35 for ; Thu, 2 Feb 2023 13:25:59 +0000 (UTC) Date: Thu, 02 Feb 2023 13:25:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1675344357; x=1675603557; bh=ZpX1KFZimuaC6f+hyHBc+rky2t3zLYO5IVvqxkyXDYI=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=lc6RZ+0JjBtQ5KI2QcjYP/XZjc+gnYMGAsmxsz62TL6vbV/ThPyFmRehfoh9BjMU7 hhKAuigHbeLy4EOWT49Fj29FpiwXxF3y9eJOCilgfDgu2z0t+H9AuZTHgOi7pNGIAS 27KsyPxX4SnfFL4LQb2OqO4VRGbadKDicK76uw1sslNNuRi0vjp2g08qFXPsVCysYr jTEozbJxm/vLASkTQmTL1FTNHvGkjYbVctLsg54W3a8edBY8RLYqD1DFWeXHCbyiqk mlRRhDW8IRNwrRywWXK2QWaOLDL7Sp4WYmMNaLK3EDeoEkw5T62y/zbEGUlWE643y2 BQJDYzQIgbiwA== To: bitcoin-dev@lists.linuxfoundation.org From: Rijndael Message-ID: In-Reply-To: References: Feedback-ID: 41648937:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 02 Feb 2023 13:33:02 +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: Thu, 02 Feb 2023 13:26:04 -0000 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=C2=A0OP_RETURN=C2= =A0or 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 >