get asset balance question

[cymqqqq]

my call interface here: 1.listassets, get an asset id 2.rgbinvoice, get a rgbinvoice string 3.decode rgbinvoice, get related information 4.send asset question: I sent 10 assets, but when I checked the asset balance(getassetbalance interface), it's still the original amount(balance not changed), I don't know why. Such as, I sent 10, and then I checked the asset balance: "data": { "settled": 100, "future": 100, "spendable": 100, "offchain_outbound": 0, "offchain_inbound": 0 } nothing changed.

[nicbus]

Hi, it's hard to come up with an explanation with the given data, can you please add more details? A minimal way to reproduce the issue including full commands would be best.

I suppose you're using 2 nodes, one issuing and sending the asset and the other receiving it. So for a minimal way to reproduce the issue I'd expect a list of commands and related output for both nodes.

[cymqqqq]

OK full commands. for rgb-lightning-node openapi: 1./listassets 2./rgbinvoice 3./decodergbinvoice 4./sendasset 5./assetbalance I just run one regtest node here

[nicbus]

Running a single node is not a well-tested path, as for LN it typically makes sense to have at least a peer to connect to. Please try to reproduce the issue using two nodes, with the first acting as issuer and sender, and the second acting as receiver.

That said, what I meant by "A minimal way to reproduce the issue including full commands" is the complete series of commands that leads to the issue, starting from an empty node.

Command parameters are important in order to understand what's going on, so please include those. The received output can give insight as well, so include that, too.

As an example, a full command looks like:

curl -X POST -H "Content-type: application/json" \
    -d '{"password": "password"}' \
    http://localhost:3001/init

which can give an output like:

{"mnemonic":"ready tuition nephew price struggle close satisfy legal repair pole old coconut"}

When reporting, please provide the full list of commands (with parameters) and related output, starting from the very beginning (/init, /unlock, /issueasset, ...) and up to the issue manifestation.

[cymqqqq]

1. start a daemon: nohup rgb-lightning-node user:password@localhost:18443 dataldk0/ --daemon-listening-port 3001 --ldk-peer-listening-port 9735 --network regtest & [1] 162070
2. init the node: curl -X POST -H "Content-type: application/json" \

   -d '{

   "password": "nodepassword" }' \ http://localhost:3001/init return {"mnemonic":"address attitude solar portion milk mountain toilet wheat rug damage chapter below"}

3. unlock the node curl -X POST -H "Content-type: application/json" \ -d '{ "password": "nodepassword" }' \ http://localhost:3001/unlock 4.generate an address: curl -X POST -H "Content-type: application/json" \ \ http://localhost:3001/address return {"address":"bcrt1q6ksgkzh6wzexq57rl5hn3d4fs7tj3nk6r0h5e4"} 5.send btc to this address ./regtest.sh sendtoaddress bcrt1qh2w7easr86d7ckn3mwuvrk7jg4t5597r6ks46g 1 return error code: -6 error message: Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool

[nicbus]

It looks like you're trying to spend unconfirmed transactions in bitcoind. Please try mining some blocks and then try again.

In case the issue persists, try starting from scratch, including your regtest setup, as that error should not happen on a fresh regtest environment.

[cymqqqq]

Ok, back to the last question, from step 4, and the full commands again: 1.

1. start a daemon: nohup rgb-lightning-node user:password@localhost:18443 dataldk0/ --daemon-listening-port 3001 --ldk-peer-listening-port 9735 --network regtest & [1] 162070
2. init the node: curl -X POST -H "Content-type: application/json" \

-d '{

"password": "nodepassword" }' http://localhost:3001/init return {"mnemonic":"address attitude solar portion milk mountain toilet wheat rug damage chapter below"}

