Store bitcoin on an offline Raspberry Pi.







- Goal
- Contents
- Brief Summary
- Summary
- Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction #2
- Recipe For Manually Mounting A USB Memory Stick
- Representative Sample Of Bash Commands Used
- Downloadable Assets
- Notes
- Financial Information For This Project
- Further Work
- Project Log







I generated an address on an offline Raspberry Pi. I tested this address by successfully transferring a small amount of bitcoin into and out of it, proving that I could always retrieve bitcoin from it.

I then transferred a larger amount of bitcoin into the address, and stored it there for a week.

Note: All transactions were constructed and signed offline, then manually transferred to an online computer for broadcasting.











Goal


Store bitcoin on an offline Raspberry Pi.




Overall results:


- I generated an address (the "test address") on an offline Raspberry Pi.
- I validated the test address by successfully transferring a small amount of bitcoin into and out of it. This allowed me to be certain that I could retrieve bitcoin from it.
- I stored a larger amount of bitcoin in the test address for a week, before transferring it back to an exchange service.
- All transactions were constructed and signed offline, then manually transferred to an online computer for broadcasting.




Original plan of action for this project:


- Download necessary code from previous articles.

- Create a private key. Store it on the Raspberry Pi. This will require generating entropy.

- Generate a Bitcoin address from the private key.

- Test this address by transferring some bitcoin into and out of it.

- Store a larger amount of bitcoin in the address.

- The private key will of course be revealed in the article describing this project, so this bitcoin won't be stored permanently in this address. Instead, I'll transfer the bitcoin out again. To store some bitcoin, a reader can follow all the steps apart from this one.




What I actually did during the project:


0) My equipment is listed in the "Equipment" part of the Notes section.

1) I chose this set of previous articles:
- Recipe for generating entropy bytes using dice
- Recipe for generating a Bitcoin address
- Recipe for creating and signing a standard Bitcoin transaction
- Recipe for creating and signing a nonstandard Bitcoin transaction
- Displaying hex bytes for manual copying

2) I downloaded all the assets linked from these articles. Note: Some assets are linked from more than one of these articles.

List of downloaded assets:

- bitcoin_functions.py
- bjorn_edstrom_ripemd160.py
- convert_dice_rolls_to_hex_bytes_2.py
- create_nonstandard_transaction.py
- create_transaction.py
- display_hex_bytes.py
- ecdsa-0.10.tar.gz
- generate_bitcoin_address_3.py
- nonstandard_bitcoin_functions.py
- nonstandard_transaction.py
- pypy_sha256.py
- transaction.py

These assets are linked in the Downloadable Assets section.

3) Using a memory stick, I transferred these assets from my work computer Aineko to the Raspberry Pi. To find out how to do this, please see the section Recipe For Manually Mounting A USB Memory Stick.

4) I logged commands and command output on the Raspberry Pi. Please see the "Recording shell output" part of the Notes section for details. Later, I transferred these logs back to Aineko for integration into this article.

5) I checked and recorded some details about the Raspberry Pi (its operating system, the versions of various tools).

6) I generated a private key using dice and stored it on the Raspberry Pi. I then derived the corresponding Bitcoin address, which I called the "test address".

Note: Files containing the various dice roll results are listed in the Downloadable Assets section. The entropy values derived from these files are included in the "Entropy values generated during this project" part of the Notes section.

7) I calculated an amount of bitcoin to use for validating the test address. Details are included in the section Financial Information For This Project. I used LocalBitcoins to transfer some bitcoin to the test address. LocalBitcoins created a transaction that included this transfer. I named this transaction "tx0".

8) I used a service to obtain information about tx0. Some of this information was needed for constructing a transaction that spent from the test address.

Note: I used various services during this project. They are listed in the "Services used during this project" part of the Notes section.

9) I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1 (on my LocalBitcoins account). I named this transaction "tx1" and later "tx1a". I used a transaction-broadcasting service to broadcast it to the Bitcoin network. This transaction was never mined. LocalBitcoins saw this transaction and generated a new receiving address for my account, "receiving address 2".

Note: All transactions in this project were manually transferred to the online computer (Aineko) from the offline Raspberry Pi. I used the display_hex_bytes.py tool to display the transaction hex bytes in a more easily-read format.

Note: The addresses used in this project are listed in the "Addresses generated and/or used in this project" part of the Notes section.

Note: The transactions that I created in this project are displayed in the "Transactions created during this project" part of the Notes section. Details about the transactions that LocalBitcoins created are also included.

10) I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2. I called this transaction "tx1b". This transaction was rejected by two transaction-broadcasting services, because it was a double-spend attempt (it tried to spend the same unspent output as tx1a did, but to a different address, while tx1a was still in the memory pools of the services). I was thinking about the fee rate change and had forgotten that the Bitcoin network would perceive it as a double-spend attempt.

Note: Several points concerning Bitcoin transactions:
- New transactions spend unspent-outputs-of-previous-transactions. These can also be called "inputs".
- The bitcoin balance of an address is the sum of the unspent outputs sent by previous transactions to this address.
- To spend bitcoin from an address, the bitcoin amount must be constructed from complete inputs. Any change can be sent in a new unspent output back to the original address or to another address that you control. Inputs cannot be broken into smaller inputs prior to spending - new inputs (larger or smaller) must be created by a new transaction.

11) I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1, using a higher fee than in tx1a. I called this transaction "tx1c". This was a replace-by-fee transaction (only the fee was different), which is valid on the Bitcoin network (unlike a double-spend transaction), but the two transaction-broadcasting services still rejected it. I waited until tx1a had been cleared from the memory pool of one of the transaction-broadcasting services (this took about 48 hours), and then uploaded tx1c again to that service. This time, the service accepted tx1c, which was later mined.

Note: A recipe for making replace-by-fee transactions is included in the section Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction #2.

Note: A new entropy value is needed for each transaction signature.

Note: The times taken for confirmation of tx1c and tx3 are shown in the "Transaction confirmation times" part of the Notes section.

12) The successful mining of tx1c validated the test address. It proved that the address was correctly calculated from the private key. I could now move a large amount of bitcoin into this address and be certain that I could retrieve it. Even if I later constructed a new transaction that turned out to be invalid, and discovered that the cause was an error in the code stack used to create and sign a transaction, I knew that eventually this error could be fixed and a valid transaction could be created. I would only risk a temporary lack of access to the bitcoin stored in this address, not its permanent loss.

13) I used LocalBitcoins to transfer a relatively larger amount of bitcoin ($50 worth at the then-current exchange rate) to the test address. LocalBitcoins created a transaction that included this transfer. I named this transaction "tx2".

14) I used a service to obtain information about tx2. Some of this information was needed for constructing a transaction that could spend from the test address (more specifically: could spend the unspent output that tx2 sent to the test address).

15) A week passed, during which $50 worth of bitcoin was stored on the Raspberry Pi.

16) I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2 (on my LocalBitcoins account). I named this transaction "tx3". I used a transaction-broadcasting service to broadcast it to the Bitcoin network. After a while, tx3 was mined.

17) This project was now completed. I had approximately carried out the original plan of action, with a deviation (tx1b) and a significant amount of extra detail and additional steps.




Notes section:


The Notes section contains the following parts:

- Definitions and acryonyms
- Services used during this project
- Equipment used during this project
- Entropy values generated during this project
- Addresses generated and/or used in this project
- Transactions created during this project
- create_nonstandard_transaction.py settings used to create the transactions
- Time taken to manually transfer transactions by typing
- Transaction confirmation times
- Dice rolling results
- Recording shell output
- Miscellaneous









A previous recipe with this title was published in the article Creating and signing a standard raw Bitcoin transaction, in the section Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction.


Objectives:
- Fine control of the transaction fee.
- Ability to rebroadcast a new transaction with a higher fee if the previous transaction is not mined within a reasonable time period. This new transaction, if mined, should invalidate the previous transaction.

Several points concerning Bitcoin transactions:
- New transactions spend unspent-outputs-of-previous-transactions. These can also be called "inputs".
- The bitcoin balance of an address is the sum of the unspent outputs sent by previous transactions to this address.
- To spend bitcoin from an address, the bitcoin amount must be constructed from complete inputs. Any change can be sent in a new unspent output back to the original address or to another address that you control. Inputs cannot be broken into smaller inputs prior to spending - new inputs (larger or smaller) must be created by a new transaction.


1) Gather the required data for a new transaction. How to do this is not specified in this recipe. Include at least one "change address" output. Inputs should be added as necessary to achieve the desired output values. The sum of the inputs may be greater than the sum of the desired output values, i.e. some bitcoin may be left over. This left-over bitcoin should be sent to the change address output. Include an additional input that is specifically for paying the as-yet-unknown transaction fee. Set the bitcoin in this input to be sent to the change address output.

2) Look at current Bitcoin network transaction fee rates. How to do this is not specified in this recipe. Choose a fee rate for the transaction.

3) Use a software tool to create and sign a transaction with the specified fee rate. This tool must be able to calculate an estimate of the transaction size in order to derive a fee value from the fee rate. This fee value will be stored implicitly in the transaction as the difference between the input values and the output values. After the tool has created and signed the transaction, it should calculate and report the actual fee rate of the final signed form of the transaction. The process / structure of the software tool is not specified in this recipe.

4) Broadcast the transaction to the Bitcoin network or upload the transaction to a service that can do this for you. How to do this is not specified in this recipe.

5) A node will store unconfirmed transactions in its memory pools for a particular time period. If the transaction is not mined (confirmed) within this period, the node will delete it from its memory pool. This period will vary depending on the node. Some reading indicates that the default period is 72 hours (3 days). I have tried this once during this project - the delay was about 48 hours (2 days). After broadcasting the transaction, wait 3 days + a small delay. If the transaction is mined during this period, stop here (and wait for the transaction to be 6 blocks deep in the Bitcoin blockchain). Otherwise, confirm that it has been deleted from the relevant node's memory pool (by e.g. looking up the transaction's txid) and continue to step (6).

Note: If you run a node that accepts replace-by-fee transactions (or have access to a service that does this), then you can upload a new version of the transaction immediately, without waiting for it to be removed from the node's memory pool. If there exists a path through the Bitcoin network from your node to a miner's node, consisting of nodes that all accept replace-by-fee transactions, then the new version of your transaction will propagate along this path, allowing you to quickly replace an unconfirmed transaction with a new version. The miner's node will probably be set to accept replace-by-fee transactions for mining, as this is necessarily more profitable.

6) Look at current Bitcoin network transaction fee rates. How to do this is not specified in this recipe. Choose a higher fee rate than the one chosen in step (2).

7) Repeat steps (2)-(6) until the transaction is mined.


Note: If a transaction disappears from the network (i.e. the memory pools of all public nodes), this doesn't mean that it has vanished permanently. Anyone who stored it can rebroadcast it later - it will still be valid. In order to make it invalid, create a new transaction that uses at least one of the same inputs.

Note: An input in a transaction is an as-yet-unspent output of a previous transaction. Each unspent output can only ever be spent once. If a transaction is broadcast that uses at least one input that has already been spent, this transaction is invalid and will not be mined.









0) Copy data that you wish to transfer to the destination computer into a directory named "work", located at the top level of the filesystem on the memory stick.


1) Insert the memory stick into a USB port on the destination computer.


2) If you are using a command-line interface, skip this step. If you are using a graphical user interface, open a terminal emulator.


3) Use the following command sequence to manually mount the memory stick (i.e. make its filesystem accessible).




4) Use the following commands to copy data to and from the memory stick.




5) Use the following command sequence to unmount the memory stick. Once unmounted, it can be physically unplugged without causing any problems.




6) Unplug the memory stick from the destination computer.











Note: The output is not always included for every command.






Example of logging into a Raspberry Pi using the default credentials (username = "pi", password = "raspberry"). Note that the password is not printed to the screen.

[Insert the power cable into the Raspberry Pi. Wait for it to boot up.]





Example of shutting down a Raspberry Pi:



[Then unplug the power cable.]











This article's assets are files containing 5 sets of 212 dice rolls. 32 bytes of entropy were derived from each set.

List of assets:
- dice_rolls_3.txt (known during this project as dice_rolls.txt)
- dice_rolls_4.txt (known during this project as dice_rolls2.txt)
- dice_rolls_5.txt (known during this project as dice_rolls3.txt)
- dice_rolls_6.txt (known during this project as dice_rolls4.txt)
- dice_rolls_7.txt (known during this project as dice_rolls5.txt)

