Off-chain trading using a lightning network of BTC & tainted BSQ

[stejbac]

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

This is a somewhat ambitious proposal for an eventual off-chain trading protocol using a fork of the lightning network and a form of BSQ bonding, which is intended to reduce network fees + delays and eliminate the problematic role of the Burning Man as a collector of disputed BTC funds.

An off-chain trade protocol secured by BSQ bonds was considered a while ago in #32, but progress was stalled. I believe the main issue with that proposal is the difficulty of preventing reuse of the bond for an unlimited volume of simultaneous open trades in a truly secure way. In some sense, the bond needs to be 'borrowed' when a given trade opens and returned when it closes. Thus preventing unlimited reuse requires solving the double-spend problem (which is what a blockchain does!) and I don't think that the Bisq P2P network can really be expected to provide the level of security required to do this, in order to prevent theft of large amounts of trader deposits. (Also note that it isn't enough to detect unauthorised bond reuse after the fact and then confiscate the bond, since an attacker who can manipulate P2P network consensus could steal a very large amount of funds by sweeping the offer book, before being detected.)

So to prevent unlimited bond reuse, one needs a way to 'lend' a bond to the trade peer(s) in a way that is immune to double-spending in the face of potential P2P network attack. A BSQ lightning network could be implemented for this purpose, to transfer a bond instantly and without tx fees. However, this has the obvious problem that the recipient could just run off with the bond, which would be worth more than the BTC escrow. This proposal attempts to solve the problem by attaching a temporary taint to the transferred BSQ, intended to render it near worthless, such that the taint can only be removed upon return of the BSQ to the original bond holder.

Tainted BSQ

We could make a fork of the DAO consensus rules, by introducing a new OP_RETURN type, say TAINT((byte) 0x18), as defined in the OpReturnType Java enum. This could have two fields in its binary data:

• An arbitrary tag/hash, different for each trade & bond holder pair (say 20 bytes);
• A self-destruct absolute block height (say 4 bytes).

A BSQ tx with such an OP_RETURN output would have two or more BSQ outputs, the first two of which would be enforced to have equal value. These would be respectively tainted and antitainted BSQ. The DAO state parser would trace such special BSQ coins in the same way as regular BSQ, without requiring any further metadata to be embedded in downstream txs to identify them. (Anti)tainted BSQ can be transferred in the same way as regular BSQ. Additionally, such coins can be split, joined or partially burned in transfer txs, just as regular BSQ. However, they would be subject to additional rules, which failing to follow would cause the relevant BSQ tx outputs to be burned:

• (Anti)tainted BSQ can only be used in transfer (& possibly proof-of-burn) txs, not voting/proposals/bonding etc.
• A transfer tx cannot create any BSQ outputs of mixed/partial (anti)taint, that is, by combining inputs with different TAINT tag fields or self-destruct absolute heights.
• The order of contiguous taint/antitaint/no-taint of the BSQ outputs is assumed to follow that of the BSQ inputs.
• If matching antitaint follows taint in the BSQ inputs, they cancel each other out fully or partially (depending on the respective coin values), resulting in a contiguous block of one or more clean BSQ outputs. So say a tx has a 1 BSQ tainted input, a 2 BSQ tainted input and a 4 BSQ antitainted input respectively, and 3 BSQ, 3 BSQ & 1 BSQ outputs respectively (plus any number of BTC inputs/outputs), then the first two BSQ outputs would be clean and the third would be antitainted.

The self-destruct field specifies the block height at which the (anti)tainted BSQ would be automatically burned, if it had not yet been cleaned by cancelling out the taint and antitaint as above. This feature is probably not essential but may help to ensure that the coins never acquire any real market value, plus it may help to prevent long term pollution of the UXTO set by coins that fail to be cleaned. An absolute block height is used because tainted+antitainted BSQ would typically be locked in lightning channels and never get reified on-chain, but could do so any time in an uncooperative channel closure. It's necessary that the self-destruct heights match when cancelling taint & antitaint, since otherwise the self-destruct time could be continually pushed back by creating new tainted+antitainted output pairs and neutralising with an older output.

