edgecase
27. Item, the said abbot doth daily embezzle, sell, and convey the goods and chattels, and jewels of the said monastery, having no need so to do: for it is thought that he hath a thousand marks or two thousand lying by him that he hath gotten by selling of orders, and the jewels and plate of the monastery and corradyes; and it is to be feared that he will alienate all the rest, unless your good lordship speedily make redress and provision to let the same.
Author: StJohn Piano
Published: 2018-09-25
Datafeed Article 60
This article has been digitally signed by Edgecase Datafeed.
This article has been digitally signed by its author.
7760 words - 2966 lines - 75 pages




GOAL



Verify a signed deed of the source code for Gnu Privacy Guard (GnuPG or GPG) 1.4.10.





CONTENTS



- Goal
- Contents
- Brief Summary
- Summary
- Downloadable Assets
- Notes
- Further Work
- Project Log





BRIEF SUMMARY



I have confirmed that the file
gnupg-1.4.10.tar.gz.asc
in my possession was in fact:
- signed by Mircea Popescu's public key
- deeded (timestamped in the Bitcoin blockchain) in a transaction in block 378272 (datetime 2015-10-10 13:00:31)








SUMMARY



I have confirmed that the file
gnupg-1.4.10.tar.gz.asc
in my possession was in fact:
- signed by Mircea Popescu's public key
- deeded (timestamped in the Bitcoin blockchain) in the mainchain block at blockheight 378272 with datetime 2015-10-10 13:00:31 by a transaction that sent 0.0001 bitcoin to the address
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
The transaction has this transaction id (txid):
597f61fa3811a78a9d401094e4132f281c400b61bb8742514ab758aad0e2daa0



I used GPG 2.0.14 on a VPS to confirm that Mircea Popescu's signature is mathematically valid.


For a description of how I verified the deed timestamp, please see the "How I found the confirmational transaction for a specific signed deed" part of the Notes section.


The Notes section contains these parts:
- Acronyms
- Systems used
- Deedbot
- How I found the confirmational transaction for a specific signed deed
- GPG
- Miscellaneous








DOWNLOADABLE ASSETS



The next linked asset is a script that generates a standard Bitcoin address from a private key in raw byte form (e.g. "hello_world") or in hex byte form (e.g.
"b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346")

generate_bitcoin_address_2.py [paywalled]

This is a new version of
generate_bitcoin_address.py [paywalled],
which is an asset of the article Generating a standard Bitcoin address. Please see this previous article for details concerning the use of this asset.

Changes:
- Line 40 has been added. It contains the following text:
private_key_hex2 = private_key_hex


This fixes the problem in the previous version where, if
private_key_hex
is already 32 bytes long, the
if
statement on line 42 won't execute, and the variable private_key_hex2 won't be created, causing an error on line 45.


The next linked asset is a copy of GPG 1.4.10, signed by Mircea Popescu and deeded in a transaction in Bitcoin block 378272 (datetime 2015-10-10 13:00:31).

gnupg-1.4.10.tar.gz.asc


The next linked asset is Mircea Popescu's public key. It is stored as an asset of the article Compiling bitcoind (trb 0.5.4) on Debian 7.11.

mircea_popescu.asc


The next three linked assets are dependencies of
generate_bitcoin_address.py
and were used in this project. They are stored as assets of the article Reading and verifying a standard raw bitcoin transaction.

Please see the previous article Generating a standard Bitcoin address for details concerning the use of these assets as dependencies of
generate_bitcoin_address.py.

bjorn_edstrom_ripemd160.py [paywalled]

ecdsa-0.10.tar.gz [paywalled]

pypy_sha256.py [paywalled]








NOTES



Parts:
- Acronyms
- Systems used
- Deedbot
- How I found the confirmational transaction for a specific signed deed
- GPG
- Miscellaneous




Acryonyms


- GPG or GnuPG = GNU Privacy Guard
- GNU = GNU's Not Unix
- VPS = Virtual Private Server




Systems used


My system:
- Name = SP_THINKPAD_1. SP stands for StJohn Piano.
- Hardware = Lenovo Thinkpad X200 (Laptop). Two internal hard drives, each of 75 GB capacity.
- Processor = Intel(R) Core(TM)2 Duo CPU, P8600 @ 2.40GHz
- Memory (RAM) = 4.00 GB
- Operating System = Windows 7 Professional (Service Pack 1), 64-bit

I installed Cygwin on SP_THINKPAD_1 during a previous project: Installing Cygwin on Windows 7

I installed OpenSSH on Cygwin during another previous project: Installing OpenSSH on Cygwin and using it to access a VPS

During this project, I used OpenSSH to access a VPS, where I performed most of the verification work.

VPS details:
- Provider: DigitalOcean
- Distribution = CentOS 6.9 x64
- Memory = 1 GB
- vCPUS = 1 vCPU
- SSD Disk = 25 GB
- Transfer = 1 TB
- Price = $5/mo, $0.007/hr
- Datacentre region = London
- hostname = spt1
- SSH Key = SP_THINKPAD_1
- IP address = 178.62.36.113
- domain = edgecase-test.net

I used the tool
sftp
, which is part of the OpenSSH package, to upload files from SP_THINKPAD_1 to the VPS.


"cygdrive" is a symbolic link within Cygwin to the "Computer" directory on Windows, which contains the mounted disk drives (e.g. the main C: drive).

Below is a example showing how to use the cygdrive symbolic link to access the C: drive filesystem on the main Windows 7 system.

Admin@Admin-PC ~

$ pwd
/home/Admin

Admin@Admin-PC ~

$ ls -1 /
bin
cygdrive
Cygwin.bat
Cygwin.ico
Cygwin-Terminal.ico
dev
etc
home
lib
proc
sbin
tmp
usr
var

Admin@Admin-PC ~

$ ls -1 /cygdrive
c
d
e

Admin@Admin-PC ~

$ cd /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source

Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source

$ ls -1
notes.txt
tmp.txt
to_do.txt
work





Deedbot


Deedbot is an IRC chatbot owned and maintained by trinque that timestamps new bundles of submitted items ("deeds") on the Bitcoin blockchain. Items can only be submitted by trusted counterparties.

According to the documentation on deedbot.org, this is accomplished by:
1) hourly collection of all new submitted items into a new bundle.
2) all submitted items in the new bundle are joined with a single newline (i.e. a newline is placed between every pair of items).
3) calculating the SHA256 hash digest of the result of (2).
4) treating the result of (3) as a Bitcoin private key and deriving a Bitcoin address from it.
5) making a transfer of a small amount of bitcoin to this address, which timestamps the first appearance of this address on the Bitcoin blockchain, and thus timestamps the existence and exact contents of the bundle of submitted files, making them tamper-proof.

Note: As long as the Bitcoin blockchain remains protected by a high mining hash rate, it is unalterable by a third party. The deeds are tamper-proof because the transaction inserts a hash of their contents (formatted into an address) into the Bitcoin blockchain. If they are changed, and the bundle of deeds is put through the verification process, a different hash (and therefore a different address) will be produced, for which no confirmational transaction will be found.

Note: Address collisions are possible but extremely unlikely. However, I will note that it is theoretically possible that:
a) a deed is altered and a different address is produced by the deed verification process.
b) another unrelated transaction in the specific block spends to this address, thereby confirming the altered version of the deed.

[Untested] I think that the submitted items are concatenated together in the order in which they were received.