The asset names have been changed because this datafeed already contains some existing assets with the prefix "dice_rolls".

Asset: Set 1 of the dice roll results
dice_rolls_3.txt

Asset: Set 2 of the dice roll results
dice_rolls_4.txt

Asset: Set 3 of the dice roll results
dice_rolls_5.txt

Asset: Set 4 of the dice roll results
dice_rolls_6.txt

Asset: Set 5 of the dice roll results
dice_rolls_7.txt



The following code assets were developed / tested on my work computer during previous projects. During this project, I used them successfully on the offline computer.

List of assets of other articles:
1) bitcoin_functions.py
2) bjorn_edstrom_ripemd160.py
3) convert_dice_rolls_to_hex_bytes_2.py
4) create_nonstandard_transaction.py
5) create_transaction.py
6) display_hex_bytes.py
7) ecdsa-0.10.tar.gz
8) generate_bitcoin_address_3.py
9) nonstandard_bitcoin_functions.py
10) nonstandard_transaction.py
11) pypy_sha256.py
12) transaction.py

Asset 1: A library of functions for handling standard Bitcoin data types.
bitcoin_functions.py [paywalled]

Asset 2: An implementation of RIPEMD-160, written by Björn Edström.
bjorn_edstrom_ripemd160.py [paywalled]

Asset 3: A script that converts dice roll results into bytes.
convert_dice_rolls_to_hex_bytes_2.py [paywalled]

Asset 4: A script that creates and signs a nonstandard Bitcoin transaction with one standard P2PKH input and one nonstandard P2SH output.
create_nonstandard_transaction.py [paywalled]

Asset 5: A script that creates and signs a standard Bitcoin transaction with one input and one output.
create_transaction.py [paywalled]
Note: This asset was not actually used during this project.

Asset 6: A script that prints a hex byte string, inserting spaces and newlines to make it more readable.
display_hex_bytes.py [paywalled]

Asset 7: A Python implementation of ECDSA cryptography, written by Peter Pearson.
ecdsa-0.10.tar.gz [paywalled]

Asset 8: A script that generates a standard Bitcoin address from a private key.
generate_bitcoin_address_3.py [paywalled]

Asset 9: A library of functions for handling nonstandard Bitcoin data types.
nonstandard_bitcoin_functions.py [paywalled]

Asset 10: A library of classes for nonstandard Bitcoin transactions.
nonstandard_transaction.py [paywalled]

Asset 11: A Python implementation of SHA256.
pypy_sha256.py [paywalled]

Asset 12: A library of classes for standard Bitcoin transactions.
transaction.py [paywalled]



List of the articles that I read in order to choose these assets:
- Recipe for generating entropy bytes using dice
- Recipe for generating a Bitcoin address
- Recipe for creating and signing a standard Bitcoin transaction
- Recipe for creating and signing a nonstandard Bitcoin transaction
- Displaying hex bytes for manual copying

















Parts:


- Definitions and acryonyms
- Services used during this project
- Equipment used during this project
- Entropy values generated during this project
- Addresses generated and/or used in this project
- Transactions created during this project
- create_nonstandard_transaction.py settings used to create the transactions
- Time taken to manually transfer transactions by typing
- Transaction confirmation times
- Dice rolling results
- Recording shell output
- Miscellaneous






Definitions and acryonyms


P2PKH = Pay-To-Public-Key-Hash

P2SH = Pay-To-Script-Hash

previous_output_hash is the big-endian 32-byte double-SHA256 hash of a previous transaction.

tx = transaction

txid = "transaction id". It is the little-endian form of the previous_output_hash.

aka = "also known as". Indicates a secondary name for something. Example: Robert (aka Bob) is a good programmer. Example: Transaction tx1 (aka tx1a) was never mined.


My working definition of a standard transaction:
- It has at least one input and at least one output.
- All input and output addresses are Pay-To-Public-Key-Hash (P2PKH).
- All input scriptSigs contain uncompressed public keys.


My working definition of a nonstandard transaction:
- It has at least one input and at least one output.
- At least one input or output address is not a standard Pay-To-Public-Key-Hash (P2PKH) address.


My working definition of a standard address:
- An uncompressed single-signature Pay-To-Public-Key-Hash (P2PKH) address.






Services used during this project


I used
localbitcoins.com
to:
- store some bitcoin
- transfer a small amount of bitcoin to the test address
- receive this small amount back again from the test address
- transfer a relatively larger amount of bitcoin to the now-validated test address
- receive this larger amount back again from the test address

I used
bitcoinfees.earn.com
to choose fee rates for my transactions. It displays estimated delays (in blocks and in minutes) for ranges of fee rates (in satoshis / byte).

I used the search field at
live.blockcypher.com
to search for transactions by txid.

On the resulting transaction pages e.g. for tx0:
live.blockcypher.com/btc/tx/07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd
I was able to click Advanced Details / API Call, which produced a raw text dump of the transaction, e.g.
api.blockcypher.com/v1/btc/main/txs/07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd?limit=50&includeHex=true

Note: I had to read through the transaction raw text dump in order to find the index of a particular unspent output. A service that allowed someone to look up the index of an unspent output would be useful.

I used
live.blockcypher.com/btc/decodetx
to decode a signed transaction. If the service can successfully decode a transaction, this indicates that the transaction is formatted correctly.

I used
live.blockcypher.com/btc/pushtx
to upload a signed transaction for broadcast to the Bitcoin network.

I used
www.blockchain.com/btc/pushtx
to attempt to upload a signed transaction for broadcast to the Bitcoin network. The error message it produced was helpful.

I used the search field at
www.blockchain.com
to search for transactions (by txid) and for addresses.






Equipment used during this project


My work computer: Aineko, a 2008 Macbook running Mac OS X 10.6.8 Snow Leopard, with Python 2.7.13 installed.

The offline computer used during this project: A Raspberry Pi, Model B+ V1.2 [circa 2014]. It has various ports, including 4 USB ports (which allows simultaneous use of a mouse, a keyboard, and a memory stick) and an HDMI port. It does not have an onboard WiFi chip. I have various peripherals for the Raspberry Pi. These are: An 8GB micro SD card with an installed operating system, a Raspberry Pi power cable, a screen with a DVI port, a screen power cable, a DVI male-male connector cable, a DVI female to HDMI male converter, a USB keyboard, a USB mouse, and a plastic case customised for the Raspberry Pi Model B+. The installed operating system is Raspbian GNU/Linux 7 (wheezy) and the Linux kernel version is 4.1.13+. Tools: nano 2.2.6, tee 8.13, Python 2.7.3.

USB memory stick: 8 GB, FAT32 format, name = "NO NAME"






Entropy values generated during this project


Using dice, I generated 5 sets of 212 dice rolls. Files containing the dice roll results are listed in the Downloadable Assets section. I extracted 32 bytes of entropy from each set, producing these files, which contain entropy values:

- private_key.txt
- random_value2.txt
- random_value3.txt
- random_value4.txt
- random_value.txt

The values in these files were printed during the logged work on the Raspberry Pi, so I can go over the project log, find them, and copy them here.

Values:

- private_key.txt


- random_value.txt


- random_value2.txt


- random_value3.txt


- random_value4.txt


Note that random_value2.txt and random_value3.txt contain the same value. The value in random_value3.txt should have been derived from dice_rolls4.txt, but I accidentally derived it from dice_rolls3.txt instead.

Uses of these entropy values:
- private_key.txt was used as the private key for the test address.
- random_value.txt was used to sign tx1a.
- random_value2.txt was used to sign tx1b.
- random_value3.txt was used to sign tx1c.
- random_value4.txt was used to sign tx3.






Addresses generated and/or used in this project


I generated one address: "test address"

Test address:
- Private key (hex bytes):
c592e1dad5e9871fdeffb551b4544b0a1cf0378c6371d7a397ff5faf04c934ca
- Bitcoin address:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK

The test address was an output address in transactions tx0 and tx2 (both created by the LocalBitcoins service).


I used two receiving addresses on my LocalBitcoins account.

Receiving address 1: "output address"
369Dpo9CrJASneaHLdwWfKym7N84XTUyvH

Receiving address 1 was the output address for tx1 (aka tx1a) and tx1c.

Because LocalBitcoins saw tx1a, which used receiving address 1 as its output address, LocalBitcoins generated a second receiving address (receiving address 2), even though tx1a was never mined.

Receiving address 2: "output address", later "lb_address2" (lb = LocalBitcoins)
36p1w3YrNKd2Q3xaXbe9ASUQkeynjVLfDx

Receiving address 2 was the output address for tx1b and tx3.


Note from LocalBitcoins concerning receiving addresses:

{To protect your privacy, we provide a new bitcoin address for each transfer. This prevents someone from tracking all the payments you receive by looking at the blockchain.

Note that addresses are valid only for 12 months.}


Because of this note, I used receiving address 1 as an output address in tx1c (mined), even though LocalBitcoins had already generated receiving address 2 for me after seeing tx1a (never mined). LocalBitcoins still interpreted tx1c as a deposit to my account.






Transactions created during this project




Transactions:
- tx0
- tx1 / tx1a
- tx1b
- tx1c
- tx2
- tx3




I'll use:
- txid0 to mean the txid (transaction id) of tx0
- txid1 to mean the txid of tx1 (aka tx1a)
- txid1a to mean the txid of tx1a
- txid1b to mean the txid of tx1b
- txid1c to mean the txid of tx1c
- txid2 to mean the txid of tx2
- txid3 to mean the txid of tx3




Transaction sequence:
- tx0: I used LocalBitcoins to transfer some bitcoin to the test address. LocalBitcoins created a transaction that included this transfer.
- tx1 / tx1a: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1 (on my LocalBitcoins account). I used a transaction-broadcasting service to broadcast it to the Bitcoin network. This transaction was never mined. LocalBitcoins saw this transaction and generated a new receiving address for my account, "receiving address 2".
- tx1b: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2. This transaction was rejected by two transaction-broadcasting services, because it was a double-spend attempt (it tried to spend the same unspent output as tx1a did, but to a different address, while tx1a was still in the memory pools of the services).
- tx1c: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1, using a higher fee than in tx1a. This was a replace-by-fee transaction (only the fee was different), which is valid on the Bitcoin network (unlike a double-spend transaction), but the two transaction-broadcasting services still rejected it. I waited until tx1a had been cleared from the memory pool of one of the transaction-broadcasting services, and then uploaded tx1c again to that service. This time, the service accepted tx1c, which was later mined.
- tx2: I used LocalBitcoins to transfer a relatively larger amount of bitcoin to the test address. LocalBitcoins created a transaction that included this transfer.
- tx3: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2 (on my LocalBitcoins account). I used a transaction-broadcasting service to broadcast it to the Bitcoin network. After a while, tx3 was mined.




1) tx0: I used LocalBitcoins to transfer some bitcoin to the test address. LocalBitcoins created a transaction that included this transfer.

txid0:


I did not obtain and use the raw byte sequence of transaction tx0. Instead, I used a service to get the information I needed about an output in tx0. To repeat my steps, browse to the link below, click "Advanced Details", and click "API Call". The result will be the service's information concerning tx0, not the raw form of tx0 as stored in the Bitcoin blockchain.
live.blockcypher.com/btc/tx/07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd

Key details:
- block_hash:
0000000000000000001b43b8af8973377619def5043634e9cb2d7dd584d973be
- block_height: 550741
- confirmed: 2018-11-19T19:46:37Z
- received: 2018-11-19T19:46:37Z
- txid:
07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd
- vout_sz (number of outputs): 32

tx0 sent a new unspent output to the test address.

From tx0, I acquired the following data of this particular unspent output for use as the input in tx1:
- index: 15
- value: 0.002 bitcoin
- The txid of tx0, which contains this unspent output, is:
07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd




2) tx1 / tx1a: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1 (on my LocalBitcoins account). I used a transaction-broadcasting service to broadcast it to the Bitcoin network. This transaction was never mined. LocalBitcoins saw this transaction and generated a new receiving address for my account, "receiving address 2".

txid1 / txid1a:


tx1 / tx1a (raw byte form):





3) tx1b: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2. This transaction was rejected by two transaction-broadcasting services, because it was a double-spend attempt (it tried to spend the same unspent output as tx1a did, but to a different address, while tx1a was still in the memory pools of the services).

