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 <[email protected]> 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 > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
