From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YS7ui-0000Pm-49 for bitcoin-development@lists.sourceforge.net; Sun, 01 Mar 2015 17:44:24 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YS7uf-0003lm-W7 for bitcoin-development@lists.sourceforge.net; Sun, 01 Mar 2015 17:44:24 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Sun, 01 Mar 2015 11:44:15 -0600 id 00000000000613CD.0000000054F34FEF.00002070 Date: Sun, 1 Mar 2015 11:44:14 -0600 From: Troy Benjegerdes To: Jeff Garzik Message-ID: <20150301174414.GU14804@nl.grid.coop> References: <20150212064719.GA6563@savin.petertodd.org> <20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com> <20150219085604.GT14804@nl.grid.coop> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.68.2 X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1YS7uf-0003lm-W7 Cc: Bitcoin Development , Jorge =?iso-8859-1?Q?Tim=F3n?= Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 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: Sun, 01 Mar 2015 17:44:24 -0000 Bitcoin was/is a disruptive technology for credit card payment processors= , and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payme= nt processors. I think whether you call it scorched earth is a bit more of a reflection = of whether you stand to make money, or lose money from the distruption. Personally, I think 'first-seen' is a dangerous scorched-earth policy tha= t only benefits the people who own the internet routers that determine what is seen first. But from the standpoint of consensus, can we at least agree that it's a *node policy* decision, and the market particpants should be free to choo= se whichever policy works best for them? Otherwise, I think the only way to make 'first-seen' work is by adding=20 a timestamp to CTransaction. On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote: > "scorched earth" refers to the _real world_ impact such policies would > have on present-day 0-conf usage within the bitcoin community. >=20 > All payment processors AFAIK process transactions through some scoring > system, then accept 0-conf transactions for payments. >=20 > This isn't some theoretical exercise. Like it or not many use > insecure 0-conf transactions for rapid payments. Deploying something > that makes 0-conf transactions unusable would have a wide, negative > impact on present day bitcoin payments, thus "scorched earth" >=20 > Without adequate decentralized solutions for instant payments, > deploying replace-by-fee widely would simply push instant transactions > even more into the realm of centralized, walled-garden services. >=20 >=20 >=20 >=20 >=20 >=20 > On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach wrote: > > Thank you Jorge for the contribution of the Stag Hunt terminology. It = is > > much better than a politically charged "scorched earth". > > > > On Feb 21, 2015 11:10 AM, "Jorge Tim=F3n" wrote: > >> > >> I agree "scorched hearth" is a really bad name for the 0 conf protoc= ol > >> based on game theory. I would have preferred "stag hunt" since that'= s > >> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hun= t) > >> but I like the protocol and I think it would be interesting to > >> integrate it in the payment protocol. > >> Even if that protocol didn't existed or didn't worked, replace-by-fe= e > >> is purely part of a node's policy, not part of consensus. > >> >From the whitepaper, 0 conf transactions being secure by the good w= ill > >> of miners was never an assumption, and it is clear to me that the > >> system cannot provide those guaranties based on such a weak scheme. = I > >> believe thinking otherwise is naive. > >> As to consider non-standard policies "an attack to bitcoin" because > >> "that's not how bitcoin used to work", then I guess minimum relay fe= e > >> policies can also be considered "an attack to bitcoin" on the same > >> grounds. > >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the > >> system, but I expect that most nodes will eventually move to policie= s > >> that are economically rational for miners such as replace-by-fee. > >> Not only I disagree this will be "the end of bitcoin" or "will push > >> the price of the btc miners are mining down", I believe it will be > >> something good for bitcoin. > >> Since this is apparently controversial I don't want to push for > >> replace-by-fee to become the new standard policy (something that wou= ld > >> make sense to me). But once the policy code is sufficiently modular = as > >> to support several policies I would like bitcoin core to have a > >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no > >> policy checks at all). > >> One step at a time I guess... > >> > >> > >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes = wrote: > >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > >> >> > >> >> > >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > >> >> > > >> >> > Most money/payment systems include some method to reverse or un= do > >> >> > payments made in error. In these systems, the longer settlement > >> >> > times you mention below are a feature, not a bug, and give more > >> >> > time for a human to react to errors and system failures. > >> >> > > >> >> > >> >> Settlement has to be final somewhere. That is the whole point of = it. > >> >> Transfer costs in current electronic payment systems are a direct > >> >> consequence of their non-finality. That's the point Satoshi was m= aking > >> >> in the introduction to the whitepaper: "With the possibility of > >> >> reversal, the need for trust spreads". > >> > > >> > The problem with that statement is I trust a merchant that I went = into > >> > a store and made a payment with personally more than I trust the > >> > firmware > >> > on my hard drive [1]. > >> > > >> > The attack surface of devices in your computer is huge. A motivate= d > >> > attacker > >> > just needs to get an intern into a company that makes some kind of > >> > component > >> > or system that's in your computer, cloud server, hardware wallet, = or > >> > what > >> > have you that has firmware capable of reading your private keys. > >> > > >> > With the possibility of mass trojaned hardware, if we are going to = trust > >> > the system, it must somehow allow reversal through a human-in-the-= loop. > >> > > >> >> There is nothing wrong with having reversible mechanisms built on = top > >> >> of Bitcoin, and indeed it makes sense for most activity to happen = at > >> >> those higher layers. It's easy to build things that way, but > >> >> impossible to build them the other way: you can't build a > >> >> non-reversible layer on top of a reversible layer. > >> > > >> > We built 'reliable' TCP on top of unreliable ethernet networks. My > >> > experience > >> > with networking was if you tried to guarantee message delivery at = the > >> > lowest > >> > level, the system got exceedingly complicated, expensive, and brit= tle. > >> > > >> > Most applications, in particular paying someone you already trust, = are > >> > quite > >> > happy running on reversible systems, and in some cases more reliab= le and > >> > lower risk. (carrying non-reversible cash is generally considered = risky) > >> > > >> > The problem is that if the base currency is assumed to be > >> > non-reversible, > >> > then it's brittle and becomes 'too big to fail'. > >> > > >> > Where the blockchain improves on everything else is in transparenc= y. If > >> > you > >> > reverse transactions a lot, it will be obvious from an analysis. I = would > >> > much > >> > rather deal with a known, predictable, and relatively continous > >> > transaction > >> > reversal rate (percentage) than have to deal with sudden failures = where > >> > some anonymous bad actor makes off with a fortune. > >> > > >> > We already have zero-conf double-spend transaction reversal, why n= ot > >> > explicitly > >> > extend that a little in a way that senders and receivers have a ch= oice > >> > to > >> > use it, or not? > >> > > >> > > >> > [1] > >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSK= BN0LK1QV20150216 > >> > > >> > > >> > ------------------------------------------------------------------= ------------ > >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > >> > from Actuate! Instantly Supercharge Your Business Reports and Dash= boards > >> > with Interactivity, Sharing, Native Excel Exports, App Integration = & > >> > more > >> > Get technology previously reserved for billion-dollar corporations= , FREE > >> > > >> > http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/41= 40/ostg.clktrk > >> > _______________________________________________ > >> > Bitcoin-development mailing list > >> > Bitcoin-development@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > >> > >> --------------------------------------------------------------------= ---------- > >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > >> from Actuate! Instantly Supercharge Your Business Reports and Dashbo= ards > >> with Interactivity, Sharing, Native Excel Exports, App Integration & = more > >> Get technology previously reserved for billion-dollar corporations, = FREE > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140= /ostg.clktrk > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > ---------------------------------------------------------------------= --------- > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboa= rds > > with Interactivity, Sharing, Native Excel Exports, App Integration & = more > > Get technology previously reserved for billion-dollar corporations, F= REE > > http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/= ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >=20 >=20 >=20 > --=20 > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ >=20 > -----------------------------------------------------------------------= ------- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboard= s > with Interactivity, Sharing, Native Excel Exports, App Integration & mo= re > Get technology previously reserved for billion-dollar corporations, FRE= E > http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/os= tg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --=20 -------------------------------------------------------------------------= --- Troy Benjegerdes 'da hozer' hozer@hozed.= org 7 elements earth::water::air::fire::mind::spirit::soul grid.c= oop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash