Cursed Inscriptions [1/n]

[raphjaph]

Recognizes multiple inscriptions per transaction:

1. in different inputs
2. in the same input

All but the first inscription in the first input are cursed (for now). In addition all but the first inscription in an input are made unbound (they will be bound in the future as reinscriptions).

[BatBushRacks]

@raphjaph @veryordinally first off thank you for being open source devs... irregardless of no open discussion... any update on #2109... why is it being straight up disregarded?

[veryordinally]

@raphjaph @veryordinally first off thank you for being open source devs... irregardless of no open discussion... any update on #2109... why is it being straight up disregarded?

We're working through the many different types of cursed inscriptions step by step, and are starting with what looks like the most-straightforward cases. Please be a little patient. Current plan is to get the uncontroversial cases of cursed inscriptions out first, so that we can make forward progress, and then tackle the other cases from #2045 like cursed inscriptions with unrecognized even tags (including OP66 etc), and other cases (like inscriptions on P2WSH) as in case #2139 after that.

[BennyTheDev]

what are reinscriptions?

[raphjaph]

reinscriptions

inscribing a sat multiple times. Still figuring out if we should allow that and how exactly it should work.

[BatBushRacks]

@raphjaph @veryordinally first off thank you for being open source devs... irregardless of no open discussion... any update on #2109... why is it being straight up disregarded?

We're working through the many different types of cursed inscriptions step by step, and are starting with what looks like the most-straightforward cases. Please be a little patient. Current plan is to get the uncontroversial cases of cursed inscriptions out first, so that we can make forward progress, and then tackle the other cases from #2045 like cursed inscriptions with unrecognized even tags (including OP66 etc), and other cases (like inscriptions on P2WSH) as in case #2139 after that.

@veryordinally thank you so much for responding... that all sounds great... patience is possible when we all have honest discourse... though what seems to be missing is any mention of the bound or unbound treatment of #2109... can we get a commitment that they will be bound?

[BennyTheDev]

reinscriptions

inscribing a sat multiple times. Still figuring out if we should allow that and how exactly it should work.

Thank you.

In regards to, all but but the first inscriptions being unbound: you mean multiple inscriptions within one input, not inscriptions across multiple inputs, correct? I am a bit confused about the initial comment, because it sounds like "anything" but the first is cursed and unbound.

[DanteScott]

reinscriptions

inscribing a sat multiple times. Still figuring out if we should allow that and how exactly it should work.

I think allowing reinscriptions would be useful in making rare sat / sub 100k inscriptions “recycleable”. Assuming the inscription number remains after reinscription, we could see new sub 100k collections emerge and rare sat inscriptions repurposed.

[BatBushRacks]

@raphjaph @veryordinally first off thank you for being open source devs... irregardless of no open discussion... any update on #2109... why is it being straight up disregarded?

We're working through the many different types of cursed inscriptions step by step, and are starting with what looks like the most-straightforward cases. Please be a little patient. Current plan is to get the uncontroversial cases of cursed inscriptions out first, so that we can make forward progress, and then tackle the other cases from #2045 like cursed inscriptions with unrecognized even tags (including OP66 etc), and other cases (like inscriptions on P2WSH) as in case #2139 after that.

@veryordinally thank you so much for responding... that all sounds great... patience is possible when we all have honest discourse... though what seems to be missing is any mention of the bound or unbound treatment of #2109... can we get a commitment that they will be bound?

Conveniently speedily merged without comment on #2109... seems like a pattern... avoid avoid avoid...

[BennyTheDev]

I think there is an edge case not covered:

if there is just one inscription in a tx but not in input 0, it is cursed but treated like a "collection" and the new satpoint calculations are applied, which leads them to be unbound under certain circumstances. Imho they should generally get offset = 0 and be bound.

You can cross-test this with ord 0.5.1, modify it to inscribe for example from input index 1. It will treat it as it should, while ord 0.6.0 completely differs.

