Address Coordinator as a source of Trust

[nobu-maeda]

One of the key limitations Bisq and RoboSats has is that Maker offers are often very rigid. If a Maker have a buy offer for 0.1 BTC, a Taker hoping to buy only 0.01 BTC cannot take that offer.

Ideally, the protocol should be able to support such that an offer can be taken partially, and thus multiple times, before the offer is considered fulfilled and invalidated. Whether this is enabled depends on client implementation and potentially an option to the Maker. Ultimately whether a partial fill is acceptable to the Maker is up to the Maker and client implementation/defaults. The protocol level should support and not prevent this.

[Reckless-Satoshi]

Hey @nobu-maeda, had a great deal of fun reading over your ideas. Nice work!

I hope to be able to lay out some ideas and concerns and contribute to the development.

Edit: to be concise, everything I say below applies mostly to the LN pipeline, where mediator/arbitrator/node must necessarily be the same party.

Concerns

My main concern is the largely forgotten role of the coordinator as source of trust. This is a problem that seems to come up in most Nostr p2p schemes (also in the draft nostr-protocol/nips#405 ). It seems to be taken seriously only by Mostro and the RoboSats federation.

Ultimately whether a partial fill is acceptable to the Maker is up to the Maker and client implementation/defaults.

Wouldn't the coordinator have to support it as well? I think this issue is an example of how one forgets of the role of the coordinator. The fact that a maker could create an order and post it on Nostr without a coordinator first agreeing to host the trade (be the judge) is akin to a maker posting an order on Craiglist, Twitter or Reddit (it's a bit crazy! :D).

The coordinators are the judges, source of trust, escrow party, possibly also the pricing oracle, will charge commission/rates, have access to private information, can slash bonds or issue negative reputation, have to process collaborative cancellations, or unilateral cancellations, etc. Many rounds of communication between maker/taker <-> coordinator are needed. That means: the coordinator must always be online or the trades will fail or get stuck. Given that fact, the only thing we are decentralizing with Nostr is the messaging layer (at the cost of privacy): so we have to evaluate what is the worth of enabling direct maker <-> taker communication if the source of trust can go offline at any moment during a trade. And it if is worth it, whether Nostr is the right channel (certainly not the most private).

