Jubilee Bounty

[casey]

Currently, there are many desirable ways of making an inscription which results in the inscription being cursed and receiving a negative inscription number. These include multiple inscriptions in a transaction, inscriptions using the pointer field, and inscriptions with metadata larger than 520 bytes. These inscriptions weren't indexed by the first version of ord, so in order to index them while keeping inscription numbers stable, they are assigned negative inscription numbers outside of the positive inscription number sequence.

We are planning, at a future block height, to make new inscriptions which use these features uncursed. This is fancifully termed the Jubilee.

We would like to avoid a situation where, after the Jubilee, we discover new ways to make inscriptions which are desireable, and which cause the inscription to be unrecognized by ord, which might necessitate a second Jubilee, fancifully termed "Jubilee 2: Electric Boogaloo".

To help root out issues before the Jubilee, we are offering a 0.1 BTC bounty to the first person who finds a way to create an inscription which is unrecognized by the current master branch version of ord, is desirable to recognize, and which we don't already know about. The bounty runs from today, November 17th, to Sunday November 26th.

Please keep in mind that this criteria is highly subjective. We reserve the right to determine what is and isn't desirable to recognize, and what we have already considered. By participating in the bounty, keep in mind that you are relying on our subjective judgement!

Some examples of things which would qualify for the bounty:

• A bug in the index, envelope, or inscription parser which causes an inscription to be unrecognized.
• A massive and beneficial improvement in how inscriptions are encoded.

Some examples of things which woudln't qualify for the bounty:

• Bugs or issues which cause inscriptions to be unbound or corrupted, but still recognized.
• Inscriptions in P2SH and P2WH inputs. We've considered this decided not to support it.
• Alternative encodings of envelope tag numbers. There are many possible ways to encode integers as tags, and we believe that the current acccepted encodings are fine.
• Inscriptions in the Taproot signature annex. This is not eligible because although it would be beneficial, we already know about this case, and plan to do it with a activation height-based rollout.

Good luck, and happy hunting!

[felipelincoln]

instead of recognizing only the following witness data

OP_FALSE
OP_IF
PROTOCOL_ID
...

it could also support

OP_TRUE
OP_NOTIF
PROTOCOL_ID
...

Example reveal txn not indexed by ord

and

OP_TRUE
OP_IF
OP_ELSE
PROTOCOL_ID
...

Example reveal txn not indexed by ord

[casey]

@felipelincoln This is true, and it would be better! However, it's a marginal improvement, and probably not worth the disruption, and we already knew about it: https://twitter.com/rodarmor/status/1706124168314638538

[arik-so]

What about ending the envelope in an OP_ELSE instead of an OP_ENDIF, so there could be something like a signature verification in the else clause?

Example: https://mempool.space/testnet/tx/3d1a2f7bb221d04e585dbe4dd61d77c9809769231ceb0a65ddcd637bd2c926e9

[arik-so]

Also, what about inserting arbitrary op codes in the middle of an envelope, such as an OP_DROP – should that mark the envelope as invalid?

Example: https://mempool.space/testnet/tx/a194afa2a7de7945fa91ef4a23cc9f8f0a682db70a0f1497033053262de03b3c

[casey]

What about ending the envelope in an OP_ELSE instead of an OP_ENDIF, so there could be something like a signature verification in the else clause?

Example: https://mempool.space/testnet/tx/3d1a2f7bb221d04e585dbe4dd61d77c9809769231ceb0a65ddcd637bd2c926e9

Once ord sees an inscription transaction, it's already been validated by bitcoin core, since it's been included in a block. So, it knows that all opcodes in the transaction were executed successfully, so it doesn't need to check them itself. If there's need for some kind of verification that bitcoind can't perform, the data needed to do so could be included in a header value.

[casey]

Also, what about inserting arbitrary op codes in the middle of an envelope, such as an OP_DROP – should that mark the envelope as invalid?

Example: https://mempool.space/testnet/tx/a194afa2a7de7945fa91ef4a23cc9f8f0a682db70a0f1497033053262de03b3c

I think so. Since they aren't executed, I can't think of any particular benefit to recognizing them.

[arik-so]

Once ord sees an inscription transaction, it's already been validated by bitcoin core, since it's been included in a block.

Of course. Point being that that verification, aimed at bitcoin core, could live inside the else clause. The else clause is not supposed to be part of the envelope; the envelope would simply end in OP_ELSE.

[arik-so]

Since they aren't executed, I can't think of any particular benefit to recognizing them.

True, though I would note that this also breaks when that op code is inside the body, following OP_0. Not sure why somebody would want to put an op code in the body (other than the above mentioned OP_ELSE), but it seems like a more reasonable location to be putting arbitrary stuff.

[cbspears]

True, though I would note that this also breaks when that op code is inside the body, following OP_0. Not sure why somebody would want to put an op code in the body (other than the above mentioned OP_ELSE), but it seems like a more reasonable location to be putting arbitrary stuff.

I am not super familiar with the development of rollups, but isn't one of the main ideas behind the new rollup work on Bitcoin (utilizing the inscription envelope design) to enable opcodes which would otherwise require a bitcoin soft fork?

[casey]

