Generate a Bitcoin address and use a small transaction to validate it.









- Goal
- Contents
- Brief Summary
- Summary
- Downloadable Assets
- Notes
- Thoughts
- Project Log









During this project, I validated an address by transferring some bitcoin into and out of it. I could have then moved a larger amount of bitcoin into this address and be certain that I could later retrieve it.

I used an exchange service to transfer bitcoin into the address. I constructed and signed a raw Bitcoin transaction in order to transfer the bitcoin out of this address.

Please read the Summary section for a more thorough description of this project.











Original plan of action for this project:


- Generate an address: the "test address".

- Transfer some bitcoin to the test address. I'll call this "tx0". "tx" = transaction.

- Construct and sign a transaction that transfers bitcoin out of the test address to another "final" address. I'll call this "tx1".

- Broadcast the transaction. If the transaction is mined, then the address has been validated.




What I actually did during the project:


- Created a project directory:
using_a_transaction_to_validate_a_bitcoin_address

- Decided to use my current LocalBitcoins receiving address as the final address. It was a P2SH address (i.e. nonstandard), so creating transaction tx1 would require the create_nonstandard_transaction toolset.

- Within the project directory, created a work directory named "work".

- Obtained 5 dice and a tray with raised edges in which to roll them.

- Browsed to the previous article Generating entropy with dice and downloaded the following asset:
-- convert_dice_rolls_to_hex_bytes.py

- Browsed to the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2 and downloaded the following assets:
-- bjorn_edstrom_ripemd160.py
-- ecdsa-0.10.tar.gz
-- pypy_sha256.py
-- bitcoin_functions.py
-- generate_bitcoin_address_3.py
-- transaction.py
-- nonstandard_bitcoin_functions.py
-- nonstandard_transaction.py
-- create_nonstandard_transaction.py

- Moved these downloaded files to the work directory.

- Reading the relevant recipes in the articles containing these assets, I noted that I would need 64 bytes of entropy.

- In order to generate this entropy, I used the dice and tray acquired earlier and proceeded through the section Recipe For Generating Entropy Bytes Using Dice in the previous article Generating entropy with dice. This recipe is included as an excerpt at the relevant point in the Project Log section.

- I fixed some problems in the asset
convert_dice_rolls_to_hex_bytes.py,
creating the asset
convert_dice_rolls_to_hex_bytes_2.py. This new asset can be found in the Downloadable Assets section.

- I used Python to split the generated entropy into two sections of 32 bytes each. Details can be found in the "Using Python slicing to divide entropy bytes into pieces with particular lengths" part of the Notes section.

- I proceeded through Recipe 1 (Setup) in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. This recipe is included as an excerpt at the relevant point in the Project Log section.

- I generated the test address by proceeding through Recipe 2 (generate_bitcoin_address_3.py) in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. This recipe is included as an excerpt at the relevant point in the Project Log section.

- I calculated an amount of bitcoin to transfer to the test address that would cover expected costs, with extra so as to have room to manoeuvre.

- I used LocalBitcoins to transfer this amount of bitcoin to the test address. This was tx0.

- I constructed and signed a nonstandard transaction (tx1) that transferred the available bitcoin (minus a transaction fee) from the test address to the final address. I did this by proceeding through Recipe 4 (create_nonstandard_transaction.py), in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. This recipe is included as an excerpt at the relevant point in the Project Log section.

- I used a service to decode the transaction, indicating that the transaction was formatted correctly.

- I used a service to broadcast the transaction. Time taken for mining + 6-block-deep confirmation ~= 12.5 hours.




Overall results:


- The test address was successfully validated. I moved some bitcoin into it and successfully retrieved it. I could have then moved a larger amount of bitcoin into this address and be certain that I could later retrieve it.




Notes section:


The Notes section contains the following parts:

- Definitions and acryonyms
- Services used during this project
- Using Python slicing to divide entropy bytes into pieces with particular lengths
- Addresses generated and/or used in this project
- Transactions created during this project
- Dice rolling results
- Financial information for this project




Thoughts section:


The Thoughts section contains the following parts:

- Validating a Bitcoin address
- Does the hash in a Bitcoin address provide any protection?
- What is the chance of two people independently generating the same Bitcoin address?









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




The following asset was developed during this project and was run using Python 2.7.13 on Aineko.

Description: A script that converts dice roll results into bytes.
convert_dice_rolls_to_hex_bytes_2.py
This is a new version of convert_dice_rolls_to_hex_bytes.py, an asset of the previous article Generating entropy with dice.
Changes:
- Changed two hardcoded values to be the correct variable.
- Added a check that removes an extra hex character (half-byte) if it exists.
Note: During this project, this file was called
"convert_dice_rolls_to_hex_bytes.py".


Description: A set of 423 dice roll results produced during this project.
dice_rolls_2.txt
Note: During this project, this file was called "dice_rolls.txt".











Parts:


- Definitions and acryonyms
- Services used during this project
- Using Python slicing to divide entropy bytes into pieces with particular lengths
- Addresses generated and/or used in this project
- Transactions created during this project
- Dice rolling results
- Financial information for this project




Definitions and acryonyms


P2PKH = Pay-To-Public-Key-Hash

P2SH = Pay-To-Script-Hash

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

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


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 it to the test address, and receive it 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.
live.blockcypher.com/btc/tx/bf7a16ef4bf8763b7bf7f02b03155c9a2f9b997d19e64a770bf3f7d3f24cc48b
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/bf7a16ef4bf8763b7bf7f02b03155c9a2f9b997d19e64a770bf3f7d3f24cc48b?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.




Using Python slicing to divide entropy bytes into pieces with particular lengths


64 bytes of entropy:



I want to divide this entropy into two pieces, each of 32 bytes. Note that 2 hex characters represent 1 byte, so 64 hex characters comprise 32 bytes.





Entropy-bytes-1:


Entropy-bytes-2:





Addresses generated and/or used in this project


I generated one address, the "test address".


Test address:
- Private key (hex bytes):
a26e15954d2dafcee70eeaaa084eab8a4c1a30b0f71a42be4d8da20123bff121
- Bitcoin address:
1AGygbyEFYduWkkmZbbvirgS9kuBBMLJCP


Final address (My then-current LocalBitcoins receiving address):
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti




Transactions created during this project


I'll use:
- txid0 to mean the txid (transaction id) of tx0
- txid1 to mean the txid of tx1




tx0:

I transferred some bitcoin from my LocalBitcoins account to the test address. LocalBitcoins created a larger transaction, which included many other transfers, that executed this transfer.

txid0:


Link:
live.blockcypher.com/btc/tx/bf7a16ef4bf8763b7bf7f02b03155c9a2f9b997d19e64a770bf3f7d3f24cc48b

Additional details:
- block_hash:
00000000000000000001d5c84216c226186288fad3bedb057a25b393f44cae0d
- block_height:
547832
- confirmed:
2018-10-29T12:26:02Z




tx1:

tx1 transferred the available bitcoin (minus a transaction fee) from the test address to the final address.

txid1:


Link:
live.blockcypher.com/btc/tx/dfd0304f6bd018d8d97e63e387eeab0696b61d9632d50d28f1618daf434a7ba3

Additional details:
- block_hash:
000000000000000000204cb0026f5c7dd1ba847144528c79589493ff005351c3
- block_height:
547916
- size:
221 bytes
- fees:
221 satoshi
- confirmed:
2018-10-30T03:28:42Z

Actual fee rate for tx1 is 221 / 221 = 1 (satoshi / byte).

Time taken for mining + 6-block-deep confirmation ~= 12.5 hours.

The estimated delay for a transaction with this fee rate was:
1-8 blocks (0-110 minutes) for a fee rate of 1-2 satoshis / byte.

The signed transaction tx1:






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 423 dice roll results. A file containing these results is included in the Downloadable Assets section.

I proceeded leisurely but steadily.
Time taken: 16:20

16*60 + 20 = 980 seconds

980 / 423 ~= 2.32 seconds per dice roll

expected entropy per dice roll ~= 1.3333 bits

(1.3333 bits of expected entropy per dice roll) / (2.32 seconds per dice roll)
= (1.3333 / 2.32) * (bits of expected entropy / second)
= 0.57 bits of expected entropy / second

With a rate of 0.57 bits of entropy per second, I would expect that to generate a Bitcoin address, which needs 32 bytes,
(32*8 bits) / (0.57 expected bits of entropy per second)
= 32*8 / 0.57
~= 449 seconds
~= 7.5 minutes
would be required.




Financial information for this project


LocalBitcoins:
- Deposit fee for incoming transactions: 0.00015 BTC
- Transaction fee for transferring bitcoin: 0.00005 BTC

Current USD / BTC price:
$6330.00

The LocalBitcoins transaction fee was deducted from my LocalBitcoins wallet balance, not from the transction amount.

I calculated an amount of bitcoin to transfer that would be large enough to pay the necessary costs, with extra so as to have room to manoeuvre.

Calculations:
- Using a high-end fee rate of 60 satoshi / byte, and an estimated transaction size of 223 bytes, the estimated high-end fee was:
(60 satoshi / byte) * (223 bytes) = 13380 satoshi
- Total cost in Bitcoin:
= (high-end) Bitcoin transaction fee + the LocalBitcoins deposit fee
= 13380 satoshi + 0.00015 BTC
= 0.00013380 BTC + 0.00015 BTC
= 0.00028380 BTC
- Total cost in US Dollars (USD):
(6330 USD / BTC) * 0.00028380 BTC ~= $1.80
- I decided to transfer $5-worth of bitcoin to the test address, so as to have room to manoeuvre.
- Final amount in Bitcoin:
$5 * (1 BTC / 6330 USD) ~= 0.00078989 BTC

Work:
- I transferred 0.00078989 bitcoin in tx0.
- LocalBitcoins charged a transaction fee of 0.00005 bitcoin for tx0. This was subtracted from my LocalBitcoins wallet balance, not from the amount that was actually sent.
- For tx1, I used a transaction fee of 221 satoshis (0.00000221 bitcoin).
- When it accepted and processed tx1, LocalBitcoins charged a deposit fee of 0.00015000 bitcoin.
- Total bitcoin spent:
= LocalBitcoins transaction fee for tx0 + tx1 transaction fee + LocalBitcoins deposit fee for tx1 = 0.00005000 + 0.00000221 + 0.00015000 = 0.00020221 bitcoin.
- Total bitcoin spent, in then-current US Dollar prices:
0.00020221 bitcoin * (6330 USD / BTC) ~= $1.28

Results:
- Total bitcoin spent during this project: 0.00020221 bitcoin.
- Equivalent cost in US Dollars of this amount of bitcoin: $1.28











Parts:


- Validating a Bitcoin address
- Does the hash in a Bitcoin address provide any protection?
- What is the chance of two people independently generating the same Bitcoin address?






Validating a Bitcoin address


Note: I normally use the phrase "Validating an X" to refer to confirming the validity of X's format. Here, however, I'm confirming the validity of the link between X and Y, where X is derived from Y. (A Bitcoin address is derived from a private key). Perhaps I should find another word to describe this type of check.

If a valid transaction can be created that transfers bitcoin out of an address, then that address is valid.

No matter how much analysis is performed, it is always possible that there may be an error / bug in the code + hardware stack that generates the Bitcoin address from the private key. If such an error exists, and an address is incorrectly calculated from a private key, and bitcoin is transferred to this address, it will not be possible to retrieve this bitcoin. It will now be controlled by an unknown private key.

Hypothetically, if this unknown private key were known, and an address could be generated correctly from it with no errors, then the resulting address would match the one that was incorrectly generated earlier.

The only way to be certain that bitcoin can be transferred out of an address is to do so. It is preferable to test the validity of an address using a small amount of value before using it to store a large amount of value.

An address is validated once some bitcoin has been moved into an address and then successfully spent from it. A larger amount of bitcoin can now be moved into this address and the owner can be certain that it can be retrieved. Even if the owner later discovers an error in the code stack used to create and sign a transaction, he/she knows that eventually this error could be fixed and a valid transaction could be created. The owner would only risk a temporary lack of access to the bitcoin, not its permanent loss.






Does the hash in a Bitcoin address provide any protection?


One notable aspect of the Bitcoin cryptosystem is that an address contains a hash of the public key, not the public key itself. This means that if bitcoin has been transferred to an address, but not spent from it, then an adversary only knows the hash of the public key.

Notes:
- The actual hash operation is RIPEMD-160( SHA256( public key ) ).
- For a good hash function, it is computationally infeasible to reverse the hash and derive the original value.

Any transaction that spends bitcoin (i.e. spends an unspent output) from this address will include the public key in its scriptSig. This means that as soon as bitcoin has been spent from an address, an adversary knows the public key.

I have read that this aspect of Bitcoin is a protection, and that it is best to use a new address for every transaction, so that an adversary never knows the public key of an address until the bitcoin in it has been transferred to a new address.

Is this true? How much and under what circumstances would knowledge of the public key help an adversary?

In the ECDSA cryptosystem used in Bitcoin, there are (approximately) 2^256 private keys. A particular public key might be derived from any one of these private keys.

