Get output value of recursive inscription endpoint from database instead of Bitcoin Core

[raphjaph]

fn inscription_recursive

[Blockamoto]

Wow this would dramatically speed up recursive requests.

It centralizes recursion, however.

Would need a failsafe method to check bitcoin core for the same endpoints. FAST recursion and SLOW recursion.

The FAST method would be through database. The SLOW method would be through core.

So if FAST method becomes default, how could I access the SLOW method for full verification purposes?

Maybe an environment in the explorer to run full tests on recursive inscriptions via Core, which cross-references the database for errors.

[raphjaph]

What do you mean by centralize recursion?

[Blockamoto]

What do you mean by centralize recursion?

The current method of recursion requests data directly from Bitcoin Core, correct?

If an inscription is fetching sat numbers, for example, the ord logic is applied to the data retrieved directly from core through the node.

This is like a single SMALL cog attached (ord logic) between inscriptions and the core spoke.

All I have to validate is that the LOGIC (small cog) is correct.

With this update, recursion can no longer fetch data directly from Bitcoin Core. It must rely on the Ord database for its data. Is this correct?

So, whilst I may choose to TRUST that the database is logically sound and maintained correctly, that reorgs are handled properly, and other potential errors, this is not guaranteed.

Now ORD database is replacing the central spoke of Bitcoin as the Constant in this equation, and Bitcoin is a cog from which it collects and stores ITS data. However, we know ORD is subject to trust and changeability, which means it is not suited to be the constant.

More opportunity for things to go wrong in between my inscription and the answer retrieved by my inscription, in which I'm looking for the best source of truth.

Let me know if anything is incorrect here!

---

The speed advantages are welcome, which is I why I am glad for this improvement. As the DEFAULT method for retrieval, I think it's fine, as the data ultimately comes from the same place and stored by the node.

I would just request the ability to run an inscription with the SLOW method. If we assume database has no problems, this only needs to be used for validating inscriptions against core. But I think it's vital to be able to run inscriptions from core as an option.

Similar to how we have "preview" and "content", maybe we should have an extra field for "execution". Slower method of retrievong data, but fetches directly from Bitcoin Core.

Let me know if my concerns are unfounded. For me, the appeal of recursion is that I am fetching data directly from Bitcoin Core. Removing such ability with no option to do this is what I mean by centralization. I would prefer the option.

[elocremarc]

With this update, recursion can no longer fetch data directly from Bitcoin Core. It must rely on the Ord database for its data. Is this correct?

We already doing this on fn_recursive_inscription with the sat. We are also using the DB on the child/sat endpoints as well.

But I think it's vital to be able to run inscriptions from core as an option.

I don't really understand your logic. Ord has always been a lens over bitcoin core how the data is processed doesn't matter you are always trusting some ordinals server to return the correct response. Recursion has never been doing RPC calls directly to core your always interfacing with it over ord.

If we assume database has no problems,

That is why this repo has extensive test requirements

Let me know if my concerns are unfounded. For me, the appeal of recursion is that I am fetching data directly from Bitcoin Core. Removing such ability with no option to do this is what I mean by centralization. I would prefer the option.

You can run your own ord explorer against your own bitcoin core and verify the shared hallucination with command ord server https://docs.ordinals.com/guides/explorer.html#running-the-explorer