path: root/79/322079cd6cbd2be98f8aac409cda359da923ae

Return-Path: <zachgrw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2D326C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 24 Apr 2021 23:38:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 20E9A40485
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 24 Apr 2021 23:38:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FR69pXaFtICn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 24 Apr 2021 23:38:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com
 [IPv6:2607:f8b0:4864:20::d36])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 536CF40483
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 24 Apr 2021 23:38:08 +0000 (UTC)
Received: by mail-io1-xd36.google.com with SMTP id s16so47137890iog.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 24 Apr 2021 16:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=966syP8oIwdUQTxZspciBkqfCNs6UDLdjvTMuT5ebkA=;
 b=uWVlSOqt/TdaLe9zn/J34LljWZz6ZQaXqpkg3mkrL0dU/uneQk2oytlEJhzvYYQunN
 K4FLCleb8toGZun9nls71fgJknGzaLqeZQkQNXHa2/Ew5TapxhTJ8MFPNn3rBUYynJsf
 oN4D9YlFGkyiNx9CzOmSQMaqlhwPaCeH4D8LtqliuqBYcVa2TNrgsouFrJ1JL/DnDD/x
 3L5rgXaFNj71YG7qhuGUGB+JaHvjgCuLtpxRlFHIrsp1LxyVulFibXz96kXk84nm5OR7
 ZWQbfOQUYRp7VuEjZjxCZkSjDQ//klz8Mj+vIbWxtmgUzd8dPMka+tZJBezz3RVnclDK
 pqug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=966syP8oIwdUQTxZspciBkqfCNs6UDLdjvTMuT5ebkA=;
 b=Vzq4Md9joaKEHvGTheOQ+TTEKqYT7VPjqI/8joUi/qP1e879yGAA6L63gC8IW27hkS
 ZUd4T/+7uBGvTLoNZvNMoFnbty6XWMj2+EEAC545zlx44iu9+xBYWhj89hp+BfnsZl1h
 6MRho2yZKktPIeLcdnI1B1xBCwjJR+y3hQQvtgXYmz7O7E9z8cmIiWkiuwriXGU2V2cx
 parhdjHato3iyMttYeQT3D+0xLeqU8hEEcACTKnwaHLEKnL0hKX0aAqbxRsn1TtpLzgq
 r1dmV/Wl1iRf00ENR1mFT2DzuNQ/BkBBWTPqbW6Xswf5uQ/uNCLictjk/1M6N0M2mEWL
 hIPw==
X-Gm-Message-State: AOAM531GM+2XwRn2ASoGOzN5EkjELisuDfRjydeoI039t5xFPaV3ZQds
 ocfASDmbg1lQU6IWpSTlXeWF7xFoavVSy20s1G++38pZXIY=
X-Google-Smtp-Source: ABdhPJzIVVEtJEXYjeKpBudxIJooSAdjXwAyTzVRvmnM3LVL9xd3Zc/f4Efp6e8SEoapQE+JXfAOTuzCA3hM9O6a5fk=
X-Received: by 2002:a05:6602:2b0a:: with SMTP id
 p10mr8290481iov.129.1619307487434; 
 Sat, 24 Apr 2021 16:38:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhj7jXSrdbfFJTYw-UzGgZTF0kz-Vr61juF0gJGLf2EKqQ@mail.gmail.com>
 <20210423181550.xri2ravlwfe3vpc6@ganymede>
 <CAD5xwhgnL_u1hS99HPTMBfQbRohgmajzNX4XiGYnN9mZDqjC7g@mail.gmail.com>
 <20210424215900.nufcy6uzjzompdbs@ganymede>
In-Reply-To: <20210424215900.nufcy6uzjzompdbs@ganymede>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Sun, 25 Apr 2021 01:37:56 +0200
Message-ID: <CAJ4-pEDmHctqx7XEqGO5--au7YmLpOnUvf3qhxbatujFJtvjvA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000092189905c0c06787"
X-Mailman-Approved-At: Sat, 24 Apr 2021 23:40:49 +0000
Subject: Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2021 23:38:10 -0000

