Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1U5Thf-0004mU-Vt for bitcoin-development@lists.sourceforge.net; Wed, 13 Feb 2013 04:12:16 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1U5Thd-0000jI-VT for bitcoin-development@lists.sourceforge.net; Wed, 13 Feb 2013 04:12:15 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r1D4C565036582; Wed, 13 Feb 2013 04:12: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 r1D4C0HX013943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 04:12:03 GMT Date: Tue, 12 Feb 2013 23:12:09 -0500 From: Peter Todd To: Gavin Andresen Message-ID: <20130213041209.GA28202@savin> References: <20130212151108.GA639@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 85bb41ce-7593-11e2-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwEUHlAWAgsB AmUbW1BeUV97WWA7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAGgF dR5mOhlzdAxCezBy ZUVlXT5TWRYocUcu F1NTEGQFeGZhPWIC AkULch5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4xMBVu Dx0HBSk+VVYOXSQr MyQ7IH0RDV1ZO0M+ eXwZbmg1DyIoLEVQ GFsvSCpQPVoAQSVj EAVBRUMYHDRXRSoU Hg0vPwNTagAA X-Authentic-SMTP: 61633532353630.1023: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: 1U5Thd-0000jI-VT Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [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: Wed, 13 Feb 2013 04:12:16 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2013 at 12:42:37PM -0500, Gavin Andresen wrote: > On Tue, Feb 12, 2013 at 10:11 AM, Peter Todd wrote: >=20 > > .... Again, thoughts? > > >=20 > First: I really like the fidelity bond concept, and want to see it happen. >=20 > RE: OP_RETURN : I've got a knee-jerk opposition to the OP_RETURN opcode, > because it was the cause of the nastiest bug ever Bitcoin history. So I'd So what exactly was the OP_RETURN bug anyway? I know it has something to do with not executing the scriptSig and scriptPubKey separately (https://bitcointalk.org/index.php?topic=3D58579.msg691432#msg691432) but commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged. > be more comfortable using either OP_FALSE or OP_INVALIDOPCODE for the > "provably unspendable" transaction. You know, come to think of it, OP_FALSE doesn't get used by standard transactions either, and it's behavior is a little odd in how it does push to the stack. So lets make the standard OP_INVALIDOPCODE, specifically 0xFF, and put it at the start of the scriptPubKey. > RE: anyone-can-spend transactions: Thinking aloud... I wonder if we might > inadvertently cause "spend storms" on the network; if suddenly there are = 11 > BTC sitting in an anybody-can-spend txout, I could imagine EVERYBODY on t= he > network trying to race each other to spend it (maybe assuming that there > are a few miners on old versions of the software who are too dumb to claim > it for themselves). That's a good point. It would encourage efforts to identify as many Bitcoin nodes as possible, particularly miners, and I don't think we really want to incentivise that. It's not a problem unique to this proposal - compromised private keys and SIGHASH_NONE (1) - but fidelity bonds will give people incentive to develop the infrastructure to exploit it. 1) Speaking of, maybe I'm missing something, but if I have a transaction with one or more txin's and sign every signature with SIGHASH_SINGLE, what stops an attacker from adding their own txout at the end and diverting the mining fee to themselves? Having said that, if we both make empty scriptPubKeys standard, and add code so that miners will always try to spend the outputs for themselves at the same time, we can get rid of this problem by removing the incentive. It would also still make non-fidelity-bond uses viable as well. Of course, if you want to go down that path, we might as well add code to detect and spend fidelity bonds too, and make the publish transactions IsStandard(). Basically for every script in a confirmed block check if any pushdata op happens to be a script that we would be willing to add to the mempool at nBlockHeight + N. (assuming current utxo set) If so, add it to the mempool now. N should be at least 100 blocks I think for the same reason that coinbase tx's take 100 blocks to spend. The limit also means the size of the mempool can't get larger than MAX_BLOCK_SIZE * N. Meanwhile IsStandard() would allow the scriptPubKey OP_INVALIDOPCODE P2SH already treats data as scripts, so treating data as entire tx's isn't that big of a leap. Also since the txout is unspendable, the Satoshi criteria that block-reorgs should not make child tx's vanish is still met. (though tx mutability sort of breaks this anyway) We would however open quite a few cans of worms: 1) We just made non-final !IsStandard() for a reason. 2) What if there are transactions already in the mempool that spend the txin's of the sacrifice? If we ignore them, we've just created another way to double-spend unconfirmed transactions. On the other hand, if we don't ignore them, we've just created a way to give us a chance to mine the sacrifice for ourselves. Personally I'm with you Gavin and think assuming miners are greedy is best, but lets just say I probably shouldn't write an implementation with a function named IsTxOutStealable()? 2a) What if multiple sacrifice publications exist spending the same txin's? We should have deterministic behavior and mine the most valuable one. If you don't do that, the attackers effective hashpower is increased. (and thus the true sacrifice value of the bond decreases) 2b) ...but this is actually an annoying optmization problem. You could create a whole bunch of sacrifices, each spending two or more inputs, one small, one large. Then create one large sacrifice, that spends all the *small* inputs. If the value of the large sacrifice is less than the combined totals of the smaller sacrifices, you should be mining the small ones rather than the large for maximum return. 3) With the 10KB limit on scripts, a naive IsStandard() could wind up recursing about 200 times; we probably should say recursive publish transactions are non-standard. 3b) ...on the other hand, if they are non-standard, implementations that use fidelity bonds better make sure they don't accept such monsters. We probably should just define one standard sacrifice tx form with one txin, one txout, and a standard P2SH scriptPubKey, but miners can still do their own thing and cause problems in determining the true value sacrificed if they don't get the optimization problem right. Fidelity bonds needs a lot more thought, and a testnet implementation... --=20 'peter'[:-1]@petertodd.org --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRGxKZAAoJEH+rEUJn5PoE6MYH/0StlBdDOZCRTliX9dUJ547a LgM0xNIx509rciRodc4muVO3Sjw5dylpo0meyA0WMfVHSeQV9fikCJEybnCBw6YE sVn8RiELW88EWJgXK0ljtdUdHFG4UqjOqgPLo+z+7pNdxe+eIxQgp9G7mPDBTpgq 15QtaeuSehro34Zfk69DDHoM2ZpRbD3eX+CEYacD/Ay+9LsIxaAVjoU65sGZRNpC SnaOW9PXGKLUD1eMiTYXsN1LFWMfvpD/BWVyzesJuu6anYhmBqkeRmuvNBErMOOS Pz4l8L81SZKpa+uNlFlx0pcpbjwlso5FQ68NeYq0NcLGuSAq2rNp5earlsqLI/I= =cdcH -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--