This knowledge would be useful only if there were some mathematical weakness in the ECDSA cryptosystem. If such a weakness were discovered, a frontal attack might become possible on some (or all) known public keys. My current understanding is that a frontal attack on a cryptosystem usually involves finding a way to reduce the possibility space of the results of performing a reverse operation, to the point where this possibility space can feasibly be brute forced.

Note: A non-frontal / indirect attack usually involves sabotaging an opponent's entropy sources and/or software supply chain.

A mathematical weakness in ECDSA might exist. It might already be known, or it might be discovered some day. I have not heard or read of such a weakness, but many cryptosystems in the past have been broken, so it is wise to plan for a weakness to be discovered, or at least to consider the possibility carefully.

I'll define some terms:
- "hidden-key addresses" = "addresses from which no bitcoin has ever been spent"
- "known-key addresses" = "addresses from which bitcoin has been spent at least once"

I can see two possible reasons for Satoshi Nakamoto to have hashed the public key within addresses:
1) Protection against a potential future discovery of a weakness in ECDSA. Any bitcoin in hidden-key addresses will be safe if such a discovery is made. Any bitcoin in known-key addresses might be at risk.
2) Shorter addresses. Public keys are 64 bytes. RIPEMD-160 hashes are 20 bytes. Addresses are usually ~30 characters. Ignoring the complications of base58 encoding for a moment, these two numbers suggest that addresses would have been approximately 3 times their current size if Satoshi Nakamoto had not used hashing, i.e. ~90 characters.

In case (1), bitcoin in hidden-key addresses would not necessarily be safe if an attack against the hash function were also discovered, and could feasibly be used in conjunction with the attack on ECDSA. Admittedly, these two attacks would have to be compatible i.e. operate on the same or related possibility spaces. I have read that Satoshi Nakamoto used two hash functions (SHA256, then RIPEMD-160) in order to make this combined attack more difficult.

So: To attack a hidden-key address, an adversary would need to discover weaknesses in: ECDSA, SHA256, RIPEMD-160. These weaknesses would also have to be compatible. To attack a known-key address, an adversary would only need to discover a weakness in ECDSA.

Let's consider a dictionary attack. Can this be used more successfully if the public key is known?

A dictionary attack is a brute force attack against the possibility space of private keys that a human is likely to choose. Example: A memorable passphrase. A character sequence (e.g. letters, words, phrases, numbers) of up to 32 bytes can be used as a memorable private key. The attack is possible because an adversary can make educated guesses about which sequences of characters are likely to be used. Some examples: lines of famous poems, idioms, common passwords, names of famous people, your mother's maiden name, your birthplace.

Note: A dictionary attack can also be made if a sabotaged or low-quality entropy source is used and an adversary knows some details about this entropy source.

A dictionary attack is made against a public key by testing many private keys. The attack generates private keys and calculates the corresponding public keys. If the desired public key is found, the attack has succeeded. In order to make a dictionary attack against the hash of a public key, rather than just the public key, the adversary simply needs to do some more calculation per item to hash the public key. Then, if the desired public key hash has been found, the attack has succeeded. A dictionary attack will work just as well against the public key hash as against the public key. Therefore, the hash in an address offers almost no protection against a dictionary attack.


Conclusion: The hash in a Bitcoin address provides good protection against a potential future discovery of a weakness in the ECDSA cryptosystem.






What is the chance of two people independently generating the same Bitcoin address?


If two people both generate the same Bitcoin address, they will both control any bitcoin transferred to this address. In effect, this would be an unplanned "joint account".

Let's assume that both people have access to a high-quality entropy source, so all possible private keys have an equal chance of being generated.

Note: The question "What are the odds of two people generating the same address?" is equivalent to the question "What are the odds of one person generating the same address twice?".

Let's note down some values and do some calculations.

A public key is 512 bytes (64 bytes). It consists of two 256-bit (32-byte) values (X and Y) that specify a point on the elliptic curve. The corresponding private key is only 256 bits (32 bytes).

A bit can be either 0 or 1. A sequence of 512 bits can represent 2^512 possible values.

RIPEMD-160 hashes are 160 bits (20 bytes). A sequence of 160 bits can represent 2^160 possible values. Bitcoin addresses encode / contain a RIPEMD-160 hash value. There are therefore 2^160 possible Bitcoin addresses.

(2^512) / (2^160) = 2^(512-160) = 2^352

So, for every Bitcoin address, there are 2^352 public key values that hash to that address.

However, not all possible public key values are valid. There are (approximately) 2^256 private key values, and each of them corresponds to a single public key.

(2^256) / (2^160) = 2^(256-160) = 2^96

So, for every Bitcoin address, there are 2^96 valid public key values that hash to that addresses. There are also 2^96 private key values that lead to that address.

If a private key is generated using high-quality entropy, the chance that it will lead to a particular address is:

(number of private keys per address) / (number of possible private keys)
= (2^96) / (2^256)
= 2^(96-256)
= 2^(-160)
= 1 / (2^160)

So, 1 in 2^160.

Which is, unsurprisingly, 1 chance in [number of possible addresses].


Hm. I shall proceed carefully.

Let P(x) mean "The probability of outcome x".


1) Given a particular address, what are the chances of two people independently both generating it?

P(generate a particular address) * P(generate a particular address)
= (1 / (2^160)) * (1 / (2^160))
= 1 / (2^(160+160))
= 1 / (2^320)

So, 1 in 2^320.


2) What are the chances of two people independently generating the same address? (This could be any possible address).

I think this is the sum of:
P(both people generate address 1) +
P(both people generate address 2) +
...
P(both people generate address 2^160)

This is equivalent to multiplying P(generate a particular address) by (number of possible addresses). This is:

(1 / (2^320)) * (2^160)
= (2^(-320)) * (2^160)
= 2^(-320+160)
= 2^(-160)

So, 1 in 2^160.


Ok, that's the chance of two people generating the same address. What about this question: If someone generates a new private key, what is the chance that it will lead to an existing address?

Well, how many existing addresses are there?

The chart displayed at
www.blockchain.com/charts/n-unique-addresses
indicates that currently there are (approximately) 500000 unique addresses on the Bitcoin blockchain. Presumably, these are addresses that currently hold bitcoin, since the chart shows that the number of unique addresses was higher in the past.

2^19 = 524288 ~= 500000

Hm.

The chance of the outcome "generate any one of ~2^19 existing addresses" should be:

P(generate a particular address) * (number of existing addresses)
= (1 / (2^160)) * 2^19
= 2^(19-160)
= 2^(-141)
= 1 / (2^141)

So, 1 in 2^141.


Conclusion: The chance of two people independently generating the same address is 1 in 2^160. The chance of one person generating an existing address is (currently) 1 in 2^141.














