diff options
| author | Anthony Towns <aj@erisian.com.au> | 2025-05-12 23:47:45 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@googlegroups.com> | 2025-05-12 06:51:21 -0700 |
| commit | 87c26fdb80061e11872fa02110945b4f6d3a69fb (patch) | |
| tree | 34724d2a1f9bd8dc000d2d6626b302bbe54f7739 | |
| parent | c7ddeaccab1f521262a1c08dcdc1339f36f411f4 (diff) | |
| download | pi-bitcoindev-87c26fdb80061e11872fa02110945b4f6d3a69fb.tar.gz pi-bitcoindev-87c26fdb80061e11872fa02110945b4f6d3a69fb.zip | |
Re: [bitcoindev] Relax OP_RETURN standardness restrictions
| -rw-r--r-- | c7/d27bce5ea4dcdd39768c14e171641d3f38bc2a | 302 |
1 files changed, 302 insertions, 0 deletions
diff --git a/c7/d27bce5ea4dcdd39768c14e171641d3f38bc2a b/c7/d27bce5ea4dcdd39768c14e171641d3f38bc2a new file mode 100644 index 000000000..14c35abf4 --- /dev/null +++ b/c7/d27bce5ea4dcdd39768c14e171641d3f38bc2a @@ -0,0 +1,302 @@ +Delivery-date: Mon, 12 May 2025 06:51:21 -0700 +Received: from mail-qt1-f190.google.com ([209.85.160.190]) + by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + (Exim 4.94.2) + (envelope-from <bitcoindev+bncBDBNTKFG4EDRBQPZQ7AQMGQEHRBOPOI@googlegroups.com>) + id 1uETYu-0004XJ-77 + for bitcoindev@gnusha.org; Mon, 12 May 2025 06:51:21 -0700 +Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-4766afee192sf132523771cf.0 + for <bitcoindev@gnusha.org>; Mon, 12 May 2025 06:51:20 -0700 (PDT) +ARC-Seal: i=2; a=rsa-sha256; t=1747057873; cv=pass; + d=google.com; s=arc-20240605; + b=YDV5xnbS+ruO+NgZR0gfDzSmP8gtHTSjw4nA7PK6BptMZZNQFqksv+2UUH4dXqzVo5 + o61Qsd3PlWchUgMGok+dhseX8rfRob/k2O+vcveNMz1uqrNhcPHZVZZ9kGOYp6Bycsxi + EdPu3Dy62WsHyl6WmuirZPsCaxl8PAmGnzNi90ChY54lQYc/jiyRNbkElB462+LksmfP + 7RZFAFIg2rgtzZFMxNar2SESSIaI8x3p/7QHf35QzN/kbYQP1BpMrLLbhHO3hoYlj7xD + piqpflwyRFA2p2Cs9hj4mNmkKTthfeb7SLFuuzepl4IQIPPggQaNmdoaHo50K6UR5XrJ + LzTw== +ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:content-transfer-encoding + :in-reply-to:content-disposition:mime-version:references:message-id + :subject:cc:to:from:date:sender:dkim-signature; + bh=QDbjRuG2aMB6knbNc4D6mlIe/BUvDTVABMGC9F5lWyk=; + fh=PY38Xtzn5Fz/o0IPQ1CcM2nf6op82FL3Obvj7rcRj5E=; + b=TDz2u78IHDiu+KumnGRbuW5RVk1ivWcmux0fYELCS4Z6klaNLub+enlcowwf0uTp9z + ckfY+X0wPJl9z3vqaIt2BDjFBlpCaJljl1iI46vc/VMPGx97oe/2hS/W/89WmRaR8Lze + vWCABqHCdYG7J1Ttt0Q0UGW2iSv3tM7IOt/y1TK17i9q4oVdyzRlY4+gF3lZd89Ncj4C + gsTGyt8/eWKMsXcksIsoHyE1N1QeWqWPtXpJTeQECTOdZr2Zdndwe48Q1zebYet1o/OA + Tq0K6dDAnOI6ND+YoQvcHv+S4luhLz+wNYKpvQlWko4EEcrgviLgJ2RYsq9LKmlEvR4H + 7Z9g==; + darn=gnusha.org +ARC-Authentication-Results: i=2; gmr-mx.google.com; + spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=googlegroups.com; s=20230601; t=1747057873; x=1747662673; darn=gnusha.org; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:content-transfer-encoding + :x-original-authentication-results:x-original-sender:in-reply-to + :content-disposition:mime-version:references:message-id:subject:cc + :to:from:date:sender:from:to:cc:subject:date:message-id:reply-to; + bh=QDbjRuG2aMB6knbNc4D6mlIe/BUvDTVABMGC9F5lWyk=; + b=VBrhsHQV9d6h9tO2Ycr0l80SYWOPjJ5LQl5eR0WHBrHIwc2j0DEyIC95ZFp+sGou9D + O3suzmol4hGdAQrKdDEVv/h7Wz9Ba8P2qU5fZJlyq2zQEchuPaVa/8RTMq+xdDuhYLSO + peFnRPq3p3pws39lfucRw/iBIkX99gm5KQWwjjiPK1dQy2zN3IFCA08veGaI+wgbXScv + sJiDTh/qyH2XLiM2MIfck3j5rVWU/3OMw7othZ4/hV5aI91RQdJ8itTvl2LwX65xjVVy + OjU3oehI6NLdwflGz9ZS6VkCGwT1DWmlXlRn3dZPt80/MM+VmXivCzvpboudEmDwaqEk + 5eQA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1747057873; x=1747662673; + h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post + :list-id:mailing-list:precedence:content-transfer-encoding + :x-original-authentication-results:x-original-sender:in-reply-to + :content-disposition:mime-version:references:message-id:subject:cc + :to:from:date:x-beenthere:x-gm-message-state:sender:from:to:cc + :subject:date:message-id:reply-to; + bh=QDbjRuG2aMB6knbNc4D6mlIe/BUvDTVABMGC9F5lWyk=; + b=rV8zh9odpW2AKFYjZEIE6ET48s8fHLLk31Y8OrvbensfOlliuJEogUGaddn9Hjj3I7 + SHHOAB+PVHklQeIuFeidQtNUujcsm2B+eTWBnTO99kaKxVeM8dy3v6EL0DUdUOhGCEwy + cnmGL2fYO31m1gMIE2gdsAg25aHnfqoG2ThpKZn/B2go2tjjZDrJOOFj9AXPzlZl/FZN + eh6bRIWWINyRGwynJ5zuW0uxSvgz2ufUTjGU6ZcHYvCNqw6KH5c7qhA+dOQdoLa25q2h + CMJouHCZGQbxjn6BjTQQC89hu/GMlnrGNzbEbg1Y80I3VBzMxUlN9FFj9xMEuknPFTGv + w79w== +Sender: bitcoindev@googlegroups.com +X-Forwarded-Encrypted: i=2; AJvYcCV07LQS3G/DEaLvCNo+dOLdXP7LgZOkYT6zqDKxDWfnyrr1bYn/8FcJhlWk7KnnEyc9K3dWSYj5tQcH@gnusha.org +X-Gm-Message-State: AOJu0YwyZxZ7CXB79KWQVIgYNk7KZbaISRCIu2tPI1P4X83UczSnHnff + Zeo1GQvodI6MxPi6qhDCsqDw9w+UZCsSI4YWjsxzcW/2vHgr83fP +X-Google-Smtp-Source: AGHT+IFktvPMQgR/kEF4gYWHW7/x1Z/ONGA6jHtzfh3OdnIMiCOQtOhLwcMZLd8bWGQAlqQZ9xIDlA== +X-Received: by 2002:ac8:5fce:0:b0:476:b06a:716e with SMTP id d75a77b69052e-494527df73bmr217594591cf.34.1747057860424; + Mon, 12 May 2025 06:51:00 -0700 (PDT) +X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEwAA+jDtlse7YwAQP6sN9KVicdVXt43vNF5Onnd/9Emw== +Received: by 2002:a05:622a:a008:b0:47a:e5d0:12f with SMTP id + d75a77b69052e-4944949ad03ls5484161cf.2.-pod-prod-04-us; Mon, 12 May 2025 + 06:50:57 -0700 (PDT) +X-Received: by 2002:a05:620a:1794:b0:7c7:a5ce:aaf1 with SMTP id af79cd13be357-7cd01144905mr2125130685a.35.1747057857684; + Mon, 12 May 2025 06:50:57 -0700 (PDT) +Received: by 2002:a05:620a:8216:b0:7c5:50d5:7703 with SMTP id af79cd13be357-7ccfa178a37ms85a; + Mon, 12 May 2025 06:48:34 -0700 (PDT) +X-Received: by 2002:a05:622a:1c08:b0:494:79c9:91e8 with SMTP id d75a77b69052e-49479c991f9mr52097021cf.28.1747057675829; + Mon, 12 May 2025 06:47:55 -0700 (PDT) +ARC-Seal: i=1; a=rsa-sha256; t=1747057675; cv=none; + d=google.com; s=arc-20240605; + b=Dqu3CKlR9U8ankMN5dUDGqgJzpwxVbdkFNxmAfK2ng6ZeOvJSjiCNikR5MXOc/heB/ + IGzUAwKp0MJlXb5GQ8cCsedHs/NSmT8/GFAPg4K7NVx928kWdRLRnn6M9HBQXvR5GEfa + PZtco4gpvTIaqd5JWuaQXqb1Ya1OecHY77SYQchMCnEN/xPHUdB8wqmbxHxKP021C7Rr + Mye+zczccWObQxw+kafraSuTLfzKoD6xK1efR+ebUkVbFe7knMsefeDJfzIa6GSTbThQ + woJx+dhXOEHo7NFcWNQUR/mOWYCs5yn/UwDi8NbkOw2DxuhBBBQvFfgzgXTaB2LWxjdJ + 5gAw== +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; + h=in-reply-to:content-disposition:mime-version:references:message-id + :subject:cc:to:from:date; + bh=uhZvOjZiVP4cKKBaVh2ioKNGGWaBXI98bbPtEJ55pVI=; + fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=; + b=laMKb4eRw8Z/Wpt30cK/NWGfQHU2D3YtV6B3RpJlZ+d3CfJe9dpwZv+LsdrEYldslA + IKtS9/JDYGmsmbRaU8eBWPkYZ6k8LqbcSGaGBr77DC/+zFXBVjtP8EHFOY+Es9o6UU0F + DaJYNAEwDmwRlauGQ6mbD6ZtWmmSuXX++rfyGJM9B+WRa63t7ooh91h2FdYDiAQApKId + lR76cpZHdE/bJuFD23BLICg3RHBkzibrmkKQgb7jhR/Rjtdv5+wMlFV20qckMejvlwOo + GmozwA+giJErpq49TdOA1Ks+HlzqU/mOt1SRrbo8WyXAx7gD9iYshcQw3NqX1gQgPW5/ + Ckuw==; + dara=google.com +ARC-Authentication-Results: i=1; gmr-mx.google.com; + spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au +Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) + by gmr-mx.google.com with ESMTPS id d75a77b69052e-4945246b37dsi2888821cf.1.2025.05.12.06.47.55 + for <bitcoindev@googlegroups.com> + (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); + Mon, 12 May 2025 06:47:55 -0700 (PDT) +Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; +Received: from aj@azure.erisian.com.au + by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + (Exim 4.96) + (envelope-from <aj@erisian.com.au>) + id 1uETVU-0002ZD-1n; + Mon, 12 May 2025 23:47:50 +1000 +Received: by email (sSMTP sendmail emulation); Mon, 12 May 2025 23:47:45 +1000 +Date: Mon, 12 May 2025 23:47:45 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Antoine Poinsot <darosior@protonmail.com> +Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com> +Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions +Message-ID: <aCH8AdZeBAc0UVfT@erisian.com.au> +References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset="UTF-8" +Content-Disposition: inline +In-Reply-To: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com> +X-Spam_score: -0.0 +X-Spam_bar: / +X-Original-Sender: aj@erisian.com.au +X-Original-Authentication-Results: gmr-mx.google.com; spf=pass + (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as + permitted sender) smtp.mailfrom=aj@erisian.com.au +Content-Transfer-Encoding: quoted-printable +Precedence: list +Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com +List-ID: <bitcoindev.googlegroups.com> +X-Google-Group-Id: 786775582512 +List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com> +List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com> +List-Archive: <https://groups.google.com/group/bitcoindev +List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com> +List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>, + <https://groups.google.com/group/bitcoindev/subscribe> +X-Spam-Score: -0.8 (/) + +On Thu, Apr 17, 2025 at 06:52:34PM +0000, 'Antoine Poinsot' via Bitcoin Dev= +elopment Mailing List wrote: +> Bitcoin Core will by default only relay and mine transactions with at mos= +t a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. T= +his standardness rule falls into the third category: it aims to mildly dete= +r data storage while still allowing a less harmful alternative than using n= +on-provably-unspendable outputs. +>=20 +> Developers are now designing constructions that work around these limitat= +ions. An example is Clementine, the recently-announced Citrea bridge, which= + uses unspendable Taproot outputs to store data in its "WatchtowerChallenge= +" transaction due to the standardness restrictions on the size of OP_RETURN= +s[^0]. + +The reason for limiting OP_RETURNs to 80 bytes of data is to encourage +developers to store hashes on the chain, rather than the actual +data. Why store 1GB when you can commit to it with a 32B hash, and save +99.9999968% in fees? In all this debate I haven't seen an analysis of +other alternatives Citrea/Clementine might use, rather than storing 144 +bytes of data on chain. + +As I understand it, the context in which they're using the data is the +following protocol: + + * we have three known groups: Operators, Watchtowers and Signers + * we also have: Users and Challengers (who can be anyone) + * we assume that there is at least 1 honest Operator, 1 honest Watchtower, + 1 honest Signer, and 1 honest Challenger, and >50% honest hashrate + +When things go wrong, and one of the Operators tries to cheat, one way +they can do so is by publishing a claim that they posted a transaction +in a Bitcoin block that's not actually in the Bitcoin block chain. At +that point, an honest Watchtower observers the claim, and produces a +Groth16 proof that he has a more-work chain that does not contain the +block claimed by the Operator. + + * but what if the Operator was honest and the Watchtower was trying to che= +at? + + * in that case, the claimed Groth16 proof can be evaluated via a sequence = +of + transactions following the BitVM and will be found to be invalid + +The Groth16 proof/evaluator here is acting as a light client (doing +header only evaluation), but with even less data than a traditional +light client -- it only needs the Groth16 proof, not the ~40MB of data +from all the block headers. While 40MB of data isn't much for a phone +or raspberry pi or similar, it is a lot if you need to manually provide +it to a BitVM program. + +Because the Watchtower here may be dishonest, they can't just be expected +to publish a hash of their proof -- nobody else can generate the exact +same proof they would without their random inputs, and publishing their +random inputs as well as a commitment would also be more than 80 bytes. + +Possibly a protocol like the following could work, however: + + * Operator claims block X with work W had the relevant tx + * Watchtower observes block Y with work W+A does not include X in its his= +tory, + waits until Y has 6 confirmations, and publishes Y's block hash and W+A + * Challenger: + - observes block Y, generates their own Groth16 proof that X is + not in Y's ancestor set, and verifies this via BitVM, penalising + the operator + - observes block Z with work W+2*A with X in its ancestry but not + Y, generates their own Groth16 proof for that, verifies this via + BitVM, penalising the watchtower + - observes block Z with work W+2*A with neither X nor Y in its + ancestry, generates their own Groth16 proof for that, verifies + this via BitVM, penalising the watchtower + +This process is only triggered if either the Operator or Watchtower is +dishonest, and in that case it's likely the full BitVM protocol will +also be triggered, so the potential for a ~100 byte saving is probably +just lost in the noise. + + + +However the point of all this is just to find a way of ensuring that the Op= +erator +publishes a block hash that's actually in the block chain. But knowing what= + block +hashes are in the block chain is something bitcoind is already pretty good = +at, +so we could do that pretty differently. eg, Consider the hex string + + 50 01 24 030c3500 00000000000000000002a7c4c1e48d76c5a37902165a270156b7a8d= +72728a054 + +A string like that could be interpreted as: + + * this is an annex entry + * of type 1, "per-input height lock" + * data length 36 bytes + * 3-byte int, value 800,000 + * 32-byte hash, the block hash of block 800,000 + +And a consensus rule could be added that the presence of a type 1 annex +entry means a transaction is invalid unless the given block height +has been reached, and the hash of the block at that height (ends with) +the provided bytes. + +That would ensure that the Operator's transaction does provide a real block +hash, which I believe is all that the Groth16 proof in question achieves. + +I think that's probably sufficient for this use case -- you'd pull the +Operator's tx from the blockchain, then provide it to a BitVM program, +which would verify the witness was signed by the Operator, that the annex +data is of the appropriate length, and then go on to use the block hash +for further computation, presumably establishing some transaction is +included in the block by evaluating a merkle path. So that would remove +both the need to include the 144B groth16 proof, but would also avoid +an entire BitVM evaluation. + +Having an annex entry acting as a per-input height lock seems somewhat +useful in general, and might, eg, allow multiple lightning payments to be +timed out in a single transaction, which might be nice. Being able to +commit to the block hash of your height lock is potentially useful when +dealing with controversial soft forks, hard forks, chain splits, or large +reorgs; as you can use the commitment to make a spend only valid on one +chain or the other yourself, rather than needing to try a double spend +race against yourself or collaborate with a miner to mix a new coinbase +output with your coins. + +I think doing that via structuring the annex should be pretty feasible, +as a small number of unconditional contextual assertions from a well known +location in the traction should be easy to extract and operate on, in +the same way we treat tx's nVersion, nSequence and nLockTime time today. +In particular that sort of assertion can be validated independently of +executing scripts, which should make working out if a tx can remain in +the mempool after a reorg more straightforward. + +Embedding it via an opcode in script seems somewhat more dangerous in two +ways -- you don't know which block hashes a script might reference until +you run the script (so have to give the script interpreter access to all +the blocks), and to cater for reorgs will need to track the most recent +block hash a script references and store that in the tx's mempool entry. +Those aren't impossible to deal with, but it seems better to me to have +keep the information that scripts can use as computation inputs very +local to the transaction being processed. + +References: + - https://citrea.xyz/clementine_whitepaper.pdf + - https://x.com/0x_orkun/status/1918009290326950147 + - https://gnusha.org/pi/bitcoindev/20220305055924.GB5308@erisian.com.au/ + +Cheers, +aj + +--=20 +You received this message because you are subscribed to the Google Groups "= +Bitcoin Development Mailing List" group. +To unsubscribe from this group and stop receiving emails from it, send an e= +mail to bitcoindev+unsubscribe@googlegroups.com. +To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= +aCH8AdZeBAc0UVfT%40erisian.com.au. + |