From: Troy Benjegerdes <hozer@hozed•org>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: "Bitcoin Development" <bitcoin-development@lists•sourceforge.net>,
"Jorge Timón" <jtimon@blockstream•io>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Sun, 1 Mar 2015 11:44:14 -0600 [thread overview]
Message-ID: <20150301174414.GU14804@nl.grid.coop> (raw)
In-Reply-To: <CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
Bitcoin was/is a disruptive technology for credit card payment processors,
and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment
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 that
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 choose
whichever policy works best for them?
Otherwise, I think the only way to make 'first-seen' work is by adding
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.
>
> All payment processors AFAIK process transactions through some scoring
> system, then accept 0-conf transactions for payments.
>
> 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"
>
> 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.
>
>
>
>
>
>
> 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ón" <jtimon@jtimon•cc> wrote:
> >>
> >> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> >> 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_hunt)
> >> 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-fee
> >> is purely part of a node's policy, not part of consensus.
> >> >From the whitepaper, 0 conf transactions being secure by the good will
> >> 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 fee
> >> 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 policies
> >> 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 would
> >> 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 undo
> >> >> > 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 making
> >> >> 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 motivated
> >> > 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 brittle.
> >> >
> >> > Most applications, in particular paying someone you already trust, are
> >> > quite
> >> > happy running on reversible systems, and in some cases more reliable 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 transparency. 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 not
> >> > explicitly
> >> > extend that a little in a way that senders and receivers have a choice
> >> > to
> >> > use it, or not?
> >> >
> >> >
> >> > [1]
> >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> > 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=190641631&iu=/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 Dashboards
> >> 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=190641631&iu=/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 Dashboards
> > 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=190641631&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> 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=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed•org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
next prev parent reply other threads:[~2015-03-01 17:44 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 6:47 Peter Todd
2015-02-12 7:23 ` Tamas Blummer
2015-02-12 7:45 ` Peter Todd
2015-02-12 8:27 ` Tamas Blummer
2015-02-12 8:49 ` Peter Todd
2015-02-12 9:01 ` Tamas Blummer
2015-02-15 20:51 ` Troy Benjegerdes
2015-02-12 8:16 ` Alex Mizrahi
2015-02-12 11:58 ` Mike Hearn
2015-02-12 12:23 ` Natanael
2015-02-12 12:49 ` Mike Hearn
2015-02-12 13:02 ` Natanael
2015-02-12 13:44 ` Mike Hearn
2015-02-12 14:36 ` Natanael
2015-02-12 14:53 ` Mike Hearn
2015-02-12 15:20 ` Natanael
2015-02-12 15:30 ` Justus Ranvier
2015-02-12 13:36 ` Oleg Andreev
2015-02-12 12:52 ` Alex Mizrahi
2015-02-12 13:18 ` Mike Hearn
2015-02-12 13:45 ` Alex Mizrahi
2015-02-12 13:52 ` Mike Hearn
2015-02-12 14:04 ` Tamas Blummer
2015-02-12 14:16 ` Mike Hearn
2015-02-12 14:25 ` Tamas Blummer
2015-02-12 23:08 ` Tom Harding
2015-02-12 14:32 ` Alex Mizrahi
2015-02-12 15:15 ` Mike Hearn
2015-02-12 15:32 ` Natanael
2015-02-12 15:42 ` Mike Hearn
2015-02-12 15:54 ` Natanael
2015-02-12 16:57 ` Btc Drak
2015-02-12 17:24 ` Oleg Andreev
2015-02-12 18:11 ` Justus Ranvier
2015-02-12 18:37 ` Allen Piscitello
2015-02-12 19:15 ` Alan Reiner
2015-02-12 19:34 ` Justus Ranvier
2015-02-12 19:45 ` Peter Todd
2015-02-12 19:49 ` Justus Ranvier
2015-02-12 19:47 ` Allen Piscitello
2015-02-12 19:52 ` Justus Ranvier
2015-02-12 20:02 ` Natanael
2015-02-12 20:36 ` Allen Piscitello
2015-02-14 14:47 ` Ross Nicoll
2015-02-12 20:06 ` Peter Todd
2015-02-12 19:49 ` Gregory Maxwell
2015-02-12 20:18 ` Peter Todd
2015-02-13 11:34 ` Mike Hearn
2015-02-12 12:54 ` Tamas Blummer
2015-02-12 14:42 ` Alex Mizrahi
2015-02-12 15:27 ` Jeff Garzik
2015-02-15 21:25 ` Troy Benjegerdes
2015-02-15 21:40 ` Adam Gibson
2015-02-19 8:56 ` Troy Benjegerdes
2015-02-21 19:09 ` Jorge Timón
2015-02-21 20:30 ` Mark Friedenbach
2015-02-21 22:47 ` Jeff Garzik
2015-02-22 1:15 ` Peter Todd
2015-02-22 3:25 ` Jorge Timón
2015-02-22 4:06 ` Jeff Garzik
2015-02-22 11:41 ` Eric Lombrozo
2015-02-22 12:06 ` Eric Lombrozo
2015-02-22 13:41 ` Eric Lombrozo
2015-02-22 13:53 ` Peter Todd
2015-02-22 23:29 ` Eric Lombrozo
2015-02-24 1:11 ` Jeff Garzik
2015-03-01 17:59 ` Troy Benjegerdes
2015-03-01 19:05 ` Neil Fincham
2015-03-01 17:44 ` Troy Benjegerdes [this message]
2015-02-12 16:15 ` Lawrence Nahum
2015-02-12 18:14 ` Tom Harding
2015-02-12 21:40 ` Josh Lehan
2015-02-22 16:36 ` Tom Harding
2015-02-22 17:12 ` Peter Todd
2015-02-22 19:25 ` Tom Harding
2015-02-22 21:50 ` Peter Todd
2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd
2015-05-05 2:23 ` Kevin Greene
2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150301174414.GU14804@nl.grid.coop \
--to=hozer@hozed$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
--cc=jtimon@blockstream$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox