📅 Original date posted:2011-08-04
🗒️ Summary of this message: A proposal to address double-spending attacks on the Bitcoin network by propagating conflicts on each of the conflicted inputs.
📝 Original message:On Thu, Aug 4, 2011 at 3:42 PM, Andy Parkins <andyparkins at gmail.com> wrote:
> On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:
>
>> But why? It results in slightly more network traffic which is exactly
>> what we don't want, and it adds yet another message people have to know
>> about.
>
> "Slightly" is an understatement. It add more network traffic for every
> double spend attempt. Which don't happen very often.
But they can be trivially generated on demand, and potentially result
in unbounded flooding.
Even if you carefully don't duplicate an announcement I can easily
generate an unlimited number of double-spends for the network to
flood. The normal anti-DDOS logic doesn't work because there can be no
additional proof-of-workish costs for the double spend (they'd share
whatever anti-ddos fees the first txn had).
This is somewhat soluble, I guess. Rather than NAK the transaction the
way it would work is propagating conflicts on each of the conflicted
inputs. "I've seen at least two transactions recently trying to spend
input X, here is proof: (two txn IDs)". Even if there are more spends
of that input you don't need to hear about them, knowing about two
spends of an input is enough to consider that input (and perhaps all
inputs with an identical script to that one) temporarily suspect.
Though it would have to be done input by input.
This might be an interesting feature if not for the fact that the
software already waits a fair number of confirms before considering
something confirmed. Of course, a sybil can just filter these messages
diminishing their usefulness.
I suppose I could add this as a (7) to this list:
https://bitcointalk.org/index.php?topic=28565.msg359948#msg359948
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 02:12:34
in reply to nevent1q…rrjn
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 02:12:34Event JSON
{
"id": "f6cc737de0c194c811f74b63e1ac2b0a39f48cb143279dc9d3c41ec7f1d2a872",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686103954,
"kind": 1,
"tags": [
[
"e",
"f7bac66510d148bc7cd5c36f79897fafe3410a2bc9df45238a65f8429b9407f0",
"",
"root"
],
[
"e",
"5f7a80db7bd746f636cb71a8bd133f01aa49587822b289f7e9f80d6ae1ca62cd",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-08-04\n🗒️ Summary of this message: A proposal to address double-spending attacks on the Bitcoin network by propagating conflicts on each of the conflicted inputs.\n📝 Original message:On Thu, Aug 4, 2011 at 3:42 PM, Andy Parkins \u003candyparkins at gmail.com\u003e wrote:\n\u003e On Thursday 04 August 2011 19:39:56 Matt Corallo wrote:\n\u003e\n\u003e\u003e But why? It results in slightly more network traffic which is exactly\n\u003e\u003e what we don't want, and it adds yet another message people have to know\n\u003e\u003e about.\n\u003e\n\u003e \"Slightly\" is an understatement. It add more network traffic for every\n\u003e double spend attempt. Which don't happen very often.\n\nBut they can be trivially generated on demand, and potentially result\nin unbounded flooding.\n\nEven if you carefully don't duplicate an announcement I can easily\ngenerate an unlimited number of double-spends for the network to\nflood. The normal anti-DDOS logic doesn't work because there can be no\nadditional proof-of-workish costs for the double spend (they'd share\nwhatever anti-ddos fees the first txn had).\n\nThis is somewhat soluble, I guess. Rather than NAK the transaction the\nway it would work is propagating conflicts on each of the conflicted\ninputs. \"I've seen at least two transactions recently trying to spend\ninput X, here is proof: (two txn IDs)\". Even if there are more spends\nof that input you don't need to hear about them, knowing about two\nspends of an input is enough to consider that input (and perhaps all\ninputs with an identical script to that one) temporarily suspect.\nThough it would have to be done input by input.\n\nThis might be an interesting feature if not for the fact that the\nsoftware already waits a fair number of confirms before considering\nsomething confirmed. Of course, a sybil can just filter these messages\ndiminishing their usefulness.\n\nI suppose I could add this as a (7) to this list:\nhttps://bitcointalk.org/index.php?topic=28565.msg359948#msg359948",
"sig": "b091041acf5132156ef0ef9bfc0855d1a44a73f84b0ad7c0dc1dab19319eafbd957fde48bac595df5cae3f50bebc313a42f8844bccc5b28cd0db21102a98e9c4"
}