Recursive Endpoint for Self-Referencing and Referencing other Inscriptions, reducing costs, enhanced accessibility and efficiency

[ORDHeavens]

Proposal to introduce a new recursive endpoint. This feature would enable inscriptions to reference information about themselves without prior knowledge of the inscription IDm and information about other inscriptions. Thus, significantly reducing costs, optimizing block space usage and reduce transactions load further lowering price globally.

Old command

/̶r̶/̶s̶a̶t̶/̶c̶u̶r̶r̶e̶n̶t̶:̶ ̶O̶u̶t̶p̶u̶t̶s̶ ̶t̶h̶e̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶i̶n̶s̶c̶r̶i̶p̶t̶i̶o̶n̶'̶s̶ ̶s̶a̶t̶ ̶n̶u̶m̶b̶e̶r̶.̶
̶/̶r̶/̶s̶a̶t̶/̶i̶d̶/̶c̶u̶r̶r̶e̶n̶t̶:̶ ̶O̶u̶t̶p̶u̶t̶s̶ ̶t̶h̶e̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶i̶n̶s̶c̶r̶i̶p̶t̶i̶o̶n̶'̶s̶ ̶f̶u̶l̶l̶ ̶I̶D̶.̶

Improved command proposed by @RabbiGains-eth
/r/self returning:

{ 
   inscription_id: 371b1fe39a2f0463008ee1f9ab75e0af7b3d80beeb2be6eb5cfed9d848e48b54i0,
   parent_id: 3518fb0f9112542df40f31d4c7dd6e9366acd8401ce3b4cc9b6f5c00d6d21fb3i0,
   sat_number: 45026248133,
   utxo: cb7ca4e9a8c827bbbe4dcc73700b2fda39242c234f2020147d756cc3fe2787f8:2,
   genesis_blockheight: 818927
}

Benefits
Cost Reduction: Up to circa 75% cost savings for inscriptions requiring their sat number or self-reference.
Block Space Efficiency: Potential reduction in transaction and block space usage by up to 33% on such type of inscriptions.
Enhanced Flexibility: Opens up new possibilities for creative and broader applications of inscriptions, decentralized/user mints (always more and more used).

Implementing a recursive endpoint for self-referencing in Bitcoin inscriptions offers significant efficiency improvements and cost reductions, fostering innovation in the use of digital artifacts on the blockchain. I encourage an open discussion with the community and developers to review and if considered valuable, integrate this proposal into ord.

ORDHeavens and RabbiGains - We are all innovating together!

[RabbiGains-eth]

Proposing /r/self returns:

{ 
   inscription_id: 371b1fe39a2f0463008ee1f9ab75e0af7b3d80beeb2be6eb5cfed9d848e48b54i0,
   parent_id: 3518fb0f9112542df40f31d4c7dd6e9366acd8401ce3b4cc9b6f5c00d6d21fb3i0,
   sat_number: 45026248133,
   utxo: cb7ca4e9a8c827bbbe4dcc73700b2fda39242c234f2020147d756cc3fe2787f8:2,
   genesis_blockheight: 818927
}

[ORDHeavens]

That is much more compact and elegant and you can fetch out all info with a simple command! And with the new tech/protocols we have on ordinals, such a command is becoming very useful compared to months ago when that was not really necessary.

I have also improved the main proposal with your command.
Thank you!

[jerryfane]

+1 on this

[ep150de]

+1 and would be nice to return the current owner wallet address

ex:
{
inscription_id: 371b1fe39a2f0463008ee1f9ab75e0af7b3d80beeb2be6eb5cfed9d848e48b54i0,
parent_id: 3518fb0f9112542df40f31d4c7dd6e9366acd8401ce3b4cc9b6f5c00d6d21fb3i0,
sat_number: 45026248133,
utxo: cb7ca4e9a8c827bbbe4dcc73700b2fda39242c234f2020147d756cc3fe2787f8:2,
genesis_blockheight: 818927
owner_address: bc1pju5qh9kqzz7szwyxnys6r22yy08er37dxqf7p54ymygz094yy9vs0890vk
}

