Checkpoint at block 193,000 #1698
Conversation
|
This is way too close to current right now. How long are we planning on staying in RC? (Not that I'm aware of a fork this would conflict with, of course, but I like keeping the high ground of saying we've never released a checkpoint remotely near the tip) |
|
It's been a while (and quite a lot of code changes) since 0.6.3, so I assume we'll be in RC for at least two weeks. How far back is "long enough" for a checkpoint? |
|
3 months? |
|
Meh, I'd say 1 or 2 difficulty-adjust-cycles (2 or 4 weeks)? |
|
I think I'd claimed "8000 blocks" in some discussion before, I'm not seriously married to any specific value. I think it should be at least 1 difficulty cycle. 2 difficulty cycles sounds good. Sort of a bummer that we don't lock in the new difficulty when it's increasing like now, but it doesn't really matter. |
|
ok. I'll go ~2000 blocks (~2 weeks) back, and assuming we're in RC for 2 more weeks that'll be ~2 difficulty cycles at release. So block 193,000 or thereabouts... |
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/80cfc3a48551513d6133a2433b257c25727f8874 for binaries and test log. |
|
ACK |
…FinalTx dfa9928 [BUG][Wallet] Lock cs_main before accessing CheckFinalTx (random-zebra) Pull request description: Bug introduced in bitcoin#1698 . The LockHeld assertion in `CheckFinalTx` fails when it is called from `GetMasternodeVinAndKeys` (via `CheckTXAvailability`). This PR adds an assertion to the functions calling `CheckFinalTx` - `removeForReorg` - `CheckTXAvailability` And acquires `cs_main` mutex in `GetMasternodeVinAndKeys`. ACKs for top commit: furszy: good catch, utACK dfa9928 Fuzzbawls: utACK dfa9928 Tree-SHA512: b6b435b3086728444461c1ff4feb8b2116e8486ad384ccb9c4045fc648cfecb88e485e0d96d034684c424763d418496c0ff432ced85712b95834f8fecd4bf5cd
Replace the checkpoint at 185,333 with block 193,000.
(edited, was 195,000)