Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Btc Drak <btcdrak@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike@plan99.net> wrote:

> 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.
>

I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.

Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.

[-- Attachment #2: Type: text/html, Size: 3529 bytes --]