path: root/33/25ad494320f119fbedced30ce5ae35e3df6e1a

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 <hozer@grid.coop>) 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 <hozer@hozed.org>
To: Jeff Garzik <jgarzik@bitpay.com>
Message-ID: <20150301174414.GU14804@nl.grid.coop>
References: <20150212064719.GA6563@savin.petertodd.org>
	<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
	<CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
	<20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com>
	<20150219085604.GT14804@nl.grid.coop>
	<CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
	<CAOG=w-uJFobZtkd8OoPnOJC3uqCOwjsqyfNWJTg3j3sJQn+wXQ@mail.gmail.com>
	<CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
In-Reply-To: <CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
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 <bitcoin-development@lists.sourceforge.net>,
	Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@blockstream.io>
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: <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: 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 <mark@friedenbach.org=
> 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" <jtimon@jtimon.cc> 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 <hozer@hozed.org> =
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