Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YjdH6-0003FL-Mf for bitcoin-development@lists.sourceforge.net; Sun, 19 Apr 2015 00:39:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.77 as permitted sender) client-ip=62.13.149.77; envelope-from=pete@petertodd.org; helo=outmail149077.authsmtp.com; Received: from outmail149077.authsmtp.com ([62.13.149.77]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YjdH4-0003oi-R8 for bitcoin-development@lists.sourceforge.net; Sun, 19 Apr 2015 00:39:52 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3INXpBc016582; Sun, 19 Apr 2015 00:33:51 +0100 (BST) Received: from muck (bas3-cooksville17-1176329474.dsl.bell.ca [70.29.93.2]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3INXjYt086800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 19 Apr 2015 00:33:48 +0100 (BST) Date: Sat, 18 Apr 2015 19:33:52 -0400 From: Peter Todd To: Stephen Morse Message-ID: <20150418233352.GA9878@muck> References: <20150409172808.GB27775@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: X-Server-Quench: 5d988b56-e623-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUGUUGAgsB AmMbW1ReU157XWo7 bApPbwxDa0lQXRpv WE9WQxwWF3wWaUZo Qh4WVBFyd0tEfX14 ZQhnCnlTVBZ/c1so RExXCGwHMGN9YTYY VF1YdwFReQMbfxxA PlMxNiYHcQ51Pz4z GA41ejw8IzhbLzxQ TwcRGBo4XEcPEnYt QA0YVTIwGwUDZywo LyA3MlN0 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 70.29.93.2/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YjdH4-0003oi-R8 Cc: bitcoin-development Subject: Re: [Bitcoin-development] Build your own nHashType 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: Sun, 19 Apr 2015 00:39:52 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 09, 2015 at 10:56:20PM -0400, Stephen Morse wrote: > On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd wrote: >=20 > > For the OP: Have you looked at how CODESEPARATOR allows the signature to > > sign code to run as part of verifying the signature? E.g. my signature > > can say "valid if you run these additional opcodes and they return true" > > where those additional opcodes take the transaction, hash it in the > > defined way, and verify that the ECC signature correctly signs that > > hash and the hash of the additional opcodes. For instance in this case > > making a signature that's only valid if the tx fee is less than the > > defined amount would be a matter of GET_FEE LESSTHAN VERI= FY > > >=20 > I've never been able to really see a good use case for OP_CODESEPARATOR, > and I'm not sure I completely have my head wrapped around what you're > proposing. From this > > and this > , > though, it seems like OP_CODESEPARATOR cannot really be made useful unless > you already have a way to sign without hashing the TXIDs referenced by yo= ur > input, in which case you need to modify the nHashType. I wrote up how to do this on #bitcoin-wizards, Dec 9th 2014: 17:13 < petertodd> hearn: even now you can use OP_CODESEPARATOR to implement efficient payword schemes 17:14 < petertodd> hearn: early on you could have used it to do some really useful after-the-fact signing delegation by wrapping a IF ENDIF around the CODESEPARATOR introduced into the middle of the scriptSig/scriptPubKey pair - shame we got rid of that without thinking the design through 17:15 < petertodd> hearn: e.g. "create a signature that delegates signing authority to another pubkey" 17:15 < petertodd> probably all 100% accidental... but a nice accident 17:16 < hearn> it's probably for the best. i can imagine such things being a surprise for implementations not expecting them. a script 2.0 effort that incorporates lots of neat features but still lets script 1.0 work would be nice to have, one day 17:17 < petertodd> satoshi belived in 1 implementation, and by putting CODESEPARATOR into the scriptSig/scriptPubKey concatenation you had to opt-in to making that feature possible to use in any particular scriptPubKey 17:17 < petertodd> w/o the mis-matched ENDIF you can't pull off that trick because you can't turn CODESEPARATOR off 17:19 < petertodd> to be explicit: scriptPubKey: ENDIF CHECKSIG, then the normal case is scriptSig: 1 IF 17:19 < petertodd> they concatenate to 1 IF ENDIF CHECKSIG, CODESEPARATOR is evaluated, and the signature is evaluated on the script ENDIF CHECKSIG 17:20 < petertodd> to delegate signing authority after the fact sign a signature on the script 0 IF ENDIF CHECKSIG 17:21 < petertodd> (remember that CODESEPARATORS are removed by SignatureHash()) 17:22 < petertodd> oops, I mean: CHECKSIGVERIFY 0 IF ENDIF CHECKSIG 17:22 < petertodd> anyway, to finally spend it, create another signature with pubkey2 signing the script CHECKSIGVERIFY 0 IF ENDIF CHECKSIG again, and finally spend it with the scriptSig: CODESEPARATOR 0 IF 17:24 < petertodd> after concatenation the script: CODESEPARATOR 0 IF CODESEPARATOR ENDIF CHECKSIG is evaluated, the inner signature satisfies, and the outer signature is satisfied only if the scriptPubKey was essentially changed after the fact to also require the inner, second, pubkey2 to be satisfied 17:26 < petertodd> a nice use-case would, forinstance, have been to have a signing robot be able to create signatures offline for a given txout with SIGHASH_SINGLE such that you had a spending limit enforced, and exactly who was then allowed to spend the funds - say a department of a company - could be picked after the fact without re-spending the txout 17:33 < petertodd> gmaxwell: re: script validation state, a good model would be to have the tx input to EvalScript() essentially be a CMerkleTx, and the prevout scriptPubKey be the prevout CTxOut (*maybe* the prevout tx itself... bit dubious there...) --=20 'peter'[:-1]@petertodd.org 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVMundXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZTc5ODBhYWI5YzA5NmM0NmU3ZjM0YzQzYTY2MWM1Y2Iy ZWE3MTUyNWViYjhhZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyQWgf/VgRIK72KnpkHX5LZ83rPuxDI snxbhHDgeuyRdw5zWI7EFgNGRhBTktxhinuSfjbh2W3SNcyLOtF4DtyQQ7BY8vio ZExGU1MjEBltbTiZLqUUy/NHG2nH0t4JeuAgMOxSn4AW73Lrqj60KIyzWngUstU8 z8W4baITu2XZATvMXC7kZq0Y4WqGck/hlcicoKywGk5FN70cRlyhEDtBZdLzESYu Rl6+gzHj+/UaPdsx97rJHlf9aY9w+VnbiHSB0gK+9awgxZeNebFPXxCOmtIJfgyI pvl0Y/aw4NCOdan45F/lA5NWEOULkVJrYuS78gaBTmLQqDX1M3+/30g4BZQ4CA== =WMSQ -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--