Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-25 🗒️ Summary of this message: OP_EVAL ...

📅 Original date posted:2011-10-25
🗒️ Summary of this message: OP_EVAL scriptPubKeys contain a hash of a script, but pre-calculating every possible hash is inefficient. Instead, store the hash --> script mapping.
📝 Original message:On Tue, Oct 25, 2011 at 6:49 AM, Mike Hearn <mike at plan99.net> wrote:
> scriptPubKeys that use OP_EVAL contain a hash of a script. If I
> understand correctly, that means to detect a transaction in a block
> that is relevant to your wallet, that means you need to pre-calculate
> every possible hash that might appear.

You could do it that way... but that would be inefficient.

You give the hash to whoever is paying you, and store the hash -->
script mapping when you do that (assuming you're not using a
deterministic wallet; if you are, you probably just increment a
counter in the wallet).

The only use case I can think of where you'd want to check for every
possible hash is if you lose your wallet, you have a wallet backup
that has your private keys in it, but DOES NOT have the hash -->
script mapping(s).

For use cases involving other people, that's probably not a problem--
you could ask them to tell you what public keys are involved, and then
add them back in to the wallet (the RPC interface I settled on for
m-of-n txns is an "addmultisigaddress" that takes the "m" and an array
of "n" public keys, creates the script, adds the hash-->script mapping
to the wallet, and returns the hash).

For use cases where all the keys belong to you... either a good,
automatic, in-the-cloud-backup or the equivalent of "-rescan" is
needed to recover in case the mappings are lost.

--
--
Gavin Andresen