--00000000000092189905c0c06787
Content-Type: text/plain; charset="UTF-8"

> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
>   think) for OP_RETURN versus 40 bytes for a BIP141 payload.
>   Maximizing payload size better amortizes the overhead cost of the
>   containing transaction and the output's nValue field.

In order to reduce the footprint of data stored on-chain, could it perhaps
be beneficial to introduce some non-transaction data structure in order to
facilitate storing data on-chain such that it maximizes payload size
vs. on-chain size, while at the same time ensuring that using such data
structure is (almost) as expensive in use per payload-byte as the
next-cheapest alternative (which now is using OP_RETURN) with
help of weight units?

Zac


On Sun, Apr 25, 2021 at 12:01 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> > I meant the type itself is too wide, not the length of the value. As in
> > Script can represent things we know nothing about.
>
> I guess I still don't understand your concern, then.  If script can
> represent things we know nothing about, then script commitments such as
> P2SH, P2WSH, and P2TR also represent things we know nothing about.  All
> you know is what container format they used.  For P2PK, bare multisig,
> OP_RETURN, and other direct uses of scriptPubKey, that container format
> is "bare" (or whatever you want to call it).
>
> > Btw: According to... Oh wait... You?
> >
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
> > the max size is 10k bytes.
>
> I'm not sure what I knew at the time I wrote that answer, but the 10,000
> byte limit is only applied when EvalScript is run, which only happens
> when the output is being spent.  I've appended to this email a
> demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
> 999,000 bytes but ran into problems with bash's maximum command line
> length limit).  I've updated the answer to hopefully make it more
> correct.
>
> > Is it possible/easy to, say, using bech32m make an inappropriate message
> in
> > the address? You'd have to write the message, then see what it decodes to
> > without checking, and then re encode? I guess this is worse than hex?
>
> If someone wants to abuse bech32m, I suspect they'll do it the same way
> people have abused base58check[1], by using the address format's
> alphabet directly.  E.g., you compose your message using only
> the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
> the appropriate checksum.
>
> [1]
> https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes
>
> > But it seems this is a general thing... If you wanted an inappropriate
> > message you could therefore just use bech32m addressed outputs.
>
> Yes, and people have done that with base58check.  IsStandard OP_RETURN
> attempts to minimize that abuse by being cheaper in two ways:
>
> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
>    think) for OP_RETURN versus 40 bytes for a BIP141 payload.
>    Maximizing payload size better amortizes the overhead cost of the
>    containing transaction and the output's nValue field.
>
> 2. Exemption from the dust limit.  If you use a currently defined
>    address type, the nValue needs to pay at least a few thousand nBTC
>    (few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC.  For
>    OP_RETURN, the nValue can be 0, so there's no additional cost beyond
>    normal transaction relay fees.
>
> Although someone creating an OP_RETURN up to ~1 MB with miner support
> can bypass the dust limit, the efficiency advantage remains no matter
> what.
>
> > One of the nice things is that the current psbt interface uses a blind
> > union type whereby the entires in an array are either [address, amount]
> or
> > ["data", hex]. Having an address type would allow more uniform handling,
> > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin
> uses
> > a hashmap of address to amount so without a patch you can't create op
> > returns).
>
> I don't particularly care how the data in PSBTs are structured.  My mild
> opposition was to adding code to the wallet that exposes everyday users
> to OP_RETURN addresses.
>
> > I would much prefer to not have to do this in a custom way, as opposed
> > to a way which is defined in a standard manner across all software
> > (after all, that's the point of standards).
>
> I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
> want to make sure this isn't underwhelmingly motivated or will lead to a
> resurgence of block chain graffiti.
>
> -Dave
>
> ## Creating an 11,000 byte OP_RETURN
>
> $ bitcoind -daemon -regtest -acceptnonstdtxn
> Bitcoin Core starting
>
> $ bitcoin-cli -regtest -generate 101
> {
>   "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
>   "blocks": [
> [...]
> }
>
> $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000
> count=11 | xxd -g0 -p | tr -d '\n' )'"}]'
> 11+0 records in
> 11+0 records out
> 11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s
> {
>   "txid":
> "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51",
>   "complete": true
> }
>
> $ bitcoin-cli -regtest getrawmempool
> [
>   "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
> ]
>
> $ bitcoin-cli -regtest -generate 1
> {
>   "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh",
>   "blocks": [
>     "2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b"
>   ]
> }
>
> $bitcoin-cli -regtest getblock
> 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq
> .tx[1].txid
> "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; 1. More data allowed in scriptSig, e=
.g. 80 byte payload (81 actually, I<br>&gt;=C2=A0 =C2=A0think) for OP_RETUR=
N versus 40 bytes for a BIP141 payload.<br>&gt;=C2=A0 =C2=A0Maximizing payl=
oad size better amortizes the overhead cost of the<br>&gt;=C2=A0 =C2=A0cont=
aining transaction and the output&#39;s nValue field.<br></div><div dir=3D"=
ltr"><br></div><div>In order to reduce the footprint of data stored on-chai=
n, could it perhaps</div><div>be beneficial to introduce some non-transacti=
on data structure in order to</div><div>facilitate storing data on-chain su=
ch that it maximizes payload size</div><div>vs. on-chain size, while at the=
 same time ensuring that using such data</div><div>structure is (almost) as=
 expensive in use per payload-byte as the</div><div>next-cheapest alternati=
ve (which now is using OP_RETURN) with</div><div>help of weight units?</div=
><div><br></div><div>Zac</div><div><br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 25, 2021 at 12:01 AM Dav=
id A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Apr 24, 2021 a=
t 01:05:25PM -0700, Jeremy wrote:<br>
&gt; I meant the type itself is too wide, not the length of the value. As i=
n<br>
&gt; Script can represent things we know nothing about. <br>
<br>
I guess I still don&#39;t understand your concern, then.=C2=A0 If script ca=
n<br>
represent things we know nothing about, then script commitments such as<br>
P2SH, P2WSH, and P2TR also represent things we know nothing about.=C2=A0 Al=
l<br>
you know is what container format they used.=C2=A0 For P2PK, bare multisig,=
<br>
OP_RETURN, and other direct uses of scriptPubKey, that container format<br>
is &quot;bare&quot; (or whatever you want to call it).<br>
<br>
&gt; Btw: According to... Oh wait... You?<br>
&gt; <a href=3D"https://bitcoin.stackexchange.com/questions/35878/is-there-=
a-maximum-size-of-a-scriptsig-scriptpubkey" rel=3D"noreferrer" target=3D"_b=
lank">https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-=
size-of-a-scriptsig-scriptpubkey</a><br>
&gt; the max size is 10k bytes.<br>
<br>
I&#39;m not sure what I knew at the time I wrote that answer, but the 10,00=
0<br>
byte limit is only applied when EvalScript is run, which only happens<br>
when the output is being spent.=C2=A0 I&#39;ve appended to this email a<br>
demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried<br>
999,000 bytes but ran into problems with bash&#39;s maximum command line<br=
>
length limit).=C2=A0 I&#39;ve updated the answer to hopefully make it more<=
br>
correct.<br>
<br>
&gt; Is it possible/easy to, say, using bech32m make an inappropriate messa=
ge in<br>
&gt; the address? You&#39;d have to write the message, then see what it dec=
odes to<br>
&gt; without checking, and then re encode? I guess this is worse than hex?<=
br>
<br>
If someone wants to abuse bech32m, I suspect they&#39;ll do it the same way=
<br>
people have abused base58check[1], by using the address format&#39;s<br>
alphabet directly.=C2=A0 E.g., you compose your message using only<br>
the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append<br>
the appropriate checksum.<br>
<br>
[1] <a href=3D"https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_d=
ata_in_hashes" rel=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/w=
iki/P2SH%C2%B2#The_problem:_storing_data_in_hashes</a><br>
<br>
&gt; But it seems this is a general thing... If you wanted an inappropriate=
<br>
&gt; message you could therefore just use bech32m addressed outputs.<br>
<br>
Yes, and people have done that with base58check.=C2=A0 IsStandard OP_RETURN=
<br>
attempts to minimize that abuse by being cheaper in two ways:<br>
<br>
1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I<br>
=C2=A0 =C2=A0think) for OP_RETURN versus 40 bytes for a BIP141 payload.<br>
=C2=A0 =C2=A0Maximizing payload size better amortizes the overhead cost of =
the<br>
=C2=A0 =C2=A0containing transaction and the output&#39;s nValue field.<br>
<br>
2. Exemption from the dust limit.=C2=A0 If you use a currently defined<br>
=C2=A0 =C2=A0address type, the nValue needs to pay at least a few thousand =
nBTC<br>
=C2=A0 =C2=A0(few hundred satoshis), about $0.15 USD minimum at $50k USD/BT=
C.=C2=A0 For<br>
=C2=A0 =C2=A0OP_RETURN, the nValue can be 0, so there&#39;s no additional c=
ost beyond<br>
=C2=A0 =C2=A0normal transaction relay fees.<br>
<br>
Although someone creating an OP_RETURN up to ~1 MB with miner support<br>
can bypass the dust limit, the efficiency advantage remains no matter<br>
what.<br>
<br>
&gt; One of the nice things is that the current psbt interface uses a blind=
<br>
&gt; union type whereby the entires in an array are either [address, amount=
] or<br>
&gt; [&quot;data&quot;, hex]. Having an address type would allow more unifo=
rm handling,<br>
&gt; which is convenient for strongly typed RPC bindings (e.g. rust bitcoin=
 uses<br>
&gt; a hashmap of address to amount so without a patch you can&#39;t create=
 op<br>
&gt; returns).<br>
<br>
I don&#39;t particularly care how the data in PSBTs are structured.=C2=A0 M=
y mild<br>
opposition was to adding code to the wallet that exposes everyday users<br>
to OP_RETURN addresses.<br>
<br>
&gt; I would much prefer to not have to do this in a custom way, as opposed=
<br>
&gt; to a way which is defined in a standard manner across all software<br>
&gt; (after all, that&#39;s the point of standards).<br>
<br>
I&#39;m currently +0.1 on the idea of an address format of OP_RETURN, but I=
<br>
want to make sure this isn&#39;t underwhelmingly motivated or will lead to =
a<br>
resurgence of block chain graffiti.<br>
<br>
-Dave<br>
<br>
## Creating an 11,000 byte OP_RETURN<br>
<br>
$ bitcoind -daemon -regtest -acceptnonstdtxn<br>
Bitcoin Core starting<br>
<br>
$ bitcoin-cli -regtest -generate 101<br>
{<br>
=C2=A0 &quot;address&quot;: &quot;bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufu=
x9r&quot;,<br>
=C2=A0 &quot;blocks&quot;: [<br>
[...]<br>
}<br>
<br>
$ bitcoin-cli -regtest send &#39;[{&quot;data&quot;: &quot;&#39;$( dd if=3D=
/dev/zero bs=3D1000 count=3D11 | xxd -g0 -p | tr -d &#39;\n&#39; )&#39;&quo=
t;}]&#39;<br>
11+0 records in<br>
11+0 records out<br>
11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s<br>
{<br>
=C2=A0 &quot;txid&quot;: &quot;ef3d396c7d21914a2c308031c9ba1857694fc33df71f=
5a349b409ab3406dab51&quot;,<br>
=C2=A0 &quot;complete&quot;: true<br>
}<br>
<br>
$ bitcoin-cli -regtest getrawmempool<br>
[<br>
=C2=A0 &quot;ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab=
51&quot;<br>
]<br>
<br>
$ bitcoin-cli -regtest -generate 1<br>
{<br>
=C2=A0 &quot;address&quot;: &quot;bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py=
5zh&quot;,<br>
=C2=A0 &quot;blocks&quot;: [<br>
=C2=A0 =C2=A0 &quot;2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a=
314c5604b&quot;<br>
=C2=A0 ]<br>
}<br>
<br>
$bitcoin-cli -regtest getblock 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106=
d216d3abb3a314c5604b 2 | jq .tx[1].txid<br>
&quot;ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51&quot=
;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--00000000000092189905c0c06787--