📅 Original date posted:2017-05-18
📝 Original message:Locking the lower bits on the timestamp will likely break existing
hardware that relies on being able to roll ntime.
On Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Bitcoin Development Mailing List,
>
> I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.
>
>
> 1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.
>
> The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.
>
>
> 2. General ASIC optimisation cannot be considered a Security Vulnerabilities.
>
> Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.
>
>
> 3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.
>
> ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be considered an exploit of the Bitcoin Proof-of-Work Function.
>
> For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:
> http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf
>
> The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.
>
>
> 4. Work should be taken to prudently and swiftly restore Bitcoins Security Properties.
>
> I recommend the Bitcoin Community fix this vulnerability with expediency.
>
>
>
> Cameron.
>
> PS:
>
> With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.
>
> (Here is my working list of things to do):
>
> 1. Include extra data in the Coinbase Transaction, such as the Witness Root.
>
> 2. Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).
>
> 3. Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.
>
> 4. Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).
>
> Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 18:01:17
in reply to nevent1q…vdvs
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 18:01:17Event JSON
{
"id": "5e850bbd8d5c4f464e1cb93a9268e4bd46798525b00a47d6943806956daee904",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160877,
"kind": 1,
"tags": [
[
"e",
"f70bddd64502508bed584572ca722b248b72bf405d306807bd48f551b97bae4d",
"",
"root"
],
[
"e",
"a674a2f0ed835683a66fc689b39b69ff60748df5a1a17d3ed3c0f6d73666509d",
"",
"reply"
],
[
"p",
"05ff1a1da79f4ed8e7928f7b6cf225a88de06820c57a7e5425d2ac5dac6068d9"
]
],
"content": "📅 Original date posted:2017-05-18\n📝 Original message:Locking the lower bits on the timestamp will likely break existing\nhardware that relies on being able to roll ntime.\n\nOn Thu, May 18, 2017 at 8:44 AM, Cameron Garnham via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hello Bitcoin Development Mailing List,\n\u003e\n\u003e I wish to explain why the current approach to ‘ASICBOOST’ dose not comply with our established best practices for security vulnerabilities and suggest what I consider to be an approach closer matching established industry best practices.\n\u003e\n\u003e\n\u003e 1. Significant deviations from the Bitcoin Security Model have been acknowledged as security vulnerabilities.\n\u003e\n\u003e The Bitcoin Security Model assumes that every input into the Proof-of-Work function should have the same difficulty of producing a desired output.\n\u003e\n\u003e\n\u003e 2. General ASIC optimisation cannot be considered a Security Vulnerabilities.\n\u003e\n\u003e Quickly being able to check inputs is not a vulnerability. However, being able to craft inputs that are significantly easier to check than alternative inputs is a vulnerability.\n\u003e\n\u003e\n\u003e 3. We should assign a CVE to the vulnerability exploited by ‘ASICBOOST’.\n\u003e\n\u003e ‘ASICBOOST’ is an attack on this Bitcoin’s security assumptions and should be considered an exploit of the Bitcoin Proof-of-Work Function.\n\u003e\n\u003e For a more detailed look at ‘ASICBOOST’, please have a look at this excellent document by Jeremy Rubin:\n\u003e http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf\n\u003e\n\u003e The Bitcoin Community should be able to track the progress of restoring the quality of the Bitcoin Proof-of-Work function to its original assumptions.\n\u003e\n\u003e\n\u003e 4. Work should be taken to prudently and swiftly restore Bitcoins Security Properties.\n\u003e\n\u003e I recommend the Bitcoin Community fix this vulnerability with expediency.\n\u003e\n\u003e\n\u003e\n\u003e Cameron.\n\u003e\n\u003e PS:\n\u003e\n\u003e With a soft-fork it probably is possible to completely fix this Proof-of-Work vulnerability.\n\u003e\n\u003e (Here is my working list of things to do):\n\u003e\n\u003e 1. Include extra data in the Coinbase Transaction, such as the Witness Root.\n\u003e\n\u003e 2. Lock the Version. (Use a space in the Coinbase Transaction for signalling future upgrades).\n\u003e\n\u003e 3. Lock the lower-bits on the Timestamp: Block timestamps only need ~1minute granularity.\n\u003e\n\u003e 4. Make a deterministic ordering of transaction chains within a block. (However, I believe this option is more difficult).\n\u003e\n\u003e Of course, if we have a hard-fork, we should consider the Proof-of-Work internal merkle structure directly.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "9db05ee1f7d79d37d4e445ed3d51118d786f7f342fea985d32d1164b92aa0b4a558ce94a1218d7b6cdad6dde95a593d0dc27139ad7061f1dbb4dc15d19629cd3"
}