Create a project directory:
using_a_transaction_to_validate_a_bitcoin_address



If a valid transaction can be created that transfers bitcoin out of an address, then that address is valid.

No matter how much analysis is performed, it is always possible that there may be an error or bug in the code and hardware stack that generates the Bitcoin address from the private key. The only way to be certain that bitcoin can be transferred out of an address is to do so. It is therefore preferable to test the validity of an address using a small amount of value before using it to store a large amount of value.

One protection in the Bitcoin cryptosystem is that addresses contain hashes of public keys, not public keys. This means that if bitcoin has been transferred to an address, but not spent from it, then an adversary only knows the hash of the public key. As soon as bitcoin has been transferred out of the address, the public key is available to an adversary, since it is included in the transaction.

Does this matter? Well, it's an extra obstacle for an adversary trying to generate many addresses, see if they exist on the Bitcoin blockchain, check if there is unspent bitcoin stored in them, and steal it. RIPEMD-160 hashes are 160 bits (20 bytes) long. ECDSA public keys are 512 bits (64 bytes) long. Many public keys will map to the same hash value.

Hm. How many?

512 bits can represent 2^512 possible bit sequences. 160 bits can represent 2^160 possible bit sequences.

(2^512) / (2^160) = 2^(512-160) = 2^352

That's a lot. So, for every Bitcoin address, there are 2^352 public keys that might hash down to that address.


Hm. A public key consists of two 256-bit (32-byte) values for X and Y (specifying a point on the elliptic curve). The corresponding private key is only 32 bytes, not 64 bytes.

(2^256) / (2^160) = 2^(256-160) = 2^96

Technically, only 2^96 of those 2^352 public keys will actually be actual valid Bitcoin public keys that have a corresponding private key. However, an adversary won't know which of the 2^352 candidate public keys that hash to the known address hash are actual valid Bitcoin public keys.

Note: The actual candidate public keys are unknown to the adversary - 2^352 is simply the theoretical number of candidates, given a particular hash value.

Note: Not all 256-bit values are valid private keys, but most are. See Generating a standard Bitcoin address, Notes / Discoveries section, part "Notes on the nature, secure creation, and validity of Bitcoin private keys and transactions", item (1).

Now, if a transaction is broadcast from an address, then an adversary knows the public key. The 2^352 unknown candidate public keys are reduced to 1 known public key. However, there are still approximately 2^256 candidate private keys that might correspond to this public key. Given the size of this possibility space, a brute force attack is not a threat.

If low-quality entropy is used, then the known public key is vulnerable to a dictionary attack. Low-quality entropy example: a memorable passphrase. A dictionary attack is a brute force attack against the possibility space of private keys that a human is likely to choose. A 32-byte character sequence (e.g. letters, words, phrases, numbers) can be used as a memorable private key. The attack is possible because an adversary can make educated guesses about which sequences of characters are likely to be used. Some examples: lines of famous poems, idioms, common passwords, names of famous people, your mother's maiden name, your birthplace.

Note: A longer character sequence can be used and hashed when necessary (e.g. with SHA256) to reduce it to the length of a private key.

Hm. Wait. The 2^352 candidate public keys from earlier all hash to the same address. This means that they (or rather the 2^96 valid private keys) can all spend from that address. The hash, not the public key, is the value that is required in a valid transaction scriptSig. Any public key that hashes to this value will be accepted as valid in a transaction.

If high-quality entropy is used to generate the private key then it is still safe from a dictionary attack.

Hm. A dictionary attack would still work against the address / hash just as well as against the public key. The adversary simply needs to do some more calculation per item to derive the address / hash from the public key.

I conclude that the hash does not provide enough protection to justify keeping the public key secret i.e. not using a transaction to validate an address.

Note: I don't know whether Satoshi Nakamoto actually intended the RIPEMD-160 hash in the address to be a protection or if he simply wanted the address to be shorter.

Note: For every 160-bit hash in a Bitcoin address, there are 2^96 private keys that correspond to this address. If two people both generate the same private key, and transfer bitcoin to the corresponding address, they will both have access to the resulting bitcoin. A "joint account", in practice. What are the actual odds of accidentally having a joint account? Not high, but what are they?

Hm. Well, there are 2^160 addresses and (approximately) 2^256 private keys. For each address, there are 2^96 private keys that map to that address. Let's call these "joint-account" private keys.

Odds of an accidental joint account within the private key possibility space:
(Number of joint-account private keys per address) / (Number of possible private keys) = 2^96 / 2^256 = 2^(96-256) = 2^(-160)
= 1 / 2^160

Ah. Quite small. So, if I generate a private key using high-quality entropy, the odds of someone else also generating this key or a related joint-account key are 1 in 2^160.

Which... makes sense, given that there are 2^160 valid addresses.





Plan of action:

- Generate an address. This will be the "test address".
- Transfer some bitcoin to it. I'll call this "tx0".
- Construct and sign a transaction that transfers bitcoin out of the test address to another "final" address. I'll call this "tx1".
- Broadcast the transaction. If the transaction is mined, then the address has been validated.


I'll use toolsets developed during previous projects.


For generating entropy:
Generating entropy with dice

I'll need entropy for the Bitcoin private key and for signing the transaction.


For:
- generating a Bitcoin address from the private key.
- constructing and signing a single-input, single-output transaction (standard or nonstandard).
Creating and signing a standard raw Bitcoin transaction: Iteration #2




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




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.


I define a "standard" address to be an uncompressed single-signature Pay-To-Public-Key-Hash (P2PKH) address.



I'll transfer bitcoin from my LocalBitcoins account to the test address.


I'll use my current LocalBitcoins receiving address as the final address. It will be Pay-To-Script-Hash (P2SH) i.e. nonstandard, so I'll use the create_nonstandard_transaction toolset.


Log on to LocalBitcoins.
Current receiving address:
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti
Current deposit fee for incoming transactions: 0.00015 BTC
Transaction fee: 0.00005 BTC



In the project directory, create a work directory named "work".


Let's gather the toolsets.

I have 5 dice and a tray with raised edges in which to roll them.

Browse to:
Generating entropy with dice
Go to the Downloadable Assets section. Download the asset
- convert_dice_rolls_to_hex_bytes.py.
Move this asset into the work directory.

Note the section Recipe For Generating Entropy Bytes Using Dice.

Browse to:
Creating and signing a standard raw Bitcoin transaction: Iteration #2
Go to the Downloadable Assets section. Download the assets
- bjorn_edstrom_ripemd160.py
- ecdsa-0.10.tar.gz
- pypy_sha256.py
- bitcoin_functions.py
- generate_bitcoin_address_3.py
- transaction.py
- nonstandard_bitcoin_functions.py
- nonstandard_transaction.py
- create_nonstandard_transaction.py
Move these assets into the work directory.

