📅 Original date posted:2013-03-12
📝 Original message:On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr <luke at dashjr.org> wrote:
>
>
> I think we should be careful not to downplay the reality either.
> For a number of hours, transactions could have received up to N
> confirmations
> and then still been reversed. While we could contact the bigger payment
> processors, I saw people still trying to buy/sell on OTC, whom could have
> been
> scammed even by taking standard precautions.
>
>
I don't want to misrepresent what happened, but how much of that was really
a risk? The block was rejected, but the transactions were not. Any valid
transactions to hit the network would get added to everyone's memory pool
and mined in both chains. Thus all nodes would still reject double-spend
attempts. As far as I understood it, you would've had to have majority
mining power on one of the chains (and both had non-negligible computing
power on them), so double-spending still required an exceptional amount of
resources -- just not the normal 50% that is normally needed. Perhaps...
10%? But how many people can even have 10%? In addition to that, a
victim needs to be found that hasn't seen the alert, is willing to execute
a large transaction, and is on the wrong side of the chain.
Is this incorrect? Yes, there was less resources needed to execute an
attack -- but it still required a very powerful attacker, way outside the
scope of "regular users."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/417265d3/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 11:37:40
in reply to nevent1q…s5fl
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 11:37:40Event JSON
{
"id": "b23bb20393165e8040e0ddba5a265deeb2af20e83504b013ca8e18ac6806a629",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686137860,
"kind": 1,
"tags": [
[
"e",
"f33f518d3b5ede4c8e85312ebea36f59a0dce8fd1c908dfe9352a4a28b6ea01d",
"",
"root"
],
[
"e",
"05b06302f9f10693b9814c3f8d1f803c86f43b8238005a7f0bc21d89bcafc60c",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2013-03-12\n📝 Original message:On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e I think we should be careful not to downplay the reality either.\n\u003e For a number of hours, transactions could have received up to N\n\u003e confirmations\n\u003e and then still been reversed. While we could contact the bigger payment\n\u003e processors, I saw people still trying to buy/sell on OTC, whom could have\n\u003e been\n\u003e scammed even by taking standard precautions.\n\u003e\n\u003e\nI don't want to misrepresent what happened, but how much of that was really\na risk? The block was rejected, but the transactions were not. Any valid\ntransactions to hit the network would get added to everyone's memory pool\nand mined in both chains. Thus all nodes would still reject double-spend\nattempts. As far as I understood it, you would've had to have majority\nmining power on one of the chains (and both had non-negligible computing\npower on them), so double-spending still required an exceptional amount of\nresources -- just not the normal 50% that is normally needed. Perhaps...\n10%? But how many people can even have 10%? In addition to that, a\nvictim needs to be found that hasn't seen the alert, is willing to execute\na large transaction, and is on the wrong side of the chain.\n\nIs this incorrect? Yes, there was less resources needed to execute an\nattack -- but it still required a very powerful attacker, way outside the\nscope of \"regular users.\"\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/417265d3/attachment.html\u003e",
"sig": "d13805a3e0a441f62013ed572ee01523c3b13d26d76d7ef8e0a1704455fc06b6a1dde38d43a72422721358ed00373070773f4378a05a37ca663f35e5a7f6ffaf"
}