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 1WRRHe-0005o1-TY for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 19:08:42 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.100 as permitted sender) client-ip=62.13.148.100; envelope-from=pete@petertodd.org; helo=outmail148100.authsmtp.co.uk; Received: from outmail148100.authsmtp.co.uk ([62.13.148.100]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WRRHd-0001OZ-N4 for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 19:08:42 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2MJ81FT047219; Sat, 22 Mar 2014 19:08:01 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 s2MJ7uU2023704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 19:07:58 GMT Date: Sat, 22 Mar 2014 15:08:25 -0400 From: Peter Todd To: Troy Benjegerdes Message-ID: <20140322190825.GB6047@savin> References: <20140322084702.GA13436@savin> <20140322150836.GG3180@nl.grid.coop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: <20140322150836.GG3180@nl.grid.coop> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 4850dce2-b1f5-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAAUFVQGAgsB AmIbWl1eUFp7XGs7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2F7 AVt7UBlwdAJGfDBx ZEJiWD5fVEF6IRUo QFMGFDsDeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4rFzgw QxEEEn0qHEsIXW06 Ixs+Nl8bGg4eKEw5 PFU8XVYJexEVEG8W EkRHDSNVKlVJTC0t Fg5cRlMFWCZMWjtR BwZgPB5BSjBVRyBc CQ5eUxwJByJDX25S RS5ZWyYgSVI4Ykwn P0zM 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: 1WRRHd-0001OZ-N4 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee 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: Sat, 22 Mar 2014 19:08:43 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote: > On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: > > There's been a lot of recent hoopla over proof-of-publication, with the > > OP_RETURN length getting reduced to a rather useless 40 bytes at > > the last minute prior to the 0.9 release. Secondly I noticed a > > overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken > > into account, making it possible to broadcast unminable transactions and > > bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG > > outputs given that the sigops limit and the way they use up a fixed 20 > > sigops per op makes them hard to do fee calculations for. They also make > > it easy to bloat the UTXO set, potentially a bad thing. This would of > > course require things using them to change. Currently that's just > > Counterparty, so I gave them the heads up in my email. >=20 > I've spend some time looking at the Datacoin code, and I've come to the= =20 > conclusion the next copycatcoin I release will have an explicit 'data'=20 > field with something like 169 bytes (a bakers dozen squared), which will= =20 > add 1 byte to each transaction if unused, and provide a small, but usable > data field for proof of publication. As a new coin, I can also do a > hardfork that increases the data size limit much easier if there is a > compelling reason to make it bigger. >=20 > I think this will prove to be a much more reliable infrastructure for=20 > proof of publication than various hacks to overcome 40 byte limits with > Bitcoin. >=20 > I am disclosing this here so the bitcoin 1% has plenty of time to evaluate > the market risk they face from the 40 byte limit, and put some pressure to > implement some of the alternatives Todd proposes. Lol! Granted, I guess I should "disclose" that I'm working on tree chains, which just improve the scalability of blockchains directly. I'm think tree-chains could be implemented as a soft-fork; if applied to Bitcoin the datacoin 1% might face market risk. :P --=20 'peter'[:-1]@petertodd.org 0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91 --wq9mPyueHGvFACwf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTLd+lXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDBiYmNjNTMxZDQ4YmVhOGQ2NzU5N2UyNzViNWFiY2ZmMThl MThmNDYyNjY3MjNlOTEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuR+wgAjq/dl/mF245u3CEvN6zbeuKb sOZC/wSb5p2T2az0nXPHpkYsThiCTlCgczNo63bIRHfsHhxvILOunFpe7ZO9pTuL XOvjOoagXi1RSfQCQZTOG9bCVKPiDXIy8LCbZ95VukmWjVHoikSbOTfzNs2qQJPR q7XUj3ashnbSKvEsVc1B9DVRVmnpdLWAshxIXa5xp015WVDDMaIOI3+W4LxbkXg3 pD1PqsnjW/S66Y0LPIOu+MdPfJKKHQoIsnMAnarNw9kbuaOOM5VNAYnIpH5MbPEc 09OAzIAh3sFENRsuHyGj61cbzoTY4naE+Bwj5wlNsKu9t1rB+AIH7bQn8D1rIw== =7rM+ -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf--