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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5HVt-0004xU-5c for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 15:11:17 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.101 as permitted sender) client-ip=62.13.149.101; envelope-from=pete@petertodd.org; helo=outmail149101.authsmtp.com; Received: from outmail149101.authsmtp.com ([62.13.149.101]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U5HVo-0006IZ-KE for bitcoin-development@lists.sourceforge.net; Tue, 12 Feb 2013 15:11:17 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r1CFB5Fd075293 for ; Tue, 12 Feb 2013 15:11:05 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r1CFB1Tw068709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 12 Feb 2013 15:11:03 GMT Date: Tue, 12 Feb 2013 10:11:08 -0500 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20130212151108.GA639@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 6b22097c-7526-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1 Jh0bXVBSFQZ4ABkL Bx8UUh08cANYeX5u ZEFqQHFbVVt/fUFi QwAWFB5wF2YEL2AZ WEdYfk1VcAJPfFFD OFJ9VHoKMngAY3hm WlZqMmp0NGkOI2EN GltQfApNHh5UF2cq fT4pT30iGFUZVm0o JAYnMkIkAUwyP1Qp eVInVRo/CygoJzFj JWcFDihDb1wIXSkq CwwSQEgFCDBbTS5W BhBgPg9PHyBJMgAA X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1U5HVo-0006IZ-KE Subject: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts 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: Tue, 12 Feb 2013 15:11:17 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In my fidelity bond protocol (1) I'm proposing the use of two possible new features: The first is the use of OP_RETURN at the end of a scriptPubKey to designate that the txout can be immediately pruned as it is obviously unspendable. My use-case is the publish part of the two-step publish-sacrifice protocol. I specifically want to use OP_RETURN rather than a spendable scriptPubKey like OP_CHECKSIG so that implementors can not get lazy and fail to actually write the code to spend the non-standard outputs created, thus polluting the UTXO set. Simply using by itself as the scriptPubKey - spendable with an empty scriptSig - is another possiblity, but I suspect no-one will want to spend the tx fees to clean up those txouts; note how long it took for someone to bother doing that with p2pools share chain hash txout, and the effort(2) seems to have been a one-time experiment. Of course, P2Pool itself could use this mechanism too. OP_RETURN marks the script as invalid upon execution, and since a script is invalid if an OP_IF or OP_ELSE is not terminated with OP_ENDIF it is guaranteed to execute. (there is no op-code that marks a script as valid and returns immediately) OP_FALSE is another possibility too; I don't see clear advantages for one or the other modulo OP_FALSE's more intuitive name. Finally OP_VERIF and OP_VERNOTIF say that "Transaction is invalid even when occuring in an unexecuted OP_IF branch" on the wiki, although a look at EvalScript() leaves me less than convinced this is true. More to the point, the mechanism should be something that is as unlikely as possible to have different behavior in alternate implementations. (remember that often only valid transactions are put in unittests by lazy implementors) OP_RETURN doesn't need any special support in the reference client yet nor am I suggesting to make it a standard transaction type, but I would like some feedback on if the idea itself is reasonable. The second idea is the use of an empty scriptPubKey to create trivially spendable outputs; provide the the scriptKey OP_TRUE or similar. For fidelity bonds the advantage is to create a mechanism where even non-miners have a chance at taking the funds sacrificed, and thus increase the incentive to scan the blockchain for sacrifices and makes it more likely for the sacrifice to be a true sacrifice of value. An additional advantage is you avoid having to provide the txin to prove the value of the mining fee. The advantage over just using a pubkey with a known secret key is that the transaction size is shorter; remember that the sacrifice transaction has to be published as serialized data in a prior transaction. In the future another use would be as a way of multiple parties to collectively sign an assurance contract(3) donating to miners. This is effectively a mining fee because miners who chose to include the transaction can always chose to include an additional transfer from the txout to a scriptPubKey only they can spend. For the purpose of fidelity bonds ideally an empty scriptPubKey spent by the scriptSig OP_TRUE would be made a standard transaction type to make collecting the funds as easy as possible until miners start doing so themselves. Having it a standard transaction type would also make it easier for miners to implement the code to do this themselves; in particular this discourages them from just allowing all non-standard transactions. The main disadvantage I see is that it makes it easier for people with buggy custom transaction code to accidentally lose their funds. Again, thoughts? 1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md 2) See the transactions associated with 1HfA1KHC7bT1hnPPCjpj9CB4koLM4Hz8Va 3) https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts --=20 'peter'[:-1]@petertodd.org --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRGluMAAoJEH+rEUJn5PoEjEoIAIv7FbF1j2jcxBck6lRTyM+r KgyQhx0MKRGdYO+8mWFbFedNLlY1STb+RdVTo16DkF3D4TxwDz85JgB73uqVx5eV OXCgSQ4dAQMl8smU/LAZnSq5Ll/OfeZ7APilDH2vFraFmJFBwZ4giMUaILB2Jt5Y p8d916muZEJgAVgGDwMaesmvQVnBqG+4GZNGt/06wmX48dDMxlGeu3j64TfsuHnT YerPlBXO3IVJUiHCccl7w4sqnbK6WGVImrMBwo2tyfIMDc4pMNkzsz+UsJHoEO2D uMTwFQDpn5xQp0Vqbgzd49ozOWP7x3GiRA1smTvCY8oZ/t7B1r5ksZDKuy/ncpg= =mvBr -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--