path: root/41/4f78f84c4be2827fbe7dffa4a9d7328226162c

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F2966C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 01:48:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CC50B402CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 01:48:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3ZMCBhq9iGA8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 01:48: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 smtp4.osuosl.org (Postfix) with ESMTPS id 7DF3240287
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 01:48:53 +0000 (UTC)
Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com
 [209.85.167.54]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20I1moXZ016821
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Jan 2022 20:48:51 -0500
Received: by mail-lf1-f54.google.com with SMTP id x22so64469587lfd.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Jan 2022 17:48:51 -0800 (PST)
X-Gm-Message-State: AOAM533AWkTVkR57yeQRmAUOU4G3aZhBh60ISPqc6fWPMIvd/IMqtbJk
 rjX9e+Wc4Bi+aoogak09LMaKIm93ZNkiwp6T1qI=
X-Google-Smtp-Source: ABdhPJxmoJEuYXVVsYKND2GUtfw073UHyoAQbQqJaf2GZOx28840G76iBMg1YyxyI3HU9GtACdXr0sCcdYPJD2K00uQ=
X-Received: by 2002:a05:651c:98c:: with SMTP id
 b12mr17951228ljq.81.1642470529889; 
 Mon, 17 Jan 2022 17:48:49 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 17 Jan 2022 17:48:38 -0800
X-Gmail-Original-Message-ID: <CAD5xwhiP=jYHqnBTmwqJZkKGzSbRpWG+TGoXvuZU=m6KKBKakg@mail.gmail.com>
Message-ID: <CAD5xwhiP=jYHqnBTmwqJZkKGzSbRpWG+TGoXvuZU=m6KKBKakg@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007cfb4905d5d1780b"
Subject: [bitcoin-dev] SASE Invoices
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, 18 Jan 2022 01:48:55 -0000

--0000000000007cfb4905d5d1780b
Content-Type: text/plain; charset="UTF-8"

Devs,

I was recently speaking with Casey R about some of the infrastructural
problems with addresses and felt it would be worth summarizing some notes
from that conversation for y'all to consider more broadly.

Currently, when you generate (e.g., a Taproot address):

- The key may or may not be a NUMS point
- Script paths might still be required for safety (e.g. a backup federation)
- There may be single use constructs (e.g. HTLC)
- The amount required to be sent might be specific (e.g., HTLC or a vault)

These issues exist in other address types as well, and covenants (such as
the kinds enabled by TLUV, APO, or CTV) make exact amounts also important.

As such, it may make sense to specify a new type of Invoice that's a bit
like a SASE, a "Self Addressed Stamped Envelope". SASEs simplify mail
processing because the processor just puts whatever was requested in the
exact envelope you provided, and that's "self authenticated".

A SASE Invoice for Bitcoin might look like an address *plus* a signature
covering that address and any metadata required for the payment to be
considered valid. For example, I might make a TR key and specify that it is
my hot wallet and therefore permitted for only between 0 to 1 Bitcoin. Or I
might specify for a covenant containing address it should only have 0.1234
Bitcoin exactly. Other use cases might include "good for one payment only"
or "please do not use after xxxx date, contact to renew". Some of these
might be perilous, so it's worth careful thought on what acceptable SASE
policies might be.

Businesses making payments might receive a SASE Invoice and save the SASE.
Then, in the future, a SASE can be used e.g. in dispute mediation to show
that the payment sent corresponded to the one requested by that address.
Businesses could even give users unique codes to put into their SASE
generator to bind the address for their own use / to ensure the usage right
of the address isn't transferrable.

if the top-level TR key is a NUMS point, and no signature can be produced
(as might happen for a covenant), then it could be a NUMS point derived
from the hash-to-curve of the SASE Invoice policy.

Such SASE Invoice standards would also go a long way towards
combating address reuse. If standard software does not produce reusable
SASE Invoices, then it would be clear to users that they should generate a
SASE with the expected amount per requested payment.

A well designed SASE spec could also cover things like EPKs and derivation
paths as well.

Previously, https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
was designed in a similar problem space. A big part of SASE invoices would
be for it to be focused on generating fixed payment codes rather than
initiating an online protocol / complicated handshaking.

