From: Mike Hearn <mike@plan99•net>
To: Alex Mizrahi <alex.mizrahi@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Thu, 12 Feb 2015 16:15:00 +0100 [thread overview]
Message-ID: <CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com> (raw)
In-Reply-To: <CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]
>
> So anyway, in my opinion, it is actually great that Bitcoin is still
> relatively small: we have an opportunity to analyze and improve things.
> But you seem to be hostile to people who do that (and who do not share
> your opinion), which is kinda uncool.
>
To clarify once more, I'm all for people researching and building ways to
make Bitcoin better and safer. And debating that here is cool too.
The "replace by fee" patches don't do this; as you said yourself the whole
scorched earth thing makes no sense. It's not a solution to anything and
it's important people realise that.
Perhaps it will help if I spell out why this whole approach won't work (but
can easily damage bitcoin a lot along the way).
Normal Bitcoin nodes pick which transaction to put into a block by simply
selecting whichever they saw arrive first, as determined by the arrival
order of network packets. This rule is simple and has multiple advantages
for people using Bitcoin to buy and sell things.
Replace-by-fee changes this so nodes select whichever chain of unconfirmed
transactions pays the highest miner fees. Up until the point that a
transaction appears in a block, anyone can broadcast a double spend (or a
spend of an unconfirmed transaction) which pays higher fees than before,
causing that tx chain to become the candidate for chain inclusion.
Peter argues that this is stable and makes unconfirmed transactions safe
because a fraudster can buy something, walk out of the shop, and broadcast
a double spend with a higher fee. But then the merchant can re-spend the
original payment back to themselves with an *even* higher fee than that.
Then the fraudster can re-spend their double spend with an *even* higher
fee than that, and so on back and forth, until *all* the money has been
spent to miner fees. Thus the merchant loses their goods but the fraudster
has still "paid" in some sense because they don't get the money either.
This argument makes no sense for two reasons.
The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.
The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
*but* so is the little company who lost everything. Whoever can outspend
the other wins.
We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".
[-- Attachment #2: Type: text/html, Size: 4012 bytes --]
next prev parent reply other threads:[~2015-02-12 15:15 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 [this message]
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
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='CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=alex.mizrahi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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