Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2D326C000B for ; 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 ; 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 ; 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 ; Sat, 24 Apr 2021 23:38:08 +0000 (UTC) Received: by mail-io1-xd36.google.com with SMTP id s16so47137890iog.9 for ; 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: <20210423181550.xri2ravlwfe3vpc6@ganymede> <20210424215900.nufcy6uzjzompdbs@ganymede> In-Reply-To: <20210424215900.nufcy6uzjzompdbs@ganymede> From: Zac Greenwood Date: Sun, 25 Apr 2021 01:37:56 +0200 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> 1. More data allowed in scriptSig, e= .g. 80 byte payload (81 actually, I
>=C2=A0 =C2=A0think) for OP_RETUR= N versus 40 bytes for a BIP141 payload.
>=C2=A0 =C2=A0Maximizing payl= oad size better amortizes the overhead cost of the
>=C2=A0 =C2=A0cont= aining transaction and the output's nValue field.

In order to reduce the footprint of data stored on-chai= n, could it perhaps
be beneficial to introduce some non-transacti= on data structure in order to
facilitate storing data on-chain su= ch 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 alternati= ve (which now is using OP_RETURN) with
help of weight units?

Zac


On Sun, Apr 25, 2021 at 12:01 AM Dav= id A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Sat, Apr 24, 2021 a= t 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As i= n
> Script can represent things we know nothing about.

I guess I still don't understand your concern, then.=C2=A0 If script ca= n
represent things we know nothing about, then script commitments such as
P2SH, P2WSH, and P2TR also represent things we know nothing about.=C2=A0 Al= l
you know is what container format they used.=C2=A0 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,00= 0
byte limit is only applied when EvalScript is run, which only happens
when the output is being spent.=C2=A0 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).=C2=A0 I've updated the answer to hopefully make it more<= br> correct.

> Is it possible/easy to, say, using bech32m make an inappropriate messa= ge in
> the address? You'd have to write the message, then see what it dec= odes to
> without checking, and then re encode? I guess this is worse than hex?<= br>
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.=C2=A0 E.g., you compose your message using only
the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
the appropriate checksum.

[1] https://en.bitcoin.it/w= iki/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.=C2=A0 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
=C2=A0 =C2=A0think) for OP_RETURN versus 40 bytes for a BIP141 payload.
=C2=A0 =C2=A0Maximizing payload size better amortizes the overhead cost of = the
=C2=A0 =C2=A0containing transaction and the output's nValue field.

2. Exemption from the dust limit.=C2=A0 If you use a currently defined
=C2=A0 =C2=A0address type, the nValue needs to pay at least a few thousand = nBTC
=C2=A0 =C2=A0(few hundred satoshis), about $0.15 USD minimum at $50k USD/BT= C.=C2=A0 For
=C2=A0 =C2=A0OP_RETURN, the nValue can be 0, so there's no additional c= ost beyond
=C2=A0 =C2=A0normal 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 unifo= rm 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.=C2=A0 M= y 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
{
=C2=A0 "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufu= x9r",
=C2=A0 "blocks": [
[...]
}

$ bitcoin-cli -regtest send '[{"data": "'$( dd if=3D= /dev/zero bs=3D1000 count=3D11 | xxd -g0 -p | tr -d '\n' )'&quo= t;}]'
11+0 records in
11+0 records out
11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s
{
=C2=A0 "txid": "ef3d396c7d21914a2c308031c9ba1857694fc33df71f= 5a349b409ab3406dab51",
=C2=A0 "complete": true
}

$ bitcoin-cli -regtest getrawmempool
[
=C2=A0 "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab= 51"
]

$ bitcoin-cli -regtest -generate 1
{
=C2=A0 "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py= 5zh",
=C2=A0 "blocks": [
=C2=A0 =C2=A0 "2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a= 314c5604b"
=C2=A0 ]
}

$bitcoin-cli -regtest getblock 2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106= d216d3abb3a314c5604b 2 | jq .tx[1].txid
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"= ;
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000092189905c0c06787--