WIP: NIP-70 Signature Requests and Responses using Nostr

[mgravitt]

This proposal introduces an event type with kind 10010 representing a peer-to-peer request for signature of a specific payload and event kind 10011 as the signature response.

Motivations include support for partially signed bitcoin transactions (PSBT) and business documents, such as ricardian contracts.

Status: Under development

Reference implementation: https://github.com/3yekn/nostr/pull/1

Motivation

Bitcoin PSBTs

Alice, Bob, Charlie, David, and Erika manage a company's bitcoin treasury that is used to pay vendors. The amounts are large, so the treasury is protected in a multisignature wallet. The payment frequency is low, so there is not a need for an L2 such as lightning.

They often use popular bitcoin wallets such as Electrum or Sparrow to manage the treasury. These wallets require that a spending proposer export the PSBT to a text file, send the file out-of-band, where the prospective approver must then import the PSBT, sign, export, and repeat. Eventually, the PSBT or combination of signatures reaches the threshold for the transaction to be finalized and broadcast.

The treasurers wish to improve and streamline the process using Nostr and user-friendly policy editors such as BDK's Elephant.

Business Document Signatures

This feature set could replace common legal document approval/signature applications such as DocuSign or Adobe Sign. Instead of a PSBT, the content could be markdown, plain text, or content such as OpenLaw markup, the Accord project, or other types of Ricardian contracts.

Notes & RFC

Privacy

• The content may or may not be encrypted. Some public DAO treasuries may desire open approvals, although most will likely be encrypted.
• It will likely be common for this feature to be used on private or permissioned relays.

Tagging Prospective Approvers

• The p tag is for tagging a specific account, presuming requesting approval from that user. If it is common for non-approval pubkeys to also be tagged, then a new tag type spec for requested_signer should be added. (TBD)

Bitcoin PSBT and Payload Decoding

• Bitcoin signature request URIs have been proposed over the years but it is unclear how many wallets support them. The content in a 10010 event may contain a URI encoded PSBT or a non-URI encoded PSBT.
• Some legal agreement specifications provide templated or handlebars-style hydration. In these cases, an event may reference an commonly adopted template (via URL, namespace, or hash) and provide the data in the Event tags (e.g. NDA template with a name and expiration date as data fields).

Additional Examples

Additional examples are planned to be developed for further illustrations.

• Partially signed bitcoin transactions
• Purchase Order
• Bill of Lading
• Non-disclosure Agreement
• Multisignature nostr post (e.g. https://github.com/nickfarrow/frostr)

Example Client Implementation

Clients may show the event under DMs or in a specific signature-request zone.

Clients may add Approve or Reject or ... (more) buttons directly in the client, or provide a URI to open the signature request within a bitcoin wallet (similar to the zap functionality).

Miscellaneous References

• Bill Clinton's speech on Electronic Signatures Act
• Ricardian contracts
• Electronic Data Interchange, a very old yet widely used protocol for business documents
• Coinstr presentation, bitcoin multi-custody signature orchestration using Nostr
• Coinstr website

[fiatjaf]

I think this is accomplishing more-or-less the same goals as the Nostr Connect proposal which is in some NIP PR or issue somewhere.

https://nips.be/prnip/46

[mgravitt]

I think 46 is similar enough that it can be used, especially now that it was merged and I think a couple of clients are implementing it. I will close this and see if I can migrate my reference implementation to that. thanks!

[fiatjaf]

Thank you!