path: root/5b/634e2f12ed021caa1bd9a236074b36e8e2118c

Delivery-date: Thu, 02 Oct 2025 14:59:48 -0700
Received: from mail-oa1-f61.google.com ([209.85.160.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCJNLJPWXAIBBSXL7PDAMGQEOBACO2A@googlegroups.com>)
	id 1v4RL2-0005eN-1s
	for bitcoindev@gnusha.org; Thu, 02 Oct 2025 14:59:48 -0700
Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-33bb2e3a481sf3245082fac.2
        for <bitcoindev@gnusha.org>; Thu, 02 Oct 2025 14:59:47 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1759442382; cv=pass;
        d=google.com; s=arc-20240605;
        b=PLPcfP3NeKYRXtUxDtwuaEwuH40XrTkrcpSxOefM0B4dYzY6xxbRhgiDJdfrTyD3/t
         BGKFFs/UyLBalHqYDNKFssCBmMTEw9BRKV61gVUDHkDekfRn83fRkVMcNtszGKde0YeT
         G8IhkAoQfAprhX0rDc2+RHiVGfQjvhj1jYSFMQHbeiiYHt3OcjoyRTTYQGLT8WX9qglR
         Y6lWb8XmIkqDHKdtkDVhhUIvaiF/SziLWEkEH9Hk825Jhfmw4RWzr7+Ivgxu3nVnxYqd
         UpfHJHVcci0l4JiW1FdFn2jC/9SKDRk4Xc6snShmJgrnvqPKlZpsMX9bWQgJwhRbaiAv
         KOZA==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=XS60O9A8bvADTvTu3sZMAwL1UPb32gO5+tjT4BwtBC0=;
        fh=r6Fzf/34bUvWuV0JzeXQDds3Zc/ZDkrAKr47x4vpX4E=;
        b=b5+hC6pZbZxO/SQUbBmC29FdUQhhCXJXgPce0PSx1BQuIMgRNY6xPbZ4SbTORDXF5a
         JtqtUYZ5Nb/yjopWGqhWYJ3na4kdWeub40Ub6NJIxzUNgd+lpiRvIFSwLIhLnR6Kgg1o
         CO6wXrgss4DHzPmy4qL2At0LU2LjxixrbIfB4sD4IdORc3LsWZ6zYEUdPk8W0JktSmzV
         GvHi36UwVIHVTODFxT/M/SNb1vNip9DhIj925np/+6Ezrs5cIzH6FF2vx4an6fAKyDfx
         OyZCUz/ZYgcuUr2rOmyCLVWg0gTm+M6DHrCJNe/bJ/ViFCgCJtMx7yjQLkH7bKhJITT2
         bCtw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=O93Gllbv;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1759442382; x=1760047182; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=XS60O9A8bvADTvTu3sZMAwL1UPb32gO5+tjT4BwtBC0=;
        b=PkO5AQlm2Q1BEYQWuJB0JK1JdK72J2Dv/v18CilDhOAT7TK9wvp8m4ZRSgr185Gx+M
         Dos+nPXxiREKvbOhDm0ckI2VYiWoqftNyPhWVhD4PnassdRtjKix6ZbyAVSgu5zqi3Ig
         CpczjxB0fpapY+hR9QYiWVmw8uJiDueZThkhTx48GjEwwLXwyOGYZwcyS4sGUc0xUgH5
         Wx2vN5fcZyQKoYWFvceZ08Q3UoFRPhz7oWOWfEafL3gyNCiJEPVC89AdK2FdMgT7qUbt
         WHzVqtQvTGi0hVkNG3EEy9OuCIW1ii/i9HtOx3PTqDUOUWBhL7BSnHpawVqC6luIfyf7
         7YVQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759442382; x=1760047182; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=XS60O9A8bvADTvTu3sZMAwL1UPb32gO5+tjT4BwtBC0=;
        b=Exbv4BkBmi2MfPEzkIUXjeLj2+gjTax68ixTP8KAl1KXZhjE3xn24CjBkaJ3JU2m4U
         BsSo9/vaZYUvqBS5ghTgc+ogIi+tDYzdA7TxelJ3JzUSCI5N6nxbw4ExXRnbY0hs/p5Y
         9vlrltsfKPzLqx6wApcgVKHJNJxBHWzcBcnzedYgAopcVTWexlkpnNsjuROwOMy3MHdK
         +C43PPW1POrkaEWuK6jlI9Y1pf/lu5yWwQ6ugcFOEGBlo34qUI7nKpPq77OwDL5BhJdQ
         xltCQo7tDbEvgwtbUuHUgr7hzsonsNtmeBSiSxbMzk9XNd+x2rzSjj4z9REmWsShXiHO
         sYgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759442382; x=1760047182;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=XS60O9A8bvADTvTu3sZMAwL1UPb32gO5+tjT4BwtBC0=;
        b=F/bygbNwCbQaUQgRxslCgRz1ad/6cAnX8zdoEynrG76EGWC+WtBPqrHrXiu88y4b8E
         YyoE0LTHoUf831XO83nzg/sJRcen7if8lWf4xCNDZTm7vlQ50up/dxcRNkQwR/tSzAnS
         vOLm5jYkA3YEVonQaMsUwdfkZ6kFKyOoB7fCs7zQerTdcXSaqOmrzgSSjBfDRMsWumpM
         hArblOjlVtFVVKsvYP9hM9QDNMGeiiIlSYtnPoRZRqpxYr3lW4FPA9Akcc9V3YjSqSCh
         m3Hfhr+CNtZKTExPuwVLIvuPCZsk/OlmsSwVjLun6sxO/1hWaoyTHipwPn1iN3bSat0e
         8oBQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXSv7+YKHxvxi4a6W5Qpj8Kunz+FIwyRtSmQxiVBiRj4BvgGyQEf1Fv+76K0x6P6J7zaQFOEmprTt5k@gnusha.org
X-Gm-Message-State: AOJu0Yz6TmzrKZX5U0mKCxVQ5Eq9NgKRoOeGPNfbYfgr0EtKk2Hvd8uH
	3y0TX1jjeQc12luIEjSyxentVHmyqOV0YTLcSzb3IZqPhCpXQxZ38nbS
X-Google-Smtp-Source: AGHT+IH3RCrLq3JeMRCVXV45VMEuQHUGkw//eE7OHZVGD6l5absEr2e+PdeOZ/zvntnHOXf2ac9rOw==
X-Received: by 2002:a05:6870:6108:b0:321:2772:dd9 with SMTP id 586e51a60fabf-3b0fd2c33b8mr534025fac.12.1759442381886;
        Thu, 02 Oct 2025 14:59:41 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd7u8OzaEXFSv5Q7QxYYq0JlSXuH7GGwEBLNBEnwbj6DvA=="
Received: by 2002:a05:6871:230e:b0:30b:d6e4:3de6 with SMTP id
 586e51a60fabf-3ac01eb2b95ls685391fac.2.-pod-prod-01-us; Thu, 02 Oct 2025
 14:59:38 -0700 (PDT)
X-Received: by 2002:a05:6808:3a0f:b0:43f:1ae3:78f1 with SMTP id 5614622812f47-43fc17ac4c7mr407664b6e.20.1759442378135;
        Thu, 02 Oct 2025 14:59:38 -0700 (PDT)
Received: by 2002:a05:6808:1b2c:b0:43d:2644:97ea with SMTP id 5614622812f47-43fc081a8aamsb6e;
        Thu, 2 Oct 2025 12:49:25 -0700 (PDT)
X-Received: by 2002:a17:90b:33d1:b0:336:b563:993f with SMTP id 98e67ed59e1d1-339c27b9360mr563821a91.34.1759434563165;
        Thu, 02 Oct 2025 12:49:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1759434563; cv=none;
        d=google.com; s=arc-20240605;
        b=d29EwtMOwIb6h+zCQqWXWB8nYtSh8QWUxAUJLYeUpEashnjKQY+Sc+v6xirrEDvouN
         tu3/KeLbueGrUZTAt7YpL6XFCWOX/X7fZwpdjLzPfPgcGMjovENH33YoU0E9iwNGwsz1
         khgsDe5587lnDHcOspNn2J57dO5FVBYIFUW8yq8TQaoUiSR5eLAmkUEUm1yLtVAb9m0a
         RCCQZNJWWiK2OXAXmYLHOOawgxtjCwCcw7EYMDkXFMxZgxnDk9vJY9XtXWAXEzbn82kx
         Bta0K1FE9gJmsKt258Y/gKcqTrtBLYyXafv3mKU1+z+YqEb9eNBziFgqfC9lL2A98glI
         z1Ww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=xpf60RS7BcYRQWjAAZFvPM3qKvpPWxPZDUAst/7/O9k=;
        fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=;
        b=QE9+6yxZsmkJrAR+K0yLgpvpZG0dy62ptI0xiGOiQW85GDDBUiDl6I61mWIjzHxGBJ
         BMUsDANJezJ6D4RMQ+QhC/DFjj9QcWDsMG8H+1Mwerddax7etTLo2N38vSrf6dw349WJ
         /3E9E9sKMU9zPJyqxBqJt+snEE83octGp029ABiJobjDSfs3nenk0xJag9vRT5xpvpd5
         uao1GkEvhIUdZN44O0KrAYT0K+t2u/NP0cRjXf3ucT7Pz4gycp5aR/dukbtJJN05/Ytc
         abPQOjNxX6Vyptbd9UBESRMoLBtV6F/puDytCu3AHfPGbXYV2OncE5gS5Y5ztvqEZGFG
         4iTA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=O93Gllbv;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com. [2607:f8b0:4864:20::530])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-339b4ea4dedsi139672a91.1.2025.10.02.12.49.23
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Thu, 02 Oct 2025 12:49:23 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) client-ip=2607:f8b0:4864:20::530;
Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-b551b040930so893853a12.2
        for <bitcoindev@googlegroups.com>; Thu, 02 Oct 2025 12:49:23 -0700 (PDT)
