diff options
| author | Peter Todd <pete@petertodd.org> | 2014-03-22 15:34:35 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-22 19:34:17 +0000 |
| commit | e0a19255f2154a2c3a32a61e0d69ae05ebcb719c (patch) | |
| tree | e4cd463019e82fbd4fc6d0557d411aecb9e104eb | |
| parent | a669ff8a6755a79ba7ac00334c7411cecba4ec44 (diff) | |
| download | pi-bitcoindev-e0a19255f2154a2c3a32a61e0d69ae05ebcb719c.tar.gz pi-bitcoindev-e0a19255f2154a2c3a32a61e0d69ae05ebcb719c.zip | |
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
| -rw-r--r-- | f8/f1827fcfbb4a63a8c51d67804a1c10668cf66c | 196 |
1 files changed, 196 insertions, 0 deletions
diff --git a/f8/f1827fcfbb4a63a8c51d67804a1c10668cf66c b/f8/f1827fcfbb4a63a8c51d67804a1c10668cf66c new file mode 100644 index 000000000..6b982a458 --- /dev/null +++ b/f8/f1827fcfbb4a63a8c51d67804a1c10668cf66c @@ -0,0 +1,196 @@ +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 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 <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) +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: <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: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 <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-- + + |