[GAP-22] Invoice-based reputation system

reputation/invoice_based_reputation.tex

@@ -0,0 +1,192 @@
+\documentclass{article}
+\usepackage{amsfonts}
+\usepackage{amsmath}
+\usepackage{hyperref}
+
+\title{Invoice - based reputation system}
+\author{Jan Betley\\ Golem Factory}
+
+\begin{document}
+\maketitle
+
+\section{The main concept}
+
+General note: this is a crude description of an idea, not a "final" design I'm covinced will work.
+IOW, this document should be enough for discussions and future plans, not something we can now go and implement.
+
+\subsection{Assumptions}
+
+The most important assumption in this document is the expected utility maximization hypothesis\footnote{
+\href{https://en.wikipedia.org/wiki/Expected\_utility\_hypothesis}
+     {https://en.wikipedia.org/wiki/Expected\_utility\_hypothesis}
+}: providers and requestors will do what they think is best for them, and the main purpose of the reputation system
+is to construct an environment where the most profitable behaviour is also the desired behaviour.
+
+Few more assumptions (some of them are questionable even as approximations - there is a further section discussing them):
+
+\begin{enumerate}
+    \item The ground truth about all payments on the market (timestamp, amount, sender, receiver) is known.
+    \item The ground truth about all invoices on the market (timestamp, amount, sender, receiver) is known.
+    \item Obtaining \& parsing the data about invoices/payments costs neither money nor time.
+    \item The only thing provider cares about is "how much I will be paid?" and the only thing requestor cares about
+        are the quality of the services received and amount paid.
+    \item The market is balanced, i.e.: 
+        \begin{enumerate}
+            \item Good enough and sufficiently cheap provider will spend no more than X\% of time waiting for agreements, for a reasonable X (e.g. 10\%).
+            \item Requestor willing to pay a sufficient amount of money will find enough providers fast enough
+        \end{enumerate}
+\end{enumerate}
+
+
+\subsection{General idea}
+
+The full knowledge about invoices and payments gives us a crude approximation of the "reputation-like" information: 
+good requestors pay, good providers are paid. In more detail:
+\begin{enumerate}
+    \item Provider POV: the requestor who paid bigger part of their past invoices will more likely pay another invoice than another requestor
+        who paid less past invoices.
+    \item Requestor POV: the provider whose invoices are usually paid more likely provides high quality services than a provider who is paid
+        only rarely or never.
+\end{enumerate}
+
+Justification behind these statements:
+\begin{itemize}
+    \item Both first and second: providers/requestors market strategy rarely changes, so it's likely that when trading with us
+        they will behave similarly to the way they behaved in the similar past situations.
+    \item Second: if a requestor doesn't pay the provider, they are less likely to trade with them in the future (e.g. because of the provider's local history), 
+        and thus requestors more often pay providers they want to trade with, and those are more likely the providers we want to trade with.
+\end{itemize}
+
+\subsection{Detailed strategies}
+
+There are countless possible strategies that are consistent with the main idea, strategies in this section are just examples.
+
+Provider strategy:
+\begin{enumerate}
+    \item Gather a local history of all our contracts - (requestor id, invoice amount, paid amount) + additional details (e.g. agreement length, initial demand etc).
+    \item Send offers to the market with "base" prices, that will later (in the negotiation phase) be increased for untrusted requestors.
+    \item When a requestor responds to the our initial offer:
+        \begin{itemize}
+            \item If this is a new requestor (i.e. one that didn't yet trade with anyone on the market, or didn't trade enough):
+                \begin{enumerate}
+                    \item Counteroffer with a "payment in advance" property
+                    \item If accepted, start with sending a debit note (for some fixed amount) with a short payment time
+                    \item Refuse to start an activity until the first debit note is paid
+                    \item Continue in the same manner, i.e. request upfront payments
+                \end{enumerate}
+            \item If this is a requestor we've already traded with, and they didn't pay all the due amount:
+                \begin{enumerate}
+                    \item Add the missing amount (possibly with some discounting factor) to the fixed amount
+                    \item If agreed, start with sending a debit note for the missing amount, with short payment time
+                    \item Refuse to start an activity until the debit note is paid
+                \end{enumerate}
+            \item In other cases, i.e. when requestor has some experience on the market and they either didn't trade with us or paid a full amount:
+                \begin{enumerate}
+                    \item Estimate the \% of the final invoice we expect the requestor to pay us. In the most primitive version this might be just the \%
+                        of their invoices they paid until now, although this can (and should) be done much better\footnote{E.g. if they didn't pay a provider that is
+                        never paid, there's a big chance this is an invalid provider who just does no work at all, but if they didn't pay a provider who's usually
+                        paid fully then probably something's wrong with the requestora.
+                        We should also include in the estimations few other types of the information, e.g.
+                        \begin{itemize}
+                            \item Our own experiences with this requestor (i.e. requestor who dutifully paid us a lot will probably pay again).
+                            \item Expected agreement length, proposed payment interval etc.
+                        \end{itemize}}
+                    \item If we estimate $\sim$100\% of the invoice will be paid, accept the offer. 
+                    \item If we estimate less will be paid, reply with a counter-offer with higher prices, so that they compensate for the \% of the invoice
+                        we expect not to be paid.
+                \end{enumerate}
+        \end{itemize}
+\end{enumerate}
+
+Requestor strategy:
+\begin{enumerate}
+    \item Gather similar local history as the provider
+    \item Sign agreements that require an advance payment only with providers you have a reason to trust 
+        (e.g. because you traded with them before or because they have a good history on the market)
+    \item Except for the previous point, just try to sign the most profitable agreements, including any information about the "provider quality" you have.
+        This should include "high quality providers are paid more often than low quality providers", but also other things like "provider benchmarks" or
+        the history of the requestor's trades.
+    \item Provider sends debit notes/invoices stating the expected amounts, but requestor decides freely about the amount paid (they might also decide not to pay at all).
+        When deciding about the amount to pay, consider a following tradeof. The less money I pay:
+        \begin{itemize}
+            \item (gain) The more money I still own.
+            \item (loss) The more expensive deals I will have with other providers, especially if I decide not to pay a provider who's usually paid.
+            \item (loss) The more I will have to pay to trade with this provider again.
+        \end{itemize}
+        And pay any amount you consider best from your POV.\footnote{
+            This should somehow converge to "the worse is the provider, the less we want to pay" - and that's exactly what we want.
+        }
+\end{enumerate}
+
+\subsection{The reputation system deployment process}
+
+So we have defined some strategies for requestors/providers.
+Who will use them? How to encourage others to use similar strategies?
+The plan looks as follows:
+\begin{enumerate}
+    \item Implement provider/requestor strategies described above. Set them as default provider strategies and recommended requestor strategies.
+    \item Put on the market enough providers/requestors who use these strategies.
+    \item (Crucial assumption that should be analyzed) When a new provider/requestor enters the market, they use these (or similar) strategies, because they
+        are the most profitable. Thus, as the market grows, the adoption level of these strategies remains high.
+    \item Finally, we can remove the initial providers/requestors and the reputation system will still work.
+\end{enumerate}
+
+\section{Discussion}
+\subsection{Assumption 2 - ground truth about invoices}
+
+This is hard, and this must be solved well for this whole idea to work.
+There are two general directions:
+\begin{enumerate}
+    \item Implement some logic that will enforce this ground truth, e.g.:
+        \begin{itemize}
+            \item Put invoices on some additional chain
+            \item Require invoices to be signed by both sides (?)
+        \end{itemize}
+    \item Drop this assumption, but modify the strategies so that "agreeing on the invoice amount" will be profitable for both sides, e.g.
+        \begin{itemize}
+            \item Both provider and requestor "report" invoices somewhere
+            \item For the requestor it's always (or usually?) better to report the same value that was reported by the provider
+            \item For the provider it's always (or usually?) better to have the invoice value confirmed by the requestor
+        \end{itemize}
+\end{enumerate}
+
+\subsection{Assumption 3 - obtaining/parsing invoice data cost}
+
+We'll need a node information API (GAP-14) that will gather the data and provide useful simple aggregates that will be consumed in strategies.
+
+This looks like a fully centralized solution, but:
+\begin{itemize}
+    \item If the invoices are gathered in a public location (e.g. a side chain) then there can be multiple different APIs aggregating the same information.
+    \item If the invoices are gathered in a database without a public access, then there could be some other entity who also gathers invoice data.
+\end{itemize}
+
+\subsection{Other assumptions}
+
+\begin{itemize}
+
+    \item Assumption 1 (payments ground truth) is true, because we pay in crypto.
+    \item Assumption 4 (providers care only about money, requestors care only about service quality) is false\footnote{e.g. requestor would also want their data not to be stolen.}, but this is simply what this reputation system gives us - and it's quite a lot,
+hopefully enough for a "serious" start of the market.
+    \item Assumption 5 is fulfilled for any functioning market.
+\end{itemize}
+
+\subsection{Misc random notes}
+\begin{enumerate}
+    \item There is a malicious strategy available:
+        \begin{enumerate}
+            \item Put my own providers and requestors on the market
+            \item Trade between them only until their reputation grows enough
+            \item Use requestors to steal from other providers, use providers to steal from other requestors
+        \end{enumerate}
+        This is an important problem, but hopefully solvable:
+        \begin{itemize}
+            \item Because of the transaction costs, building up reputation this way costs
+            \item Provider-requestor clusters like this will be visible in the data. E.g. a provider who got paid by X different requestors surely looks better than
+                a provider who was paid multiple times by only one requestor.
+        \end{itemize}
+    \item Maybe debit notes would be better than invoices? This seems to be a good direction, because it gives us an additional useful information - 
+        the amount accepted by the requestor. Accepting and not paying later is much worse than just rejecting the debit note.
+    \item The obvious vulnerability is that if an estabilished requestor (i.e. not paying in advance) intends to leave the market, then there's no
+        incentive for them to pay the last invoice(s). This is true, but not really important - estabilished requestors will be rarely deciding to leave the market.
+\end{enumerate}
+\end{document}