Use the search bar at the top of the website to search for a specific transaction.

Or you could just check out a random one:

Examples

Basic

P2PKH

• 6359f0868171b1d194cbee1af2f16ea598ae8fad666d9b012c8ed2b79a236ec4 (29 Dec 2010)
• These P2PKH transactions were the most common in earlier versions of bitcoin. They allow you to send bitcoins to 1addresses. This transaction spends one P2PKH output, and creates two new P2PKH outputs.

P2MS

• 581d30e2a73a2db683ac2f15d53590bd0cd72de52555c2722d9d6a78e9fea510 (06 Dec 2016)
• This transaction contains one output with a typical 2-of-3 P2MS locking script on it. It required 2 signatures from any of the 3 public keys to unlock it.

P2SH

• d3adb18d5e118bb856fbea4b1af936602454b44a98fc6c823aedc858b491fc13 (22 Dec 2013)
• This transaction has a single P2SH output. It gets spent in transaction cc11ca9e9dc188663c41eb23b15370f68eded56b7ec54dd5bc4f2d2ae93addb2, where it's revealed that the hashed script inside the P2SH was a 2-of-3 P2MS script.

P2MS

• 581d30e2a73a2db683ac2f15d53590bd0cd72de52555c2722d9d6a78e9fea510 (06 Dec 2016)
• This transaction contains one output with a typical 2-of-3 P2MS locking script on it. It required 2 signatures from any of the 3 public keys to unlock it.

P2SH

• d3adb18d5e118bb856fbea4b1af936602454b44a98fc6c823aedc858b491fc13 (22 Dec 2013)
• This transaction has a single P2SH output. It gets spent in transaction cc11ca9e9dc188663c41eb23b15370f68eded56b7ec54dd5bc4f2d2ae93addb2, where it's revealed that the hashed script inside the P2SH was a 2-of-3 P2MS script.

P2WPKH

• 8b8d1473ce0a9936b70524435d37d37ae226d39f74ce8ff7abf545c501dfce9e (13 Jul 2023)
• This transaction contains a single P2WPKH output. They work in a similar way to P2PKH in that you lock the output to a public key, but they use the witness field instead of the scriptsig field for unlocking. These are now used in favour of the legacy P2PKH locking scripts.

P2WSH

• 46ebe264b0115a439732554b2b390b11b332b5b5692958b1754aa0ee57b64265 (11 May 2020)
• The second output of this transaction contains a P2WSH locking script. They work in a similar way to P2SH, but they use the witness field instead of the scriptsig field for unlocking. These are now used in favour of the legacy P2SH locking scripts. This second output gets spent in transaction b38a88b073743bcc84170071cff4b68dec6fb5dc0bc8ffcb3d4ca632c2c78255, where it's revealed that the hashed script inside the P2WSH was a 2-of-3 P2MS script.

P2TR

• 05ef444d4b24608fc3a2d3f242609f58e0ae4bf8da9caefb494482d4d57d9f02 (13 Jul 2023)
• This transaction contains a single P2TR output.

Technical

Coinbase Transaction

• a8d0c0184dde994a09ec054286f1ce581bebf46446a512166eae7628734ea0a5 (25 Feb 2016)
• A coinbase transaction is a special as it doesn't "spend" any previous outputs. Therefore, for the input to the transaction the "previous TXID" is all zeros. The input scriptsig is also redundant, so miners typically use it for inserting custom text and data.

Coinbase Transaction (Segwit)

• da917699942e4a96272401b534381a75512eeebe8403084500bd637bd47168b3 (24 Aug 2017)
• A segwit coinbase transaction is similar to a normal coinbase transaction but with a couple of extra rules. It requires a commitment to the wTXIDs in one of its outputs, and a witness reserved value must be placed inside the input witness field.

Relative Locktime

• d4371904cdb461204bb3dbb2b780803248c101b80ec22cf0f6e702f600b62172 (11 Sep 2021)
• This transaction makes use of the relative locktime feature (via the input sequence field). This transaction could only have been mined 360 blocks after the output it's spending was mined.

Interesting

Vojtěch Strnad Transaction

• b10c0000004da5a9d1d9b4ae32e09f0b3e62d21a5cce5428d4ad714fb444eb5d (29 Jun 2024)
• This is the most complex/interesting transaction ever constructed. It uses every possible locking script, amongst many other Easter eggs. Here's a full explanation by the creator.

SHA-1 Hash Collision Spend

• 8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc (23 Feb 2017)
• This transaction spends the Peter Todd SHA-1 hash collision locking script. Basically, the original transaction contained a P2SH output with custom script inside. If you look at the spending transaction you can see that the redeem script was 6e879169a77ca787, which as opcodes is: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL. In other words, to spend this output, you needed to find two different pieces of data that hash to the same value when using SHA-1. The original 1 BTC bounty output lock was created on 13 Sep 2013, and it was finally spent on 23 Feb 2017 (shortly after SHA-1 hash collisions were first found).

Famous

Pizza Transaction

• a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d (22 May 2010)
• This is the famous 10,000 BTC Pizza transaction made by Laszlo back in May 2010. It's significant because it was the first time bitcoin was ever used to purchase real-world goods, which gave bitcoins real-world value (as opposed to just being a valueless digital currency). People today sometimes joke about how he paid 10,000 BTC for a pizza considering today's exchange rate, but Laszlo effectively created the exchange rate for bitcoin, which makes him (and this transaction) an important part of bitcoin's history. Thanks Laszlo.

