From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C9821C000B for ; Tue, 20 Apr 2021 15:46:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A3A274021B for ; Tue, 20 Apr 2021 15:46:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgQwrGVcbhsX for ; Tue, 20 Apr 2021 15:46:21 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 9A6F6401F5 for ; Tue, 20 Apr 2021 15:46:21 +0000 (UTC) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13KFkJop020582 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 20 Apr 2021 11:46:20 -0400 Received: by mail-io1-f49.google.com with SMTP id p8so17562795iol.11 for ; Tue, 20 Apr 2021 08:46:19 -0700 (PDT) X-Gm-Message-State: AOAM532RLN5zaTcsNlyQVTnZE39J9xBJcl2QhR68jghogUJ9f+BhbFi7 lR23toM3QGR0OA70gMc5fyoBrGcCGzGj0J5/Xzc= X-Google-Smtp-Source: ABdhPJzTUUCYN9jK//FfEeImILZYnF24wDh5j4ty/L8wWIgocb6TgweLe0mWwqeKesQ7z4uJyf4qJU7BQ+VzsMoDiMA= X-Received: by 2002:a5d:8d12:: with SMTP id p18mr19832664ioj.31.1618933579174; Tue, 20 Apr 2021 08:46:19 -0700 (PDT) MIME-Version: 1.0 From: Jeremy Date: Tue, 20 Apr 2021 08:46:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="000000000000e6d72d05c069589c" Subject: [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: Tue, 20 Apr 2021 15:46:25 -0000 --000000000000e6d72d05c069589c Content-Type: text/plain; charset="UTF-8" Hi All, Introducing the notion that we might want to have an address type defined for OP_RETURN. I came across this when writing some code that wanted to handle common classes of user transactions generically, it's kind of annoying that you have to write code that's effectively: ``` try { print(script.address()); } catch { try { print(script.op_return()); } catch { print("unknown thing"); } } ``` I think that OP_RETURN, being relatively well defined, could have an address type. This would aid in simplifying types for programs. E.g., in Rust I want to have: ``` struct Coin(Address, Amount) impl Coin { fn get_coin(o: Outpoint) -> Result{/**/} } enum Error { UnknownType, CoinDoesNotExist, } ``` and without Address defining OP_RETURN I can't read a Coin containing an OP_RETURN. It would be possible to define Coin to store script, but then everywhere I want an address I would have to perform a conversion and Script is technically "too wide" a type as what I really want is to only return coins with known output types. More concretely this is a challenge for me as I'm building the Sapio compiler and I want to make it so that all contract compilations result in an Address, but I need to support OP_RETURN for various reasons, so I cannot make Sapio only output addresses. As far as I understand the counterargument against this, it is (thanks to Luke Jr): 1) We should only have addresses or descriptors for things we know exactly what they are, and also for things that represent something that is not only payable but also potentially spendable. 2) OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address. 3) Further, most uses of OP_RETURN are proprietary (e.g., we don't know what it represents) so therefore it would be lying to the user to pretend we know how to interpret it. My counterargument is that: 1) Addresses should represent things that people commonly create outputs for -- perhaps regrettably, OP_RETURN is such a thing so software (e.g., https://citp.github.io/BlockSci/reference/addresses/address.html) already does treat OP_RETURN as an address type, just without a standard representation. 2) Many things are unspendable. E.g., a 0 value payment to an address, a payment to P2SH(OP_RETURN ), etc. We can't know spendability based on address type. 3) All scripts can have proprietary interpretations, the job of the address is to do our best job of interpreting standard types to the best of our ability. An example where this has been (ab)used previously is P2SH wrapped SegWit, where one cannot distinguish if the underlying is to be evaluated as P2SH or SegWit. Further, future OP_RETURN address types could take precedence if they are well specified. Do folks agree with the motivations for defining an address type? Are there any design constraints? Some starter thoughts 1) Should it be human readable & checksummed or encoded? 2) Should it have a fixed length of max 40-80 bytes or should we support arbitrary length strings? 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) (my answers are 1. human readable + checksum, 2. arbitrary to support nonstandard ones which miners create 3. non payable in standard software) Cheers, Jeremy Best, Jeremy -- @JeremyRubin --000000000000e6d72d05c069589c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Introduci= ng the notion that we might want to have an address type defined for OP_RET= URN.

I came across this when writing some code that wanted to handle = common classes of user transactions generically, it's kind of annoying = that you have to write code that's effectively:

```
try {
=C2=A0= =C2=A0 print(script.address());
} cat= ch {
=C2=A0=C2=A0 try {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 print(script.= op_return());
=C2=A0=C2=A0 } catc= h {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr= int("unknown thing");
= =C2=A0=C2=A0 }
}
```

I think that OP_RETURN, being relativel= y well defined, could have an address type.

This would aid in simplif= ying types for programs. E.g., in Rust I want to have:

```
struct Coin(Address, Amount)
impl Coin {
=C2= =A0 fn get_coin(o: Outpoint) -> Result<Coin, Error>{/**/}
}
e= num Error {
=C2=A0 UnknownType,
=
=C2=A0 CoinDoesNotExist,
}
```

and without Address defining OP_RETURN I can't read a Coin containi= ng an OP_RETURN. It would be possible to define Coin to store script, but t= hen everywhere I want an address I would have to perform a conversion and S= cript is technically "too wide" a type as what I really want is t= o only return coins with known output types.

More concretely this is = a challenge for me as I'm building the Sapio compiler and I want to mak= e it so that all contract compilations result in an Address, but I need to = support OP_RETURN for various reasons, so I cannot make Sapio only output a= ddresses.

As far as I understand the counterargument against this= , it is (thanks to Luke Jr):

=
1) We should only have addresses or = descriptors for things we know exactly what they are, and also for things t= hat represent something that is not only payable but also potentially spend= able.
2) OP_RETURN, being unspend= able and usually proprietary in purpose, should not have an address.
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:#000000">3) Further, most uses of OP_RETURN are prop= rietary (e.g., we don't know what it represents) so therefore it would = be lying to the user to pretend we know how to interpret it.


My counterargument is that:

1) Add= resses should represent things that people commonly create outputs for -- p= erhaps regrettably, OP_RETURN is such a thing so software (e.g., https://= citp.github.io/BlockSci/reference/addresses/address.html) already does = treat OP_RETURN as an address type, just without a standard representation.=
2) Many things are unspendable. E.g.= , a 0 value payment to an address, a payment to P2SH(OP_RETURN <data>= ), etc. We can't know spendability based on address type.
3) All scripts can have proprietary interpretation= s, the job of the address is to do our best job of interpreting standard t= ypes to the best of our ability. An example where this has been (ab)used pr= eviously is P2SH wrapped SegWit, where one cannot distinguish if the underl= ying is to be evaluated as P2SH or SegWit. Further, future OP_RETURN addres= s types could take precedence if they are well specified.


Do folks agree with the motivations for d= efining an address type? Are there any design constraints?

Some star= ter thoughts
1) Should it be huma= n readable & checksummed or encoded?
2) Should it have a fixed length of max 40-80 bytes or should we suppor= t arbitrary length strings?
3) Should= it be possible (i.e., from core) to pay into such an OP_RETURN or should w= e categorize OP_RETURNS as a non-payable address type (and just use it for = parsing blockdata)

(my answers are 1. human readable + checksum, 2. a= rbitrary to support nonstandard ones which miners create 3. non payable in = standard software)

Cheers,
=
Jeremy



Best= ,

Jeremy

--
@JeremyRubin
--000000000000e6d72d05c069589c--