In this context, "timestamping" should really be called "blockstamping", as this process only proves that an address first appeared in a particular block at a particular blockheight. Blocks include a timestamp, and miners try to maintain time synchronisation (I vaguely recall that a new block is invalid if its timestamp value is too much greater than the previous block's timestamp value), but the timestamp is less accurate than the blockheight.

Deed properties displayed on the page
deedbot.org:
- blockheight (at which the timestamp block appears)
- address (Bitcoin address)
- author (GPG fingerprint, without spaces)
- deed number (1-indexed, probably indicates relative position within a bundle)
- source

The source value is usually 'None', but sometimes it is e.g.:
"http://files.bitcoin-assets.com/log/2016-01.txt"




How I found the confirmational transaction for a specific signed deed


I was able to find the deed submission datetime from the #trilema chat channel log.

#trilema chat channel log excerpt:
btcbase.org/log/2015-10-10#1295983

mircea_popescu: deedbot- http://trilema.com/wp-content/uploads/2015/10/gnupg-1.4.10.tar.gz.asc


The datetime was stored as a title attribute of this log line. Its value was:
Sat, 10 Oct 2015 12:08:05 GMT

Starting from the timestamp of block 500000, and using the fact that the time between blocks is approximately 10 minutes, I then calculated the approximate blockheight of this datetime: 378265
This calculation required multiple iterations. During each iteration, I used a blockchain information service to look up the timestamp at the calculated blockheight, and, using this timestamp, recalculated a new candidate blockheight.

I scrolled down the page displayed at
deedbot.org
looking for the blockheight 378265.
I found two deeds with these blockheights:
378272
377215

Blockheight 378265 is not shown but lies between 377215 and 378272.

The block at blockheight 378272 is the next deed block that occurs after the deed submission time. Browsing to the deed at blockheight 378272 and viewing the beginning of its contents confirmed that this was the correct block.

Note: bundle-378272.txt contains only one deed item. If it had contained multiple concatenated deed items, I might have had to find and read the beginning of each deed item in order to see whether the desired deed item was included in the bundle.

Clicking the deed blockheight number led to:
deedbot.org/bundle-378272.txt
I downloaded a copy of this file.
I then used
diff
to confirm that this deed bundle is identical to the copy of
gnupg-1.4.10.tar.gz.asc
that I originally downloaded from
trilema.com/wp-content/uploads/2015/10/gnupg-1.4.10.tar.gz.asc

I calculated the SHA256 hash digest of bundle-378272.txt, treated this as a Bitcoin private key, and derived the corresponding Bitcoin address:
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X

Within the block at blockheight 378272, I found a transaction that transferred bitcoin to Bitcoin address:
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
It has this transaction id (txid):
597f61fa3811a78a9d401094e4132f281c400b61bb8742514ab758aad0e2daa0


I found information about this transaction displayed at:
www.blockchain.com/btc/tx/597f61fa3811a78a9d401094e4132f281c400b61bb8742514ab758aad0e2daa0

Transaction details:
- datetime: 2015-10-10 13:00:31
- source address:
1BkCTj36DMdcF8TVa1by9zfwdcMFm3VAES (0.0916 BTC)
- destination addresses:
1BkCTj36DMdcF8TVa1by9zfwdcMFm3VAES (0.0914 BTC)
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X (0.0001 BTC)
- total input: 0.0916 BTC
- total output: 0.0915 BTC
- size: 259 bytes
- fee: 0.0001 BTC

Further investigation showed that there was a later transaction that transferred the available bitcoin out of the deed bundle address 6 days later.

The txid of this second transaction:
eebd52abd46762a172be87fe8c0a463476a7f6f709a5e9ebd929d86822be0f1c


I found information about this second transaction displayed at:
www.blockchain.com/btc/tx/eebd52abd46762a172be87fe8c0a463476a7f6f709a5e9ebd929d86822be0f1c

Second transaction's details:
- datetime: 2015-10-16 21:28:23
- source addresses:
19mxAPvaFDnArssXDRXKmJXeboBoVoD6er
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
- destination address:
1Pb8RBEy24hTyajq1gecDNcif9EQZqjbQT (0.0001382 BTC)
- total input: 0.0002 BTC
- total output: 0.0001382 BTC
- size: 406 bytes
- fee: 0.0000618 BTC


Note: Calculating the Bitcoin address from the deed bundle and finding a transaction to it in the correct block confirmed the timestamp of the signed deed.




GPG


In the GPG FAQ at
www.gnupg.org/faq/gnupg-faq.html
I read that:
- Using the
--armor
flag will cause GnuPG to generate output containing only printable characters.
- An "inline signature" is the result of using the
--clearsign
flag.


In the signed deed verified in this project, Mircea Popescu stated that:
- The signed deed contains a base64 blob of gnupg-1.4.10.tar.gz which is a historically accurate archive of GnuPG version 1.4.10.
- He does not think that there is anything wrong with GPG 1.4.x, so the minor version number ("10") in the version string 1.4.10 is not intended to be significant.
- He thinks that the use of GnuPG 2.x is irresponsible and harmful.




Miscellaneous


Mircea Popescu's key's fingerprint is 6160 E1CA C8A3 C529 66FD 7699 8A73 6F0E 2FB7 B452.
Without spaces:
6160E1CAC8A3C52966FD76998A736F0E2FB7B452


A previous project, Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin, includes a basic guide to
vi
commands. Browse to the article and search for the string "# WHAT IS VI?".

Some reading indicates that
vim
is an extension of the
vi
editor, and most of the
vi
commands work the same way in
vim
.


Altering project logs (as opposed to adding patches / clarifications / expansions), carries a risk of incomplete / inconsistent alteration, which may cause more problems than it solves. So, unless removing clues for adversaries, it's better to try to avoid altering your project logs.








FURTHER WORK



Verify a deed bundle containing more than one item.
- Check whether submitted items are concatenated together in the order in which they were received.
- Confirm that a newline character is inserted between every pair of submitted items.








PROJECT LOG




In 2015, Mircea Popescu deeded a signed copy of GPG 1.4.10.


#trilema chat channel log excerpt:
btcbase.org/log/2015-10-10#1295983

mircea_popescu: deedbot- http://trilema.com/wp-content/uploads/2015/10/gnupg-1.4.10.tar.gz.asc




Explanation:
- "deeding" = the act of timestamping a signed file on a blockchain.
- Trinque runs a bot ("deedbot") that regularly timestamps new batches of submitted files on the Bitcoin blockchain. I think that his bot accomplishes this by:
-- 1) concatenating the files-to-be-deeded together in the order in which they were received.
-- 2) calculating the SHA256 hash digest of the concatenation.
-- 3) treating the SHA256 hash digest as a Bitcoin private key and deriving a Bitcoin address from it.
-- 4) making a transfer of a small amount of bitcoin to this address, which timestamps the first appearance of this address on the Bitcoin blockchain.
- Notes:
-- Deedbot only accepts submissions from trusted counterparties.
-- In this context, "timestamping" should really be called "blockstamping", as this process only proves that an address first appeared in a particular block at a particular blockheight. Blocks include a timestamp, and miners try to maintain time synchronisation (I vaguely recall that a new block is invalid if its timestamp value is too much greater than the previous block's timestamp value), but the timestamp is less accurate than the blockheight.
-- At the date of the excerpt, a file could be submitted to deedbot by typing the command string "deedbot- [http-link-to-file]".


I downloaded the file
gnupg-1.4.10.tar.gz.asc
from the link
trilema.com/wp-content/uploads/2015/10/gnupg-1.4.10.tar.gz.asc

In my archives, this gnupg file has the date property 19/02/2017, which suggests that I downloaded it on that date.




I have two objectives:
1) verify that the deeded file
gnupg-1.4.10.tar.gz.asc
is digitally signed by Mircea Popescu.
2) verify the deedbot timestamp for this file.



My system:
- Name = SP_THINKPAD_1. SP stands for StJohn Piano.
- Hardware = Lenovo Thinkpad X200 (Laptop). Two internal hard drives, each of 75 GB capacity.
- Processor = Intel(R) Core(TM)2 Duo CPU, P8600 @ 2.40GHz
- Memory (RAM) = 4.00 GB
- Operating System = Windows 7 Professional (Service Pack 1), 64-bit


I installed Cygwin on SP_THINKPAD_1 during a previous project: Installing Cygwin on Windows 7

In a second project, Installing OpenSSH on Cygwin and using it to access a VPS, I was able to:
- install the Cygwin package openssh 7.5p1-1.
- create a new SSH keypair.
- create a new droplet on DigitalOcean
- grant access from the new SSH public key to the new droplet.
- use OpenSSH on Cygwin to log into the droplet.


"Droplet" is DigitalOcean's term for a VPS.
DigitalOcean is a cloud infrastructure provider.


Acryonyms:
- GPG or GnuPG = GNU Privacy Guard
- GNU = GNU's not Unix
- VPS = Virtual Private Server


The droplet is still active.

Droplet details:
- Distribution = CentOS 6.9 x64
- Memory = 1 GB
- vCPUS = 1 vCPU
- SSD Disk = 25 GB
- Transfer = 1 TB
- Price = $5/mo, $0.007/hr
- Datacentre region = London
- hostname = spt1
- SSH Key = SP_THINKPAD_1
- IP address = 178.62.36.113
- domain = edgecase-test.net


I've already created a project directory:
compile_gpg_1.4.10_from_source

Note [added later]: This project was spun off from another unpublished project: Compiling GPG 1.4.10 from source. This is why the project directory is not named
"verify_signed_deed_of_gpg_1.4.0_source_code"
I decided to add this note rather than alter the project log. Altering logs (as opposed to adding patches / clarifications / expansions), carries a risk of incomplete alteration, which may cause more problems than it solves. So, unless removing clues for adversaries, it's better to try to avoid altering logs.


Within this directory, create a work directory named "work".

Copy the file
gnupg-1.4.10.tar.gz.asc
from my archives to the work directory.


Open it with NotePad++. It's 84050 lines long.



Excerpt (lines 1-15):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically
accurate archive of GnuPG version 1.4.10.

While the minor version number is not intended to be significant, as I do
not at the present time believe there's anything wrong with releases in the
1.4. branch, I do hold usage of GnuPG 2.x to be irresponsible and in
principle harmful to a Republican future.

H4sIAP/8GFYAA+w8+XvaSLL5Nforer18Y5MN2PjM2OtZKVh2WHM9JOeY4ymyEKAvIGkl4SPJ/O+v
qg+pBcKe+Dl45lv6S6C6jj6qqqtPPPSn4bBSq+5Wa1ubz75P2tra2j44OMDv2sHelvwt0rNabXv3
YK+2t3dQe7ZV296u7T0je9+pPbk0jRM7IuTZxIsc117Mdx/9L5qGsv0nofc9fODb7b8DEiv7LyPl
7P/JvY3d6MqNHtcLvsn+e8BX293e3VrZfxkpZ3/PT8bfIQB8u/13avsHK/svI+Xs73jh6LEH/7MH




Excerpt (lines 84025-84050):

qHnVQgzct1ZUkiVBIgZ3zwI596CTAF/hYXHPgzMVU2pVnQ/oZzxLyrtv9nIO8sdGif9Un8X03/24
AFvm/6sJeWn6r5D/PMxnFT9fH7uPxefDfVbj/9zNBdhS/k8nc/4xJFRx/h/gk+H/3M0F2GpMoKWO
wQo2UMEGKthABRvoc2UDfVBG0Ape3T5TRpDxxpPDCNKOxTKMIKtowQj6AzGCPhE+kOrXp8AHWtaX
z5oPZJ3jgu58gM9q9N/dVICX+n/Oxv/qbm4W9N9DfDL0321VgFcg++6gEewSfQXNV9B8Bc1X0Hyf
Fs13UxPOe9LWdmk9j8a2S+N5tbZTxJ1XdfvWVN1iki6Hnvu0iLluhph7BCe6qYgPgktDmLzOgjxP
zSYs9P1Ri7Buy6jF5jJqsbuMWhR6cnVq8bOlEDNL+2D04NKW86k/NfNOzZ2PTgl2U4fJA9j1L+I0
NSveJtR58hGbBaVZfIpP8Sk+xedP+vn/A9FDZG0ASBYB

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJWGP49AAoJEIpzbw4vt7RS+3MQAIjdyghumfcoJAE+1kHNsapK
7kd0SGBG57LZXXRKdg5CdfD/WcRcwNh3EUtXqQ8v9J0EX++FhYigfdqHaMnvcarn
3psiKG2QaeGzEm4/qYJ+Lh7fdA2ypXgCGPIeVh6Co9IZnfiIcUk8egd6CnP3Obew
hOJ+NWZXu4FAZhSST7I7mm1COGjvnLMjvpp7kzJ7h2tTjZE878WZ/r0ID2mDdaHd
ovmLe3gVLbJpnjiXr6kzET5oWCA2fGwJS+mMKkXZgH3FU45fa2Z85OCxEIujDNwe
J8gTtZUerHEXsO3h30Ss2f/E8HE40wGtnxWAKmAhNBSLQlSd3l66jy3hg1eGeubs
S3bur7wHapMN1dN+lu/G/txzCUaZ+DtdXo1gNR24a5AHYbnGEIQQBnvrI9Kzixh5
YrnGuxSyOKMxBkGApCKbWms0dDiZJoi0+SQgBXVERYq3P0PFEIzbsCg+nZGdTgOM
74Xx5sZtk2093w0U1mvTBKoAuA8tNBfohaNQXccFU8Vol5B+KknM+b6VuomTm4oc
mvuIiVJMl2kSsmkMxG7vR+PMpvZ0dlYd0eTzTYoxg8pjEcC8c0JzxHAFqtisi7No
6vgjS/gOu+/VtSsOqLoZxaJk5S6YSRjX3hmBlI5K4hoiPpWsKaB6sfW4HpU826Qw
MzjO/BUQPn1isWjESUPq
=+uHn
-----END PGP SIGNATURE-----





The file contains its own signature, so I think that it's a clearsigned file. I think that the ".asc" extension indicates that the file is in an ASCII-only encoding.



Excerpt from:
www.gnupg.org/faq/gnupg-faq.html

8.17 How do I force GnuPG to make printable-text output?

Normally, computers use eight-bit binary code. This often presents trouble for email, which often requires that only printable (seven-bit) characters may be used. By using the
--armor
flag, GnuPG will generate output containing only printable characters.


8.18 How do I create an 'inline signature'?

An inline signature wraps a textual header and footer around the text to be signed, leaving the text readable without running GnuPG. This doesn't conceal the text at all and therefore provides no secrecy, but if someone edits the text GnuPG will report that the signature is bad.

To generate an inline signature, run

gpg --armor --output signed_file.asc --local-user [your_key_ID] --clearsign message_file.txt


