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; 
Date: Sat, 22 Mar 2014 15:34:35 -0400
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@monetize.io>
Message-ID: <20140322193435.GC6047@savin>
References: <20140322084702.GA13436@savin>
	<CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7"
Content-Disposition: inline
In-Reply-To: <CAC1+kJNh=7yhmAdFHFv9VBJOOMhen6nwr=U9peG2J_7EovPqxA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Handling miner adoption gracefully for
 embedded consensus systems via double-spending/replace-by-fee
Precedence: list


--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 <pete@petertodd.org> 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.
>=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--