Note the section Recipes For Using Various Downloadable Assets, particularly these recipes:
- 1: Setup
- 2: generate_bitcoin_address_3.py
- 4: create_nonstandard_transaction.py



A thought: I seem to recall that another reason to hash the Bitcoin public key is to protect against the potential future discovery of a mathematical flaw in ECDSA, which might allow an adversary to reduce the possibility space of candidate private keys for the known public key, and thus make a brute force attack more feasible. If only the hash is publicly available, i.e. no bitcoin has been spent from the address, then even if a flaw in ECDSA is discovered, any bitcoin in the address should remain safe. In this situation, the flaw would be exploitable only if compatible flaws had also been discovered in the SHA256 and RIPEMD-160 hash algorithms.


Reading the following recipes in Creating and signing a standard raw Bitcoin transaction: Iteration #2, in the section Recipes For Using Various Downloadable Assets:
- 1: Setup
- 2: generate_bitcoin_address_3.py
- 4: create_nonstandard_transaction.py
I note that recipes 2 and 4 each require 32 bytes of entropy.

For this project, I need to generate 1 address and construct 1 nonstandard transaction. Note that the transaction has only 1 input signature (which is the part that needs entropy). I will thus need 1*32 + 1*32 = 64 bytes of entropy.



I'll proceed through the section Recipe For Generating Entropy Bytes Using Dice in Generating entropy with dice in order to generate this entropy. I'll copy it here.


Excerpt:

Recipe For Generating Entropy Bytes Using Dice

Note: This recipe relies, at its base, on the algorithm described in the Notes section, in the "Algorithm for converting dice rolls to entropy bytes" part.

0. Obtain the script convert_dice_rolls_to_hex_bytes.py. This file is stored as an asset of this article. See the Downloadable Assets section.

1. Obtain one or more dice.

2. Choose a desired number of bytes of entropy. Multiply this number by 8 to convert to bits. Divide the result by the expected-bit-rate-per-dice-roll value (1.3333) to find the expected number of dice rolls that should generate this number of entropy bits. Multiply this result by 1.1 to add a 10% margin, then round up to the nearest integer.

Note: Some dice roll result values will be discarded so that the value domain becomes base4, which can be then be converted to base16 (i.e. hex bytes).

3. Perform this number of dice rolls and record the results in a text file. An individual dice roll must be recorded as one individual character from the list "123456". Whitespace (newline, tab, space) can be used to separate groups of dice roll values. Recommendation: Roll the dice on a flat tray with raised edges, so that they don't scatter too far.

4. In the script convert_dice_rolls_to_hex_bytes.py, scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

- Set the variable

desired_n

to be the desired number of bytes of entropy.
- Set the variable

dice_rolls_file_path

to be the path to the text file containing the dice roll results.

5. Open a terminal. Change directory to the directory containing this script. Run the script using the following command:

python convert_dice_rolls_to_hex_bytes.py

6. The output of the script should contain the generated entropy as hex bytes.

7. (optional) If more dice rolls are needed in order to reach the desired number of bytes of entropy, the script will calculate a suggested number of new dice rolls. Perform the dice rolls, add the results to the dice roll results text file, and run the script again.

Let's do step 2.
- I want 64 bytes of entropy.
- Multiply by 8: 64*8 = 512 bits
- Divide by 1.3333: 512/1.3333 ~= 384
- Multiply by 1.1: 384 * 1.1 = 422.4
- Round up to the nearest integer: round(422.4) = 423
Result: 423


Next: Step 3.

3. Perform this number of dice rolls and record the results in a text file. An individual dice roll must be recorded as one individual character from the list "123456". Whitespace (newline, tab, space) can be used to separate groups of dice roll values. Recommendation: Roll the dice on a flat tray with raised edges, so that they don't scatter too far.

I'll record the results here, and time how long it takes to get them. I'll use lines of 5 characters and groups of 5 lines. Each group will thus contain 5*5 = 25 dice rolls.

423/25 = 16.92 groups




423 dice rolls.

Time taken: 16:20
16*60 + 20 = 980 seconds

980 / 423 ~= 2.32 seconds per dice roll

expected entropy per dice roll ~= 1.3333 bits

(1.3333 bits of expected entropy per dice roll) / (2.32 seconds per dice roll)
= (1.3333 / 2.32) * (bits of expected entropy / second)
= 0.57 bits of expected entropy / second

Compare with the result found in the previous project Generating entropy with dice:
- 0.89 bits of entropy per second


I did not proceed quickly, as in the previous project. I proceeded leisurely but steadily.

Using the rate of 0.57 bits of entropy per second, I would expect that to generate a Bitcoin address, which needs 32 bytes,
(32*8 bits) / (0.57 expected bits of entropy per second)
= 32*8 / 0.57
~= 449 seconds
~= 7.5 minutes
would be required.


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


I'll copy the dice results into a new file called "dice_rolls.txt" and save this file in the work directory. I'll remove the notes e.g. "10 groups so far".






Next: Step 4

4. In the script convert_dice_rolls_to_hex_bytes.py, scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

- Set the variable

desired_n

to be the desired number of bytes of entropy.
- Set the variable

dice_rolls_file_path

to be the path to the text file containing the dice roll results.

is already set to be "dice_rolls.txt".

Set to be 64.


Next: Steps 5 & 6

5. Open a terminal. Change directory to the directory containing this script. Run the script using the following command:

python convert_dice_rolls_to_hex_bytes.py

6. The output of the script should contain the generated entropy as hex bytes.

Open a terminal. Change directory to the work directory.





Hm. Remaining hex bytes should only be 2 hex bytes (4 hex characters).


Ah. There's an error in the code.

In the following section:



The number in lines 99 and 102 should actually be . The value 32 was hardcoded, which didn't cause any problems during the previous project because I wanted a 32-byte result.

In the code, substitute for in lines 99 and 102.

Then run the script again.





Hm. Why have an odd number of hex characters been left over?


Aha. I didn't include a check for that.


Immediately after the newline at the end of line 88, add the following section:




Then run the script again.






Excellent.

The desired 64 bytes of entropy:



I want to divide this entropy into two pieces, each of 32 bytes. Note that 2 hex characters represent 1 byte.





Entropy-bytes-1:


Entropy-bytes-2:






Ok. I'll move on to recipe 1 (Setup), in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. I'll copy it here.


Excerpt:

Recipe 1: Setup


