Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RJKRx-0004FG-Jv for bitcoin-development@lists.sourceforge.net; Thu, 27 Oct 2011 07:32:29 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1RJKRv-0005iv-W0 for bitcoin-development@lists.sourceforge.net; Thu, 27 Oct 2011 07:32:29 +0000 Received: from [109.105.106.199] ([109.105.106.199]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9R7WGXu027850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 09:32:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Thu, 27 Oct 2011 09:32:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com> References: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com> To: Gavin Andresen X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RJKRv-0005iv-W0 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:32:29 -0000 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.=20 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=F8nager = wrote: >> I think it is a very important feature to be able to extract = transaction to/from you only from your private keys. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > Feel free to contact me about your 'tiered implementation for thin > clients' -- I don't think OP_EVAL will make that significantly harder. >=20 > I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing > that CHECKMULTISIG becomes a standard transaction type. >=20 > --=20 > -- > 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: gronager@ceptacle.com