From: Peter Todd <pete@petertodd•org>
To: "Russell O'Connor" <roconnor@blockstream•io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Date: Thu, 1 Mar 2018 10:11:29 -0500 [thread overview]
Message-ID: <20180301151129.GA9373@fedora-23-dvm> (raw)
In-Reply-To: <CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd•org> wrote:
>
> >
> > Ah ok, I misunderstood and didn't realise you were talking about the case
> > where
> > Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> > case
> > is possible to solve without putting some kind of restriction on spending
> > unconfirmed outputs; with a restriction it's fairly simple to solve.
>
>
> When you say that you don't think it is possible to solve, do you mean that
> there is a specific problem with this proposal of replacing transactions
> when offered a new transaction whose fee rate exceeds the package fee rate
> of the original transaction (and ensuring that the fee increase covers the
> size of the transactions being ejected)? Is your concern only about the
> ability to computing and track the package fee rate for transactions within
> the mempool or is there some other issue you foresee?
I mean, I think in general solving this problem is probably not possible.
Basically, the fundamental problem is someone else has consumed network
bandwidth that should be paid for with fees. What you're trying to do is
replace a transaction without paying those fees, which is identical to what an
attacker is trying to do, and thus any such scheme will be as vulnerable to
attack as not having that protection in the first place.
...which does give you an out: maybe the attack isn't important enough to
matter. :)
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-03-01 15:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 15:52 Russell O'Connor
2018-02-12 17:30 ` rhavar
2018-02-12 22:58 ` Peter Todd
2018-02-12 23:19 ` Russell O'Connor
2018-02-12 23:42 ` Peter Todd
2018-02-12 23:46 ` Russell O'Connor
2018-02-14 14:08 ` Russell O'Connor
2018-02-14 14:16 ` Greg Sanders
2018-02-27 16:25 ` Russell O'Connor
2018-03-01 15:11 ` Peter Todd [this message]
2018-03-08 15:39 ` Russell O'Connor
2018-03-08 18:34 ` Peter Todd
2018-03-08 20:07 ` Russell O'Connor
2018-03-09 18:28 ` Peter Todd
2018-03-09 18:40 ` rhavar
2018-02-12 23:23 ` rhavar
2018-02-13 18:40 ` Peter Todd
2018-02-14 2:07 ` rhavar
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=20180301151129.GA9373@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@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