📅 Original date posted:2018-08-22
📝 Original message:I only knew about ArtForz's fix, which isn't backwards compatible.
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code
On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
> difficulty calculation was vulnerable to gaming with inaccurate
> timestamps to massively increase the rate of block production beyond
> the system's intentional design. It can be fixed with a soft-fork that
> further constraints block timestamps, and a couple of proposals have
> been floated along these lines.
>
> I put a demonstration of timewarp early in the testnet3 chain to also
> let people test mitigations against that. It pegs the difficulty way
> down and then churned out blocks at the maximum rate that the median
> time protocol rule allows.
>
> I, and I assume others, haven't put a big priority into fixing this
> vulnerability because it requires a majority hashrate and could easily
> be blocked if someone started using it.
>
> But there haven't been too many other network consensus rules going on
> right now, and I believe at least several of the proposals suggested
> are fully compatible with existing behaviour and only trigger in the
> presence of exceptional circumstances-- e.g. a timewarp attack. So
> the risk of deploying these mitigations would be minimal.
>
> Before I dust off my old fix and perhaps prematurely cause fixation on
> a particular approach, I thought it would be useful to ask the list if
> anyone else was aware of a favourite backwards compatible timewarp fix
> proposal they wanted to point out.
>
> Cheers.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 18:14:09
in reply to nevent1q…g4jq
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 18:14:09Event JSON
{
"id": "d0ce8aae86dd1331fd58b817a8f55c6f8c57351002e07e0da085aead2a54c34e",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686161649,
"kind": 1,
"tags": [
[
"e",
"46c355a6f8c41cd523515034c9d7a614ef42b8cc667628d16987c384eb59bff0",
"",
"root"
],
[
"e",
"7c964e4f0ac8bb30a9b2050b4df51d392da3a6019715f960331804c0e306aaf5",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-08-22\n📝 Original message:I only knew about ArtForz's fix, which isn't backwards compatible.\n\nhttps://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11\nhttps://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code\n\n\nOn Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Since 2012 (IIRC) we've known that Bitcoin's non-overlapping\n\u003e difficulty calculation was vulnerable to gaming with inaccurate\n\u003e timestamps to massively increase the rate of block production beyond\n\u003e the system's intentional design. It can be fixed with a soft-fork that\n\u003e further constraints block timestamps, and a couple of proposals have\n\u003e been floated along these lines.\n\u003e\n\u003e I put a demonstration of timewarp early in the testnet3 chain to also\n\u003e let people test mitigations against that. It pegs the difficulty way\n\u003e down and then churned out blocks at the maximum rate that the median\n\u003e time protocol rule allows.\n\u003e\n\u003e I, and I assume others, haven't put a big priority into fixing this\n\u003e vulnerability because it requires a majority hashrate and could easily\n\u003e be blocked if someone started using it.\n\u003e\n\u003e But there haven't been too many other network consensus rules going on\n\u003e right now, and I believe at least several of the proposals suggested\n\u003e are fully compatible with existing behaviour and only trigger in the\n\u003e presence of exceptional circumstances-- e.g. a timewarp attack. So\n\u003e the risk of deploying these mitigations would be minimal.\n\u003e\n\u003e Before I dust off my old fix and perhaps prematurely cause fixation on\n\u003e a particular approach, I thought it would be useful to ask the list if\n\u003e anyone else was aware of a favourite backwards compatible timewarp fix\n\u003e proposal they wanted to point out.\n\u003e\n\u003e Cheers.\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": "5056c76c45c8a05f6de9b27df31ce0bdec1ab506319b56c25b7e79a9bdd92e8a0fd156edc396e10244b2e50dd2cda225cb2a8a0415000a2d2ea46aa0e82219f0"
}