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.
For the case of a single payment, that's not a problem. It means for each key you now have to check for: - raw key - key hash - hash of script that contains key hash - hash of script that contains raw key which isn't so bad. What is the complexity like when multi-signing comes into the picture? I *think* it's not an issue for the use cases currently envisioned, but being unable to "see into" a script could complicate things later. Specifically: for a wallet protection service, you have to make sure the WPS keys are matched 1:1 with your own private keys. You must never mix them up otherwise you have to check the block chain for the cross-product. Deterministic wallets are one way to achieve that without compromising privacy. For escrow contracts, using OP_EVAL means you cannot detect them unless the sender has told you the pubkey they are going to use, because otherwise you can't recreate the hashed script. Escrow protocols require some out of band communication anyway in order to set up the escrow key, so this isn't inherently a problem. Are there any use cases where you will want to recognize transactions to you, where you can't predict the full script contents? ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
