upgrade/convert BSQ to Taproot-assets

[skaunov]

The primary target of the discussion is to learn if it's a no-no thing. If it's considerable I would prepare this further for https://github.com/bisq-network/proposals.

the path of my thought to get here

BSQ is currently implemented via custom off-chain data approach, where users must present data via their node. When Bisq was released it was viable approach and inevitably custom at that time. It served us well over the years though now we have resync problems and no interoperability.

Moving to a standard, created during the passed time, seems to have immediate benefits as it will enable access to the standard tools, improve exposure, free resources to Bisq-specific tasks by using a ready/typical solution for a typical task.

I entertained the idea in the chat, and the critique was 1) the Taproot assets are sad/meaningless and 2) no need to change what works. Let me briefly address these. 1) Many deployed Taproot assets may have issues, but that doesn't diminish the tech's strengths for utility tokens like BSQ. 2) It will be changed anyway as v2 is rewritten from a scratch, and as it will be leveraging Lightning, designing another/new/own approach to BSQ on Lightning seems wasteful (compared to just go Taproot-assets).

benefits

• Might solve resync issues. I think this approach allows to approach to Hackathon challenge: Scaling the DAO and BSQ #3343 completely differently.
• all Taproot-assets explorers will be working with it -- no need to spend resources on debugging and fixing the only custom one we have
• usual tools will allow BSQ transfers, balance checks, and other wallet operations
• Lightning integration out of the box
• expanded trading: possibility to expose BSQ to the wider markets and facilitate the usage of the token from both ends (easier to buy -- more usage of Bisq, easier to sell -- better incentive to contribute)
• Lower risk path forward: adopting a standard is likely less error-prone.

I'm not sure if a wallet separation is permanent or temporary feature, but the conversion would align well as BTC and BSQ could be handled in the same way in Bisq-2.

the risks

Speaking about wallets: I don't know any yet supporting Taproot-assets. But currently Lightning-lab develops the tapd with their good pace, and I bet if Bisq decide to adopt the standard, a wallet will get support earlier than Bisq will be ready to use it. If I'm mistaking here and our pace will be that fast on this then an overhead to just add a support into Sparrow looks small.

I would like to hear your views on this to think on the things I missed here. And ofc to learn if such way is considerable at all. Also it would be helpful to know what should be included in a proposal on this (beside obviously a migration spec) like maybe stages -- and your advises/concerns on those items.

[HenrikJannsen]

Thanks for your discussion.

I entertained the idea in the chat, and the critique was 1) the Taproot assets are sad/meaningless and 2) no need to change what works.

Which chat do you refer to? In Matrix, I could not find a relevant discussion on that topic. The best place would be the Bisq 1 dev room.

It will be changed anyway as v2 is rewritten from scratch, and as it will be leveraging Lightning

Actually, we have not planned to integrate the DAO directly into Bisq 2. Rough ideas are to re-architect it to address the scaling issues and isolate it as a headless app with a gRPC interface, which can then be used by the Bisq 1 desktop app. That app would get reduced to a DAO management and BSQ wallet/trading app, and potentially be used from Bisq 2 for not yet defined use cases (e.g., allowing BSQ for fee payment might be one).

We want to avoid Bisq 2 users requiring the DAO data and having to run the DAO consensus code, thus some trusted DAO node would be provided. Of course, users can opt in to run such a node themselves, and that would be welcomed, but the reality is that most would likely not do that. Though if it’s just a few, we have sufficient audit functionality so that the trust put into such provided DAO nodes does not cause much risk.

Regarding Lightning: We had some LN-related protocol plans, but after realizing that with our very limited dev forces we are already now over-stretched by developing and maintaining Bisq 1, the DAO, Bisq Easy, Bisq MuSig, and now three mobile apps, I think we have to reconsider that roadmap. After a long period of super low mining fees, the motivation for LN has also been reduced. Furthermore, I myself at least have a more critical view of LN — not from the technical perspective, but from the reality that most users run mobile apps with custodial models with questionable privacy and security properties.

