OK, let me try to explain what I see is the problem: So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses).
This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not). In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s. This, I find a nice and clean setup, where cryptographic keys can be mapped to assets. If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra "public key" being the "something extra", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used. I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean. So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL. Cheers, Michael On 26/10/2011, at 17:00, Gavin Andresen wrote: > On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <grona...@ceptacle.com> > wrote: >> I think it is a very important feature to be able to extract transaction >> to/from you only from your private keys. > > Why? If somebody is sending me bitcoins, then they'll have to get > either an address or one or more public keys from me. OP_EVAL just > lets me give them a short address that represents an arbitrary number > of keys combined in an arbitrary way. > > I agree with Gregory: it shouldn't matter if that address is > HASH(public key) or HASH(op_eval_script), the issues are the same (if > you lose or cannot re-create the key/script then you're in trouble). > > Maybe I'm missing something; are you worried that blockexplorer won't > know that coins sent to HASH(op_eval_script) are actually a > complicated transaction until the coins are spent again? I'd consider > that a feature, not a bug, because only the people involved in the > transaction need to know the details until after the transaction is > complete. > > Feel free to contact me about your 'tiered implementation for thin > clients' -- I don't think OP_EVAL will make that significantly harder. > > I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing > that CHECKMULTISIG becomes a standard transaction type. > > -- > -- > Gavin Andresen Michael Gronager, PhD Owner Ceptacle / NDGF Director, NORDUnet A/S Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 62 14 01 E-mail: grona...@ceptacle.com ------------------------------------------------------------------------------ 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
