path: root/7e/f01c61e0dcd7ec642e8fc9ea866523a341204c

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C9821C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Tue, 20 Apr 2021 11:46:20 -0400
Received: by mail-io1-f49.google.com with SMTP id p8so17562795iol.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <jlrubin@mit.edu>
Date: Tue, 20 Apr 2021 08:46:07 -0700
X-Gmail-Original-Message-ID: <CAD5xwhj7jXSrdbfFJTYw-UzGgZTF0kz-Vr61juF0gJGLf2EKqQ@mail.gmail.com>
Message-ID: <CAD5xwhj7jXSrdbfFJTYw-UzGgZTF0kz-Vr61juF0gJGLf2EKqQ@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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<Coin, Error>{/**/}
}
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 <data>), 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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--000000000000e6d72d05c069589c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi All,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Introduci=
ng the notion that we might want to have an address type defined for OP_RET=
URN.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">I came across this when writing some code that wanted to handle =
common classes of user transactions generically, it&#39;s kind of annoying =
that you have to write code that&#39;s effectively:</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">```</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">try {</div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0=
=C2=A0 print(script.address());</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">} cat=
ch {</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000">=C2=A0=C2=A0 try {</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 print(script.=
op_return());<br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0=C2=A0 } catc=
h {</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr=
int(&quot;unknown thing&quot;);<br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
=C2=A0=C2=A0 }<br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">}<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">```</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">I think that OP_RETURN, being relativel=
y well defined, could have an address type.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">This would aid in simplif=
ying types for programs. E.g., in Rust I want to have:</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000">```</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">struct Coin(Address, Amount)</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">impl Coin {</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=
=A0 fn get_coin(o: Outpoint) -&gt; Result&lt;Coin, Error&gt;{/**/}<br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">}</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">e=
num Error {</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">=C2=A0 UnknownType,</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">=C2=A0 CoinDoesNotExist,<br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">}<br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">```</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00">and without Address defining OP_RETURN I can&#39;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 &quot;too wide&quot; a type as what I really want is t=
o only return coins with known output types.</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000">More concretely this is =
a challenge for me as I&#39;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.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:#000000">As far as I understand the counterargument against this=
, it is (thanks to Luke Jr):<br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">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.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000">2) OP_RETURN, being unspend=
able and usually proprietary in purpose, should not have an address.</div><=
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&#39;t know what it represents) so therefore it would =
be lying to the user to pretend we know how to interpret it.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000">My counterargument is that:</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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., <a href=3D=
"https://citp.github.io/BlockSci/reference/addresses/address.html">https://=
citp.github.io/BlockSci/reference/addresses/address.html</a>) already does =
treat OP_RETURN as an address type, just without a standard representation.=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">2) Many things are unspendable. E.g.=
, a 0 value payment to an address, a payment to P2SH(OP_RETURN &lt;data&gt;=
), etc. We can&#39;t know spendability based on address type.</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">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.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">Do folks agree with the motivations for d=
efining an address type? Are there any design constraints?</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Some star=
ter thoughts<br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">1) Should it be huma=
n readable &amp; checksummed or encoded?</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00">2) Should it have a fixed length of max 40-80 bytes or should we suppor=
t arbitrary length strings?</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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)</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">(my answers are 1. human readable + checksum, 2. a=
rbitrary to support nonstandard ones which miners create 3. non payable in =
standard software)<br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">Cheers,</div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000">Jeremy<br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Best=
,</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">Jeremy<br></div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a=
 href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a=
><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></=
div></div></div>

--000000000000e6d72d05c069589c--