rgb-wg/rgb

RGB smart contracts: command-line tool & wallet runtime library for desktop and mobile integration

rgb's Issues

v0.11 cli don't compile

the doc in readme.md is wrong .

cargo install rgb-wallet won't compile as it looks for an exe

cargo install --path . --all-features in /cli ( the old command ? ) allmost work . but not :)

how to distinguish imported interface and issued contract?

the methods blow should list all of them:

contract_ids_by_iface

contract_ids

error compile

Compiling rgb-contracts v0.10.0-beta.2 (C:\Users\serge\Documents\GitHub\rgb)
error[E0061]: this method takes 2 arguments but 1 argument was supplied
--> src\bin\rgb\command.rs:361:55
|
361 | if let Ok(allocations) = contract.fungible(owned.name.clone()) {
| ^^^^^^^^-------------------- an argument of type std::option::Option<&_> is missing

bug:can`t import wallet by using descriptor

I can't import one wallet. But my other wallet can.
rgb github commit hash is 680102a
I had two wallets when I was testing. One of my wallets works. But one of them doesn't work.
I tested both win and linux environments with the same problem

PS D:\rgb> rgb create -d .alice default --tapret-key-only "[6786b8cc/86h/1h/0h]tpubDCSs4JU4Kpae7ibt45FEPZb4FGcfvPhsmKCkdk6NDwSGQk2QSBS5t1txw6QoCFnDPiRtS8Tq1orGBVoeXKexNQSPor1FmLnKPCSKhqkjBSF/<0;1>/*"
RGB: command-line wallet for RGB smart contracts
     by LNP/BP Standards Association

Unable to find or parse config file; using config defaults
Loading descriptor from command-line argument ... success
Syncing ......................................................thread 'main' panicked at 'source slice length (21) does not match destination slice length (20)', C:\Users\13599\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\bp-invoice-0.11.0-beta.3\src\address.rs:321:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am using the sparrow wallet.mnemonic word:
cannon loud robust fee layer flame slot either unlock upset net immense
gasp erosion three able cook liar insect tool method extend fetch worry

rgb-runtime 0.11.0-beta.3 compile error

Do I miss any steps? I add rgb-runtime = "0.11.0-beta.3" to my Cargo.toml, then the errors comes out.

PSBT is invalid since it doublespends

Using this branch of the rgb-sandbox, where I re-introduced a second asset issuance (as it was with RGB v0.10), when trying to execute a transfer I get the following error:

Error: the provided PSBT is invalid since it doublespends on some of its inputs.

This happens using either opret or tapret as closing method.

recipient validation fails when spending a previous received allocation

Receiving the same asset twice, then trying to spend the allocation from the first received transfer fails when the recipient accepts the transfer.

In other words, in this test scenario

• wallet 1: issue an asset
• wallet 1: send (200) assets to wallet 2
• wallet 1: send (100) assets to wallet 2
• wallet 2: send (150) assets to wallet 3
  wallet 3 returns the following when calling rgb-wallet accept:

Validation failures:
- seal defined in the history as a part of operation output e8b44beee04a880a8d1220dae08b39fed49c36be1165f0e3a114867016e54ccb/0x0FA0/1 is confidential and can't be validated.
- transition bundle 60193a7a82eafa27d3aa73f5cc9fa60d89bd3d9c30fdb6618745fae3578ce34e references state transition fe1e1d7c93cad4fecec630f5a55df9306a3b05b3f5e09d337e1c197e822e8526 which is not included into the bundle input map.

Note: the amounts are designed to force the wallet to select the 1st allocation when sending (as the 2nd one is insufficient).

This is reminiscent of rgb-std #101 and #102.

The issue can be reproduced using this branch of the rgb-sandbox. To do so, execute it with tapret support (as opret is not working at the moment):

./demo.sh -v -t

suppress "stock file is absent, creating a new one" eprint

Instantiating a runtime by calling Runtime::load_attach() currently prints stock file is absent, creating a new one.

This is inconvenient and I think this output should be suppressed.
Similarly to what's been done in #23, I propose to protect that eprint behind a feature flag (e.g. log, which appears otherwise unused).

Possible error? related to set taproothost while constructing psbt.

“Taproot commitment: an OP_RETURN script containing the LNPBP-4 message is added in the top right leaf of the TapTree of the first Taproot output of the Bitcoin transaction
”
But in the pay. rs code is the use of the

        let output = psbt
            .outputs_mut()
            .find(|o| o.script.is_p2tr() && Some(&o.script) != beneficiary_script.as_ref())
            .ok_or(CompositionError::TapretRequired)?;
        // TODO: Add descriptor id to the tapret host data
        output.set_tapret_host().expect("just created");

Instead directly specify output index of 0 as the taproot host.
Observe that it actually set index 1 to taproot host. index 0 is the Beneficiary::WitnessVout gain address.

rgb-wallet compile failed

error: ailed to run custom build command for openssl-sys v0.9.98
error: he system library openssl required by crate openssl-sys was not found.

Im used docker ubuntu:latest image, and run on container。
But compile failed because of library，and fix it by install follow thing：

$ apt install libssl-dev

Maybe $ apt install pkg-config is not enough

More debug commands

The idea is to provide a set of commands to do a low-level export of debug information of different parts of the stash, indexes etc.

These commands should be prefixed with debug and be hidden from the normal docs

Also allow modification of the structures inside the consignment or stash/index using import from YAML/TOML files

DumbResolver?

i see when import and transfer there is a resolver with DumbResolver, it do nothing ? why?

rgb accept failed

RGB: command-line wallet for RGB smart contracts
     by LNP/BP Standards Association

Loading descriptor from wallet default ... success
Loading stock ... success
@000000: put     s16[0],"the issued amounts do not match between the reported global state and confidential owned state"; -> s16[0]="the issued amounts do not match between the reported global state and confidential owned state"
@000006: pccs    0x0FA0,0x07D2           ; Warning: current version of RGB Core doesn't support production of bulletproofs; thus, fungible state must be never kept concealed
->
@000011: ret                             ; -> execution stopped; st0=true
Unknown witness transactions:
- 88189d5bf2ad52417ae73825dc5496061f096e3c8cb8b6b778b13222c70260c2
Validation failures:
- operation d332f80734fe9f8671559bc9951baf3c0908d0a3723848ae4bc7644335b09771 is absent from the consignment.
- witness transaction 88189d5bf2ad52417ae73825dc5496061f096e3c8cb8b6b778b13222c70260c2 is not known to the transaction resolver.
- operation 4471926a3cbedc76b689bcaee87a93ebfbf41e40bd6cae6393cec2e923aa8427 is under a different contract rgb:2c1oFiE-V8ZxFr7hF-WXZc6CDXu-WJKziiq5R-RmkDKwUR1-3eVdMDf.

Error: consignment has transactions which are not known and thus the contract can't be imported. If you are sure that you'd like to take the risc, call `import_contract_force`.

it seems the contract id after impoted is diff not uniform

CLI not working with opret

Trying to execute a transfer via CLI fails when using opret1st as closing method.

The error that's returned is:

Error: one of the RGB assignments spent require presence of tapret output - even this is not a taproot wallet. Unable to create a valid PSBT, manual work is needed.

The behavior can be reproduced using this branch of rgb-sandbox and running the command:

./demo.sh -v

The same operation works when using tapret1st. It can be seen working with the same rgb-sandbox branch by running the command (which enables tapret1st):

./demo.sh -v -t

rgb-runtime v0.11 beta3 can not compile

when I try to compile it, the errors:

rgb issue Error

rgb import rgb20-demo.rgb This can be successful.

rgb issue 4h3xkAmiRdQs2HwQmnFVqoj5DG3NhGkJRpNZXjNrJT2N RGB20 examples/rgb20-demo.yaml
I still failed to use this command.

rgb issue 4h3xkAmiRdQs2HwQmnFVqoj5DG3NhGkJRpNZXjNrJT2N RGB20 examples/rgb20-demo.yaml
Error: schema urn:lnp-bp:sc:4h3xkA-miRdQs2H-wQmnFVqo-j5DG3NhG-kJRpNZXj-NrJT2N#vision-scuba-sample is unknown.
It may happen due to RGB standard library bug, or indicate internal stash inconsistency and compromised stash data storage.

I need to issue a new contract and recompile it instead of importing the already compiled contract.

asset name length clarification

While trying to issue an asset I've received an error because name didn't meet the requirement of being at least 5 chars long. I'm wondering why this limitation is there, before (in v0.9) it was limited from 1 up to 256 chars. @dr-orlovsky could you please clarify this change?

Improve error reporting

When the contract doesn't have sufficient state to pay the invoice the error message is not giving a clear indication of what's going wrong.

Original report: RGB-WG/rgb-std#67

How to run a RGB node?

fix: Complete the match case of Command::SetHost

match method {
    CloseMethod::OpretFirst => {
        psbt.outputs_mut()
            .find(|o| o.script.is_op_return() && !o.is_opret_host())
            .and_then(|outp| {
                psbt_modified = true;
                outp.set_opret_host().ok()
            });
        // psbt.unsigned_tx
        //     .output
        //     .iter()
        //     .zip(&mut psbt.outputs)
        //     .find(|(o, outp)| {
        //         o.script_pubkey.is_op_return() && !outp.is_opret_host()
        //     })
        //     .and_then(|(_, outp)| {
        //         psbt_modified = true;
        //         outp.set_opret_host().ok()
        //     });
    }
    CloseMethod::TapretFirst => {
        psbt.outputs_mut()
            .find(|o| o.script.is_p2tr() && !o.is_tapret_host())
            .and_then(|outp| {
                psbt_modified = true;
                outp.set_tapret_host().ok()
            });
        // psbt.unsigned_tx
        //     .output
        //     .iter()
        //     .zip(&mut psbt.outputs)
        //     .find(|(o, outp)| {
        //         o.script_pubkey.is_v1_p2tr() && !outp.is_tapret_host()
        //     })
        //     .and_then(|(_, outp)| {
        //         psbt_modified = true;
        //         outp.set_tapret_host().ok()
        //     });
    }
    _ => {}
};

RGB state is not updated on blockchain re-orgs or RBFs

Using this branch of rgb-sandbox I get zero balance after accepting a transfer twice.

Here's what the test run does:

• set up the test environment, the wallets and the asset
• stop esplora, save esplora and wallet 1 (issuer/sender) data
• restart esplora
• execute a transfer between wallet 1 and 2, using a blinded UTXO
• stop esplora, restore saved esplora and wallet 1 data
• execute the same transfer between wallet 1 and 2 again

The 2nd transfer re-uses the same invoice as the 1st one and overrides the expected final balance, as it's supposed to be the same once all is done.

Before the 2nd transfer, the recipient sees one UTXO and the asset balance from the 1st transfer, as expected. The transfer is successful, including the recipient accepting it into the stash.

The problem is that, after the 2nd transfer, the recipient sees no UTXOs and therefore the asset balance is 0. The expected outcome is that the same UTXO and asset balance as before the 2nd transfer should be visible.

This happens with both opret and tapret.

Wrong MAGIC Number in PSBT (transfer step)

Description

Version: 62b5009

I noticed the wrong behavior in Psbt::encode in the transfer step.

For some reason, when I try to sign the PSBT created in the transfer step, the descriptor-wallet returns:

Magic bytes for a PSBT must be the ASCII for "PSBT" serialized in the most significant byte order.

But, this problem does not occur when I try to sing the PSBT created by the command rgb construct ....

Asset state is not reported

alice is the asset owner,

after bob create the invoice, alice transfer and bob accept

bob state the contract, the output like blow:
RGB: command-line wallet for RGB smart contracts
by LNP/BP Standards Association

Loading descriptor from wallet default ... success
Loading stock ... success
Global:
spec := (naming=(ticker=("DBG"), name=("Debug asset"), details=1(("Pay attention: the asset has no value"))), precision=2)
data := (terms=("SUBJECT TO, AND WITHOUT IN ANY WAY LIMITING, THE REPRESENTATIONS AND WARRANTIES OF ANY SELLER EXPRESSLY SET FORTH IN THIS AGREEMENT OR ANY OTHER EXPRESS OBLIGATION OF SELLERS PURSUANT TO THE TERMS HEREOF, AND ACKNOWLEDGING THE PRIOR USE OF THE PROPERTY AND PURCHASER’S OPPORTUNITY TO INSPECT THE PROPERTY, PURCHASER AGREES TO PURCHASE THE PROPERTY “AS IS”, “WHERE IS”, WITH ALL FAULTS AND CONDITIONS THEREON. ANY WRITTEN OR ORAL INFORMATION, REPORTS, STATEMENTS, DOCUMENTS OR RECORDS CONCERNING THE PROPERTY PROVIDED OR MADE AVAILABLE TO PURCHASER, ITS AGENTS OR CONSTITUENTS BY ANY SELLER, ANY SELLER’S AGENTS, EMPLOYEES OR THIRD PARTIES REPRESENTING OR PURPORTING TO REPRESENT ANY SELLER, SHALL NOT BE REPRESENTATIONS OR WARRANTIES, UNLESS SPECIFICALLY SET FORTH HEREIN. IN PURCHASING THE PROPERTY OR TAKING OTHER ACTION HEREUNDER, PURCHASER HAS NOT AND SHALL NOT RELY ON ANY SUCH DISCLOSURES, BUT RATHER, PURCHASER SHALL RELY ONLY ON PURCHASER’S OWN INSPECTION OF THE PROPERTY AND THE REPRESENTATIONS AND WARRANTIES HEREIN. PURCHASER ACKNOWLEDGES THAT THE PURCHASE PRICE REFLECTS AND TAKES INTO ACCOUNT THAT THE PROPERTY IS BEING SOLD “AS IS”.
"), media=~)
issuedSupply := (100000000)
created := (1687969158)

Owned:
assetOwner:

the owner is empty, and i have broadcast the psbt which created by transfer command

Not accounting for non-RGB inputs in coin selection

Trying to execute a few transfers using this branch of rgb-sandbox I run into the following error:

Error: not enough funds to pay fee of 400 sats; all inputs contain 2000 sats and outputs spends 2000 sats out of them.

The wallet should have enough bitcoins as the unspents come up as:

Height     Amount, ṩ    Outpoint                                                                                                                                                                                                                                                                                               
bcrt1q06vjlq89kufjgzenwusm99l6hv5ygxhur8qun8    &9/0                                                                                                                                                                                                                                                                           
107             2000    e6cfb776a1e03165f6e739a6452231ac9d30fb20cbde0ae130ed7b10d20dc7b1:0                                                                                                                                                                                                                                     
106             2000    7a39dd007218bdbf3d6d1a2b919700d9a144a1d2cab20cace5a8ad57df2395b7:0                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                                                                               
bcrt1qwke7jgvxuwcwk8q4m4mglgmltyfzasde5c4nsj    &0/0                                                                                                                                                                                                                                                                           
105        100000000    2a0bd1672cfb051c7c0627d1295c07325974b53048a87169c80b44f8698c949e:0                                                                                                                                                                                                                                     

I guess this happens because the input selection is not adding more inputs if needed to cover fees (or outputs), but I haven't dug deeper than this.

Remove a contract

We think it would be useful to have a method to "de-register"/"forget" an asset, or in other words to remove data related to an asset from the stash. Currently AFAIK there is no way to do this. We think there could be cases where a user doesn't care anymore about an asset, he is ok with burning it, but to reduce stash data consumption (and possibly improve performance) it would be nice to have a method that allows this.
This is not urgent but a nice to have, IMO it can be done after 0.11 testing.

I am confused what is the core difference between RGB20 and RGB25? Why do we need both of them?

Examples for create/import wallet with v0.11

I'm trying to use the latest version(i.e master/v0.11) to create a wallet, however, got an error with unknown username 'DCSgjFcLS9iZkN6H4BxuhUga'. Here is the command i run:

./rgb create alice --tapret-key-only tapret(tpubDCSgjFcLS9iZkN6H4BxuhUgabTchh3qqad49fYqndF595dnhcVTApsaEfGXXMVJTh2wrT2wKWPbcrSaX6VNMSaBp8NYThxHj3DA8oDiUNcK)

Also, i found that in the source codes, there're bp.toml and rgb.toml configuration files. Is there some examples for these two configure file, i.e. What fields can i set in these two file?

transfer accept succeeds even if transaction has not been confirmed

Using our rgb-sandbox I have tried accepting transfers for which the anchoring transaction has not been confirmed and it unexpectedly succeeds.

I expected the accept operation to return a failure instead, as the --force option is not provided.

I have prepared a modified version of the sandbox in this branch to reproduce the condition. Running the demo.sh script with the --noconf option disables mining after broadcasting the transfer transactions. This can be confirmed e.g. by looking at bitcoind logs while the script is running (docker compose logs -f bitcoind).

duplicate outpoint when transfer multi RGB20 from 1 UTXO

1. alice tranfer 100 RGB20 to bob
2. alice tranfer 50 RGB20 to bob

after above steps, bob's one UTXO have 150 RGB20 with two witnesses

3. bob transfer 100+ (120 eg) to anyone else, it should combined payment

Result: the psbt will have duplicate outpoint ( sparrow will report error)

add support for electrum server

Currently, the only supported explorer is esplora. It would be useful to also be able to use an electrum server (e.g. electrs) as was the case in RGB v0.10.

electrs requires less resources than esplora and current RGB developers and users already rely on an electrum server, so switching to esplora requires quite some work and is therefore not ideal.

I know esplora was the fastest solution but I think having electrum server support is still worth it. @dr-orlovsky can you please add electrum server support?

Uable to use the rgb state command to link the wallet

These might be newbie questions.
`
% rgb --version
rgb-contracts 0.10.2
% rgb state 2h1ANBx-okZWRsUcx-AsyoQ9h56-oetttA7zD-k6L741i9H-GKTmcNL RGB20 -w default
Global:
spec := (naming=(ticker=("TST"), name=("Test asset by RGB command-line"), details=), precision=8)
data := (terms=("SUBJECT TO, AND WITHOUT IN ANY WAY LIMITING, THE REPRESENTATIONS AND WARRANTIES OF ANY SELLER EXPRESSLY SET FORTH IN THIS AGREEMENT OR ANY OTHER EXPRESS OBLIGATION OF SELLERS PURSUANT TO THE TERMS HEREOF, AND ACKNOWLEDGING THE PRIOR USE OF THE PROPERTY AND PURCHASER’S OPPORTUNITY TO INSPECT THE PROPERTY, PURCHASER AGREES TO PURCHASE THE PROPERTY “AS IS”, “WHERE IS”, WITH ALL FAULTS AND CONDITIONS THEREON. ANY WRITTEN OR ORAL INFORMATION, REPORTS, STATEMENTS, DOCUMENTS OR RECORDS CONCERNING THE PROPERTY PROVIDED OR MADE AVAILABLE TO PURCHASER, ITS AGENTS OR CONSTITUENTS BY ANY SELLER, ANY SELLER’S AGENTS, EMPLOYEES OR THIRD PARTIES REPRESENTING OR PURPORTING TO REPRESENT ANY SELLER, SHALL NOT BE REPRESENTATIONS OR WARRANTIES, UNLESS SPECIFICALLY SET FORTH HEREIN. IN PURCHASING THE PROPERTY OR TAKING OTHER ACTION HEREUNDER, PURCHASER HAS NOT AND SHALL NOT RELY ON ANY SUCH DISCLOSURES, BUT RATHER, PURCHASER SHALL RELY ONLY ON PURCHASER’S OWN INSPECTION OF THE PROPERTY AND THE REPRESENTATIONS AND WARRANTIES HEREIN. PURCHASER ACKNOWLEDGES THAT THE PURCHASE PRICE REFLECTS AND TAKES INTO ACCOUNT THAT THE PROPERTY IS BEING SOLD “AS IS”.
"), media=)
issuedSupply := (100000000000000)
created := (1687969158)

Owned:
assetOwner:
amount=100000000000000, utxo=ca43e9a01782343c78fa67cc20d75d81545a8d38a031d361180c36c088639fed:0, witness=~ # owner unknown
% rgb utxos
%
`
When I tried the demo process in the https://www.youtube.com/watch?v=P5UQJAaan0I (RGB 0.10 realease Part IV), I failed to link the wallet to the contract (after I issued the contract and created the wallet). It suppossed to have derivation right?
BTW, for the command "rgb invoice" in the demo, how should I construct the Seal (tapret1st:xxxxx) from tx?

Provide separate file storage for stash, index and state

Strange behavior in `rgb state` method

Hi @dr-orlovsky,

Initially, I opened this issue because I had found strange behavior in the rgb state method. After investigating, I discovered that the bug is actually in the strict_encoding lib. So, I opened a PR to fix the issue.

When I execute the rgb state twice consecutively, the method returns the error below:

thread 'main' panicked at 'unknown contract: InternalInconsistency(Stash(IfaceImplAbsent(IfaceId(Array<32>(96c1c4c96bd199ff5a65a0609a985c72672b23a23b3832688940f197e302f701)), SchemaId(Array<32>(36d5a42aca71a4032167d37384a5e89bc314991a46f8a69381b4887dbcc8684f)))))', src/bin/rgb/command.rs:249:22
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

When we execute the rgb info before rgb state, the error does not happen. Also, I changed these lines of code by the code below, and I sometimes noticed the method stock.iface_by_name returned a wrong face_id:

Less confusing name for unresolved txids in validation status

Context: #29 (comment)

rgb issue error

rgb issue 4h3xkAmiRdQs2HwQmnFVqoj5DG3NhGkJRpNZXjNrJT2N RGB20 examples/rgb20-demo.yaml
Error: schema urn:lnp-bp:sc:4h3xkA-miRdQs2H-wQmnFVqo-j5DG3NhG-kJRpNZXj-NrJT2N#vision-scuba-sample is unknown.
It may happen due to RGB standard library bug, or indicate internal stash inconsistency and compromised stash data storage.

version: rgb-contracts 0.10.1
chain: default

Unable to import any of the examples.

I have pulled the repository and all the code is up to date.

I received an error message when running rgb -w xavier import examples/rgb20-demo.toml.

Error: Invalid file data.

I received an error message while running rgb -w xavier import examples/rgb20-demo.rgb.

Error: Encountered unsupported value `1` for enum `ContainerVer` during decode operation.

Error: state provided via PSBT inputs is not sufficient to cover invoice state requirements.

Sir，the version I'm using is v0.10, transfer return Error: state provided via PSBT inputs is not sufficient to cover invoice state requirements

FIle: rgb20-demo.yaml

assetOwner:
    seal: is bob utxo

---

rgb -d .bob create bob tpub
rgb -d .alice create alice tpub

rgb -d .bob issue `schemata` RGB20 ./examples/rgb20-demo.yaml
- A new contract rgb:2nAASEf-9UCWzMNLB-LAkTcFpYh-8NN7ASWEY-5BMfeKxiX-fTyMdf1 is issued and added to the stash. 

rgb -d .bob export rgb:2nAASEf-9UCWzMNLB-LAkTcFpYh-8NN7ASWEY-5BMfeKxiX-fTyMdf1 ./examples/rgb20-demo.rgb
rgb -d .alice import ./examples/rgb20-demo.rgb

Now owner is bob,

rgb -d .alice invoice 2nAASEf-9UCWzMNLB-LAkTcFpYh-8NN7ASWEY-5BMfeKxiX-fTyMdf1 RGB20 1000 tapret1st: `alice utxo`
- return invoice

After I saved the psbt file using sparrow wallet(bob send pbst).

rgb -d .bob set-host ./psbt/20demo.psbt
rgb -d .bob transfer ./psbt/20demo.psbt $invoice  ./examples/transfer.rgb
return Error: state provided via PSBT inputs is not sufficient to cover invoice state requirements.

---

Thanks for your help.

provide offline methods

The current implementation of Runtime requires a valid electrum_url in order to be loaded. This means that all RGB methods require to be online, even methods that do not have this requirement because they actually use only data saved on disk (e.g. iface_by_name and contract_iface to get asset metadata). I propose to make all methods that do not require a blockchain resolver available even when offline.

I think there are many ways to implement this. One solution could be: making the electrum_url parameter of Runtime::load an optional one, then of course make also the resolver Runtime's' field optional and check for it's presence only on methods that actually need it, returning an error if the Runtime has been instantiated without an electrum URL.

@dr-orlovsky what do you think?

make ContractText optional or improve error message

I've tried issuing an asset without the ContractText and I received this error:

thread 'main' panicked at 'internal error: failed validating self-issued contract: Consignment { validation_status: Some(Status { unresolved_txids: [], unmined_terminals: [], failures: [SchemaGlobalStateOccurrences(OpId(Array<32>(e67cc09d8f17f2c60a7d7c0e3fa05f36c833fc27c6078cb031bac8cdab922ec2)), 1, OccurrencesMismatch { min: 1, max: 1, found: 0 })], warnings: [], info: [] }), version: V1, transfer: false, schema: Schema { ffv: Ffv(0), subset_of: None, global_types: Confined({0: GlobalStateSchema { sem_id: SemId(Array<32>(2ab484b50de3237b6d9c7ffe119cac7ec4f08d6aac5f16abd61a1a5034f3aba4)), max_items: 1 }, 1: GlobalStateSchema { sem_id: SemId(Array<32>(f0d3a8af463a63cefc4a3a212d49f49137076a787e6f88f986303d0863ddca30)), max_items: 1 }}), owned_types: Confined({0: Fungible(Unsigned64Bit)}), valency_types: Confined({}), genesis: GenesisSchema { metadata: SemId(Array<32>(c6bdee62481531f0f5e0758cda686053c050c4fc4ad1219a5c5b8e5bfdc1b6b1)), globals: Confined({0: Once, 1: Once}), assignments: Confined({0: OnceOrMore}), valencies: Confined({}) }, extensions: Confined({}), transitions: Confined({0: TransitionSchema { metadata: SemId(Array<32>(c6bdee62481531f0f5e0758cda686053c050c4fc4ad1219a5c5b8e5bfdc1b6b1)), globals: Confined({}), inputs: Confined({0: OnceOrMore}), assignments: Confined({0: OnceOrMore}), valencies: Confined({}) }}), type_system: TypeSystem(Confined({SemId(Array<32>(228336739c9b08ca2bf3ac42343d91b1e7b0882c5995ce3daf9d6bf47fd30345)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("ContractName") }), ty: Tuple(UnnamedFields(Confined([SemId(Array<32>(e580dccf6f4e623f25eb4378b4d99705736ca36b66661a2c00f8a489e472b7ab))]))) }, SemId(Array<32>(2ab484b50de3237b6d9c7ffe119cac7ec4f08d6aac5f16abd61a1a5034f3aba4)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("Nominal") }), ty: Struct(NamedFields(Confined([Field { name: FieldName("ticker"), ty: SemId(Array<32>(92e75ca87a0d45ef319dd973902d8da2d2682e4c7e23df479bfe7be842983506)) }, Field { name: FieldName("name"), ty: SemId(Array<32>(228336739c9b08ca2bf3ac42343d91b1e7b0882c5995ce3daf9d6bf47fd30345)) }, Field { name: FieldName("details"), ty: SemId(Array<32>(365613c0314392f9736b10b036646ff96cea7885a19c19f20dfbd4b664034e4a)) }, Field { name: FieldName("precision"), ty: SemId(Array<32>(ca4347dfc005310a1ae5592b7dd6f3e93645e5231305fbe992ef33ce2cdae31e)) }]))) }, SemId(Array<32>(365613c0314392f9736b10b036646ff96cea7885a19c19f20dfbd4b664034e4a)): TypeInfo { fqn: None, ty: Union(UnionVariants(Confined({Variant { name: FieldName("none"), tag: 0 }: SemId(Array<32>(c6bdee62481531f0f5e0758cda686053c050c4fc4ad1219a5c5b8e5bfdc1b6b1)), Variant { name: FieldName("some"), tag: 1 }: SemId(Array<32>(d0a0bacb5647452dc535ab3a9535a699a55fa86ff239129719bf2e5004639414))}))) }, SemId(Array<32>(3e558ffa0f0c38c22b61be4d110b893694d51c534c706f348af313251ec90336)): TypeInfo { fqn: None, ty: List(SemId(Array<32>(61cd903df3b4fbb4d828d35c53f976e3f81dc9e11820b2aa76661e4d28a25510)), Sizing { min: 0, max: 65535 }) }, SemId(Array<32>(446fbb71b827037e6df7f81d838288365e152ba4dc406d6a43920dc98a6c6f25)): TypeInfo { fqn: None, ty: List(SemId(Array<32>(61cd903df3b4fbb4d828d35c53f976e3f81dc9e11820b2aa76661e4d28a25510)), Sizing { min: 40, max: 255 }) }, SemId(Array<32>(5577ee213895eed3a4a4e822db7cf6078f4b5e20d77270ba3c10bf8973c6cd4b)): TypeInfo { fqn: None, ty: Enum(EnumVariants(Confined({Variant { name: FieldName("_32"), tag: 32 }, Variant { name: FieldName("_33"), tag: 33 }, Variant { name: FieldName("_34"), tag: 34 }, Variant { name: FieldName("_35"), tag: 35 }, Variant { name: FieldName("_36"), tag: 36 }, Variant { name: FieldName("_37"), tag: 37 }, Variant { name: FieldName("_38"), tag: 38 }, Variant { name: FieldName("_39"), tag: 39 }, Variant { name: FieldName("_40"), tag: 40 }, Variant { name: FieldName("_41"), tag: 41 }, Variant { name: FieldName("_42"), tag: 42 }, Variant { name: FieldName("_43"), tag: 43 }, Variant { name: FieldName("_44"), tag: 44 }, Variant { name: FieldName("_45"), tag: 45 }, Variant { name: FieldName("_46"), tag: 46 }, Variant { name: FieldName("_47"), tag: 47 }, Variant { name: FieldName("_48"), tag: 48 }, Variant { name: FieldName("_49"), tag: 49 }, Variant { name: FieldName("_50"), tag: 50 }, Variant { name: FieldName("_51"), tag: 51 }, Variant { name: FieldName("_52"), tag: 52 }, Variant { name: FieldName("_53"), tag: 53 }, Variant { name: FieldName("_54"), tag: 54 }, Variant { name: FieldName("_55"), tag: 55 }, Variant { name: FieldName("_56"), tag: 56 }, Variant { name: FieldName("_57"), tag: 57 }, Variant { name: FieldName("_58"), tag: 58 }, Variant { name: FieldName("_59"), tag: 59 }, Variant { name: FieldName("_60"), tag: 60 }, Variant { name: FieldName("_61"), tag: 61 }, Variant { name: FieldName("_62"), tag: 62 }, Variant { name: FieldName("_63"), tag: 63 }, Variant { name: FieldName("_64"), tag: 64 }, Variant { name: FieldName("_65"), tag: 65 }, Variant { name: FieldName("_66"), tag: 66 }, Variant { name: FieldName("_67"), tag: 67 }, Variant { name: FieldName("_68"), tag: 68 }, Variant { name: FieldName("_69"), tag: 69 }, Variant { name: FieldName("_70"), tag: 70 }, Variant { name: FieldName("_71"), tag: 71 }, Variant { name: FieldName("_72"), tag: 72 }, Variant { name: FieldName("_73"), tag: 73 }, Variant { name: FieldName("_74"), tag: 74 }, Variant { name: FieldName("_75"), tag: 75 }, Variant { name: FieldName("_76"), tag: 76 }, Variant { name: FieldName("_77"), tag: 77 }, Variant { name: FieldName("_78"), tag: 78 }, Variant { name: FieldName("_79"), tag: 79 }, Variant { name: FieldName("_80"), tag: 80 }, Variant { name: FieldName("_81"), tag: 81 }, Variant { name: FieldName("_82"), tag: 82 }, Variant { name: FieldName("_83"), tag: 83 }, Variant { name: FieldName("_84"), tag: 84 }, Variant { name: FieldName("_85"), tag: 85 }, Variant { name: FieldName("_86"), tag: 86 }, Variant { name: FieldName("_87"), tag: 87 }, Variant { name: FieldName("_88"), tag: 88 }, Variant { name: FieldName("_89"), tag: 89 }, Variant { name: FieldName("_90"), tag: 90 }, Variant { name: FieldName("_91"), tag: 91 }, Variant { name: FieldName("_92"), tag: 92 }, Variant { name: FieldName("_93"), tag: 93 }, Variant { name: FieldName("_94"), tag: 94 }, Variant { name: FieldName("_95"), tag: 95 }, Variant { name: FieldName("_96"), tag: 96 }, Variant { name: FieldName("_97"), tag: 97 }, Variant { name: FieldName("_98"), tag: 98 }, Variant { name: FieldName("_99"), tag: 99 }, Variant { name: FieldName("_100"), tag: 100 }, Variant { name: FieldName("_101"), tag: 101 }, Variant { name: FieldName("_102"), tag: 102 }, Variant { name: FieldName("_103"), tag: 103 }, Variant { name: FieldName("_104"), tag: 104 }, Variant { name: FieldName("_105"), tag: 105 }, Variant { name: FieldName("_106"), tag: 106 }, Variant { name: FieldName("_107"), tag: 107 }, Variant { name: FieldName("_108"), tag: 108 }, Variant { name: FieldName("_109"), tag: 109 }, Variant { name: FieldName("_110"), tag: 110 }, Variant { name: FieldName("_111"), tag: 111 }, Variant { name: FieldName("_112"), tag: 112 }, Variant { name: FieldName("_113"), tag: 113 }, Variant { name: FieldName("_114"), tag: 114 }, Variant { name: FieldName("_115"), tag: 115 }, Variant { name: FieldName("_116"), tag: 116 }, Variant { name: FieldName("_117"), tag: 117 }, Variant { name: FieldName("_118"), tag: 118 }, Variant { name: FieldName("_119"), tag: 119 }, Variant { name: FieldName("_120"), tag: 120 }, Variant { name: FieldName("_121"), tag: 121 }, Variant { name: FieldName("_122"), tag: 122 }, Variant { name: FieldName("_123"), tag: 123 }, Variant { name: FieldName("_124"), tag: 124 }, Variant { name: FieldName("_125"), tag: 125 }, Variant { name: FieldName("_126"), tag: 126 }, Variant { name: FieldName("_127"), tag: 127 }}))) }, SemId(Array<32>(5cd0c3c0db677e225d50c0cd55a38fd2a79d3a29d625e34f78dfd6166c3cb806)): TypeInfo { fqn: None, ty: List(SemId(Array<32>(5577ee213895eed3a4a4e822db7cf6078f4b5e20d77270ba3c10bf8973c6cd4b)), Sizing { min: 1, max: 8 }) }, SemId(Array<32>(61cd903df3b4fbb4d828d35c53f976e3f81dc9e11820b2aa76661e4d28a25510)): TypeInfo { fqn: None, ty: UnicodeChar }, SemId(Array<32>(6fc6963706a108342019e8f169da7ef48a8f43c8a818832446f3ee17a8b539bc)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("ContractDetails") }), ty: Tuple(UnnamedFields(Confined([SemId(Array<32>(446fbb71b827037e6df7f81d838288365e152ba4dc406d6a43920dc98a6c6f25))]))) }, SemId(Array<32>(92e75ca87a0d45ef319dd973902d8da2d2682e4c7e23df479bfe7be842983506)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("Ticker") }), ty: Tuple(UnnamedFields(Confined([SemId(Array<32>(5cd0c3c0db677e225d50c0cd55a38fd2a79d3a29d625e34f78dfd6166c3cb806))]))) }, SemId(Array<32>(c6bdee62481531f0f5e0758cda686053c050c4fc4ad1219a5c5b8e5bfdc1b6b1)): TypeInfo { fqn: None, ty: Primitive(Primitive(0)) }, SemId(Array<32>(ca4347dfc005310a1ae5592b7dd6f3e93645e5231305fbe992ef33ce2cdae31e)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("Precision") }), ty: Enum(EnumVariants(Confined({Variant { name: FieldName("indivisible"), tag: 0 }, Variant { name: FieldName("deci"), tag: 1 }, Variant { name: FieldName("centi"), tag: 2 }, Variant { name: FieldName("milli"), tag: 3 }, Variant { name: FieldName("micro"), tag: 6 }, Variant { name: FieldName("deciMicro"), tag: 7 }, Variant { name: FieldName("centiMicro"), tag: 8 }, Variant { name: FieldName("nano"), tag: 9 }, Variant { name: FieldName("deciNano"), tag: 10 }, Variant { name: FieldName("centiNano"), tag: 11 }, Variant { name: FieldName("pico"), tag: 12 }, Variant { name: FieldName("deciPico"), tag: 13 }, Variant { name: FieldName("centiPico"), tag: 14 }, Variant { name: FieldName("femto"), tag: 15 }, Variant { name: FieldName("deciFemto"), tag: 16 }, Variant { name: FieldName("centiFemto"), tag: 17 }, Variant { name: FieldName("atto"), tag: 18 }}))) }, SemId(Array<32>(d0a0bacb5647452dc535ab3a9535a699a55fa86ff239129719bf2e5004639414)): TypeInfo { fqn: None, ty: Tuple(UnnamedFields(Confined([SemId(Array<32>(6fc6963706a108342019e8f169da7ef48a8f43c8a818832446f3ee17a8b539bc))]))) }, SemId(Array<32>(e580dccf6f4e623f25eb4378b4d99705736ca36b66661a2c00f8a489e472b7ab)): TypeInfo { fqn: None, ty: List(SemId(Array<32>(61cd903df3b4fbb4d828d35c53f976e3f81dc9e11820b2aa76661e4d28a25510)), Sizing { min: 5, max: 40 }) }, SemId(Array<32>(f0d3a8af463a63cefc4a3a212d49f49137076a787e6f88f986303d0863ddca30)): TypeInfo { fqn: Some(TypeFqn { lib: LibName("RGBContract"), name: TypeName("ContractText") }), ty: Tuple(UnnamedFields(Confined([SemId(Array<32>(3e558ffa0f0c38c22b61be4d110b893694d51c534c706f348af313251ec90336))]))) }})), script: AluVM(AluScript { libs: Confined({LibId(Array<32>(0e27a1ddfa53b021015034df8a038caa840d9d651fd22b6aa6f892966adf567e)): Lib { isae: IsaSeg({"RGB"}), code: ByteStr("d00000"), data: ByteStr(""), libs: LibSeg { set: {}, table: {} } }}), entry_points: Confined({ValidateOwnedState(0): LibSite { lib: LibId(Array<32>(0e27a1ddfa53b021015034df8a038caa840d9d651fd22b6aa6f892966adf567e)), pos: 0 }}) }) }, ifaces: Confined({IfaceId(Array<32>(96b4abb5794e7ef3bed670977356daf1260412e229bdb041eace77f1d88614bf)): IfacePair { iface: Iface { version: V1, name: TypeName("RGB20"), global_state: Confined({TypeName("ContractText"): Req { info: Typed(SemId(Array<32>(f0d3a8af463a63cefc4a3a212d49f49137076a787e6f88f986303d0863ddca30))), required: true }, TypeName("Nominal"): Req { info: Typed(SemId(Array<32>(2ab484b50de3237b6d9c7ffe119cac7ec4f08d6aac5f16abd61a1a5034f3aba4))), required: true }}), assignments: Confined({TypeName("Assets"): AssignIface { public: false, owned_state: Amount }}), valencies: Confined({}), genesis: GenesisIface { metadata: None, global: Confined({TypeName("ContractText"): Once, TypeName("Nominal"): Once}), assignments: Confined({TypeName("Assets"): OnceOrMore}), valencies: Confined({}) }, transitions: Confined({TypeName("Transfer"): TransitionIface { metadata: None, globals: Confined({}), inputs: Confined({TypeName("Assets"): OnceOrMore}), assignments: Confined({TypeName("Assets"): OnceOrMore}), valencies: Confined({}), default_assignment: Some(TypeName("Assets")) }}), extensions: Confined({}), default_operation: Some(TypeName("Transfer")) }, iimpl: IfaceImpl { version: V1, schema_id: SchemaId(Array<32>(36d5a42aca71a4032167d37384a5e89bc314991a46f8a69381b4887dbcc8684f)), iface_id: IfaceId(Array<32>(96b4abb5794e7ef3bed670977356daf1260412e229bdb041eace77f1d88614bf)), global_state: Confined({NamedType { id: 0, name: TypeName("Nominal") }, NamedType { id: 1, name: TypeName("ContractText") }}), assignments: Confined({NamedType { id: 0, name: TypeName("Assets") }}), valencies: Confined({}), transitions: Confined({NamedType { id: 0, name: TypeName("Transfer") }}), extensions: Confined({}) } }}), supplements: Confined({}), genesis: Genesis { ffv: Ffv(0), schema_id: SchemaId(Array<32>(36d5a42aca71a4032167d37384a5e89bc314991a46f8a69381b4887dbcc8684f)), chain: Regtest, metadata: Confined([]), globals: GlobalState(Confined({0: GlobalValues(Confined([RevealedData("\u{4}USDT\nUSD Tether\0\0")]))})), assignments: Assignments(Confined({0: Fungible(Confined([Revealed { seal: BlindSeal { method: OpretFirst, txid: Txid("8d455eb2147a3bd3c6c30390d76653b025ff599b1b5c64afbfa19d9e0271759e"), vout: Vout(0), blinding: 18219531870053859832 }, state: RevealedValue { value: Bits64(2000), blinding: BlindingFactor(Array<32>(d20a0500378b1d37f55d56369d7890fc5e40143d257cc13169f5c6f2ad87bac6)) } }]))})), valencies: Confined({}) }, terminals: Confined({}), bundles: Confined([]), extensions: Confined([]), attachments: Confined({}), signatures: Confined({}) }', src/bin/rgb/command.rs:490:22

I'm wondering what's the reason to make ContractText mandatory. @dr-orlovsky can it be made optional?

Anyway, if it stays mandatory I think that the error message could be improved.

Error when execute a rgb20 transfer

I'm just testing a rgb20 transfer, however, got error when run rgb transfer <rgb-transfer-psbt-file> <invoice> <rgb-transfer-output-file>, here is the error message:

Error: not enough PSBT output found to put all required state (can't add assignment type 4000 for unspecified-velocity state).

Is that mean i constructed a wrong psbt file? I'm just using the utxo which is showed in Owned section with rgb state command as inputs. Here is what i do:

1. Using Sparrow wallet to send to an different address which is belongs to the wallet itself 1000 satoshis;
2. click create transaction and then Finalize Transaction for Signing.
3. save the transaction by click Save Transaction.

Cause the wallet is a new wallet, and there's only one unspent utxo, so the input is exact the utxo (or in RGB world, sealer) used in the RGB20 contracts. So how can i fix this error. Also, i found that rgb utxos returns null after created default wallet while the wallet do has utxos. BTW. my rgb version is: 0.10.0

Wrong beneficiary in rgb transfer step

Description

Version: 62b5009

When we try running the transfer command below, the cli returns: Error: taproot output doesn't specify internal key.

rgb  -w default transfer rgb:28hM4....f86n 100 ./transfer.rgb

After investigate, I noticed that the transfer step mistakenly uses the invoice beneficiary, transferring all the satoshis to him, which ends up producing an incorrect output in the PSBT.

Type: bug

question: psbt output address diff with rgb address

1. contruct psbt, the address derive is default to keychain 10 and without taproot tweaks

2. rgb address -k 10 -i index, it derived the address with taproot tweaks

the result is step 1 and step 2 address is not same even though the keychain and index are all same

is this behavior normal?
how to sign the psbt?

operation slow-down

Following the development of RGB crates we noticed a significant slow-down of some RGB operations.

This can clearly be felt when running in debug mode and has been spotted both using our rgb-lib and rgb-sandbox projects.

I prepared two rgb-sandbox branches, which use different dependencies and time the rgb import and rgb issue commands, to show the difference:

• v0.10_fast uses older dependencies (plus some small fixes)
• v0.10_slow uses the current master

Comparing runs with those branches I get the following results, which show a greater than 10x time increase:

• v0.10_fast

    rgb import:   372 ms
    rgb issue:    969 ms

• v0.10_slow

    rgb import:  5604 ms
    rgb issue:  11628 ms

For reference, these are the results when building in release mode, which still show a ~5x time increase:

• v0.10_fast

    rgb import:    69 ms
    rgb issue:     94 ms

• v0.10_slow

    rgb import:   305 ms
    rgb issue:    590 ms

It seems to me it's worth investigating the cause of such a sizable slow-down.

Here's a list of the main differences in dependencies between the two versions:

crate	v0.10_fast	v0.10_slow
rgb-core	0.10.4	1de67f7b
rgb-wallet / rgb-std	d90868a7	79eb02cc
strict_encoding	2.3.0	2.4.0
strict_types	1.3.0	1.4.0

PS: I don't think this is the project where the "bug" is, but opening here as it's the main CLI entrypoint, what rgb-sandbox uses and what I changed to show the difference.

de-accept a consignment

If my understanding is correct, with current implementation we should accept a consignment only when we are confident the transfer is final and irreversible (enough blocks have been mined). For now this approach is ok but this could slow down RGB transfers. We think it would be nice to be able to accept consignments on 0/low-conf transactions and be able to de-accept a consignment in case of a re-org or an RBF.
This is not urgent but a nice to have, IMO it can be done after 0.11 testing.

how to create wallet using rgb cli

rgb create alice

When I was executing the command line above, I encountered an error message： “Error: you must provide an argument specifying wallet descriptor”

version is v0.11.0-alpha.2

Change sent to an unknown address

I've run into quite a strange problem testing transfers using this RGB command line interface. I was following this video where Dr. Orlovsky performs a demo transaction (link).

Upon following the video step for step I encountered an error right at the end when the transfer was broadcast to the blockchain. The RGB20 assets did indeed transfer and go to the correct address however the change did not, instead the change is sent to a random taproot address that the tpub does not have access to. This can be confirmed by running "rgb utxos" on corresponding wallet after the transfer is broadcast. It will be unable to see the change and the private key will have lost control of some amount of the assets.

At first I thought this was because of a mistake on our part however we noticed in the video Dr. Orlovsky had the exact same issue!

To provide a little bit more information and clarity.

In the video Dr. Orlovsky uses this TPUB: tpubDCNiWHaiSkgnQjuhsg9kjwaUzaxQjUcmhagvYzqQ3TYJTgFGJstVaqnu4yhtFktBhCVFmBNLQ5sN53qKzZbMksm3XEyGJsEhQPfVZdWmTE2

Which he creates an RGB wallet for with the descriptor tapret(tpubDCNiWHaiSkgnQjuhsg9kjwaUzaxQjUcmhagvYzqQ3TYJTgFGJstVaqnu4yhtFktBhCVFmBNLQ5sN53qKzZbMksm3XEyGJsEhQPfVZdWmTE2, ...)

He then issues 1000000000000000 of an RGB20 asset called TST to a UTXO associated with this wallet.

He then performs a transfer action where he transfers 100 TST to a new UTXO. He signs the transfer PSBT and then broadcasts it.

This is the transaction he broadcast in the video: https://www.blockstream.info/testnet/tx/85f9b8ce3b495a206de334928c89ce8fc93f02304b634641ac76e4008948e2a3

The transaction has 1 input (The UTXO which sealed the TST) and 1 output, which is the change from the transaction. The change also is the UTXO where the remaining TST is bound. The address the change is sent to is: tb1pmv024fd3f62peg5rg5ex8m3zl4n9qkze5xsrw58fknh5987hkmusflwcpu

The tpub from earlier is unable to detect the change utxo (85f9b8ce3b495a206de334928c89ce8fc93f02304b634641ac76e4008948e2a3:0) when calling "rgb utxos" OR when calling "btc-cold check " furthermore the change utxo is unspent (meaning the problem is not that it has been spent).

The result in the video and when we performed tests is that when you do a RGB transfer call the correct amount of assets get transferred to the person you want to send them to but the change gets sent to a random address meaning the original owner loses their RGB20 assets (or loses the ability to spend them). From what I can tell this looks like when the RGB CLI is manipulating the PSBT (through the transfer call) it is deriving the change address incorrectly from the tpub.

You can test this yourself by adding the TPUB Dr. Orlovsky used to the wallets on the RGB CLI.

rgb create VideoWallet tpubDCNiWHaiSkgnQjuhsg9kjwaUzaxQjUcmhagvYzqQ3TYJTgFGJstVaqnu4yhtFktBhCVFmBNLQ5sN53qKzZbMksm3XEyGJsEhQPfVZdWmTE2

and then by checking the utxos

rgb utxos -w VideoWallet

You will notice that there are no UTXOs from the transaction from the video and the wallet no longer owns the vast majority of TST tokens. The utxo is also unspent which we can see by checking the address associated with it which only has 1 transaction which is the transaction sending change to it.

I'm assuming the error is caused by the client deriving the wrong change address when modifying the output of the PSBT file.

We can consistently reproduce this error and are happy to jump on a call to help identify and fix it. Any and all help would be appreciated.

Failed to construct psbt when do tansfer

rgb -d .alice -w default transfer rgb:28hM47M-EZ7N4qCDB-gF2Mh73Vx-nJHhgLM7m-2671i3NJY-bLU8TzT/RGB20/1000+tb1pgdl5cks7zu7wymr5vwwcc5rstvkxuj03c8qctvarx5g6qgfsgjms04f86n 100 consignment.rgb

Error: field name beneficiary is unknown to the contract interface

missing rgb20 rgb21 rgb 25 simple working examples

Right after compiling the last rgb version on osx, There's no simple examples rgb20 or 21 or 25 ready to go.

I would love to see 3 yml files, interfaces and schemata with some typical content , especially some encoded picture for the RGB21, as we don't have a file size problem and we don't really need to put a digital art on ipfs or arweare .

We would use the rgb issue "interface" RGBXX sample.yml and it would just work .

I even could not make it work with the separate rgb-schemata repo

docs: update readme.md to keep `rgb` cli up-to-date

Finally, install RGB command-line utility shipped with this repo by running

cargo install --path cli --all-features

To use the library from other rust code add dependency to the Cargo.toml file:

[dependencies]
rgb-runtime = "0.11.0-alpha.2" // or latest version

bug：Import contract (id) error in win environment

win

PS D:\rgb20-usdt>  rgb -d .alice create default tpubDCRYBMFMJcwYAd7g7GEdNzTnqg7k8wE2PQZ6NgXq2tJER3aWSK4sRNpje4nnvxC9Ffs2borWAgdQMDi8J8b4sXBQNqMnFxVWWVA6BswzWAgdQMDi8J8b4sXBQNqMnFxVWWVA6BswzGyU
Stock file not found, creating default stock
Wallet file not found, creating new wallet list
Created new wallet 'default' with descriptor 'tapret(tpubDCRYBMFMJcwYAd7g7GEdNzTnqg7k8wE2PQZ6NgXq2tJER3aWSK4sRNpje4nnvxC9Ffs2borWAgdQMDi8J8b4sXBQNqMnFxVWWVA6BswzGyUdQMDi8J8b4sXBQNqMnFxVWWVA6BswzGyU, ...)'
PS D:\rgb20-usdt>  rgb -d .bob create default tpubDCeaDjmVbxPkLxvXgmdsTjGF55WWL4Kf1Z64eQstJAyqQ7DaBD9DDGo7Q26yxww5ifbFuELZcmxnM8LkJ1Xmij6itneguA5VKcqc5YbMbjmxnM8LkJ1Xmij6itneguA5VKcqc5YbMbjz
Stock file not found, creating default stock
Wallet file not found, creating new wallet list
Created new wallet 'default' with descriptor 'tapret(tpubDCeaDjmVbxPkLxvXgmdsTjGF55WWL4Kf1Z64eQstJAyqQ7DaBD9DDGo7Q26yxww5ifbFuELZcmxnM8LkJ1Xmij6itneguA5VKcqc5YbMbjzxnM8LkJ1Xmij6itneguA5VKcqc5YbMbjz, ...)'
PS D:\rgb20-usdt> rgb -d .alice import contracts/rgb20-usdt.contract.rgb
Contract rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp imported to the stash
PS D:\rgb20-usdt> rgb -d .bob import contracts/rgb20-usdt.contract.rgb
Contract rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp imported to the stash
PS D:\rgb20-usdt>  rgb -d .alice contracts
rgb:JMDUCWz-q1uGbmJEt-C4Hg2tqXa-BEzuCB8TG-2Vq5cfCas-RaF13k
PS D:\rgb20-usdt> rgb -d .bob contracts
rgb:2cG7m1E-U1BCYbYAU-rNJGg82h9-agzXPX8xf-HP4fNPiZJ-SDyXzX6
PS D:\rgb20-usdt>

linux :

root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt# rgb -d .alice contracts
rgb:JMDUCWz-q1uGbmJEt-C4Hg2tqXa-BEzuCB8TG-2Vq5cfCas-RaF13k
root@LAPTOP-NRHB1K5B:/mnt/d/bitmask/rgb20-usdt# rgb -d .bob contracts
rgb:2cG7m1E-U1BCYbYAU-rNJGg82h9-agzXPX8xf-HP4fNPiZJ-SDyXzX6
root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt# rgb -d .alice import contracts/rgb20-usdt.contract.rgb
Contract rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp imported to the stash
root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt#  rgb -d .bob import contracts/rgb20-usdt.contract.rgb
Contract rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp imported to the stash
root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt# rgb -d .alice contracts
rgb:JMDUCWz-q1uGbmJEt-C4Hg2tqXa-BEzuCB8TG-2Vq5cfCas-RaF13k
rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp
root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt# rgb -d .bob contracts
rgb:s6syetq-eN85tdbpb-hBut9K6F3-uFfjVZsJ6-WVYGv6FXa-UTwCnp 
rgb:2cG7m1E-U1BCYbYAU-rNJGg82h9-agzXPX8xf-HP4fNPiZJ-SDyXzX6
root@LAPTOP-NRHB1K5B:/mnt/d/rgb20-usdt# 

After importing the contract in the Win environment, using the specified wallet to view it, it was found that the contract ID is incorrect, and the same contract can be imported repeatedly