Replace long LoadChainstate parameters list with options struct. Replace long list of return values with simpler error strings.
No changes in behavior. Motivation is just to make libbitcoin_kernel API easier to use and more future-proof, and make internal code clearer and more maintainable.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
6@@ -7,21 +7,22 @@
7 #include <key.h>
8 #include <random.h>
9 #include <util/time.h>
10+#include <util/translation.h>
nit in the last commit. Maybe have this file checked by iwyu?
re: #25308 (review)
nit in the last commit. Maybe have this file checked by iwyu?
Sure, done in new commit
pr/retcode.2 -> pr/retcode.3, compare) making a few more cleanups and enabling IWYU
Updated 1066e9cff1631cd7e3d5ef930c42c0c1227992b8 -> 3981f5e7c090959b98a7fa0b9e92b52c36e60e96 (pr/retcode.3 -> pr/retcode.4, compare) fixing unintended change in catch statement
util/translation if at all possible, why do you prefer error strings?
I really want to avoid reintroducing stringy error returns and coupling with
util/translationif at all possible, why do you prefer error strings?
From most important to least important reasons:
Error codes can be great. Error strings can be great. Right tool for the job.
Rebased 3981f5e7c090959b98a7fa0b9e92b52c36e60e96 -> f3ec82fc466b247e9ed6b329554e6938799fadb5 (pr/retcode.4 -> pr/retcode.5, compare) due to conflict with #25306
12+#include <memory>
13
14 namespace kernel {
15
16-std::optional<SanityCheckError> SanityChecks(const Context&)
17+std::optional<bilingual_str> SanityChecks(const Context&)
std::string here? I don’t want to introduce further coupling with translation.
re: #25308 (review)
In commit “refactor: Reduce number of SanityChecks return values” (0b9bb465e9a0e2d4c9b7dc398e59dc380e8c4e60)
Could we just use
std::stringhere? I don’t want to introduce further coupling with translation.
We could actually use std::string instead of bilingual_str in this commit (not in the earlier commit), but I think it is better to use bilingual_str for reasons described in the other reply that commit.
47 };
48
49+enum class InitStatus { SUCCESS, FAILURE, FAILURE_INCOMPATIBLE_DB, INTERRUPTED };
50+
51+//! Status code and optional error string.
52+using InitResult = std::tuple<InitStatus, bilingual_str>;
std::string here? I don’t want to introduce further coupling with translation.
LoadChainstateResult so that it’s clearer it’s specifically about LoadChainstate and not all of init? Not a big deal either way.
re: #25308 (review)
In commit “refactor: Reduce number of LoadChainstate return values” (ed3c27ae5034f27f6240d2dcafbdbfd9bc55b9d7)
Could we just use
std::stringhere?
It’s not possible to do this without changing behavior. Error messages like “Error opening block database” and “Incorrect or no genesis block found. Wrong datadir for network?” are translated and can’t be returned through std::string.
I don’t want to introduce further coupling with translation.
I think there are only upsides not downsides to using bilingual_str for messages that may be shown to the users.
Using bilingual_str instead of std::string only adds a dependency on the bilingual_str struct struct which is a simple pair of std::string’s. This is a very minimal dependency, and it doesn’t require the caller to use translations or the kernel library to provide them. It just allows translations to be passed along if they are present.
In general, I think it is a good practice to use bilingual_str for user messages, whether or not they will be translated. Using the bilingual_str type distinguishes user messages from other types of strings, and helps future-proof code so API’s don’t have to change if translations are added or removed. The choice of whether or not to translate an string can be context dependent, and may depending on how frequently a specific message will be shown or how complicated it is to translate. Just using bilingual_str everywhere means APIs can pass translations along and not be tied to these implementation details.
re: #25308 (review)
In commit “refactor: Reduce number of LoadChainstate return values” (ed3c27ae5034f27f6240d2dcafbdbfd9bc55b9d7)
nit: Perhaps rename to
LoadChainstateResultso that it’s clearer it’s specifically aboutLoadChainstateand not all of init? Not a big deal either way.
Good suggestion, renamed both types
99+ node::CacheSizes cache_sizes;
100+ cache_sizes.block_tree_db = 2 << 20;
101+ cache_sizes.coins_db = 2 << 22;
102+ cache_sizes.coins = (450 << 20) - (2 << 20) - (2 << 22);
103+ node::InitOptions options;
104+ options.coins_error_cb=[] { return false; };
0 options.coins_error_cb = [] { return false; };
re: #25308 (review)
In commit “refactor: Reduce number of LoadChainstate return values” (ed3c27ae5034f27f6240d2dcafbdbfd9bc55b9d7)
Thanks, updated whitespace
44+ int64_t check_level = DEFAULT_CHECKLEVEL;
45+ std::function<bool()> check_interrupt;
46+ std::function<void()> coins_error_cb;
47 };
48
49+enum class InitStatus { SUCCESS, FAILURE, FAILURE_INCOMPATIBLE_DB, INTERRUPTED };
re: #25308 (review)
In commit “refactor: Reduce number of LoadChainstate return values” (ed3c27ae5034f27f6240d2dcafbdbfd9bc55b9d7)
Perhaps we can add some Doxygen comments hinting callers on how they should behave when encountering each case.
Thanks, added comment with suggestions
Concept ACK. I’ve thought about this a bit, and I think I’m convinced that this current way can work.
The key point that convinced me was: what users of LoadChainstate care about discerning between is not what particular internal failure happened, but rather what to do about the failure, which is nicely encapsulated in InitStatus.
Originally, my thought was that requiring callers to match against strings to determine what to do is footgun-y. However, if a case like that ever arises, it simply means that InitStatus should be modified to indicate the right course of action.
In SanityChecks’s case, any sanity check failure indicates to the caller that something is catastrophically wrong and the only course of action is to bail, so there’s no need for an additional Status enum.
Thanks for fixing the IWYU for src/kernel btw, I’ve been meaning to do that.
21 #include <util/overflow.h>
22 #include <util/system.h>
23 #include <validation.h>
24+#include <version.h>
25
26+#include <assert.h>
re: #25308 (review)
In commit “ci: Enable IWYU in src/kernel directory” (f3ec82fc466b247e9ed6b329554e6938799fadb5)
We want to use/are migrating to the C++ headers. I know IWYU suggests
<assert.h>(have been meaning to make it suggest the newer headers), but it will be equally as happy with<cassert>. Thanks for fixing these up in any case.
Thanks, switched to cassert
96- false,
97- []() { return false; });
98+ node::CacheSizes cache_sizes;
99+ cache_sizes.block_tree_db = 2 << 20;
100+ cache_sizes.coins_db = 2 << 22;
101+ cache_sizes.coins = (450 << 20) - (2 << 20) - (2 << 22);
In 1b32c5b7:
tiny nit, extra space
0 cache_sizes.coins = (450 << 20) - (2 << 20) - (2 << 22);
86- bool coins_db_in_memory,
87- std::function<bool()> shutdown_requested = nullptr,
88- std::function<void()> coins_error_cb = nullptr);
89+std::optional<ChainstateLoadingError> LoadChainstate(ChainstateManager& chainman,
90+ const CacheSizes& cache_sizes,
91+ const InitOptions& options = {});
InitOptions default value can be removed.
84@@ -75,10 +85,7 @@ enum class ChainstateLoadVerifyError {
85 };
86
87 std::optional<ChainstateLoadVerifyError> VerifyLoadedChainstate(ChainstateManager& chainman,
88- bool fReset,
89- bool fReindexChainState,
90- int check_blocks,
91- int check_level);
92+ const InitOptions& options = {});
InitOptions default value can be removed.
re: #25308 (review)
Same as above, in 1b32c5b: The
InitOptionsdefault value can be removed.
Thanks, removed
60
61 // Check for changed -prune state. What we are concerned about is a user who has pruned blocks
62 // in the past, but is now trying to run unpruned.
63 if (chainman.m_blockman.m_have_pruned && !options.prune) {
64- return ChainstateLoadingError::ERROR_PRUNED_NEEDS_REINDEX;
65+ return {InitStatus::FAILURE, _("You need to rebuild the database using -reindex to go back to unpruned mode. This will redownload the entire blockchain")};
In ed3c27ae:
tiny nit: remove extra space.
0 return {InitStatus::FAILURE, _("You need to rebuild the database using -reindex to go back to unpruned mode. This will redownload the entire blockchain")};
re: #25308 (review)
In ed3c27a:
tiny nit: remove extra space.
This is a refactoring PR, so would prefer not to change behavior here. (This is a translated string so changing it may require updating translations, as well as the original string)
Thanks for reviews!
Updated f3ec82fc466b247e9ed6b329554e6938799fadb5 -> 7d97076cb7d4020110a830ae9fe4107f82511c41 (pr/retcode.5 -> pr/retcode.6, compare) with suggestions, mainly fixing up whitespace and renaming the new types
pr/retcode.6 -> pr/retcode.7, compare) due to conflict with #25290
1459+ options.check_level = args.GetIntArg("-checklevel", DEFAULT_CHECKLEVEL);
1460+ options.check_interrupt = ShutdownRequested;
1461+ options.coins_error_cb = [] {
1462 uiInterface.ThreadSafeMessageBox(
1463 _("Error reading from database, shutting down."),
1464 "", CClientUIInterface::MSG_ERROR);
nit: indentation here seems to be screwed.
I can change it if desired, but it was actually intentional to just move these lines without changing the indentation
91 }
92
93 // ReplayBlocks is a no-op if we cleared the coinsviewdb with -reindex or -reindex-chainstate
94 if (!chainstate->ReplayBlocks()) {
95- return ChainstateLoadingError::ERROR_REPLAYBLOCKS_FAILED;
96+ return {ChainstateLoadStatus::FAILURE, _("Unable to replay blocks. You will need to rebuild the database using -reindex-chainstate.")};
Not for this PR but thinking about possible translations errors: shouldn’t we remove -reindex-chainstate from the translatable string?
0 return {ChainstateLoadStatus::FAILURE, strprintf(_("Unable to replay blocks. You will need to rebuild the database using %s."), "-reindex-chainstate")};
(Same for the rest startup flags on this function)
Code review ACK 9ac9a11d
A tiny non-blocking nit and an extra comment to improve in a future PR only.
17@@ -16,6 +18,23 @@ struct Params;
18 } // namespace Consensus
19
20 namespace node {
21+
22+struct CacheSizes;
23+
24+struct ChainstateLoadOptions
25+{
re: #25308 (review)
nit in the first commit: clang-format this new line?
Thanks, ran clang-format here and elsewhere
28+ bool coins_db_in_memory = false;
29+ bool reindex = false;
30+ bool reindex_chainstate = false;
31+ bool prune = false;
32+ int64_t check_blocks = DEFAULT_CHECKBLOCKS;
33+ int64_t check_level = DEFAULT_CHECKLEVEL;
{} over = to enable narrowing warnings for integers?
re: #25308 (review)
first commit: Use
{}over=to enable narrowing warnings for integers?
Thanks, changed
1456+ options.prune = node::fPruneMode;
1457+ options.check_blocks = args.GetIntArg("-checkblocks", DEFAULT_CHECKBLOCKS);
1458+ options.check_level = args.GetIntArg("-checklevel", DEFAULT_CHECKLEVEL);
1459+ options.check_interrupt = ShutdownRequested;
1460+ options.coins_error_cb = [] {
1461+ uiInterface.ThreadSafeMessageBox(
--color-moved=dimmed-zebra --color-moved-ws=ignore-all-space, so adjusting it should be fine.
re: #25308 (review)
nit in the first commit: It is possible to ignore moved space changes:
--color-moved=dimmed-zebra --color-moved-ws=ignore-all-space, so adjusting it should be fine.
Thanks, fixed indentation
98+ node::CacheSizes cache_sizes;
99+ cache_sizes.block_tree_db = 2 << 20;
100+ cache_sizes.coins_db = 2 << 22;
101+ cache_sizes.coins = (450 << 20) - (2 << 20) - (2 << 22);
102+ node::ChainstateLoadOptions options;
103+ options.coins_error_cb = [] { return false; };
options.check_interrupt.
coins_error_cb is of type std::function<void()>, but this lambda returns a bool
re: #25308 (review)
Why does this even compile?
coins_error_cbis of typestd::function<void()>, but this lambda returns abool
Good catch! Changed coins_error_cb to check_interrupt. I think this change would not actually have caused a problem in the bitcoin-chainstate example program, but now the new code should be more obviously equivalent to the previous code.
Reason it compiled is that the lambda is Callable with arguments and return type of the std::function. Rules about what can be assigned to a std::function are https://en.cppreference.com/w/cpp/utility/functional/function/operator%3D
42 auto& pblocktree{chainman.m_blockman.m_block_tree_db};
43 // new CBlockTreeDB tries to delete the existing file, which
44 // fails if it's still open from the previous loop. Close it first:
45 pblocktree.reset();
46- pblocktree.reset(new CBlockTreeDB(nBlockTreeDBCache, block_tree_db_in_memory, fReset));
47+ pblocktree.reset(new CBlockTreeDB(cache_sizes.block_tree_db, options.block_tree_db_in_memory, options.reindex));
std::make_unique, which is used in most other places over new?
re: #25308 (review)
unrelated nit in the first commit: Could use
std::make_unique, which is used in most other places overnew?
Yes there is basically no reason to use new anywhere. Just to keep this commit straightforward I would not want to change this here, especially since pblocktree is an auto reference and it’s not totally obvious that it is a unique_ptr. But I’d happily review followups replacing new with make_unique here and elsewhere.
49- if (fReset) {
50+ if (options.reindex) {
51 pblocktree->WriteReindexing(true);
52 //If we're reindexing in prune mode, wipe away unusable block files and all undo data files
53- if (fPruneMode)
54+ if (options.prune)
{ while touching this line?
61 // LoadBlockIndex will load m_have_pruned if we've ever removed a
62 // block file from disk.
63- // Note that it also sets fReindex based on the disk flag!
64- // From here on out fReindex and fReset mean something different!
65+ // Note that it also sets fReindex global based on the disk flag!
66+ // From here on out fReindex and options.reindex values may be different!
re: #25308 (review)
first commit: What does “out” mean? Maybe remove it?
Dropped “out”. here on out is just more verbose
229- /*coins_db_in_memory=*/true);
230+ node::ChainstateLoadOptions options;
231+ options.mempool = Assert(m_node.mempool.get());
232+ options.block_tree_db_in_memory = true;
233+ options.coins_db_in_memory = true;
234+ options.reindex = node::fReindex.load();
load is not needed in this context, as the compiler can infer the type?
re: #25308 (review)
first commit: I think
loadis not needed in this context, as the compiler can infer the type?
Thanks, dropped
234+ options.reindex = node::fReindex.load();
235+ options.reindex_chainstate = m_args.GetBoolArg("-reindex-chainstate", false);
236+ options.prune = node::fPruneMode;
237+ options.check_blocks = m_args.GetIntArg("-checkblocks", DEFAULT_CHECKBLOCKS);
238+ options.check_level = m_args.GetIntArg("-checklevel", DEFAULT_CHECKLEVEL);
239+ auto maybe_load_error = LoadChainstate(*Assert(m_node.chainman.get()), m_cache_sizes, options);
get is not needed? (Calling * on a reference to a unique ptr’s underlying raw pointer is equal to calling * on a reference to the unique ptr ?)
re: #25308 (review)
first commit: I think
getis not needed? (Calling*on a reference to a unique ptr’s underlying raw pointer is equal to calling*on a reference to the unique ptr ?)
Thanks, dropped
there is a bug in 9237c2295d9aa3d5e184db3da37760d7c78cdc27 🚆
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3there is a bug in 9237c2295d9aa3d5e184db3da37760d7c78cdc27 🚆
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUjNQAv/Zs7YW1PwWfHH+yRuxXGJ6sfoSy4e0PeSKwgs9dLOkPxtvj1jE7y2HK+q
80Hxv4C98L3zGI223Gz0dC1q7urfYykO0erS7Dd5yYnVA8Vkfq5Lg+22xramAYOPu
9X9XHtyZi74y5H/vxw8DFQAqGUppzZIuyD8UA/h0RvUbbHPZmwsd/z6UFQlHYGIak
10vTPzwa7XbtEm/tfF9Qo6zQyU1ukbBxMx6Mm787C0X8pKSiz0RNTvOEGXB+csxBOu
119WH5b0q4hKMcwZwY54I8UJ4UPiG1id2YF5LVb4Ce3R2hHrKoWBJWbaMcFR6wnG0I
12TEbqiTACEC1uS6C8uMlw1jdRq1YFXNXYOxnegrunwPbbOcdboaizNMjd93TpPUXi
13MZhGNfrDhP+Vki9wRDfRJNb+QBeSJawDpSORMqSqoFPlWWVnEErVzx6/5i8WBZa4
1424VJ9ophDcgmIALKDSCnjVKJnur5gnkzIGJA4fLdJQhlX5kg7SL1IVeXpeeq2L6p
15Czc262DE
16=dehA
17-----END PGP SIGNATURE-----
Updated 9ac9a11d4aa1c051c9d486657ff3021019e802e5 -> e022eaf87c65e8d7d27d8f5fa4cadc359c843e8a (pr/retcode.7 -> pr/retcode.8, compare) with suggested changes
re: #25308 (comment)
Could use 316afb1 ?
Unfortunately, this does not work because BResult does not support returning an error string and an error status at the same time. This is why I was discouraging the std::variant implementation in #25218 in favor of it having a std::optional<bilingual_str> error field. I think BResult can be extended to cover this case, though, and I will follow up with another PR to incorporate it. I think it would expand the scope of this PR too much to try to extend BResult here, though.
97 std::cerr << "Failed to load Chain state from your datadir." << std::endl;
98 goto epilogue;
99 } else {
100- auto maybe_verify_error = node::VerifyLoadedChainstate(chainman, options);
101- if (maybe_verify_error.has_value()) {
102+ std::tie(status, error) = node::VerifyLoadedChainstate(chainman, options);
[load_status, load_error] and [verify_status, verify_error]?
re: #25308 (review)
second commit: Any reason to overwrite/shadow this? Should be fine to have
[load_status, load_error]and[verify_status, verify_error]?
If you look at init.cpp you can see how error handling would get more complicated with multiple status and error values. This example program doesn’t have any error handling (right now), but the logic of using one status and error variable to represent the latest status instead of multiple variables to previous statuses still applies. It keeps function state simpler and is less prone to errors from referencing the wrong variable.
More broadly though the whole LoadChainState / VerifyLoadedChainstate separation seems janky to me. And the logging and timing init.cpp code is doing around these calls also seems awkward. I think a good followup to this PR would get rid for VerifyLoadedChainstate function and just add an bool verify option to ChainstateLoadOptions and move more logging and timing code out of init.cpp.
80-};
81-
82-std::optional<ChainstateLoadVerifyError> VerifyLoadedChainstate(ChainstateManager& chainman,
83- const ChainstateLoadOptions& options);
84+ChainstateLoadResult LoadChainstate(ChainstateManager& chainman, const CacheSizes& cache_sizes,
85+ const ChainstateLoadOptions& options);
re: #25308 (review)
second commit: I wonder if it was easier to review if the two functions were converted in separate commits?
I think it would be harder to review and introduce the potential for bugs in the intermediate commit. If you look code calling these functions in init.cpp you can see it has a lot of cases that need to be handled, and a twisty control flow involving exceptions and changing intermediate variables and timing and log statements. It seems like less of a burden on reviewers and less error prone to update the init.cpp code in one shot, than to change the same code twice and leave it in an intermediate state where the load and verify calls don’t have consistent return styles.
review ACK c7c3059507 🍈
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3review ACK c7c3059507 🍈
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUg6KQv/dRTmRfl2ssxhtuwmONucZd9Ip3Gtl8RLmSZjPBiS2mOO6dD34ZNt1NL7
8/d3chuy5aAf2c3LtQKA0j0qzWQOvb0mz3jUAFiBS50RK/rUAzzcBrvSZpyv/F4IL
9SA3M0gNEfytNxV0uwk8aGAUPAVqoH1hveT2O7NHKcQNEoBq/cchW6TBoQZVZz13E
10IXDuETCcbHp8mXEDSKT+JSDxt5bDBVYJHO9/c3XJO6B7gb2/FWsnx1pgRqmD0iDu
11XD5O9GXq1a8b/hohPHEp7q0VF6m3FOj7fsvlx7g69x6Y0oCoKKtLOAfrbpZUAVm6
12BtU1JzZ0NO9FiAyEsra9z4VymzryaCC488cZMeaQz7SqYaot0vdYTCEHrNJQHk4A
13XnvPjhJbZ+OYIH6a9aWWNPuxK94mjMVCJpzsO2JGF+mzp96W5OGggEDmmffqo5hC
14uRwmmFTBQiX+SRDiae1/8aWbjDReb19He3CvvJ7Ffyo1F/uDUCqLn6ghRRIIj6Ep
15T7mVO8bS
16=ITtH
17-----END PGP SIGNATURE-----
ACK e022eaf87c65e8d7d27d8f5fa4cadc359c843e8a (jamesob/ackr/25308.1.ryanofsky.refactor_reduce_number_o)
The line count reduction speaks for itself! Nice refactor. Initially I was a little sad to lose the error value enums for the chainstate initialization functions, but if we aren’t testing on them or really using them for anything aside from mapping to error strings, I agree that it’s fine to forego them.
Read through commits locally and built each one.
pr/retcode.8 -> pr/retcode.9, compare) due to conflict with #25487
pr/retcode.9 -> pr/retcode.10, compare) due to conflict with #25466
ACK fb31664f94451c51c77393b53274f3a8867ed1d6 🚤
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3ACK fb31664f94451c51c77393b53274f3a8867ed1d6 🚤
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUjCIwv/YUURfo7o0AVAGSJZRLACHRy+lzHJIkI3aMdh895dYKmo1d1aVDNZd2XL
8K6vTGMf2S6RgE4xvtRCz57c5KrfTcjlEgyT1xzZ9ybNOKjnf2a06emZLvgM1T5bg
9i4cp4PJYqJkYlttNqXWawUuUlevYi/eD7uZMQyx2s61AAfWjJM0I8+idJYPmhzWg
10KPMaF6U3amHCX4CRMjQRWUQNlzu1ZZz3d5pBIj+VtVDJ+GnW6NOvgUgsarQD5GQ7
11KmQisteypNvSqd2lRZhIvqr0MLUKoowJlXpDzNZAjtDckC68kBtFPzRRW3ybKlEu
12j7lH3wRpj46rgC1GP8JOWNQ+mJHkKLy9o3lIsT1JCM6vHiOXcH98WmnkEJFIXcix
13dzmmURN+fh+JjL0Ft127iJa40R1mxqxQ/sI/xXgIAkzuZon7Xqt5otU7NhAJgLIf
14fDt6usRDhVD0XD848xpUJ7XkFxlK9BuTAO6BmyWYW7x0naR8O1vGKw6ujiya28u4
15jVaEjRYP
16=vMWy
17-----END PGP SIGNATURE-----
Suggested https://github.com/bitcoin/bitcoin/pull/25308#discussion_r892505713
pr/retcode.10 -> pr/retcode.11, compare) due to conflicts with #25494 and #25645
ACK 1e761a0169ebdbd3b5784af39fc2248b4546eeea 🕚
Signature:
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA512
2
3ACK 1e761a0169ebdbd3b5784af39fc2248b4546eeea 🕚
4-----BEGIN PGP SIGNATURE-----
5
6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
7pUj60wv+IY0G/RNQGAu7vVe19qrbdpSiDWKDuTcsbjIn4nLmwav/SkKO9CbdbUe3
8n4oVsfVGmhksUF/DrTbEd0qrQMw4SH6rUemfrRiQAW5RyZuj9H6uzw7/Kg5xdI5l
94qzP4xf3WLgCJ4Aqk41O3Y1lOyqE0zTt9YVznWutNGGJZh3dYD34kyGGCSd78BbD
10RCaa7ap+sJCF5HQF+aJXqslvBAKvJ0+sXzpbMmOnX2AAUNkYsuGeWOn+5OnKlGgA
11awx5snXIwNDKGrkfUoUeqeP7nVMLjSAqt+HNZYlS6hV7NPL8raxvJhQAVteACOje
12LTFft7Zrni4IzM5ozXVQwpgVAVrCJ/L3pRm90XXvSTWELo07OWj7Dxni/F1twD93
13wY9767zZEfON2Wb/SP33a9DlRbA/o8iVFswfv/Cqzjtl3T+RV9RWgi0ZF3UMpx+q
14xwmLnunLT7hI5MvPKGtyVPZTybK8rn72G1uamb0wLXDh8hCZI2qbZssgfTiJtgm6
15PMzwpr5X
16=jnK3
17-----END PGP SIGNATURE-----