[jotapea]

Recognizes multiple inscriptions per transaction:

1. in different inputs
2. in the same input

I believe the most sound way to move forward is to only count the FIRST inscription per input. Or even simpler, only consider the inscription valid if it has ONE inscription per input.

Recognizing multiple inscriptions in the same input seems like over-complicating the protocol when there is no real need. Is not like multi-file inscriptions are not possible now, because the data envelope can itself be a multi-part file (like a zip file or just multiple files directly encoded in a json).

AND what is the point of multiple inscriptions in the same input, if the main goal of recognizing multiple inscriptions per transaction is already covered by allowing them in different inputs?

Sorry for coming off in a harsh way, but over-complicating the protocol is not the best design choice.

[cvasqxz]

Sorry for coming off in a harsh way, but over-complicating the protocol is not the best design choice.

There's an economical incentive to over-complicate the protocol, people will try to break the inscriptions parsing to say they have a rare inscription and sell it at a premium

This is why bitcoin has the BIP system, to prevent people adding stuff to the code for personal profits or benefits

[BatBushRacks]

I think there is an edge case not covered:

if there is just one inscription in a tx but not in input 0, it is cursed but treated like a "collection" and the new satpoint calculations are applied, which leads them to be unbound under certain circumstances. Imho they should generally get offset = 0 and be bound.

You can cross-test this with ord 0.5.1, modify it to inscribe for example from input index 1. It will treat it as it should, while ord 0.6.0 completely differs.

@BennyTheDev not a dev so not certain... but looks like a fix is being made for the bug you found... #2154... sure would be nice if the devs understood that open source includes open discourse... hopefully with time...

[concernedordinal]

reinscriptions

inscribing a sat multiple times. Still figuring out if we should allow that and how exactly it should work.

Hey @raphjaph this directly contradicts what you wrote in the first message. That said "All but the first inscription in the first input are cursed (for now). In addition all but the first inscription in an input are made unbound (they will be bound in the future as reinscriptions)." Can you clarify things? Super confusing as it currently stands.

[jokie88]

Sorry for coming off in a harsh way, but over-complicating the protocol is not the best design choice.

There's an economical incentive to over-complicate the protocol, people will try to break the inscriptions parsing to say they have a rare inscription and sell it at a premium

This is why bitcoin has the BIP system, to prevent people adding stuff to the code for personal profits or benefits

This is a very important and under-appreciated risk. The long term health and longevity of the Ordinals protocol is the most important thing for the ecosystem. Once you add something in, it is hard to take it out.

If Ordinals as a protocol becomes too bloated or unmaintainable, people will move to a new standard. (this sort of standards obsolescence happens quite often in tech)

If people move on to a new standard of course, no inscriptions will hold any value and the entire ecosystem will disappear.

I encourage everyone to focus on the big picture let the team make the best decision they can.

[creamplanet]

Sorry for coming off in a harsh way, but over-complicating the protocol is not the best design choice.

There's an economical incentive to over-complicate the protocol, people will try to break the inscriptions parsing to say they have a rare inscription and sell it at a premium
This is why bitcoin has the BIP system, to prevent people adding stuff to the code for personal profits or benefits

This is a very important and under-appreciated risk. The long term health and longevity of the Ordinals protocol is the most important thing for the ecosystem. Once you add something in, it is hard to take it out.

If Ordinals as a protocol becomes too bloated or unmaintainable, people will move to a new standard. (this sort of standards obsolescence happens quite often in tech)

If people move on to a new standard of course, no inscriptions will hold any value and the entire ecosystem will disappear.

I encourage everyone to focus on the big picture let the team make the best decision they can.

My understanding was recognizing both "1. in different inputs" and "2. in the same input" is bloated and unnecessary. Seems to be in line with your thinking. Maybe I don't understand what you mean. Contradiction on reinscription is concerning from this angle too.