3. unlock the node curl -X POST -H "Content-type: application/json" -d '{ "password": "nodepassword" }' http://localhost:3001/unlock 4.generate an address: curl -X POST -H "Content-type: application/json"

   http://localhost:3001/address return {"address":"bcrt1q6ksgkzh6wzexq57rl5hn3d4fs7tj3nk6r0h5e4"} 5.send btc to this address ./regtest.sh sendtoaddress bcrt1qh2w7easr86d7ckn3mwuvrk7jg4t5597r6ks46g 1 return error code: -6 error message: Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool 4.mine a block: ./regtest.sh mine 104 success 5.send btc to this address ./regtest.sh sendtoaddress bcrt1qh2w7easr86d7ckn3mwuvrk7jg4t5597r6ks46g 1 success, and return a txid 6.create utxo: curl -X POST -H "Content-type: application/json" \ -d '{ "up_to": true, "num": 4 }' \ http://localhost:3001/createutxos success 7.issue asset: curl -X POST -H "Content-type: application/json" \ -d '{"ticker": "USDT", "name": "USDT", "amounts": [100], "precision": 10}' \ http://localhost:3001/issueasset success, and return {"asset_id":"rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y"} 8.generate rgb invoince: curl -X POST -H "Content-type: application/json" \ -d '{ "min_confirmations": 0, "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" }' \ http://localhost:3001/rgbinvoice success, return {"recipient_id":"utxob:2C82TSE-SAfYTsTXS-wMtbUaoMk-5HNURpqeV-QTPgeupfs-5muP4RB","invoice":"rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y/RGB20/utxob:2C82TSE-SAfYTsTXS-wMtbUaoMk-5HNURpqeV-QTPgeupfs-5muP4RB?expiry=1703032434&endpoints=rpc://127.0.0.1:3000/json-rpc","expiration_timestamp":1703032434} 9.decode rgb invoice: curl -X POST -H "Content-type: application/json" \ -d '{ "invoice": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y/RGB20/utxob:2C82TSE-SAfYTsTXS-wMtbUaoMk-5HNURpqeV-QTPgeupfs-5muP4RB?expiry=1703032434&endpoints=rpc://127.0.0.1:3000/json-rpc" }' \ http://localhost:3001/decodergbinvoice success, return {"recipient_id":"utxob:2C82TSE-SAfYTsTXS-wMtbUaoMk-5HNURpqeV-QTPgeupfs-5muP4RB","asset_iface":"RGB20","asset_id":"rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y","amount":null,"network":null,"expiration_timestamp":1703032434,"transport_endpoints":["rpc://127.0.0.1:3000/json-rpc"]} 10.send assets: curl -X POST -H "Content-type: application/json" \ -d '{ "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y", "min_confirmations": 0, "amount": 10, "blinded_utxo": "utxob:2C82TSE-SAfYTsTXS-wMtbUaoMk-5HNURpqeV-QTPgeupfs-5muP4RB", "donation": true, "transport_endpoints": ["rpc://127.0.0.1:3000/json-rpc"] }' \ http://localhost:3001/sendasset success, return txid, {"txid":"d2c9a9e4fcc6442295441ed2cd5331bc4779ba6a06923af2026ed2e3dd346332"} 11.refresh transfer: curl -X POST -H "Content-type: application/json" \ http://localhost:3001/refreshtransfers success 12.get asset balance: curl -X POST -H "Content-type: application/json" \ -d '{ "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" }' \ http://localhost:3001/assetbalance success, return {"settled":90,"future":100,"spendable":90,"offchain_outbound":0,"offchain_inbound":0} So, all the steps here, do I miss any steps? And if I want to display the asset balance to the frontend page, which part should choose? settled or spendable?

[cymqqqq]

It's very strange, I tried to send it again: 1.create utxo 2.generate rgb invoice 3.decode rgb invoice 4.send rgb invoice 5.get asset balance, in this step, weird things come out, from the last get asset balance step, it was {"settled":90,"future":100,"spendable":90,"offchain_outbound":0,"offchain_inbound":0} but this time, it back to {"settled":100,"future":100,"spendable":100,"offchain_outbound":0,"offchain_inbound":0}

[cymqqqq]

I found another weird thing is: I tried from the frontend page to execute the full command by the openapi and from the command line execute full command by the server.

1. frontend page operation can not change the asset balance {"settled":100,"future":100,"spendable":100,"offchain_outbound":0,"offchain_inbound":0} curl -X POST -H "Content-type: application/json" -d '{
   "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" }' http://localhost:3001/assetbalance