Initial condition: You must have Python 2.7.x installed on your computer. These code assets were tested under Python 2.7.13 running on Mac OS X 10.6.8 (Snow Leopard), and should run successfully on other versions of Python 2.7.


Steps:

- Create a work directory.

- Browse to the Downloadable Assets section of this article.

- Download the asset bjorn_edstrom_ripemd160.py.

- Download the asset ecdsa-0.10.tar.gz.

- Download the asset pypy_sha256.py.

- Download the asset bitcoin_functions.py.

- Move these assets into the work directory.

- Unpack the zipped tape archive file ecdsa-0.10.tar.gz. This can be done by opening a terminal, changing directory to the work directory, and running the following command:

tar -zxvf ecdsa-0.10.tar.gz

This unpacking should produce a new directory named ecdsa-0.10 in the work directory. The directory ecdsa-0.10 should contain a directory named ecdsa. Copy the ecdsa directory into the work directory.

I already have Python 2.7.13 installed on this computer.

I've already created a work directory. I've already downloaded the listed assets and moved them into the work directory.

Next: Unpack the zipped tape archive file ecdsa-0.10.tar.gz.


In the terminal, in the work directory:





Setup complete.


Next: Recipe 2 (generate_bitcoin_address_3.py), in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. I'll copy it here.


Excerpt:

Recipe 2: generate_bitcoin_address_3.py


Notes:
- generate_bitcoin_address_3.py is a script that generates a standard Bitcoin address from a private key.
- All control values in this script are strings.


Steps:

- Work through Recipe 1: Setup.

- Generate a random private key that is between 1 and 32 bytes long. This requires some work (e.g. using dice) and is not covered in this recipe.

Note: Ideally a private key should be 32 bytes long. It can be raw bytes (printable ASCII characters) or hex bytes (hex characters). Hex characters must be lowercase. 1 byte is represented by 2 hex characters, so a 32-byte private key will be 64 hex characters long. I recommend hex bytes, as these can represent all possible private keys. I find that raw byte private keys are convenient during testing.

- Browse to the Downloadable Assets section of this article.

- Download the asset generate_bitcoin_address_3.py. Move it into the work directory.

- Open the file generate_bitcoin_address_3.py in a text editor. Scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

- If the private key is in raw bytes, set the variable

private_key_type

to

"raw_bytes"

and set the variable

private_key_raw_bytes

to the private key.

- If the private key is in hex bytes, set the variable

private_key_type

to

"hex_bytes"

and set the variable

private_key_hex_bytes

to the private key.

- Open a terminal and change directory to the work directory.

- Run the following command:

python generate_bitcoin_address_3.py

- The output should contain the Bitcoin address that corresponds to your private key.

Note: Please go to the "Addresses generated and/or used in this project" part of the Notes section to see two examples of the output of this script.

I've already worked through Recipe 1: Setup.

I'll use the first half of the entropy that I generated earlier, entropy-bytes-1, as the private key for generating an address.

Entropy-bytes-1:


I've already downloaded the asset generate_bitcoin_address_3.py and moved it into the work directory.


Next:

- Open the file generate_bitcoin_address_3.py in a text editor. Scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

[...]

- If the private key is in hex bytes, set the variable

private_key_type

to

"hex_bytes"

and set the variable

private_key_hex_bytes

to the private key.

Done.

set to .

set to
.

Note: Unused input variables can be set to the empty string {""}, but there is no need to. I left set to .


Finally:

- Open a terminal and change directory to the work directory.

- Run the following command:

python generate_bitcoin_address_3.py

- The output should contain the Bitcoin address that corresponds to your private key.

Excellent.


Test address:
- Private key (hex bytes):
a26e15954d2dafcee70eeaaa084eab8a4c1a30b0f71a42be4d8da20123bff121
- Bitcoin address:
1AGygbyEFYduWkkmZbbvirgS9kuBBMLJCP







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

LocalBitcoins:
- Current deposit fee for incoming transactions: 0.00015 BTC
- 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 223 bytes.

The fee rate range 1-2 satoshi / byte includes many transactions waiting for confirmation. Estimated delay = 1-8 blocks (0-110 minutes).

A fee rate of 60 satoshi / byte looks quite high.

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

13380 satoshi * 1 BTC / 10^8 satoshi = 0.00013380 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.00013380 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.00013380 + 0.00015
= 0.00028380 BTC


Current USD / BTC price:
$6330.00

(6330 USD / BTC) * 0.00028380 BTC ~= $1.80


I'll transfer $5-worth of bitcoin to the test address, so as to have room to manoeuvre.


$5 * (1 BTC / 6330 USD) ~= 0.00078989 BTC




Next: Transfer bitcoin to the test address. This transaction will be tx0.

Log on to LocalBitcoins.

Go to Wallet / Send bitcoins.

Send 0.00078989 BTC to
1AGygbyEFYduWkkmZbbvirgS9kuBBMLJCP

Go to Wallet / Transactions.

In the new entry for
1AGygbyEFYduWkkmZbbvirgS9kuBBMLJCP,
the txid is shown:



Browse to:
live.blockcypher.com

Search for this txid.

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

Confirmations: 0/6

Set timer for 1 hour.

Timer has ended.
Refresh page.
Confirmations: 3/6

Set timer for 30 minutes.

Timer has ended.
Refresh page.
Confirmations: 5/6

[do something else for a while]

Refresh page.
Confirmations: 6+


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

Result: tx0




Key details:
- block_hash:
00000000000000000001d5c84216c226186288fad3bedb057a25b393f44cae0d
- block_height: 547832
- confirmed: 2018-10-29T12:26:02Z
- received: 2018-10-29T12:01:38.373Z
- txid:
bf7a16ef4bf8763b7bf7f02b03155c9a2f9b997d19e64a770bf3f7d3f24cc48b






Next: Construct and sign a (nonstandard) transaction that transfers bitcoin out of the test address to the (nonstandard) final address.


Next: Recipe 4 (create_nonstandard_transaction.py), in the section Recipes For Using Various Downloadable Assets in the previous article Creating and signing a standard raw Bitcoin transaction: Iteration #2. I'll copy it here.


Excerpt:

Recipe 4: create_nonstandard_transaction.py


Notes:
- create_nonstandard_transaction.py is a script that creates and signs a nonstandard Bitcoin transaction with one input and one output. The input address must be a standard P2PKH address and the output address must be a nonstandard P2SH address. P2PKH addresses start with the character '1'. P2SH addresses start with the character '3'.
- All control values in this script are strings.
- 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.


Definitions:
- input address: the address that currently contains the bitcoin that you want to transfer in this transaction.
- output address: the address to which the bitcoin will be transferred by this transaction.
- previous_output_hash: big-endian 32-byte double-SHA256 hash of a previous transaction.
- txid: "transaction id", the little-endian form of the previous_output_hash.


