Closed EthanShang8989 closed 3 months ago
I am not sure what do you mean by "validation issues". If you run cargo run --example rgb21
it issues NFT contract without any issues. Right now the token index set to 2
(with no specific reason), so if you transfer that contract you have to specify index 2
. Otherwise you can change it in the contract issue code to 1
and than continue to use 1
.
Is this issue you are talking about or a different one? https://github.com/RGB-WG/rgb-std/issues/146
Yes, it's the same problem. I have now set the amout in the invoice and the token index in the issue contract to 1. But I'm experiencing
@000000: ldg 0x0836,0,s16[1] ; -> s16[1]=01000000010455444154010755444174657374000104746578740105706c61696e0013006269746c6967687420726762323120746573740105696d6167650103706e6700b9bf23a30bedcc4c7e5b7e83412f8962ed33012dbb822a15fb536e5f2fbf9d280000
@000005: put a16[0],0 ; -> a16[0]=0
@000009: extr s16[1],r128[1],a16[0] ; a16[0]=0 s16[1]=01000000010455444154010755444174657374000104746578740105706c61696e0013006269746c6967687420726762323120746573740105696d6167650103706e6700b9bf23a30bedcc4c7e5b7e83412f8962ed33012dbb822a15fb536e5f2fbf9d280000 -> r128[1]=0x74414455070154414455040100000001
@000012: spy a32[0],r128[1] ; a32[0]=~ r128[1]=0x74414455070154414455040100000001 -> a32[0]=1 r128[1]=~ st0=false
@000015: lds 0x0FA0,0,s16[1] ; -> s16[1]="<010000000100000000000000>" **//here**
@000021: extr s16[1],r128[1],a16[0] ; s16[1]="<010000000100000000000000>" a16[0]=0 -> r128[1]=0x100000001
@000024: spy a32[1],r128[1] ; a32[1]=~ r128[1]=0x100000001 -> r128[1]=~ a32[1]=1
@000027: eq.n a32[0],a32[1] ; a32[0]=1 a32[1]=1 -> st0=true
@000030: jif 0x0028 ; -> 40
@000040: put a16[0],4 ; -> a16[0]=4
@000044: extr s16[1],r128[1],a16[0] ; s16[1]="<010000000100000000000000>" a16[0]=4 -> r128[1]=1 st0=false
@000047: spy a64[1],r128[1] ; r128[1]=1 a64[1]=~ -> r128[1]=~ a64[1]=1 st0=true
@000050: put a64[0],1 ; -> a64[0]=1
@000054: eq.n a64[0],a64[1] ; a64[0]=1 a64[1]=1 ->
@000057: put s16[0],"owned<20>fraction<20>is<20>not<20>1"; -> s16[0]="owned<20>fraction<20>is<20>not<20>1"
@000063: ret ; -> execution stopped; st0=true
@000064: ldp 0x0FA0,0,s16[1] ; -> s16[1]="<010000000100000000000000>"
@000070: jmp 0x0005 ; -> 5
@000005: put a16[0],0 ; -> a16[0]=0
@000009: extr s16[1],r128[1],a16[0] ; a16[0]=0 s16[1]="<010000000100000000000000>" -> r128[1]=0x100000001 st0=false
@000012: spy a32[0],r128[1] ; r128[1]=0x100000001 a32[0]=~ -> r128[1]=~ a32[0]=1
@000015: lds 0x0FA0,0,s16[1] ; -> s16[1]="<0100000000000000>" **//here**
@000021: extr s16[1],r128[1],a16[0] ; a16[0]=0 s16[1]="<0100000000000000>" -> r128[1]=1
@000024: spy a32[1],r128[1] ; r128[1]=1 a32[1]=~ -> a32[1]=1 r128[1]=~ st0=true
@000027: eq.n a32[0],a32[1] ; a32[0]=1 a32[1]=1 ->
@000030: jif 0x0028 ; -> 40
@000040: put a16[0],4 ; -> a16[0]=4
@000044: extr s16[1],r128[1],a16[0] ; s16[1]="<0100000000000000>" a16[0]=4 -> r128[1]=0 st0=false
@000047: spy a64[1],r128[1] ; r128[1]=0 a64[1]=~ -> r128[1]=~ a64[1]=0 st0=true
@000050: put a64[0],1 ; -> a64[0]=1
@000054: eq.n a64[0],a64[1] ; a64[0]=1 a64[1]=0 -> st0=false
@000057: put s16[0],"owned<20>fraction<20>is<20>not<20>1"; -> s16[0]="owned<20>fraction<20>is<20>not<20>1"
@000063: ret ; -> execution stopped; st0=false
Validation failures:
- invalid owned state value in operation 5738f68ede172d6f8a279c9f05485258de56f660857961bb457b2eb7c7c8c465, state type #0x0FA0 which does not match semantic type id urn:ubideco:semid:2eQfG13SrdSq4UVbEUCA3V5Sybt72FJBBFYBs6ZU63ZS#igor-baboon-leonid.
- operation 5738f68ede172d6f8a279c9f05485258de56f660857961bb457b2eb7c7c8c465 is invalid: owned fraction is not 1
Here, the lds is also unable to load the "correct" data. If it could load the same data as the former, I believe that a64[1] could be set to 1, and the validation script would pass. According to the error message, I used the UTXO "fdcb58bb1c1a05311423959520735e755307ad1e260e5e83c8b723fcace22da5:1" as the seal during issuance. I confirmed in the state that this is indeed the seal used. When constructing the PSBT, I manually selected this UTXO as one of the inputs. Additionally, I modified the stock.compose function to accept RGB21 invoices, and I achieved this by adding the following method.
main_builder.add_data_default(beneficiary, Amount::from(1_u64))?
.complete_transition(contract_id)?,
batch:
batch: Batch {
main: TransitionInfo {
id: OpId(
Array<32>(1401602e490a7c71dadb5fd72efd9c5c9083ee9caf23c7ee6ed2d0d3f2750d6a),
),
inputs: Confined(
[
Bitcoin(
Outpoint {
txid: Array<32>(fdcb58bb1c1a05311423959520735e755307ad1e260e5e83c8b723fcace22da5),
vout: Vout(
1,
),
},
),
],
),
transition: Transition {
ffv: Ffv(
0,
),
contract_id: ContractId(
Array<32>(bb07d247b19adb7b88256c8f368fd6d3fc593261085f9ab8b575a6f3e3cc2414),
),
transition_type: TransitionType(
10000,
),
metadata: Confined(
[],
),
globals: GlobalState(
Confined(
{},
),
),
inputs: Inputs(
Confined(
{
Input {
prev_out: Opout {
op: OpId(
Array<32>(bb07d247b19adb7b88256c8f368fd6d3fc593261085f9ab8b575a6f3e3cc2414),
),
ty: AssignmentType(
4000,
),
no: 0,
},
reserved: ReservedByte(
0,
),
},
},
),
),
assignments: Assignments(
Confined(
{
AssignmentType(
4000,
): Structured(
Confined(
[
Revealed {
seal: Bitcoin(
BlindSeal {
method: TapretFirst,
txid: WitnessTx,
vout: Vout(
1,
),
blinding: 16960374734987402121,
},
),
state: RevealedData(
"\u{1}\0\0\0\0\0\0\0",
),
},
],
),
),
},
),
),
valencies: Valencies(
Confined(
{},
),
),
},
methods: TapretFirst,
},
blanks: Confined(
[],
),
}
I'm not quite sure what I'm supposed to do about this.
Is it the same problem which was resolved in https://github.com/RGB-WG/rgb-std/issues/146#issuecomment-1945532240 or a different one?
This is fixed
I'm trying to work with the RGB21 workflow in version 0.11. However, I am experiencing validation failures after the acceptance of the contract, and I'm not quite sure about the token index to set during the issuance and the amount to set in the invoice. I have tried different combinations, but none of them seem to work.According to convention, both of these should be set to 1.