Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F2966C002F for ; 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 ; 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 ; 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 ; 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 ; Mon, 17 Jan 2022 20:48:51 -0500 Received: by mail-lf1-f54.google.com with SMTP id x22so64469587lfd.10 for ; 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 Date: Mon, 17 Jan 2022 17:48:38 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 --0000000000007cfb4905d5d1780b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Devs,

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'all to consider more broadly.

Currently, when you gene= rate (e.g., a Taproot address):

<= /div>
- The key may or may not be a NUMS po= int
- Script paths might still be req= uired 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 t= ype 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= 9;s "self authenticated".
<= br>
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 "good for one payment only" or "please do not use a= fter xxxx date, contact to renew". Some of these might be perilous, so= it's worth careful thought on what acceptable SASE policies might be.<= /div>

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't transferrable.

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.

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.

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

Previously,=C2=A0https://github.com/bitcoin/bips/blob/maste= r/bip-0070.mediawiki 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= .

Cheers,

Jeremy

p.s.:

There'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.
=
--0000000000007cfb4905d5d1780b--