Transaction Data, Inputs & Outputs

[Blockamoto]

We are a few endpoints away from having the complete block data available to build a fully functional block explorer like mempool. This would also also open the floodgates for Bitmap and other projects to render the full block data visually.

We are missing endpoints for:

• transaction data
• inputs/outputs

These endpoints will open up potential for a cambrian explosion upon the Ordinals interweb, and for Bitmap to flourish through inscriptions that refer to this data rather than through off-chain renders of block data.

[wtfblix]

It makes absolute sense ✊🟧

[Blockamoto]

🫡

[cvasqxz]

If you make an endpoint to check blocks and transactions you could create the possibility to use ordinals.com as a public blockchain API, and that's a bad idea

[Blockamoto]

Why is this a bad idea?

[cvasqxz]

It's a lot of bandwidth for the website, also the call to fetch transactions from the node is slow so you will add a lot of stress on the backend

Blockchain APIs are made to support that stress, using external databases, load balancers and stuff, and also they limit the amount of free API calls because that kind of service is expensive to mantain

[Blockamoto]

These sound like opportunities rather than problems.

[astralarkitekt]

I agree with @Blockamoto here. These are opportunities.

Couldn't a proper CORS implementation solve some of the issues you're talking about?

Secondly - transaction endpoints are really the only aspect MISSING from Ord being a public blockchain api. Yes the queries are expensive but that's where leveraging caching will play a part.

Another opportunity is to segregate the data properly. Calls to fetch a block's transactions could lighten payloads by only providing transaction id's.

Further, calls to a /r/txn/HASH endpoint could provide details for the transactions in smaller payloads.

API design isn't MY strong suit, but I'm sure this can be done elegantly and efficiently in a way that minimizes and mitigates exponential bandwidth consumption.

As with anything ambitious - this will require planning and forethought but shouldn't be shut down because it's a challenge to implement well.

Just spitballing here, thoughts?

[Blockamoto]

Thanks for your input. I agree, it is the missing link. 🫡

[raphjaph]

What are the exact endpoints you are looking for and what data should they return?

[Blockamoto]

Hi Raph, thanks for your response.

To enable the full scale interweb metaverse upon Bitmap Ordinals, we are simply missing recursive methods to return the entire transaction data, and metaprotocol tags.

To begin, we can return transaction ID's by inputting block hash or block height.

/r/txhash/<QUERY> : return transaction hashes within block. <QUERY> blockheight or block hash.

Next, we want to expose the data of a single transaction by inputting transaction ID. This should return the hex, address, block height, input & outputs hash & info, value, fee, and inscriptions.

/r/tx/<TXID> : return full transaction info by inputting transaction ID.

Now, we want to specifically call upon a specific input/output. This data will also be exposed in the transaction info.

/r/output/<OUTPUTID> : return value, script pubkey, address, transaction hash, spent status, from a specific <OUTPUTID>

Finally, we'd like to return inscriptions from within a Metaprotocol. We can do this completely raw with all inscriptions using the tag, and we can also do this through Parent & Child, allowing the filtering of only Metaprotocol inscriptions from within a specific family tree.

/r/metaprotocol/<METAPROTOCOL> : returns all inscriptions from within a Metaprotocol.

There may be more avenues and potential for what get added. I look forward to seeing you, hopefully at Lisbon,

Best wishes, Bitoshi.

[twosatsmaxi]

/r/txhash/ : return transaction hashes within block. blockheight or block hash.

Instead, there can be just a single endpoint returning metadata for all transactions in a single query to the bitcoind, and ord would extract metadatas like vin/vouts or just a size of the tx, weight, size.

bitcoin-cli has capability to return more transactions data instead of just txids with verbosity set to 2 for getblock api this,

/r/tx/ : return full transaction info by inputting transaction ID.

Having this would put load on ord server if the client is iterating over all the transactions, but that can happen with inscriptions to like running infinite loop at client side to get same inscriptions repeatedly, but if a single endpoint which returns metadata for all txs serves your purpose @Blockamoto then this separate tx endpoint won't be needed.

[Blockamoto]

I see what you are saying.

For the purpose of creating an inscription that acts as a recursive block explorer, which in turn would enable the possibility of a high resolution inscription-based Bitmapper, we would need the recursive endpoints.

Ord already has a block explorer built in, it's just the recursive endpoints that need to reflect this.

[astralarkitekt]

Hi @raphjaph and team!

I've got a project waiting on the creation of these endpoints to launch.

It's been a week since ordinals dev hour where you spoke with bitoshi about them - has a yes/no decision been reached?

Can anyone from the Ordinals team confirm - is this happening?

I don't see anything about this on the project tracker, but I'm hearing on X that, yes, it's happening.

Don't Trust. Verify hehe.

Thanks for your reply!