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>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