txid1b:


tx1b (raw byte form):





4) tx1c: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 1, using a higher fee than in tx1a. This was a replace-by-fee transaction (only the fee was different), which is valid on the Bitcoin network (unlike a double-spend transaction), but the two transaction-broadcasting services still rejected it. I waited until tx1a had been cleared from the memory pool of one of the transaction-broadcasting services, and then uploaded tx1c again to that service. This time, the service accepted tx1c, which was later mined.

txid1c:


tx1c (raw byte form):


Key details:
- block_hash:
000000000000000000091db255f327f3938cb33cd1076d7554b7bbd22b9c1000
- block_height: 551106
- confirmed: 2018-11-22T20:17:05Z
- received: 2018-11-22T17:46:01.324Z
- hash (txid):
8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0
- vout_sz (number of outputs): 1




5) tx2: I used LocalBitcoins to transfer a relatively larger amount of bitcoin to the test address. LocalBitcoins created a transaction that included this transfer.

txid2:


I did not obtain and use the raw byte sequence of transaction tx2. Instead, I used a service to get the information I needed about an output in tx2. To repeat my steps, browse to the link below, click "Advanced Details", and click "API Call". The result will be the service's information concerning tx2, not the raw form of tx as stored in the Bitcoin blockchain.
live.blockcypher.com/btc/tx/af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2

Key details:
- block_hash:
0000000000000000001f85686e50bbc4e929b50768669165731e5c73a690f680
- block_height: 551219
- block_index: 502
- hash (txid):
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2
- total: 4991126340
- fees: 152990
- size: 2822
- preference: high
- relayed_by: 45.79.10.204:8333
- confirmed: 2018-11-23T18:25:35Z
- received: 2018-11-23T18:10:40.724Z
- vout_sz (number of outputs): 85

tx2 sent a new unspent output to the test address.

From tx2, I acquired the following data of this particular unspent output for use as the input in tx3:
- index: 25
- value: 1200000 satoshi (0.012 bitcoin)
- The txid of tx2, which contains this unspent output, is:
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2




6) tx3: I created a transaction on the offline Raspberry Pi that transferred the available bitcoin from the test address to receiving address 2 (on my LocalBitcoins account). I used a transaction-broadcasting service to broadcast it to the Bitcoin network. After a while, tx3 was mined.

txid3:


tx3 (raw byte form):


Key details:
- block_hash:
0000000000000000000ab9373f3ce1c96528c09ffa13fe2005a4d32470b7c98b
- block_height: 552081
- confirmed: 2018-11-30T23:27:35Z
- received: 2018-11-30T18:55:34.661Z
- hash (txid):
00f630f5152f4fce9831933fcd4eb878428308755f9f8e31a3135de6a4754093
- vout_sz (number of outputs): 1






create_nonstandard_transaction.py settings used to create the transactions




tx1 (aka tx1a):






tx1b:






tx1c:






tx3:








Time taken to manually transfer transactions by typing


In this project, I read the transactions on the screen of the offline computer (Raspberry Pi) and manually typed them into text files on the online computer (Aineko). Each transaction was a nonstandard P2SH transaction that contained one standard P2PKH input and one nonstandard P2SH output.

I used a tool to display the transaction hex bytes in a more readable format by inserting whitespace. I found that listening to music made the typing process quite tolerable.

I used a stopwatch to record the time taken for typing each transaction, with one exception (tx1c) where I forgot to do so. This time includes a final double-check of each hex character group on the online computer against the original group displayed on the offline computer's screen.

Times taken (minutes:seconds):
- tx1 (aka tx1a): 13:18
- tx1b: 12:37
- tx1c: Not recorded
- tx3: 10:04

From the recorded times, I see that manually typing out a single-input single-output transaction should take about 15 minutes at most, and about 10 minutes if done quickly.

Let's calculate the overall data transfer rate in bits / second. Don't include tx1c in this calculation.

Transaction sizes according to my work:
- tx1 / tx1a: 225 bytes
- tx1b: 226 bytes
- tx3: 226 bytes

Total data size:
225 + 226 + 226 = 677 bytes = 677*8 bits = 5416 bits

Total time:
(13*60 + 18) + (12*60 + 37) + (10*60 + 4) = 2159 seconds

Overall data transfer rate (bits / second):
5416 bits / 2159 seconds = 5416 / 2159 ~=
2.51 bits / second

At this data transfer rate, how long would it hypothetically take to transfer the code assets over to the Raspberry Pi manually, typing them in rather than using a memory stick?

Make a new test directory. Copy these assets into it:
- bitcoin_functions.py
- bjorn_edstrom_ripemd160.py
- convert_dice_rolls_to_hex_bytes_2.py
- create_nonstandard_transaction.py
- create_transaction.py
- display_hex_bytes.py
- ecdsa-0.10.tar.gz
- generate_bitcoin_address_3.py
- nonstandard_bitcoin_functions.py
- nonstandard_transaction.py
- pypy_sha256.py
- transaction.py

Unpack the zipped tape archive file ecdsa-0.10.tar.gz. In the resulting directory ecdsa-0.10, find the directory "ecdsa" and copy it to the test directory.

Delete:
- ecdsa-0.10.tar.gz
- ecdsa-0.10

Open a terminal and change directory to the test directory.

Find the byte length of all the files in the test directory tree.



23341 + 14429 + 7034 + 13624 + 13000 + 2323 + 644 + 178 + 1640 + 7023 + 24328 + 8609 + 12323 + 16105 + 2794 + 11985 + 28868 + 9263 + 4270 + 2371 + 12817 + 11687 + 19219 =
247875 bytes

Total data:
247875 bytes = 247875 * 8 bits =
1983000 bits

Total time at manual transfer data rate:
1983000 bits / (2.51 bits / second) = 1983000 / 2.51 ~=
790039 seconds ~=
13167 hours ~=
1097 12-hour days ~=
3 years (typing for 12 hours / day)

In practice, typing ASCII code would be significantly faster than typing hex bytes, but this result is a good upper-bound estimate.

Delete the test directory.






Transaction confirmation times


The following times are calculated by subtracting the "received" time from the "confirmed" time as reported by the service live.blockcypher.com. To acquire this information from the service, search for a txid. On the resulting transaction page, click "Advanced Details" then "API Call". On the resulting transaction information page, look for the key names "confirmed" and "received" and record their corresponding values.

Transactions tx0 and tx2 were created by LocalBitcoins, with fees chosen by LocalBitcoins. They are not included here.
Transactions tx1 (aka tx1a) and tx1b were never mined. Transactions tx1c and tx3 were mined.

I assume that "received" time means "the time at which the service first saw the transaction" and that "confirmed" time means "the time at which the transaction was first included in a block".

Transaction details according to the service:
- tx1c: size = 222 bytes, fee = 14586 satoshi
- tx3: size = 222 bytes, fee = 2210 satoshi

Transaction details according to my work:
- tx1c: chosen fee rate = 66 satoshi / byte, estimated size = 221 bytes, size = 226 bytes, fee = 14586 satoshi
- tx3: chosen fee rate = 10 satoshi / byte, estimated size = 221 bytes, size = 226 bytes, fee = 2210 satoshi

Received times:
- tx1c: 2018-11-22T17:46:01.324Z
- tx3: 2018-11-30T18:55:34.661Z

Confirmed times:
- tx1c: 2018-11-22T20:17:05Z
- tx3: 2018-11-30T23:27:35Z

For each transaction, subtract received time from confirmed time to find time taken for confirmation:
- tx1c:
2018-11-22T20:17:05Z - 2018-11-22T17:46:01.324Z =
0 days + (20:17 - 17:46) =
2:31 (hours:minutes)
- tx3:
2018-11-30T23:27:35Z - 2018-11-30T18:55:34.661Z =
0 days + (23:27 - 18:55) =
4:32 (hours:minutes)

Times taken for confirmation (hours:minutes):
- tx1c: 2:31
- tx3: 4:32

Estimated delays according to the service bitcoinfees.earn.com:
- tx1c: 0 blocks (0-35 minutes) for the fee rate of 60 satoshi / byte.
- tx3: 0-7 blocks (0-180 minutes) for the fee rate of 10 satoshi / byte.






Dice rolling results


I found that listening to music made the dice rolling quite tolerable.

Using a set of 5 dice, and rolling them in a tray with raised edges, I generated 5 sets of 212 dice roll results. The files containing these results are included in the Downloadable Assets section.

Table matching sets to filenames:
- Set 1: dice_rolls.txt
- Set 2: dice_rolls2.txt
- Set 3: dice_rolls3.txt
- Set 4: dice_rolls4.txt
- Set 5: dice_rolls5.txt

32 bytes of entropy were derived from each set.

The entropy derived from set 1 was used for the private key of the test address.
The entropy derived from set 2 was used to sign the transaction tx1 (aka tx1a).
The entropy derived from set 3 was used to sign the transaction tx1b.
The entropy derived from set 4 was intended to be used for signing the transaction tx1c. However, I made a mistake and re-used the entropy derived from set 3 to do this.
The entropy derived from set 5 was used to sign the transaction tx3.

I used a stopwatch to record the time taken for each set of 212 results.

Times taken (minutes:seconds):
- Set 1: 10:30
- Set 2: 7:32
- Set 3: 6:33
- Set 4: 5:53
- Set 5: 6:59

Extra entropy generated but not used:
- Set 1: 1 byte
- Set 2: 4 bytes
- Set 3: 1 byte
- Set 4: 1 byte
- Set 5: 5 bytes

From the recorded times, I see that using 5 dice to generate 32 bytes of entropy should take about 10 minutes at most, and about 7 minutes if done quickly.

Let's calculate the overall entropy generation rate in bits / second.

Total entropy bytes: 32*5 + (1+4+1+1+5) = 172 bytes = 172*8 bits = 1376 bits
Total time: (10*60 + 30) + (7*60 + 32) + (6*60 + 33) + (5*60 + 53) + (6*60 + 59) = 2247 seconds

Overall entropy generation rate:
1376 bits / 2247 seconds = 1376 / 2247 ~=
0.61 bits / second






Recording shell output


In a previous project, I learned how to execute a command in the bash shell and simultaneously archive its output in a text file.

The project: Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin

Excerpt:

6) RECORDING SHELL OUTPUT

Use the

tee

command.

Example:

program [arguments...] 2>&1 | tee -a outfile

This should display both output and error messages and append these to a storage file.

The -a option means "append".

2>&1

can be used in Bash to redirect errors/warnings (which are normally sent to stderr) to normal output (stdout). In this case both will be piped to the next command (

tee

).

Note:

tee

doesn't record the command itself, only the output. This can be worked around by echoing the command to the log file before running it. Use the

-e

flag for the

echo

command so that it will interpret backslash-escaped newline characters.

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --version\n" | tee -a work.log

[root@kalkin work]# rpm --version | tee -a work.log

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --help\n" | tee -a work.log

[root@kalkin work]# rpm --help | tee -a work.log

Example of capturing output sent to standard error:

# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test 2>&1 | tee -a work.log

Note: If the command itself includes a newline sequence "\n", the -e flag in the command will cause it to be recorded as an actual newline byte. You will have to edit the log file manually in order to correct this.