Cheers,

Jeremy

p.s.:

There's something that looks even *more* like a single use SASE where you
might use one of your existing UTXOs with anyonecanpay and single to pay to
an output which has the funds requested + the funds in the output. a payer
paying this transaction has no choice but to pay you the correct
amount/fees for the specific txn, and it clearly cannot be reused. This is
quite bizarre though, but is noted here if anyone wants something even
closer to a physical SASE.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--0000000000007cfb4905d5d1780b
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">Devs,</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">I was recentl=
y speaking with Casey R about some of the infrastructural problems with add=
resses and felt it would be worth summarizing some notes from that conversa=
tion for y&#39;all to consider more broadly.</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">Currently, when you gene=
rate (e.g., a Taproot address):</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:small;color:#000000">- The key may or may not be a NUMS po=
int</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">- Script paths might still be req=
uired for safety (e.g. a backup federation)</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000">- There may be single use constructs (e.g. HTLC)</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000">- The amount required to be sent might be specific (e.g.=
, HTLC or a vault)</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">These issues exist in other address types as well,=
 and covenants (such as the kinds enabled by TLUV, APO, or CTV) make exact =
amounts also important.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000">As such, it may make sense to specify a new t=
ype of Invoice that&#39;s a bit like a SASE, a &quot;Self Addressed Stamped=
 Envelope&quot;. SASEs simplify mail processing because the processor just =
puts whatever was requested in the exact envelope you provided, and that&#3=
9;s &quot;self authenticated&quot;.</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:small;color:#000000">A SASE Invoice for Bitcoin might =
look like an address *plus* a signature covering that address and any metad=
ata required for the payment to be considered valid. For example, I might m=
ake a TR key and specify that it is my hot wallet and therefore permitted f=
or only between 0 to 1 Bitcoin. Or I might specify for a covenant containin=
g address it should only have 0.1234 Bitcoin exactly. Other use cases might=
 include &quot;good for one payment only&quot; or &quot;please do not use a=
fter xxxx date, contact to renew&quot;. Some of these might be perilous, so=
 it&#39;s worth careful thought on what acceptable SASE policies might be.<=
/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:small;color:#00=
0000">Businesses making payments might receive a SASE Invoice and save the =
SASE. Then, in the future, a SASE can be used e.g. in dispute mediation to =
show that the payment sent corresponded to the one requested by that addres=
s. Businesses could even give users unique codes to put into their SASE gen=
erator to bind the address for their own use / to ensure the usage right of=
 the address isn&#39;t transferrable.</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">if the top-level TR key is a NU=
MS point, and no signature can be produced (as might happen for a covenant)=
, then it could be a NUMS point derived from the hash-to-curve of the SASE =
Invoice policy.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Such SASE Invoice standards would also go a long way=
 towards combating=C2=A0address reuse. If standard software does not produc=
e reusable SASE Invoices, then it would be clear to users that they should =
generate a SASE with the expected amount per requested payment.</div><div c=
lass=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:small;color:#000000">A wel=
l designed SASE spec could also cover things like EPKs and derivation paths=
 as well.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000">Previously,=C2=A0<a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0070.mediawiki">https://github.com/bitcoin/bips/blob/maste=
r/bip-0070.mediawiki</a> was designed in a similar problem space. A big par=
t of SASE invoices would be for it to be focused on generating fixed paymen=
t codes rather than initiating an online protocol / complicated handshaking=
.</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">Cheers,</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Jeremy</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">p.s.:</div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000">There&#39;s something that =
looks even *more* like a single use SASE where you might use one of your ex=
isting UTXOs with anyonecanpay and single to pay to an output which has the=
 funds requested=C2=A0+ the funds in the output. a payer paying this transa=
ction has no choice but to pay you the correct amount/fees for the specific=
 txn, and it clearly cannot be reused. This is quite bizarre though, but is=
 noted here if anyone wants something even closer to a physical SASE.</div>=
<br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smar=
tmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter=
.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div>

--0000000000007cfb4905d5d1780b--