Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 12672C000B for ; Sat, 24 Apr 2021 22:29:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ED2C083B9F for ; Sat, 24 Apr 2021 22:29:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiJj2tcxiLEP for ; Sat, 24 Apr 2021 22:29:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5E2DE83B9C for ; Sat, 24 Apr 2021 22:29:53 +0000 (UTC) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13OMToCO027671 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 24 Apr 2021 18:29:51 -0400 Received: by mail-il1-f169.google.com with SMTP id a9so1623655ilh.9 for ; Sat, 24 Apr 2021 15:29:51 -0700 (PDT) X-Gm-Message-State: AOAM530etsSwlyHfj15xe7c437/4TlXDaMEFdfPTmwHNnqt0yZMFyzBE N/vGKZNLj0je+dowN8Zx+UHB8LoC9dl0vG4tk2o= X-Google-Smtp-Source: ABdhPJyYff6xQ6I8ZGhJvpwI9uFhjlouVhOhBZnxRxCgTTTHWiVYFsi8OZO2xds0KsyaxwC33M6hHs9UrTjR5yOLe+U= X-Received: by 2002:a92:6e0e:: with SMTP id j14mr7916613ilc.90.1619303390702; Sat, 24 Apr 2021 15:29:50 -0700 (PDT) MIME-Version: 1.0 References: <20210423181550.xri2ravlwfe3vpc6@ganymede> <20210424215900.nufcy6uzjzompdbs@ganymede> In-Reply-To: <20210424215900.nufcy6uzjzompdbs@ganymede> From: Jeremy Date: Sat, 24 Apr 2021 15:29:39 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="00000000000062f15a05c0bf7319" Cc: Bitcoin Protocol Discussion 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 22:29:55 -0000 --00000000000062f15a05c0bf7319 Content-Type: text/plain; charset="UTF-8" I guess in the interest of being clear; I don't particularly want a OP_RETURN address either, they're just annoying to program around, and they exist historically, as well as perhaps in the future. Maybe people will start using the annex space to add any metadata required? E.g. stealth addresses. I kinda hope not, but probably will be proposed as a SF since it's much cheaper (witness + no amount) and per-input vs. per-tx. It's interesting that they can be created with any length... i guess any script can be an op return if you make it long enough... -- @JeremyRubin On Sat, Apr 24, 2021 at 3:00 PM David A. Harding 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" > --00000000000062f15a05c0bf7319 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess in the interest o= f being clear; I don't particularly want a OP_RETURN address either, th= ey're just annoying to program around, and they exist historically, as = well as perhaps in the future.

Maybe people will start using the anne= x space to add any metadata required? E.g. stealth addresses. I kinda hope = not, but probably will be proposed as a SF since it's much cheaper (wit= ness=C2=A0+ no amount) and per-input vs. per-tx.

It's interes= ting that they can be created with any length... i guess any script can be = an op return if you make it long enough...
<= div dir=3D"ltr">--
@JeremyRubin


=
On Sat, Apr 24, 2021 at 3:00 PM David= A. Harding <dave@dtrt.org> wrot= e:
On Sat, Apr 2= 4, 2021 at 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"= ;
--00000000000062f15a05c0bf7319--