From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 07 Oct 2025 02:38:47 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v649e-0007ZC-R0 for bitcoindev@gnusha.org; Tue, 07 Oct 2025 02:38:47 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-35568e6088asf9632574fac.0 for ; Tue, 07 Oct 2025 02:38:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759829920; cv=pass; d=google.com; s=arc-20240605; b=jZhr7VKYjkhhI4ZjdZT9vymXnCknCLeWbppq4eQIIcbebN2cpUXgDbBExlzJ02YrVr N3H2b3QQL5SEOKfi0R4LoLvdoU/6yXCttZ07+utmh7bfNNHgM0lRWI/tz7aMJQIl+/FE m/wT6YlQQGNy/wo7aqdyZ0N3VcJOlyKmjKb/KdVr1KSWLDEYTucEV5vsiqIPdVCQ1+gf jYmWkMtNxKOlzG3as9FoQdRMN6Jj1QROqs6DsREwI3SQwaIlU8tOTRXkpvfzIYZrZ2YL c8yI3VHuRhDtigjHiSqkLxzzjQKrtCpAJOiAsvYg4owiGT11V+jXjd1xxbjsn7M5njLv KuMA== 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:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=ip2ZedjhSf3v3W9YSh97QY/IknujYedXrEXYIi8VHFU=; fh=9tRK+jZtuUW14+YEJSq2LO8NI/FxKBVzA6qJKVvp6Y8=; b=iYH02IpdHLsyktB/g7j8AlUXvWMp6DLBrCvZVRWwYFHZ6f8vyW5CxfJzjMtIHLrSk2 L+QPA0nfpXodc5ydXo/Zky4Dq5qE4WorkQLNG440TBKqHCGCaIX7nCkoWAdLze59YJie XbZroUWHe2dwwWLToG66WabquUuiueY+uN23w7To0DOSfSKNnMxPwuIw23uJpCPkNR6l EyH/Ynry5GWsQ+CsndSEFkWY1UHE823kHmPLSzvMFakie60rwHiien28jZcxIHCr//b4 /3r3t3tIGK8iD64RQ9Rs1oclZRBqyG9NFhkZ686U7ughlhhIezarmginqYNVBalrM7xk 0nBA==; 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=1759829920; x=1760434720; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=ip2ZedjhSf3v3W9YSh97QY/IknujYedXrEXYIi8VHFU=; b=Muj2dh8AlW16W2NigoLwKxz55HVE3Z9qr/POslSChh7hbMQMYZx9KyJBeTH4gy3riC bdR88VJf2mxJQnMHu5gfGoRWi2Jdb7y6Mia01Heazxbdu7OijkzvDJ5IGZMWjO31+Eqp sx0bAn/hZjfCHm0EpjPhYeB5+RfPB4MUg4xpIRmBGnjw6Hhjti+kceRnsasY/8fR2525 EsZN2CY+axKaU1aU5miahMTzrbYTYLyZ0yy6+VgsWTPTjLl9UFH2qcODIeCAw0mwGIKR Psu6nYDX/rm86Z9MA3Zgg1MA2wAK9Yr2lt8nP5Ni4sYw1odpjUorCQu/sqz7WdpgR8Wx OTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759829920; x=1760434720; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence: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=ip2ZedjhSf3v3W9YSh97QY/IknujYedXrEXYIi8VHFU=; b=Fuw15S59KL4dqJjl3AJn4DYwBJYdaEdPhORptGa8HLOcs1QFbBpIp5PDnLqhnIiTeN 57SSqdsuhSpWpc0QfGE+Md4N7H6IMWNq4OgofDRspeTQOI253GKm9hIFiBLiHdkzPzB2 cV2JxxlkTxK/hgA0KmpfGze19WGvLcacL8TISxAq8J3oHvMWkK4Te+ee8iO9Cr6n9lJ/ 108l8Gab/3Q6muEEaQa0z0bXKtsGWsghKp8DOsTDvd+5MIxd4eJgmlGncBEjsWD5QVM7 /iGbk8i06EfP17KqrPL4o3I+IsdPZW2jf42v5fPd4W3F8BGkFvCosdYIjjPAdTADIklG eDuQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWU6j2NWP6fidNzYYKUy1e4NICnqkbQBVWl15FcaxfHxfXG3ADJyYOyk9UPgKC7YuziJrOLrSQdT08H@gnusha.org X-Gm-Message-State: AOJu0Yzcbbf9GtGSb70Rd4aXLQxJWAWKzQFLmujpXgWAz6um5+uFJIaQ N9ulIIwOhrGXQxq6Rp+K4+IWo10hI6bRoS34YwOdmG3ClNYm4lXWX0c1 X-Google-Smtp-Source: AGHT+IHxTEiydNhSUEOlJn+a7O/O1N9M5CZSk2MDiZR1CyJCraKQnfqOZgInxobdxa7C0BJ5/KWHyQ== X-Received: by 2002:a05:6870:80cb:b0:340:d6f1:4165 with SMTP id 586e51a60fabf-3b0f51c06f4mr7882118fac.19.1759829920108; Tue, 07 Oct 2025 02:38:40 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5AQwreWWpstzNwaV48x42CaLmrglkPoreXAENc+0Hocw==" Received: by 2002:a05:6871:5827:b0:31d:8e96:6f5e with SMTP id 586e51a60fabf-3ac00d3dbbels3258930fac.2.-pod-prod-08-us; Tue, 07 Oct 2025 02:38:35 -0700 (PDT) X-Received: by 2002:a05:6808:1983:b0:438:257d:6664 with SMTP id 5614622812f47-43fc17abce8mr8552892b6e.20.1759829915491; Tue, 07 Oct 2025 02:38:35 -0700 (PDT) Received: by 2002:a05:6808:1d37:b0:43f:5b9f:a4a0 with SMTP id 5614622812f47-43fc04cc07cmsb6e; Tue, 7 Oct 2025 01:22:31 -0700 (PDT) X-Received: by 2002:a05:6830:6c09:b0:758:6251:2e5c with SMTP id 46e09a7af769-7bf7774ab2bmr9954075a34.31.1759825350472; Tue, 07 Oct 2025 01:22:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759825350; cv=none; d=google.com; s=arc-20240605; b=a+picRKCgJLX3dNNZV589dDlTzuMES7KpCQp0wfsdiCEFaHuk9MLw8s1hns9ZEKAmP HPqwTt6q9jHtxbEXD+6OhoACz7mheBN3hKwURTS7GJ+FECcXGCz87VwKNwLmGaRNWdYf HMkDIyqJ6xenSmaFoTU+sfF53a+cCKpmc5RuRyUNT6pycx7R5lVCOFDp8m59MLqkpwK3 FRxpN5ooeGr1K2s3f/n6cH4rB3+Yfi7gABjUt9owmMYj+CY2grPjZ8S6/DwM30bwRM+V mo+V5rSYmsYOq/hJHYE91NlrB3pwfvVn8EEsO2RBgSbtNwNfUJxblmqQRrKzIbajrU/E WgMQ== 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=F8gssXOZRwBTKbQZDctpslXI/VoJOnBM4Z5F2+d407M=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=VeaSZ1D0P7VOnxjC1niPEDE2b2NggGNE213XQTSR3wvcJje3vvNoIeaXHMHL1FUIxe p+s8+W29Ts19iMVNm9z6gXXN4c3PwLx6sIN+4UlQkQ56KJ47xCTR7D2EdUq/wUf7lwZA Y0U8MLfFCbt9ALS2t0s1RXkyKRnMWGq19bcGVtBqu3eR03JzJSxCBri2F441O6IAR6C4 Sttsr1WCZ53vLhZLgI6iw6DwvD7PX3yPRO0s9lXjq+qaYo0WMZ5bOfP3SCfd+2o+nASY VDj3Mjr4fSD3e/5lMh/gWsQxCCcYalvhG9jURWvMlpy7q1qRQehPPQtqohqMCaSsqaBF +vaQ==; 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 46e09a7af769-7c056fe6581si78107a34.0.2025.10.07.01.22.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 01:22:30 -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 ) id 1v62xb-0003ez-07; Tue, 07 Oct 2025 18:22:27 +1000 Received: by email (sSMTP sendmail emulation); Tue, 07 Oct 2025 18:22:22 +1000 Date: Tue, 7 Oct 2025 18:22:22 +1000 From: Anthony Towns To: waxwing/ AdamISZ Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr Message-ID: References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.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 Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On Wed, Oct 01, 2025 at 07:24:50AM -0700, waxwing/ AdamISZ wrote: > I'm curious about the case of P, R, s published in utxos to prevent usage > of utxos as data. I think this answers in the half-affirmative: you can > only embed data by leaking the privkey so that it (can) immediately fall > out of the utxo set. I think you can attack the setup here. If you allow scriptPubKeys in the utxo set whose spending conditions are HTLC/atomic-swap-like: (pubkey A and preimage reveal of X) OR (pubkey B and block height > H) then you either set H to be arbitrarily far in the future and reveal B's privkey, or choose an NUMS X with no known preimage, and reveal A's privkey. If you don't allow those things (eg, by requiring such constructions also have a (pubkey musig(A,B)) path) then I think you rule out NUMS-IPK constructions, and end up making things like vaults ("hotkey with delay, coldkey anytime") difficult to send to ("I have to sign with my cold key to request funds?"), or, depending on what the utxo R,s is signing, encourage key reuse. > (To emphasize, this is different to the earlier observations (including by > me!) that just say it is *possible* to leak data by leaking the private > key; here I'm trying to prove that there is *no other way*). That seems right to me. I think if the signature scheme supported pubkey recovery (ie, s*G = R + H(R,m)*P, and our "m" didn't commit to P as well), you could get around this by just having P be the data, with no one, including the "signer" able to recover the private key. > However I still am probably in the large majority that thinks it's > appalling to imagine a sig attached to every pubkey onchain. I think the only thing achieved by embedding data in the utxo set (vs an OP_RETURN output or witness data) is to bloat the utxo set; and if that's the goal, it can equally easily be done with spendable outputs that the attacker simply chooses not to ever spend. So that doesn't seem like a terribly interesting solution to anything. As far as embedding data in signatures goes, I think the following scheme would allow you to publish data in a cryptographically-secure way, with minimal lost funds: 0) Setup secret keys p and q, and a 32-byte secret k. H(a,b,..) is sha256 of a,b,.. concatenated. 1) Split your data into N 31 byte blocks, a1, a2, .., aN. 2) Calculate r0 as H(k*G). Calculate r1, .., rN as: r(i+1) = H(p, r(i)) + a(i) 3) Sign N+1 transactions in a chain spending pubkey p*G, using rN, r(N-1), .., r1, r0 as nonces. All but the final tx should pay to a p*G output to continue the chain; the final output should pay to q*G instead. 4) Once all transactions are sufficiently confirmed, spend the final output with k as the secret nonce (and hence R=k*G as the public nonce). Recover the data using the following process: 1) From the final transaction, recover R=k*G, and calculate r0 as H(R). Recover p from the previous transaction, p = (s0-r0)/H(r0*G, P,mi). 2) Recover ri from each signature; ri = si - H(Ri, P, mi)*p. Recover the data ai as ai = ri - H(p,r(i-1)). Dealing with the points being 32-bytes might require carrying over a sign-bit; but that should be possible in the spare ~7 bits since each block was only 31 bytes not 32 bytes. Left as an exercise for the reader, etc. I believe that the privkey p is secure prior to k*G being revealed, since all the nonces are distinct hashes seeded by that privkey; and q remains secure because k is never revealed. If you wanted to not reuse the pubkey p*G repeatedly, you could tweak it to be p0 = p, p(i+1) = p + H(k*G, p(i)), or similar. That would allow you to use an n-of-n multisig to get multiple blocks in a single transaction without seeming weird, eg. I believe the only way to distinguish this from a normal transaction pattern where a wallet has a change output, is via the final transaction that reveals k*G, and detecting the relationship between k*G and the spending conditions of the transaction that created the coin being spent. That's already somewhat expensive to check for every spend, but could be made more so by publishing k*G on some other medium (ie the data is in the blockchain, but you obtain the txid and key to find the data from elsewhere), or by revealing (k+x)*G where x is a random 20-bit (?) number, and a significant but tractable amount of grinding is needed to recover the desired k*G and decode the data -- the idea being that that is tractable for someone who knows there is data at that txid, but not tractable when performed on every signature in the blockchain in order to filter data publication. I think if you did 20 such transactions per block, each spending a single 20-of-20 tapscript multisig, you'd get 12400 bytes of data per block (without violating standardness constraints), at a cost of ~11800vb, so much less efficient than inscriptions, but slightly more efficient than OP_RETURN, and significantly less detectable than either. I think Knots default policy currently allows up to 50-of-50 multisig in tapscript, which would give you 31kB of data in ~26.6kvB of tx weight in a block. If you're regularly making payments from a particular wallet, I think that procedure would allow you to encode data in your change outputs at the rate of 32B/tx for no additional cost. Though the data would only be recoverable once complete, and it's probably worth noting that I haven't provided any security proofs... Cheers, aj -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aOTNvteE8PCm6yDd%40erisian.com.au.