To streamline the experience and avoid messages that do not arrive (or are right away censored by relays), one could think that it is best if the trade coordinator acts as relay. Not far fetched, given that the coordinator has to be always online anyway. You see how this goes from here: we end up again having something like RoboSats but with very bad privacy (i.e., the RoboSats Federation would be strictly superior RoboSats/robosats#228).

Summary: Decentralizing the communication with Nostr does not improve trust issues or p2p pipelines (this is also clear in your writings). However, unifying all order of all p2p coordinators is important and is the key point of this project. Creating a bigger liquidity pool will certainly make p2p more mainstream. However, there are many ways to have a common order book: Nostr possibly the best one, but it could be as simple as other existing tools that are already used by many e.g., https://github.com/j4imefoo/nokyc.

Ideas

I would start small. First by letting all existing coordinators (hodlhodl, agora, bisq, peach, lnp2pbot, any robosats runner...) publish orders in a standardized Nostr-centric way. Each order goes with instructions for takers on how to proceed for any trade-kind (given how widely diverse the different existing p2p pipelines are, best is to not impose a predetermined one). Therefore, orders will have to either:

1. orders are posted in Nostr directly by the coordinators (they first have asked for bond/reputation).

2. orders are posted by the makers with one or several designated coordinators. Then the coordinators will reply signing that they are willing to host the order after a successful check of the maker (reputation or bond).

IMO without a coordinator backing an order, it is just noise/spam, the Nostr p2p book will be filled with orders of makers that have no intention to follow through and without any coordinator willing to host the trades. For an order to be considered as "posted", the bond/reputation must be placed first. A taker will also have a hard time taking an order if he does not know who will host it (Who judges a dispute? What are the fees? What is the privacy policy? etc).

Other sci-fi cool-ass ideas (that fit perfectly af)

A real naive light-weight p2p protocol without coordinators can be done. Inspired by the 2-2 overcollateralized escrow vision of Satoshi (source https://bitcointalk.org/index.php?topic=750.msg8140#msg8140) Both maker/taker will stake a higher amount than the traded one in a 2-2. Their intention will be to act in such way that the full amount is not burned (cooperate), so disputes have to be solved without an overseeing third party. As no one wants to burn BTC it is unlikely to be used by anyone to scam (on purpose). But humans are stupid, so you never know what might happen when you enter a trade :D. The cool thing about this one is that it can be done 100% from Nostr client-to-client without the need of any external source of trust. It really can take the most out of Nostr and so far it has not been built because it is "difficult for traders to find each other".

TLDR: I think the current naive proposal, is too naive . Nonetheless, it is opinionated enough to be a new trading platform itself. I think however, the intention is to be a unifying force for all existing order books (which would be amazing!), and for that to happen there are very low hanging fruits we should purse first (e.g. unify order books in Nostr. That gets us 80% to the goal with only 20% the work).

Once again, congratulations on this initiative. Hoping to have some time soon to give a second read: I am sure some of my concerns above might actually even disappear on a second read :)

[nobu-maeda]

@Reckless-Satoshi Thanks for giving this a detailed read. Having you giving it a read and providing feedback means a lot to me!

What I was envisioning with n3xB is precisely just a protocol for all the existing 'coordinators'. Even tho I view them more as liquidity pools instead of coordinators. And I'd argue that Bisq, the gold standard, has only arbitrators (and only after a 4 days timeout expiry), and no coordinators. I think the other platforms you mentioned starts to have a larger and larger coordinator role, up to entire registered companies in clear-net webservers acting as custodial coordinators. I did use RoboSat extensively in my examples, but after going through the exercise and inspect the inner working of RoboSats, I did also realize that if I am to launch the initial proof of concept, I'd have to become a coordinator myself to make things work. So the current mental model and the proof of concept I am working on is really just a simplified version of Bisq (no reputation model), but relayed through Nostr to make it more friendly for mobile clients.

Ultimately tho yes, what we really need is just a standardize messaging scheme to coordinate all sort of different settlement pipeline and schemes in and open extensible format spread across dumb relays. I am actually pretty against reliant on much relay level support, as needing specific support makes this much less censorship resistant. If marketplace traffic are just going to be ephemerally placed and taken off existing Nostr social media relays, that'll be the most ideal.

The base 'naive' protocol should be flexible so that if anyone, Bisq, hodlhodl, peach, wants to create a new settlement pipeline, they can. But I hope overtime it'll boil down to mostly only a few settlement formats, so that we maximize liquidity in the most common trades. It'll probably be a UX nightmare if there are going to be dozens of settlement schemes that clients and users have to work against.

My very first stab at this was actually trying to create a mobile client for Bisq. But the whole Bisq project is moving way, way too slowly. Their architecture was also highly unfriendly to mobile clients, which most of the real world runs on. Why I started n3xB once I discovered Nostr. So I don't think we can wait for all the existing 'coordinators' for buy-in before moving forward. I do hope for more collaboration so that the base layer is going to be sufficiently open and adopted by existing players tho.

Thanks once again for your attention and feedback!!

PS. I have no problem against a 2 of 2 mutually assured destructive bonds, without 3rd party arbitrators. The protocol should not limit this arrangement. Clients can decide to provide these trades to users if they want, caveat emptor.

[Reckless-Satoshi]

Thank you for the further explanations. And again for all the work you are putting into this project. To be honest, is very refreshing to see bold moves for freedom like this.

I'll use this reply to more pedagogically explain why the coordinators are so important and why there is no coordinator-less model. Please, double check what I am going to say below about Bisq, this is something I haven't checked back for a long time and a quick look at Bisq FAQ does not mention these exact details.

And I'd argue that Bisq, the gold standard, has only arbitrators (and only after a 4 days timeout expiry), and no coordinators.

It is indeed the most coordinator-less exchange. However, there is the implicit mandate for the Bisq DAO to obverse any order posted in the Bisq protocol. There is no only mediators and arbitrators, there is an "escrow party" to which any 2-2 order can be spent (technically "burned to the donation address" https://bisq.wiki/Donation_Address_Owner ). I think the time-lock is 10 or 20 days depending of the trading pair. Then it is up to Burning Man (a bonded Bisq role bisq-network/roles#80) to return the escrow to the one user the arbitrator suggests (yet, these could be not returned!). Of course, the Bisq DAO has garner a great reputation and this model works well, the dispute resolution process is brilliant. But do not be mislead, the DAO is a critical part. Posting an order in Bisq is not akin to posting an order in Twitter/Reddit/Nostr without a designated coordinator: collateral is put upfront, the fees are known, the dispute resolution process is known, the privacy policy is known, the DAO's reputation is known, its governance model is known, etc. This is a coordinator (albeit a decentralized one).

Let's make a mental exercise. Let's imagine there is a new p2p platform called Busq . It is a perfect Bisq replica, you can verify it is the same code and protocol. However, you do not know where this new DAO came from (it has no reputation or you cannot verify its governance scheme). Would you post the first order? I would advise against posting an order there, because the coordinator, even if the design is close-to-perfection (~decentralized), are always to be trusted. For example, in case of dispute the new DAO could not return the Sats to the user the arbitrator suggests.

For an order on a messaging protocol like Nostr to have the same properties as an order posted on Bisq, a lot of overhead must be put in place to create trust on the protocol itself (...the Bisq boilerplate), this would constrain the flexibility of the protocol: probably it would become a new p2p platform.

With all that said: I am sure a naive approach where users can make / take orders with not coordinator involved from the begging WILL WORK. It will work because current bitcoiners are good people :) However, it will not fare well in the long run once it starts to receive attacks.

I am sorry to insist on the low hanging fruits :D There are easy and simple ways to contribute significantly towards a bigger p2p market by: 1) focusing on a joint order book specification or 2) use a real coordinator-less scheme like the mutually assured destruction one (...this would be a new p2p platform though).

