First attempt at the “Back to Genesis” issue
There has been a lot of talk about the problem of having to verify a transaction’s parents’ parents are authentic when attempting to use a “unique identifier”.
I may have a solution that has one large assumption of a future feature; the ability to require a state variable to start at a value. Although it may actually be possible now using the correct logic gates.
Here is the crux of it: if you use the hashPrevouts as the unique identifier at the beginning of the contract, then you can store it in the sCrypt state and require it as the unique identifier (uid) for future transaction inputs.
No one can forge a transaction’s hashPrevouts to my knowledge. Then the only question is, “did the transaction I just received actually use this contract”?
So you might need to have a copy of the scrypt-lib npm module installed in the recipient wallet, so that they could verify that this lock was used on the transaction, along with the advertised inputs.
You might want to attempt to spend the received token (to yourself) in order to validate it is legitimate. I don’t think that would be a big deal with tx fees as cheap as they are on BSV.
Lastly, the contract issuer would likely want to publicly acknowledge the rawtx of the original transaction with the hashPrevouts which was used as the unique identifier.
PS. I would be happy to share these files if you’d like to take a crack at the logic gates. Available via buildonbsv@gmail.com.
To summarize the issue with this method, presently you can initialize the contract with any value as ‘uid’, including the hashPrevouts of a different transaction. To be secure, this solution requires a state value to start at b‘00’ (or any other provable value) and change to the hashPrevouts of the initializing transaction. It would also work if we could prove that uid “had ever” been equal to b’00'.
Edits:
1. This could be a hint. It shows how sCrypt contracts can initialize each other.