Firsts

P2PK

• f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 (12 Jan 2009)
• These P2PK outputs were used in the early days of bitcoin (primarily by miners in coinbase transactions), but are rarely used anymore. This was the first ever "actual" bitcoin transaction (i.e. not a coinbase transaction) sent by Satoshi to Hal Finney.

P2PKH

• 6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516 (16 Jan 2009)
• Not sure why Satoshi used a P2PK output in the first ever bitcoin transaction. This P2PKH transaction appeared 4 days later.

P2MS

• 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1 (30 Jan 2012)
• This was technically the first multisig transaction. It only required one signature to spend the first output in this transaction, but it gave a choice of two possible public keys that you could create a signature for (1-of-2 multisig).

P2SH

• 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6 (07 Mar 2012)
• This was the first transaction that created an output with a P2SH lock on it (that was later spent). These type of scripts were enabled after block 173,805 by BIP 16.

OP_RETURN

• 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc (29 Mar 2013)
• This was the first transaction that used OP_RETURN to store a string of ASCII text inside an output. The data push after the OP_RETURN opcode contains the string: "!Twenty byte digest.". This effectively burned the 0.05000000 BTC that was used as an input (worth $4.50 at the time), as OP_RETURN outputs cannot be spent and there was no other output created to send the coins onwards.

P2WPKH

• dfcec48bb8491856c353306ab5febeb7e99e4d783eedf3de98f3ee0812b92bad (24 Aug 2017)
• This was the first transaction that used the new Segwit P2WPKH output locking script. It works in the same way as a P2PKH, but it uses the witness field instead of the scriptsig field for unlocking. These P2WPKH scripts were enabled on block 481,824 by BIP 141

P2WSH

• dfcec48bb8491856c353306ab5febeb7e99e4d783eedf3de98f3ee0812b92bad (24 Aug 2017)
• This was the first transaction that used the new Segwit P2WSH output locking script (and was later spent). Technically the first P2WSH transaction was 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6, but it has never been spent, so it may have been created incorrectly. It works in the same way as a P2SH, but it uses the witness field instead of the scriptsig field for unlocking. These P2WSH scripts were enabled at the same time as P2WPKH scripts on block 481,824 by BIP 141

Largest

Some of these transactions contain a large amount of data. Opening them on this blockchain explorer may cause your browser to crash.

Size

• 4af9047d8b4b6ffffaa5c74ee36d0506a6741ba6fc6b39fe20e4e08df799cf99 (22 Apr 2023)
• This transaction is 3,969,494 bytes (3.969494 MB) in size. It's primarily made up of witness data, which gets a 0.25 per byte discount when included in a block, which allows it to keep within the 4,000,000 weigh unit block size limit.

Size (1 MB Block Limit)

• bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08 (07 Jul 2015)
• This transaction is 999,657 bytes (0.999657 MB), which was the largest mainnet transaction when the block limit was set to 1 MB (before the segregated witness upgrade). It contains 5,569 inputs and 1 output. This transaction actually paid 0 sats in fees, so it's possible this transaction was created by the person who mined the block (blocks were close to being full at the time so zero-fee transactions weren't being mined).
• Similarly large transactions around this time include:
  • 5d8875ed1707cfee2221741b3144e575aec4e0d6412eeffe1e0fa07335f61311 (999,651 bytes)
  • cb550c9a1c63498f7ecb7bafc6f915318f16bb54069ff6257b4e069b97b367c8 (999,634 bytes)
  • 9c667c64fcbb484b44dcce638f69130bbf1a4dd0fbb4423f58ceff92af4219ec (999,622 bytes)

Number of inputs

• 52539a56b1eb890504b775171923430f0355eb836a57134ba598170a2f8980c1 (01 Aug 2015)
• This transaction spends 20,000 inputs. This is not the only one though, as were nine 20,000-input transactions made on the same day 01 Aug 2015, presumably by the same person. I'm not sure why, but I'd guess it was part of some sort of test.

Number of outputs

• dd9f6bbf80ab36b722ca95d93268667a3ea6938288e0d4cf0e7d2e28a7a91ab3 (01 Jan 2016)
• This transaction creates 13,107 outputs. Again I'm not sure why, but probably another test of some sort to start the New Year in style. Technically you could create a maximum of 65,535 outputs in a transaction (due to the limitations of the compact size field), but this is the most I've ever seen.

Fee

• cc455ae816e6cdafdb58d54e35d4f46d860047458eacf1c7405dc634631c570d (26 Apr 2016)
• This transaction has a fee of 291.2409 BTC ($135,770.68 at the time). This is because it spends 13 outputs with a total value of 291.241 BTC but only creates 1 output with a value of 0.0001 BTC, which meant the remainder could be collected as the transaction fee by the miner. Transactions with fees this large are usually created by mistake, and this is a particularly bad mistake.
• Note: The block explorer on this site doesn't show transaction fees. This is because it gets transaction data using bitcoin-cli getrawtransaction only, and fees are not given for mined transactions. You can look up inputs manually to see their values, but I purposely don't do this to reduce the number of queries I need to make and to keep the pages as fast as possible.

scriptpubkey

• e411dbebd2f7d64dafeef9b14b5c59ec60c36779d43f850e5e347abee1e1a455 (29 Jul 2010)
• This transaction has an output with a 4,026 byte locking script. It contains 4,001 unnecessary OP_CHECKSIG opcodes at the end, which makes this output unspendable.