<p>An idea on how to move forward with light clients, where to focus the efforts with the API and how to grow the Bisq user base.</p>
<h2>Motivation</h2>
<h3>Safety</h3>
<p>Now that Bisq has an API it will be possible to build light clients that connect to a bisq-daemon running on a VPS or similar. There are risks with running software that controls private keys on a VPS as they are potential targets for hackers.</p>
<p>In the case the server is set up to cater to multiple users there is also an additional risk that these users take by trusting the operator of the server.</p>
<h3>Convenience</h3>
<p>There are some hurdles for new users to use Bisq. One is the requirement to own some BTC to be used as deposit during the trade. Then there is the need for a desktop app that needs to be downloaded and installed. The first one might be overcome by allowing for independent operators to onboard users as they see fit, using credit or other means. That would be made possible by moving certain aspects to a light client in the form of a mobile app that connects to a server, which alleviates the problems of downloading and running a desktop client.</p>
<h2>Requirements</h2>
<p>As users would connect to a bisq server through the API they would currently expose their full account information, BTC and BSQ private keys and trading history to the server. It is assumed this server would be run by the user themself with only one server per user. This is rather inefficient and not easy to set up for the average user.</p>
<p>To allow for federated bisq servers to be used by light clients and still preserve the most important aspects of a decentralized trading platform a minimum of the following criteria should be fulfilled</p>
<ul>
<li>The server should not be able to steal funds</li>
<li>The server should not see account information of users</li>
</ul>
<h2>Implementation</h2>
<p>Let's focus on the case where the user is the maker as it's the harder case. If the user were the taker they would be online while taking an offer and the rest of the protocol is the same for takers and makers.</p>
<h3>Private Keys</h3>
<p>To allow the users full control of their BTC they will have to be available to sign transactions throughout the trade process. In particular they need to be available to sign and fund the deposit transaction while an offers is being taken. As the maker they need to react to the request from the taker to sign the deposit tx. This seems doable with a light client app running on a phone reacting to a notification from the server, but it might be too slow.</p>
<p>The BTC keys can be stored with the phone client and the bisq server would not be able to steal the funds.</p>
<h3>Accounts</h3>
<p>Account information is currently stored with the bisq client. To avoid that the bisq server could access account information it could instead store accounts as accountAgeWitnesses hash and payment method. During a trade the server would forward mailboxmessages from lightclients to the other user.</p>
<p>It might be that accounts are not needed at all on the server side and could be provided by the light client on demand, that might be even better.</p>
<h3>Network</h3>
<p>The phone client would run a Tor hidden service to connect to the server. This likely has some problems with either reliability or battery usage or both. More research is needed to see if this is a reasonable way forward.</p>
<p>Chat messages from trades, mediation and arbitration would have to be forwarded. Handling payout of funds in all these cases would also have to be done on the light client.</p>
<p>It would also be worth thinking about adding other options to connect to the bisq-daemon. It could then act as a bridge to the Bisq network for those that aren't able to use Tor.</p>
<h3>Fees</h3>
<p>The trading fees could be paid in BSQ by the bisq server and charged to the users in BTC. There is already the fee tx to initiate an offer and by adding a BTC change output that's controlled by the server and the server adding the fees in BSQ the server can charge users while fees are paid in BSQ. This would be a way to fund these servers by charging a markup on the BSQ fees but still a discount compared to fees paid in BTC.</p>
<h2>Drawbacks</h2>
<p>This kind of federated server setup would centralize parts of the Bisq network and give control to the server operators. There is however no barrier to entry to setup these servers so anyone could do it. The users of this kind of server might be users that would otherwise not have the ability to use Bisq, in that case it would still be an improvement from the users perspective.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/174?email_source=notifications&email_token=AJFFTNTFAD3ZOXE5PFOAVXDQ7XAXXA5CNFSM4KLYCPWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIYSYYQ">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNU7YVJXI4TI2S5JWQLQ7XAXXANCNFSM4KLYCPWA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNTDKJWTYHWZHUV76J3Q7XAXXA5CNFSM4KLYCPWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIYSYYQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/174?email_source=notifications\u0026email_token=AJFFTNTFAD3ZOXE5PFOAVXDQ7XAXXA5CNFSM4KLYCPWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIYSYYQ",
"url": "https://github.com/bisq-network/proposals/issues/174?email_source=notifications\u0026email_token=AJFFTNTFAD3ZOXE5PFOAVXDQ7XAXXA5CNFSM4KLYCPWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIYSYYQ",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>