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








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








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)











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):



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











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

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:


This fixes the problem in the previous version where, if is already 32 bytes long, the 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]











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 , 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.






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



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 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):


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:


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 flag will cause GnuPG to generate output containing only printable characters.
- An "inline signature" is the result of using the 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 commands. Browse to the article and search for the string "# WHAT IS VI?".

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


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.











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.












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





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):





Excerpt (lines 84025-84050):






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 option. The option causes the output to be in encoded only in printable ASCII characters.

In order to use the command

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 tool to do this. I'll see if it's already available in my Cygwin instance.


Open a Cygwin terminal.




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).








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.





Notes:
- Looks as though the 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:

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.



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 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



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:

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 to check that its contents is identical to the contents of
gnupg-1.4.10.tar.gz.asc






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.






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.





SHA256 value to use as a Bitcoin private key:


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.






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.






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






The text editor is available.


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

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

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


[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.




Note:
- Ignore this line:



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


Relevant section of the code:




Solution: Insert the following line immediately after line 39:



Result:




Use 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]






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)


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:


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 is already 32 bytes long, the 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:


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.






Good.



Loose end: When I use the command
,
the output includes a line describing the previous login:

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 login output with the string "[IP address string]".




That's the end of this project.














I went over the project log later and expanded some work sections and some explanations. This means that datetimes in computer output e.g.

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.