[ORDHeavens]

Yeah that can avoid the need of having to add another line to fetch for it afterwards!!! Thanks or your contribution @ep150de much appreciated!!

[raphjaph]

I think a better and more general approach would be to add an endpoint that returns information about an inscription, something like /r/info/<INSCRIPTION_ID>. An inscription can extract their own inscription id from the URL path so that's how you would get self.

All the fields look except for maybe the owner_address since we don't want to encourage address reuse and stuff like that.

[RabbiGains-eth]

All the fields look except for maybe the owner_address since we don't want to encourage address reuse and stuff like that.

Awesome to get your attention on this @raphjaph. The more general endpoint as you described is definitely more powerful.

Yeah that can avoid the need of having to add another line to fetch for it afterwards!!! Thanks or your contribution @ep150de much appreciated!!

Address could be nice, but I do understand the reuse concerns.
What are some of the use-cases you see for the address field that would not work by using the UTXO location?

[ORDHeavens]

@raphjaph thank you for your attention! Would not expect a lesser elegant and improved command from yourself!

If I understood correctly you would get:

/r/info/<INSCRIPTION_ID> to get any inscription info and you would use /r/info/self to get the current inscription info?

Or do you mean to use a command such as :

let inscriptionId = window.location.pathname.split('/')[2]; and then from that doing /r/info/<INSCRIPTION_ID> to fetch the info.

Let me know and will add that to the proposal above!

[ep150de]

I was originally thinking if someone wanted to make art derive from an algo seed from the inscription owner wallet, so as the art is traded, some facets and colors or features are changed and determined by the owner wallet address. Allowing the art to evolve or be dynamic based on wallet address. -ep150de -------- Original message --------From: "RabbiGains.eth" ***@***.***> Date: 1/24/24 7:46 AM (GMT-08:00) To: ordinals/ord ***@***.***> Cc: ep150de ***@***.***>, Mention ***@***.***> Subject: Re: [ordinals/ord] Recursive Endpoint for Self-Referencing Inscriptions on Bitcoin, reducing costs, enhanced accessibility and efficiency of the blockchain (Issue #3015) All the fields look except for maybe the owner_address since we don't want to encourage address reuse and stuff like that. Awesome to get your attention on this @raphjaph. The more general endpoint as you described is definitely more powerful. Yeah that can avoid the need of having to add another line to fetch for it afterwards!!! Thanks or your contribution @ep150de much appreciated!! Address could be nice, but I do understand the reuse concerns. What are some of the use-cases you see for the address field that would not work by using the UTXO location? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ORDHeavens]

That can be done with the UTXO which also changes when the ordinal is transferred 🤗 by referencing it you achieve a very similar outcome, or maybe more interesting cause if you send it to your same address you can still have a different outcome 💪

[raphjaph]

#2628

[ZedZeroth]

Hi everyone. I also came here to request something along these lines. Ordinals.com already shows the UTXO "location" of each inscription so I feel like it should be possible to reference this as an endpoint? e.g. /r/location/<INSCRIPTION_ID> or /r/utxo/<INSCRIPTION_ID>

I also believe that /r/address/<INSCRIPTION_ID> (owner address) would allow for some very interesting behaviour, particularly with regard to collection mechanics. Thank you :)

[ZedZeroth]

What are some of the use-cases you see for the address field that would not work by using the UTXO location?

I can think of MANY really cool ideas if inscriptions could "know" that they were at the same address as each other :)

If this can be implemented it would be amazing IMO :)

My vote if for access to both UTXO and ADDRESS. The other data also look useful although most of it can be found indirectly currently I think? Maybe not parent ID? Thanks

[ZedZeroth]

Apologies if I've misunderstood but this appears to be a nonsensical ChatGPT response?