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

Embedded RGB fixes #70

Merged
merged 8 commits into from
Sep 1, 2022
Merged

Embedded RGB fixes #70

merged 8 commits into from
Sep 1, 2022

Conversation

cryptoquick
Copy link
Member

Includes API changes from earlier this week, plus solves some issues in asset transfer, and includes latest changes from both of Zoe's PRs in rgb-node:

To be clear, the code duplication arrangement is temporary until we can build & contribute Embedded Storm upstream (zmq inproc / in-memory btreemap instead of sled).

The code here only fails because BDK fails to sign the PSBT because it fails to satisfy some condition. It's possible we'll need to use the RGB descriptor wallet to sign and broadcast the PSBT.

_ => Err(format_err!("Error: Unknown error in import_asset")),
},
}
pub fn import_asset(genesis: &str) -> Result<ThinAsset> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, the intention of this method is that if we have the descriptor , it returns how much tokens you have.
But really what we need for lambda is that: that if you pass the genesis or contract id AND utxo/blinded you get the ThinAsset with how many tokens you have. And if there are not utxo/blinded, then we simple get what it's being done now.

So instead of rgb_tokens_descripr, must be, utxo: Option<&str>, blinded: Option<&str> and the rest the same

I think the better is that I do a PR with my propose, but bettr give me your opinion on that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method can only get the asset by full genesis, but the genesis should be stored via lambda keyed by rgb id, and retrieved so it can be passed to this method by the client. They should be two separate operations, so that the contents can be encrypted end-to-end. Eventually all RGB methods will be run in WASM or clientside, the RGB lambdas are temporary, but the storage lambdas are permanent.

We should have a separate method that processes an entire consignment and returns all assets and balances. I haven't worked on that yet, but will do after I get transfers working.

Does that all make sense / sound good?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense, of course.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, I'll merge now

@cryptoquick cryptoquick merged commit 34ced9c into rgb-core-HT Sep 1, 2022
@cryptoquick cryptoquick deleted the rgb-core-HT-api-changes branch September 1, 2022 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants