Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RIzK4-0006rf-Cc for bitcoin-development@lists.sourceforge.net; Wed, 26 Oct 2011 08:58:56 +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 1RIzK2-0007lT-Kq for bitcoin-development@lists.sourceforge.net; Wed, 26 Oct 2011 08:58:56 +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 p9Q8wjo1029693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Oct 2011 10:58:47 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Wed, 26 Oct 2011 10:58:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com> References:

To: Bitcoin Dev 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: 1RIzK2-0007lT-Kq 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: Wed, 26 Oct 2011 08:58:56 -0000 I think it is a very important feature to be able to extract transaction = to/from you only from your private keys. In the standard transactions = this is easily accomplished - in the case you only want to find the addr = to tx mapping: vector > > vSolution; if (!Solver(scriptPubKey, vSolution)) return 0; BOOST_FOREACH(PAIRTYPE(opcodetype, vector)& item, = vSolution) { vector vchPubKey; if (item.first =3D=3D OP_PUBKEY) // encode the pubkey into a hash160 return Hash160(item.second); else if (item.first =3D=3D OP_PUBKEYHASH) return uint160(item.second); =20 } This possibility is used today in: * blockexplorer * bitcoin-js * my own tiered implementation for thin clients I agree that you can of course always construct payment schemes to hide = payments (hashes from classic novels, sending the private key off line = etc), but I consider those either exotic or on purpose hidden, and hence = they are not really a problem, nor an argument that this feature does = not really exist today. So, if we introduce a standard (multikey) payment that hides the address = (or makes it overly complicated to extract it) it will be a major = problem for the projects that I listed above.=20 I will post a more detailed technical comment reflecting directly on the = BIPs, but the wiki is currently down and I need to re-read the BIPs = first. Cheers, Michael On 25/10/2011, at 18:47, Alan Reiner wrote: > On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell = wrote: > On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen = wrote: >> 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). >=20 > If anyone finds that solution unsatisfying, consider=97 It's already = the > case that I could take one of your disclosed public keys and create an > infinite series of secondary keys out of it for which only you could > decode, and the only way for you to find them in the blockchain would > be to have performed the same procedure and made a note of the > addresses you're watching for. >=20 >=20 > (1) As I understand it, OP_EVAL is being proposed as an *optional* = tool for multi-signature transactions. It sounds like to me, that you = can still use the regular OP_CHECKMULTISIG if you are concerned about = these things. If you're dealing with too many parties with questionable = reliability that they will notify you of transacitons that include you, = I don't see anything wrong with declaring that you'd only prefer dealing = with OP_CMS transactions and not OP_EVAL (besides some grumbling from = them that their way is "better"). Either way, they're screwing = themselves, too, if they want to include you on transactions and don't = notify you as such (kind of defeats the purpose of multi-sig txs). >=20 > (2) I think it's unnecessary to discuss cases where you somehow lose = your mappings but not your private keys. In order for OP_EVAL scripts = to work, the subscripts/mappings are *just as important* as your regular = private keys. They should be kept in your wallet forever just like your = private keys--and thus you lose none of them or all of them. The only = real difference is that they aren't sensitive like your private keys, so = they don't have to be encrypted. >=20 > (3) There should most definitely be a button on the main client that = allows you to "Add OP_EVAL script" or something along those lines (maybe = something with a less obscure name). We need to make it as easy as = possible for someone to add such a script/mapping to their wallet. = Although, this invites a breach of one of my core rules of user = interfaces: if the functionality is dependent on the user performing = some regular maintenance task, you better be prepared for all users to = fail at doing it. Even diligent users are going to forget/mess-up = sometimes. If failure at performing this task results in breaking the = client or losing money, we should avoid promoting that usage paradigm. >=20 > = --------------------------------------------------------------------------= ---- > 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=20 > about Cisco certifications, training, and career opportunities.=20 > = http://p.sf.net/sfu/cisco-dev2dev_________________________________________= ______ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development