Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-30 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2013-10-30
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that >50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.
On 10/30/13 1:24 AM, Mike Hearn wrote:
>
> But if you are getting soft-forked recent versions of the
> reference implementation WILL alert you; see this code in
> main.cpp:
>
>
> Perhaps I'm confused about how we're using the term soft fork. My
> understanding is that this is where a new upgrade is designed to
> look valid to old nodes, and if you don't upgrade you rely on the
> miner majority to get you "back on track". For instance, P2SH was
> done this way - old nodes that didn't upgrade during that
> transition believed all spends of P2SH outputs were valid, even
> those spending someone elses coins.
>
> In this case, the code you cite won't do anything because your
> client will never reject a block during a soft-forking upgrade,
> even if it does something that's supposed to be invalid or
> nonsensical.
>
> If a new block version changes the serialization format or script
> language or SIGHASH rules such that old clients reject the block,
> then they will end up on a hard fork and the alerting code will
> trigger, which is correct and as it should be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S
qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ
jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr
6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu
2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp
2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX
padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET
0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb
rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI
nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/
sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT
eccFOHArsbW3eSfKP/Mb
=FSQI
-----END PGP SIGNATURE-----
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that >50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.
On 10/30/13 1:24 AM, Mike Hearn wrote:
>
> But if you are getting soft-forked recent versions of the
> reference implementation WILL alert you; see this code in
> main.cpp:
>
>
> Perhaps I'm confused about how we're using the term soft fork. My
> understanding is that this is where a new upgrade is designed to
> look valid to old nodes, and if you don't upgrade you rely on the
> miner majority to get you "back on track". For instance, P2SH was
> done this way - old nodes that didn't upgrade during that
> transition believed all spends of P2SH outputs were valid, even
> those spending someone elses coins.
>
> In this case, the code you cite won't do anything because your
> client will never reject a block during a soft-forking upgrade,
> even if it does something that's supposed to be invalid or
> nonsensical.
>
> If a new block version changes the serialization format or script
> language or SIGHASH rules such that old clients reject the block,
> then they will end up on a hard fork and the alerting code will
> trigger, which is correct and as it should be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S
qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ
jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr
6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu
2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp
2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX
padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET
0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb
rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI
nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/
sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT
eccFOHArsbW3eSfKP/Mb
=FSQI
-----END PGP SIGNATURE-----