null
Merge request reports
Activity
I am personally curious how you would compare the intended product with something like OpenBazaar. The issue of trust can become quite hairy, in particular how to do reliable escrow with a 'centralized' database that might MitM (and so on).
Edited by koe
I've never used OpenBazaar and don't see it mentioned much in the Monero circles, so my understanding is limited to what I can see externally. Here are my comparisons after briefly reviewing OB:
-
I'm not proposing to create a decentralized marketplace, just an application which stores data in a central database. Users would in fact have to "trust" the platform/service. It would be open-source and available for anyone to run a clone of (if they wanted to). Many vendors would not be comfortable doing business on a trustless, decentralized marketplace and need some semblance of trust instead.
-
There would be no client side application or external software; it would be purely web-based.
-
Web stores/vendors would have clear, human readable URLS, ie
mycompany.example.com, whereas OB has hashed/randomized URLs -
It would be Monero only. OB seems to only support BTC, BCH, LTC, and ZEC (except for some of the trading).
-
An escrow process would be built into the platform and defined as code. The RPC interfaces of daemons and wallets would be used to gather metrics about transactions, balances, inventory, etc and application logic would guide the process along. This is a generic answer but the details are in the implementation. This is how I handle escrow in my auction app: https://github.com/lalanza808/xmrauctions/blob/master/bids/views.py#L116 and https://github.com/lalanza808/xmrauctions/blob/master/sales/tasks/payments.py#L13 - a new account gets generated on an RPC connected wallet - the wallet account gets tied to the item sale - background jobs poll the RPC interface of the wallet and wait for incoming funds - when all conditions are met, the process continues.
-
The web-based nature of the app means that vendors and buyers only communicate with the frontend, while escrow and business logic resides in the backend. TLS mitigates any real MitM attacks. The other attack vectors are mitigated by solid application logic, clean and tested code, and good systems administration and operational security practices.
-
Nothing wrong with more competitors :)
Edited by lza_menace-
"Users would in fact have to "trust" the platform/service. It would be open-source and available for anyone to run a clone of (if they wanted to)."
This may be the hardest problem any project like this faces, since there is no clear way to verify an open-source code base is actually deployed by the service. Certainly there are many such projects that are totally honest and trustworthy, while there are many others that absolutely cannot be trusted and end up stealing people's money. Moreover, the dreaded TLAs can compromise any system like this, which is a special pain point for the typical modern Monero enthusiast (perhaps a bit less painful for the typical user).
I am not saying it's not worthwhile, and I have myself put thought into the same thing recently. It seems possible to do a lot of encryption, and defend in that way against TLA access. However, that is only effective for historical data. After TLA access, which might well be undetectable to users, the data is no longer secure.
It's also possible to implement real multisig between users and vendors, with the service as escrow. However, with the service as message transport, it's not possible to know if the service is compromised and in fact MITM of the conversation.
The best counter point is that transaction amounts in a marketplace are often quite low, especially in a very new service which hasn't established a reputation. Low volume == low risk.
In conclusion, I hope other users can weigh in, since markets using Monero are essential, and making the best decisions to chase that version of the future is very valuable.
-
@pricode that's pretty much the plan!
-
@koe I've amended the PR based on some good feedback I received. The goal now is to build an open source web store application that anyone could launch or run on their own with simple mechanisms to provision on popular cloud providers. Would love to get your feedback now that it's not a centralized platform.
Your revision certainly addresses the problem of MITM, and the more general problem of a dishonest marketplace operator. I think there is an interesting trust matrix here.
Dishonest buyer: In all cases, dishonest buyers are not a problem since they must provide payment before receiving a product. The issue of DDOS is unrelated to trust.
Centralized marketplace
Dishonest vendor: An honest marketplace operator will swiftly delist any vendor who misbehaves, so buyers that trust the operator can be confident most vendors are legitimate. Dishonest vendors are fairly low risk to buyers, since at most they will lose the value of one purchase. Dishonest vendors are high risk to operators, since an operator's reputation depends in large part on having reliable vendors, so this fact means even dishonest operators are likely to enforce honest vendors.
Dishonest operator: A dishonest operator may be undetectable right up to the moment they exit scam. So long as buyers don't deposit money with the marketplace (i.e. just pay vendors directly), it's unlikely an exit scam could be very profitable. However, a dishonest operator may MITM any communications between vendor and buyer, and even honest vendors wouldn't have an easy way to avoid that risk.
Solitary vendor
Dishonest vendor: It is the vendor's responsibility to develop a reputation. Since they can't piggy-back off the operator's reputation, it may be relatively harder to get customers. Advanced multisig capabilities, where the escrow agent/moderator is a separate third party, would likely improve that situation greatly, although the technological/infrastructure challenges are non-trivial. Again, dishonest vendors are fairly low risk to buyers, since at most they will lose the value of one purchase.
Honest vendor: Honest buyers and vendors can interact without worrying their communications are compromised.
I think your revision escapes the difficult problem of setting up a trustworthy marketplace, and makes this proposal more appetizing, and also perhaps more likely to see adoption (not that I'm qualified to evaluate that kind of thing).
Edited by koe
Is it possible or worthwhile to include some scope to easily integrate with other payment processors, for example GloBee, Monero Integrations, Stripe, etc? Flexibility through API/plugins seems important to me.
Maybe this is already covered, and if so, can you walk me through how the payment process would work? I think some extensibility for fiat conversion would be used in 90%+ of cases.
-
@sgp My first thought was to not setup any payment processors or third parties and just include a dedicated wallet endpoint with the app deployment; was not planning any currency conversion since other projects/services already do that.
In that scenario of having a wallet RPC endpoint available the application would make API calls to the wallet to handle payments. For example, if a visitors goes to purchase items a "sale" object containing the items in the cart gets created, a new wallet account gets generated on the RPC connected wallet, the wallet account gets tied to the item sale and user, the visitor is provided the wallet address to send funds to, background jobs poll the RPC interface of the wallet and wait for incoming funds, and when all conditions are met, the process continues (seller can ship the item after confirmations).
However, having a wallet endpoint and node to manage can be a bit clunky. I would be open to building integrations into the application if the community finds that route more enticing; it would likely be much simpler to manage. I'll research the available payment processors just to have a better understanding of what's required to integrate.
Edited by lza_menace
