Update nMinimumChainWork and defaultAssumeValid.

[gmaxwell]

No description provided.

[petertodd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

utACK 3f78e460ba980d38149ee50ff5dfd75741aad9f2

I believe 0000000000000000000000000000000000000000003f94d1ad391682fe038bf5 to a valid Bitcoin blockchain.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYpgDFAAoJECSBQD2l8JH7xgEH/2n5BSrLNBkUrZthOeBYdXa+
ntmjRzhZaMmlRgCTVnVJR0PN8e3FHEhdeWz+LxAwAlefOTehGqlqjxmaI1VQnqGq
8a3LLvmZdQ5WD5fN4wGA4wDU1DjRPdG0k8O0W/p9BK/ABMgWiV0wyx1pDXvvn6V/
I9r8CGNlxUd1VqT9x6T3rxSkEZIPZcYWkVSEfp930348Dz6W7wC9qFKw8+pZ95h0
YVX/KUgFmq2+5ufuzBCW9irzwC1QrEcp1DO3Lg2myjYqqHJ2Z4wKN+zA2tNUpB+d
8NxVbqBdyKdD0SbJMYYOV3byJwPBiiejZzFZgp5fu3obEOSS0JA8r+dMxLrxUl4=
=Jkyt
-----END PGP SIGNATURE-----

[jtimon]

utACK 3f78e46 for mainnet.
For testnet, getblock "0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc" tells me that the minimum chain work should be 0x00000000000000000000000000000000000000000000001dcfc5dbe39283e519 instead of 0x00000000000000000000000000000000000000000000001f057509eba81aed91

[MarcoFalke]

@jtimon The minimum chain work is not required to match the work of the block that is assumed to be valid.

…

On Thu, Feb 16, 2017 at 9:47 PM, Jorge Timón ***@***.***> wrote: utACK 3f78e46 for mainnet. For testnet, getblock "0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc" tells me that the minimum chain work should be 0x00000000000000000000000000000000000000000000001dcfc5dbe39283e519 instead of 0x00000000000000000000000000000000000000000000001f057509eba81aed91 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jtimon]

Right, but any reason for not having them matching? EDIT: (specially when you're updating both)

[MarcoFalke]

I assume the rationale is that testnet is super flaky and it is better to be conservative in what block to assume valid, as it has to be part of a valid chain to have any effect. ... In theory you could even "pre-date" the minimum chain work to the minimum chain work you expect at the earliest expected time of release.

[gmaxwell]

@jtimon we only set the assumevalid back because the chain might reorg. But even if the chain reorgs the work will be strictly equal or better. So the chainwork should be set as far forward as possible, but assumevalid may need to be set back to avoid reorgs. (I submitted this PR only after looking to see that there was no visible fork at the bitcoin height there and checked that the block was a couple minutes old at least, otherwise I would have set it one block back-- but I still would have had chainwork at the highest point currently available)

And yes, as Marco says: we could even set minimum chain work into the future (except for the fact that doing so might confuse testing!)

[MarcoFalke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Post merge utACK 3f78e460ba980d38149ee50ff5dfd75741aad9f
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJYp58IAAoJEC1/I3LlD+E3lnMH/RYgl3ENy05TRDGxY8PMVkav
NVGIQCqgrsffHBQw62bCH66gSxpPnBLf5bOw8ZYhiHaiCMgw3ODx9DTc5GL/2v0V
m4F/Sr9PW4GQUKzVxTYZTGL+HkwYHplUtPr5yc9++pP8PkXHy/JzVp+4I6IwYAOr
qXEmGLrbNUfzvaUe9I+0SZYD/H+lFifg3b2FmX/i0hXJZMSqJ9sBQjCyHLGMBqU5
Do0eHAlp5kxtq0Dc4I+dzF22P5mOZ11xS6AtWUcD0o4MKQOq+1/gYh62jnWBuxHE
YbtVYaBg0gFZBFNLP8u4vi4LHbFPs6+DLuCQnO3ehXOcgOyOTMooZCFyxyF2Y08=
=eIBQ
-----END PGP SIGNATURE-----

[sdaftuar]

post-merge ACK

[sdaftuar]

post-merge ACK

[sdaftuar]

ACK 0x00000000000000000013176bf8d7dfeab4e1db31dc93bc311b436e82ab226b90

[sdaftuar]

ACK 0x00000000000128796ee387cf110ccb9d2f36cffaf7f73079c995377c65ac0dcc