Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[Jeremy <jlrubin@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 5693 bytes --]

Inline responses

On Fri, Apr 23, 2021, 11:18 AM David A. Harding <dave@dtrt.org> wrote:

> On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
>
>
>
>
>
> * > Script is technically "too wide" a type as what I really want is to >
> only return coins with known output types. I don't understand this
> concern.  If script is too wide a type, then OP_RETURN being a scriptPubKey
> of arbitrary length up to almost a million bytes is also going to be too
> wide, right?*
>


I meant the type itself is too wide, not the length of the value. As in
Script can represent things we know nothing about. There's a bit of leaky
abstraction since the values self describe the type they are. For addresses
it's just representations IMO for the standard output types one might
expect from standard software.

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. Still probably too big for an address, but I'd
be ok with making op_return addresses only defined for a small size (e.g.
128 bytes?)



>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * > 1) Should it be human readable & checksummed or encoded? It should
> absolutely not be human readable in the sense of being meaningful to
> humans.  We've seen in the past that tools and sites that display OP_RETURN
> data as ASCII encourage people to put text in the block chain that is
> offensive and illegal.  This puts people running nodes at risk of social
> and legal intervention.  Bitcoin's premissionless nature means we can't
> stop people from creating such problems, but we can lower the risk by
> having our tools default to meaningless representations of OP_RETURN data.
> The best advice I've seen is to display OP_RETURN data in hex.  It's still
> possible to say things like "dead beef" with that, but significant abuse is
> hard.  This will, of course, make even 80 byte OP_RETURN "addresses" very
> long.*
>

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?

But it seems this is a general thing... If you wanted an inappropriate
message you could therefore just use bech32m addressed outputs.


> >
>
>
>
> * 2) Should it have a fixed length of max 40-80 bytes or should we support
> > arbitrary length strings? If it doesn't support the fell range,
> somebody's just going to complain later and there will have to be a v2
> address.*
>

So 10,000 bytes? Or do we care to represent outputs that would be consensus
invalid?



>
>
>
>
>
>
>
>
>
>
>
> * > 3) Should it be possible (i.e., from core) to pay into such an
> OP_RETURN or > should we categorize OP_RETURNS as a non-payable address
> type (and just use > it for parsing blockdata) I don't think including
> arbitrary data in the block chain is something that's currently useful for
> typical end users, and applications that want to use OP_RETURN with Bitcoin
> Core can already call create(psbt|rawtransaction) with the `data` field, so
> I'd be mildly opposed in including such a feature in Bitcoin Core's
> wallet.  If at least a few other wallets add the feature to pay OP_RETURN
> "addresses" and it seems popular, then I'm wrong and so I would probably
> then change my position.*
>

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


>
>
>
>
>
> * Regarding "parsing block data", I don't think there's any need to change
> Bitcoin Core's current representation of OP_RETURN outputs (which is just
> showing the hex-encoded script in RPC output).  For any program needing
> OP_RETURN output, hex format is going to be a the next best thing to
> getting it in raw binary.  Any other address format is going to be equal or
> more work*.
>

Thats a fair point. I'm mostly thinking about this in the context of
strongly typed languages/frameworks where you'll get an address object or
enum out, rather than something *stringly* typed. But yes in terms of
stringy languages I don't think any changes are needed.

*Additionally, as mentioned in the other thread about OP_RETURN this*
*week, increasing transaction fees should increasingly push uses of*
*OP_RETURN off the network or into more efficient constructions, so it*
*doesn't seem warranted to me to spend a lot of time trying to optimize*
*how we use it when we'll be using it less and less over time.*


Hmm. I agree it should get priced out over time. However there are some
uses for this kind of stuff. E.g. stealth addresses, or a single instance
of open time stamps.

The main reason I think they merit some sort of std address type is that
I'm writing software that can handle things that we might reasonably see on
the network. And it's relatively annoying (without a custom type) to
represent OP_RETURN as a not-exceptional type of thing.

In my code what I have done is added the following type:

pub enum ExtendedAddress {
/// A regular standard address type
Address(bitcoin::Address),
/// An OP_RETURN
OpReturn(OpReturn),
/// Unknown
Unknown(bitcoin::Script),
}
Which works more or less fine, but 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).

Best,

Jeremy

[-- Attachment #2: Type: text/html, Size: 10657 bytes --]