📅 Original date posted:2018-03-01
📝 Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180301/3ef65ba8/attachment-0001.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:11:03
in reply to nevent1q…hsqq
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:11:03Event JSON
{
"id": "f19788010ceee8357d8d52e0e3895ba6b400dceb26823154830f325ea218f695",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161463,
"kind": 1,
"tags": [
[
"e",
"7ff68932dd1a40e3238cc697fed378ce55127dd209cab0dae87c325cd17cc22a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-03-01\n📝 Original message:On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:\n\u003e On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e\n\u003e \u003e Ah ok, I misunderstood and didn't realise you were talking about the case\n\u003e \u003e where\n\u003e \u003e Alice re-spends her unconfirmed payment. Unfortunately I don't think that\n\u003e \u003e case\n\u003e \u003e is possible to solve without putting some kind of restriction on spending\n\u003e \u003e unconfirmed outputs; with a restriction it's fairly simple to solve.\n\u003e \n\u003e \n\u003e When you say that you don't think it is possible to solve, do you mean that\n\u003e there is a specific problem with this proposal of replacing transactions\n\u003e when offered a new transaction whose fee rate exceeds the package fee rate\n\u003e of the original transaction (and ensuring that the fee increase covers the\n\u003e size of the transactions being ejected)? Is your concern only about the\n\u003e ability to computing and track the package fee rate for transactions within\n\u003e the mempool or is there some other issue you foresee?\n\nI mean, I think in general solving this problem is probably not possible.\nBasically, the fundamental problem is someone else has consumed network\nbandwidth that should be paid for with fees. What you're trying to do is\nreplace a transaction without paying those fees, which is identical to what an\nattacker is trying to do, and thus any such scheme will be as vulnerable to\nattack as not having that protection in the first place.\n\n...which does give you an out: maybe the attack isn't important enough to\nmatter. :)\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: 488 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180301/3ef65ba8/attachment-0001.sig\u003e",
"sig": "d3f397d0197d50b00d30aaac49d01fcc37482b09c444615cf22ba0904688424bd2a22a373b25aa1dd54211e443bb5bc82402f10a0a6e7e0156a3aa511d449ef6"
}