Steps:

- Work through Recipe 1: Setup.

- Gather the following pieces of information:

-- The txid of the previous transaction that transferred the unspent output to the input address.

-- The index of this unspent output in the previous transaction (the "previous_output_index"). This index is implicit and starts at zero.

-- The private key (in hex bytes) of the input address.

-- The bitcoin amount (or satoshi amount) contained within the unspent output. Let's call this the "input amount".

- Choose the following pieces of information:

-- The output address.

-- The bitcoin amount (or satoshi amount) that you wish to transfer to the output address. Let's call this the "output amount".

-- The change address. Currently, this is the same as the output address. Any value not assigned to an output address will be assigned to the change address. The fee will then be subtracted from the value assigned to the change address.

-- The fee (in satoshi) or fee_rate (in satoshi / byte). The fee must be an integer e.g.

"225"

. The fee_rate must be an integer e.g.

"1"

or a float e.g.

"1.2"

. You should look up the range of fee rates for transactions that are currently being mined.

- Generate a random value that is between 1 and 32 bytes long. This requires some work (e.g. using dice) and is not covered in this recipe.

Note: This random value will be used for creating the ECDSA signature of the transaction. Every ECDSA signature you ever make should use a different random value. Ideally a random value should be 32 bytes long. It can be raw bytes (printable ASCII characters) or hex bytes (hex characters). Hex characters must be lowercase. 1 byte is represented by 2 hex characters, so a 32-byte random value will be 64 hex characters long. I recommend hex bytes, as these can represent all possible random values. I find that raw byte random values are convenient during testing.

- Browse to the Downloadable Assets section of this article.

- Download the asset transaction.py.

- Download the asset nonstandard_bitcoin_functions.py

- Download the asset nonstandard_transaction.py.

- Download the asset create_nonstandard_transaction.py

- Move these assets into the work directory.

- Open the file create_nonstandard_transaction.py in a text editor. Scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

- Set the variable

random_value

to the random value.

- If the random value is in raw bytes, set the variable

random_value_type

to

"raw_bytes"

.

- If the random value is in hex bytes, set the variable

random_value_type

to

"hex_bytes"

.

- The variable

input_data

is a dictionary that contains several other variables.

-- Set the value of the variable

input_data["txid"]

to be the txid.

-- Set the value of the variable

input_data["previous_output_index"]

to be the index of the unspent output.

-- Set the value of the variable

input_data["private_key_hex"]

to be the private key.

-- If the input amount is in satoshi, set the value of the variable

input_data["satoshi_amount"]

to be the input amount.

-- If the input amount is in bitcoin, set the value of the variable

input_data["bitcoin_amount"]

to be the input amount.

Note: Currently, if both of the variables

input_data["satoshi_amount"]

and

input_data["bitcoin_amount"]

are set, then

input_data["bitcoin_amount"]

will take precedence. You can comment out the unused variable of the pair by placing a number sign ('#') at the start of the relevant line.

-- Set the value of the variable

input_data["input_type"]

to be

"p2pkh"

.

- The variable

output_data

is a dictionary that contains several other variables.

-- Set the value of the variable

output_data["address"]

to be the output address.

-- If the output amount is in satoshi, set the value of the variable

output_data["satoshi_amount"]

to be the output amount.

-- If the output amount is in bitcoin, set the value of the variable

output_data["bitcoin_amount"]

to be the output amount.

Note: Currently, if both of the variables

output_data["satoshi_amount"]

and

output_data["bitcoin_amount"]

are set,

output_data["bitcoin_amount"]

will take precedence. You can comment out the unused variable of the pair by placing a number sign ('#') at the start of the relevant line.

-- Set the value of the variable

output_data["output_type"]

to be

"p2sh"

.

- Set the variable

change_address

to be the change address.

- If you have chosen to set the fee as an absolute number of satoshi, set the variable

fee

to be the fee amount and set the variable

fee_type

to be

"fee"

.

- If you have chosen to set the fee as a fee rate (in satoshi / byte), set the variable

fee_rate

to be the fee rate and set the variable

fee_type

to be

"fee_rate"

.

- Open a terminal and change directory to the work directory.

- Run the following command:

python create_nonstandard_transaction.py

- The output should contain the signed transaction as a hex byte sequence without spaces.

Note: Please go to the "Transactions created during this project" part of the Notes section to see an example of the output of this script.

I've already worked through Recipe 1: Setup.


Next:

- Gather the following pieces of information:

-- The txid of the previous transaction that transferred the unspent output to the input address.

-- The index of this unspent output in the previous transaction (the "previous_output_index"). This index is implicit and starts at zero.

-- The private key (in hex bytes) of the input address.

-- The bitcoin amount (or satoshi amount) contained within the unspent output. Let's call this the "input amount".

txid0:



In the earlier information about tx0, I see that:
- vout_sz = 23
i.e. there are 23 outputs.

One of these outputs is the one sent to the test address.

Searching through the earlier information for
1AGygbyEFYduWkkmZbbvirgS9kuBBMLJCP
I find:



The particular output that I am interested in is the first one in the output list.

Outputs are implicitly 0-indexed, so this output has an index of 0.

So:
previous_output_index = 0

The private key in hex bytes of the input address is:


The satoshi amount contained in this output is shown in the datablock above, stored in the variable "value":
78989



Let's collect this information together:
1) txid of the previous transaction (txid0):

2) previous_output_index:
0
3) private key of the input address in hex bytes:

4) input amount (in satoshi):
78989



Next:

- Choose the following pieces of information:

-- The output address.

-- The bitcoin amount (or satoshi amount) that you wish to transfer to the output address. Let's call this the "output amount".

-- The change address. Currently, this is the same as the output address. Any value not assigned to an output address will be assigned to the change address. The fee will then be subtracted from the value assigned to the change address.

-- The fee (in satoshi) or fee_rate (in satoshi / byte). The fee must be an integer e.g.

"225"

. The fee_rate must be an integer e.g.

"1"

or a float e.g.

"1.2"

. You should look up the range of fee rates for transactions that are currently being mined.

The output address is the final address (my current LocalBitcoins receiving address):
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti

The amount that I wish to transfer to the output address. Well, I'll set this to be the same as the input value, and the create_nonstandard_transaction.py script will subtract the fee from it.

So: output amount = input amount = 78989 (satoshi).

The change address. Currently, the only option supported is "change address is the single output address", so the change address is:
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti

I'll use the smallest fee rate in the set of reasonable fee rates reported by bitcoinfees.earn.com, which is 1 satoshi / byte. "Reasonable" means that transactions with this fee rate are currently being mined.



