path: root/c7/d27bce5ea4dcdd39768c14e171641d3f38bc2a

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.