Change Details

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 writing, the only affected txs are these: 52e307670ad54db6490f8ac11fe456a71dd0ef8f9fb1e52b1248f25eb69bb504 00a17fbae6ee18cf7f645f45f30ed7abd9c39a551e3043fab15433f4e210590e 6450378a5ab233a0fdb76e24903a17f9771c5f38d175fc611e6e98bdfbd7764f 65650c0b17d063ede2bfa28d1530f31b0bb1e0413849b1e31bde8f5adb6af891 3382a0d3fba1f62e52fe37cb0b7733d35ca11eaff200b9b2993d92301bf816ae ef4bcadfbcb8c3a7c734ce957b5078d760229b93be41091918c2b1e18bd09807 5d8403451c6313c0e9f41746af8a86a8929c331f1e01331726fad9166a07ba7a 71bbaef28e09d8d6fadd41f053db7768dbb5fa4570f06b961dfc29db3dc00b1d 846692c201067961c84c397e635a14a8b776a0b1c9dc89a8e24f472700e56e2a 77445dd56cea3173e957db23060380fe99a01bab570d93226f831252f85cea41 347939105c1c90282698ef83d59d525aa5022002318949cb6c9dde271535432f 237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67 64bd61eedfef518e995c421bbd9dab99553a7787f74f1afddf1c33d1b947ec41 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. Depends on D16936.

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 writing, the only affected txs are these: 52e307670ad54db6490f8ac11fe456a71dd0ef8f9fb1e52b1248f25eb69bb504 00a17fbae6ee18cf7f645f45f30ed7abd9c39a551e3043fab15433f4e210590e 6450378a5ab233a0fdb76e24903a17f9771c5f38d175fc611e6e98bdfbd7764f 65650c0b17d063ede2bfa28d1530f31b0bb1e0413849b1e31bde8f5adb6af891 3382a0d3fba1f62e52fe37cb0b7733d35ca11eaff200b9b2993d92301bf816ae ef4bcadfbcb8c3a7c734ce957b5078d760229b93be41091918c2b1e18bd09807 5d8403451c6313c0e9f41746af8a86a8929c331f1e01331726fad9166a07ba7a 71bbaef28e09d8d6fadd41f053db7768dbb5fa4570f06b961dfc29db3dc00b1d 846692c201067961c84c397e635a14a8b776a0b1c9dc89a8e24f472700e56e2a 77445dd56cea3173e957db23060380fe99a01bab570d93226f831252f85cea41 347939105c1c90282698ef83d59d525aa5022002318949cb6c9dde271535432f 237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67 64bd61eedfef518e995c421bbd9dab99553a7787f74f1afddf1c33d1b947ec41 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. Depends on D16936.

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 writing, the only affected txs are these: 52e307670ad54db6490f8ac11fe456a71dd0ef8f9fb1e52b1248f25eb69bb504 00a17fbae6ee18cf7f645f45f30ed7abd9c39a551e3043fab15433f4e210590e 6450378a5ab233a0fdb76e24903a17f9771c5f38d175fc611e6e98bdfbd7764f 65650c0b17d063ede2bfa28d1530f31b0bb1e0413849b1e31bde8f5adb6af891 3382a0d3fba1f62e52fe37cb0b7733d35ca11eaff200b9b2993d92301bf816ae ef4bcadfbcb8c3a7c734ce957b5078d760229b93be41091918c2b1e18bd09807 5d8403451c6313c0e9f41746af8a86a8929c331f1e01331726fad9166a07ba7a 71bbaef28e09d8d6fadd41f053db7768dbb5fa4570f06b961dfc29db3dc00b1d 846692c201067961c84c397e635a14a8b776a0b1c9dc89a8e24f472700e56e2a 77445dd56cea3173e957db23060380fe99a01bab570d93226f831252f85cea41 347939105c1c90282698ef83d59d525aa5022002318949cb6c9dde271535432f 237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67 64bd61eedfef518e995c421bbd9dab99553a7787f74f1afddf1c33d1b947ec41 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. Depends on D16936.