Integrate RGB into Bisq 2

[HenrikJannsen]

Development of RGB[1] seems to enter a stage where it could be considered to be used for production projects.

The basic concepts have a lot in common with the guiding principles of the Bisq DAO:

• Only participants do verification of the contract
• Contract data is not stored on the blockchain but exchanged between privatizations via a dedicated network (Bisq P2P network in our case)
• The blockchain is used only for time-stamping purposes (RGB extends that to LN)

RGB provides a generic implementation of those principles and comes with further improvements regarding privacy (confidential transactions) and scalability (use LN for time-stamping instead the blockchain). It will provide a virtual machine for contract execution and Rust can be used to write simple contracts. More advanced contracts will require writing code for AluVM in AluAssembly language.

I think we should consider to use RGB as the protocol execution layer for Bisq 2.

I did not look closer into RGB to be able to make concrete suggestions how that could look like. The basic idea for the Bisq 2 protocol execution layer was to create a framework with a state machine model to be utilized by the different protocols. This framework layer could be replaced by RGB.

I do not think that on-chain transactions can be avoided in case of the Bisq Multisig protocol as there need to be a guarantee that the BTC are locked up and RBG and a timestamping tx cannot provide that guarantee (though the lockup tx can be used for timestamping purposes - as the hash of the trade contract was added as opReturn data in earlier Bisq versions).
So I am not sure if the Bisq multisig protocol would benefit substantially from using RGB, but I think it would open up more flexibility for other protocols (hedge, loans,...).

To integrate RGB (written in Rust) with our Java environment we could use JNI (I guess they provide language bindings).

Another long term plan could be to re-implement the Bisq DAO in RGB and swap then the current BSQ with a burn-and-issue swap to the new DAO.

Any developer interested to look closer into RGB to see how Bisq could utilize it?

[1] https://rgb.tech, https://blackpaper.rgb.tech

[flix1]

Idea worth exploring.

Eventually as on-chain fees grow we will need to transition most of Bisq functions, especially the 2-of-2 multisig used for trades, to a lightning network equivalent. RGB is the best currently available option. Superior to Taro IMHO.

However this is a pretty tall order. I don't think that there are any devs anywhere that know enough about RGB and Bisq to do this now. We will need to recruit RGB devs and teach them about Bisq or have a Bisq dev learn RGB.

Nevertheless it will be necessary. The sooner we start, the better.

[HenrikJannsen]

@flix1 As mentioned above I guess RGB will not make the on-chain transaction for locking up funds obsolete. At least to my very limited understanding of RGB.

[dr-orlovsky]

@LNP-BP Standards Association, leading and coordinating RGB development and adoption, is ready to propose an assistance in this effort. First of all, happy to cooperate on completion of JNI buildings - and here tools from @RGB-Tools, a project by @Bitfinex, may also be helpful. We are also working on providing more tools to build DAOs and starting a work on open DEX standard for Lightning - all these seems like a great cooperation areas.

[HenrikJannsen]

Invite you to join the effort and work on it together!

Would love to. How can I join?

The overall setup we are coming with is not RGB-specific; it is rather a way of enabling any Lightning node to operate as an exchange. The price discovery algorithm is separated from the exchange operations, i.e. it can work with either orderbook-based setups (which will require a dedicated protocol for orderbook) or AMM. The later can be combined with a liquidity pool - either trusted, or untrusted, with a multi-peer channel (another part of the protocol).

My perspective is strongly biased around the Fiat-Bitcoin exchange model. I fear I cannot contribute much to crypto-crypto models and AMM, though I looked into those models but consider them problematic from risk assessment perspective (very difficult to get an idea about the real risks due multiple exchange risks and default risks) and from the perspective of costs for the price finding (profit for arbitrage of liquidity providers is too high IMO for the utility to get price information, specially in the context where CEX dominate and provide a free/cheap - though trusted - price feed).
For the Fiat DEX concept I do not see a feasible way how to fully automate the trade process as banks do not provide modern standardized APIs to get information about the Fiat transfer, thus requiring manual user input to get information about the fiat settlement.

[dr-orlovsky]

Would love to. How can I join?

How we can contact you on a non-public channel to discuss the details?

[HenrikJannsen]

Do you use Matrix/Element? I am @boilingfrog:matrix.org there.

[nikicat]

... For the Fiat DEX concept I do not see a feasible way how to fully automate the trade process as banks do not provide modern standardized APIs to get information about the Fiat transfer, thus requiring manual user input to get information about the fiat settlement.

Hello, I think about automating fiat transfers by reverse-engineering a bank app's network protocols and then communicating with banks using their's unofficial APIs. What's your opinion on this, could it work or do you see some critical issues with such an approach?

[nikicat]

Do you use Matrix/Element? I am @boilingfrog:matrix.org there.

Ah, it's you, then no more questions :-)