From f8742e53308357110b081c8266dc7fb59a60339b Mon Sep 17 00:00:00 2001 From: Antoine Riard Date: Wed, 5 Jul 2023 03:01:43 +0100 Subject: [PATCH] Add Order note based on BOLT12 payment protocol --- XXX.md | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 XXX.md diff --git a/XXX.md b/XXX.md new file mode 100644 index 0000000..0382b57 --- /dev/null +++ b/XXX.md @@ -0,0 +1,92 @@ +NIP-XXX +======= + +`draft` `optional` `author:ariard` + +Order +----- + +This NIP defines a new event type to communicate trade orders between Nostr relays and clients. + +A new parameterized replaceable event `order` is introduced `32500`. This event content field is a Lightning [BOLT12](https://bolt12.org/bolt12.html) string. + +## Motivation + +This proposal aims to enable peer-to-peer markets over the Nostr network, where clients can select +market places or trade counterparties with high-level of flexibility, efficiency and privacy. + +Two types of peer-to-peer markets can be build from an order event: +- over-the-counter markets +- exchanges + +Over-the-counter markets can be defined where a dealer is selling products for the account of its +clients to a set of market-makers, where they have commitments to the product. This can be a Nostr +encrypted or public group events, where the members are selected according to the dealer's policy. + +Exchanges markets can be defined as a publication space where the makers orders are executed against +takers one by the intermediary of a brokering service. This service can be run on top of a Nostr +relay, where the makers and takers are Nostr clients. + +The technical difference between OTC and exchanges lays in the lack of financial interest of +the intermediary in the trade order, and only charges a fee for the publication service. While this +distinction comes with trade-off in term of security model (e.g chain notarization of all the exchange +trades with [NIP03](https://github.com/nostr-protocol/nips/blob/master/03.md)), in practice the differences +are expected to be blurred and function of the goods/products quantity. + +## Design + +The separation between the offer field related to the trade and the event fields related to the processing +of the event enable to introduce orders types based on Nostr tags e.g: +- buy/sell limit order where the offer is not more valid based on a market price indicated in a tag +- stop order where the offer becomes valid when a market price is reached or passed +- time-sensitive order where the offer becomes valid when a chain height is reached + +Those orders types can be defined in future NIPs and enforced by the relay at order routing. + +Merkle construction of the BOLT12 invoice signatures allow selective reveal of the offer fields and therefore +enable brokering service where a Nostr relay can announce an order to its clients, without revealing the issuer +pubkey or withholding some fields related to the order execution (e.g the `blinded_path`). + +The dissociation of the event signature from the offer signature enable to transit the offer across "market +zones" (e.g from a exchange A to an exchange B) without breaking the validity of the offer signature itself. +The old order can be recycled as a new ones with corresponding tags to adapt to the new market zone policy. + +## Specification + +Order has the following format on the wire: + +```json +{ + "id": 32-bytes lowercase hex-encoded sha256 of the serialized event data, + "pubkey": 32-bytes lowercase hex-encoded public key of the event creator, + "created_at": unix timestamp in seconds, + "kind": 32_500, + "tags": [ + ["d", "optional value"], + ], + "content": bolt12 string, + "sig": 64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field +} +``` + +An `order` note creator note: + - MUST set the `kind` field to `32_500` + - MUST set the event `content` field to a valid BOLT12 string + +An `order` receiving node: + - MUST reject event of kind `32_500` if the content is not a valid BOLT12 string + - MAY substitute the `pubkey` field by its own pubkey and re-sign the event + +## Security + +TODO: both relay/client-sides + +## Backward compatibility + +BOLT12-enabled Lightning wallets can read the content of order events and verify the authenticity of the payment or +trade information, without substantial change in the parsing or validation logic of the payment module. A Nostr client +is just responsible to transfer a bolt12 string to the payment module. + +## Acknowledgements + +The Lightning protocol development community for the BOLT12 payment protocol.