First set up your environment variables as described in Directory Structure Microsoft Windows.
Run the wxWidgets windows setup, wxMSW-X.X.X-Setup.exe. The project will build with wxMSW-3.1.2, and will not build with earlier versions. Or just unzip the file into the target directory, as the install does not in fact do any useful configuration.
Build instructions are in %WXWIN%\docs\msw\install.txt The setup program
for wxWidgets should set the environment variable WXWIN correctly, but does
not do so. Manually set the WXWIN environment variable
When building in Visual Studio, have to retarget the solution to use the current libraries, retarget to use x64, and change the code generation default in every project versions from Multithreaded Dll to Multithreaded (select all projects except the custom build project, then go to properties/C++/code generation/Runtime). The DLL change has to be done separately for release and debug builds, since Debug uses the MTd libraries, and Release uses the MT libraries.
A Visual Studio project needs the library build by the wxWidget Visual Studio project, an nmake project needs the library built by the wxWidget makefile.vs
If you build roWallet under nmake, using Visual Studio tools, you should build your wxWidgets libraries using the using nmake – fmakefile.vc, not the wxWidget Visual Studio project files.
If you build roWallet using the Visual Studio project, you should build your wxWidgets libraries using Visual Studio and the wxWidgets Visual Studio project files.
UDP sockets seem seriously under supported and undocumented in wxWidgets, though theoretically present.
The discussion, however, makes up for the paucity of documentation.
wxWidgets somehow neglects to mention that you need to use the
different and entirely incompatible UDP specific system calls, recvfrom()
and sendto() and instead of read() and write()
If using C sockets, need to pull in completely different header files on Unix than on Windows, including Winsock2 rather than Winsock on windows, but these completely different header files pull in almost the same routines that work in almost the same way.
#ifdef _WIN64
#include <winsock2.h>
#else
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/wait.h>
#include <netdb.h>
#endifIf using wxWidgets, need to build with
#define WXWIN_COMPATIBILITY_3_0 0
#define wxUSE_COMPILER_TLS 2
#define wxUSE_STD_CONTAINERS 1
#define wxUSE_IPV6 1in %WXWIN%\include\wx\msw\setup.h
And for gnu builds, ./configure && make && make install, have to
change them separately and again in configure. What configure actually
does is difficult to understand and predict, so I have put asserts in the code
to detect and complain about unsatisfactory settings.
#ifdef _WIN64
constexpr bool b_WINDOWS = true;
#else
constexpr bool b_WINDOWS = false;
#endif
static_assert( __cplusplus >= 201703l, "Out of date C syntax");
static_assert(wxUSE_IPV6 == 1, "IP6 unavailable in wxWidgets");
static_assert(WXWIN_COMPATIBILITY_3_0 == 0, "wxWidgets api out of date");
static_assert(wxUSE_COMPILER_TLS == (b_WINDOWS ? 2 : 1), "out of date workarounds in wxWidgets for windows bugs");
static_assert(wxUSE_STD_CONTAINERS_COMPATIBLY == 1, "interoperability between stl and wxWidgets broken");
static_assert(wxUSE_STD_CONTAINERS == 1, "wxWidgets api out of date");The two wxWidgets libraries that you build can co-exist because stored in
different directories of %WXWIN%. Unfortunately the visual studio build
projects default to the multithreaded dll, which breaks every other library,
because multithreaded, rather than multithreaded dll, is the usual windows
default used by statically linked libraries. so each subproject in the
wxWidgets Visual Studio project has to be changed to link to multithreaded,
rather than multithreaded DLL. This is a bug, or at least an inconvenient
deviation from usual practice, in the current release of wxWidgets.
If built by a visual studio project, the wxWidgets build constructs a header file in a build location for visual studio projects to use, if built by nmake under visual studio tools, the build constructs a header file in another build location for nmake projects to use.
#ifdef _DEBUG
#pragma comment(lib, "wxbase31ud.lib")
#else
#pragma comment(lib, "wxbase31u.lib")
#endifYou are going to have to setup the environment variables %GSL%, %SODIUM% and %WXWIN% on your windows machines for my visual studio project files to work and going to have to build libsodium and wxWidgets in Visual Studio.
To an unrelated directory tree.
Create an empty desktop project using Visual Studio Wizard. Change the build type displayed at the top of Visual Studio from Debug X86 to Debug X64
In Solution Explorer (a palette-window of the VisualStudio-mainwindow), click on the project name, then click on the properties icon, the little wrench, and then in the left pane of the Property Pages dialog box, expand Configuration Properties and select VC++ Directories. Additional include- or lib-paths are specifyable there.
Set General/C++ Language Standard to ISO(S++17) Standard (std::c++17)
Add to the include paths (properties/configuration properties/VC++ Directories/Include Directories
$(GSL)\include
$(WXWIN)\include\msvc
$(WXWIN)\include
$(SODIUM)\src\libsodium\includeAdd to the lib path (properties/configuration properties/VC++ Directories/Library Directories) the location of the wxWidgets libraries
$(WXWIN)\lib\vc_x64_lib\
$(SODIUM)\Build\Debug\x64Set Linker/System to Windows (/SUBSYSTEM:WINDOWS). This is always set to CONSOLE, for no sane reason, even if you tell it to create an empty windows project.
Put unit test command line arguments (-dt) in Configuration/Debugging/Command Arguments.
Add the header, source, and resource files. The C++ option will then become available in properties. Be mindful that if you edit a wxWidgets *.rc file in Visual Studio, Visual Studio destroys it.
Set C/++/Code Generation/Runtime Library to Multi-threaded Debug(/MTd) in place of multi threaded DLL. When you switch back and forth between release and debug, this is apt to be set incorrectly, for reasons that are hard to keep track of.
Set C++/Preprocessor to _DEBUG, _WINDOWS, in place of _DEBUG, _CONSOLE for the Debug version, and _NDEBUG, _WINDOWS for the release version. If you compile a release version without defining _NDEBUG, a flood of mystery linker error messages ensue, caused by the fact that I use _NDEBUG to select library version, which is an improvement on the previous Visual Studio behavior, where Visual Studio cheerfully generated an executable that mysteriously just died at runtime because of mismatched libraries.
These instructions lifted wholesale from:
Creating wxWidgets Programs with Visual Studio 2017
Hello World Example
When you add the sqlite3.c amalgamation, make sure to mark it as not using precompiled headers before the first attempt to compile it, otherwise it breaks horribly, (C++ format precompiled headers being incompatible with C precompiled headers) and when you belatedly turn off the precompiled headers, some data that Visual Studio has generated hangs around, so that turning off the precompiled headers fails fix the problem.
Similarly, if you do a typo in the include paths. Remains stuck on the old include paths even if you fix it. To do a real clean, close down visual studio, delete the directories generated by visual studio, and then your edits to the configuration will propagate properly
wxWidgets for visual studio should be [installed by the windows installer]
(https://www.wxwidgets.org/downloads/), then follow the instructions in
%WXWIN%\docs\msw\install.md, after adjusting the visual studio projectg
files to build with multithreaded, rather than multithreaded DLL, for to
avoid DLL hell, we are not building with Microsoft DLLs. Set Project to X64.
Visual Studio resource editor will destroy a resource file that is intended for wxWidgets. WxWidgets resource files should only be edited in a text editor.
The native Icon format of wxWidgets is xpm, which does not have built in support for multiple icon sizes, multiple color resolutions, and partial transparency. The greenfish icon editor works to convert any icon format to any other, (though it forgets to include the const qualifier) but, sad to say, native wxWidgets icons, xpm, are lowest common denominator, therefore, crap. And xpm format is also crap, a crap representation of crap data, making windows native bitmap format look good by comparison.
Most of the documentation for wxWidgets is the samples directory, which is set up to build only in the samples directory. To move a project out of the samples directory, and get it compiling in the environment you have set up for your code in Visual Studio, copy the sample, and copy the resources its needs into your target directory, then correct the sample, so that instead of looking for resources relative to itself, in the wxWidgets directory, it looks for its rc file and stuff in its new home directory. You will need the resource files from the root of the samples, and possibly some files from samples/images.
Due to a persistent bug in visual studio, probably need to delete the generated project studio files so that the new values will take effect. Do not touch *.rc files with Visual Studio resource editor, or it will break them.
I never succeeded in doing this, so there are probably no end of gotchas of which I am unaware.
[Run the wxWidgets windows setup, wxMSW-X.X.X-Setup.exe] (https://github.com/wxWidgets/wxWidgets/releases/). The project will build with wxMSW-3.1.2, and will not build with earlier versions
[Build wxWidgets] (http://wiki.codeblocks.org/index.php/WxWindowsQuickRef). See also the instructions in wxWidgets-X.X.X/docs/msw/install.txt, or docs/msw-X.X.X/install.md. CodeBlocks on windows wants you to build in the command window.
Install Code::Blocks.
Do the Code::Blocks [hello world tutorial] (http://wiki.codeblocks.org/index.php?title=WxSmith_tutorial%3a_Hello_world).
But Code::Blocks looks suspiciously dead.
Install build essentials, and gtk (gtk being the build essentials for Ubuntu GUI) The native and home environment of wxWidgets is the Mate fork of Gnome, and it is behavior in all other environments is derived from this behavior.
sudo apt-get install libgtk-3-dev build-essential checkinstallThese instructions copied from How to compile and install wxWidgets on Ubuntu/Debian/Linux Mint more or less wholesale.
Download Source code tar.gz from the latest releases.
Place the source in the directory code/wxWidgets/.
See the instructions in
code/wxWidgets/docs/gtk/install.txt
cd code/wxWidgets
mkdir gtk-build
cd gtk-build/
./configure --disable-shared --enable-unicode
makeIn C++17, if you are using exceptions, everything is owned by the stack, and
heap values are owned by stack variables which release the heap value in
their destructor. std::unique_ptr and std::shared_ptr, and your own
custom heap owning objects.
In wxWidgets, ownership is complicated, because different aspects of ownership are owned in different hierarchies.
The destructors of modal windows get called in the normal fashion, but modeless windows are always referenced in derived code by non owning pointers pointing into the heap. They are owned by their parent window when their constructor calls its base constructor, and their derived destructor somehow mysteriously gets called by wxWidgets after wxWidgets finishes destroying all the windows that the higher level window owns.
Suppose you have a complicated window with a complicated hierarchy of modeless windows in a complicated hierarchy of sizers.
Suppose it wants to destroy one of its many children?
Then it asks the child for the child’s sizer, detaches it, calls destroy on the child, which somehow eventually calls the highly derived child destructor, and tells the sizers to do layout again.
A sizer full of windows can be treated as if it was an owning window by calling wxSizer::Clear on it with the argument to delete child windows. But otherwise the owning window that wants to delete one particular window by derived code has to do so by non owning pointers pointing into the heap
wxWidgets has a windows hierarchy, with windows owning windows, with memory ownership by windows, and events being passed up the hierarchy.
wxWidgets has the bind hierarchy, where an object can get events from an object with a different lifetime, so it has to unbind in its destructor. (Exept in the normal case where all graphical objects get constructed at the start of the program and destructed at the end of the program.)
And wxWidgets has the sizer hierarchy, which allocates screen space to child windows within the parent window.
Sizer objects have to be detached, and then explicitly deleted, and child windows have to be detached from the sizer hierarchy, then explicitly destroyed. And then you call layout on the master sizer of the owning window.
And then you have the tab hierachy. You have to tell the main window the tab order of its child windows, which is by default the order of their creation.
If you are potentially managing an indefinitely large number of windows, like a browser, you need the wxNotebook control. (Which lacks a close button on the tabs)
So, most complex case: You have sizer that acts like a window within a larger window. It is a sizer within a larger sizer. It gets constructed in response to user events, and destructed in response to user events, while the main window continues. The windows within the frame are direct children of larger window, and they are also children of the sizer, which is a child of the main sizer, which is owned and controlled by the larger window.
But, for future integration with wxNotebook, probably best to put it into an object of type wxPanel. So you define an object that will contain ordinary dumb pointers to all these objects, which takes the parent window and the parent sizer as a arguments. On construction it constructs all the wxWidgets child windows that it needs, with the main window as their window parent, puts them into its sizer and prepends its sizer to the main sizer as their sizer grandparent, binds them, calls layout on the main sizer, and on destruction unbinds them, detaches them from their sizer, calls delete on the sizer objects, then destroy on the window objects and then calls layout on the main sizer.
But the way the experts do it is to make that object a wxPanel window.
On construction, first construct windows, then put them into the sizer, then bind them, then call layout. On destruction, first unbind, then detach from sizer, then destroy sizer objects, then destroy windows objects, then call layout on the main sizer.
Generates an event based program with no gui, console input and console output. Should use only objects in wxBase. wxBase is a separate library, and you should avoid linking to all the other libraries, except wxNet, and not even wxCore, because if you are linking to another library, the other routines in the other library will expect a gui.
Our program that synchronizes with other peers is going to need to run as a daemon on Linux and service on windows, with no UI except it talks to the client wallet, which will run as a regular gui program, possibly on another machine far away.
It is probably easier if we use the same library, wxWidgets, for OS independence for both daemon and client.
[wxWidgets mailing list.] (https://www.wxwidgets.org/support/mailing-lists/guide/) I have never used this. I have often had my share of grief on wxWidgets, but by the time I reduced it to a problem capable of being addressed on the mailing list, the problem was always solved.
Which tells me that wxWidgets is pretty good, and the considerable grief that it generates is only that which is inevitable on a multiplatform gui.
Supports Ristretto25519, the crypto tool that I am competent to use. Nothing else seems to support this.
Libsodium is the authoritative library, derived most directly from Bernstein.
git clone https://github.com/jedisct1/libsodium.git
cd libsodiumCompiled as a separate project under visual studio. Retarget the solution to use the current libraries, retarget to use x64, and change the code generation default (properties/C++/code For the your visual studio project to include the sodium.h file, have to define SODIUM_STATIC before including the header file when linking to the static sodium library.
#define SODIUM_STATIC
#include <sodium.h>
#pragma comment(lib, "libsodium.lib")To link to libsodium.lib have to add $(SODIUM)\Build\Debug\x64 to Visual Studio/project properties/linker/General/Additional Library Directories, where SODIUM is the environment variable pointing to the root libsodium directory, and similarly for the Release version of your code $(SODIUM)\Build\Release\x64. Assembly code is disabled by default, need to re-enable it once unit test works with encrypted utd communication.
We need to eventually re-organize as a git subproject and autotools subproject, but, for the moment, it is a separate library project, hence the environment variable SODIUM.
Might be better to not use environment variables $(SODIUM) and to use Git submodules and autotools submodules instead, was wxWidgets does internally.
Set the libsodium project properties to DebugLib x64
Set the libsodium project properties/General/configuration type to static (should be static already if you have selected Debug Lib and ReleaseLib)
It provides all the crypto algorithms you need, including Argon2 for password stretching, and freedom from NSA. Neglects to include base 58 encoding. Wrote my own base 64 library, which differs from the standard base 64 library in being oriented to small items, addressing arbitrary bit fields rather than blocks of three bytes, in being url safe, and in mapping 0, o, and O to zero, and mapping 1, i, I, and l to one, to allow for human entry.
Going to need an algorithm for generating passphrases, but passphrases will be hashed and argoned,
Sqlite is not incorporated as an already built library, nor as a library at all, but as source code.
When you add the sqlite3.c amalgamation, make sure to mark it as not using precompiled headers before the first attempt to compile it, otherwise it breaks horribly, (C++ format precompiled headers being incompatible with C precompiled headers) and when you belatedly turn off the precompiled headers, some data that Visual Studio has generated hangs around, so that turning off the precompiled headers fails fix the problem.
Similarly, if you do a typo in the include paths. Remains stuck on the old include paths even if you fix it. To do a real clean, close down visual studio, delete the directories generated by visual studio, and then your edits to the configuration will propagate properly
When creating the database, should turn WAL on:PRAGMA journal_mode=WAL; PRAGMA synchronous=1; but before distributing it, make sure the WAL file has been cleaned out with sqlite3_close().
Wal mode ensures that we never get a busy error from normal business, only under abnormal conditions, provided that only one thread in one process ever writes to the the database. Which means we do not face the hard problem of handling the busy error.
We have also chosen our threading model so that database connections and their associated compiled sql statements are thread local, but one database connection can be connected to many databases, and each database can have many database connections from many threads and many processes
Wal mode in the default settings means that writes are normally instantaneous, because they do not hit the disk, but every so often, on completing a transaction, four megabytes get written to disk (which saves a whole lot of read/writes to disk, replacing them with sequential writes without too many reads). So it is probably not a good idea to download large amounts of data from the internet on the UI thread, because every so often the write thread is going to do four megabyes of actual write to actual disk.
In Wal mode, recently “written” transaction data will be read from memory. So it is a premature optimization to keep data in program memory, when the same data is probably in Wal memory or in cache.
Because Wal writes are near instantaneous, multiple threads writing seldom block each other – but if one thread is busy writing while the previous thread is busy flushing four megabytes of actual data to disk, the Wal file may grow excessively. According to the documentation, a write thread does the flushing, but it looks to me that a background thread does the flushing.
But the UI thread will typically only be doing reads and writes every now and then, so if one has only one continually writing thread, you don’t have to use restart or full which means you very rarely get busy calls, so do not have to handle them elegantly and efficiently.
I suspect that the wal file gets cleaned mighty fast, so before doing anything clever, measure.by running PRAGMA wal_checkpoint every minute or so, which returns a table of one row and three columns telling you how much stuff needs to be written when the checkpoint started, and how much was going to be written when it completed, leaving another thread working on actually writing it. (Two PRAGMA wal_checkpoints in rapid succession are apt to give the same answer) Also log how long the checkpoint took. If the second column is substantially larger than a thousand, and the third column is kind of small, you have a checkpoint problem. This problem is unlikely to happen, because the disk has a much bigger pipe than the network, so it looks to me that with the usual settings, wal and passive checkpointing, all the actual disk write IO is going to take place in a backround thread, because we are just not going to be disk bound on updates and writes. We may find ourselves disk bound on random access reads, but Wal, transactions, and checkpoints are not relevant to that problem.
del C:\Users\studi\AppData\Local\RoBlockchain\RoData3cx8bdx.sqlite
sqlite3 C:\Users\studi\AppData\Local\RoBlockchain\RoData3cx8bdx.sqliteWhere the file RoData3cx8bdx.sqlite contains:
PRAGMA encoding = "UTF-8";
PRAGMA journal_mode=WAL;
PRAGMA foreign_keys = OFF;
PRAGMA synchronous = 1;
CREATE TABLE w( --wallets
PublicKey BLOB PRIMARY KEY NOT NULL UNIQUE,
Name TEXT NOT NULL UNIQUE, – automatically creates index
PetName TEXT,
title TEXT
);
CREATE TABLE MasterSecret(
PublicKey BLOB PRIMARY KEY NOT NULL UNIQUE,
Secret BLOB,
Expires INTEGER NOT NULL,
FOREIGN KEY(PublicKey) REFERENCES w(PublicKey)
);
INSERT INTO w VALUES(X'deadbeef','Adam',NULL,NULL);
.dump
.output RoData3cx8bdx.sql
.dump
.exitWe are stashing everything in the user specific directory wxStandardPaths::GetAppDocumentsDir()
and the user specific database, which is wrong. Eventually we will need two databases, one global to all users on a particular machine, which you select when you install, and one for each particular user, that gets generated when the particular user first runs his wallet.
Further confusing matters, wxConfigBase settings are always per user on windows.
At the moment, only one database and one config object.
In our own code, we don’t need to issue PRAGMA synchronous = 1; PRAGMA foreign_keys = ON; because we modify the sqlite3.c with the following:
I need to customize the sqlite3.c almalgamation with my own custom compile options as follows.
//My custom compile options
#define SQLITE_DQS 0 //Doublequote names, single quote strings. This setting disables the double – quoted string literal misfeature.
#define SQLITE_THREADSAFE 2 //One thread, one database connection. Data structures such as compiled SQL are threadlocal. But sqlite3 is empowered to do its own multithreading. Many databases per database connection. Database connection and compiled sql statements are threadlocal. last_insert_rowid() is not subject to race conditions in this mode, returning the most recent rowid generated by the thread.
#define SQLITE_DEFAULT_MEMSTATUS 0 //Don’t track memory usage. Disables the ability of the program using sqlite3 to monitor its memory usage. This setting causes the sqlite3_status() interfaces that track memory usage to be disabled. This helps the sqlite3_malloc() routines run much faster, and since SQLite uses sqlite3_malloc() internally, this helps to make the entire library faster.
#define SQLITE_DEFAULT_WAL_SYNCHRONOUS 1 // in WAL mode, recent changes to the database might be rolled back by a power loss, but the database will not be corrupted. Furthermore, transaction commit is much faster in WAL mode using synchronous=NORMAL than with the default synchronous=FULL. For these reasons, it is recommended that the synchronous setting be changed from FULL to NORMAL when switching to WAL mode. This compile-time option will accomplish that.
#define SQLITE_DEFAULT_FOREIGN_KEYS 0 //Dont handle foreign key constraints. Programmer has to do it himself.
#define SQLITE_LIKE_DOESNT_MATCH_BLOBS 1 //Blobs are not strings. Historically, SQLite has allowed BLOB operands to the LIKE and GLOB operators. But having a BLOB as an operand of LIKE or GLOB complicates and slows the LIKE optimization. When this option is set, it means that the LIKE and GLOB operators always return FALSE if either operand is a BLOB. That simplifies the implementation of the LIKE optimization and allows queries that use the LIKE optimization to run faster.
#define SQLITE_MAX_EXPR_DEPTH 0 //Setting the maximum expression parse-tree depth to zero disables all checking of the expression parse-tree depth, which simplifies the code resulting in faster execution, and helps the parse tree to use less memory.
#define SQLITE_OMIT_DECLTYPE 1 // By omitting the (seldom-needed) ability to return the declared type of columns from the result set of query, prepared statements can be made to consume less memory.
#define SQLITE_OMIT_DEPRECATED 1
#define SQLITE_DQS 0 //Don’t accept double quoted string literals.
#define SQLITE_OMIT_PROGRESS_CALLBACK 1
#define SQLITE_OMIT_SHARED_CACHE 1
#define SQLITE_OMIT_UTF16 1
#define SQLITE_USE_ALLOCA 1 //Make use of alloca() for dynamically allocating temporary stack space for use within a single function, on systems that support alloca(). Without this option, temporary space is allocated from the heap
#define SQLITE_OMIT_LOAD_EXTENSION 1
#define SQLITE_TEMP_STORE 3 //Temporary files are in memory
#define SQLITE_OMIT_AUTOINIT 1 //.The SQLite library needs to be initialized using a call to sqlite3_initialize() before certain interfaces are used.This initialization normally happens automatically the first time it is needed.However, with the SQLITE_OMIT_AUTOINIT option, the automatic initialization is omitted.This helps many API calls to run a little faster(since they do not have to check to see if initialization has already occurredand then run initialization if it has not previously been invoked) but it also means that the application must call sqlite3_initialize() manually.If SQLite is compiled with – DSQLITE_OMIT_AUTOINIT and a routine like sqlite3_malloc() or sqlite3_vfs_find() or sqlite3_open() is invoked without first calling sqlite3_initialize(), the likely result will be a segfault
//end my custom compile options*/To compile the standard sqlite3.exe tool.
We don’t need to issue PRAGMA journal_mode=WAL; PRAGMA schema.synchronous = 1; in our own code except if we create a new database, which our code will
typically not do, because our install will copy a working database.
In our code, we do need to issue PRAGMA optimize; on close.
Missing from their short summary of the C interface is:
/*
** Return UTF-8 encoded English language explanation of the most recent
** error.
*/
SQLITE_API const char *sqlite3_errmsg(sqlite3 *db)The general rule being that for any unexpected value of rc, any value other than SQLITE_OK, SQLITE_ROW, and SQLITE_DONE, display that message. sqlite3_exec wraps this, but we should probably not use sqlite3_exec.
SQlite’s pragma for identifying that something is the right application file format does not seem to work, or maybe it does work and there is some magic that I am not aware of. But this does not matter, because it only protects against Murphy, not Machiavelli, and we are going to need to guard against Machiavelli.
We need to make sure that compiled sql statements are only compiled after the database connection is live, and destroyed before the database is closed.
The order of construction and destruction within an object is
Objects on the stack are destroyed in the reverse of the order that they were declared.
The gui object that enables the user to manipulate the contents of the database should contain the database connection, and the compiled sql objects that manipulate the database, declared in that order, so that they get destroyed in that reverse order, compiled sql being destroyed before the database connection is destroyed, and so that in order to create the gui to manipulate the database, we have to first construction a database connection. Since the creation could throw, and we need to handle the throw in the gui, we need a gui already constructed, which then attempts to construct more gui, and informs the user if the construction fails.
So the outer gui figures out a plausible database name, and then attempts to construct the inner gui whose constructor then attempts to open a database connection and make sure the database is in a good state, and throws if it cannot construct a good connection to a good database.
To protect against Machiavelli, peers have to by default check the early part of the block chain to make sure it has the correct hash, preferably in obfuscated and undocumented code, accessed through a define located in a rather random header file so that Machiavelli will have to audit my code, then supply his victims with the new code as well as the new database. Or just hard code the genesis block, though Machiavelli will have an easier time finding that one. Maybe both. Hard code the genesis block, and have obfuscated hard code for the early blocks.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.