📅 Original date posted:2018-03-08
📝 Original message: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.
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? Not many
wallets let you spend unconfirmed outputs that you didn't create.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 614 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/dccea518/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:11:04
in reply to nevent1q…ushl
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:11:04Event JSON
{
"id": "00db91a4c2b40724dd8caa6167cf5841152e7ed6418c423b23db89c65f4f3b7a",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161464,
"kind": 1,
"tags": [
[
"e",
"7ff68932dd1a40e3238cc697fed378ce55127dd209cab0dae87c325cd17cc22a",
"",
"root"
],
[
"e",
"f541b86b40d81b586b17c9369c483d290d07b5ad256c368adb8a20b2488ce91f",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2018-03-08\n📝 Original message:On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:\n\u003e On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e I mean, I think in general solving this problem is probably not possible.\n\u003e \u003e Basically, the fundamental problem is someone else has consumed network\n\u003e \u003e bandwidth that should be paid for with fees. What you're trying to do is\n\u003e \u003e replace a transaction without paying those fees, which is identical to\n\u003e \u003e what an\n\u003e \u003e attacker is trying to do, and thus any such scheme will be as vulnerable to\n\u003e \u003e attack as not having that protection in the first place.\n\u003e \u003e\n\u003e \u003e ...which does give you an out: maybe the attack isn't important enough to\n\u003e \u003e matter. :)\n\u003e \u003e\n\u003e \n\u003e Thanks, that makes sense.\n\u003e \n\u003e I still think it is worthwhile pursuing this proposed change in RBF policy\n\u003e as it would seem that the current policy is problematic in practice today\n\u003e where participants are just performing normal transactions and are not\n\u003e trying to attack each other.\n\nBut that's not a good argument: whether or not normal users are trying to\nattack each other has nothing to do with whether or not you're opening up an\nattack by relaxing anti-DoS protections.\n\nEqually, how often are normal users who aren't attacking each other creating\nissues anyway? You can always have your wallet code just skip use of RBF\nreplacements in the event that someone does spend an unconfirmed output that\nyou sent them; how often does this actually happen in practice? Not many\nwallets let you spend unconfirmed outputs that you didn't create.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 614 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180308/dccea518/attachment.sig\u003e",
"sig": "fd079c18ad9ed86f0918abb0cdde1942ac26a47973fecedf197f6a5bceb45ee28e1553e66d4c17d0d00ede01a054db1373224d108842ebed638c84fa97d553e5"
}