X-Gm-Gg: ASbGncuhxtBdJSwCkvC+zAzWLmVF/HpDzxOPLcU4JcZJd9dNSXZwuej4oWKG/HpaZRE
	MH7wOaZ3ZP7UTSRGYXBKSrgNmNVR3yDPmXdidChmvHZSJo7HuBCbRo3gZE2QYg6O7h9PU/nyytE
	WXE/srVJ3Hu/KxYxxAzlkry0QDy0d8H3TEVz96e9ct1cLaGBJPmCyfIxDgiOlKkwl4NSXYiAbSO
	IpBeHLZbbTO3A3LLa+nmMx509RJHa5uLz0bLvsVHg==
X-Received: by 2002:a17:90b:38c6:b0:32e:f1c:e778 with SMTP id
 98e67ed59e1d1-339c2707b92mr667383a91.3.1759434562628; Thu, 02 Oct 2025
 12:49:22 -0700 (PDT)
MIME-Version: 1.0
References: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
 <CAAS2fgQRz=EJ+Nm2rxrB_SEpqroFbcc+hUhmghJJ1jrJc-WUDA@mail.gmail.com>
 <aN21KbXTORgXAVH0@mail.wpsoftware.net> <2e366b25-f789-4c9d-acf9-b87149d6a796n@googlegroups.com>
 <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