[Reckless-Satoshi]

Given that this issue has derived into a different topic and the topic at hand is possibly more relevant than the initial one. What do you think about re-purposing (renaming) this issue? This thread could be framed as an open discussion about the possible short-comings of assigning a coordinator after the order is posted.

[nobu-maeda]

@Reckless-Satoshi Thanks for keeping this discussion strong!

I agree with most everything you've said, except for describing Bisq as an escrow. Perhaps an arbitration escrow, but not a trade escrow. From my understanding 90%+ of trades never gets into arbitration and as such never gets into the hands of the Bisq DAO. Only the fee portion does. We can definitely describe an arbitrator as a coordinator tho. Its really semantics and probably more useful looking at the difference in magnitude rather than categorically.

Irregardless of how large a role a coordinator should have for the specific trade mechanic, my intention is to have a protocol so that it supports any schemes. I guess a way to frame it is to view it as - how can we minimize trading platform fragmentation and maximize the separation of concerns in the different components of a p2p platform? My guess is that's why Nostr succeeded because no one owns the network effect, not even fiatjaf or Damus. Developers feels a sense of ownership when they jump in to create a new relay implementation, a new client, or runs a relay, etc. And each can build on top of some other library and component only do the necessary portion to put in their unique spin, without reinventing the entire wheel. And definitely without bootstrapping and recreating the 2 sided market and network effects.

The counter-example would be Mostro vs RoboSats. Mostro is essentially building everything from scratch, despite the trade mechanics being almost identical to that of RoboSats, just to put in their spin (of putting on Nostr I assume). Not many are also keen on building clients for Robosats either, as I suspect its viewed as someone else's project and subject to platform risk, instead of an open protocol that anyone feels empowered to build on. Same case for Bisq as no one in the past 8 years felt empowered enough to build an independent project on top of Bisq. This is in contrast to Nostr which have dozens of client and relay implementations in less than 2 years. The latter is what we need for P2P trading.

In terms of the specifics of coordinators. My current published proposal actually has the maker suggest an array of pubkey of potential arbitrator/coordinators, which the taker can select from. Coordinator/arbitrator selection criteria for now is out of band of the protocol, as one shouldn't trust everything thru the protocol anyways and should have an independent mechanism to establish any trust necessary. In the end I'm hoping for a marketplace of inter-compatible coordinator/arbitrators, instead of decentralizing a single coordinator like the Bisq DAO. I think this is only achievable by having the order-book inter-compatible and open. If the orderbook is coupled to the coordinator, this marketplace of coordinator is no longer possible, not without fracturing the orderbook.

I am updating the protocol proposal to reflect my latest understanding, and hoping to see if I can come up with something that Mostro will agree to adopt and make inter-compatible with. Will ping you once I have that, and a proposal for Mostr to consider, available. If we have at least 2 trade mechanics built on an implementation neutral n3xB base protocol, maybe that will instill confidence for a plethora of inter-compatible solutions to build on-top.

I think Mostro is heading towards the right direction. But its not protocol centric and generic enough. I'd suspect developers are concerned Mostro being a single project which owns the protocol, creating the perception of platform risk I mentioned. If n3xB can be the equivalent of Nostr and nothing more than protocol, and Mostro being just one implementation of it (I call it trade mechanics), that might alleviate that perception and inspire a Nostr like proliferation of p2p development.