This document discusses bitcoin transactions. It explains that transactions move value on the bitcoin network by wrapping the transfer of funds within a transaction prior to broadcasting. The structure of transactions includes inputs, which point to unspent transaction outputs (UTXOs) being used as funds, and outputs, which create new UTXOs. Standard transaction types include pay-to-public-key-hash, pay-to-public-key, multi-signature, and pay-to-script-hash transactions. The document provides examples of these transaction types and resources for exploring transactions further.
4. Transactions
• Movement of value on the network
• These actions are wrapped within a transaction prior to broadcast
• Transactions are in plain text and readable by all
• Broadcasted to all Bitcoin nodes
4
6. • Inputs are the source of funds being moved, pointers to the
transaction hash and sequence number of the UTXO containing
moved value
• The output of a transaction is the creation of an unspent transaction
output (UTXO)
• UTXO are denominated in Satoshis
• A locking script that encumbers this value requiring specific
conditions to be met for the owner to spend
6
7. Transaction Structure Cond.
• A transaction completely depletes the UTXO
being used
• Should only a portion be required, change
must be considered
• Change is the unused portion of the UTXO
being moved
• The difference between the new UTXO and
change is taken by the network as a fee
7
9. Standard Transactions
• Pay-to-Public-Key-Hash (P2PKH)
• Pay-to-Public-Key
• Multi-Signature
• Data Output
• Pay-to-Script-Hash (P2SH)
The majority of Bitcoin transactions today
are of this general type. These types of
transactions are used to transfer value,
typically from one user to another. They
are constructed having the form: scriptSig
(or the unlocking script) first, followed by
the scriptPubKey (or locking script).
9
10. Standard Transactions
• Pay-to-Public-Key-Hash (P2PKH)
• Pay-to-Public-Key
• Multi-Signature
• Data Output
• Pay-to-Script-Hash (P2SH)
Another payment transaction. These types
of transactions are effectively outdated
with P2PKH being preferred. The public
key itself, not its hash, is stored in the
locking script. This has the advantages of
being shorter, though less secure.
10
11. Standard Transactions
• Pay-to-Public-Key-Hash (P2PKH)
• Pay-to-Public-Key
• Multi-Signature
• Data Output
• Pay-to-Script-Hash (P2SH)
A M of N schema, where there are N total
number of keys and M are needed to
create the signature for a valid transaction.
Presently limited to a maximum of 15 listed
public keys.
11
12. Standard Transactions
• Pay-to-Public-Key-Hash (P2PKH)
• Pay-to-Public-Key
• Multi-Signature
• Data Output
• Pay-to-Script-Hash (P2SH)
The allure of the Block Chain, as a single
source of shared truth embodied by a
immutable database opens up many
possibilities. Notary services and beyond.
As such, developers have wanted to take
full advantage of this instrument.
OP_RETURN allows for 40 bytes of data
to be stored in the block chain.
12
13. Standard Transactions
• Pay-to-Public-Key-Hash (P2PKH)
• Pay-to-Public-Key
• Multi-Signature
• Data Output
• Pay-to-Script-Hash (P2SH)
Payment to P2SH goes instead to a
potentially complex locking script but rather
to the hash of the script. This greatly
shortens the overall size of the transaction.
A future spend of this UTXO requires the
script whose hash matches.
13
14. My Method of Inquiry
After building my transaction, I had a serial hex mess -
But what did all of this stuff mean?
14
Transactions are an expression of intent to transfer value between parties.
Pic: https://commons.wikimedia.org/wiki/File:Bitcoin_Transaction_Inputs_and_Outputs.png
What do they do?
Movement of value across a decentralized network.
Although cryptographic solutions abound in Bitcoin, transactions are clear text.
A signed transaction is broadcasted to all nodes on the network, not just to the address receiving a payment.
Every node independently validates each transaction to prevent an invalid transaction.
What are they?
Just because these are data structures and must therefore conform to well defined rules - that doesn’t say anything about knowing what those rules are. I had to search through multiple sources. As no one source held a complete record what exactly the role of each byte.
Also, never forget that one is reading HEX.
A block explorer is critical in this case - either you are making a RPC to a local copy of the Block Chain, or more likely you are using someone’s Web API. The information of a transaction ID and seq can only be had via these two routes.
The Script is not the only mechanism for ‘locking’ down a transaction:
nLockTime :: A transaction is invalid until such time (or block height) exceeds the value ascribed to this. Most of the time, this value is set to null - and is therefore ignored. However, if a value has been assigned then it acts exactly like the post dating of a check. As this makes for an invalid transaction though, no relay will accept this transaction. If you wish to use this, then you must use a service that will hold the transaction and only releasing it after this condition has been met.
Lastly it uses UNIX time - one major difference being signed Vs. Unsigned. Bitcoin uses an unsigned 32 byte integer. As such nLockTime is immune to 2038 UNIX ‘bug’.
Failure to include a proper change address will result in unintended loss.
Instead of a separate data field for fees, the network subtracts inputs and outputs with this difference being ‘fees’.
Change addresses (all addresses really) should never be re-used. The re-use of an address is considered bad security practice.
isStandard() == This function within the Bitcoin Protocol defines the five (5) standard transactions.
A transaction that is not standard may be rejected by the miner. It does not mean though that it can’t go through, and some mining pools will process non-standard transactions: see ELIGIUS
The “transaction” that one typically is referring to. The mechanism whereby value is encumbered by another.
Older mechanism. Shorter - though one’s public key is completely in the clear.
There is a limit of 15 public keys - and one should double check if this is still the case (April 17 2015)
To reduce the potential for bloat, OP_RETURN was brought into 0.9 of the core client. This transaction returns null and does not move/encumber value.
It is simply a means to placing data into the blockchain in a prune-able manner that does not otherwise effect unspent transaction outputs. Currently the max information that can be stored is 40 bytes —> 80 bytes with v0.10 upgrade. So target a data payload of 40 bytes until more nodes have upgraded their software.
Suppose you have a multi-sig address and someone wishes to pay to this. This would require that the transaction contains the N public keys and may result in a large transaction, and hence a larger fee. Instead the hash of this complex script is used.
A question asked, revolved around the ‘size’ and pricing transactions. Upon further research: (April 19 2015; https://en.bitcoin.it/wiki/Transaction_fees) A transaction that is smaller than 1,000 bytes and all outputs are greater than 0.01 BTC, then the fee can be waived. Though the typical fee is 0.0001 BTC or 0.1 mBTC.
However, for larger transactions - the current rate is 0.1 mBTC per 1,000 bytes.
I was able to create a serialized hex transaction and then send it to the network, but I wondered what did all those characters mean?
I’m a bit old school and still like the feeling that paper affords. So I printed up a transaction and proceeded to deconstructing what each field meant.
It was my way of really getting into the data.
When looking at a transaction, you must always remember that everything is in hex. Also, it is byte size - so you need to basically grab two characters at a time in order to make any meaning.
Then Checked Out:
http://www.siliconian.com/blog/16-bitcoin-blockchain/22-deconstructing-bitcoin-transactions
Hex to ASCII Vs. Hex-to-Decimal. This was by far the most complex, as I was constantly switching these in my mind.