I am not super familiar with the development of rollups, but isn't one of the main ideas behind the new rollup work on Bitcoin (utilizing the inscription envelope design) to enable opcodes which would otherwise require a bitcoin soft fork?

Rollup payloads would probably be just pushbyte opcodes, which contained the rollup scripts, not directly including them in an envelope verbatim.

[casey]

Of course. Point being that that verification, aimed at bitcoin core, could live inside the else clause. The else clause is not supposed to be part of the envelope; the envelope would simply end in OP_ELSE.

Right, but in that case, it doesn't need to be in the else clause at all. It can just be before or after the envelope. Also, this could be done in a backwards compatible way if we wanted to do it later.

[arik-so]

Just out of curiosity, how would the backwards-compatible way work without renumbering?

[casey]

Just out of curiosity, how would the backwards-compatible way work without renumbering?

Currently, inscriptions with a trailing OP_ELSE are indexed and already receive an inscription number, so if we wanted to give special meaning to the content of the OP_ELSE, we could do so without renumbering.

[arik-so]

Hm, I feel like I'm missing something. The transaction I linked above, 3d1a2f7bb221d04e585dbe4dd61d77c9809769231ceb0a65ddcd637bd2c926e9, did not have an inscription indexed: https://testnet.ordinals.com/tx/3d1a2f7bb221d04e585dbe4dd61d77c9809769231ceb0a65ddcd637bd2c926e9

But to be fair, it did have some random stuff inside the else clause (OP_TRUE OP_DROP, to make it be valid for bitcoind). So I tried with just a trailing OP_ELSE here: https://mempool.space/testnet/tx/7bb6dfc94905e1aa4568274241d8cc7861ba6acaac81249069bb060ad73edda6

And it also did not get indexed: https://testnet.ordinals.com/tx/7bb6dfc94905e1aa4568274241d8cc7861ba6acaac81249069bb060ad73edda6

Sorry in advance for being dense!

[casey]

Ah, no, of course you're right. The envelope ends with the OP_ELSE, which is an invalid op code.

[arik-so]

I can submit a PR to fix it – if you think it should be, that is. It's fairly trivial.

[casey]

What do you imagine the use-case would be? It would be for associating arbitrary bitcoin script with an inscription, but I'm not sure what that would be useful for. Especially because it has to be executes, so you couldn't include the equivalent of a script pubkey, which is only valid when given additional inputs, or a script witch becomes valid later, for example with a timelock.

[arik-so]

I cannot imagine a scenario where this would actually make sense, considering it's cheaper to do bitcoin-script-related checks outside the envelope. Really the question is merely if it should be considered valid, which is a subjective matter that I probably should not opine on.

[ipoh123]

@casey Hi, found a bug in the index if there are two or more OP_0 before OP_IF. OP_0 OP_0 OP_IF ... OP_ENDIF

check this tx https://mempool.space/tx/99972873dcd0596c2c81e3ed97704aa3924665a872f9eb9fbb9e1f975703e998

[casey]

@ipoh123 Nice find! I think this qualifies for the bounty. Check out the fix in #2745. It adds a new type of curse, the stuttering curse, for inscriptions which start with OP_FALSE OP_FALSE OP_IF or OP_FALSE OP_IF OP_FALSE OP_IF.

[arik-so]

Love the find! In a very similar vein, if the envelope is nested inside another OP_IF, should it be detected? I. e.

OP_FALSE 
OP_IF
    OP_FALSE
    OP_IF
        <ORDINAL ENVELOPE CONTENT>
    OP_ENDIF
OP_ENDIF

Example: https://mempool.space/testnet/tx/a0f87956d3b56605e1fb2dbe4464d2ae36cd50479ab5a1c7bab06911d16921bc https://testnet.ordinals.com/tx/a0f87956d3b56605e1fb2dbe4464d2ae36cd50479ab5a1c7bab06911d16921bc

[arik-so]

Maybe testnet.ordinals.com just isn't updated yet, because you explicitly mention in your comment it should be detected.

EDIT: Ah, it's not merged yet lol, nvm.

[casey]

It is November 27th, one day after the bounty deadline, so the Jubilee Bounty has concluded! @ipoh123's find was the first and only qualifying submission, finding a bug in the inscription parser which would cause inscriptions with combinations of OP_FALSE and OP_IF before the inscription to go unrecognized. @ipoh123, can you send me an Bitcoin address to receive the bounty reward? (You can also drop your Telegram handle and DM me there at @rodarmor.)

Although this did cause some inscriptions to be unrecognized, it doesn't make me worry very much about the Jubilee, since we probably wouldn't have bothered to do another Jubilee based on this find.

[ipoh123]

@casey bc1pxpwu76l3ksjz8l0xmvljrgkzw6fnjsa5zccssnwyvuwrdg3fgq7sjpxrkh :)

[casey]

@ipoh123 Thank you! And sorry for the delay, we should be able to pay the bounty shortly, no later than Friday of this week.

[casey]

@ipoh123 The bounty has been paid out! https://mempool.space/tx/74bd591accfb44167b7799de12778bee93288a590159d09c78cb90184634398a Thank you very much for finding the stuttering curse! 🙇‍♂️

[ipoh123]

@casey reveived! Thanks!~