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 <pete@petertodd.org>) 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 <pete@petertodd.org>
To: Troy Benjegerdes <hozer@hozed.org>
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: <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: 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 <data> 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--