In-Reply-To: <cf15c24e-18d0-4221-a3d4-4177c82a6381n@googlegroups.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Thu, 2 Oct 2025 19:49:10 +0000
X-Gm-Features: AS18NWC-AAzu-smhwPfGRaO7RRPJqzs57oIvY36B6gt43mksOqpfrrTDn3-0uRY
Message-ID: <CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ@mail.gmail.com>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000001c72330640324859"
X-Original-Sender: gmaxwell@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=O93Gllbv;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::530
 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
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.5 (/)

--0000000000001c72330640324859
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I just meant in the purely grinding non-key leaking case you could get 4
bytes into the nonce pretty easily and 4 bytes into either the pubkey or
signature out of a 64 byte signature.  Obviously the delivered embedding
rate in a whole txn will be lower, but maybe not that much thanks to
multisig outputs.


On Thu, Oct 2, 2025 at 4:17=E2=80=AFPM waxwing/ AdamISZ <ekaggata@gmail.com=
> wrote:

> > >  12% embedding rate
> > Where do you get that number from? 33% for embedding 256 bits in (P, R,
> s) (but as per this discussion, according to me, at the cost of key
> leakage). If we include the other bytes in a (taproot anyway) utxo that's
> not much less, I guess 30% ish. I could try to guess but it'd be easier i=
f
> you told me :)
>
> Thinking about it again: to publish data, you have to publish a
> transaction! I guess the most economical, paying taproot to taproot, is
> about 192 bytes with script path plus the posited extra 64 for the (R,s) =
in
> the output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a bi=
t
> different for key path though, because no control block? Well it hardly
> matters, it's some small fraction in that range.
>
> An interesting mechanical detail in this near-absurd scenario is that if
> you wanted to repeatedly publish off the same (presumably a few multiples
> of dust level) output, you couldn't also do the leak single key thing,
> since you'd lose control to re-spend. So that'd place us in the "explicit
> multisig" scenario that Greg mentioned, which I think would only make sen=
se
> with legacy script? Kind of a different scenario, also it would be really
> weird to update legacy script to take into account a new "you must sign t=
he
> pubkeys" rule. Though I guess in this fictional scenario, it might happen
> like that. If you did do it with legacy, you'd be publishing bare 2 of 2
> multisig. If you did it with taproot due to how that works, the script is
> not published until the output is spent, so I think that's outside what I
> was considering ("data in utxo set"). (I guess you could also use somethi=
ng
> like a hash lock which might be more efficient). So anyway if you wanted =
to
> do this repeatedly and minimize cost, for whatever strange reason, you'd =
be
> adding another 50-100 bytes each time bringing that % down to like 10% or
> less.
>
> But that all became way too hypothetical to even analyze properly :)
>
> Anyway just to reemphasize I certainly wasn't advocating this
> sig-attaching system, but it seems important to know what the result of i=
t
> would be: we would still not have changed the obvious reality that
> embedding data in witness gives more space for data, and is more
> economical, and we would only reduce by a big factor how much can be
> embedded in outputs (anything from 8% to 15% embedding rate seems possibl=
e
> depending on the hypothetical details), while having to screw up much of
> Bitcoin's functionality in the process.
>
> Cheers,
> AdamISZ/waxwing
>
> --
> 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/cf15c24e-18d0-4221-a3d4-4177=
c82a6381n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-417=
7c82a6381n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.gmail.com.