A lightning network for tainted BSQ payments

The main purpose of having txs which create equal amounts of tainted and antitainted BSQ (from clean BSQ) and letting both move freely in transfer txs is to facilitate multi-channel hops of tainted BSQ through a lightning network. If a node operator in the network receives a pending payment of tainted BSQ through one of his channels, he can forward it on by creating equal amounts of tainted+antitainted BSQ in a down route pending payment, keeping the antitainted BSQ for himself and paying the newly tainted BSQ to his down route channel partner. Then he can be made whole again if one of those channels closes, since he simply needs to close the neighbouring channel (well before the taint self-destruct date), leaving him with equal amounts of tainted & antitainted BSQ, which he can then combine together to recover his original clean BSQ.

Most of the time a tainted BSQ payment would be later reversed, when the respective trade closes normally, and probably along the same route of payment channels. That would clean all the taint and antitaint from the channels. Occasionally, it might go back along a different route, which would create a cycle of tainted BSQ payments. These cycles could be easily removed later, by cooperation between the affected nodes.

It should be noted that such tainted BSQ payments tie up channel liquidity along the route, much like a pending payment path of HTLCs. I don't believe that there is any way to set up a multiparty contract/escrow across a lightning network that doesn't tie up liquidity in proportion to the total size of the escrow times the number of channel hops between the contract parties.

It should also be noted that, unlike a regular BTC lightning network, each node would have a non-scalar account balance with its channel partner, consisting of an untainted BSQ balance and a balance of each kind of tainted & antitainted BSQ created within the channel, as well as a possible uncoloured BTC balance, the latter to ensure that there are funds for mining fees. Hopefully it wouldn't be a massive amount of work to fork an existing lightning client to support this. For example, the Eclair wallet is a JVM implementation written in Scala, with a separate eclair-core module that could possibly be adapted. Perhaps a BitcoinJ SPV wallet-based back end could be developed for it (as it currently has bitcoind & electrum back ends), so that it could be embedded into Bisq. The Rust-Lightning repo also looks quite interesting and states that it's intended to be extensible (although it appears to be a rather immature implementation).

Trading with an optional third party escrow agent