Let's collect this information together:
1) output address:
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti
2) output amount (satoshi):
78989
3) change address:
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti
4) fee rate (satoshi / byte):
1



Next:

- Generate a random value that is between 1 and 32 bytes long. This requires some work (e.g. using dice) and is not covered in this recipe.

Note: This random value will be used for creating the ECDSA signature of the transaction. Every ECDSA signature you ever make should use a different random value. Ideally a random value should be 32 bytes long. It can be raw bytes (printable ASCII characters) or hex bytes (hex characters). Hex characters must be lowercase. 1 byte is represented by 2 hex characters, so a 32-byte random value will be 64 hex characters long. I recommend hex bytes, as these can represent all possible random values. I find that raw byte random values are convenient during testing.

I'll use the second half of the entropy that I generated earlier, entropy-bytes-2, as the random value for creating the ECDSA signature of the transaction.

Entropy-bytes-2:





Next:

- Browse to the Downloadable Assets section of this article.

- Download the asset transaction.py.

- Download the asset nonstandard_bitcoin_functions.py

- Download the asset nonstandard_transaction.py.

- Download the asset create_nonstandard_transaction.py

- Move these assets into the work directory.

I've already downloaded the assets
- transaction.py
- nonstandard_bitcoin_functions.py
- nonstandard_transaction.py
- create_nonstandard_transaction.py
and moved them into the work directory.


Next:

- Open the file create_nonstandard_transaction.py in a text editor. Scroll to the section of text that lies between

##### START CONTROLS

and

##### END CONTROLS

- Set the variable

random_value

to the random value.

- If the random value is in raw bytes, set the variable

random_value_type

to

"raw_bytes"

.

- If the random value is in hex bytes, set the variable

random_value_type

to

"hex_bytes"

.

- The variable

input_data

is a dictionary that contains several other variables.

-- Set the value of the variable

input_data["txid"]

to be the txid.

-- Set the value of the variable

input_data["previous_output_index"]

to be the index of the unspent output.

-- Set the value of the variable

input_data["private_key_hex"]

to be the private key.

-- If the input amount is in satoshi, set the value of the variable

input_data["satoshi_amount"]

to be the input amount.

-- If the input amount is in bitcoin, set the value of the variable

input_data["bitcoin_amount"]

to be the input amount.

Note: Currently, if both of the variables

input_data["satoshi_amount"]

and

input_data["bitcoin_amount"]

are set, then

input_data["bitcoin_amount"]

will take precedence. You can comment out the unused variable of the pair by placing a number sign ('#') at the start of the relevant line.

-- Set the value of the variable

input_data["input_type"]

to be

"p2pkh"

.

- The variable

output_data

is a dictionary that contains several other variables.

-- Set the value of the variable

output_data["address"]

to be the output address.

-- If the output amount is in satoshi, set the value of the variable

output_data["satoshi_amount"]

to be the output amount.

-- If the output amount is in bitcoin, set the value of the variable

output_data["bitcoin_amount"]

to be the output amount.

Note: Currently, if both of the variables

output_data["satoshi_amount"]

and

output_data["bitcoin_amount"]

are set,

output_data["bitcoin_amount"]

will take precedence. You can comment out the unused variable of the pair by placing a number sign ('#') at the start of the relevant line.

-- Set the value of the variable

output_data["output_type"]

to be

"p2sh"

.

- Set the variable

change_address

to be the change address.

- If you have chosen to set the fee as an absolute number of satoshi, set the variable

fee

to be the fee amount and set the variable

fee_type

to be

"fee"

.

- If you have chosen to set the fee as a fee rate (in satoshi / byte), set the variable

fee_rate

to be the fee rate and set the variable

fee_type

to be

"fee_rate"

.

Done.

set to
.

set to .

set to
.

set to .

set to
.

set to .

Comment out the unused variable by placing a number sign ('#') at the start of the relevant line. Note: It was actually already commented out.

set to .

set to
.

set to .

Comment out the unused variable by placing a number sign ('#') at the start of the relevant line.

set to .

set to
.

set to .

set to .


Results:






Finally:

- Open a terminal and change directory to the work directory.

- Run the following command:

python create_nonstandard_transaction.py

- The output should contain the signed transaction as a hex byte sequence without spaces.

In the terminal, in the work directory:





Woops. The estimated size of a transaction with one P2PKH input and one P2SH output should actually have been 221 bytes, not 223 bytes.


The signed transaction (tx1):






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.




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/dfd0304f6bd018d8d97e63e387eeab0696b61d9632d50d28f1618daf434a7ba3
Details:
- Transaction Successfully Broadcst
- AMOUNT TRANSACTED: 0.00078768 BTC
- FEES: 0.00000221 BTC
- Confirmations: 0/6
- Miner Preference: LOW
- Size: 221 bytes
- Version: 1
- Relayed By: 54.167.244.83




Time: 14:53


Log into LocalBitcoins.
Browse to Wallet / Receive bitcoins.

An incoming transaction is listed.
- Time: 2:51 pm
- Address:
3QpwGejV9Dyai72HDhXZVkYBWioyuLVjti
- BTC: 0.00078768
- Confirmed in about: 30 minutes


In the previous project Creating and signing a standard raw Bitcoin transaction: Iteration #2, a similar transaction with a similar fee rate took about 6 hours to be mined and be confirmed 6 times.




Time: 23:24
Refresh transaction page.
- Confirmations: 0/6


Time: 08:46 (next day)
Refresh transaction page.
- Confirmations: 6+


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

Result: tx0





Key details:
- block_hash:
000000000000000000204cb0026f5c7dd1ba847144528c79589493ff005351c3
- block_height: 547916
- confirmed: 2018-10-30T03:28:42Z
- received: 2018-10-29T14:51:09.984Z
- txid:
dfd0304f6bd018d8d97e63e387eeab0696b61d9632d50d28f1618daf434a7ba3



Using the times from blockcypher.com:
- Broadcast time: 2018-10-29 14:51
- Confirmation time: 2018-10-30 03:28

Time taken ~= 12.5 hours



Log on to LocalBitcoins.
Go to Wallet / Transactions.
- Latest received transaction:
-- Datetime: 10/30/2018 03:46
-- Received BTC: 0.00063768
-- Description: Deposit to 3QpwGe......
-- Deposit Fee BTC: 0.00015000



The test address has now been validated. I have moved some bitcoin into it and then successfully retrieved it.

I can now move a large amount of bitcoin into this address and be certain that I can retrieve it. Even if I later discover 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, not its permanent loss.


Good.





That's the end of this project.