📅 Original date posted:2018-03-08
📝 Original message:On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd <pete at petertodd.org> wrote:
> On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:
> > On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete at petertodd.org> wrote:
> > > 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.
>
> But that's not a good argument: whether or not normal users are trying to
> attack each other has nothing to do with whether or not you're opening up
> an
> attack by relaxing anti-DoS protections.
>
I'm not suggesting removing the anti-DoS protections. I'm suggesting that
replaced transaction require a fee increase of at least the min-fee-rate
times the size of all the transactions being ejected (in addition to the
other proposed requirements).
> Equally, how often are normal users who aren't attacking each other
> creating
> issues anyway? You can always have your wallet code just skip use of RBF
>
replacements in the event that someone does spend an unconfirmed output that
> you sent them; how often does this actually happen in practice?
Just ask rhavar. It happens regularly.
Not many wallets let you spend unconfirmed outputs that you didn't create.
>
The problem is with institutional wallets sweeping incoming payments. It
seems that in practice they are happy to sweep unconfirmed outputs.
Setting all of the above aside for a moment. We need to understand that
rational miners are going to prefer to transactions with higher package fee
rates regardless of whatever your personal preferred RBF policy is. If we
do not bring the RBF policy to alignment with what is economically
rational, then miners are going to change their own policies anyways,
probably all in slightly different ways. It behooves everyone to develop a
reasonable standard RBF policy, that is still robust against possible DoS
vectors, and aligns with miner incentives, so that all participants know
what behaviour they can reasonably expect. It is simply a bonus that this
change in RBF policy also partially mitigates the problem of pinned
transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/9193b079/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:11:04
in reply to nevent1q…lzrm
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:11:04Event JSON
{
"id": "815b3a9d2c4d26473619421831fc06c93a58035f885c21a24a7607833480c901",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161464,
"kind": 1,
"tags": [
[
"e",
"7ff68932dd1a40e3238cc697fed378ce55127dd209cab0dae87c325cd17cc22a",
"",
"root"
],
[
"e",
"00db91a4c2b40724dd8caa6167cf5841152e7ed6418c423b23db89c65f4f3b7a",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2018-03-08\n📝 Original message:On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:\n\u003e \u003e On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e \u003e I mean, I think in general solving this problem is probably not\n\u003e possible.\n\u003e \u003e \u003e Basically, the fundamental problem is someone else has consumed network\n\u003e \u003e \u003e bandwidth that should be paid for with fees. What you're trying to do\n\u003e is\n\u003e \u003e \u003e replace a transaction without paying those fees, which is identical to\n\u003e \u003e \u003e what an\n\u003e \u003e \u003e attacker is trying to do, and thus any such scheme will be as\n\u003e vulnerable to\n\u003e \u003e \u003e attack as not having that protection in the first place.\n\u003e \u003e \u003e\n\u003e \u003e \u003e ...which does give you an out: maybe the attack isn't important enough\n\u003e to\n\u003e \u003e \u003e matter. :)\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e Thanks, that makes sense.\n\u003e \u003e\n\u003e \u003e I still think it is worthwhile pursuing this proposed change in RBF\n\u003e policy\n\u003e \u003e as it would seem that the current policy is problematic in practice today\n\u003e \u003e where participants are just performing normal transactions and are not\n\u003e \u003e trying to attack each other.\n\u003e\n\u003e But that's not a good argument: whether or not normal users are trying to\n\u003e attack each other has nothing to do with whether or not you're opening up\n\u003e an\n\u003e attack by relaxing anti-DoS protections.\n\u003e\n\nI'm not suggesting removing the anti-DoS protections. I'm suggesting that\nreplaced transaction require a fee increase of at least the min-fee-rate\ntimes the size of all the transactions being ejected (in addition to the\nother proposed requirements).\n\n\n\u003e Equally, how often are normal users who aren't attacking each other\n\u003e creating\n\u003e issues anyway? You can always have your wallet code just skip use of RBF\n\u003e\nreplacements in the event that someone does spend an unconfirmed output that\n\u003e you sent them; how often does this actually happen in practice?\n\n\nJust ask rhavar. It happens regularly.\n\nNot many wallets let you spend unconfirmed outputs that you didn't create.\n\u003e\n\nThe problem is with institutional wallets sweeping incoming payments. It\nseems that in practice they are happy to sweep unconfirmed outputs.\n\nSetting all of the above aside for a moment. We need to understand that\nrational miners are going to prefer to transactions with higher package fee\nrates regardless of whatever your personal preferred RBF policy is. If we\ndo not bring the RBF policy to alignment with what is economically\nrational, then miners are going to change their own policies anyways,\nprobably all in slightly different ways. It behooves everyone to develop a\nreasonable standard RBF policy, that is still robust against possible DoS\nvectors, and aligns with miner incentives, so that all participants know\nwhat behaviour they can reasonably expect. It is simply a bonus that this\nchange in RBF policy also partially mitigates the problem of pinned\ntransactions.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/9193b079/attachment.html\u003e",
"sig": "5fec347c90b287005f49829c604d53d8ab8ce8d57ce89f18f21c88e68a95547f3b4fa6750355f509d90f74084d908613438e1481478601c079bf0f41a36e92a5"
}