馃搮 Original date posted:2015-07-23
馃摑 Original message:Discussions about whether to get miner's confirmation on
uncontroversial hardforks or not, and about whether to use nHeight,
nMedianTime or just use nTime are spreading all around. Hopefully
getting a BIP number (even though this is still a draft) will help
concentrating discussions about deployment of uncontroversial
hardforks to a single place.
Greg, can I get a BIP number for this?
On Sun, Jun 21, 2015 at 12:54 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> On Sun, Jun 21, 2015 at 11:31 AM, Jorge Tim贸n <jtimon at jtimon.cc> wrote:
>>
>> You mean the timewarp fix can be coded as a softfork instead of a
>> hardfork? How so?
>
>
> The easiest would be a rule requiring that all blocks are within 1 day of
> the median of the previous 11 blocks. At the moment, you need to be greater
> than that value. This would add a condition at the other end.
>
> It wouldn't be a total fix, but it would protect against the exploit.
>
> A stricter soft fork would be that the two blocks in question have to have
> the same timestamp. This would force the off by 1 and the correct value to
> give the same result.
>
>> If that's the case, do you have a better candidate?
>
>
> I think it is fine, since fixing it "right" does require a hard fork,
> especially if it is only to show a non controversial hard fork.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 15:43:17
in reply to nevent1q鈥gl8
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:43:17Event JSON
{
"id": "4d718d37d555eb8608277b07e1a630d653030d790e513dbe0febb786b4a91aac",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152597,
"kind": 1,
"tags": [
[
"e",
"c572b249f818758373645da4a4d4cffe8ccabef79cdef027e0e502d5d2c5daf2",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "馃搮 Original date posted:2015-07-23\n馃摑 Original message:Discussions about whether to get miner's confirmation on\nuncontroversial hardforks or not, and about whether to use nHeight,\nnMedianTime or just use nTime are spreading all around. Hopefully\ngetting a BIP number (even though this is still a draft) will help\nconcentrating discussions about deployment of uncontroversial\nhardforks to a single place.\nGreg, can I get a BIP number for this?\n\nOn Sun, Jun 21, 2015 at 12:54 PM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\u003e On Sun, Jun 21, 2015 at 11:31 AM, Jorge Tim贸n \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\u003e\n\u003e\u003e You mean the timewarp fix can be coded as a softfork instead of a\n\u003e\u003e hardfork? How so?\n\u003e\n\u003e\n\u003e The easiest would be a rule requiring that all blocks are within 1 day of\n\u003e the median of the previous 11 blocks. At the moment, you need to be greater\n\u003e than that value. This would add a condition at the other end.\n\u003e\n\u003e It wouldn't be a total fix, but it would protect against the exploit.\n\u003e\n\u003e A stricter soft fork would be that the two blocks in question have to have\n\u003e the same timestamp. This would force the off by 1 and the correct value to\n\u003e give the same result.\n\u003e\n\u003e\u003e If that's the case, do you have a better candidate?\n\u003e\n\u003e\n\u003e I think it is fine, since fixing it \"right\" does require a hard fork,\n\u003e especially if it is only to show a non controversial hard fork.\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "67965c10bd8ef459667de42f393d0dc9f1b6f98ead42bb7984317bbc574a19648f2df1edece0d4b078d84af3b812786e9797a71449cd8d0723df55f62785fe18"
}