📅 Original date posted:2018-03-08
📝 Original message:On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete at petertodd.org> wrote:
> On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> > 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. :)
>
Thanks, that makes sense.
I still think it is worthwhile pursuing this proposed change in RBF policy
as it would seem that the current policy is problematic in practice today
where participants are just performing normal transactions and are not
trying to attack each other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/dfce6649/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:11:03
in reply to nevent1q…3p6v
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:11:03Event JSON
{
"id": "f541b86b40d81b586b17c9369c483d290d07b5ad256c368adb8a20b2488ce91f",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161463,
"kind": 1,
"tags": [
[
"e",
"7ff68932dd1a40e3238cc697fed378ce55127dd209cab0dae87c325cd17cc22a",
"",
"root"
],
[
"e",
"f19788010ceee8357d8d52e0e3895ba6b400dceb26823154830f325ea218f695",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2018-03-08\n📝 Original message:On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:\n\u003e \u003e When you say that you don't think it is possible to solve, do you mean\n\u003e that\n\u003e \u003e there is a specific problem with this proposal of replacing transactions\n\u003e \u003e when offered a new transaction whose fee rate exceeds the package fee\n\u003e rate\n\u003e \u003e of the original transaction (and ensuring that the fee increase covers\n\u003e the\n\u003e \u003e size of the transactions being ejected)? Is your concern only about the\n\u003e \u003e ability to computing and track the package fee rate for transactions\n\u003e within\n\u003e \u003e the mempool or is there some other issue you foresee?\n\u003e\n\u003e I mean, I think in general solving this problem is probably not possible.\n\u003e Basically, the fundamental problem is someone else has consumed network\n\u003e bandwidth that should be paid for with fees. What you're trying to do is\n\u003e replace a transaction without paying those fees, which is identical to\n\u003e what an\n\u003e attacker is trying to do, and thus any such scheme will be as vulnerable to\n\u003e attack as not having that protection in the first place.\n\u003e\n\u003e ...which does give you an out: maybe the attack isn't important enough to\n\u003e matter. :)\n\u003e\n\nThanks, that makes sense.\n\nI still think it is worthwhile pursuing this proposed change in RBF policy\nas it would seem that the current policy is problematic in practice today\nwhere participants are just performing normal transactions and are not\ntrying to attack each other.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/dfce6649/attachment.html\u003e",
"sig": "5f5ac42705e678063520e791acfe09ee9c02be8f29c6d9f9bdd8b60f246460f7c7e367a2ba7191eddd81d9d917e0274857e8bee1580d8863b7eac8792390c9c5"
}