...

diff --git a/RATIONALE.txt b/RATIONALE.txt
new file mode 100644 (file)
index 0000000..269a106
--- /dev/null
+++ b/RATIONALE.txt
@@ -0,0 +1,27 @@
+Technical Choices Rationale:
+
+#########################################################################################
+Q: Why C?
+
+A: Multiple reasons.
+
+Firstly, to minimize dependencies. Auditing lots of packages and monitoring for updates is a major concern for a project like this. This minimizes the surface area for vulnerabilities.
+
+It is also the easiest way to interface with some of the utilities used. Building an application in the same language which the operating system uses allows for some bindings directly into kernel functionality and apis/libaries native to the operating system. This allows for reducing the amount of dependencies even further and minimizes the need to farming out functionality to shell commands.
+
+Finally, there is a clear path for removing the final major dependency (Bitcoin Core) if C is used. The major limiting factor in implementing the descriptor functionality is the elliptic curve functionality which could be replaced by libsecp256k1, an open source library written in C.
+
+#########################################################################################
+Q: Bitcoin Core is written in C++, QT exists, why not use that? 
+
+A: Frankly, I'm not a fan of C++'s aesthetics. Too much is hidden behind abstractions and can make the code difficult to read. I think it is harder to audit for that reason. On net, I think the balance of our gains from C++ (can grab code out of Bitcoin Core directly) do not outweigh the negatives (have to use C code to interface with OS anyways; that means development will have to support 2 languages).
+
+#########################################################################################
+Q: Why not Go/Rust/Python/JS/etc.?
+
+A: I don't know Go/Rust/Python. My experience with using python tools has been nothing but dependency hell. JavaScript attack surface seems too large and also has dependency issues. Rust/Go don't seem to have fully fleshed out GUI libaries (the best ones seem to be bindings to qt and gtk) nor easy libraries to interface with some of the dependencies/tools used in the initial setup. The ones that exist are mostly wrappers to C libaries or shell commands themselves. I'm also interested in making this project reproducible, and condensing project down into a single binary is key for that, hence only compiled languages should be considered.
+
+#########################################################################################
+Q: Why Debian/Ubuntu?
+
+Familiar with Debian. Ubuntu is the easiest distribution to setup and is based on Debian.

diff --git a/README.txt b/README.txt
index 9f5baf0ac0b4015881f272b3f8f7ad7e1108211f..d8902182b1466e94bcd6c76d6af37d2ddb66d202 100644 (file)
--- a/README.txt
+++ b/README.txt
@@ -1,8 +1,14 @@
 Project Summary:
 This project is meant to replace and provide additional tooling for a cold storage setup created in an ad-hoc manner using a few small utilities and Bitcoin Core.
 
+Contents:
+I. Summary of Manual Setup
+II. Project Rationale
+III. Architecture
+IV. Later Goals
+
 #########################################################################################
-Run Through of Initial Setup:
+I. Summary of Manual Setup:
 The initial setup consisted of a bunch of shell commands and requires the following Debian packages:
 
 `apt-get install -y cryptsetup eject jq nmcli shred`
@@ -110,8 +116,8 @@ signed.psbt was transferred back to the "live" computer and broadcast to the Bit
 Funds were sent to the multi-signature addresses and another wallet and back multiple times using different combinations of keys (i.e. separately with keys 1-3, keys 4-6, and with keys 2, 5 , and 7) each time completely wiping and restoring the "clean" computer.
 
 #########################################################################################
+II. Project Rationale
 
-Rationale for project:
 Setup is difficult even for experienced technical users, mistakes can be made and since process is manual and contains a lot of manual checking, unknown failure modes certainly exist. Automated tooling to aid creating and verifying setup URGENTLY needed. GUI creation would allow for non-technical (or minimally technical users) to create robust custody solutions.
 
 Goal:
@@ -124,7 +130,7 @@ Note on dependencies:
 Security is paramount on a project like this. Using only open-source, validated, widely used software is a must. Minimizing dependencies should be a goal of any implementation.
 
 #########################################################################################
-Architecture:
+III. Architecture
 
 Programming Language: C
 Build Tooling: gnu autotools
@@ -141,8 +147,8 @@ Primary problems to tackle:
 Three primary GUI flows need to be created.
 
 First flow is satisfying dependencies:
--automated installing of required packages: jq, mkfs.ext4 (part of the e2fsprogs package)
--automated installing and validation (requires gpg?) of Bitcoin Core
+-automated installing of required packages: jq, mkfs.ext4 (part of the e2fsprogs package), curl (for downloading Bitcoin Core), gpg (for validating Bitcoin Core)
+-automated installing and validation of Bitcoin Core
 -once all dependencies setup, shutdown networking and start Bitcoin Core
 
 NOTE: mount/umount have C bindings (see `man mount.2` and `man umount.2`). The functionality of nmcli, shred, eject, base64, and wipefs should be able to be easily extracted from source-code of their respective packages and can be eliminated as dependencies. The rest of the commands used above (echo, tr, cat, dd)  can be eliminated by simple functions.
@@ -153,18 +159,22 @@ Second flow is creating multi-signature setup:
 -walkthrough for setting up a live wallet in Bitcoin Core on a separate computer
 
 Third flow is restoring wallets and signing a psbt:
+-instructions for generating a psbt, transferring via usb, validating transfer was successful
 -loading psbt into GUI
 -insert usb, decrypting, load wallet, signing psbt, saving result, unloading wallet
 -saving completed psbt
 
-In addition to the three primary flows, extensive testing framework should be created to validate setup.
+In addition to the three primary flows, extensive testing framework should be created to validate setup. This testing framework should be able to interact with other Bitcoin software (i.e. Bitcoin Core) and validate results.
 
 Avoid dymically (malloc, etc.) allocated memory.
 
 #########################################################################################
-Later:
--use Yubikey instead of passphrase
--flow for testing setup
--flow for signing a message
--remove dependency on Bitcoin Core, jq
--remove dependency on mkfs.ext4
+IV. Later Goals
+
+Primary extension goal would be to allow Yubikeys instead of passphrases to encrypt usbs. Technically should be a minor modification, although will probably require additional dependencies.
+
+It would also be nice to have a GUI flow setup for testing configuration and wallet setup. Passing psbts around, signing, checking usb validity, etc.
+
+Could possibly see use cases for signing arbitrary messages.
+
+The major technical improvement would be to remove the dependency on Bitcoin Core (and by extension jq) and replace with custom descriptor functionality and libsecp256k1 (https://github.com/bitcoin-core/secp256k1).