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"
Subject: Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN
Precedence: list

--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--