search

CNTRPRTY / xcpdev-genesis

Open Counterparty Bitcoin Data Explorer - DIY Node
https://xcp.dev
The Unlicense
4 stars 4 forks source link

Source vs issuer for issuance #1

Closed Jpja closed 1 year ago

Jpja commented 1 year ago

The issuances table has two addresses which are usually the same.

However, when ownership is transferred the source is the previous owner and the issuer is the new owner.

image

Xcp.dev shows issuances for an address only when it is the issuer. I suggest showing also when the address is source.

jotapea commented 1 year ago

@Jpja thanks for posting this (first) issue!

This response will also explain why there is no public api (at least for now).

The current version of xcp.dev can be considered an "opinionated" data explorer. My approach to adding features is mainly based on what I want to present in the website, and then I build the api endpoint(s) that will provide the feature/functionality.

But by being open source, anyone can build their own alternative implementation.

Here is the query that returns the issuance data you see in xcp.dev/address/<address>:

SELECT i.*, b.block_time
FROM issuances i
JOIN blocks b ON i.block_index = b.block_index
WHERE i.asset IN (
    SELECT asset
    FROM issuances
    WHERE issuer = $issuer
    AND status = 'valid'
)
AND i.status = 'valid'
ORDER BY i.tx_index ASC;

This provides all the data I need to show the assets that at any moment the address of interest has been an issuer. And in my design, I want to show each asset only once, because then, the user is still able to find all issuance data related to an asset in its xcp.dev/asset/<asset> page.

In this asset page (EDIT: In the api response from the asset page) both the source and issuer data for each issuance is presented.

But having said all this, what feature/functionality would you like to see that is not currently offered, or you would like to be done different or simpler/more direct (like not having to open multiple pages)?

speaktech commented 1 year ago

Looking at the page https://www.xcp.dev/asset/PEONTRUST, I do not see the two variables clearly lableled. Source (original owner) and issuer (current-owner) should be clearly market. In this case they should be two different values. One can determine the values manually by reading through the ownership transfers.

However, I would like to add context to the OP. It is important information to clarify and not conflate these values. Currently, the only (semi) public counterparty API offered displays the new owner address for both 'issuer' and 'owner'. https://xchain.io/api/asset/peontrust

All in all it would be nice to have the most relevant information available for each asset. for example, this page draws from 4 different API sources in order to get all the relevant information in once place. https://thewojakway.com/card/peontrust

Information for each asset could include the following:

If you were to consider offering an public API, I would like to give it more consideration and add to the discussion then.

thanks!

jotapea commented 1 year ago

Looking at the page https://www.xcp.dev/asset/PEONTRUST, I do not see the two variables clearly lableled.

Fair, I should have said "asset api response" instead of "asset page".

Here is the api response relating to the issuances for PEONTRUST:

{
   "ip":"x.x.x.x",
   "message":"",
   "data": {
      "asset_row": {"asset_id":"3169021483439","asset_name":"PEONTRUST","block_index":727248,"asset_longname":null},
      "tables": {
         "issuances": [
            {"tx_index":1944400,"tx_hash":"1a16f978ed7e91ff3a856187e934cf3280869305d30eaff600e1b3e86c05b967","msg_index":0,"block_index":727248,"asset":"PEONTRUST","quantity":1971,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","transfer":0,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":50000000,"locked":0,"status":"valid","asset_longname":null,"reset":0,"block_time":1647230649},
            {"tx_index":1966982,"tx_hash":"2e388efe2a7b923d04beb16f39236b0ca99b58b51151fedb9a3f278f251b023a","msg_index":0,"block_index":729157,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","transfer":0,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1648327752},
            {"tx_index":2150723,"tx_hash":"b799ed81fdb285d3ed99f79b4732538fe9fb1a7e4cb38966f8c42ccec797204f","msg_index":137,"block_index":759528,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"13TxabRnJncRY8rC6o5jzXyEYThbjpvghH","transfer":1,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1666275319},
            {"tx_index":2210607,"tx_hash":"f4c3eda85f65fd35b9febb92be7021473123c5409ee6ab07f0552751c92c0976","msg_index":222,"block_index":770068,"asset":"PEONTRUST","quantity":0,"divisible":0,"source":"1parodyTHe9y2VHk8kZNMZBNTkPTwKj3r","issuer":"1N1JG4AoxfnR7K6AdyE3qAnoEd4PqdCtm3","transfer":1,"callable":0,"call_date":0,"call_price":0,"description":"thewojakway.com/j/PEONTRUST.json","fee_paid":0,"locked":1,"status":"valid","asset_longname":null,"reset":0,"block_time":1672684057}
         ],
         "destructions":[]
      }
   }
}

The issuances array comes directly from the following query done to the protocol's SQLite database:

SELECT i.*, b.block_time
FROM issuances i
JOIN blocks b ON i.block_index = b.block_index
WHERE i.asset = $asset_name
ORDER BY i.tx_index ASC;

So, the api response includes ALL the issuance data available for an asset (even the invalid entries).

The page does hide some properties, but it is a design choice to avoid repetition while still providing the same fundamental information. Also, the protocol's database does not have an "owner" property, so I don't think I will adopt it.

But @speaktech, you might have discovered a (quite bad) bug. My understanding was that source meant the transaction originator, not the original (as in the genesis issuance) issuer. Which is consistent with the use of the same field name for other types of transactions in the protocol.

Were you able to transfer the issuance of PEONTRUST a second time from the original/genesis issuer address?

PS: Thanks for your suggestions of what to include in the asset page / api. Some of these suggestions are already provided, but will still take your input in consideration for future features / adjustments.

jotapea commented 1 year ago

Were you able to transfer the issuance of PEONTRUST a second time from the original/genesis issuer address?

Looking at the input address (source) for tx_hash: f4c3eda85f65fd35b9febb92be7021473123c5409ee6ab07f0552751c92c0976 you can see it came from the transferred issuer 13TxabRnJncRY8rC6o5jzXyEYThbjpvghH.

The Bitcoin transaction is correct, so the bug is not as bad as it seems (in this instance, maybe it can still be exploited?). Is just the message that is stored wrong in the SQLite DB, making my "hide unnecessary data" approach even more appropriate in this case lol.

@Jpja @speaktech anything else you want to discuss or add? If not I'll close this issue.

jotapea commented 1 year ago

@Jpja @speaktech as explained above, the original issue of hiding the source is a design choice to avoid repeating data. Because all issuances are always shown, the previous issuer in a transfer (the source) is the one above... BUT there was a case when this design missed data: when the genesis issuance is also a transfer.

The latest release (v0.9) fixes this by adding a "... from: \

..." to the issuer / source result when the genesis issuance is also a transfer.

https://www.xcp.dev/asset/A12103990090051188182

Closing this issue as completed.