> _This is a Bisq Network proposal. Please familiarize yourself with the [submis…sion and review process](https://docs.bisq.network/proposals.html)._
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 https://github.com/bisq-network/proposals/issues/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](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md#HTLC-Hashed-Time-Locked-Contract). 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](https://github.com/ACINQ/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](https://github.com/rust-bitcoin/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 https://github.com/bisq-network/proposals/issues/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<sub>AC</sub>_ & _H<sub>1BC</sub>_ respectively) of their BTC escrow to Carol, who in turn makes a pending lightning payment (using HTLCs with a third hash _H<sub>2BC</sub>_) 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<sub>A</sub>_, _S<sub>1B</sub>_, _S<sub>2B</sub>_ (two for Bob) & _S<sub>C</sub>_ and share commitments to them (say hashes), _H<sub>A</sub>_, _H<sub>1B</sub>_, _H<sub>2B</sub>_ & _H<sub>C</sub>_, respectively. Then we set the earlier three hashes to be the following:
> _H<sub>AC</sub> = SHA256(S<sub>AC</sub>)_, with payment preimage _S<sub>AC</sub> = S<sub>A</sub>||S<sub>C</sub>_;
> _H<sub>1BC</sub> = SHA256(S<sub>1BC</sub>)_, with payment preimage _S<sub>1BC</sub> = S<sub>1B</sub>||S<sub>C</sub>_;
> _H<sub>2BC</sub> = SHA256(S<sub>2BC</sub>)_, with payment preimage _S<sub>2BC</sub> = S<sub>2B</sub>||S<sub>C</sub>_,
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](https://en.wikipedia.org/wiki/Garbled_circuit). Carol needs to be sure that her secret _S<sub>C</sub>_ 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<sub>C</sub>_ 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<sub>C</sub>_ 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<sub>A</sub>_ to Carol and Bob reveals _S<sub>1B</sub>_ to Carol, allowing Carol to commit the two escrow payments, which begins the trade. At this point only _S<sub>2B</sub>_ 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<sub>A</sub>, S<sub>C</sub>, 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.