[bitcoin-dev] SASE Invoices

[Jeremy <jlrubin@mit.edu>]

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

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>

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