Suppose Alice and Bob are a BTC buyer and seller respectively and Carol is a third party BSQ 'bond' holder, acting as an escrow agent. To start a trade, Carol makes equal sized tainted BSQ pending payments to Alice and Bob, with a taint unique to that trade. Alice and Bob then make pending payments of their respective BTC deposits to Carol. This includes the trade amount (for Bob), plus equal sized (say 15% or so) security deposits each. The pending payments all share the same lightning secret (generated by Carol) and hash, so the entire exchange can then be made to go through atomically. (It isn't strictly necessary for the payments to all be made atomically, so long as Carol makes her BSQ payment before receiving any BTC from each respective trader, since all lightning payments have receipts. But it prevents the trader from walking off with the tainted BSQ and seriously inconveniencing Carol without penalty. Plus it is quite easy to make it atomic.)

Once the fiat payment from Alice to Bob has been made, the whole process can be reversed to close the trade: Carol makes a pending payment of the escrow back to Alice and Bob, in the correct proportions. Alice and Bob then make pending payments of the tainted BSQ back to Carol and the whole thing is made to go through atomically.

If there is a dispute which cannot be resolved through mediation and there's a breakdown of cooperation with the escrow agent, then the honest parties should close their respective lightning channels and burn the (anti)tainted BSQ that they're left with. If Carol handed back all her escrow correctly, then her burned BSQ should be reimbursed by the DAO. Alternatively, if an honest trader did not get back their escrow and subsequently burned the tainted BSQ that they were left with, then the DAO should reimburse them with an equivalent amount of BSQ or pay them in BTC via a refund agent. Either way, the honest parties are made whole and the DAO does not lose any money so long as Carol's 'bond' was big enough.

The absolute minimum bond size needed for this to work securely is twice the total BTC escrow value, but it should probably be quite a bit more than this (say double) to account for the BSQ-BTC price volatility. It should emphasised that the escrow agent is a rather low trust role and the protocol should work just as securely if Alice or Bob doubles up as the escrow agent. In that case, the bond would only need to be half as big, as one would be sending half of it to oneself. Moreover, the protocol can be easily extended to support multiple escrow agents, with the bond divided between them, which is secure so long as each one uses a separate taint. When Alice and Bob both double up as equal sized escrow agents, the maximum individual bond size is minimised, to a quarter of Carol's original bond size. The scheme then becomes similar to that in #32.

The point of having a third party escrow agent is simply to avoid Alice and Bob having to purchase large amounts of BSQ to start trading, which may be difficult or inconvenient for them.

An alternative, simpler lightning-based trade protocol

As an interim step to implementing the full scheme above, we could implement a hopefully simpler though less secure and decentralised trade protocol, which relies on just a regular BTC lightning network. It's a similar 3-party protocol to the above, between Alice, Bob and Carol, except this time Carol is the Burning Man / donation address holder. (One could have multiple such entities for network redundancy, though that would probably lead to similar security problems as having multiple Burning Men.)

The traders, Alice and Bob, each make a simultaneous pending lightning payment (using HTLCs with hashes H_AC & H_1BC respectively) of their BTC escrow to Carol, who in turn makes a pending lightning payment (using HTLCs with a third hash H_2BC) back to Alice and Bob with a 10-20 day timeout. This second payment is routed through Bob to Alice and back to Bob again, in such a way that it drops off the trade amount + security deposit at Alice's node and sends the rest of the escrow (the security deposit) on to the seller, Bob.

It's essential that the full escrow amount is routed through both Alice and Bob in this second payment, since none of the lightning network outside one's own node can really be trusted. So if, say, the buyer Alice was in collusion with the donation address holder Carol, then without routing the full return payment through Bob, after confirmation of the first payment they could immediately steal all of the funds except a pending security deposit payment to Bob which would cancel after 10 days. By routing the full return payment through both traders, one should have no worse security than the present trade protocol w.r.t. the donation address holder. That is, a corrupt donation address holder could steal a large amount of funds by posing as a trader and sweeping the offer book, but is limited by the collateral needed for all those trades, which would be tied up for 10 days minimum before freeing up funds to continue with the scam, in which time it would be shut down. This allows a theft of no more than around 8 times the available starting funds (unlike a situation with an immediate deposit refund to the scammer, which allows unlimited theft from any starting amount). With a lightning-based protocol, the security is probably somewhat better in practice, since any attempt at mass theft would likely quickly tie up all the available liquidity / channel capacity with pending payments (HTLCs).

Before setting up any of the pending payments, Alice, Bob & Carol prepare 16-byte secrets S_A, S_1B, S_2B (two for Bob) & S_C and share commitments to them (say hashes), H_A, H_1B, H_2B & H_C, respectively. Then we set the earlier three hashes to be the following:

H_AC = SHA256(S_AC), with payment preimage S_AC = S_A||S_C;
H_1BC = SHA256(S_1BC), with payment preimage S_1BC = S_1B||S_C;
H_2BC = SHA256(S_2BC), with payment preimage S_2BC = S_2B||S_C,

where X||Y is the concatenation of X and Y. These hashes need to be computed jointly, in such a way that it doesn't reveal any of the 4 secrets (or 3 preimages) to the other parties. That requires the use of a generic secure 2-party computation between Alice & Carol for the first hash and between Bob & Carol for the second two hashes, using garbled circuits. Carol needs to be sure that her secret S_C isn't surreptitiously leaked and Alice and Bob need to be sure that the first two hashes produced are actually valid (that is, they will leak S_C when their preimages are revealed during the commitment of the first two payments). Thus neither side can trust the garbled circuit provided by the other side, so without using zero-knowledge proofs (which would be very complex and big/slow), each side must exchange garbled circuits, run them independently and compare results.

Carol's secret S_C serves as both a receipt of the escrow payment and a key which allows Bob to unlock the third pending payment back to the traders. Once all three pending payments are set up, Alice reveals S_A to Carol and Bob reveals S_1B to Carol, allowing Carol to commit the two escrow payments, which begins the trade. At this point only S_2B remains secret, which Bob uses to commit the third payment to close the trade. Also at this point, there is no further involvement from Carol and the escrow can be recovered without her cooperation so long as Alice and Bob are in agreement, so that the remaining pending payment doesn't time out. If it does, the trade goes into arbitration and then Carol controls the escrow. So hopefully from a legal perspective, Carol wouldn't really be considered a custodian of the escrow, as she cannot do anything to stop the return of it to Alice and Bob.

The garbled circuits are big (of the order of MBs each) and so their exchange at the start of the trade would be slow. They can also be prepared well in advance, though, but are single use like one-time pads. Luckily, all the exchanges are with Carol and since there would only be one, or a very few, donation address holders, it should be possible to build up a small supply of such circuits for each separate trader and donation address holder by drip-feeding them through the P2P network prior to a given trade, so that it can start quickly (as actually running the circuits is very fast).

(The underlying problem which makes the use of garbled circuits necessary is that payment preimages in Lightning HTLCs are constrained to be exactly 32 bytes long, and that is short enough to fit in a single 512-bit message chunk of the SHA256 digest algorithm. If the network could be forked to make the preimages bigger, say 96 bytes, then that would spill into 2 chunks, so jointly computing hashes of each preimage which contains mixed secrets S_A, S_C, etc. could be done by passing the partial digest back and forth between the two parties with each side processing a fresh message chunk not containing the other side's secrets. That would make the whole trade setup much easier and more efficient.)

Final remark

Just as it is possible to do off-chain trading using BTC Lightning without needing any concept of tainted BSQ, one could use tainted BSQ in atomic swap txs as part of an ordinary on-chain trading protocol, in order to help eliminate the Burning Man. So it's really two separate problems being addressed here with two separate approaches. But I think it works best when they are combined.

[chimp1984]

Thanks a lot @stejbac for those excellent ideas!

To better understand your proposal I wrote down for myself the basics. I hope I interpreted it correctly, if not please correct me. I will share it here maybe it is helpful for other readers.

A taint tx creates (a) pair(s) of equal valued Tainted BSQ (TBSA) and anti-tainted BSQ (ATBSQ).
OpReturn marks tx type and carries metadata about trade context (TAG) and destruction block height (DBH).
To convert them later back both types need to be present in same value, TAG and DBH.

Example tx (ignoring BTC for miner fees):
Input: 1000 BSQ
Ouput 1: 500 BSQ -> Tainted BSQ (TBSQ)
Ouput 2: 500 BSQ -> Anti-Tainted BSQ (ATBSQ) (same output value)

TBSQ and ATBSQ can be transferred like normal BSQ with some restrictions. TBSQ or ATBSQ are not valueable as BSQ and would not be accepted in a BSQ/BTC trade. Transfer is used between traders and escrow and in LN channel hops.
If they get transferred the TAG is found in the taint tx originating the txos. Only ABSQ or ATBSQ with same TAG and DBH can be combined in a tx.

Un-taint tx example:
Input 1: 500 TBSQ
Input 2: 500 ATBSQ (same TAG, DBH as in Input 1)
Output: 1000 BSQ (clean)

How are they used for the trade protocol:

Alice is BTC buyer. We ignore security deposits and fees. We assume 10k USD = 10k BSQ = 1 BTC to keep numbers simple.
TBSQ = tained BSQ
ATBSQ = anti tainted BSQ
BSQ = normal clean BSQ
Alice buys 1 BTC from Bob for 10k USD using Carol for borrowing the BSQ bond.

Happy trade path

State 1:
Alice: 0 BTC, 10k USD
Bob: 1 BTC, 0 USD
Carol: 0 BTC, 40k BSQ

Transition 1:
Atomic Taint tx with BTC bond payment from traders to Carol in exchange to a BSQ bond

Input 1: 40k BSQ from Carol
Input 2: 1 BTC from Alice
Input 3: 1 BTC from Bob
Output 1: 10k TBSQ to Alice
Output 2: 10k TBSQ to Bob
Output 3: 20k ATBSQ to Carol
Output 4: 2 BTC to Carol
OpReturn marking it as taint tx with trade meta data as TAG and DBH

State 2:
Alice: 0 BTC, 10k USD, 10k TBSQ
Bob: 0 BTC, 0 USD, 10k TBSQ
Carol: 2 BTC, 20k ATBSQ

Transition 2 (Alice send USD):
Alice sends 10k USD to Bob

State 3:
Alice: 0 BTC, 0 USD, 10k TBSQ
Bob: 0 BTC, 10k USD, 10k TBSQ
Carol: 2 BTC, 20k ATBSQ

Transition 3 (Bob confirms USD receipt, atomic refund tx):
Un-taint tx and refund of BTC to traders and BSQ bond to Carol.

Input 1: 10k TBSQ from Alice
Input 2: 10k TBSQ from Bob
Input 3: 2 BTC from Carol
Input 4: 20k ATBSQ from Carol
Output 1: 40k BSQ to Carol
Output 2: 1 BTC to Alice
Output 3: 1 BTC to Bob

State 4:
Alice: 1 BTC, 0 USD, 0 TBSQ
Bob: 1 BTC, 10 USD, 0 TBSQ
Carol: 0 BTC, 40k BSQ

Not happy paths

Case 1:
Alice never sends USD, Bob requests refund. Alice lose her sec. deposit if she cooperates otherwise case 3. The sec. deposit was not modelled above but would be 15% of trade amount.

Case 1:
Bob did not confirm receipt. Alice requests refund. Bob lose his sec. deposit if he cooperates otherwise case 3.

Case 3:
A Trader do not refund TBSQ:
Carol do not refund the BTC and will burn the ATBSQ rendering the TBSQ of the trader worthless (and get invalidated at the destruction block hight). Carol cannot convert back the ATBSQ so she burns that as well and request refund 10K BSQ (for 1 trader) - she keeps 1 BTC for the loss of 10k BSQ

Case 4:
Carol does not refund BTC:
Traders burn TBSQ and get a DAO refund in BSQ. Alice has lost 40k BSQ (double the 2 BTC) as she cannot use the 20k ATBSQ and those get invalidated at the destruction block hight

I think the high capital requirement for Carol (4 times the trade amount if I understand it correctly) might become a problem for larger trades and volume. Currently we have about 0.5M USD volume per day, assuming average settlement time is 1 day that means 2M USD in BSQ need to be available for bonds. That is about 25% of current BSQ available. Settlement times would be much faster if we manage to automate altcoin trades (essentially XMR as thats 70-90% of total volume). Pure fiat volume is then only 20-30% so the required total capital for bonds would become much less.
Of course the demand for bonds will drive up BSQ price so that could mitigate the issue as well.

I think for altcoins we also can take benefit from the fast and cheap tx options in LN and try to do micropayment style trades if altcoin miner fee costs permit that.
E.g. If one wants to trade 2 BTC for XMR that would be very expensive for bonding (180k USD equivalent BSQ). But if the trade gets automated and split in 10 small trades and each settles quite fast (altcoin confirm time is bottleneck) the required liquidity is much lower as one completed trade free up BSQ capital. Also volatility risks with burned and reimbursend BSQ need to be considered and is a open problem with current protocol.

I am not sure if Carol could be considered a financial intermediary. At least she could run away with the BTC and then make the traders depend on the DAO to get reimbursed. I think that is worse then current burning man problem as the BM cannot trigger that the traders send the funds to the donation address as he is not part of the trade.

I have not though more about the case that Alice (or Bob) plays the role of Carol.
If we can find a way to avoid Carol and instead solve the problem that the traders need a high amount of BSQ for the bond by providing a trustless lending service, I think the legal risks that Carol could be interpreted as partizipant in the trade would get reduced.
It also would make clear that providing capital comes with costs and if traders dont want to pay for that by paying interest rate for the loan they can get BSQ themself.
If it is not possible to remove the role of Carol maybe it can be modelled as a bot or if possible as smart contract. The input to the bot/contract if there is no cooperative outcome would be provided by a mediator/arbitrator both traders would agree on to accept their judgement in case of a dispute. As the mediator has no access/control to the funds at all but only the power to trigger that funds get burned this should be more safe. Thought how can a bot/contract get the DAO reimbursement...

I will need more time to understand the second idea, specially the required garbled circuits.

I think the ideas you presented here are a huge step further to a secure off-chain protocol.
It would be great if we could find a solution which avoids a custom LN fork as that comes with a huge development challenge as well as the difficulty to bootstrap the network and it might cause different security risks than the standard LN because of the special use case in the context of an exchange with potentially large volumes.

[chimp1984]

I think i was wrong with the 4 x bond requirement, 2x should be the minimum as burning one part of the bond pair will invalidate the other.

Further I think a version without Carol should be possible as well and would look like that:

Taint tx:
Input 1: 10k BSQ from Alice
Input 2: 10k BSQ from Bob
Output 1: 5k TBSQ to Bob (corresponds to input 1)
Output 2: 5k ATBSQ to Alice (corresponds to input 1)
Output 3: 5k TBSQ to Alice (corresponds to input 2)
Output 4: 5k ATBSQ to Bob (corresponds to input 2)

Un-taint tx:
Input 1: 5k TBSQ from Alice
Input 2: 5k ATBSQ from Alice
Input 3: 5k TBSQ from Bob
Input 4: 5k ATBSQ from Bob
Output 1: 10k BSQ to Alice
Output 2: 10k BSQ to Bob

I was not sure about the details how you defined the input - output rules, but to have an atomic tx where both taint their BSQ we would need a rule that 1 input maps to a pair of 2 outputs (TBSQ / ATBSQ).

So by that in a non cooperative outcome either trader can burn the TBSQ of the peer and their own ATBSQ and thus destroying both bonds. The DAO might reimburse the side who can proof their case (e.g. following mediator/arbitrator decision).

I think that model can avoid the security deposit and does not require any blockchain for the trade currency pairs (e.g. trade apples to bananas). LN can be of course used for a BTC transfer but is not enforced by the protocol.

Of course it would still require a BSQ LN fork as we don't want ot have the 2 txs. But even without that I think it would be an interesting alternative to the current on-chain protocol (but would not justify the effort and come with the issue of high costs for the bond).

The problem that traders require at least the amount what they want to trade additionally as bond could be addressed by a lending market, so they pay some interest rate for getting that loan.

It would be great if we could find a scheme which is not based on BSQ but could work with BTC over LN. Beside the challenge to get our own LN fork the volatility risk and dependency on the BSQ/DAO economy carries considerable risks.

[chimp1984]

Another idea:
Delegate the bond functionality to Monero and getting best privacy and cheap miner fees [1]. Use a 2of2 MAD style bond tx for each trade. The trade itself would be completely blockchain-agnostic, can be off-chain, LN or anything. Trade violation lead to arbitration with mutually selected arbitrator and if no cooperative outcome is found the bond stays locked forever. There are some issues with MAD (extortion risk), but I think those can be mitigated (e.g. if one gets extorted and can proof it 100% clearly he can get reimbursed by the DAO, causing a loss for the DAO but removes that extortion risk and makes the MAD protocol safe.

I am not familiar with the details of Monero multisig, but I assume that should not cause problems. How to integrate it so that users dont need to run a full Monero node is an open challenge, but once the XMR-BTC atomic swap is implemented (probably in the next 3-6 months) there might be more options.

Actually that would convert Bisq into a Monero based platform. Bitcoin would not play a fundamental role anymore but Monero would. Might bring back some love from the Monero community ;-)

[1] If that data is correct miner fees seem to be unfairly cheap on XMR: https://bitinfocharts.com/comparison/monero-transactionfees.html#3m

[stejbac]

@chimp1984 Yes, that interpretation is basically correct. Thinking a bit further about the new BSQ tx rules, it would be useful to be able to create more than one TBSQ-ATBSQ pair per tx, just as in your example above (unlike in the original rules I devised, which always create one pair out of the first two outputs only). That would be useful for on-chain txs which atomically exchange newly created TBSQ and BTC between the traders, as in your examples. Also, it would mean that if a lightning channel had built up multiple pairs of differently tainted TBSQ-ATBSQ pairs in its final state (through lots of different trades being routed through it without all being completely cleaned up), then a cooperative channel closure would consist of just a single tx which spends the 2-2 BSQ lockup and creates all the pairs at once. That would be much neater and more efficient than trying to do it in multiple txs. To create multiple pairs of possibly different taint, perhaps one OP_RETURN output could be included per pair, or perhaps all the separate TAG & DBH fields could be strung together in a single OP_RETURN field (if that wouldn't make it too long).

Also thinking further, the BTC security deposits are unnecessary as you point out, when Alice & Bob both double up as escrow agents and they each contribute some minimum amount to the bond total. (They don't actually have to have equal sized bonds - the total size is what's really important.) This can be seen since they would just be redistributing the escrow among themselves in proportion to their respective bond sizes, in their joint role as escrow agents. (So if their bonds were equal size, for example, they would first split the BTC escrow equally, make the fiat payment and then settle the BTC - a sort of "pay half now and half on delivery" scheme.) Provided each contribute a bond above some minimum percentage of the total (15 / 1.30 ~= 11.5% for a 15% security deposit), then the initial escrow redistribution to match the bond ratio wouldn't cause the BTC amount of either party to drop below the security deposit, so the security deposit could just be elided. When adjusting the trade parameters, as Alice or Bob's bond starts to drop below 11.5% of the total, it would be necessary for them both to contribute an ever growing BTC security deposit starting from 0%, until finally it reached 15% when one of the party's bond completely disappeared.

[chimp1984]

To create multiple pairs of possibly different taint, perhaps one OP_RETURN output could be included per pair, or perhaps all the separate TAG & DBH fields could be strung together in a single OP_RETURN field (if that wouldn't make it too long).

Maybe a merkle root like structure could work here?

[stejbac]

Maybe a merkle root like structure could work here?

I guess all the TAG and DBH data would ideally be included directly in the tx somewhere, rather than just a hash or set of hashes (and then subsequently storing them off chain, like the ballot data), as that would make tx parsing simpler and more reliable.

Thinking about the loan idea, it may be possible to relax the condition that the taint (TAG+DBH pair) is unique to each trade & escrow agent (including when Alice & Bob both double up as escrow agents, so they're just swapping differently tainted TBSQ), and instead allow it to be reused for different trades but always the same escrow agent. (There's definitely a security hole if it's reused for different escrow agents.) This would allow the BSQ lender to loan out TBSQ instead of BSQ, against a much smaller amount of the borrower's BTC collateral (just slightly larger than the escrow amount), which could then be passed to the trade peer(s) as normal. Thus the lender becomes a kind of backup escrow agent and the borrower (typically one of the traders) becomes a kind of delegate escrow agent who holds the actual escrow. If clean BSQ was borrowed instead, a much larger amount of collateral would presumably be needed to make a loan safe, since otherwise the borrower could just sell it instead of giving it back (and the BSQ could go up in price).

In the case where Alice & Bob both have equal amounts (say 5k) of borrowed/reused TBSQ, then instead of creating TBSQ-ATBSQ pairs from a 10k BSQ bond each, they could open a trade (not necessarily involving BTC) by exchanging it in a tx which would typically have 3 inputs and 3 outputs, like:

Input 1: 5k TBSQ from Alice
Input 2: 5k TBSQ from Bob
Input 3: BTC mining fee fund from taker
Output 1: 5k TBSQ to lockup address
Output 2: 5k TBSQ to lockup address
Output 3: BTC mining fee change to taker

If the trade closes normally, Bob could give Alice a private key or nonce that would unlock the first input for her, in order to return her TBSQ, and vice versa for the second input. Otherwise a (possibly timelocked) prepared tx could be published by either party to burn the TBSQ of both parties. Moving one of the outputs would automatically unlock the other output, much like the single tx trade protocol idea: #279. Thus it would be possible to trade arbitrary currency pairs with a single on-chain tx per trade to lock up the bonds. As I mentioned in #279, it may be possible to use cryptographic techniques to make the outputs P2WPKH instead of needing a custom script, in which case I guess it works out at 307 vBytes per trade (according to the bitcoinops.org size calculator). (The TBSQ coins could be used whole even if they're too big for the given trade, instead of splitting/joining them, in order to save tx fees.)

[stejbac]

Taking the above idea a bit further, we could have only one party (say the maker) providing a TBSQ bond and the taker providing a (much smaller) on-chain BTC security deposit (which, as I mentioned, is needed if either trader makes a bond of less than around 11% of the total required), with the rest of the trade being done off-chain, including provision of the security deposit of the maker. Then the on-chain tx would only need two inputs & two outputs, say:

Input 1: 10k TBSQ from the maker
Input 2: 0.15 BTC security deposit from the taker
Output 1: 10k TBSQ to lockup address
Output 2: 0.15 BTC to lockup address

This time, in the event of arbitration, the timelocked prepared tx would burn the maker's TBSQ and pay the (much smaller value) 0.15 BTC taker security deposit to the maker, so that they both have funds at stake.

If the trade closes normally, they would swap private keys (or maybe nonces instead) so that the TBSQ & BTC went back to the maker and taker respectively, but shaving a little bit off of each. In this way, the maker would pay the trade fees by burning some of their TBSQ and the taker would pay the mining fee. Also, the traders would try not to split or join their TBSQ or BTC coins, but instead keep passing them on from one trade to the next, shaving a little bit off each time to pay fees, so that each trade only required a single tx of 2 inputs & outputs like the above. The coins would not need to be the exact amount required and instead all the trades would be overcollateralised, using perhaps a range of reused coins of geometrically increasing size kept by each trader.

In this way, we could perhaps get the cost down to 208 vbytes per trade (or slightly more at 211 vbytes if we upgraded to taproot). It looks like recently the tx fees were reaching more than 150 sats/vbyte, so that would still be 31200 sats or around $15 per trade at the current BTC price. I have no idea how high that could climb over the next few years, maybe to $100's?

[Kixunil]

Very happy to see this moving forward, awesome folks!

There's also generalized lightning implementation written in Rust which aims to be even more extensible than Rust-Lightning and already supports colored coins via RGB.
I'm not sure if it's possible/beneficial to move BSQ to RGB as I don't understand the details deeply. Pinging @dr-orlovsky who could clarify it and may be interested in collaboration as I believe Bisq and RGB have very similar values (freedom).

I'm not currently capable of helping with this myself but I wish you good luck with this awesome project!

[pazza83]

Hi @stejbac

Closing as approved.

Please action what is needed and consider making a project if appropriate.

Many thanks.