docs: nip p2p trading #405
Conversation
11001.md
Outdated
| tags: [ | ||
| ["D", "BUY"], | ||
| ["C", "BTC/NGN"], | ||
| ["P", "10000000.00000000"], // price, 1 BTC = 10000000 NGN |
There was a problem hiding this comment.
I think this may be unpractical. It is better to have the price as a percentage difference from the price given by some exchange API, as Bisq does, for example.
There was a problem hiding this comment.
it works for liquid market (ie: USD or EUR), but how does this works for market in which there is no centralized exchange/price discovery with an orderbook?
There was a problem hiding this comment.
Why not support both. P could have a type flag that's either "static" or "dynamic". If it's dynamic then an endpoint is expected
There was a problem hiding this comment.
Why not support both.
I guess the main reason to converge to a single solution is that the more complex the spec is, the more cumbersome it will be for clients to build on top of it.
I think this may be unpractical. It is better to have the price as a percentage difference from the price given by some exchange API, as Bisq does, for example.
I think the solution @fiatjaf suggest would put more burden on the order taker, as opposed to the maker (which can typically be a market market, that could automate the price update using a replace e tag).
Also it would add complexity to the client because now client have to fetch price on the exchange (and manage all the use case like if the exchange doesn't respond) in addition to the nostr websocket connection.
My current thinking is that it should be optional for the client to compare the actual price than what is present on some exchange, but this comparison should be optional and serve as a reference. I think Paxful does that (show the premium/discount) but I need to double check.
|
Does it require a NIP? Because I have tested it for a project with basic nostr events and it works as expected. |
using event I guess this is my thoughts about it: https://github.com/nostr-protocol/nips/pull/405/files#diff-1a3de61680a29732cfe482cc8f4362e494a03ab61bb2d8a0eea98c2e2b6f21deR72 |
There should definitely be a separate kind for this... on the other hand I don't think making a nip for every single usecase works well. Maybe we should have a list of "application specific" kinds somewhere? Similar to the list of coins for derivation paths. |
|
I love the idea. I agree with @Egge7 that marketplace events should have their own kind. However I also think that we need relays to specialize on serving marketplace content. Because as adoption grows, the number of entries will become far too many for client side filtering. I see P2P trading as one sub-kind of marketplace event. Filters I would like to use to retrieve marketplace content:
I there is a agreement on this general schema, I can write up a NIP that roughly sketches this so that this P2P BTC pull request can build on it and move forward. |
11001.md
Outdated
|
|
||
| ### TODO: | ||
|
|
||
| - extend this nip with a kind for settled trades, __key__ extension, as it's the one needed to build reputation. |
There was a problem hiding this comment.
Interesting to start thinking on what is the assurance mechanism to avoid non-legit offers to be created and settled in the sake of building reputation reusable in other legit coordinators.
There was a problem hiding this comment.
I think the reputation should be out of the scope for this nip. It will be very similar at the end than what is coming up with nostr for the twitter use case. some sort of web of trust.
There was a problem hiding this comment.
If you want to have that trade protocol be based on reputation, you should think now how to do it.
The protocol problem is trivial but decentralized reputation is the hard problem. Centralized reputation is rather easy but you do not gain anything from censorship resistance as the fate of Local Bitcoin, Paxful shows us.
Web of trust is not the solution. It needs to include some costs, otherwise what prevents one from creating a web of fake identities. WoT is also a UX problem. Why has PGP WoT never become a great success? Its too complex and requires lot of work for verification and risk assessment.
There was a problem hiding this comment.
Web of trust is not the solution. It needs to include some costs, otherwise what prevents one from creating a web of fake identities.
how is this problem applying to this nip in particular? I think it's a problem that apply to all nostr use case (the twitter nostr use case have the same challenges) and should be address in a separate nip.
this makes sense. will incorporate the idea in the draft shortly. |
|
diving into your comment @bu5hm4nn:
|
|
Thanks for considering my comment. I was thinking in terms of general marketplace notes, of which P2P Bitcoin could be a category. Basically Craigslist/Facebook Marketplace on nostr. Location tags in the form of geohashes are mentioned in NIP-12 and use the tag 'g'. Not sure if any relay implements a search filter for them though. |
|
Thanks @Reckless-Satoshi for bringing this NIP to my attention. I have had a similar idea (many have these days) for using Nostr as a global order-book storage through relays, and to have an open inter-operable protocol so all potential clients implementations, liquidity providers, etc can be working with the same order book. Thus creating a much bigger pool of liquidity that would help bridging Bitcoin to TradFi, and thus enhancing adoption and price stability. I am however in the camp that is against bloating the Nostr base layer for specific applications. This includes even Bitcoin marketplace applications. The more NIPS an application depends on, the higher the likelihood it will not be implemented by some relays, and thus having less relays to bolster multicast decentralization. Ideally trade traffic is ephemeral and mixed into plain-Jane social media relays, and any specification inside trade messaging is a layer 2 specification on top of Nostr. For n3xB. My latest thinking is just to use tags for filtering, and use I do understand that client filtering will hit its limit eventually, but I'd consider it bike shedding before this takes off. If we look at Bisq or RoboSat volumes today, this would be a very good problem to have. |
|
Shouldn't there be a NIP for escrow services? Those'll be required for all sorts of nostrils apps, and it would be good to be able to broadcast an escrow service, specify which payment methods are supported (hodl invoices for e.g.), and which app types can use it as an escrow. |
|
|
||
| Optional tags are the following: | ||
| ``` | ||
| ["e", "formerEventId" ], // used for replace order |
There was a problem hiding this comment.
Check NIP-33, why not use "d" to allow order replacements?
Each order is unique based on its (kind,pubkey,d-tag) values and the most recent one will be the valid one.
|
|
||
| ### replace and delete | ||
|
|
||
| NIP-09 allows for the removal of an offer, such as when a trade is completed and liquidity is no longer available. |
There was a problem hiding this comment.
Instead of relying on deletions (or additionally), maybe a status can be used alongside the replacement mechanism? I feel like that would be more reliable than expecting relays to honour deletions.
Also maybe consider NIP-42 expirations.
| ### TODO: | ||
|
|
||
| - extend this nip with a kind for settled trades, __key__ extension, as it's the one needed to build reputation. | ||
| - nip for escrows (escrow could probably be the same than for the marketplace?) |
| - nip for escrows (escrow could probably be the same than for the marketplace?) | ||
| - extend this nip with optional bonds (a la robosats) | ||
| - specify how trade can be deleted | ||
| - geo for in person trading |
|
|
||
| An ecosystem where different clients use the same specification on how to create and settle trades would create a thriving environment where clients compete in their UX and product offerings, to the benefit of the users and the global liquidity of the network. | ||
|
|
||
| While it would be likely that clients are initially dedicated to this application, an ideal scenario would be that, over time, generic clients also integrate this NIP. This would incentivize a large group of users who would own Bitcoin, from zaps for instance, to trade with each other for local fiat currencies, without having the current barrier to entry of having a dedicated app. |
There was a problem hiding this comment.
To support non-dedicated apps, consider describing how to format an "alt" tag in the spec. NIP-31
There was a problem hiding this comment.
Is it possible to allow users to set a market price order? I mean, I want to sell bitcoin and get 10 EUR but instead of setting a bitcoin price I want to sell at the market price at the moment the order is taken with premium of 2.
for this I think we should indicate the API that is being used by the origin (Mostro, bisq, etc) and we need a tag for the premium
| tags: [ | ||
| ["D", "BUY"], | ||
| ["C", "BTC/NGN"], | ||
| ["P", "10000000.00000000"], // price, 1 BTC = 10000000 NGN |
There was a problem hiding this comment.
Users usually needs to indicate the exact amount of fiat, instead of having a price tag, we should have a fiat amount tag, the price is calculated after the user indicates the both prices
There was a problem hiding this comment.
I thought this better, we also should allow to add a price tag, but only one of both should be mandatory, users that use price tag don't send the fiat price and the other way around
| ["m", "0.0001"], | ||
| ["M", "0.001"], | ||
| ["E", String(Math.floor(Date.now() / 1000) + 3600)], // 24h expiration | ||
| ["c", "lightning/ACH"] // payment methods |
There was a problem hiding this comment.
I think this tag should be for fiat payment methods, and we should have another tag to indicate if is onchain or offchain
|
|
||
| Optional tags are the following: | ||
| ``` | ||
| ["e", "formerEventId" ], // used for replace order |
I gave this some thought when drafting https://github.com/nobu-maeda/n3xb/blob/master/specs/maker-note/maker-note.md . I am trying to envision an architecture that minimizes reliance on a central coordinator. To create a market price order, the Maker and the Taker will need to agree on which price quote to use, a sort of mechanism to negotiation and establish agreement on this is needed. See n3xB on my current proposal. Again, I am hoping P2P trading protocol to be a Layer 2 protocol. I don't think a NIP is necessary and will bloat the Nostr protocol. And also, only just one NIP and a single event message is probably insufficient to establish and complete a trust minimized trade anyways |
|
@nicolasburtey The title on this NIP is pretty rough. Do you want to change it to something like "Peer-to-Peer Trading"? |
very first draft of a p2p trading spec. more work is needed but early feedback would be appreciate to see who else can be interested by this nip.