public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Tom Harding <tomh@thinlink.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Date: Sun, 22 Feb 2015 12:12:22 -0500	[thread overview]
Message-ID: <20150222171222.GA30816@savin.petertodd.org> (raw)
In-Reply-To: <54EA0571.4050107@thinlink.com>

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

On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote:
> On 2/11/2015 10:47 PM, Peter Todd wrote:
> >My replace-by-fee patch is now available for the v0.10.0rc4 release:
> >
> >     https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
> >
> 
> This patch immediately simplifies successful double-spends of
> unconfirmed transactions.  But the idea that it "gives a path to
> making zeroconf transactions economically secure" is quite dubious.
> 
> * You don't provide sufficient means to detect and relay
> double-spends, which is necessary to trigger a scorched-earth
> reaction.  Not all double-spends will conform to your replacement
> rules.

No, OTOH if they don't then the situation is no difference from what we
have now, and replace-by-fee does no harm. Meanwhile, relaying of bare
double-spend signatures can be implemented in the future, as I suggested
last year for your/Andresen's double-spend relaying patch.

Did you notice the even more obvious way to defeat ANYONECANPAY scorched
earth with that patch?

>   * Maybe XT nodes would help to overcome this.  But meanwhile, in
> the ANYONECANPAY design, Bob's replacement is a triple-spend.  Even
> XT nodes won't relay it.

So? RBF nodes will.

> * It's unclear when, if ever, any senders/receivers will actually
> try to use scorched-earth as a double-spend deterrent.

I suspect many won't, because few people need to rely on unconfirmed
transactions anyway.

> Also, this patch significantly weakens DoS protections:
> 
> * It removes the early conflict check, making all conflict
> processing more expensive

If you're going to consider replacement, conflict processing will
definitely be more expensive. :)

An actual DoS attacker would do their DoS attack in a way where conflict
processing has nothing to do with it, so this change does no actual
harm.

>   * There is no attempt to protect against the same transaction
> being continually replaced with the fee bumped by a minimal amount.

What exact git commit were you looking at? I did have an early one that
did have a bug along those lines, now fixed.

The current version ensures every replacement pays at least as much
additional fees as would normally cost to broadcast that much data on
the network, and additionally requires the fees/KB to always increase;
under all circumstances it should be no more of a DoS threat than
low-fee transactions are otherwise. I'd like to know if there is a flaw
in that code however!

-- 
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2015-02-22 17:12 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 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
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 [this message]
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=20150222171222.GA30816@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=tomh@thinlink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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