lightninglabs / lightning-api-ng Goto Github PK

The description for TXID in Label Transaction should include a note that, in the case of GRPC, the TXID needs to be passed in reverse byte order. More info here in the section Searching for TXIDs in the blockchain

The tooltip in the "REST placement" column with the text "Use base64 & URL encoding in the query. See REST Encoding." has the wrong link.

Incorrect: https://lightning.engineering/api-docs/docs/api/taproot-assets/#rest-encoding

Correct: https://lightning.engineering/api-docs/api/taproot-assets/#rest-encoding

The following API references are not building against the master branches according to README. They are all referencing commits that are were pushed ~1 month ago.

LND, Loop, Taproot Assets Protocol, Lightning Terminal (LiT)

When calling /v1/payments via REST API the Attributes creation_date_start and creation_date_end are ignored and they are not working. It always returns all invoices.

Currently, the docs generation pipeline has the merger tool written in golang which ingests the protos and outputs JSON files which are consumed by the Typescript generate-docs tool which outputs the markdown files for Docusaurus.

It would make the pipeline simpler if we ported the generate-docs TS code to golang into the merger code. This would remove the intermediate step of outputting JSON and simplify the maintenance of the build pipeline going forward.

Hello,

I'm not sure if this is really an issue with taproot-assets, or if I have misunderstood something.

I am trying to understand how to issue an asset in multiple batches, so that the total circulating supply is increased every time that I call the MintAsset API endpoint.

So far I have only managed to perform multiple mints so that I end up with multiple asset_ids, all grouped by the same group_key. I have not found a way to issue assets over multiple batches, while preserving the same asset_id over all mints. Is there any way to do this? If there is, please let me know, in which case the remainder of my question is irrelevant.

My understanding is that we can use the group_key to get the circulating supply and hot wallet balance for a group, and we can conceptually think of the group of assets to be "the asset". But if there is no way to perform multiple mints of the same asset while preserving the same asset_id, then I think this creates some problems with fungibility:

1. When sending an asset, I have to decide which asset_id/batch to send from. If I have minted 1000 units of an asset, and then an additional 1000 units of the same asset in the same group but in a different batch, I can't just send 1100 units in one go.

2. When generating an asset address to receive these, this is done by passing an asset_id to NewAddr. Suppose I have minted an asset over two batches. I now wish to transfer some of this asset. I generate an asset address using the first asset_id. Can I now transfer any assets minted by the second batch to that address? If not, then the assets minted between the two batches are not really fungible.

Does this problem really exist? Or have I misunderstood something regarding assets, asset groups, and minting? I would very much appreciate it if someone could explain this to me.

P.S. By the way, I have to say I'm really impressed overall with the Taproot Assets Protocol and with all of the Lightning Labs projects. Thank you all for your effort, it really adds a lot value to the Bitcoin ecosystem.

Hello,

Is some type of pagination going to be added to the AddrReceives REST API endpoint?

Maybe a minimum block height parameter, or something similar?

I am aware that is is possible to query for a specific address.

But it would be nice if we could also query for recent receives in a way that doesn't return all the receives that ever happened, in one big response.

We use multiple REST mappings in some situations to make developer usability a bit better by circumventing some of the disadvantages of the grpc-gateway library.
Examples:

• tapd universe RPC: https://github.com/lightninglabs/taproot-assets/blob/main/taprpc/universerpc/universe.yaml#L10
• lnd lightning RPC: https://github.com/lightningnetwork/lnd/blob/c26917ee1fcf7975a0d58a2ebb02f438217dd3f6/lnrpc/lightning.yaml#L112

These don't currently show up in the API docs.

Lightning Terminal (litd) has some RPC endpoints that are currently not surfaced in the API docs for sessions and accounts. It would be great to add those.

litd Pre-requisites:

• Add descriptive comments (including CLI commands) to the litd proto files so that info gets bubbled up into the docs
• Implement the REST API proxy to be consistent with the other daemons

I want backup channel and restore channel. But I found that the recovery failed, so I guessed that it was because of different macaroons, so I found that macaroon_root_key can be set in the initwallet method. Then, I searched all the methods in the api, but I didn't find a way to get macaroon_root_key, so I want to know how to get macaroon_root_key.

While reviewing lightningnetwork/lnd#8181 I realized that we have several cases where the characters are not resolved right, one example:

When trying to use a Macaroon generated by the BakeMacaroon API, failure can occur if using a root_key_id < 18441921392371827000 ([4]byte starting with {0xFF, 0xEE, 0xDD, 0xCC}).

When using a macaroon with permissions for Loop, Pool, Faraday, and Litd that was baked with a root_key_id matching the above condition, AND calling an rpc from these services, an error is returned: "proxy error with context {rpc service}: invalid macaroon: macaroon service not yet initialised". LND rpc services can still be used with this macaroon.

Currently, the LND docs are generated separately and deployed to https://api.lightning.community, while the docs for Loop, Pool, Faraday, and Taro are deployed to https://lightning.engineering/api-docs.

We want to merge LND into the docs site with the others and have https://api.lightning.community redirect to the LND page on https://lightning.engineering/api-docs.

LsatToken is missing the id field that is currently in looprpc/client.proto.

/*
The l402 ID of the token.
*/
string id = 9;

Now that the generator is written completely in Go, we can use the perms.Manager from Lightning Terminal to determine the required macaroon permissions for each call.