Referencing a sat in an inscription

[huuep]

Ordinal theory uniquely identifies sats on Bitcoin. If inscriptions can reference sats by their id and access the on-chain inscriptions on those sats, that can open up new possibilities.

One proposal for sat referencing:

"/sat/X" where X is the integer sat number, this returns the first inscription on sat X if it exists
"/sat/X/n" where n is the nth inscription on sat X if it was inscribed (and reinscribed) n times or more
"/sat/X/-1" returns the most recent inscription on sat X

A sat basically becomes a variable that can change, and record state changes for inscriptions (which are immutable) to use. This opens up a lot of powerful use cases for code based inscriptions.

[rudi-cilibrasi]

seems intuitive to me, the same way Ruby allows referencing the last element by -1

[ericatallah]

Makes sense. Might be useful to also know the number of inscriptions:
/sat/length - returns total number of inscriptions.

Could expose a basic array api even.

[jbrace02]

What use cases can you forsee that this would open up?Sent from my iPhoneOn Jun 20, 2023, at 3:42 AM, Danny Yang ***@***.***> wrote: Ordinal theory uniquely identifies sats on Bitcoin. If inscriptions can reference sats by their id and access the on-chain inscriptions on those sats, that can open up new possibilities. One proposal for sat referencing: "/sat/X" where X is the integer sat number, this returns the first inscription on sat X if it exists "/sat/X/n" where n is the nth inscription on sat X if it was inscribed (and reinscribed) n times or more "/sat/X/-1" returns the most recent inscription on sat X A sat basically becomes a variable that can change, and record state changes for inscriptions (which are immutable) to use. This opens up a lot of powerful use cases for code based inscriptions. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[huuep]

/sat/X - sat is a stable reference, and combined with reinscriptions, you can use sats as variables to record state changes on-chain with the Ordinals protocol.

[tansanDOTeth]

This is a relevant request as well: #1385

[lifofifoX]

Assuming this will largely be used programmatically, does it make more sense to make this a single JSON API endpoint instead? The payload would just be a list of inscription IDs in the order in which they were inscribed. That'd make it easier to get the total count as well.

[lifofifoX]

{
  sat: 1233,
  count: 2,
  inscriptions: [
    "ins1",
    "ins2"
  ]
}

[lifofifoX]

This API endpoint could even include other interesting information, such as block number and rarity.

[tansanDOTeth]

What would the endpoint URL look in your mind? I am guessing any HTML inscription would be able to call an endpoint like /sat and then that would return the sat number of the current inscription. Is that correct?

[yohann888]

Will inscription numbers change after reinscriptions? It really shouldn't.

But if it's being considered or not, there should also be a way to return the first or original inscription # of a sat in this sat referencing language.

This number is in of itself something that collectors value.

Proposal:

"/sat/X/prime" where X is the integer sat number, this returns the first inscription # on sat X if it exists

[veryordinally]

Inscription numbers of existing inscriptions won't change with reinscriptions. A reinscription just associates additional inscriptions to an already-inscribed sat.

[yohann888]

Ok, but will the additional inscription have a new inscription number on the first sat/inscription number? There will probably be a new inscription id, but I'm not certain whether it will assign a new inscription #.

[tansanDOTeth]

Would the endpoint be a call to something like /sat or would you need to include an ID? I was thinking the former would create something similar to the reflection concept, so any inscription can call that endpoint to introspect its own internal properties.

[RabbiGains-eth]

I would also like to suggest a way for an inscription to recall its own sat metadata.

/sat could return the inscription's sat number, sat block height, and rarity

{
  number: 123456000000,
  block_height: 98765,
  rarity: uncommon
}

[lifofifoX]

💯

This would be extremely useful.

[Saytoke]

Gents,
From the outside looking in ...

1- Is this recycling referencing the Segwit space also or the base 1 Meg only for the history data/ total addressable space?

2- Either way would it not be cumulative, per transaction, per Sat, reducing the available space each time?

3- re utxo's are they also a finite amount set at inception
or reset by subsequent transactions?
.
Goal is two fold, clear my confusion, help flesh out loose ends.

Thanks for focusing your efforts here!
.

[huuep]

Every inscription is independent, with the same limitations/properties, and costs as much as any other inscription. There is no "overwriting" or "recycling" concept.

[Saytoke]

As per an earlier post stated ...

"Inscription numbers of existing inscriptions won't change with reinscriptions. A reinscription just associates additional inscriptions to an already-inscribed sat".

How can both be simultaneously true?

"An independent sat"
versus an
"already inscribed sat"

Is the reinscribed data contained in the same sat as the previously inscribed data or not?

And more fundamentally Is the data actually even in the sat or not?
I thought it was in the transaction data field which also containes the inscription itself, which is limited to one Meg hence my question is the additional segwit space included?

Is there a graphical representation depicting how the header and data payload fields differ in an inscription / reinscription transaction versus a standard crypto transaction yet? as a picture is worth a thousand words.

I'm trying to visualize how the DLC decode would look in
Tcpdump to help @bobbodily

Re ...
https://twitter.com/BobBodily/status/1681736642648784896?t=AhC6eoGaCmhrx2s-iZMdTw&s=19

Thanks

[stet]

Is the reinscribed data contained in the same sat as the previously inscribed data or not?

There is nothing in a sat.
Inscriptions are natively independent and do not nec require a specific sat except to align with Ordinal Theory.
Inscription Numbers are not Inscription IDs.
All inscriptions use new block space as it is obv impossible to go back in time to add data.
sat serial numbers are reference IDs for inscriptions so they can be moved like sats themselves.

Hope this helps clarify the design and terminologies.

[Saytoke]

Fyi,
https://twitter.com/BRC20_Allday/status/1686648082598174720?t=3ZwrJVMMsowoNKS3CyoVSA&s=19

[BitTogether]

I would like to add if it hasnt been mentioned: referencing a satoshi could also work by referencing the alphabetical sat name, and this would enable you to take a named sat with a human readable name and inscribe it with several reinscriptions to create a software library satoshi named sftwarelib https://ordinals.com/sat/sftwarelib or to create a satoshi inscribed with several cookbooks named mycookbooks https://ordinals.com/sat/mycookbooks.
You would reference the sats by sat name and then inscription number in the same way danny describes for sat #.

[santaclauze]

Sorry if this sounds ignorant, I'm rather new to the ecosystem and plainly working off my small amount of knowledge + logic.

Would there be a way to name inscriptions? Nth inscription holds but how many inscriptions could a sat hold? The more re-inscriptions, the harder it would be to make sense of which is which! (Though I understand that the first and latest might have the most significance!)

[BitTogether]

Each inscription has it's own unique inscription number.