Fixed term BTC loans against BSQ collateral

[stejbac]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Basic Idea

In a similar vein to the BTC-BSQ atomic swap idea proposed in #50, I believe we may use the special properties of the BSQ token to implement on-chain collateralised BTC loans in a fairly safe and simple way.

To set up a loan, a BTC lender can create and sign a repayment transaction (which atomically repays the lender and returns the locked up BSQ collateral) using SIGHASH_ANYONECANPAY. Crucially, this allows the borrower to add whatever input(s) he pleases when closing the loan, so the repayment can be any valid source of BTC whose amount exceeds the tx output sum.

Additionally, the borrower signs and sends the lender a timelocked transaction to confiscate (i.e. pay to a lender-supplied address) their collateral in the event that they default.

Upon exchange of these two prepared transactions, the borrower may then safely lock up their BSQ collateral in a 2-out-of-2 multisig address in exchange for the BTC loan. This may be done either as a BTC-BSQ atomic swap as described in #50 or using the existing trade protocol.

Repayment before the deadline (or confiscation in the event of default) may then be done unilaterally, without needing any cooperation or contact with another party.

Motivation

Due to the very limited trade fee revenue right now, there is a lack of liquidity in the BTC-BSQ market and any modest increase in sell pressure is apt to plunge the price. This was particularly bad a couple of weeks ago (at the end of January), it seems, where BSQ was trading at less than 5000 sats, even though it's been around double that for the previous six months, as seen in the dashboard:

Under such circumstances, BTC loans would possibly have been very useful. It would have made a lot more sense for those impatient to sell their BSQ to simply borrow BTC against it, instead of selling it anomalously cheap and crashing the price further. In short, loans could be a useful way to provide a short term cash injection to prevent a liquidity crisis, allowing BSQ sellers to get a fairer price.

Perhaps more controversially, such loans to individual BSQ holders could be seen as a means by which the DAO can effectively borrow money collectively, which could then be used to fund growth without having to worry too much about balancing the budget in the short term. Much like a startup receiving a bank loan to fund crucial development prior to becoming profitable and then needing to pay it back. In the event that too much money is borrowed, a long squeeze would ensue, causing many borrowers to default and much of the BSQ used for staking ending up in the hands of the creditors.

More Detailed Example

Suppose Alice were to borrow 0.5 BTC from Bob against a 10000 BSQ collateral, repayable after 2 months with 5% interest per month (80% APR). Then any time before the 2 month deadline, Alice must pay Bob 0.55125 BTC to claim back her collateral. This could proceed as follows:

1. Upon Alice taking Bob's offer of a loan, Bob sends Alice his public key for the 2-2 multisig BSQ collateral lockup, as well as his BSQ confiscation payout address.
2. Alice signs and sends Bob the timelocked confiscation transaction, with 2 inputs (BSQ collateral at P2SH address + BTC mining fee) and a BSQ output. This is possibly also anyone-can-pay & SIGHASH_SINGLE to allow Bob to add whatever mining fee he pleases (or alternatively have Bob construct the tx). Alice also sends Bob her BTC loan receipt address and her BSQ collateral repayment address.
3. Bob creates a payout tx template, signs it using SIGHASH_ANYONECANPAY and sends it to Alice. The template has a BSQ input (collateral at P2SH address) and 2 outputs (BSQ collateral repayment + 0.55125 BTC repayment & interest to Bob). Bob also sends Alice an unsigned partial tx paying out his 0.5 BTC loan to her (and returning any change to him).
4. Alice adds her BSQ collateral input, P2SH BSQ lockup output (and possible BSQ change output) to the tx and signs it.
5. Bob signs and publishes the loan payout tx received from Alice. This atomically swaps Bob's loan for Alice's collateral, opening the loan.
6. Less than 2 months later, Alice adds her (single) BTC input to the anyone-can-pay tx template provided by Bob, with input large enough to cover the output sum and mining fee. She then signs and publishes this, closing the loan.

As an alternative to the last step, we could have:

