diff options
| author | Peter Todd <pete@petertodd.org> | 2013-02-12 10:11:08 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-02-12 15:11:17 +0000 |
| commit | 91a82825a2554124ded96ffcd8ae9e5a40c016d1 (patch) | |
| tree | 0395fb5f0b30f3898f5762e307648659d2eb5003 | |
| parent | d39fd106fbf1e9693d613e83722c236ba882f9a8 (diff) | |
| download | pi-bitcoindev-91a82825a2554124ded96ffcd8ae9e5a40c016d1.tar.gz pi-bitcoindev-91a82825a2554124ded96ffcd8ae9e5a40c016d1.zip | |
[Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts
| -rw-r--r-- | de/6fe80f4a19ffeaf4296c077859faaa9229e241 | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/de/6fe80f4a19ffeaf4296c077859faaa9229e241 b/de/6fe80f4a19ffeaf4296c077859faaa9229e241 new file mode 100644 index 000000000..1a6115e0c --- /dev/null +++ b/de/6fe80f4a19ffeaf4296c077859faaa9229e241 @@ -0,0 +1,170 @@ +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 <pete@petertodd.org>) 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 <bitcoin-development@lists.sourceforge.net>; + 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 <bitcoin-development@lists.sourceforge.net>; + Tue, 12 Feb 2013 15:11:03 GMT +Date: Tue, 12 Feb 2013 10:11:08 -0500 +From: Peter Todd <pete@petertodd.org> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <serialized tx> <pubkey> 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 <serialized tx> 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/-- + + |