To verify the resulting file, simply invoke GnuPG with the filename of the signed file:

gpg signed_file.asc



So, an "inline signature" is the result of using the
--clearsign
option. The
--armor
option causes the output to be in encoded only in printable ASCII characters.

In order to use the command
gpg signed_file.asc

the signer's public key must first be imported into the gpg keyring.


I'm going to copy the .asc file to the DigitalOcean droplet.


I'd like to use the
sftp
tool to do this. I'll see if it's already available in my Cygwin instance.


Open a Cygwin terminal.

Admin@Admin-PC ~

$ sftp --version
sftp: unknown option -- - usage: sftp [-1246aCfpqrv] [-B buffer_size] [-b batchfile] [-c cipher] [-D sftp_server_path] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-R num_requests] [-S program] [-s subsystem | sftp_server] host sftp [user@]host[:file ...] sftp [user@]host[:dir[/]] sftp -b batchfile [user@]host



Hm. It's available.

Some reading indicates that:
- sftp is part of the OpenSSH package.
- "cygdrive" is a symbolic link with Cygwin to the "Computer" directory on Windows, which contains the mounted disk drives (e.g. the main C: drive).




Admin@Admin-PC ~

$ pwd
/home/Admin


Admin@Admin-PC ~

$ mkdir work


Admin@Admin-PC ~

$ ls -1 /
bin
cygdrive
Cygwin.bat
Cygwin.ico
Cygwin-Terminal.ico
dev
etc
home
lib
proc
sbin
tmp
usr
var


Admin@Admin-PC ~

$ ls -1 /cygdrive
c
d
e


Admin@Admin-PC ~

$ cd /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source

$ ls -1
notes.txt
tmp.txt
to_do.txt
work


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source

$ cd work


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ls
gnupg-1.4.10.tar.gz.asc


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ sftp root@edgecase-test.net
Connected to edgecase-test.net.

sftp> lls

lls
gnupg-1.4.10.tar.gz.asc

sftp> lls

gnupg-1.4.10.tar.gz.asc

sftp> ls

ls

sftp> pwd

Remote working directory: /root

sftp> ls /home

ls /home

sftp> cd /home


sftp> mkdir work


sftp> cd work


sftp> pwd

Remote working directory: /home/work

sftp> ls /home

/home/work

sftp> lls

gnupg-1.4.10.tar.gz.asc

sftp> put gnupg-1.4.10.tar.gz.asc

Uploading gnupg-1.4.10.tar.gz.asc to /home/work/gnupg-1.4.10.tar.gz.asc gnupg-1.4.10.tar.gz.asc 100% 6319KB 1.3MB/s 00:04


sftp> ls

gnupg-1.4.10.tar.gz.asc

sftp> exit



Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ssh root@edgecase-test.net
Last login: Mon Aug 6 19:47:05 2018 from [IP address string]

[root@spt1 ~]# cd /home/work


[root@spt1 work]# ls

gnupg-1.4.10.tar.gz.asc

[root@spt1 work]# gpg --version

gpg (GnuPG) 2.0.14 libgcrypt 1.4.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2


[root@spt1 work]# gpg gnupg-1.4.10.tar.gz.asc

gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
gpg: Signature made Sat 10 Oct 2015 12:02:05 PM UTC using RSA key ID 2FB7B452
gpg: Can't check signature: No public key

[root@spt1 work]# exit

logout
Connection to edgecase-test.net closed.




Note:
- The current default GPG version on the DigitalOcean droplet (with these settings) is 2.0.14.


In a previous project, Compiling bitcoind (trb 0.5.4) on Debian 7.11, I used Mircea Popescu's key for vpatch verification. I stored the key as an asset at the end of the article.

Browse to previous article, find the link to the mircea_popescu.asc asset:
mircea_popescu.asc
and download this key into the work directory on SP_THINKPAD_1.


