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