This iterates through all scripts and finds incorrectly compressed scripts.
Only keys in the DB that are 33 bytes long are affected, and only keys that don't start with 0x02 or 0x03.
It turns out that at the time of writingalso turns out that there's no keys with 0x00 and 0x01 that are affected.
However, we scan the entire database anyway, as between now and the upgrade, someone could create txs with 33 byte long pubkeys that e.g. start with 0 or 1. Note that these txs are standard (c.f. MatchPayToPubkey), so this is definitely non-optional.
On my high-end instance, the update takes 5m:17s, so on bad hardware it shouldn't take more than 15 minutes.
At the time of writing, the only affected txs are these, the only affected txs are these:some:
52e307670ad54db6490f8ac11fe456a71dd0ef8f9fb1e52b1248f25eb69bb504- `00a17fbae6ee18cf7f645f45f30ed7abd9c39a551e3043fab15433f4e210590e`
00a17fbae6ee18cf7f645f45f30ed7abd9c39a551e3043fab15433f4e210590e- `237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67`
6450378a5ab233a0fdb76e24903a17f9771c5f38d175fc611e6e98bdfbd7764f- `3382a0d3fba1f62e52fe37cb0b7733d35ca11eaff200b9b2993d92301bf816ae`
65650c0b17d063ede2bfa28d1530f31b0bb1e0413849b1e31bde8f5adb6af891- `347939105c1c90282698ef83d59d525aa5022002318949cb6c9dde271535432f`
3382a0d3fba1f62e52fe37cb0b7733d35ca11eaff200b9b2993d92301bf816ae- `52e307670ad54db6490f8ac11fe456a71dd0ef8f9fb1e52b1248f25eb69bb504`
ef4bcadfbcb8c3a7c734ce957b5078d760229b93be41091918c2b1e18bd09807- `5d8403451c6313c0e9f41746af8a86a8929c331f1e01331726fad9166a07ba7a`
5d8403451c6313c0e9f41746af8a86a8929c331f1e01331726fad9166a07ba7a- `6450378a5ab233a0fdb76e24903a17f9771c5f38d175fc611e6e98bdfbd7764f`
71bbaef28e09d8d6fadd41f053db7768dbb5fa4570f06b961dfc29db3dc00b1d- `64bd61eedfef518e995c421bbd9dab99553a7787f74f1afddf1c33d1b947ec41`
846692c201067961c84c397e635a14a8b776a0b1c9dc89a8e24f472700e56e2a- `65650c0b17d063ede2bfa28d1530f31b0bb1e0413849b1e31bde8f5adb6af891`
77445dd56cea3173e957db23060380fe99a01bab570d93226f831252f85cea41- `657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1`
347939105c1c90282698ef83d59d525aa5022002318949cb6c9dde271535432f- `71bbaef28e09d8d6fadd41f053db7768dbb5fa4570f06b961dfc29db3dc00b1d`
237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67- `77445dd56cea3173e957db23060380fe99a01bab570d93226f831252f85cea41`
64bd61eedfef518e995c421bbd9dab99553a7787f74f1afddf1c33d1b947ec41- `846692c201067961c84c397e635a14a8b776a0b1c9dc89a8e24f472700e56e2a`
- `b57168c6b9bafe1a7a14ffdd3e4069d88e77f5ef41b931d25205b96c309526cf`
657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1
It also turns out that there's no keys with 0x00 and 0x01 that are affected.
However, we scan the entire database anyway, as between now and the upgrade, someone could create txs with 33 byte long pubkeys that e.g. start with 0 or 1. Note that these txs are standard (c.f. MatchPayToPubkey), so this is definitely non-optional.
On my high-end instance, the update takes 5m:17s, so on bad hardware it shouldn't take more than 15 minutes.- `ef4bcadfbcb8c3a7c734ce957b5078d760229b93be41091918c2b1e18bd09807`
Depends on D16936.