Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: state unification, removal of confidential assets #263

Open
dr-orlovsky opened this issue Oct 16, 2024 · 5 comments
Open

Tracking: state unification, removal of confidential assets #263

dr-orlovsky opened this issue Oct 16, 2024 · 5 comments
Assignees
Labels
epic Epic task covering multiple steps of implementation refactoring Code refactoring tracking Issue tracking (multiple) other issues or PRs
Milestone

Comments

@dr-orlovsky
Copy link
Member

dr-orlovsky commented Oct 16, 2024

affects: 0.11.0-beta.9
status: wip
breaks: [ rgb-core, rgb-std, rgb-wallet, rgb-schemata, rgb-interfaces ]

Goals

  • Remove Pedersen commitments and bulleproofs
  • Unify all types of owned state (structured, fungible, attachments, rights)
  • Remove state concealements

Proposals

  • WIP

Issues

n/a

Pull requests

@crisdut
Copy link
Member

crisdut commented Oct 23, 2024

Hi @dr-orlovsky,

Does this change have implications for Liquid support?

Thanks

@dr-orlovsky
Copy link
Member Author

We have added AssetTag because we had Confidential assets, which require its presence (as was explained to me by Adam Back in Oct 2023). A side-effect of that was ability to have trustless third-party bridges with Liquid assets (what you called "Liquid compatibility"), so when we bring an asset from Liquid to RGB it can trustlessly verify it's previous liquid history.

Now, if we remove Confidential assets from RGB, we remove (temporary) ability to do trustless third-party asset bridges from Liquid. I am saying "temporary", since theoretically you can implement CA right in AluVM and that feature would be back - except that this would require quite a lot of work and won't happen soon.

Nevertheless, this is not the same as "removing all of Liquid compatibility", since we still can:

  • run RGB contracts on Liquid blockchain;
  • move assets in RGB between Bitcoin and Liquid blockchains;
  • use RGB lightning on top of Liquid;
  • issuers can issue their assets right into RGB on Liquid (burning confidential liquid assets, if needed);
  • third-parties (to users and issuers) can do a trusted asset bridges.

So the only think which is lost with this epic is trustless third-party asset bridges with Liquid - but it can be recovered in a backward-compatible way if some is willing to invest sufficient time into developing native AluVM-based CA trustless bridge.

@crisdut
Copy link
Member

crisdut commented Oct 23, 2024

* move assets in RGB between Bitcoin and Liquid blockchains;

Atomic swap, for example?

So the only think which is lost with this epic is trustless third-party asset bridges with Liquid - but it can be recovered in a backward-compatible way if some is willing to invest sufficient time into developing native AluVM-based CA trustless bridge.

Ok, sure.

Thanks for explaining!

@dr-orlovsky
Copy link
Member Author

Atomic swap, for example?

Atomic swaps are unrelated to asset tags or confidential assets and can be done before and after the discussed changes

@crisdut
Copy link
Member

crisdut commented Oct 24, 2024

Atomic swap, for example?

Atomic swaps are unrelated to asset tags or confidential assets and can be done before and after the discussed changes

Yes, yes, I agree with you. I just pointed out one example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Epic task covering multiple steps of implementation refactoring Code refactoring tracking Issue tracking (multiple) other issues or PRs
Projects
None yet
Development

No branches or pull requests

2 participants