“Back to Genesis” Simplest Explanation

I made a few attempts at the “Back to Genesis” problem last weekend, here’s what I’ve figured out so far.

Here is a contract snippet which, at first glance, appears to create a unforgeable, unique identifier (UID), using the hashPrevouts of the txPreimage.

While this works without issue. It is highly vulnerable. You cannot prove that the ancestors used the same code.

Anyone can copy the OP codes, and make an identical output, because nothing in the script is checking the validity of the parents. So if I receive a token identified with this method, I can’t tell if it is a forgery, without checking all the ancestors back to the initial transaction.

Even if I check the script code of the parents, an attacker could make one invalid transaction, follow it up with a million valid transactions, and it would be very difficult to find the culprit.

Here’s the problem with checking the parents in the script:

If you include the rawtx to check the parents, it doubles the transaction size. Then when that rawtx is checked during the next transaction, it grows even larger, until eventually it is extremely large. Every transfer, the size would increase until it would eventually cost 1 BSV or more to send.

Really the only lead you get as to whether the script of the parents of a transaction are valid are the input transaction ids. But you cant actually check the contents of those rawtxs without creating an ever-increasingly large rawtx.

I wondered if you could hash the transaction ids together into a merkle root of sorts, and backtrack it that way. At the moment this method looks equally forgeable as the initial method. I also considered other crypto methods like a verkle root or binary trie. Those may be worth investigating.

TLDR:
If you could prove the parents of each transaction used that first code snippet, then it would be secure, but it is easy to spoof at the moment. Please let me know if you have any leads. buildonbsv@gmail.com