Thomas Kerin [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-31 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2015-07-31
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I really think there should be a document before a BIP number is assigned.
On 23/07/15 12:10, Jorge Timón via bitcoin-dev wrote:
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVu7MlAAoJEAiDZR291eTlGnkP/jG/oW2PfPwDt6t+1UJ7P1LO
/NDtpUI5wiPQ6aXBmqKSx7FxZ9QJQM1tB1SpGhFosOXXSiYLjNos0l0S6oRw7yGC
LzXmbNTL863F0vOfRU35yxQJbcUi6gOHk8E/oo2X/V+BgAoc4cweK4080C8k1vki
7kPPiSek4erMo7TVNb5vsHkOI6QXhKNV/lFuSOuRAwklRY5vL2BZi56HekOnoFdr
iHebmRrjL7R+IFzasnWtHh6KGs51tg02SOPTMXwJ/H+xDqN9LXk/DJUbp9QhEa+t
TwojQBj7D+HMWavaLRVjVQOcvxxm3PTwZHmHxzfrx3kG5nsZNWrebWElHikW8BuW
dg6Yq/6mIW59HPyNSc5HCBnNonKpZebsQU0rdzOcwWFdk0SZ1TuKrYjNu9uDVGpo
od21hIpGYa1FTxk1HQ63PMf5SKmLunvHOehWw8pmXy44k3WVkABAhi7YNIbA8Qvj
DJ+k9wtypDBraoQh1yur4r1cBbBVcbaxRwv42MBGhtTXPVzRu6CikJNwa65z1AqT
AM3av8+IIgiq9dYn1uzDh1BQGSsB5YYQZ3QDHpM1DxCvjXvmgf4RdFwC0Q0B0X3S
jnWebazQvxN9qsylHAJeTZ0+rJCsx+R3Fl2Myasz/c3a6uaYJVi9/N0j3yRm1EYt
3Py8BGrArkIe3CeXaTCV
=Yh0o
-----END PGP SIGNATURE-----
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I really think there should be a document before a BIP number is assigned.
On 23/07/15 12:10, Jorge Timón via bitcoin-dev wrote:
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJVu7MlAAoJEAiDZR291eTlGnkP/jG/oW2PfPwDt6t+1UJ7P1LO
/NDtpUI5wiPQ6aXBmqKSx7FxZ9QJQM1tB1SpGhFosOXXSiYLjNos0l0S6oRw7yGC
LzXmbNTL863F0vOfRU35yxQJbcUi6gOHk8E/oo2X/V+BgAoc4cweK4080C8k1vki
7kPPiSek4erMo7TVNb5vsHkOI6QXhKNV/lFuSOuRAwklRY5vL2BZi56HekOnoFdr
iHebmRrjL7R+IFzasnWtHh6KGs51tg02SOPTMXwJ/H+xDqN9LXk/DJUbp9QhEa+t
TwojQBj7D+HMWavaLRVjVQOcvxxm3PTwZHmHxzfrx3kG5nsZNWrebWElHikW8BuW
dg6Yq/6mIW59HPyNSc5HCBnNonKpZebsQU0rdzOcwWFdk0SZ1TuKrYjNu9uDVGpo
od21hIpGYa1FTxk1HQ63PMf5SKmLunvHOehWw8pmXy44k3WVkABAhi7YNIbA8Qvj
DJ+k9wtypDBraoQh1yur4r1cBbBVcbaxRwv42MBGhtTXPVzRu6CikJNwa65z1AqT
AM3av8+IIgiq9dYn1uzDh1BQGSsB5YYQZ3QDHpM1DxCvjXvmgf4RdFwC0Q0B0X3S
jnWebazQvxN9qsylHAJeTZ0+rJCsx+R3Fl2Myasz/c3a6uaYJVi9/N0j3yRm1EYt
3Py8BGrArkIe3CeXaTCV
=Yh0o
-----END PGP SIGNATURE-----