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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRRgP-0006jU-GK for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 19:34:17 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.108 as permitted sender) client-ip=62.13.148.108; envelope-from=pete@petertodd.org; helo=outmail148108.authsmtp.net; Received: from outmail148108.authsmtp.net ([62.13.148.108]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WRRgO-00025q-9A for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 19:34:17 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2MJYAOt013724; Sat, 22 Mar 2014 19:34:10 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 s2MJY6cq004931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 19:34:09 GMT Date: Sat, 22 Mar 2014 15:34:35 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20140322193435.GC6047@savin> References: <20140322084702.GA13436@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: f08f9f5f-b1f8-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAAUFVQGAgsB AmIbWl1eU1l7WWo7 bAxPbAVDY01GQQRq WVdMSlVNFUsrA2F7 bxhNExlycwxFeTBy ZURgWD4NXEwsfBB4 FFMGFDsOeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4rFzgw QxEEEn0qHEsIXW06 Ixs+Nl8bGg4eKEw5 PFU8XVYJexEVEG8W EkRHDSNVKlVJTC0t Fg5cRlMFWCZMWjtR BwZgPB5BSjBVRyBc CQ5eUxwJByJDX25S RS5ZWyYgSVI4Ykwn P0zM X-Authentic-SMTP: 61633532353630.1024: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: 1WRRgO-00025q-9A 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:34:17 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Tim=F3n wrote: > On 3/22/14, 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. >=20 >=20 > I'm not against about miners accepting transactions that have longer > data in non-utxo polluting OP_RETURN than whatever is specified as > standard by the reference implementation, maybe it should be risen in > standard but I think it was assumed that the most common case would be > to include the root hash of some "merklized" structure. > My only argument against non-validated proof of publication is that in > the long run it will be very expensive since they will have to compete > with transactions that actually use the utxo, a feature that is more > valuable. But that's mostly speculation and doesn't imply the need for Well remember that my thinking re: UTXO is that we need to move to a system like TXO commitments where storing the entirety of the UTXO set for all eternity is *not* required. Of course, that doesn't necessarily mean you can't have the advantages of UTXO commitments, but they need to be limited in some reasonable way so that long-term storage requirements do not grow without bound unreasonably. For example, having TXO commitments with a bounded size committed UTXO set seems reasonable; old UTXO's can be dropped from the bounded sized set, but can still be spent via the underlying TXO commitment mechanism. > any action against it. I would strongly opposed to against a > limitation on OP_RETURN at the protocol level (other than the block > size limit itself, that is) and wouldn't mind if they're removed from > isStandard. I didn't payed much attention to that and honestly I don't > care enough. > > Maybe this encourages miners to adopt their own policies, which could > be good for things like replace-by-fee, the rational policy for > miners, which I strongly support (combined with game theory can > provide "instant" transactions as you pointed out in another thread). >=20 > Maybe the right approach to keep improving modularity and implement > different and configurable mining policies. Like I said the real issue is making it easy to get those !IsStandard() transactions to the miners who are interested in them. The service bit flag I proposed + preferential peering - reserve, say, 50% of your peering slots for nodes advertising non-std tx relaying - is simple enough, but it is vulnerable to sybil attacks if done naively. > > All these methods have some overhead compared to just using OP_RETURN > > and thus cost more. >=20 > I thought the consensus was that op_return was the right way to put > non-validated data in the chain, but limiting it in standard policies > doesn't seem consistent with that. Right, but there's also a lot of the community who thinks proof-of-publication applications are bad and should be discouraged. I argued before that the way OP_RETURN was being deployed didn't actually give any reason to use it vs. other data encoding methods. Unfortunately underlying all this is a real ignorance about how Bitcoin actually works and what proof-of-publication actually is: 14-03-20.log:12:47 < gavinandresen> jgarzik: RE: mastercoin/OP_RETURN: what's the current thinking on Best Way To Do It? Seems if I was to do it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the real data from a DHT or website (or any-of-several websites). Blockchain as reference ledger, not as data storage. > Peter Todd, I don't think you're being responsible or wise saying > nonsense like "merged mined chains can be attacked for free" and I > suggest that you prove your claims by attacking namecoin "for free", > please, enlighten us, how that's done? I think we're just going to have to agree to disagree on our interpretations of the economics with regard to attacking merge-mined chains. Myself, I'm very, very wary of systems that have poor security against economically irrational attackers regardless of how good the security is, in theory, against economically rational ones. Again, what it comes down to in the end is that when I'm advising Mastercoin, Counterparty, Colored Coins, etc. on how they should design their systems I know that if they do proof-of-publication on the Bitcoin blockchain, it may cost a bit more money than possible alternatives per transaction, but the security is very well understood and robust. Fact is, these applications can certainly afford to pay the higher transaction fees - they're far from the least economically valuable use of Blockchain space. Meanwhile the alternatives have, at best, much more dubious security properties and at worse no security at all. (announce/commit sacrifices is a great example of this, and very easy to understand) --=20 'peter'[:-1]@petertodd.org 0000000000000000bbcc531d48bea8d67597e275b5abcff18e18f46266723e91 --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTLeXHXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAyZmQ5NDk3NzA1MjRlZWE1NDQ0NmFkYjcwNjAzYTkwYTRj NDkzZDM0NWY4OTBlMDQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfskagf/ZI8FdcBzDQHJIcN0GaJ0nW4F 4/Zcgjf2vVmW3VyeXcL3U1YTx/MuYx2aUS2a8RAiezPXwpXZe25ao3MEacPcAhds zLNkFdpqNVCJw2qxlgW44Y6g/E2RmvWDxQBG2g19gtzomGSZ0SpR7D8+9SS4wu+e 9jMapOsbGxha0HCLjAyNV9jmXqINLhBsY2KLuDGsuphvF2T4wYWIwescNe+XMuzf KfUmmSjIScwLUXvIxDZneHaoGKow9jhToYh3fxKkTjn1IuI51iaEsExiGFyGJ4HD P9UR7LT93dvGcg2JjsI1jcVOF6AJubCTnAV/oOKyhJA6zy5WrWDpne+vFlvzHw== =/PQK -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7--