From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RJLxM-0000fh-0v for bitcoin-development@lists.sourceforge.net; Thu, 27 Oct 2011 09:09:00 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.47 as permitted sender) client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com; helo=mail-qw0-f47.google.com; Received: from mail-qw0-f47.google.com ([209.85.216.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RJLxL-00058L-7z for bitcoin-development@lists.sourceforge.net; Thu, 27 Oct 2011 09:08:59 +0000 Received: by qam2 with SMTP id 2so3025161qam.34 for ; Thu, 27 Oct 2011 02:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.69.168 with SMTP id z40mr782442qci.261.1319706533800; Thu, 27 Oct 2011 02:08:53 -0700 (PDT) Received: by 10.229.21.135 with HTTP; Thu, 27 Oct 2011 02:08:53 -0700 (PDT) In-Reply-To: <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com> References: <7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com> <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com> Date: Thu, 27 Oct 2011 05:08:53 -0400 Message-ID: From: Gregory Maxwell To: =?UTF-8?Q?Michael_Gr=C3=B8nager?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.2 AWL AWL: From: address is in the auto white-list X-Headers-End: 1RJLxL-00058L-7z 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 09:09:00 -0000 (taking this a bit out of order) On Thu, Oct 27, 2011 at 3:32 AM, Michael Gr=C3=B8nager wrote: > OK, let me try to explain what I see is the problem: [snip] > This, I find a nice and clean setup, where cryptographic keys can be mapp= ed to assets. >From my perspective that clean boundary remains: Functionally the script is part of the cryptographic key. [snip] > except if you also have the knowledge of the script that was used. Which you must. I can see no functional difference than if you said of the current system "except if you also have knowledge of the final 32 bits of the ECC private key". I don't see any reason to expect clients to identify funds without knowing the information required=E2=80=94 it's impossible. I mean, sure, yo= u _could_ bruteforce the final 32 bits of your private key=E2=80=94 or you co= uld attempt to try the cartesian product of every key you have with every key seen in the block chain for finding an op_eval script. But thats unworkable, unnecessary, equally bad for all client types, and not being suggested. Under either system a coin is not yours unless you know all of the right bits=E2=80=94 knowing some is not good enough. Could you suggest how else we could gain the advantages of op_eval without it? How can I secure my wallet under whatever scheme I like=E2=80= =94 create a trust that requires multiparty signoff=E2=80=94 and securely have senders pay into it without expecting them all to handle some rare and complicated procedure for sending to me? (Or a burdensome address which serializes a script and a large amount of data into hundreds of characters, and which still may be unable to represent the rules I wish to have govern my account=E2=80=94 and which the sender might mutate= =E2=80=94 e.g. twiddling the threshold counts=E2=80=94 and cause me great problems/confusion) [snip] > 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 de= fined solely by your privatekeys (from which you can extract pubkeys and th= en uint160 btc-addresses). [snip] > 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 i= ntrinsic 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. On the basis of the discussion here I now oppose checkmultisig as a standard transaction type. (Sorry, I'm not trying to be a jerk if it came off that way, I'm not opposing it simply because you support it:) The advantage I saw of having it was faster deployment for the explicit escrow cases that don't need to encode the payment rules in an address (as is needed for wallet security and trusts)... but it seems to me that there is a serious misunderstanding that there is a bijection between hash160s and public keys, and one between ECC private keys and spendable transactions, and that this bijection is desirable or even essential to bitcoin. I'm concerned that this misunderstanding will moot the flexibility of the script system because every script that doesn't look like a direct mapping of hash160->pubkey->payee will be regarded as _broken_=E2=80=94 not just useless to one app or another which could have simply chosen not to generate those addresses=E2=80=94 but actually incompatible with bitcoin= , as is basically being argued here=E2=80=94 or, keeping in mind that people = can freely mine non-standard transactions, could this result in tools which are rendered insecure by unexpected transaction types=E2=80=94 Will a system that thinks HASH160 =3D IDENTITY recognize that a script which also requires an additional secret key on the stack is unspendable? Keeping checkmultisig alone as a standard transaction, when it's functionally a redundant subset of OP_EVAL (and inferior because it reduces the txn you can place in a block) could only further that misunderstanding. :-/