Might solve resync issues

In current main, some bugs have been identified and fixed related to resync (after chain forks). I think the resync bugs are a result of our limited dev resources spent on Bisq 1 and are a pure engineering/dev problem, not a conceptual issue. In case of a chain fork, we still need to handle rolling back the DAO state to a previous safe snapshot and resync from there, also with Taproot as far as I see.

all Taproot-assets explorers will be working with it

The blockchain data are only one part of the DAO data required to arrive at a certain DAO state. In most cases, they only serve as anchoring and trust source. The p2p network data are the data carrier for the relevant DAO state transitions.

I am myself not very familiar with the specifics of Taproot Assets, but from my understanding it would serve primarily as an alternative to OP_RETURN in the way the Bisq DAO is utilizing the blockchain. Putting all the Bisq-related data (e.g., proposal, voting, ...) into the blockchain would be considered undesirable (we don't want to spam the blockchain or go the Ethereum way - this is unsustainable).

The core concept of the Bisq DAO is to use the blockchain only in the most minimal way for anchoring trust. Transactions are double-linked with Bisq p2p network data, which carry the payload. The tx is only the secure timestamping of that data.

Furthermore, there is no central issuer besides the genesis block issuance (which was funded by Bisq donations). Any compensation request is funded by the contributor, making them a new issuer for the amount the DAO accepted in voting. Not sure if that level of decentralization is possible with the Taproot-based model you have in mind. Maybe you can explain in more detail how that would work.

Furthermore, the way it is determined if a UTXO is valid BSQ is that we follow all the outputs from the genesis tx as well as follow-up compensation/reimbursement txs, which have to be valid according to the DAO rules, and manage that filtered blockchain as BSQ blocks. Not sure how that would look with Taproot — I guess it could be the same, but then it does not address our core problem: that the BSQ blockchain is growing steadily and has reached a size which is not suitable for most users to deal with.

Looking forward to your feedback!

[skaunov]

Thank you! It was really insightful for me to think over this thing and to know it's not an immediate no-no. Maybe I change this reply later, but now after I started to dive deeper into the concerns/requirements you highlighted I took a view from the different angle. I mean there are a lot of ideas to discuss on these issues, but I just see that the tech is not vetted enough for an oldest Bitcoin DAO. I feel I better take this initiative to a smaller and safer place to collect the different experience first. So instead of going into the details I'd rather ask if you have some Bitcoin DAO in mind for that. X) (Maybe a hackathon, or a startup, etc; refer that to me at any moment so I could get a chance to look deeper into these problems there.)

the link to the chat you mentioned

[HenrikJannsen]

I am not aware of any other Bitcoin-based DAO myself. If you stumble upon one, please share it — I would be interested as well. RSK follows the Ethereum model and just uses Bitcoin as a secure anchor, as far as I understand.

I guess the more important distinction than the blockchain used is the question of how they use the blockchain: as a “world computer” like Ethereum, or as a trust-minimized notary for time-stamping and signing any data which represents money, be it as an asset, a delegate (like a vote), or another representation which requires protection against double spend.

I strongly believe that the Ethereum model is heavily flawed, as it cannot scale if you want to turn every corporation and its business logic onto a blockchain. No number of second layers will solve that fundamental problem.

In the model Bisq follows, there might also be a scaling issue (or a cost issue if transactions become too expensive), as we do that timestamping per relevant DAO event. But that could be addressed more easily by batching, OpenTimestamps-like Merkle trees, or even using another “cheaper” blockchain for fast confirmation and using Bitcoin for delayed, batched anchoring to achieve a compromise of security, speed, and low costs.

The obvious problem with such a model is that the project needs its own P2P network for managing the business data flow, and I guess that is the major hurdle for most projects, as this is a non-trivial challenge. Using the blockchain’s P2P network provides a cheap solution to outsource that issue to the node runners.