--0000000000001c72330640324859
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I just meant in the purely grinding non-key leaking c=
ase you could get 4 bytes into the nonce pretty easily and 4 bytes into eit=
her the pubkey or signature out of a 64 byte signature.=C2=A0 Obviously the=
 delivered embedding rate in a whole txn will be lower, but maybe not that =
much thanks to multisig outputs.</div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, Oct 2, 2025 at 4:17=E2=80=AFPM waxwing/ AdamISZ &lt;<a href=3D"ma=
ilto:ekaggata@gmail.com">ekaggata@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">&gt; &gt;=C2=A0=C2=A012% embeddi=
ng rate<div>&gt; Where do you get that number from? 33% for embedding 256 b=
its in (P, R, s) (but as per this discussion, according to me, at the cost =
of key leakage). If we include the other bytes in a (taproot anyway) utxo t=
hat&#39;s not much less, I guess 30% ish. I could try to guess=C2=A0but it&=
#39;d be easier if you told me :)</div><div><br></div><div>Thinking about i=
t again: to publish data, you have to publish a transaction! I guess the mo=
st economical, paying taproot to taproot, is about 192 bytes with script pa=
th plus the posited extra 64 for the (R,s) in the output, so yeah that&#39;=
d be 32 out of 256, 12.5%. Isn&#39;t the figure a bit different for key pat=
h though, because no control block? Well it hardly matters, it&#39;s some s=
mall fraction in that range.</div><div><br></div><div>An interesting mechan=
ical detail in this near-absurd scenario is that if you wanted to repeatedl=
y publish off the same (presumably a few multiples of dust level) output, y=
ou couldn&#39;t also do the leak single key thing, since you&#39;d lose con=
trol to re-spend. So that&#39;d place us in the &quot;explicit multisig&quo=
t; scenario that Greg mentioned, which I think would only make sense with l=
egacy script? Kind of a different scenario, also it would be really weird t=
o update legacy script to take into account a new &quot;you must sign the p=
ubkeys&quot; rule. Though I guess in this fictional scenario, it might happ=
en like that. If you did do it with legacy, you&#39;d be publishing bare 2 =
of 2 multisig. If you did it with taproot due to how that works, the script=
 is not published until the output is spent, so I think that&#39;s outside =
what I was considering (&quot;data in utxo set&quot;). (I guess you could a=
lso use something like a hash lock which might be more efficient). So anywa=
y if you wanted to do this repeatedly and minimize cost, for whatever stran=
ge reason, you&#39;d be adding another 50-100 bytes each time bringing that=
 % down to like 10% or less.</div><div><br></div><div>But that all became w=
ay too hypothetical to even analyze properly :)</div><div><br></div><div>An=
yway just to reemphasize I certainly wasn&#39;t advocating this sig-attachi=
ng system, but it seems important to know what the result of it would be: w=
e would still not have changed the obvious reality that embedding data in w=
itness gives more space for data, and is more economical, and we would only=
 reduce by a big factor how much can be embedded in outputs (anything from =
8% to 15% embedding rate seems possible depending on the hypothetical detai=
ls), while having to screw up much of Bitcoin&#39;s functionality in the pr=
ocess.</div><div><br></div><div>Cheers,</div><div>AdamISZ/waxwing</div><div=
><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ%40mail.g=
mail.com</a>.<br />

--0000000000001c72330640324859--