6. Alice is late with her repayment. Bob adds his mining fee to the timelocked (anyone-can-pay) confiscation tx provided by Alice, signs and publishes it, closing the loan by claiming her 10000 BSQ collateral.

Integrating into Bisq

I think we should consider integrating something like the above into the Bisq application, as this (as well as atomic swaps to reduce trade friction) could improve BTC-BSQ liquidity. It may also pave the way for other kinds of loans or some form of decentralised margin trading in the future. However, it would probably be a lot of work to add entirely new trading protocols, offer types and views to the UI for a separate loan market.

As an alternative, it may be possible to reuse the existing trade interface by implementing such loans as a special kind of altcoin - a non-fungible, once-transferrable token created by the borrower upon commencement of the trade. Then the "altcoin buyer's" (i.e. lender's) receipt address would be a concatenation of their BTC repayment address and their BSQ confiscation payout address. The normal trade protocol would have to be modified to exchange the partially signed final payout and confiscation transactions (prior to locking up the collateral). Then the collateral payment could contain an OP_RETURN with a hash to prove that those transactions were correctly exchanged in accordance with the modified protocol. Thus the borrower can prove to a mediator that he "paid" (i.e. locked up his collateral correctly) in the event of a dispute. (Alternatively, for extra safety, the OP_RETURN could contain everything needed to reconstruct both the signed payout and confiscation transactions.)

In this model, the "price" of the loan buy/sell offer would probably be the APR. We would also need to record other details in the offer book, namely the repayment date and the collateral amount, viewable in the offer details prior to taking it.

Integrating into the existing trade interface in this way would probably only need one new tab under the DAO part of the UI to view, create and manage all the BSQ-collateralised loans, both for the lenders and the borrowers.

[beingindot]

In case of default, what would be the impact of bsq-btc offer book?

[ifarnung]

@stejbac Interesting and well thought out idea. I can't say if the technical details work as you say, but I don't see why you couldn't engineer that system. It would be interesting to see if there was interest or use of such a product.

In my opinion it doesn't help the underlying issue which is/was lack of BSQ demand, so I'm not sure it's worth expending a lot of energy to give people greater options in how they sell BSQ. Personally, I don't think a contributor should be worried about 'tanking' the price of BSQ when they cash their contributor checks in. The BSQ is an important health metric for the exchange, and the benefit of a falling price is the information that the BSQ budget needs to be tightened (for example). If people think, for example, that if volume increases in the future and project costs go down in the future, then monthly demand for BSQ will exceed the monthly supply and the price will go much higher, and they will benefit by waiting to sell. If someone thinks that BSQ will continue to be issued at a rate that will never be burned, then they may believe that the BSQ will continue to go lower as supply outstrips demand. That person may want to sell today at even a 'historically low' price.

Let's think from the viewpoint of the loan maker: it's synthetically selling a put on the BSQ price and getting that option premium in the form of "APR" or "loan interest". If the collateral values the loan at 5000 sats each, the borrower should only choose to pay it back if the BSQ market price is above that at the end date of the loan. Otherwise, they should choose to default and "sell" their BSQ at 5000. In this case the loan maker receives the BSQ at 5000 sats each + the interest payments made along the way.

As a former options trader, selling naked puts would be considered a very dangerous strategy, especially in a market as volatile as BTC multiplied by the volatile BSQ. In January alone, we've seen the range of 2000 sats to 10000 sats, that's huge volatility!

Of course, people should be able to enter into financial arrangements that they consensually choose, but again, this offering will not change the underlying demand for BSQ, only add to the diversity of outcomes.

Ultimately as discussed in the growth call by @m52go, we need to think of ways to increase fee revenue. And at least for me, the best way is to raise the utility of the BISQ program incrementally through improvements on the customer focused offerings. BISQ is already a huge success in my mind as a functional independent exchange, and things like the new Liquid BTC asset in the next version make me excited.

Also, projects like the API are another super high priority item in my mind (I'm not a dev) as you can enable higher volume trading.

Just my two cents and I'd love to hear what others think about the idea.

[ifarnung]

@beingindot The loan maker would receive 10,000 BSQ in that example and would decide what to do with them, Sell or Hold.

[sqrrm]

Feasibility

This is a really interesting idea. I'm not sure it's that valuable to be able to borrow BTC with BSQ as collateral in itself, but perhaps there is a market for it. Regarding the details, I can't find anything wrong so far. The pre-signed repay and confiscation txs should make this safe and having ANYONECANPAY should work nicely. It would definitely be both an easier protocol and easier to implement to use an atomic commitment tx with BSQ to be locked being swapped for the BTC loan. It would also be faster, cheaper and probably somewhat safer.

Implementation

Regarding implementation it would likely not be worth changing the current trade protocol to integrate this idea. I feel the current protocol is a bit fragile and it would affect all trading with bisq if we mess it up. I think I would rather start by adding atomic BSQ/BTC trades and go from there to add this kind of idea and others. That would give us room to play with the new protocol, although most of it would just be building parts from what we have already.

The UI could probably be mostly the same as we have already, or whatever we will have after the planned revamp coming up. Good point to keep in mind while we do that to allow for more kinds of products that aren't just buying or selling BTC for some other kind of money.

Use Case

Since the loan doesn't have to be paid back it acts as a hedge on the BSQ price. Perhaps that's the main use case from Alice's point of view. She borrows 0.5 BTC for her 10000 BSQ because she's worried BSQ prices will fall and she's prepared to pay for this safety.

Bob wants to lend BTC to make money by earning interest. The risk is the BSQ volatility so he would likely require more than 100% collateral, or a high interest rate. With a 100% collateral a lower BSQ price would result in Alice keeping the 0.5 BTC and Bob making a less than the anticipated interest, perhaps even a loss, and higher prices would result in Alice repaying the loan to get the BSQ back.

There might indeed be a market for both sides of that trade with a reasonable collateral that's dependent on the BSQ volatility and the interest rate paid. Although it's not a proper interest rate, more like an option premium. Some finance guys surely has a good name for it already.

I'm not sure what the effect on the BSQ market would be though, but I feel this would stabilize BSQ prices as it adds an option to hedge ones holdings rather than sell at any cost. It locks up BSQ though so I'm not sure about the liquidity aspect.

[stejbac]

I was thinking, in light of the recent attack and its likely impact on the budget and BSQ price over the next year or two, whether it would be worth revisiting this idea. It could serve as a possible (maybe far-fetched?) way of softening the blow and indirectly drawing in investment from lenders to make up for the current loss of profitability. In the best case scenario, this could make it possible to pay back the $250,000 to the victims sooner.

It would be interesting to develop a skeletal implementation of a loan + atomic swap protocol (no UI, offer book or trade stats work for now), to make sure that the idea really is technically sound. Since the scheme described above is trustless (at least with atomic swaps as @sqrrm suggests), it should be somewhat simpler than the current Bisq trade protocol to implement. There is no need for mediators/arbitrators or presumably any kind of JSON contract, as there is no possibility of a dispute, barring bugs in the code. (I'm not sure what to do about trade fees - perhaps they could also be left out for now for simplicity.)

It would also be an opportunity to familiarise myself more with BitcoinJ, which is something I was meaning to do anyway.

I'd hope not to spend too much time on this - perhaps just a few weeks to work out a detailed protocol on paper, come up with some corresponding protobuf messages and attempt to interface with the BSQ and BTC wallets in the Bisq codebase to get a skeletal workflow that can be integration tested.

[sqrrm]

I think it's an interesting concept but it's really hard to know how much value there is in there. It's quite possible it would add a lot of value, but could equally just come to nothing. With the added benefit of possibly being able to merge the bitcoinj PR from a year ago, I say it's worth an attempt.

If nothing else, I will be keen to help as it sounds fun. It could also lead to improvements in the trade protocol.

[stejbac]

Thinking about this further, there is a serious issue that the initial loan/deposit tx would be malleable without using Segwit. So either Alice or Bob (or even a third party) could replace it with an equivalent one with a different ID, invalidating both the prepared repayment and confiscation transactions. Reading about all the various sources of malleability in non-Segwit transactions, I think it would be very difficult to prevent it without completing the upgrade of BitcoinJ to enable the publishing of Segwit transactions from within Bisq. All the loan tx inputs (but not the outputs) would need to have Segwit addresses to prevent malleability, I believe. Luckily, the ANYONECANPAY and SINGLE sighash types still work almost exactly the same way in Segwit scripts, according to BIP-0143, so the protocol should carry over unaltered. Also, I'm fairly sure Segwit BSQ transactions would validate fine in old Bisq clients.

One possible way to mitigate the issue without upgrading BitcoinJ would be to introduce an arbitrator key and make the BSQ collateral UXTO 2-out-of-3 instead of 2-out-of-2. Better I think would be to use a more complicated script which makes the UXTO spendable with either Alice+Bob's signature at any time or Alice/Bob + Arbitator's signature a day or two after the loan expires. That way if the protocol is followed correctly, the loan/deposit tx will have the correct output and the arbitrator will have no control over the funds (even in collusion with Alice or Bob). The abritrator's key would only be used (later) in the event that loan tx was replaced and confirmed with the wrong ID, preventing closure of the loan.

[ricardosaurio]

whatever that increases the demand of BSQ... The DAO offers interesting posibilities, like locking BSQ as collateral to enable trades with highgly frowned methods, like paypal. You could only offer a Paypal trade of 1/3 the value you lock up for at least 200 days after the trade is complete.

[chimp1984]

Hi @stejbac,
Interesting concept.
Here some feedback:

On the conceptual side:
As you pointed out there is a malleability risk. From my understanding malleability is caused intentionally and not "randomly" even any miner could cause it there is no incentive for them to do so. I never heard of malleability issues in such regards. So I think we can focus on cases where one of the traders would gain a benefit from malleability.
The malleability risk comes down to a blackmail risk. Alice cannot lose anything. If she cannot do the repayment she has simply traded BSQ to BTC, assuming no volatility and 100% BSQ collateral thats a zero sum game.
Bob has no incentive to cause an altered tx as he would hurt himself by not being able to get the BSQ if Alice is not repaying the BTC. But Alice could abuse that weak position of Bob by blackmailing him.
Segwit would provide a solution but I am not sure if segwit can be used for BSQ transactions.
Alternatively there could be used another idea:
The DAO could state that it will reimburse any victim of such a blackmail (proof need to be verifiable). If Alice would attempt a blackmail Bob would request a reimbursement from the DAO and Alice would fail. The DAO would suffer some financial loss, but if the protocol has an added value to the DAO and fees are paid it might be acceptable. Just being the "savior of last resort" would kill the incentive for Alice to try a blackmail attempt (which would be difficult to do and success anyway with various other reasons). There still would be a "sabotage" risk for the DAO.
Further a security deposit could be added to the collateral so that Alice if completing the deal by paying back (and not blackmailing or defaulting) she gets her deposit back, otherwise Bob gets it. That would decrease blackmail risk further if combined with the DAO reimbursement.

On the economic side:
As others have commented it has the character of more an option trade. The positive and negative effects should be analysed from people more familiar with that, but from my guts feeling I see it more as a risk rather than an opportunity. The main use cases for BSQ (paying contributors, paying trade fees) benefit from low volatility. I assume speculative trade options increase volatility, but that might be seen differently by others. At least high volatility makes markets more interesting for speculative traders.

On the BSQ ecosystem side:
The complexity of the BSQ ecosystem is already quite high and hard to understand for many participants. Adding a speculative trading option tool would add more complexity and risks on the economic side IMO.

On the technical side:
BSQ has not implemented support for multisig (as there was no use case and as we wanted to limit complexity).

[MwithM]

Closed as stalled.