From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 08 Oct 2025 01:45:13 -0700 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v6PnN-0003Ms-43 for bitcoindev@gnusha.org; Wed, 08 Oct 2025 01:45:13 -0700 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7a25c0307f1sf6912012a34.2 for ; Wed, 08 Oct 2025 01:45:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759913106; cv=pass; d=google.com; s=arc-20240605; b=J/F+7iFIvXXVgAaIJpsgzRerCnsqmEAVSTDfJQlS8MIFbgPl+bxJt+vxDnSvz7hQn3 xPFTdX3OnGFRnoeTlKnF6rrcclo42lBGdKTYhhPAa1GlS166MsEEiBfsNBPssh8h++ig qX2spa4rfIjhfG5AZkR7eM14QDffhEo0LuCCb822eDYR+lwAyMYl6nzKg8Ix67uTbJB3 6nM7hlDvjOwPgFbM64vuqgZ/6/LmJ8PXwZR/PqU6brhKz9anWVCvHx9nKEp143x10oe1 7LyvBW7C4Xv7OSoMDQ9GvCT8gh5C+8P8x6bmPRTunRglHM+Vk4Cn5oiBK1meTVw4HEeX iZqg== 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=JsdN3e3DVWfgVfJepbFNajIhJvnZVX/syGlhLEbf3RU=; fh=c7kMiVGNQ+6rZ3q0dZR2LDcRN1iNHpEzyjiSKZ0GE/Q=; b=R3RbruJITnuXIeRMGIQe510RAF0R4WARxYG0Gtk8SriUN1waASzCmusuaDLDzIZbYu VEIbzTz+56ni7MT9b6irvUXJIH72Wc3eCpIy7CIYOlp30gPmpF+jJOnxuglQNVEZB66V pTboFqlg22Jm2jOSAtJO7eaUS1SwvigVpBVLM7fonzSQ0gCtVKIfPpMJ6F3q/dp1QLFe BhppOpCooKfsqP+7jrwrA4RWjIivypfSxxvattTKFvRuyVjjTc1r36vlJSyzE27+8rjn w+pUMklpO127WB5U26RiGX/W4AcL4QV2xi9xhN3FIlPmudUbAKbgxhPc/zH7/apmJVgj BZSw==; 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=1759913106; x=1760517906; 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=JsdN3e3DVWfgVfJepbFNajIhJvnZVX/syGlhLEbf3RU=; b=hxO1Nh3EQh8LH2s4JqgXLoXz0bPOCbkJLelauWm/J2vYN+wGneWSi6rrtnyF1hspaq i+JNNgi5X3Aqlhehr6cp4tV1OTbNnM/io8llL5LpOPbVkyJ2ZgYQs15YnFZucLpZ3YUA VfJVMgc/XPAj4ZFrNZlzdonEVx1DQ8tVarQx/ZOt2jpvexa2YzTaIftliphjFB3BeQ1c jU3uKZDPUvFfm3cBkW2G32BL0kdtTfYgx6MOu8KpIt/11HXOfFZ6fyF9TRubMbPrpUDd MuYbmFFUtIC3qZJQOUdK7ERJGaHxRp9BFjc0/YTEt2gnOGsNd5Ic+J29gtA8twPqMWZe AfEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759913106; x=1760517906; 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=JsdN3e3DVWfgVfJepbFNajIhJvnZVX/syGlhLEbf3RU=; b=oegSrCnFhm3uXrVoUedf/Uuqly/CwMDq2W+/awRCAhZaAAoCdERdB4dpLL/2wDHP/x 36r/wuH5EgZXriR03QK7rXJv6F3+mKsEeNx/UV2vePz5nOddkW30r6DCZC+7xFxyEjIw BxqEWZyMOT38h1PL5AMTpbAhSmpstBkz1a9LlIUcORWpg0k1OIag3IUzRodLJylE786O mRIP+M3PhXVC6mJaV/Aew7FRkAtFJtgtdSN6Hk6sst3ubIP1eYKa2BKWyHy14LGphKlt uGZWretnKA58rCvXuoiR7FUJtwiI6cLOmSdobSqvEMl+FfnlB1AjA3GvpxtPx6GLJowt e1Hg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUQt3k6xJuKzaEkdwYsxbVD1cXMTN6xmu98K+19fPojsPnRhfX/fpj9itjvMJxAoISIfthP18JVU+Jg@gnusha.org X-Gm-Message-State: AOJu0YyNOJ+HvR4C79IGLoO2rXtiLXjDUefPCY3XrPqbl3TVC0R9fFHi iC5voJEQ5pXMbzLW3Zk85uivjH4IUcxbWBc2X23j0hxNzHOcxR3YY+zC X-Google-Smtp-Source: AGHT+IHAS8Az1l/GN802EafRVYJ9KQixKO8wm2ccGlXior6DahGZs6IKJ81LIZSULbIVqiHCexPslA== X-Received: by 2002:a05:6830:641b:b0:799:de78:29d1 with SMTP id 46e09a7af769-7c0df70c81bmr1932082a34.15.1759913106529; Wed, 08 Oct 2025 01:45:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd63giPeYfba5F6DMLCpr1u9XgmzrJEVD5WRnJzVvB97Tg==" Received: by 2002:a4a:ca02:0:b0:623:4d59:817b with SMTP id 006d021491bc7-64e032cf02dls2459841eaf.2.-pod-prod-09-us; Wed, 08 Oct 2025 01:45:01 -0700 (PDT) X-Received: by 2002:a05:6808:6414:b0:43f:5e91:d556 with SMTP id 5614622812f47-4417b3e737amr1320943b6e.44.1759913101398; Wed, 08 Oct 2025 01:45:01 -0700 (PDT) Received: by 2002:a05:6808:484:b0:43f:5b9f:a4a0 with SMTP id 5614622812f47-4417b4b3cd6msb6e; Tue, 7 Oct 2025 22:12:36 -0700 (PDT) X-Received: by 2002:a05:6870:380f:b0:332:75df:ab8e with SMTP id 586e51a60fabf-3c0f59061fdmr1166123fac.7.1759900355499; Tue, 07 Oct 2025 22:12:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759900355; cv=none; d=google.com; s=arc-20240605; b=d7nuvNanrVXZKRnMdTtZKSV6+R8pXfRREVHHMiiJlwyiccZdfc+6E0Jh6CERmpz4VR 0N6CbFbi2pMtrn6ZTM+fQMQGAafdwnPvPjUbSRcDEEdP4RT18IxsDkZo1NgFTP5WfTNS lxHqIawnPlK7PUrkjmK0Ei7zIop2PWk78yL5B8OSHxXFLmBKLtiJ7h94DLPYxJ16P4To i0wcSJ8nCM4pC74aqsACyYINppZ842p0ZA2TsGZij+QRhhrkDUJxhEVP7Qn58TQ6vg+l nHWGZqbvfP+/hv04+oIFqlXuSGH8NLuVA8EL1JlVX+4uZfizI3ilt5MBTlA+C7Q+Nb9W 9hYQ== 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=sVAcS4iO31JBZi0UR4UNpwSS70xlivlXl/HOhlvV7KY=; fh=zwD6MnSx31+wTUYXvjlRY9wKEAVfUFCZok1hjFoWcUg=; b=hvoQs+tnzId7U4GHQXaCaAzh9psZkaxXvyogTnEFXUUc32uwtbI/JTE2fctf/TOZhu hhPZrbaYv8zIItEVBinKCCVJdRSb8MMABHMYDO6TabPSxb3uzbULc3fFOBjbrbNLOCin Ns4DbhRXZpjg+J8UerDsrdOS+dA3qYXmnBIL+WW+rztoDyNMaPE5odCVuJBKRPHSgGjC U6yHhVhYNlZGT3gnK+1mHzf2/Sne7wFj2MxqSf/A2o/MNnVCZ7HQBizpeN9Z+aeP17v5 pF7r5I7440Sxzx3nNkuXHdAaDX01tRglCGrAs1dP4perlIUiinMM9dAWIbpHxUXa5BSb nPaQ==; 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 586e51a60fabf-3be8e5514bbsi191661fac.5.2025.10.07.22.12.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 22:12:35 -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 1v6MTM-0000b6-12; Wed, 08 Oct 2025 15:12:33 +1000 Received: by email (sSMTP sendmail emulation); Wed, 08 Oct 2025 15:12:28 +1000 Date: Wed, 8 Oct 2025 15:12:28 +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: 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 Tue, Oct 07, 2025 at 05:05:24AM -0700, waxwing/ AdamISZ wrote: > Yes, basically. I discuss this in the paper w.r.t. ECDSA. Your description > of the relevance of pubkey recovery is good, but there are some nuances. > You can't quite (with ECDSA) get P to be the data and have a valid sig, but > you can get 's' to be the data simply by backsolving for the private key x. > Lack of "pubkey prefixing" in the very funky 'commitment to the nonce' in > ECDSA causes that. And the second nuance, you did actually mention: you get > "not leaking the key" for free, here. But it's still only a 32/96 bytes > embedding rate though, the way I count it. You've got 4x 32-byte values to play with: s, r, p and m. The verification equation determines one of these, reducing it to 3x. m isn't able to be freely chosen, reducing it to 2x. And being able to reverse the equation in order to calculate anything requires the receiver to know one of the secrets, which reduces it to 1x. (Grinding can bump that back up to a factor of 1.something) So that's the 32. On the other side, you need to transmit everything but m which is otherwise determined by the setup, so that's the 96. > I think the logic of that is not quite right. Suppose I want to embed > pictures into the unpruneable utxo set specifically (and not only 'in > transactions'). Sure, but then I'll also suppose your goal is to harm Bitcoin by bloating the utxo set. If that weren't one of your fundamental goals, you'd use other, cheaper and easier, ways of encoding the data. > Very nice example. I am glad you took the trouble to write it out, because > I agree that examples like that are worth working through because as you > say they lean closer to being properly indistinguishable from ordinary > transaction patterns. I think the (P,R,s) outputs could be an interesting design for a non-programmable system that was intended purely for payments -- a FEDwire/SWIFT replacement without the possibility of vaults, lightning, etc. Presumably more mimblewimble friendly etc too. Presumably the "R,s" values could also be a signature of P by the operator's well known pubkey, giving you a KYC/CBDC-like system too. You could get programmability back in this scenario by allow P to sign a script, which you then satisfy, rather than signing a payment directly (ie, the graftroot approach). Anyway, once you make the system programmable in interesting ways, I think you get data embeddability pretty much immediately, and then it's just a matter of trading off the optimal encoding rate versus how easily identifiable your transactions can be. Forcing data to be hidden at a cost of making it less efficient just leaves less resources available to other users of the system, though, which doesn't seem like a win in any way to me. > Your points about limits, standardness constraints are well taken; those > are the kinds of things that do actually matter today, but I was not > thinking about. Note that I mentioned the standardness constraints not because they're limits today, but rather because they reflect the form existing txs take, so mimicing that form would allow txs embedding data via this scheme to be difficult to distinguish from other txs, and hence equally difficult to censor/filter. 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/aOXyvGaKfe7bqTXv%40erisian.com.au.