Next: Copy the key to the droplet.


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work
$ sftp root@edgecase-test.net Connected to edgecase-test.net.
sftp> lls
gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
sftp> lls -1
gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
sftp> ls
sftp> pwd
Remote working directory: /root
sftp> cd /home/work
sftp> ls
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc
sftp> ls -1
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc
sftp> ls -l1
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc
sftp> ls -l
-rw-r--r-- 1 root root 6469886 Aug 14 10:05 gnupg-1.4.10.tar.gz -rwx------ 1 root root 6470773 Aug 14 10:02 gnupg-1.4.10.tar.gz.asc
sftp> head -15 gnupg-1.4.10.tar.gz
Invalid command.
sftp> put mircea_popescu.asc
Uploading mircea_popescu.asc to /home/work/mircea_popescu.asc mircea_popescu.asc 100% 9797 98.5KB/s 00:00
sftp> ls
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
sftp> ls -1
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
sftp> exit
Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work
$ ssh root@edgecase-test.net Last login: Tue Aug 14 10:03:45 2018 from [IP address string]
[root@spt1 ~]# cd /home/work
[root@spt1 work]# ls
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
[root@spt1 work]# ls -1
gnupg-1.4.10.tar.gz gnupg-1.4.10.tar.gz.asc mircea_popescu.asc
[root@spt1 work]# head -15 gnupg-1.4.10.tar.gz
Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically accurate archive of GnuPG version 1.4.10. While the minor version number is not intended to be significant, as I do not at the present time believe there's anything wrong with releases in the 1.4. branch, I do hold usage of GnuPG 2.x to be irresponsible and in principle harmful to a Republican future. H4sIAP/8GFYAA+w8+XvaSLL5Nforer18Y5MN2PjM2OtZKVh2WHM9JOeY4ymyEKAvIGkl4SPJ/O+v qg+pBcKe+Dl45lv6S6C6jj6qqqtPPPSn4bBSq+5Wa1ubz75P2tra2j44OMDv2sHelvwt0rNabXv3 YK+2t3dQe7ZV296u7T0je9+pPbk0jRM7IuTZxIsc117Mdx/9L5qGsv0nofc9fODb7b8DEiv7LyPl 7P/JvY3d6MqNHtcLvsn+e8BX293e3VrZfxkpZ3/PT8bfIQB8u/13avsHK/svI+Xs73jh6LEH/7MH 2X/3YGdl/2WkvP1HrvMpflr7s/l/d2+1/ltKytl/+H32AN8+/rf3a6v5fylpZv53xtO++9g+8IDx v79a/y0n5fd/u9/lCOAB439vt7ay/zJSzv6fx97ln2X9v7L/UlLO/kkQjB9/+fcQ+++s7L+clLN/ P3CefP13sIXx/2Bl/+WknP1jJ/LC5NEjwAPWfwdbuyv7LyPl7D9NvD/L+d/B/sr+y0g5+4fB06//
[root@spt1 work]# tail -30 gnupg-1.4.10.tar.gz
tiZAxBBQotMQtg2jTXD1Bb3BAKMTVnAeYX9WGxL8BPc+qdTjBoMm+oQWTeIZtMNz3dxOj/5pisRX 6UzXOrM158FvpeHnPLtbDjzdN0KIb9mEuJrFNOGsCvim3Wq5kyLLgSiHuT/kc292JdmrKGJdau6I o8OOqiEKzwK95RYQ6ifRn5ZK/3CfZfQ/qwbcrY1l9H9rPaP/0d0s4r89yCej/8/k/w7clT7KP3w3 741r8JxG9f+E8UQYAAUtX9DyBS3/wWl5Op2fGC1Pfcqh5SlvRVqeYX267R5a3jTqpHhV2lej5VX5 z5KWF2Hjn4WUF+nsR6bkx7hYhoh3aHgluu2sTsDf7ErxmRZ8OGr/m5WofSJM/zDEPt8c5CD+/on9 sfHz3FyZAfBCU/yWeF1g8e4w9P6nQu3nEPtZWp+kwkxzEt3pEKkZSl8IfVTEMQP66KQ/kfX2IL0k fQ5Fn0PQZ+l5kuILKW+7fpeZ8ojBw5yJnefR8hlS3tpuQsqzdH0FKxGLZC9o9k/ys4L+94em/7ub 7c2s/L9b0P8P8XHp/xsrf1M4QK306Wh/k9g/X/ebPjk8A48auC7ifgp2QsFOKNgJt9ENz1UMt5kJ C3kJHkVwm5ng0QAvFdrfudrfq6h+5+h9+5W+sxrfOereq+p6exS9b6/lneJ2pLRiKXtQWq+tM4nN 0s4Br0UwnF9cILmdRKtoeG/eVMPbq5W9eVOt7JuoZN9CH9uri51HlXtVsT+CHvbN9aKZsDUkZ9Ny iJy3JzQxcyuV6s0Pr1K9UJM53f6qmsy3VGPO4P8XG1tvn1wMNraa7eY9uQBbZv/Zbney8r/C/vNB Pnhv8WIHJyeOk5KbugDzYOfqs5pjsGVUQdeKQLxVC3KabMPmWk4RCHBBGBSEwadKGGBVyDxPMcvP w977ERzJfg+jCE4i3aFXb6AT/Rh9diIGHuwMZnNCUEezrxKjsk/1UOcoFiGg0zAXg/NedAb4Ky8u Fb8EzBcLwe7qUUxTJPWHz3hIo4RjOk5RrYnAev2E7AVg+1BxmKleJFsMZglO/Bym+yKEWYfrZDye DGjXBpfno8F5cAGN9UWchaXxlng/GWHghfdhT3nFTWB2RuS9mDo1nDOO3jvD/HA24HEfZ+YDZiAJ x6d0vvWJMgdy/8c3+8+o6PnkkoI17qGkaDTkKI1ShAdOs2eKAn0AUwblbxVR5t7duiXT4Jsgbavr M+glwK1VjHoJksLWLbXsZVAlLy6Xjnf/fVwukVilXEKfsPsl17Vr1p1QeTHAdrX85vD1/usffUWV /1bl66nX1EkSZqTXslNItDtsmyQeTDDssr4lnn+K1KnkdYk6bYAxDN4yTl3COCEX49JhZdiu1uHv erX2avfVyZvD3Ze7L2BKqmXl3J6PSXw2R5qWzo+uGOr6PpzhDQwNUuiRi7+WVO3jElb4cu/oDVRX azertcOKjLHqhegiBA/ZD7AlACzs80B02gShCI9yKQSavPSo5RQbjGMad8v6DsR/aZzA9xRsfzAo 7Vf2W2zS+y6TD4lUngYHf0slmDT4UhtcV4NvnwcVIECqtK2gFqTznG7D1X+8d/BCjRmrEIJvjrWq cdSos9uSCzvnymrTSVoXWEqilI4sq7Sk5x8HtV29XV+a2b608vrSXKEv5dKwf1oy01rjufJXRjP+ qHnVQgzct1ZUkiVBIgZ3zwI596CTAF/hYXHPgzMVU2pVnQ/oZzxLyrtv9nIO8sdGif9Un8X03/24 AFvm/6sJeWn6r5D/PMxnFT9fH7uPxefDfVbj/9zNBdhS/k8nc/4xJFRx/h/gk+H/3M0F2GpMoKWO wQo2UMEGKthABRvoc2UDfVBG0Ape3T5TRpDxxpPDCNKOxTKMIKtowQj6AzGCPhE+kOrXp8AHWtaX z5oPZJ3jgu58gM9q9N/dVICX+n/Oxv/qbm4W9N9DfDL0321VgFcg++6gEewSfQXNV9B8Bc1X0Hyf Fs13UxPOe9LWdmk9j8a2S+N5tbZTxJ1XdfvWVN1iki6Hnvu0iLluhph7BCe6qYgPgktDmLzOgjxP zSYs9P1Ri7Buy6jF5jJqsbuMWhR6cnVq8bOlEDNL+2D04NKW86k/NfNOzZ2PTgl2U4fJA9j1L+I0 NSveJtR58hGbBaVZfIpP8Sk+xedP+vn/A9FDZG0ASBYB
[root@spt1 work]# cat mircea_popescu.asc
-----BEGIN PGP PUBLIC KEY BLOCK----- mQINBE4pZg4BEAC5Tt6Het3ulsH1s22DgCUFN/bsjBkB1aH1oZT07PGQYinEicrS tzIVwjyBIA8DiVCYfhOHtW+jhpMU+yOs92bpVWNIwh4S3sMVvmJhUafYCuVSUdNC 1iSjGj+9DgUmnO1AG7lmw/Rhu7ocMGnzoWNX+bvXG7RTAnQCd9eUrh4/TdWk9F6j wBCzR3vAR9z98qSd/f7otellZKgbMvvrVtyN3r2hj4UuHV3Dma8OHbh0fdmYLUWG qOGqKadJs+aRTLg58AA+uCtlxSmyoRwFFw6OlS4jBdbKRY/ty5kL2IRhrMQYRKIV X66LRvcPqyFEUb9SDaWBW/dluw12b+SypuKTZ+7uJehmEMCYd7aAGbg6e4xMfH1b shUbS+rQ7XvLgWpRpd2nhbYEGmDTzmVUYjmAJn8D0BX9LzklWa8tUdYYHI6szbjr ZKxQoQQ2IKdrHAnY174JWH/BXnvfOHpMxx+0boTQsRj9fxY3ORPLcXr2Tr9CouFe OCoK8bGXzXjmjsFy+YL5vAUrLRDqckdDsqCZsIAMBXr60gzVQc2xc1PHtI/ppefm bxlV30DvICQWNZofzJOAOcVyXWoDBFuZQvAjX3r26E6ReAC7ndgiB5/k15fAJJ9L xhY3BeJ/LS6sKtCFtwGlskC1T5Xik1Pd9vvNs5tsVIZDV3IBB8/4ImLg8wARAQAB tGJNaXJjZWEgUG9wZXNjdSAoQWNlc3QgYXJ0aWNvbCBhcmUgYXByaW9yaSBhdmFu dGFqdWwgYWxpdGVyYWxpdGF0aWkgYWxhdHVyaS4pIDxvZmZpY2VAcG9saW1lZGlh LnVzPokCOAQTAQIAIgUCTilmDgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AA CgkQinNvDi+3tFIFBBAApsFD7T4eyaNrERbsg11x0zj0tln5QTPQ5tGGKt4blFyq 9K4I/sLAT+QhbzwMIXEARHm3T3SimGdW76NgjG4ZSrLzxzmwRv7J7AwxfsCUyZ5T pthx+VDHNzYATdWN3VODuzdHl1kwyK7QEKeElgThnXaC4zcMAteu+H2M0QDTHRHZ YJA7MTdVWo9Jl3pptKd5Ln+0rwumdrutebAh3iOxdeoytGd210ct7bIDCIL5D58u fs+Xu29U6RskGc8GwD2taThhTJMpl5zccwLPjBBk+79s5ElqP1dmHD/KgXDCNEsS NdCisZeiU0C6W6AirFE8y4Tdm+wX1TUjNz6Q7hUajy0XPKUcQX8655WPFDuNmnkW +cRIn5rCy8LS/jEHtQ6Y/m5xKb7Bufl6JVqbm8WZaBW3JzuIZEB0lAOjGlYPKNh/ 3cPmSdG9x6CuKF+Lqv18QeAogWfu8JGgdKxU/bTxZj4/sTBdO5DjMnkgNljUHGTH sUKTJgmIrca0WlGKOBA05dgod3zZvkVCLN0j6rbT0FA6i/qc3tkD3gmDX4CYke3Z DfMbNdlyLCp3juRATPmX2zPmXSLIktmsxC0STtAd5j3u1k7iOjKTX1ByPbutgqqS vbvmDA0/QPsga+s9K7neTGvba1b7Z6DqT3mzFGa0dXstCxjX7Vc2DfxfNKBMII2I RgQQEQgABgUCU5+DcQAKCRACWk6waFdwTQ6BAJ9ONZKfKM/9XorCIZxfHiwR9P2K 6wCeNG6zxJfzqGymiHB1oh1M7n8Zf5CIRgQSEQIABgUCT0frlQAKCRDn+Ti+yVWU sikIAJ9azhwyQnk/fCM4AFMnBWpL4xhe2wCgkILJF1nUAhPRGeGpA8w/NEdwNAGI XgQQEQgABgUCURJ2KwAKCRDKqzQNtfPizoSHAPwMdehJFg1r8QHugNfTqakLrhqD xOo4V1x0rdl1yoBIDQEAjkoZCnJpasrqTHKrD4Lmr4CAUP+ye2MdeMOgzX5/tTeJ ARwEEAECAAYFAlPTkhcACgkQdFXF48DNzrna/Qf8DZPQYjjqbgxDZvnk4C2Rni8y tPsbZmpVdufGO9bZABe/zOrpT8ClrV3j4WhKh4fSVzaG+9ZaiLMXA/De2bCHflIE r0acwZXsaHPNsAEA4jpfaI5mI8qaEB3j1uwfxrqG3lHw87RN7I1xceMk4mUYbuP6 qa0hgNd23fmqGsO5zWj9oiBwOCxHw0GZWoODe1v0NwwcZA+Z1NLedsCga+jVs8f5 9oXjCI1AozotKi2AIZ41fGMf4wwSq2VMsDwnja7XRoFaJ2g3RyGaq8KlgzqF7Ckb 1TbB8Ry+w0dY4AaIQp4e8y54hkzzQrcEuvyCc5jDw93wdTHxqVCW4caokuBvbokB HAQQAQIABgUCU9UCPwAKCRCTRt3O+oF9OMv5CADDUeWtOrZRySwIp2AJdKCCoxEg 9b+9pn0HjuLYBRulMMTdMHBPwTiPBj+9d8CcmrFwVXZsix1LJcF0EDZfSJMZiNc/ ZGz0r2dLZHPRSmWDnzdWTjLDYphV3lCwxfjByjzpIB8WYDx/IsM1G5tJOkDdTobb KdjMMecXcKYXwN1rysVpxrpU26falkVYfuyk1h8xBPDclakkaqg4hCo/LfAwCvqV aVMhn7J2iluZXQ2BQ2lk9nxJ10gH9egEAyRalC/pRrdfnSzsfQ8kBdK4JeZK5Yy3 lciDG39BBPfmPgyhetKnHzo7ymSxFlB2OHh84C47WIAKCKYULyay+/f5WGmsiQEc BBABAgAGBQJVQdsjAAoJEBMojqsBcTQo3JsH/0rVJBEed5zeFWZbykT+Wg/s0PQW 4k3N+oF6UAmCxH/yVM4eO9W2/2ydsRDGODXg28bv/UiOGNf5Vu5BH76yvhMkKsSL sn2C+6UqKJXCDnICWcdSBhMUIfQXQoRCtJ/APpPzgYNInd5e246wCrceRsok5ZpD //TGjcDwk+ZKLbSDBKGcBxek0HkPtpopuR6IYsbWGNRwOXajo5ci7HMjnYJILKA1 hnrO9R5o4U3C9AnepC+I1YK3LUAnWIm8qJUjkS3RKQfLBJZ5J6TwaeZQ3a6HTrij E3jSSkuLUjkaZERvs1p5tm7xeCIHsrqaMEsdXbz5dKki2C9OEENvix9dQrSJAhwE EAECAAYFAk9uPKQACgkQPwluL9U+nJrYmg//YcDZZgtRJKtBr/PUKkI6d8JhsILo DpSxLo1X7CZqDgaDyGSEVlT/dd8whdbPlLp9YES7+CAj8UKP/PwwfyaFLYuFdoVm X5+fOz4QjyqhlQovq1jJGSoGPdNlBwnHUqhuSHv9Pw9DWaprlGjeCQl5gJHrTZMM 4IS7TuoLkDIzzkAjHoRwf3R84zNJaRXH+o0oP1exU0Cd42cVFxQK0K87OsenmM3e DCdmY6GeWCKyKZh9ABIFtDLBg/VD+RPDk0F9bHJvt/DZGjZLYwZ/a4HlAJYCcPSa Jamp+8dr7hptEG/o8n4k8zvAS39mRC4lGqBTjLXH5z2zcOIh+zT30xvFm3dkdh3f lGPU/T8w+SUQqxPjQLh1lDSxImuOH1ceG43H/M5byJj57ywlBNWP7IJVbLyfWRFR wa1fA1nXc+tP+sygu56wVZaRtVJSLzQpNfCeODP3L1cTR/D3lBB//BZkD493PNhY BCq3jAldGSn/Zd87OWo3LADQFRJsvPYz49qfEeEmXt+tMEhHP0Lvtp816hagnZiM 019jzX93zh17sxrsgyUdPa9X7Ain2W7fVMQGdKZwMGNGH1s+Bqwbu+0hfBjJxWwj KZK6puLfyO1hov/HIH944Cjg+JQyHc24I3ypO8egfll0KIukc8omwAM0VedrbhzK duYgmbvpQ7lMXCuJAhwEEAECAAYFAk+DVfcACgkQm3EgCfuqJVy0UxAApTDtgwWj IgyJ2yPR7J5oGmCIGmG1sPD8Ab13ZY4Gesu8QryzRViKz79ztimhOu6q5YWNQtcp OJ+Zxy/MDHPqw41PwFKuRQd5wLbHOERc84fytk4Nax8hicHoA8fF/TBC+VSaWanx ji2I+2jZMu6/jW18wyGzvn/Rsi2bCBkWq2vtny+1eSsjji4r8WKvlMPPIVjzi45x 9rewn8Mrc+YY5BQvLEz4jItTrYjACqP6B8OxYqoPdVeH8o+SpAk4IUg6G1tgBoUb YGe0gLQ+1ofwApA7rLhUyHCWkrMiF6i11WgZdK3hDhahUsouxn4kncBX50GyvF+F Jdk3jdimclXzscJ1xKKdzM+CzLCyaDI2eyWHnn2CPtDNGW0A1BAOpHfTCVal7ft2 zJqNWMjUouq9H9q1++nJWe278Yo7tJRJpM7rsPpmAjHfVAWMM5nKmeVHy/o6PAMx g/jm75yp9qC2M1VKasVDK7ka+ZE73rDvYzLg6SVC5V7QG3bz3osxhhynpgU0XU8U sIHhp3VN67+eWiJ3nX55DhyBmt3ssKMUNE4YkkB3udIQtv4r/gMTRkk2eB3hiNo+ 11jn+Uo/shn2OKmg3+dF+gpNWGGePpYTzrgp83Svc99RbcoiofM7UKpKoTAKdU6o K6EfjLd3ZqTg/UmVlGn4FjPYDLR2WQvr1USJAhwEEAECAAYFAk+U6mEACgkQ/Vqi peJmArAfkw/+PrOv/LdB9M7nvoaEkFjnDd9ngRRZKl5A4jwffL4HA7ctCPe1Ed09 F3/q3KuEnOwO9WcyYQvcaM7TJstPYlJrXEU8r7vmf0YJ8E9JU/H2aFQ1u46JBbyc 4Q9+i03O0H6GTYXrywnmxxEV6UB1easfUGgTGHokdCg0cFGD0Qz+MEXlQ/RNuNQh lpadM9YN+bTbdM0C9mw84lf1Xo6/d9+ZRcWVCp225o/yZ5DgFQcW46DlPVCQUWab K5axje+kfbonTyBu7B8vsyjUM3/qpcVb1WdttgskYmqbisoMPKPyu2EI9ynYXK81 t77sbi4cdwZQDa09fXdiv+Hv9AabYHS9XGE0ArpxB+N8dpyRXCH1jojcJ2jhO84n +yLvT17a6jC42RnlEWkBvFISn1KmJM00z6j5ArNIo+kbab+AisxSccLfdP1pLBwJ J5UY2qj90TYjHoki7W4HH4aHUKH4hFMnvDv+/1Sd0ocCvw+9TADv0Jfhkcjg/xg3 RxYufzHYZgLvaMsLuYIcd/Y6tSDYHMnLbZszzPkWH8O9/NrcvDHyCY0SX4+8y9SC lk1zWT/pyXH3sRY2QkM5c1F0TMx5U1PkrIEeTDXXxLjy8bElnTy+/9i7CVwabZzi hewUbm1J/qwUTFbEMUA12W6o5jQmzkKLqPj8tsilQShQpMSWauE48wuJAhwEEAEC AAYFAlPqZ8MACgkQ0VjIYZqPJ6xSow//R13NqISwC5vW24SRccqRN6P4UcH5kkVf cXpKR8DErTsRo2tUlFW+7G5TvUuc6c4T8ipBebdKWEVc9xqI82r+9i96sMxe9Ypy 5B/qqDnOzcA0uhvcGw703dvlAn3BicPSBvFOR+U/QWIsQJwwq0RtW6mYUk3aWtZ3 rs12hQuNt7mjDBNHRH5d25egu/VIXEP5BQsTRJ+0Erzm0JWIn4Pklxdneev78WYQ vG+y1Ad9VOEA8oTMiIqcq3oI0cBIs5pCBSjVHhN3ayc6i+4v0l1hnC+zI14fawye zSkjtkn2/GVQYpFPEtNPxbb8lFLvfUrkR+CzdLhuBmu6tUqKnOoKt6DGdlfILUIG KWFd3WZzhb4Am3swU25QM0TUy8WguBfaYEOSwyL6v9D+g8Mpac6VKqy5z8sieGcg w4MKRWcqj+7T6S8wvcQV0aqR/AQ9a2dDn6n4knQSmqLjsv90Cby6n4n57L6BnUop Clu1Dbl+7Sz+C8qygYfYR6f9pyr83CJ5eSmVxRoX7u8eGx1Envorwh3FzOCpdIxG QoIkKIffXVK/Mw8+R4S2BqBkPoVFcXaW6qNf3FnlR1OpJls3COl07r47M4CjW/6w 7sB5Jzd51xGd/0jshj+/Fa0i+Qau3snlgnCXj6pKzqlnKxtgt5HveR+RLC4X2Apn s4AK866kQ4eJAhwEEAECAAYFAlS8tmUACgkQTAr8z+1c3hTw9xAAulqb/8T3ZL4y p4OmhEBY1bpJK+MRje8GGODLl9yZbXC5sNbmmtuR1skVlNXlyb6eEyLt5fMhwy58 dPGSaBOAhKyYPL9LGr+brVnO88d2YHFORDPmkwGOBZhB3UXvShjOXQwXbXty0Zlh mm6CnHMIZm89HhNwNaz/zCQiTrz8dvMevueHEsdXfzaGHsECXebO61/z/qeNVbeY NEjtNsdzALkHNKU9M0BZEjVMVItjeWyJP6iIpmVQ3VpXtxJ+l0RfQoYV8faKwz7a YY9VsUtYjLYriOqMSclBxcYDMQLLlcoXCzBpwocb9Ur1hwUHC+pWttaB0YNV4X4g HRo1hqZsu4vm5Mt98dLO3YAC/vhiQE1Wdt1yqI4HGhoabqan9LHl7kwE9+CpPsmb mjvK6NLM1u8/DuIfTa8UpyamD3AdgzEleGMulnG92FtFq3uUCG83XSetX53FCWGd qjHpRR0ja8B0HRPJQkCTXScN0XybzwBPE50aHWvj1Ioc8LixQt1jcEQykojSX8/n Y+P4kg5pX6JnzINR0RARlhb8+YC6wTSeEVy8qhRpIFyCocORWx2v+gUQa0anizkB 4An3qkxO1nQu1rr4gpJeEoNws00q2DsXGZI9Hr/iEOCgEnmKm6GS7OmOPYKZ0F8r slO/N8S2oAM5FDMIiT6hd9jGjReO5iCJAhwEEAECAAYFAlVC0x0ACgkQchcFqLce ra+/gBAArvnUR03y2S3BlRCN6XMx7V7DwKkqqp9qMpzbqaSpYVbkTaGclW75pKCZ Pb3fTriDOQ5XRDdQA0Ukw6+mKU3h654RGgHVOADc9aZPTGkqMq5W6t/AKKX71Bzn o1FYd6wWKI1bMxlt99GxOb6JFtSs32NqSJppN4HDGH1Ta0Uw4O75DEyOb/dttU0I lx0HePDOP8iPrDsQZewPJlg+FE8tKGOBbJBcCaw8A4PrwjysW4/oVKHUsyN3SQTO sz5uwHdK2tsN9J2Q1DsZgC8j0fXMh1uIuuCVuJZPAJvQfPnuKFfyjMnAVdy7q3RB jIboimv+jYgcucCpe3EBiWk5ldq522eJmQ6VnHwl/nwyc0NIqg0tZQZA2zM/ql19 v7v+gj06D3XX3k7h5Cy4nTCT87+tuFGY/zm17ZpFwU1ANkpy65W1Ziy3AqYwAwAm xnMF+z02FHJrWL/UjdmZPqKl5jPhYlpQQmPPurRZBs3OieB/fT9rNykPVQqaBAFX p38yqNHzlzKK+rEmdR69zhbka8kRF0ajSjkZGSPesGyRSomI/8mtOKA7L+S5g4MH elUa/CqySCbXL1+OXKhmTnD2OyLhNyfTvMB+8OWqF5ycTF04/4hmrdwDTKHSbvP3 F5LxSHw3H/76Gtkjr3YKXBBqb43VoYypY+bDa+PblbtSPEQhdcWJAhwEEgEKAAYF AlRH4UwACgkQGIWqEOVE1v7VQg/+O5t3DV4rbAkSJB1CTr9BLKVYQXQ+mqY2ga5f u1gAT6Vy6jVU9XE+BpvaxUqsLAwwWvT0oA5iCRiXqNHVoIDsvTWhkIsfWTQ6bvf/ V2EC+YE/mrPvG9EgnqeRoPRSAh2liowkwbQ0YGUb3Xdc4vhtf1o6AeDMCTV72XFL cb6tlyQUN099uQ725NnP7LaGXz6VBb28ZbmhUS8DL7BmyY1qG5/T8K1J6ZfAMM9Z 10wKEupbOCJ9P5aKqUBOtlRgjyrZyt2LBul9C8xnLpcEpX0OFNuX/Serlo2jMlWa I/+Wk/7h6yxaKzCXOxNMFO5C81VQsJYVxzenwrKoQAf1AK/D6N8WA47wYzrRgGK/ bxOjQXGKB978dX3XPXTELYytpGZ55xYIbtVeeYzdLQHqz7vvHil1Uqxn5GOVdjqH uJZ+ASUHxYxvIt+IDhI8o9evlGP4KkKg/5fngHNjyjSS9Zy9Y9R6oK33nUBsm7Xt evWYSkJt+cRtz7cPDFWL/nLmXjYM5KANWyGu6F9o1l0m1JLIQ99N0smzfQg4vz72 pxLC5OEKufXXtqMff/L3iIPukJZQhW+s0gs7QBMP7DjD2pV2zRMPGL7p3FwM5LmA CuYd8ieqCS5iyRZ/o8obn3I/qFfVD/Ytc+LFteky3LlZ97zS97WcnvQcKlbdZ7/2 hcltoBy5Ag0ETilmDgEQAL/OZPFD8lno03a75KGti6lnHrD6dcj7T4/4ZIMxG0p+ BlA4I4t4iyBtOT7nXEB2CljXzNOH5amK6u6Yj6hrCWnVuepoeHSIk01QRHQjdVVj Al0ORw7J09VcgGwaiF8ILrwbbdmWMipFxcFRbjYFDC9S8j5utQ6kURPl8NnMJsne JFjJpC1ZEP3c5a7VlFbOCEoTl7DTBZYdsdo3blU4JnfzDV4IvZ7R5Jv9HP1Vn00L cE60HfQbBz+keLDSGqIgbORciuqXoD7Sdj5u0cDXFSOOlkE3/Izu02Ud/aP2M/Cn yi/l/AMr3Pe8YiVuICU0lKHV/LREe2krEFq5VU/1m2QkXIe4h14sRPkWVX1UFuEV WgPIhT7vHtJPlXsjnpnPge8FozsAnSKgA2haRYGHTdroM+oh+Af4OsVeaKWZx7ZP YQIOlRJONLh4d1jZcjVIS9oeM8YMy/0wXRjKhD8U4FlLiLk9elEmYVtfxgVsUoxv +OpjxUAiihUXXk3uhBpTXwG8xEAJEti/L54bzfau9K+FBU0vfn91+AC3+i7tYyo7 pjzsu1tDR6bdZMzb5h/cQ2b9bHUmNutQ9fQz7OFDtLIp3Emtne2tRmpX6Ofoo2Bw 6TqzQPcyKAlstOEvll5L+oCiTwtj4IVEj2lkYhw53p1QFRdZHfPjJfpjSi51k3zB ABEBAAGJAh8EGAECAAkFAk4pZg4CGwwACgkQinNvDi+3tFJXsQ/+Nfbh6T4XYPA0 jHH2tZCUb5015NE6F7F9rqVYAtxeOaekK12k8e/wN65gOMngFnyYjeEuD/8FoMv4 1zRJyOFr3st85XCSDadTgWQeg0i8G36vZegTEQzzkHctI2ZV2r92LyN7bxsp3XSD k2r0Tl9E/rCg8ixz33iB/XatqdCgENSltEehclzqorYIZvl/lUe820kLgc8wDFY5 hZjWuOXzoPm/lt/vhXgpn3BaOGIz4hp0xzNQACAiNyQcUb/ZY5Nzx50LSIKlZa+m X6tyLN9EKMy5N8zG8bn66MZJWlDCiURxBV8ap+r4J7Uf3LZSRQ0Cj8W69vX3H5Lw 8Ufmv+ljmpKtIZd7jbJdeLm51Rv3f1/0T23KVjXQKdgjJGW3DW4TmmpqoYN32MaP pqXlNE9doJgtjiammVwXkXzk50mgfMxYGwcOC57EuyMkaVABI71CCU+/LZ11IpQo tAiQIwmh8hLr1tA43aE/5Xw4b2YwEdOqzOzq3l+ExwG0Bgj1ninlKTM4C5C9b7M1 c/RphQ8lYUo7kDTUNV0KUCfCsofwgoBw2iD1a7bUKtQc4bgwct34VgH2wGclgN5Y 9Fty8settVIqbo8b0anUHnFt3hQa3Cvap3H6GI4QtmtdpLnFz/mx+JCrCJS1B5y3 lVzoDJlmU/Ej7oevXdPboFv3YBFOluI= =IB8n -----END PGP PUBLIC KEY BLOCK-----
[root@spt1 work]# gpg --import mircea_popescu.asc
gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 2FB7B452: public key "Mircea Popescu (Acest articol are apriori avantajul aliteralitatii alaturi.) <office@polimedia.us>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: no ultimately trusted keys found
[root@spt1 work]# gpg gnupg-1.4.10.tar.gz
gpg: no valid OpenPGP data found. gpg: processing message failed: Unknown system error
[root@spt1 work]# gpg gnupg-1.4.10.tar.gz.asc
File `gnupg-1.4.10.tar.gz' exists. Overwrite? (y/N) y gpg: Signature made Sat 10 Oct 2015 12:02:05 PM UTC using RSA key ID 2FB7B452 gpg: Good signature from "Mircea Popescu (Acest articol are apriori avantajul aliteralitatii alaturi.) <office@polimedia.us>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 6160 E1CA C8A3 C529 66FD 7699 8A73 6F0E 2FB7 B452
[root@spt1 work]# exit
logout Connection to edgecase-test.net closed.



Notes:
- Looks as though the
gpg gnupg-1.4.10.tar.gz.asc
command simply stripped off the GPG signature in order to create the file gnupg-1.4.10.tar.gz. The resulting .gz file (6469886 bytes) is slightly smaller than the original .asc file (6470773 bytes).
- Key result:
gpg: Good signature from "Mircea Popescu (Acest articol are apriori avantajul aliteralitatii alaturi.) <office@polimedia.us>"

The signature is mathematically valid, according to GPG 2.0.14 on this VPS.




Next: verify the deedbot timestamp for
gnupg-1.4.10.tar.gz.asc



Browse to:
deedbot.org


Excerpts from:
deedbot.org/faq.html

Q: What is this?

A: This is a Bitcoin document timestamping service you may use through good standing in the #trilema Web of Trust.


[...]


Q: How do I use deedbot?

A: Once voiced in #trilema and rated such that you are a member of deedbot's L1-L2, you may submit ascii-armored clearsigned GPG messages to deedbot thus.

!!deed http://dpaste.com/message.txt


If the submitted message has a valid signature from a member of L1-L2, it is accepted for inclusion in the next hourly bundle. At the hour, all submitted messages are joined with a single newline; the result is hashed with sha256. The hash is used as a Bitcoin private key, and a small amount of Bitcoin is sent to the corresponding address.





I've looked forward from the deed submission message in the #trilema chat channel log for a while. Various messages from deedbot-. One acknowledged the submission. I didn't see a message from deedbot- that indicated any details about the final deeded bundle (e.g. blockheight, Bitcoin address).




Let's look at:
deedbot.org

It contains a list of deeds, arranged in order of blockheight. I think that the deeds that have the same blockheight are bundled together. Deeds that appear by themselves at a particular blockheight have '1' in the 'Deed' column.

Deed properties displayed:
- blockheight (at which the timestamp block appears)
- address (Bitcoin address)
- author (GPG fingerprint)
- deed number (1-indexed, probably indicates relative position within a bundle)
- source

Source value is usually 'None', but sometimes it is e.g.:
"http://files.bitcoin-assets.com/log/2016-01.txt"



Hm. No datetime property displayed.

Problem: How to look up a particular file in the deed system?


Nothing in the FAQ
deedbot.org/faq.html
or the Help page
deedbot.org/help.html
appears to cover this problem.


What are some possible ways in which one could theoretically search for a deeded file?
Note: It's probably better to think of it as a byte string, rather than a file.

1) SHA256 hash of the deeded file. A SHA256 hash property could be included for each deed. Then I could hash the file and search the page
deedbot.org
for the hash value. This solution avoids depending on the filename (which is mutable).
Note: Hash collisions are a possibility, but if any occur this would still produce a short, manageable list of results.

2) The entire signed text.
2a) A portion of the signed text.

3) The signature text. Signed text can be very long, but the signature text size is limited.

4) The datetime when the deed was submitted. Searching by a datetime should produce the next block in which a deed transaction occurred.

5) Browse through all the deeds in order until I see the expected text at (or near) the top of the specific deed e.g.

Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically
accurate archive of GnuPG version 1.4.10.

While the minor version number is not intended to be significant, as I do
not at the present time believe there's anything wrong with releases in the
1.4. branch, I do hold usage of GnuPG 2.x to be irresponsible and in
principle harmful to a Republican future.


6) Reduce the set of possible deeds by searching for the author's fingerprint. Then use (5) to find the specific deed.




(1) could be accomplished by downloading all deeds from deedbot, calculating the SHA256 hash of each deed, and recording the results. I could then calculate the SHA256 hash of my candidate file and search for this result within the list of previous results.

(2) could be accomplished by downloading all deeds from deedbot, selecting text from my candidate file, and using
grep
to search through all the deeds.

(3) could be accomplished by downloading all deeds from deedbot, extracting their signatures and storing these separately, extracting the signature from my candidate file, and searching for it within the list of deed signatures.

(5) could be accomplished manually but would take a long time.



Let's try (6).

From earlier output, I see that Mircea Popescu's key's fingerprint was 6160 E1CA C8A3 C529 66FD 7699 8A73 6F0E 2FB7 B452.

On the page
deedbot.org
the fingerprints do not include spaces.

Manually remove the spaces:
6160E1CAC8A3C52966FD76998A736F0E2FB7B452

Searching for this fingerprint on the page
deedbot.org
produces 52 results.



I'd prefer to have a method that results in a narrower set of possible deeds.



Well, I can get an approximate datetime value for the deed submission. I can then find the approximate blockheight for this datetime, and look at the deed bundles in blocks at or near that blockheight. This is option (4) combined with the fact that the blockheight property is displayed for each deed.


Let's look again at the earlier excerpt from the #trilema chat channel log:
btcbase.org/log/2015-10-10#1295983

mircea_popescu: deedbot- http://trilema.com/wp-content/uploads/2015/10/gnupg-1.4.10.tar.gz.asc


In Chrome, hovering over the text "mircea_popescu" in the excerpt displays a tooltip message containing a datetime value. Right-click the page and select "View page source". Search in the page source for:
"http://btcbase.org/log/2015-10-10#1295983"
This search will find a particular <a> html tag:
<a class='nick' title='Sat, 10 Oct 2015 12:08:05 GMT' href='http://btcbase.org/log/2015-10-10#1295983'>mircea_popescu</a>

Select and copy the datetime value in this html tag:
Sat, 10 Oct 2015 12:08:05 GMT



Next: Find out the approximate blockheight at this datetime value.


Browse to:
www.blockchain.com/explorer

Latest blockheight shown is 536780.

Excerpt:
You may enter a block height, address, block hash, transaction hash, hash160, or ipv4 address...


I don't see an option to search for a particular datetime.

Search for blockheight 500000.

Result:
www.blockchain.com/btc/block/00000000000000000024fb37364cbf81fd49cc2d51c09c75c35433c3a1945d04
Timestamp = 2017-12-18 18:35:25


Hm. Approximately 1 block per 10 minutes.

So:
- 6 blocks per hour.
- 24 * 6 = 144 blocks per day.
- 144 * 365 = 52560 blocks per year.

10 Oct 2015 = 2015-10-10

Need to get to:
2015-10-10 12:08:05
from:
2017-12-18 18:35:25 (blockheight = 500000)

18:35 - 12:08 = 6:27 ~= 6:30 = 6*6+3=39 periods of 10 minutes = 39 blocks

October has 31 days. November has 30 days.

2017-10-10 to
2017-12-18 is
21 (rest of October) + 30 (November) + 18 (December) = 69 days = 69*144=9936 blocks

2015-10-10 to
2017-10-10 is
2 years = 2*52560=105120 blocks

2016 was a leap year, so add 1 day = 144 blocks.
105120 + 144 = 105264 blocks.

So, the number of blocks between
2015-10-10 12:08:05
and
2017-12-18 18:35:25 (blockheight = 500000)
is approximately
39 + 9936 + 105264 = 115239

500000 - 115239 = 384761 blockheight.



Let's look up this blockheight.


Browse to:
www.blockchain.com/explorer

Search for blockheight 384761.

Result:
www.blockchain.com/btc/block/00000000000000000de34d6b1b64aab3aa8e4855d238e5780042df865781fe9a
Timestamp = 2015-11-22 07:29:42

Hm. Off by 21+22=43 days.

43*144=6192 blocks

384761 - 6192 = 378569 blockheight.


Let's look up this blockheight.


Browse to:
www.blockchain.com/explorer

Search for blockheight 378569.

Result:
www.blockchain.com/btc/block/000000000000000004aa40b7225b37da0c6e470638b30387889d585c0024a6b7
Timestamp = 2015-10-12 12:41:29

Off by 2 days = 288 blocks.


378569 - 288 = 378281 blockheight.

Search for blockheight 378281.
Result:
www.blockchain.com/btc/block/00000000000000000866554bb43a4734f163b317ce047e2ec983fadd247d662b
Timestamp = 2015-10-10 14:51:17

Need to get to:
2015-10-10 12:08:05
from:
2015-10-10 14:51:17

14:51 - 12:08 = 2:43 ~= 2:40 = 2*6+4=16 blocks

378281 - 16 = 378265 blockheight.

Search for blockheight 378265.
Result:
www.blockchain.com/btc/block/0000000000000000102adea2788b0eb384d92e0ed900b1f153e67570591d418e
Timestamp = 2015-10-10 12:09:53


Cool. The block datetime is ~2 minutes later than the submission datetime. So: The deed should appear in a block at this blockheight or one that occurred soon after.


Browse to:
deedbot.org

Scroll down, looking for the blockheight 378265.

I see four deeds with this sequence of blockheights:
379214
379214
378272
377215

I expect that the deed with blockheight=378272 is the one I'm looking for. Deedbot creates a deed bundle (if at least one submission exists) every hour. 378272 is 378272-378265=7 blocks ~= 1 hour later than blockheight 378265.

From earlier testing, I found that the blockheight property of a deed links to the deed bundle.

So, for deed with blockheight=378272, click the string "378272". This leads to:
deedbot.org/bundle-378272.txt

Excerpt (from the top):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically
accurate archive of GnuPG version 1.4.10.

While the minor version number is not intended to be significant, as I do
not at the present time believe there's anything wrong with releases in the
1.4. branch, I do hold usage of GnuPG 2.x to be irresponsible and in
principle harmful to a Republican future.



Looks good.

Browse back to
deedbot.org
Scroll to deed with blockheight=378272, right-click the string "378272", choose "Save link as...", browse to work directory, and save the file as "bundle-378272.txt".

Its size is 6.2 MB.


I'll transfer this file to the droplet and use
diff
to check that its contents is identical to the contents of
gnupg-1.4.10.tar.gz.asc



Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ls -1
bundle-378272.txt
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ sftp root@edgecase-test.net
Connected to edgecase-test.net.

sftp> lls -1

bundle-378272.txt
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc

sftp> pwd

Remote working directory: /root

sftp> cd /home/work


sftp> ls -1

gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc

sftp> put bundle-378272.txt

put bundle-378272.txt Uploading bundle-378272.txt to /home/work/bundle-378272.txt bundle-378272.txt 100% 6319KB 812.5KB/s 00:07


sftp> ls -1

ls -1
bundle-378272.txt
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc

sftp> exit

exit


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ssh root@edgecase-test.net
Last login: Wed Aug 15 11:31:45 2018 from [IP address string]

[root@spt1 ~]# cd /home/work


[root@spt1 work]# ls -1

bundle-378272.txt
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc

[root@spt1 work]# diff --version

diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

[root@spt1 work]# diff gnupg-1.4.10.tar.gz.asc bundle-378272.txt


[root@spt1 work]# diff gnupg-1.4.10.tar.gz bundle-378272.txt

1c1,4
< Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically
---
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Find below a base64 blob of gnupg-1.4.10.tar.gz which is a historically
4c7
< While the minor version number is not intended to be significant, as I do
---
> While the minor version number is not intended to be significant, as I do
84029a84033,84049
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJWGP49AAoJEIpzbw4vt7RS+3MQAIjdyghumfcoJAE+1kHNsapK
> 7kd0SGBG57LZXXRKdg5CdfD/WcRcwNh3EUtXqQ8v9J0EX++FhYigfdqHaMnvcarn
> 3psiKG2QaeGzEm4/qYJ+Lh7fdA2ypXgCGPIeVh6Co9IZnfiIcUk8egd6CnP3Obew
> hOJ+NWZXu4FAZhSST7I7mm1COGjvnLMjvpp7kzJ7h2tTjZE878WZ/r0ID2mDdaHd
> ovmLe3gVLbJpnjiXr6kzET5oWCA2fGwJS+mMKkXZgH3FU45fa2Z85OCxEIujDNwe
> J8gTtZUerHEXsO3h30Ss2f/E8HE40wGtnxWAKmAhNBSLQlSd3l66jy3hg1eGeubs
> S3bur7wHapMN1dN+lu/G/txzCUaZ+DtdXo1gNR24a5AHYbnGEIQQBnvrI9Kzixh5
> YrnGuxSyOKMxBkGApCKbWms0dDiZJoi0+SQgBXVERYq3P0PFEIzbsCg+nZGdTgOM
> 74Xx5sZtk2093w0U1mvTBKoAuA8tNBfohaNQXccFU8Vol5B+KknM+b6VuomTm4oc
> mvuIiVJMl2kSsmkMxG7vR+PMpvZ0dlYd0eTzTYoxg8pjEcC8c0JzxHAFqtisi7No
> 6vgjS/gOu+/VtSsOqLoZxaJk5S6YSRjX3hmBlI5K4hoiPpWsKaB6sfW4HpU826Qw
> MzjO/BUQPn1isWjESUPq
> =+uHn
> -----END PGP SIGNATURE-----



Notes:
- confirmed that
gnupg-1.4.10.tar.gz.asc
is identical to
bundle-378272.txt
- confirmed that
gnupg-1.4.10.tar.gz
is the signature-less version of
gnupg-1.4.10.tar.gz.asc


Cool.




Next: Using the SHA256 hash digest of bundle-378272.txt as a Bitcoin private key, derive the corresponding Bitcoin address.


Note: bundle-378272.txt contains only one deed item.


Browse to the earlier article Generating a standard Bitcoin address, go to the Downloadable Assets section, and download these four assets:

- bjorn_edstrom_ripemd160.py
- ecdsa-0.10.tar.gz
- pypy_sha256.py
- generate_bitcoin_address.py


Put these assets in the work directory.


Now, copy these assets to the droplet.


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ls -1
bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ sftp root@edgecase-test.net
Connected to edgecase-test.net.

sftp> lls -1

bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py

sftp> pwd

pwd
Remote working directory: /root

sftp> cd /home/work


sftp> ls -1

bundle-378272.txt
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc

sftp> put bjorn_edstrom_ripemd160.py
Uploading bjorn_edstrom_ripemd160.py to /home/work/bjorn_edstrom_ripemd160.py bjorn_edstrom_ripemd160.py 100% 14KB 292.6KB/s 00:00
sftp> put ecdsa-0.10.tar.gz
Uploading ecdsa-0.10.tar.gz to /home/work/ecdsa-0.10.tar.gz ecdsa-0.10.tar.gz 100% 44KB 311.9KB/s 00:00
sftp> put generate_bitcoin_address.py
Uploading generate_bitcoin_address.py to /home/work/generate_bitcoin_address.py generate_bitcoin_address.py 100% 5384 106.5KB/s 00:00
sftp> put pypy_sha256.py
Uploading pypy_sha256.py to /home/work/pypy_sha256.py pypy_sha256.py 100% 11KB 41.3KB/s 00:00


sftp> ls -1

ls -1
bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py

sftp> exit

exit


Admin@Admin-PC /cygdrive/c/Users/Admin/Desktop/work/PROJECTS_CURRENT/compile_gpg_1.4.10_from_source/work

$ ssh root@edgecase-test.net
Last login: Wed Aug 15 11:51:04 2018 from [IP address string]

[root@spt1 ~]# cd /home/work


[root@spt1 work]# ls -1

bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py




Now, on the droplet, follow the steps in the Bitcoin Address Generation Recipe section of the earlier article Generating a standard Bitcoin address.


1) Create or generate a private key in raw byte form.


[root@spt1 work]# sha256sum --version

sha256sum (GNU coreutils) 8.4
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Ulrich Drepper, Scott Miller, and David Madore.

[root@spt1 work]# sha256sum bundle-378272.txt

b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346 bundle-378272.txt



SHA256 value to use as a Bitcoin private key:
b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346


Note: This is in hex (which is printable). In the address generation python script, I will need to set the value of the hex bytes input variable, rather than the value of the raw bytes input variable.


2) Unpack the zipped tape archive file ecdsa-0.10.tar.gz file.


[root@spt1 work]# tar --version

tar (GNU tar) 1.23
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

[root@spt1 work]# tar -zxvf ecdsa-0.10.tar.gz

ecdsa-0.10/
ecdsa-0.10/ecdsa/
ecdsa-0.10/ecdsa/__init__.py
ecdsa-0.10/ecdsa/_version.py
ecdsa-0.10/ecdsa/curves.py
ecdsa-0.10/ecdsa/der.py
ecdsa-0.10/ecdsa/ecdsa.py
ecdsa-0.10/ecdsa/ellipticcurve.py
ecdsa-0.10/ecdsa/keys.py
ecdsa-0.10/ecdsa/numbertheory.py
ecdsa-0.10/ecdsa/rfc6979.py
ecdsa-0.10/ecdsa/six.py
ecdsa-0.10/ecdsa/test_pyecdsa.py
ecdsa-0.10/ecdsa/util.py
ecdsa-0.10/LICENSE
ecdsa-0.10/MANIFEST.in
ecdsa-0.10/NEWS
ecdsa-0.10/PKG-INFO
ecdsa-0.10/README.md
ecdsa-0.10/setup.py




3) The unpacking produced a new directory: ecdsa-0.10. ecdsa-0.10 contains a directory named: ecdsa. Copy the ecdsa directory to the work directory. The ecdsa library can now be imported by the generate_bitcoin_address.py script.


[root@spt1 work]# ls -1

bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa-0.10
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py

[root@spt1 work]# ls -1 ecdsa-0.10

ecdsa
LICENSE
MANIFEST.in
NEWS
PKG-INFO
README.md
setup.py

[root@spt1 work]# cp -r ecdsa-0.10/ecdsa ./


[root@spt1 work]# ls -1

bjorn_edstrom_ripemd160.py
bundle-378272.txt
ecdsa
ecdsa-0.10
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py

[root@spt1 work]# ls -1 ecdsa

curves.py
der.py
ecdsa.py
ellipticcurve.py
__init__.py
keys.py
numbertheory.py
rfc6979.py
six.py
test_pyecdsa.py
util.py
_version.py




4) Open the generate_bitcoin_address.py file in a text editor. Set the value of the variable
private_key_hex
to be the private key in hex bytes that was generated earlier.


[root@spt1 work]# nano --version

-bash: nano: command not found

[root@spt1 work]# ed --version

-bash: ed: command not found

[root@spt1 work]# vim --version

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 21 2016 17:10:41) Included patches: 1-207, 209-629 Modified by <bugzilla@redhat.com> Compiled by <bugzilla@redhat.com> Huge version without GUI. Features included (+) or not (-): +acl +farsi +mouse_netterm +syntax +arabic +file_in_path +mouse_sgr +tag_binary +autocmd +find_in_path -mouse_sysmouse +tag_old_static -balloon_eval +float +mouse_urxvt -tag_any_white -browse +folding +mouse_xterm -tcl ++builtin_terms -footer +multi_byte +terminfo +byte_offset +fork() +multi_lang +termresponse +cindent +gettext -mzscheme +textobjects -clientserver -hangul_input +netbeans_intg +title -clipboard +iconv +path_extra -toolbar +cmdline_compl +insert_expand +perl +user_commands +cmdline_hist +jumplist +persistent_undo +vertsplit +cmdline_info +keymap +postscript +virtualedit +comments +langmap +printer +visual +conceal +libcall +profile +visualextra +cryptv +linebreak +python/dyn +viminfo +cscope +lispindent -python3 +vreplace +cursorbind +listcmds +quickfix +wildignore +cursorshape +localmap +reltime +wildmenu +dialog_con -lua +rightleft +windows +diff +menu -ruby +writebackup +digraphs +mksession +scrollbind -X11 -dnd +modify_fname +signs -xfontset -ebcdic +mouse +smartindent -xim +emacs_tags -mouseshape -sniff -xsmp +eval +mouse_dec +startuptime -xterm_clipboard +ex_extra +mouse_gpm +statusline -xterm_save +extra_search -mouse_jsbterm -sun_workshop -xpm system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" 2nd user vimrc file: "~/.vim/vimrc" user exrc file: "$HOME/.exrc" fall-back for $VIM: "/etc" f-b for $VIMRUNTIME: "/usr/share/vim/vim74" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 Linking: gcc -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE -L/usr/local/lib -Wl,--as-needed -o vim -lm -lnsl -lselinux -ltinfo -lacl -lattr -lgpm -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE -fstack-protector -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc




The text editor
vim
is available.


A previous project, Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin, includes a basic guide to
vi
commands. Browse to the article and search for the string "# WHAT IS VI?".

Some reading indicates that
vim
is an extension of the
vi
editor, and most of the
vi
commands work the same way in
vim
.

Now, use
vim
to open the file generate_bitcoin_address.py and change the value of the variable
private_key_hex
to be the SHA256 hash digest hex value:
b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346


[The vim commands for accomplishing this are not included here]


5) Run the script generate_bitcoin_address.py.
Note: It was developed under Python 2.7.13.


[root@spt1 work]# python --version

Python 2.6.6

[root@spt1 work]# python generate_bitcoin_address.py

- INPUT: private_key_bytes: hello_world - private_key_hex: b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346 Traceback (most recent call last): File "generate_bitcoin_address.py", line 147, in <module> if __name__ == '__main__': main() File "generate_bitcoin_address.py", line 45, in main print "- 32-byte private_key_hex: %s" % private_key_hex2 UnboundLocalError: local variable 'private_key_hex2' referenced before assignment


Note:
- Ignore this line:
- INPUT: private_key_bytes: hello_world



Looking at the code, I see that there is no default value for the variable
private_key_hex2
. If
private_key_hex
is already 32 bytes long, then the
if
statement won't execute and the variable
private_key_hex2
will not be initialised, causing an error on line 45 when it is accessed.


Relevant section of the code:

generate_bitcoin_address.py

python 2.7.13
	print "- private_key_hex: %s" % private_key_hex
	
	# format private key as 32 bytes.
	n = len(private_key_hex) / 2
	m = 32 - n
	if m > 0:
		# add leading zero bytes to extend private_key_hex to 32 bytes
		private_key_hex2 = m * "00" + private_key_hex
	print "- 32-byte private_key_hex: %s" % private_key_hex2



Solution: Insert the following line immediately after line 39:
private_key_hex2 = private_key_hex



Result:

generate_bitcoin_address.py

python 2.7.13
	print "- private_key_hex: %s" % private_key_hex
	
	# format private key as 32 bytes.
	private_key_hex2 = private_key_hex
	n = len(private_key_hex) / 2
	m = 32 - n
	if m > 0:
		# add leading zero bytes to extend private_key_hex to 32 bytes
		private_key_hex2 = m * "00" + private_key_hex
	print "- 32-byte private_key_hex: %s" % private_key_hex2



Use
vim
to edit
generate_bitcoin_address.py
on the droplet in order to implement the change described above.

[The vim commands for accomplishing this are not included here]


[root@spt1 work]# python generate_bitcoin_address.py


- INPUT: private_key_bytes: hello_world
- private_key_hex: b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346
- 32-byte private_key_hex: b675ceedba0843d19934d1e0508cde736b4bb7f0a56b9585329ebcbfed559346
- private key lies within input domain of secp256k1 elliptic curve.
- private_key_WIF: 5KCeHKP7qtyKYZQ2jeJt1gBagJQ9UJpS9kf5W6ew8jUuPapBrdg
- public_key_hex: 042098dc0b92c12d2f23505c1996626caf41606fc7ee4094eb7032fff26e4be7eae382aee4eafe8ec66ce512d84088ceef238d165d1f5348ea98a05dea6e2c6e08
- Bitcoin address: 1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X

[root@spt1 work]# exit

logout
Connection to edgecase-test.net closed.




Good.


Next: Look for a transaction that sends bitcoin to Bitcoin address
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
within the deed block at blockheight 378272.


Browse to:
www.blockchain.com/explorer

Search for blockheight 378272.
Result:
www.blockchain.com/btc/block/000000000000000000cd0f8777fcbbfddb3c4254b6bc04339977767f2fb4b151
Timestamp = 2015-10-10 13:00:31


Deed submission message timestamp:
Sat, 10 Oct 2015 12:08:05 GMT


Good. Judging by timestamps, the deed block occurred within the next hour after the submission.


I'm using the Chrome browser. On the block display page, search for the Bitcoin address
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X

I find 1 result, the transaction with transaction id (txid)
597f61fa3811a78a9d401094e4132f281c400b61bb8742514ab758aad0e2daa0


The txid links to a transaction page:
www.blockchain.com/btc/tx/597f61fa3811a78a9d401094e4132f281c400b61bb8742514ab758aad0e2daa0


Transaction details:
- datetime: 2015-10-10 13:00:31
- source address:
1BkCTj36DMdcF8TVa1by9zfwdcMFm3VAES (0.0916 BTC)
- destination addresses:
1BkCTj36DMdcF8TVa1by9zfwdcMFm3VAES (0.0914 BTC)
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X (0.0001 BTC)
- total input: 0.0916 BTC
- total output: 0.0915 BTC
- size: 259 bytes
- fee: 0.0001 BTC

One of the destination addresses is the same as the input address.

So: 0.0001 bitcoin was transferred from
1BkCTj36DMdcF8TVa1by9zfwdcMFm3VAES
to the deed bundle address
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X


On the transaction page, addresses link to address pages.
Click
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
It leads to:
www.blockchain.com/btc/address/1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X


Address details:
- No. of transactions: 2
- Total received: 0.0001 BTC
- Final Balance: 0 BTC


There was a second transaction, which transferred the available bitcoin out of the deed bundle address.

txid:
eebd52abd46762a172be87fe8c0a463476a7f6f709a5e9ebd929d86822be0f1c


Browse to transaction page.
www.blockchain.com/btc/tx/eebd52abd46762a172be87fe8c0a463476a7f6f709a5e9ebd929d86822be0f1c

transaction details:
- datetime: 2015-10-16 21:28:23
- source addresses:
19mxAPvaFDnArssXDRXKmJXeboBoVoD6er
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X
- destination address:
1Pb8RBEy24hTyajq1gecDNcif9EQZqjbQT (0.0001382 BTC)
- total input: 0.0002 BTC
- total output: 0.0001382 BTC
- size: 406 bytes
- fee: 0.0000618 BTC


deed block's datetime:
2015-10-10 13:00:31


So, the available bitcoin was transferred out 6 days later.




Excellent. I have confirmed that the file
gnupg-1.4.10.tar.gz.asc
in my possession was in fact:
- signed by Mircea Popescu's public key
- deeded (timestamped in the Bitcoin blockchain) in the mainchain block at blockheight 378272 with datetime 2015-10-10 13:00:31 by a transaction that sent 0.0001 bitcoin to the address
1FJdRWN7tAd8rnivBm7yojppwvDmS7F55X





Loose end: Patch for generate_bitcoin_address.py.


Currently, in generate_bitcoin_address.py, if
private_key_hex
is already 32 bytes long, the
if
statement on line 42 won't execute, and the variable private_key_hex2 won't be created, causing an error on line 45.

In the copy of generate_bitcoin_address.py in the project directory, insert the following line immediately after line 39:
private_key_hex2 = private_key_hex


The line shown above is now line 40.

Add this new version of generate_bitcoin_address.py to this article as an asset. Change its name to
generate_bitcoin_address_2.py.



Loose end: Preserve bundle-378272.txt as an asset?

No. It's identical to
gnupg-1.4.10.tar.gz.asc

Preserve
gnupg-1.4.10.tar.gz.asc
as an asset of this article.




Loose end: Log into droplet, delete everything used in this project, except
gnupg-1.4.10.tar.gz.asc,
which I want to use in a future project: Compiling GPG 1.4.10 from source.



Admin@Admin-PC ~

$ pwd
/home/Admin


Admin@Admin-PC ~

$ ssh root@edgecase-test.net
Last login: Wed Aug 15 13:22:24 2018 from [IP address string]

[root@spt1 ~]# cd /home/work


[root@spt1 work]# ls -1

bjorn_edstrom_ripemd160.py
bjorn_edstrom_ripemd160.pyc
bundle-378272.txt
ecdsa
ecdsa-0.10
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
gnupg-1.4.10.tar.gz.asc
mircea_popescu.asc
pypy_sha256.py
pypy_sha256.pyc

[root@spt1 work]# ls /home

work

[root@spt1 work]# mv gnupg-1.4.10.tar.gz.asc ../


[root@spt1 work]# ls -1 /home

gnupg-1.4.10.tar.gz.asc
work

[root@spt1 work]# ls -1

bjorn_edstrom_ripemd160.py
bjorn_edstrom_ripemd160.pyc
bundle-378272.txt
ecdsa
ecdsa-0.10
ecdsa-0.10.tar.gz
generate_bitcoin_address.py
gnupg-1.4.10.tar.gz
mircea_popescu.asc
pypy_sha256.py
pypy_sha256.pyc

[root@spt1 work]# rm *

rm: cannot remove `ecdsa': Is a directory
rm: cannot remove `ecdsa-0.10': Is a directory

[root@spt1 work]# ls -1

ecdsa
ecdsa-0.10

[root@spt1 work]# rm -r *


[root@spt1 work]# ls -1


[root@spt1 work]# mv ../gnupg-1.4.10.tar.gz.asc ./


[root@spt1 work]# ls -1 /home

work

[root@spt1 work]# ls -1

gnupg-1.4.10.tar.gz.asc

[root@spt1 work]# exit

logout
Connection to edgecase-test.net closed.



Good.



Loose end: When I use the command
ssh root@edgecase-test.net
,
the output includes a line describing the previous login:
Last login: Wed Aug 15 11:31:45 2018 from [IP address string]

I think it's an IP address string. It contains digits but also (what appear to be) network hostnames.

I'd prefer not to publish my local router address. Go through the project log and (carefully) replace all IP address strings in
ssh
login output with the string "[IP address string]".




That's the end of this project.











[start of notes]



I went over the project log later and expanded some work sections and some explanations. This means that datetimes in computer output e.g.
$ ssh root@edgecase-test.net

Last login: Mon Aug 6 19:47:05 2018 from [IP address string]

may not proceed in an exact linear sequence.

The project directory in this project was named:
compile_gpg_1.4.10_from_source

This project was spun off from another unpublished project: Compiling GPG 1.4.10 from source. This is why the project directory is not named
"verify_signed_deed_of_gpg_1.4.0_source_code".



- I have not always preserved the format of any excerpts from webpages on other sites (e.g. not preserving the original bold/italic styles, changing the list structures, not preserving hyperlinks).
- I have not always preserved the format of any computer output (e.g. from running bash commands). Examples: Setting input lines in bold text, adding/removing newlines in order to make a sequence of commands easier to read, using hyphens for lists and sublists instead of indentation, breaking wide tables into consecutive sections.




[end of notes]