Note: Use a text editor to remove any mistaken commands from the log file (as long as they didn't cause irreversible changes of some kind), so that the command can be run again properly.

You can check that the is present by running the command .

I don't usually record the logging commands themselves in a project. I also don't log every command that I use for gathering information (e.g. , ).

While logging an operation, I usually record the commands (although not in complete detail) along with annotations and comments in a separate text file (usually the main project log). When the operation is finished, I copy the resulting log, piece by piece, into the main project log, integrating the annotations and comments as I go.






Miscellaneous




Each new Bitcoin transaction signature requires a new random value. Using the same random value twice in two different ECDSA signatures (that are both broadcast) could compromise the secrecy of the private key.




Keeping the intermediate results e.g. tx_copied.txt during the project meant that if there were an error, I could go back and look for it without having to completely redo each step.




During logging of the commands on the Raspberry Pi, the text "COMMAND#" was generated as a placeholder. Later, I replaced this placeholder with "pi@raspberrypi ~/test $".




On the LocalBitcoins web application, in Wallet / Receive bitcoins / Old addresses, I found this note:

{To protect your privacy, we provide a new bitcoin address for each transfer. This prevents someone from tracking all the payments you receive by looking at the blockchain.

Note that addresses are valid only for 12 months.}

along with a list of old addresses (although only the first 10 characters of each address are shown).




Listening to music made manually copying a transaction a more tolerable experience.




For transferring data to an offline computer, using a memory stick is not the most secure way (various malware items have been able to store themselves on memory sticks). However, for storing bitcoin, using an offline computer and a memory stick is more secure than using an online computer, and security is always relative.

Ideally, the memory stick should only be used once to transfer all the code to the offline computer. Then, the memory stick should be destroyed, and any data produced on the offline computer should be manually copied to an online computer. See this article for an example of how to display data in a more easily-read format: Displaying hex bytes for manual copying
- In the limit case, code should only be moved onto an offline computer by manually typing it all in. This is not always possible within a useful timeframe. In the "Time taken to manually transfer transactions by typing" part of the Notes section, I estimated an upper bound of 3 years to manually copy the code used in this project to the offline computer. Admittedly, manually copying code would be significantly faster than manually copying hex bytes.
- In practice, steadily increasing security, as and when it is reasonable and affordable to do so, is usually the most effective strategy.
- If this project were repeated, without the logging, it would involve only a single data transfer via memory stick (the initial code installation). Input data (txids, output indices, addresses) was copied over to the offline computer or generated on it. All signed transactions were manually copied over to the online computer.




The errors returned by the transaction-broadcasting services when I uploaded a double-spend attempt (tx1b) are shown below. The same errors occurred when I uploaded a replace-by-fee transaction (tx1c). In both situations, the original transaction (tx1a) was still in the memory pools of both services.

live.blockcypher.com/btc/pushtx:
"Server Error (500)"

www.blockchain.com/btc/pushtx:




Transferring values from the online computer to the offline computer:

On the offline computer, edit create_nonstandard_transaction.py using the Nano text editor. Manually enter the gathered / chosen values (reading them from the online computer), except for the variables and .
- Delete the existing value for the variable . Then use the Nano option "Read File" to paste the contents of the file random_value.txt into the position of the value for this variable (i.e. between the quotation marks). Then press the Backspace key to delete the final newline of the file that was also pasted in.
- The variable is a dictionary that contains several other variables. Delete the existing value for the variable . Then use the Nano option "Read File" to paste the contents of the file private_key.txt into the position of the value for this variable (i.e. between the quotation marks). Then press the Backspace key to delete the final newline of the file that was also pasted in.
- Note: With long strings, e.g. the txid, you can make a copy on the online computer and split it into groups of 4 characters, then manually copy each group over to the offline Raspberry Pi, then do a double-check of the group values, and finally delete the spaces again to form the original txid.















Parts


- Definitions and prices
- Cost of storing a larger amount of bitcoin in the test address
- Cost of testing the test address
- Total cost of the project




Definitions and prices


1 satoshi = 0.00000001 bitcoin (10^(-8) bitcoin)

USD = United States Dollars ($)

BTC = bitcoin

LocalBitcoins fees:
- Current deposit fee for incoming transactions: 0.00015 BTC
- Current transaction fee (deducted from the LocalBitcoins wallet balance, not from the transaction amount): 0.00005 BTC




Cost of testing the test address


In order to validate the test address, I needed to transfer a small amount of bitcoin in and out of it. I would need this amount to be at least:
(Bitcoin network transaction fee) + (LocalBitcoins deposit fee)

The Bitcoin network transaction fee was needed in order to pay for the second transaction (that will later transfer bitcoin out of the test address).

To calculate the Bitcoin network transaction fee, I used a service to look at current fee rates for Bitcoin transactions, and chose a reasonably high fee rate:
60 satoshi / byte

I estimated that a nonstandard transaction with one P2PKH input and one P2SH output should be approximately 221 bytes. The estimated fee (using the chosen fee rate) would therefore be:
221 bytes * 60 satoshi / byte = 221 * 60 =
13260 satoshi (0.00013260 BTC)

I therefore needed to transfer at least this much to the test address:
(Bitcoin network transaction fee) + (LocalBitcoins deposit fee)
= 0.00013260 + 0.00015
= 0.00028260 BTC

Then-current USD / BTC exchange rate:
$4904.99 / BTC

(4904.99 USD / BTC) * 0.00028260 BTC = 4904.99 * 0.00028260 ~=
$1.39

I decided to transfer approximately $10 worth of bitcoin to the test address, so as to have room to manoeuvre. If the second transaction were not mined, I would need to increase the fee, and upload a new version for broadcasting.

$10 * (1 BTC / 4904.99 USD) = 10 * 1 / 4904.99 ~=
0.00203874 BTC

I transferred 0.0020 bitcoin (~$9.80) from my LocalBitcoins account into the test address. LocalBitcoins created transaction tx0, which included this transfer.
- LocalBitcoins charged a transaction fee of 0.00005 (deducted from my wallet balance, not from the transaction amount).

I created transaction tx1a and tx1b, which were not mined, so no bitcoin was spent on them.

I created transaction tx1c, which transferred 185414 satoshi from the test address to my LocalBitcoins account.
- It included a Bitcoin network transaction fee of 14586 satoshi.
- LocalBitcoins charged a deposit fee of 0.00015 BTC.

Costs of this test:
- LocalBitcoins transaction fee: 0.00005000 bitcoin
- Bitcoin network transaction fee: 14586 satoshi (0.00014586 bitcoin)
- LocalBitcoins deposit fee: 0.00015000 bitcoin

Total cost in bitcoin:
(LocalBitcoins transaction fee) + (Bitcoin network transaction fee) + (LocalBitcoins deposit fee) =
0.00005000 + 0.00014586 + 0.00015000 =
0.00034586 bitcoin

Total cost (USD):
0.00034586 bitcoin * (4904.99 USD / BTC) =
0.00034586 * (4904.99) ~=
$1.70




Cost of storing a larger amount of bitcoin in the test address


I decided to transfer ~$50 worth of bitcoin to the test address.

Then-current USD / BTC exchange rate:
$4212 / BTC

$50 * (1 BTC / 4212 USD) = 50 * 1 / 4212 ~= 0.01187084 ~=
0.0120 bitcoin

I transferred 0.0120 bitcoin (~$50) from my LocalBitcoins account into the test address. LocalBitcoins created transaction tx2, which included this transfer.
- LocalBitcoins charged a transaction fee of 0.00005 (deducted from my wallet balance, not from the transaction amount).

I created transaction tx3, which transferred 0.01182790 bitcoin from the test address to my LocalBitcoins account.
- It included a Bitcoin network transaction fee of 2210 satoshi.
- LocalBitcoins charged a deposit fee of 0.00015 BTC.

Costs:
- LocalBitcoins transaction fee: 0.00005000 bitcoin
- Bitcoin network transaction fee: 2210 satoshi (0.00002210 bitcoin)
- LocalBitcoins deposit fee: 0.00015000 bitcoin

Total cost in bitcoin:
(LocalBitcoins transaction fee) + (Bitcoin network transaction fee) + (LocalBitcoins deposit fee) =
0.00005000 + 0.00002210 + 0.00015000 =
0.00022210 bitcoin

Total cost (USD):
0.00022210 bitcoin * (4212 USD / BTC) =
0.00022210 * (4212) ~=
$0.94




Overall cost of the project


Overall cost in bitcoin:
(Cost of testing the test address) + (Cost of storing a larger amount of bitcoin in the test address) =
0.00034586 bitcoin + 0.00022210 bitcoin = 0.00034586 + 0.00022210 =
0.00056796 bitcoin

Overall cost (USD):
(Cost of testing the test address) + (Cost of storing a larger amount of bitcoin in the test address) =
$1.70 + $0.94 = 1.70 + 0.94 =
$2.64

Note the use of the relevant then-current exchange rates for each subsection of the project.













I would like to be able to transfer only a portion of the bitcoin (rather than an whole unspent output) in an offline address to another address. In order to do this, I need to be able to create transactions with two outputs - I could then set a default change output (whose destination would be the original offline address), and send only a portion of the bitcoin to the other output. This requires expansion of the existing code and careful testing.


During this project, transaction sizes (in bytes) differed slightly depending on the source.
- I estimated that a nonstandard transaction with one P2PKH input and one P2SH output should be approximately 221 bytes. All transactions that I created in this project were of this type (tx1, tx1b, tx1c, tx3).
- According to my tests after creating the transactions, they were:
-- tx1 / tx1a: 225 bytes
-- tx1b: 226 bytes
-- tx1c: 226 bytes
-- tx3: 226 bytes
- Transaction sizes according to the service live.blockcypher.com:
-- tx1 / tx1a: 221 bytes
-- tx1b: 222 bytes
-- tx1c: 222 bytes
-- tx3: 222 bytes
Investigate why these discrepancies exist, giving priority to how the estimated size is calculated. I derived the current estimate by adding up the sizes of the transaction component parts while developing the code for creating transactions.























My work computer: Aineko, a 2008 Macbook running Mac OS X 10.6.8 Snow Leopard.




I have a Raspberry Pi in my equipment stores. There is some white text on its surface, which states that it is a Model B+ V1.2 and is copyright Raspberry Pi 2014.

I have used this Raspberry Pi in other projects, and it has been connected to the Internet before, so I would not use it to store bitcoin permanently. I can still use it for a test project, though.

It has various ports, including 4 USB ports (which allows simultaneous use of a mouse, a keyboard, and a memory stick) and an HDMI port.

From previous experience, I recall that it does not have an onboard WiFi chip (instead, various suppliers sell add-on USB-connected WiFi chips that can be plugged into it).

I have various peripherals for the Raspberry Pi. These are: An 8GB micro SD card with an installed operating system, a Raspberry Pi power cable, a screen with a DVI port, a screen power cable, a DVI male-male connector cable, a DVI female to HDMI male converter, a USB keyboard, a USB mouse, and a plastic case customised for the Raspberry Pi Model B+.

Future: When I have booted up the Raspberry Pi, check which operating system is installed (I installed it a long time ago and don't recall which OS it was).

I also have a memory stick, which I will use to transfer code to the Raspberry Pi. Using a memory stick is not the most secure way to do this (various malware items have been able to store themselves on memory sticks). However, for storing bitcoin, using an offline computer and a memory stick is more secure than using an online computer, and security is always relative.

Notes:
- Ideally, the memory stick should only be used once to transfer all the code to the offline computer. Then, the memory stick should be destroyed, and any data produced on the offline computer should be manually copied to an online computer. See this article for an example of how to do this: Displaying hex bytes for manual copying
- In the limit case, code should only be moved onto an offline computer by manually typing it all in.
- In practice, steadily increasing security, as and when it is reasonable and affordable to do so, is usually the most effective strategy.


Create a project directory:
storing_bitcoin_on_an_offline_raspberry_pi

In the project directory, create a work directory:
work


Plan of action:
- Download necessary code from previous articles.
- Create a private key. Store it on the Raspberry Pi. This will require generating entropy.
- Generate a Bitcoin address from the private key.
- Test this address by transferring some bitcoin into and out of it.
- Store a larger amount of bitcoin in the address.
- The private key will of course be revealed in the article describing this project, so this bitcoin won't be stored permanently in this address. Instead, I'll transfer the bitcoin out again. To store some bitcoin, a reader can follow all the steps apart from this one.


Hm. The articles that I will need to use are:

- Recipe for generating entropy bytes using dice
- Recipe for generating a Bitcoin address
- Recipe for creating and signing a standard Bitcoin transaction
- Recipe for creating and signing a nonstandard Bitcoin transaction
- Displaying hex bytes for manual copying


Ok. Next, I will download all the assets linked from these articles. Browse to each article and download all linked assets.

Note: Some assets are linked from more than one of these articles.


List of downloaded assets:

- bitcoin_functions.py
- bjorn_edstrom_ripemd160.py
- convert_dice_rolls_to_hex_bytes_2.py
- create_nonstandard_transaction.py
- create_transaction.py
- display_hex_bytes.py
- ecdsa-0.10.tar.gz
- generate_bitcoin_address_3.py
- nonstandard_bitcoin_functions.py
- nonstandard_transaction.py
- pypy_sha256.py
- transaction.py


Move these assets into the work directory.


The work directory contains only these assets. Mac Finder / Get Info reports:
197 KB on disk (169,268 bytes) for 12 items



Future: I remember that Python is installed on the Raspberry Pi. Which version(s) are installed?



I have a USB memory stick (8 GB, FAT32 format, name = "NO NAME"). Insert it into Aineko. It mounts automatically and an icon appears on the Desktop.

Copy work directory to memory stick. Right-click Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.


Connect the mouse, keyboard, and screen to the Raspberry Pi. The mouse is for opening a terminal emulator program if the Raspberry Pi boots directly into a graphical user interface.

Insert the power cable into the Raspberry Pi. It boots up.


Result:




Enter default credentials:





The password was "raspberry" but this was not echoed to the screen.


Ah. Note: The installed OS is Debian GNU/Linux. It's probably Raspbian.


In a previous project, I learned how to execute a command in the bash shell and simultaneously archive its output in a text file.

The project: Offline installation of a C compiler on Centos 6.9 Minimal on Kalkin

Excerpt:

6) RECORDING SHELL OUTPUT

Use the

tee

command.

Example:

program [arguments...] 2>&1 | tee -a outfile

This should display both output and error messages and append these to a storage file.

The -a option means "append".

2>&1

can be used in Bash to redirect errors/warnings (which are normally sent to stderr) to normal output (stdout). In this case both will be piped to the next command (

tee

).

Note:

tee

doesn't record the command itself, only the output. This can be worked around by echoing the command to the log file before running it. Use the

-e

flag for the

echo

command so that it will interpret backslash-escaped newline characters.

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --version\n" | tee -a work.log

[root@kalkin work]# rpm --version | tee -a work.log

[root@kalkin work]# echo -e "\n\nCOMMAND# rpm --help\n" | tee -a work.log

[root@kalkin work]# rpm --help | tee -a work.log

Example of capturing output sent to standard error:

# rpm --install rpms/cloog-ppl-0.15.7-1.2.el6.x86_64.rpm --test 2>&1 | tee -a work.log

Running the command on the Raspberry Pi shows me that it is present.

I will use the approaches shown in the excerpt to log the work done on the Raspberry Pi. I won't record the logging commands themselves in this project. Some commands for gathering information (e.g. , ) may not be logged.



Ok. Next: Insert the memory stick into the Raspberry Pi and mount it.


I did this before in the project How I bought and stored some bitcoin [paywalled].

Excerpt:

Steps for manually mounting a flash drive on a Raspberry Pi:

Insert the USB flash drive into a USB port on the Raspberry Pi.

Note: If the Raspberry Pi automatically started the graphical user interface, then open the program LXTerminal, which is a terminal emulator. It can be accessed from the Desktop via Menu / Accessories / Terminal. On my Raspbian system I have LXTerminal version 0.1.11.

In the terminal, enter the following commands, which are prefixed with a dollar sign and a space ($ ). Do not include this prefix when typing a command into the terminal.

Make a new directory on the graphical desktop to hold the contents of the flash drive:
$ mkdir /home/pi/Desktop/flash_drive_contents

Make a new directory to be the mount point for the flash drive:
$ sudo mkdir /mnt/flash_drive_mount_point

Mount the flash drive:
$ sudo mount -o uid=pi,gid=pi /dev/sda1 /mnt/flash_drive_mount_point

Note that:

-o (lowercase letter "o", not the number zero) specifies that an option string follows.

uid=pi,gid=pi specifies that the user ID is "pi" and the group ID is "pi" (note there are no spaces allowed between these two terms).

/dev/sda1 is the first partition on the first USB drive that the Raspberry Pi can detect.

Copy the contents of the flash drive to the flash_drive_contents directory on the Desktop:
$ cp -r /mnt/flash_drive_mount_point/* /home/pi/Desktop/flash_drive_contents

Unmount the flash drive:
$ sudo umount /mnt/flash_drive_mount_point

The flash drive can now be unplugged.

Ok. Move to the Raspberry Pi. Insert the memory stick.





Now log the work and copy it here. Logged commands are run in the directory.

While logging, record any annotations or comments here and integrate them into the log when the log has been transferred back from the Raspberry Pi to Aineko (where this article is being written).








Ok. Now copy work.log to the memory stick, then dismount the memory stick.




Unplug the memory stick from the Raspberry Pi.



Insert it into Aineko. It mounts automatically and an icon appears on the Desktop. Open the file work.log and copy its contents into this article (above this point). Merge any annotations and comments into this log, marking them with square brackets.



Done.




So: I have generated this address on an offline computer:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK

I'll call it the "test address".



On Aineko, right-click memory stick's Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.




Next: Transfer some bitcoin to this address. Later, transfer it out. This will confirm that the address has been correctly derived from the private key.





First: Calculate how much bitcoin to send to the test address.

LocalBitcoins:
- Current deposit fee for incoming transactions: 0.00015 BTC
- Current transaction fee: 0.00005 BTC

Browse to:
bitcoinfees.earn.com

The fee rates are displayed in satoshi per byte of transaction data. A satoshi is 0.00000001 bitcoin.

Choose a high fee in order to have slack available. I'll attempt to use a low fee in the actual transaction.

A nonstandard transaction with one P2PKH input and one P2SH output should be approximately 221 bytes.

The fee rate range 1-2 satoshi / byte includes many transactions waiting for confirmation. Estimated delay = 3-66 blocks (35-840 minutes).

A fee rate of 60 satoshi / byte looks quite high. Estimated delay = 0 blocks (0-35 minutes).

I estimate that a fairly high fee will therefore be 221 bytes * 60 satoshi / byte = 221 * 60 = 13260 satoshi.

13260 satoshi * 1 BTC / 10^8 satoshi = 0.00013260 BTC


So, expected costs:
- LocalBitcoins transaction fee = 0.00005 BTC. This will be deducted from my LocalBitcoins wallet balance, not from the transction amount.
- Bitcoin network transaction fee (high-end) = 0.00013260 BTC.
- LocalBitcoins deposit fee = 0.00015 BTC.

I need to transfer at least this much to the test address:
(Bitcoin network transaction fee) + (LocalBitcoins deposit fee)
= 0.00013260 + 0.00015
= 0.00028260 BTC

This amount will need to cover the transaction costs of the second transaction (that will later transfer bitcoin out of the test address).


Current USD / BTC price:
$4904.99

(4904.99 USD / BTC) * 0.00028260 BTC = 4904.99 * 0.00028260 ~= $1.39



The number of transactions shown waiting for confirmation, especially at the lower fee ranges, is larger than I've usually seen.


I'll transfer $10-worth of bitcoin to the test address, so as to have room to manoeuvre. If the first version of the transaction is not mined, I will need to increase the fee, and upload a new version for broadcasting.


$10 * (1 BTC / 4904.99 USD) = 10 * 1 / 4904.99 ~= 0.00203874 BTC

I'll transfer 0.0020 bitcoin (~$9.8) into the test address.




Ok. Next:
Log in to LocalBitcoins. Transfer 0.0020 bitcoin to the test address:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK


Go to LocalBitcoins / Wallet / Transactions.

The transaction is listed. Message = "Pending send [etc]"


Wait for a while.


I'll call this transction "tx0" in this project.


Refresh the page.

In the latest entry (for the address
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK ),
the txid is shown:



Browse to:
live.blockcypher.com

Search for this txid.

Transaction page loads:
live.blockcypher.com/btc/tx/07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd

Confirmations: 3/6

Set timer for 40 minutes.

Timer has ended.
Refresh page.
Confirmations: 6+




Click "Advanced Details". Click "API Call".

Result: tx0




Key details:
- block_hash:
0000000000000000001b43b8af8973377619def5043634e9cb2d7dd584d973be
- block_height: 550741
- confirmed: 2018-11-19T19:46:37Z
- received: 2018-11-19T19:46:37Z
- txid:
07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd
- vout_sz (number of outputs): 32


Shutting down for the day.

On the Raspberry Pi:




To boot the Raspberry Pi up again, unplug the power cable and plug it in again.




Start work again.




Next: Create a transaction that moves the available bitcoin out of the test address. I'll call this "tx1".


I'll transfer it back to my LocalBitcoins account, which will have a nonstandard P2SH address. I will therefore follow this article:
Recipe for creating and signing a nonstandard Bitcoin transaction


Note: If I had decided to transfer the bitcoin to a standard P2PKH address, I would have followed this article:
Recipe for creating and signing a standard Bitcoin transaction



Several points concerning Bitcoin transactions:
- New transactions spend unspent-outputs-of-previous-transactions.
- The bitcoin balance of an address is the sum of the unspent outputs sent by previous transactions to this address.
- To spend bitcoin from an address, the bitcoin amount must be constructed from complete unspent outputs. Any change can be sent in a new unspent output back to the original address or another that you control. Unspent outputs cannot be broken into smaller unspent outputs prior to spending - new unspent outputs (larger or smaller) must be created by a new transaction.




The recipe requires me to gather certain pieces of information.

Let's proceed.


- The txid of the previous transaction (tx0, which transferred the unspent output to the test address) is:
07cedb340f588dec2fb14472178a92d5803c70d8d90fc0d8593b03f34035e2cd

- The index of this unspent output in the previous transaction (the "previous_output_index"):
15

[I found the previous_output_index by searching the raw form of tx0 (included earlier in this article) for the test address, temporarily marking the output that contained it, then counting manually (starting from 0) from the first output until I reached the output containing the test address.]

- The private key (in hex bytes) of the test address is:
c592e1dad5e9871fdeffb551b4544b0a1cf0378c6371d7a397ff5faf04c934ca

Note: This is stored on the Raspberry Pi in the file private_key.txt.

- The "input amount" == The bitcoin amount (or satoshi amount) contained within the unspent output:
0.002 bitcoin

- I need a 32-byte random value, to be used when signing the transaction tx1 with the input (each input must sign the transaction).
-- Hm. I'll leave this for now. I will generate 32 bytes of entropy later, when I'm working again on the Raspberry Pi.
-- Note: The random value must also be kept secret, and never exist, however temporarily on an online computer.




The recipe requires me to choose certain pieces of information.


- The output address (which must be a nonstandard P2SH address) is:
369Dpo9CrJASneaHLdwWfKym7N84XTUyvH

[This is the current receiving address on my LocalBitcoins account. It starts with the character '3', so I know it's a P2SH address.]


- The "output amount" == The bitcoin amount (or satoshi amount) that I wish to transfer to the output address:
0.002 bitcoin


[Note: This should be equal to the input amount (the code does not have the ability to send change). Any unassigned value will still be sent to the single output address (which in this recipe is the same as the change address).]


- The change address.
369Dpo9CrJASneaHLdwWfKym7N84XTUyvH

[Note: In this recipe, the change address must be the same as the single output address.]


- The fee (in satoshi) or fee_rate (in satoshi / byte):
fee_rate = 1 satoshi / byte


This is the lowest end of the fee ranges I looked at earlier.

If the transaction is not mined within 3 days, I'll increase the fee, re-sign it, and broadcast the new version (which will invalidate the older version, because it will spend the same unspent output).

Note: Each new signature requires a new random value. Using the same random value twice in two different signatures could compromise the secrecy of the private key.



I'll switch to the Raspberry Pi.


When I need the information gathered / chosen above, I'll copy it manually into the Raspberry Pi, reading it from Aineko's screen.



Insert the power cable into the Raspberry Pi.



Enter default credentials:





The password was "raspberry" but this was not echoed to the screen.







I'll begin logging in the new file called "work_log2.txt". Eventually, I'll transfer it via memory stick to Aineko.

Logged commands are run in the directory on the Raspberry Pi.

While logging, record any annotations or comments here and integrate them into the log when the log has been transferred back from the Raspberry Pi to Aineko (where this article is being written).





[Begin logging on Raspberry Pi.]





[End logging on Raspberry Pi.]



Now, on Aineko, create a text file called "tx_copied.txt" in the work directory for this project. Manually type this signed transaction data into tx_copied.txt. Double-check the data.


Time this using a stopwatch.

Time taken: 13:18
Approximately 13 minutes.

Listening to music made this step more tolerable.



Note: Keeping the intermediate results e.g. tx_copied.txt during the project means that if there is an error, I can go back and look for it without having to completely redo each step.


On Aineko, open a terminal and change directory to the work directory.






So, the signed transaction tx1, now transferred to the online computer, is:







Let's see if a blockchain information service can decode this transaction.


Browse to:
live.blockcypher.com/btc/decodetx

Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".

Click "Decode Transaction".

Result:





Looks good. No immediate error reported.


Hm. Its size is reported as 221 bytes.

Earlier, I measured the length of the signed tx hex string as 450. At 2 hex characters per byte, that's 225 bytes. Hm.


Let's check that again.



225 again.

I wonder if the blockchain information service is reformatting some part of the transaction, in a way that miners currently accept.



Let's broadcast the signed transaction.




Browse to:
live.blockcypher.com/btc/pushtx


Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".


Click "Broadcast Transaction".

Result:
Transaction page loads:
live.blockcypher.com/btc/tx/add54b899f1aba8b6276e42af86c3c03b0120a864451640b4a8d3fec89a4a72d
Details:
- Transaction Successfully Broadcst
- AMOUNT TRANSACTED: 0.00199779 BTC
- FEES: 0.00000221 BTC
- Confirmations: 0/6
- Miner Preference: LOW
- Size: 221 bytes
- Version: 1
- Relayed By: 54.224.143.214




Current datetime: 2018-11-20 17:20





Browse to:
bitcoinfees.earn.com

Hm.

For the fee range 1-2 satoshi / byte, I see that:
- 7292 unconfirmed transactions with a fee in this range have been seen in the memory pool in the last 336 hours.
- 7753 transactions with a fee in this range were mined in the last 24 hours.
-- Note: I think these were mined, although this is not stated explicitly, rather than "seen in the memory pool but never confirmed", because for some fee ranges this number is greater than the number "transactions with a fee in this range seen in the memory pool in the last 336 hours".


336 hours * (1 day / 24 hours) = 336 / 24 = 14 days = 2 weeks.




Shut down for now.

On the Raspberry Pi:



Unplug the power cable from the Raspberry Pi.





Start work again.

Next: Retrieve work_log2.txt from Raspberry Pi and copy it into this article at the appropriate earlier point. Merge various annotations / comments made here into the log.



Insert the power cable into the Raspberry Pi. It boots up.


Enter default credentials.





The password was "raspberry" but this was not echoed to the screen.


Insert the memory stick into the Raspberry Pi.






Unplug the memory stick from the Raspberry Pi.


Insert it into Aineko. It mounts automatically and an icon appears on the Desktop. Open the file work_log2.txt and integrate its contents into this article.


On Aineko, right-click memory stick's Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.




Current datetime:
2018-11-21 13:00

[nearly 20 hours have gone by]


Reload transaction page.
live.blockcypher.com/btc/tx/add54b899f1aba8b6276e42af86c3c03b0120a864451640b4a8d3fec89a4a72d
Details:
- Transaction Successfully Broadcst
- AMOUNT TRANSACTED: 0.00199779 BTC
- FEES: 0.00000221 BTC
- Confirmations: 0/6
- Miner Preference: LOW
- Size: 221 bytes
- Version: 1
- Relayed By: 85.144.83.16:8333






Hm.

Actually, I won't wait for 3 days. Instead, I'll use this as an opportunity to practise creating a new version of a transaction with a higher fee.



The previous article that contains this recipe is:
Creating and signing a standard raw Bitcoin transaction


Excerpt:

Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction

Objectives:
- Fine control of the transaction fee.
- Ability to rebroadcast a new transaction with a higher fee if the previous transaction is not mined within a reasonable time period. This new transaction, if mined, should invalidate the previous transaction.

Note: This recipe is derived from work in this project but has not been tested.

1) Gather the required data for a new transaction (this process is not specified in this recipe). Include at least one "change address" output. Inputs should be added as necessary to achieve the desired output values. The sum of the inputs may be greater than the sum of the desired output values, i.e. some bitcoin may be left over. Send this left-over bitcoin to the change address output. Include an additional input that is specifically for paying the as-yet-unknown transaction fee. Send the bitcoin from this input to the change address output.

2) Construct the transaction, without including signatures (this process is not specified in this recipe).

3) Calculate the byte length of the result of step (2). Let this result be A.

4) Let the estimated byte length of the final transaction be N. Let the approximate byte length of a single input signature be B. Let the number of inputs be C. Calculate N = A + B x C.

5) Using a fee estimation service, look at fee ranges (in satoshis / byte) and the estimated delays for each range. Choose an acceptable delay. Let the corresponding fee (in satoshis / byte) be D. Let the final transaction fee (in satoshis) be E. Calculate E = D x N.

6) Copy the result of step (2). Subtract E from the value in the change address output. The transaction fee is stored implicitly in the transaction as the difference between the sum of the input values and the sum of the output values.

7) Sign the transaction (this process is not specified in this recipe). Insert the input signatures into the transaction.

8) Let the final byte length of the transaction be M. Calculate M by finding the byte length of the result of step (7).

9) Let the final transaction fee (in satoshis / byte) be F. Calculate F = E / M. Confirm that F is within the original desired fee range.

10) Record the time, date, and blockheight. Broadcast the transaction to the Bitcoin network or upload the transaction to a service that can do this for you.

11) A node will store unconfirmed transactions in its memory pools for a particular time period. If the transaction is not mined (confirmed) within this period, the node will delete it from its memory pool. This period will vary depending on the node. Some reading indicates that the default period is 72 hours (three days). After broadcasting the transaction, wait three days + a small delay. If the transaction is mined during this period, stop here. Otherwise, continue to step (12).

12) Using a fee estimation service, look at fee ranges (in satoshis / byte) and the estimated delays for each range. Choose a higher fee range than was used previously.

13) Repeat steps (5)-(12) until the transaction is mined.


Note: If a transaction disappears from the network (i.e. the memory pools of all public nodes), this doesn't mean that it has vanished permanently. Anyone who stored it can rebroadcast it later - it will still be valid. In order to make it invalid, create a new transaction that uses at least one of the same inputs.

Note: An input in a transaction is an as-yet-unspent output of a previous transaction. Each unspent output can only ever be spent once. If a transaction is broadcast that uses at least one input that has already been spent, this transaction is invalid and will not be mined.

Hm. Many of the steps in this recipe are already handled in the existing code.

Rather than increment the fee slowly in order to get the lowest fee that I can, I'll choose a fee rate that's a bit higher than the cheapest 0-block-delay fee rate shown on the fee estimation service.


Browse to:
bitcoinfees.earn.com


This service estimates that a transaction with a fee rate of 59-60 satoshis per byte should be mined with a delay of 0 block (0-40 minutes).

I'll choose a fee rate of 66 satoshis per byte.

I'll use the name "tx1b" for this second version of transaction tx1.



Switch back to the Raspberry Pi. Most of the necessary information for creating the transaction has already been transferred over and entered into the settings for create_nonstandard_transaction.py.


Double-check that my LocalBitcoins receiving address has not changed.
Log in. It's:
36p1w3YrNKd2Q3xaXbe9ASUQkeynjVLfDx

Hm. It's changed.

Ah. The first version of tx1 (let's call it tx1a) is listed in LocalBitcoins / Receive bitcoins / incoming transactions. Therefore, a new address has been generated for receiving bitcoin at this LocalBitcoins account. I had previously thought that the address would change only when a transaction had settled. Evidently the LocalBitcoins receiving address changes when a transaction to that address is seen in their node memory pool(s).

I'll need to use this new receiving address when making tx1b.


Note: Each new signature requires a new random value. Using the same random value twice in two different signatures (that are both broadcast) could compromise the secrecy of the private key. I'll need to generate another 32 bytes of entropy.


I'll begin logging in a new file called "wlog3.txt".







Eventually, I'll transfer it via memory stick to Aineko.

Logged commands are run in the directory on the Raspberry Pi.

While logging, record any annotations or comments here and integrate them into the log when the log has been transferred back from the Raspberry Pi to Aineko (where this article is being written).



[Begin logging on Raspberry Pi.]





[End logging on Raspberry Pi.]




Now, on Aineko, create a text file called "tx1b_copied.txt" in the work directory for this project. Manually type this signed transaction data into tx1b_copied.txt. Double-check the data.


Time this using a stopwatch.

Time taken: 12:37
Approximately 13 minutes.

Listening to music made this step more tolerable.



Note: Keeping the intermediate results e.g. tx1b_copied.txt during the project means that if there is an error, I can go back, find it, and fix it without having to completely redo each step.




On Aineko, open a terminal and change directory to the work directory.





[Recipe complete.]



So, the signed transaction tx1b, now transferred to the online computer, is:







Let's see if a blockchain information service can decode this transaction.


Browse to:
live.blockcypher.com/btc/decodetx

Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".

Click "Decode Transaction".

Result:





Looks good. No immediate error reported.


Hm. Its size is reported as 222 bytes.

Some details:
- fee: 14586 satoshi
- preference: high
- hash (txid):
3677f15c9a6e62a02df0a571370ceb0de9fa90efd56441e3dcb7fe9eff188d16



Let's check the byte length of tx1b using Python.




Hm. 226 bytes.




Anyway, let's press on and broadcast the signed transaction tx1b.




Browse to:
live.blockcypher.com/btc/pushtx


Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".


Click "Broadcast Transaction".


Result:
- "Server Error (500)"


Hm.


Let's look up the txid.


Browse to:
live.blockcypher.com/btc/tx/3677f15c9a6e62a02df0a571370ceb0de9fa90efd56441e3dcb7fe9eff188d16

Result:
"No transaction found with the hash
3677f15c9a6e62a02df0a571370ceb0de9fa90efd56441e3dcb7fe9eff188d16"



Hm.



I'll try another broadcast service.


Browse to:
www.blockchain.com/btc/pushtx

Paste the signed transaction into the text box.

Click "Submit Transaction".


Result:




Ah. Some searching and reading indicates that in order for the second version of the transaction to be mined, the first version must first remain unconfirmed for some time (3 days?) and then be removed from the memory pool.
- Note: My attempting to broadcast tx1b (which spends the same output to a different receiving address) looks exactly like an attempted double-spend.
-- Ah. Should have realised this earlier before I simply changed the output address. I was just thinking about fees, but in retrospect, this is obvious. Bitcoin was designed specifically to reject this second transaction, because it could have been a double-spend attack on a merchant.



Hm. I should try to follow the replace-by-fee approach more exactly (which means: change only the fee, not any of the output addresses).



I can make a new transaction (tx1c) which sends the bitcoin to the first LocalBitcoins receiving address again, but this time with a high fee.

Will LocalBitcoins still credit my account with this bitcoin amount i.e. will it treat this previous receiving address as still belonging to my account (and only my account)?





Log in to LocalBitcoins.

In Wallet / Receive bitcoins / Old addresses, I find:

"To protect your privacy, we provide a new bitcoin address for each transfer. This prevents someone from tracking all the payments you receive by looking at the blockchain.

Note that addresses are valid only for 12 months."

along with a list of old addresses (although only the first 10 characters of each address are shown).



Ok. I can re-use the LocalBitcoins receiving address that I used originally in tx1.



I'll create a new version of the transaction, tx1c, where everything is the same as tx1 except for the fee and the random_value.



Let's try again.


Switch back to the Raspberry Pi.



Original LocalBitcoins receiving address, used in tx1:
369Dpo9CrJASneaHLdwWfKym7N84XTUyvH


Note: Each new signature requires a new random value. Using the same random value twice in two different signatures (that are both broadcast) could compromise the secrecy of the private key. I'll need to generate another 32 bytes of entropy.



I'll begin logging in a new file called "w4.txt".






Eventually, I'll transfer w4.txt to Aineko via memory stick.

Logged commands are run in the directory on the Raspberry Pi.

While logging, record any annotations or comments here and integrate them into the log when the log has been transferred back from the Raspberry Pi to Aineko (where this article is being written).




[Begin logging on Raspberry Pi.]





[End logging on Raspberry Pi.]



Now, on Aineko, create a text file called "tx1c_copied.txt" in the work directory for this project. Manually type the signed transaction data displayed on the Raspberry Pi's screen into tx1c_copied.txt. Double-check the data.


I forgot to time this using a stopwatch.

Listening to music made this step more tolerable.


Note: Keeping the intermediate results e.g. tx1c_copied.txt during the project means that if there is an error, I can go back, find it, and fix it without having to completely redo each step.




On Aineko, open a terminal and change directory to the work directory.





[Recipe complete.]



So, the signed transaction tx1c, now transferred to the online computer Aineko, is:






Let's see if a blockchain information service can decode this transaction.


Browse to:
live.blockcypher.com/btc/decodetx

Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".

Click "Decode Transaction".

Result:






Looks good. No immediate error reported.


Some details:
- size: 222 bytes
- fee: 14586 satoshi
- preference: high
- hash (txid):
8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0




Let's check the byte length of tx1c using Python.




226 bytes.



Let's broadcast the signed transaction tx1c.





Browse to:
live.blockcypher.com/btc/pushtx


Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".


Click "Broadcast Transaction".



Result:
- "Server Error (500)"


Hm.



I'll try another broadcast service.


Browse to:
www.blockchain.com/btc/pushtx

Paste the signed transaction into the text box.

Click "Submit Transaction".


Result:





Hm.


Evidently, these two broadcast-transaction services do not support replace-by-fee transactions.



I'll look up the txid.


Browse to:
live.blockcypher.com/btc/tx/8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0

Result:
"No transaction found with the hash
8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0"






Next: Retrieve wlog3.txt and w4.txt from the Raspberry Pi and copy them into this article at the appropriate earlier points. Merge various annotations / comments made here into these logs.




Insert the memory stick into the Raspberry Pi.








Unplug the memory stick from the Raspberry Pi.




Shut down for now.

On the Raspberry Pi:



Unplug the power cable from the Raspberry Pi.




Insert the memory stick into Aineko. It mounts automatically and an icon appears on the Desktop. Copy the files wlog3.txt and w4.txt to the work directory for this project on Aineko.

On Aineko, right-click memory stick's Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.


Integrate the contents of the files wlog3.txt and w4.txt into this article.


Done.



Hm.



Let "replace-by-fee transaction" mean "a new version of a transaction in which nothing has changed other than an increased transaction fee (which means: a lower value in one or more of the output addresses)"

I have read that (some?) miners run nodes that will accept a replace-by-fee transaction, because it will be more profitable to mine than the transaction that it replaces.

However, in order to get this replace-by-fee transaction (tx1c) to a miner's node, I have two options (are there more?):
a) Run my own node, and continually broadcast to the Bitcoin network the new replace-by-fee version of the transaction. Hopefully, this will propagate through the section of the Bitcoin network that accepts replace-by-fee transactions, until it reaches a mining node.
a1) Know someone personally who runs their own node and accepts replace-by-fee transactions.
b) Wait until the first version of the transaction (tx1 / tx1a) is cleared out of the memory pools of many (all?) of the Bitcoin nodes or until it is actually mined. If it is cleared, and not mined, I can broadcast the new version tx1c. This could take a long time, as nodes can choose to keep the first version in their memory pools (and relay it) as long as they like.
- Note: If tx1 is cleared without being mined, I could also broadcast tx1b, as this would no longer look like an attempted double-spend.

Another option: Search online for services that accept replace-by-fee transactions. This is a version of option a1.



Let's check if tx1 has been mined or cleared.




Refresh transaction page (tx1):
live.blockcypher.com/btc/tx/add54b899f1aba8b6276e42af86c3c03b0120a864451640b4a8d3fec89a4a72d
Result:
"No transaction found with the hash
add54b899f1aba8b6276e42af86c3c03b0120a864451640b4a8d3fec89a4a72d"



Current datetime: 2018-11-22 17:45

[about 48 hours have gone by since original broadcast of tx1]




Refresh transaction page (tx1b):
live.blockcypher.com/btc/tx/3677f15c9a6e62a02df0a571370ceb0de9fa90efd56441e3dcb7fe9eff188d16

Result:
"No transaction found with the hash
3677f15c9a6e62a02df0a571370ceb0de9fa90efd56441e3dcb7fe9eff188d16"




Hm. Interesting. This service does not appear to have either transaction (tx1 or tx1b) in its memory pool.



What about tx1c?



Refresh transaction page (tx1c):
live.blockcypher.com/btc/tx/8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0

Result:
"No transaction found with the hash
8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0"



Ah. I think that:
- this service accepted tx1 for broadcast. tx1 was never mined. eventually it was cleared from the memory pool.
- while tx1 was in the memory pool, this service rejected tx1b (as an attempt double-spend) and tx1c (also as an attempted double-spend, even though it was actually a replace-by-fee).





Log in to LocalBitcoins. It shows a pending transaction (tx1) and no new completed transaction.



Searching for both
LocalBitcoins receiving address 1:
- 369Dpo9CrJASneaHLdwWfKym7N84XTUyvH
and
LocalBitcoins receiving address 2:
- 36p1w3YrNKd2Q3xaXbe9ASUQkeynjVLfDx
on
live.blockcypher.com
produces "No transactions detected" and a balance of 0.0 BTC.



So, I think I can now try to upload tx1c to this service for broadcast. Transaction tx1 is no longer in this service's memory pool, blocking tx1c from being uploaded.



First, check current fees.


Browse to:
bitcoinfees.earn.com

The cheapest 0-block-estimated-delay fee range that I see is 53-54 satoshi / byte.

The fee rate 66 satoshi / byte in transaction tx1c should ensure a relatively quick inclusion into the blockchain.



tx1c:






Browse to:
live.blockcypher.com/btc/pushtx


Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".


Click "Broadcast Transaction".

Result:
Transaction page loads:
live.blockcypher.com/btc/tx/8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0
Details:
- Transaction Successfully Broadcst
- AMOUNT TRANSACTED: 0.00185414 BTC
- FEES: 0.00014586 BTC
- Confirmations: 0/6
- Miner Preference: HIGH
- Size: 222 bytes
- Version: 1
- Relayed By: 54.242.109.171




Current datetime: 2018-11-22 18:00




Hm.



If I search for these txids and addresses on
www.blockchain.com
I find that tx1 is still stored in that service's system (as "unconfirmed"), and tx1b and tx1c are not.


It's possible that the blockcypher service nodes are surrounded in the Bitcoin network by nodes that have stored tx1 and reject replace-by-fee transactions like tx1c. Even though tx1c has been uploaded to a node, I may still have to wait until tx1 has been cleared out of more memory pools. By the time that happens, tx1c may also have been removed from many memory pools, and I may have to upload it for broadcast again.






Current datetime: 2018-11-23 10:40


Refresh transaction page:
live.blockcypher.com/btc/tx/8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0

Confirmations: 6+


Excellent. Transaction tx1c has been mined.


Click Advanced Details.

- Block Hash:
000000000000000000091db255f327f3938cb33cd1076d7554b7bbd22b9c1000
- Block Height: 551,106
- Transaction Index: 668


Click API Call.

Result: tx1c





Key details:
- block_hash:
000000000000000000091db255f327f3938cb33cd1076d7554b7bbd22b9c1000
- block_height: 551106
- confirmed: 2018-11-22T20:17:05Z
- received: 2018-11-22T17:46:01.324Z
- hash (txid):
8b0f7ba372b61b195cd237429c9a5d079aaf9887e72dd094f2fa942a0f7ccfc0


My record of the broadcast time:
2018-11-22 18:00

blockcypher.com's record of the broadcast time:
2018-11-22T17:46

Fairly close.


Using the times from blockcypher.com:
- Broadcast time: 2018-11-22 17:46
- Confirmation time: 2018-11-22 20:17

Time taken ~= 2.5 hours



Log on to LocalBitcoins.
Go to Wallet / Transactions.
- Latest received transaction:
-- Datetime: 11/22/2018 20:31
-- Received BTC: 0.00170414
-- Description: Deposit to 369Dpo......
-- Deposit Fee BTC: 0.00015000



The test address has now been validated. I have moved some bitcoin into it and then successfully retrieved it. This proves that the address was correctly calculated from the private key.



I can now move a large amount of bitcoin into this address and be certain that I can retrieve it. Even if I later construct a new transaction that turns out to be invalid, and discover that the cause was an error in the code stack used to create and sign a transaction, I know that eventually this error could be fixed and a valid transaction could be created. I would only risk a temporary lack of access to the bitcoin stored in this address, not its permanent loss.



So, I'll now test this approach. I'll transfer a larger amount of bitcoin into the test address, store it for a while, and then transfer it back out. This is the process that can be used to securely store bitcoin offline until it is needed.







Log in to LocalBitcoins.


Current exchange rate:
$4212 / 1 BTC


Using my LocalBitcoins account, I'll transfer ~$50 worth of bitcoin to the test address.

$50 * (1 BTC / $4212) = 50 * 1 / 4212 = 0.01187084 ~= 0.012



Test address:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK

I've transferred 0.0120 bitcoin to the test address. LocalBitcoins charged a transaction fee of 0.00005 bitcoin.

Current datetime: 2018-11-23 18:22


Wait 5-10 minutes.


Refresh LocalBitcoins / Wallet / Transactions.

Latest transaction:
- 11/23/2018 18:08
- Sent BTC: 0.012
- Sent to:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK
- txid:
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2



Browse to:
live.blockcypher.com

Search for this txid.

Transaction page loads:
live.blockcypher.com/btc/tx/af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2


Details:
- AMOUNT TRANSACTED: 49.9112634 BTC
- FEES: 0.0015299 BTC
- CONFIRMATIONS: 0/6
- Miner Preference: HIGH
- Size: 2822 bytes
- Version: 2
- Relayed By: 45.79.10.204:8333
- 1 Input Consumed
- 85 Outputs Created


Set timer for 30 minutes.


Timer has finished.


Refresh transaction page.
Confirmation: 1/6


Set timer for 1 hour.


I refreshed the transaction page after 43 minutes.


Confirmations: 6+

Click Advanced Details / API Call.


Result: tx2





Key details:

- block_hash:
0000000000000000001f85686e50bbc4e929b50768669165731e5c73a690f680
- block_height: 551219
- block_index: 502
- hash (txid):
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2
- total: 4991126340
- fees: 152990
- size: 2822
- preference: high
- relayed_by: 45.79.10.204:8333
- confirmed: 2018-11-23T18:25:35Z
- received: 2018-11-23T18:10:40.724Z


Hm. Note this section at the end:


There are 85 outputs. I will eventually need to find the previous_output_index within this transaction. I'll search for the test address in the transaction data included above. If it's there, I don't need to browse to the supplied url to get the remaining outputs.

Yes, it's there.

Copy the transaction data to a new text file. Search for the test address. Select all outputs that come after it in the outputs list and delete them. Each output is contained within pairs of curly braces ('{' and '}'). A readthrough shows me that curly braces are not included within output data. Use the "Find All" feature in my text editor (TextWrangler) to discover that there are 26 total occurrences of '{'. There are therefore 26 outputs. They are zero-indexed, so the previous_output_index of the output sent to my test address in transaction tx2 is 25.

Test address:
1vkb4YyPMFcxyC83Z5m5zuN45xASoHeNK

I'll copy the specific output data here:




Let's summarise:

The index of the output that I will use as an input in tx3 is:
25

The value in this unspent output is:
1200000 satoshi (0.012 bitcoin)

The txid of tx2, which contains this unspent output, is:
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2


These 3 pieces of information, together with the private key of the test address (which is where this output is now stored in the blockchain), allow me to spend this bitcoin in a new transaction.








[nearly a week has passed]


The datetime of confirmation of tx2 was:
2018-11-23T18:25:35Z

Current datetime:
2018-11-30T12:42 UTC




Ok. I've successfully stored the bitcoin on the Raspberry Pi. I'll now demonstrate how to send it back to an exchange (LocalBitcoins).

I'll gather the necessary information for tx3.


My LocalBitcoins account will have a nonstandard P2SH address. I will follow this recipe again:
Recipe for creating and signing a nonstandard Bitcoin transaction



Let's look at fee rates. Browse to:
bitcoinfees.earn.com

I'll choose a fee rate of 10 satoshi / byte. Estimated delay = 0-7 blocks (0-180 minutes).
- This is the lowest fee rate that has an estimated delay starting at 0 blocks. The fee rate of 7-8 satoshi / byte has an estimated delay of 1-8 blocks (0-180 minutes).



Gathered information:

Unspent output:
- index: 25
- value: 1200000 satoshi (0.012 bitcoin)
- The txid of tx2, which contains this unspent output, is:
af3888cc260b6b6bfb8eb256fb70fd1e761a1c7baac0e19cd11b47726f2327d2

- The private key (in hex bytes) of the test address is:
c592e1dad5e9871fdeffb551b4544b0a1cf0378c6371d7a397ff5faf04c934ca
-- Note: This is stored on the Raspberry Pi in the file private_key.txt.



Chosen information:

Log into LocalBitcoins. Current receiving address is:
36p1w3YrNKd2Q3xaXbe9ASUQkeynjVLfDx
- This was the output address in tx1b.
- This will be the output address for tx3. I'll call it "lb_address2" (lb = LocalBitcoins).

- The "output amount" == The bitcoin amount (or satoshi amount) that I wish to transfer to the output address:
1200000 satoshi (0.012 bitcoin)
-- Note: This should be equal to the input amount (the code does not have the ability to send change). Any unassigned value will still be sent to the single output address (which in this recipe is the same as the change address).

- The change address.
36p1w3YrNKd2Q3xaXbe9ASUQkeynjVLfDx
-- Note: In this recipe, the change address must be the same as the single output address.

- The fee (in satoshi) or fee_rate (in satoshi / byte):
fee_rate = 10 satoshi / byte








I'll switch to the Raspberry Pi.


When I need the information gathered / chosen above, I'll copy it manually into the Raspberry Pi, reading it from Aineko's screen.



Insert the power cable into the Raspberry Pi.



Enter default credentials:





The password was "raspberry" but this was not echoed to the screen.






I'll begin logging in the new file called "w5.txt".







Eventually, I'll transfer w5.txt to Aineko via memory stick.

Logged commands are run in the directory on the Raspberry Pi.


While logging, record any annotations or comments here and integrate them into the log when the log has been transferred back from the Raspberry Pi to Aineko (where this article is being written).





[Begin logging on Raspberry Pi.]






[End logging on Raspberry Pi.]



Now, on Aineko, create a text file called "tx3_copied.txt" in the work directory for this project. Manually type the signed transaction data displayed on the Raspberry Pi's screen into tx3_copied.txt. Double-check the data.

Time taken: 10:04
Approximately 10 minutes.


Listening to music made this step more tolerable.


Note: Keeping the intermediate results e.g. tx3_copied.txt during the project means that if there is an error, I can go back, find it, and fix it without having to completely redo each step.




On Aineko, open a terminal and change directory to the work directory.





[Recipe complete.]




So, the signed transaction tx3, now transferred to the online computer Aineko, is:








Let's check the byte length of tx3 using Python.




226 bytes.






Next: Retrieve w5.txt from the Raspberry Pi and copy it into this article at the appropriate earlier point. Merge various annotations / comments made here into this log.





Insert the memory stick into the Raspberry Pi.








Unplug the memory stick from the Raspberry Pi.


Insert the memory stick into Aineko. It mounts automatically and an icon appears on the Desktop. Copy the file w5.txt to the work directory for this project on Aineko.

On Aineko, right-click memory stick's Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.


Integrate the contents of the file w5.txt into the marked section earlier in this article.


Done.




Shut down the Raspberry Pi for now.

On the Raspberry Pi:



Unplug the power cable from the Raspberry Pi.






Switch to Aineko.


Let's see if a blockchain information service can decode this transaction.


Browse to:
live.blockcypher.com/btc/decodetx

Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".

Click "Decode Transaction".

Result:





Looks good. No immediate error reported.


Some details:
- size: 222
- fee: 2210
- preference: low
- hash (txid):
00f630f5152f4fce9831933fcd4eb878428308755f9f8e31a3135de6a4754093






Let's broadcast the signed transaction tx3.


Browse to:
live.blockcypher.com/btc/pushtx


Paste the signed transaction into the text box named "Transaction Hex". Network is set to "Bitcoin".


Click "Broadcast Transaction".


Result:
Transaction page loads:
live.blockcypher.com/btc/tx/00f630f5152f4fce9831933fcd4eb878428308755f9f8e31a3135de6a4754093
Details:
- Transaction Successfully Broadcst
- AMOUNT TRANSACTED: 0.0119779 BTC
- FEES: 0.0000221 BTC
- Confirmations: 0/6
- Miner Preference: LOW
- Size: 222 bytes
- Version: 1
- Relayed By: 54.166.113.205



Current datetime: 2018-11-30 19:10



Set timer for 2 hours.


Timer has finished.



[some additional time passes]



Current datetime: 2018-11-30 21:47



Refresh transaction page.
Confirmations: 0/6



I'll wait until tomorrow to check again.





Current datetime:
2018-12-01 10:56


Refresh transaction page:
live.blockcypher.com/btc/tx/00f630f5152f4fce9831933fcd4eb878428308755f9f8e31a3135de6a4754093

Confirmations: 6+




Excellent. Transaction tx3 has been mined.


Click Advanced Details.

- Block Hash:
0000000000000000000ab9373f3ce1c96528c09ffa13fe2005a4d32470b7c98b
- Block Height: 552,081
- Transaction Index: 1,941


Click API Call.

Result: tx3





Key details:
- block_hash:
0000000000000000000ab9373f3ce1c96528c09ffa13fe2005a4d32470b7c98b
- block_height: 552081
- confirmed: 2018-11-30T23:27:35Z
- received: 2018-11-30T18:55:34.661Z
- hash (txid):
00f630f5152f4fce9831933fcd4eb878428308755f9f8e31a3135de6a4754093




Using the times from blockcypher.com:
- Broadcast time: 2018-11-30 18:55
- Confirmation time: 2018-11-30 23:27

Time taken ~= 4.5 hours




Log on to LocalBitcoins.
Go to Wallet / Transactions.
- Latest received transaction:
-- Datetime: 11/30/2018 23:57
-- Received BTC: 0.0118279
-- Description: Deposit to 36p1w3......
-- Deposit Fee BTC: 0.00015000



I have successfully transferred the relatively larger amount of stored bitcoin from the Raspberry Pi to the LocalBitcoins exchange.



Excellent.



That's the end of the project.



Now, begin writing up the analysis. There may be some clean-up / archival work, which I may document here.




I'll preserve the dice rolling results as assets of this article.

Boot up the Raspberry Pi and transfer the files:
- dice_rolls.txt
- dice_rolls2.txt
- dice_rolls3.txt
- dice_rolls4.txt
- dice_rolls5.txt
to Aineko via memory stick.



I've written recipes:
- Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction
- Recipe For Manually Mounting A USB Memory Stick

Now test them.

Boot up the Raspberry Pi.

In the home directory ("/home/pi"), make a new directory "test2".

Copy the entropy byte files from the "test" directory to the "test2" directory. These are:
- private_key.txt
- random_value2.txt
- random_value3.txt
- random_value4.txt
- random_value.txt

Note that random_value2.txt and random_value3.txt contain the same value. The value in random_value3.txt should have been derived from dice_rolls4.txt, but was accidentally derived from dice_rolls3.txt instead.

random_value.txt was used to sign tx1a.
random_value2.txt was used to sign tx1b.
random_value3.txt was used to sign tx1c.
random_value4.txt was used to sign tx3.

Copy the signed transaction files to the test2 directory as well.



Delete the "test" directory, which contains almost everything on the Raspberry Pi that I used during this project. I used the command to do this.

In the home directory, also delete:
- w4.txt
- w5.txt
- wlog3.txt
These were temporary backup files.


Change directory to the test2 directory.

Rename:
- signed_transaction.txt to tx1a_original.txt
- signed_transaction2.txt to tx1b_original.txt
- signed_transaction3.txt to tx1c_original.txt
- signed_transaction4.txt to tx3_original.txt


Delete the directory . It was created with root permissions, so root permissions are required to delete it. Use the command .



First, I will test:
Recipe For Manually Mounting A USB Memory Stick
because I'll also use it to transfer the code assets to the Raspberry Pi, in preparation for testing the other recipe.


Insert the memory stick into Aineko. It mounts automatically and an icon appears on the Desktop. Delete everything on it.

Make a new directory named "code_assets" on the memory stick. From the work directory in the project directory on Aineko, copy the code assets into the code_assets directory.

On Aineko, right-click memory stick's Desktop icon and choose Eject "NO NAME". Unplug the memory stick from Aineko.

Follow the recipe as closely as possible. Make a new directory named "memory_stick_contents" in the test2 directory on the Raspberry Pi. Copy the contents of the code_assets directory on the memory stick to the memory_stick_contents directory on the Raspberry Pi.

Note: This time, there's no "work.log" file to copy to the memory stick. Test this recipe section by copying private_key.txt to the memory stick, and then delete it from the memory stick.

Recipe completed. Works fine.



Next, I will test:
Recipe For Managing The Fee And Broadcast Of A Bitcoin Transaction

I won't test it completely. At the appropriate points, I'll assume that the events (e.g. transaction confirmation) occur as they did during the project.

Copy the files in the memory_stick_contents directory to the parent test2 directory. The command I used was:

Unpack the zipped tape archive file ecdsa-0.10.tar.gz, then copy the "ecdsa" directory into the test2 directory.


At this point, I assume that I have gathered the required data for a new transaction (step 1), and that I have looked at current Bitcoin network transaction fee rates and chosen a fee rate for the transaction (step 2). Actually, I'm re-using the values used for tx1a. The fee rate is 1 satoshi / byte.


Edit create_nonstandard_transaction.py using the Nano text editor so that its settings section (lines 40-66) are the settings originally used to create tx1a. Manually enter the gathered / chosen values (reading them from the main project log (this text file) displayed on Aineko's screen), except for the variables and .
- Delete the existing value for the variable . Then use the Nano option "Read File" to paste the contents of the file random_value.txt into the position of the value for this variable (i.e. between the quotation marks). Then press the Backspace key to delete the final newline of the file that was also pasted in.
- The variable is a dictionary that contains several other variables. Delete the existing value for the variable . Then use the Nano option "Read File" to paste the contents of the file private_key.txt into the position of the value for this variable (i.e. between the quotation marks). Then press the Backspace key to delete the final newline of the file that was also pasted in.
- Note: With long strings, e.g. the txid, you can make a copy on the online computer (Aineko, in this case) and split it into groups of 4 characters, then manually copy each group over to the offline Raspberry Pi, then do a double-check of the group values, and finally delete the spaces again to form the original txid.


tx1a settings:





I used this command to direct the output of the transaction creation into a file:


Then I used the Nano text editor to delete most of the contents of tx1a, leaving only the final signed form of the transaction.

This completes step 3 of the recipe.


The command produced no output, confirming that the two files are identical.


At this point, I assume that I have broadcast transaction tx1a (step 4), that 2 days have passed, that it has not been mined, and that it has now been removed from the memory pool of the node run by the broadcast service (step 5).

I also assume that I have looked at current Bitcoin network transaction fee rates and chosen a new and higher fee rate for the transaction (step 6). Actually, I'm re-using the values used for tx1c. The fee rate is 66 satoshi / byte.

Note: I'm not re-constructing tx1b, as it was a double-spend attempt (it tried to spend the same unspent output as tx1a did, but to a different address, while tx1a was still in the memory pool), and it is not relevant to testing this recipe.




Edit create_nonstandard_transaction.py using the Nano text editor so that its settings section (lines 40-66) are the settings originally used to create tx1c. Manually enter the gathered / chosen values (reading them from the main project log (this text file) displayed on Aineko's screen), except for the variable .
- Delete the existing value for the variable . Then use the Nano option "Read File" to paste the contents of the file random_value3.txt (used to sign the original tx1c) into the position of the value for this variable (i.e. between the quotation marks). Then press the Backspace key to delete the final newline of the file that was also pasted in.
- The details of the input that I am trying to spend do not need to be changed. This refers to every subvariable contained in the dictionary variable .
- The output address and the change address do not need to be changed. I am trying to send the available bitcoin to the same output address.
- I only need to change the fee_rate and the random_value.



tx1c settings:






I used this command to direct the output of the transaction creation into a file:


Then I used the Nano text editor to delete most of the contents of tx1c, leaving only the final signed form of the transaction.

This completes another iteration of steps 2-3 of the recipe.


The command produced no output, confirming that the two files are identical.


At this point, I assume that I have broadcast transaction tx1c, that it has been mined within 5 hours, and that it is now 6 blocks deep in the Bitcoin blockchain, i.e. the same events have happened as those that occurred during this project, and I have had a successful result.


Ok. I'll count that as a successful test of the recipe.


Shut down the Raspberry Pi.


I've finished writing the analysis (various sections, notes, summary). Boot up the Raspberry Pi, delete the test2 directory, and shut it down again. Insert the memory stick into Aineko and delete the work directory on it.



















Changes from the original text:

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