2. the command line operation can change the asset balance. {"settled":79,"future":100,"spendable":79,"offchain_outbound":0,"offchain_inbound":0} curl -X POST -H "Content-type: application/json" -d '{ "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" }' http://localhost:3001/assetbalance I don't know why. Both are the same asset id

[cymqqqq]

this time, I tried the swagger api: 1.create utxo { "up_to": true, "num": 4 } 2.rgb invoice { "min_confirmations": 0, "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" } return "data": { "recipient_id": "utxob:C81YGPP-BNtuhiTBj-FzsN3zvWF-bAtpk8Ju1-2DUzc8w1m-J24RjH", "invoice": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y/RGB20/utxob:C81YGPP-BNtuhiTBj-FzsN3zvWF-bAtpk8Ju1-2DUzc8w1m-J24RjH?expiry=1703035226&endpoints=rpc://127.0.0.1:3000/json-rpc", "expiration_timestamp": 1703035226 } 3.decode rgb invoice 4.send rgb asset { "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y", "amount": 3, "blinded_utxo": "utxob:LBGEZEx-r5JNdyKqY-TJwGPNPVN-xWRs9XbJS-KabL58cDT-sznboL", "donation": true, "min_confirmations": 0, "transport_endpoints": [ "rpc://127.0.0.1:3000/json-rpc" ] } return "data": { "txid": "5b0cd468772a8501bfe52518b019b1ddbd139499d3c66b1f3a7a066e7b0d23d6" } 5.get asset balance { "asset_id": "rgb:uZugPmo-C6yraPsje-6JyYQNqLc-8rQF4fYPH-dGRC8ec1w-9T888Y" } return "data": { "settled": 97, "future": 100, "spendable": 97, "offchain_outbound": 0, "offchain_inbound": 0 } Sorry, I'm totally confused now. :(

[nicbus]

5.send btc to this address ./regtest.sh sendtoaddress bcrt1qh2w7easr86d7ckn3mwuvrk7jg4t5597r6ks46g 1 return error code: -6 error message: Unconfirmed UTXOs are available, but spending them creates a chain of transactions that will be rejected by the mempool 4.mine a block: ./regtest.sh mine 104 success 5.send btc to this address ./regtest.sh sendtoaddress bcrt1qh2w7easr86d7ckn3mwuvrk7jg4t5597r6ks46g 1 success, and return a txid

Assuming you (re)started the regtest services before executing the reported commands, this is unexpected, as the regtest.sh script already mines 103 blocks to make funds available for sending. The reason for the issue might be that regtest services had been started for a previous test and funds had already been depleted without ever mining a new block.

Can you please confirm that the issue goes away if you restart the services (regtest.sh stop + regtest.sh start) before executing the reported commands?

4.mine a block: ./regtest.sh mine 104

Please not that this command mines 104 blocks, not just one.

So, all the steps here, do I miss any steps?

The steps are ok, but you are still using a single node, which is not the way to go, as already clarified.

To move further you'll need to update your setup to use two nodes. One will issue and send the asset, the other one will receive the asset.

And if I want to display the asset balance to the frontend page, which part should choose? settled or spendable?

All three versions are correct, they each give a different view on the on-chain balance.

See rgb-lib's Balance for details.

It's very strange, I tried to send it again: < [...]>

I found another weird thing is: I tried from the frontend page to execute the full command by the openapi and from the command line execute full command by the server. [...]

The confusion is probably due to the added complexity of how RGB transfer refreshing works and the fact that you're using a single node to test this, which makes matters harder to understand.

On-chain transfers start in the WaitingCounterparty status. Assuming everything goes as intended, after a first refresh they move to the WaitingConfirmations status and, after the transaction gets to the required number of confirmations plus a second refresh, they move to the Settled status.

Sender and recipient transfers are separate and go through the status changes independently. Using a single node can mix some of these updates, making it harder to understand what's going on.

Update your setup to use two nodes and try issuing and transferring an asset from the first to the second node. Check the status of the transfer and the balance of the asset on both sides. Then, refresh once on each node, checking transfer status and asset balance on both sides. Finally, mine a block and refresh one last time on each node, checking transfer status and asset balance on both sides. This should let you see all the transfer statuses one after another and also see how the asset balances change, including differences between settled and future variants.