Bitcoin non-standard script output addresses

s-031b4af5197ec30a926f48cf40e11a7d.md

s-031b4af5197ec30a926f48cf40e11a7d

This page summarizes the non-standard Bitcoin output identified as s-031b4af5197ec30a926f48cf40e11a7d in Blockchair’s database, detailing its script, spending conditions, balance status, and technical context. The output is associated with transaction cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35 in block 291508, mined on March 20, 2014.

Overview

• Identifier: s-031b4af5197ec30a926f48cf40e11a7d (Blockchair-specific, likely a 16-byte hash of the scriptPubKey)
• Transaction ID: cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35
• Block: 291508 (mined 2014-03-20 15:56:44)
• Output Value: 0.5495 BTC (54,950,000 satoshis)
• Output Index: 0
• ScriptPubKey: OP_PUSHNUM_1 (hex: 51)
• Type: Non-standard (UNKNOWN)
• Spent In: Transaction 51874c4b26a92dacb256f0e60303daabf60a63681111c4c1948f0bba25d8df96, input 0, block 211997
• Balance Status: Fully spent (0 BTC remaining)

Non-Standard Output Context

The s- prefix is a Blockchair-specific notation for non-standard outputs that don’t map to standard Bitcoin addresses (e.g., P2PKH, P2SH, P2WPKH, P2TR). The scriptPubKey OP_PUSHNUM_1 pushes 1 (interpreted as True) onto the stack, lacking cryptographic conditions like signatures or hashes. This makes it an “anyone-can-spend” output, unusual for Bitcoin due to its lack of security.

Purpose and Historical Context

• Possible Uses:
  • Testing/Experimentation: Common in Bitcoin’s early years (2009–2014) for protocol testing.
  • Burn Output: Funds may have been intentionally made accessible to remove them from circulation.
  • Error: Could result from a mistake, risking immediate spending by others.
• Historical Note: Non-standard scripts like this were more prevalent in 2014, before standardized address formats dominated for compatibility.

Spending Details

The output was spent in transaction 51874c4b26a92dacb256f0e60303daabf60a63681111c4c1948f0bba25d8df96 with the following details:

• scriptSig: OP_PUSHBYTES_1 00 OP_DROP (hex: 010075)
• Output:
  • Type: P2PKH
  • scriptPubKey: OP_DUP OP_HASH160 OP_PUSHBYTES_20 d994aabea310efb308baa96c044aeae1fe1c4131 OP_EQUALVERIFY OP_CHECKSIG
  • Value: 0.4171 BTC (41,710,000 satoshis)
• Fee: 0.1324 BTC (13,240,000 satoshis)
• Subsequent Spending: The P2PKH output was spent in transaction fa0ca6e610678d4702872a0a09e6e095ff0079996ac2e92fc2ac290d3b376e31:0 in block 212146.

Spending Conditions

The scriptPubKey (OP_PUSHNUM_1) requires only that the combined script execution leaves True on the stack without triggering failure. The scriptSig (OP_PUSHBYTES_1 00 OP_DROP) pushes a zero byte and removes it, leaving the stack empty for OP_PUSHNUM_1 to push True. This means:

• Condition: No cryptographic proof (e.g., signature or key) is required; anyone can spend by providing a valid scriptSig.
• Execution:
  1. OP_PUSHBYTES_1 00: Pushes 0x00 (stack: [0x00])
  2. OP_DROP: Removes top item (stack: [])
  3. OP_PUSHNUM_1: Pushes 1 (stack: [1])
  4. Result: True on stack, script valid.

Balance Analysis

• Input: 0.5495 BTC
• Output: 0.4171 BTC
• Fee: 0.5495 - 0.4171 = 0.1324 BTC
• Remaining Balance: 0 BTC (fully spent)

Conversion to Standard Address

• Possible?: No
• Reason: The scriptPubKey (OP_PUSHNUM_1) lacks a public key hash or redeem script, preventing encoding as a standard address (e.g., P2PKH, P2SH, P2WPKH, P2TR).

Clarification on Script Code

The string 51874c4b26a92dacb256f0e60303daabf60a63681111c4c1948f0bba25d8df96 is the spending transaction ID, not script code. The scriptPubKey is fully represented by OP_PUSHNUM_1 (hex: 51).

Verification

• Blockchair: Shows s-031b4af5197ec30a926f48cf40e11a7d with 0.5495 BTC, spent in block 211997.
• btcscan.org: Confirms scriptPubKey as 51 and scriptSig as 010075.
• Blockstream.info: Displays raw scriptPubKey (51) without s- prefix.

Technical Summary

ScriptPubKey

• ASM: OP_PUSHNUM_1
• Hex: 51
• Opcode: 0x51 (pushes 1/True onto stack)
• Behavior: Leaves True on stack, no cryptographic checks.

ScriptSig (Spending)

• ASM: OP_PUSHBYTES_1 00 OP_DROP
• Hex: 010075
• Opcodes:
  • 01: Pushes 1 byte (00)
  • 75 (OP_DROP): Removes top stack item
• Behavior: No-op, ensures OP_PUSHNUM_1 can push True.

Transaction Details

• Output Transaction: cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35:0
  • Value: 0.5495 BTC
  • Block: 291508
• Spending Transaction: 51874c4b26a92dacb256f0e60303daabf60a63681111c4c1948f0bba25d8df96:0
  • Output Value: 0.4171 BTC (P2PKH)
  • Fee: 0.1324 BTC
  • Block: 211997

Spending Conditions

• Requirement: Valid scriptSig that allows OP_PUSHNUM_1 to leave True on stack.
• Security: None; anyone can spend due to lack of cryptographic conditions.
• Example Valid scriptSig: Empty or any non-failing script (e.g., OP_PUSHBYTES_1 00 OP_DROP).

Balance

• Status: Fully spent (0 BTC remaining).
• Distribution: 0.4171 BTC to P2PKH address, 0.1324 BTC as miner fee.

Conversion

• Status: Not convertible to standard address.
• Reason: No public key hash or redeem script present.

Potential Issues

• Security Risk: “Anyone-can-spend” nature makes funds vulnerable to immediate claiming.
• Historical Anomaly: Likely a test or error from 2014, when non-standard scripts were more common.

References

• Bitcoin Wiki: Script
• Bitcoin_Addresses_Summary.md
• Blockchair Data: blockchair_bitcoin_inputs_20140426.tsv.gz
• btcscan.org: Transactions cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35, 51874c4b26a92dacb256f0e60303daabf60a63681111c4c1948f0bba25d8df96

s-1428b6578b0073fcd6871a28b99bf95b.md

s-1428b6578b0073fcd6871a28b99bf95b

Script Details

• Transaction ID: 9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e
• Output Value: 0.01 BTC
• ScriptPubKey:
  • ASM: OP_PUSHBYTES_8 04678afd04678afd OP_DROP OP_SHA256 OP_PUSHBYTES_32 894eeb82f9a851f5d1cb1be3249f58bc8d259963832c5e7474a76f7a859ee95c OP_EQUAL
  • Hex: 0804678afd04678afd75a820894eeb82f9a851f5d1cb1be3249f58bc8d259963832c5e7474a76f7a859ee95c87
• Type: Non-standard, Blockchair identifier s-1428b6578b0073fcd6871a28b99bf95b
• Spending Transaction: 4f1433d6433d3ce8a877519ba9ddc310dbee96dba939aca0dbef0176a3563436, input index 1, block #157785

Script Logic

The script implements a hash puzzle, requiring the spender to provide a preimage whose SHA-256 hash matches 894eeb82f9a851f5d1cb1be3249f58bc8d259963832c5e7474a76f7a859ee95c. The script’s execution flow is:

1. Push and Drop: Pushes 8 bytes (04678afd04678afd) and drops them (no effect on validation).
2. Hash Computation: Takes the scriptSig’s preimage, computes its SHA-256 hash.
3. Comparison: Checks if the computed hash equals the target hash using OP_EQUAL.
4. Outcome: If true, the script validates; otherwise, it fails.

Stack Operations

Step	Opcode/Data	Stack Before	Stack After
1	OP_PUSHBYTES_8 04678afd04678afd	[preimage]	[preimage, 04678afd04678afd]
2	OP_DROP	[preimage, 04678afd04678afd]	[preimage]
3	OP_SHA256	[preimage]	[SHA256(preimage)]
4	OP_PUSHBYTES_32 894eeb82...e95c	[SHA256(preimage)]	[SHA256(preimage), 894eeb...e95c]
5	OP_EQUAL	[SHA256(preimage), 894eeb...e95c]	[true/false]

Spending Conditions

• Requirement: ScriptSig must push a preimage satisfying SHA256(preimage) = 894eeb82f9a851f5d1cb1be3249f58bc8d259963832c5e7474a76f7a859ee95c.
• Security: No signature required; spendable by anyone with the preimage.
• ScriptSig Format: OP_PUSHBYTES_n <preimage> (exact preimage unknown without raw transaction data).

Spending Details

• Transaction: 4f1433d6433d3ce8a877519ba9ddc310dbee96dba939aca0dbef0176a3563436
• Input: Index 1, referencing the original output.
• Output ScriptPubKey:
  • ASM: OP_DUP OP_HASH160 OP_PUSHBYTES_20 20e9fc9cf541aa0439ff5ddbeff3ebd316b1a107 OP_EQUALVERIFY OP_CHECKSIG
  • Hex: 76a91420e9fc9cf541aa0439ff5ddbeff3ebd316b1a10788ac
  • Type: P2PKH, locking to a public key hash (address starts with 1).
• Process: The spender provided the correct preimage, validated the input, and redirected funds to a P2PKH address, mined in block #157785.

Analysis Notes

• Non-Standard: Not convertible to a standard address (P2PKH/P2SH); s- prefix is Blockchair-specific.
• Purpose: Likely a puzzle or test, common in early Bitcoin (2011).
• Verification: Use bitcoin-cli getrawtransaction or explorers to extract scriptSig and verify preimage.
• Limitations: Preimage not provided; requires raw transaction data for full analysis.

s-18dbc79a30ec2dc88c2d87890de1b31e.md

s-18dbc79a30ec2dc88c2d87890de1b31e

This page summarizes the analysis of the Bitcoin non-standard script address s-18dbc79a30ec2dc88c2d87890de1b31e, associated with a puzzle-like transaction from 2013. It covers the script's logic, spending conditions, historical context, and balance status, providing a technical summary for reference.

Overview

• Address: s-18dbc79a30ec2dc88c2d87890de1b31e
• Type: Non-standard script output (Blockchair-specific prefix s-)
• Transaction: Funded by bc216d5f3d330dcd73c41ef59e5ca42a2ef401fec8fca0209f753697ce591bab (block 269597, November 14, 2013) with 0.00055 BTC (55,000 satoshis).
• Spent: Fully spent in fd9d8d6156233ffc84c4c6c76b265ab1fd947bb4e99475a19d9d54da6d226556 (block 269628, November 14, 2013) for 0.00045 BTC (45,000 satoshis) plus 0.0001 BTC (10,000 satoshis) fee.
• Claimed Balance: A 2025 blockchair_bitcoin_addresses_and_balance file suggests 115,000 satoshis remain, but this is unverified and likely an error.
• Purpose: Likely a Bitcoin puzzle, requiring cryptographic or signature-based conditions to spend, common in early Bitcoin challenges.

Puzzle Context

The script is believed to be part of a 2013-era Bitcoin puzzle, similar to the ~1000 BTC Challenge, where funds are locked to encourage solving cryptographic problems. The script's complexity, involving size checks, hash verification, and dual signature requirements, supports this hypothesis. The OP_BOOLOR operation suggests a backdoor for the creator to reclaim funds, which was used in the spending transaction.

Script Logic

The scriptPubKey defines the conditions for spending the funds:

OP_SIZE OP_PUSHBYTES_1 20 OP_PUSHBYTES_1 23 OP_WITHIN OP_SWAP OP_SHA256 OP_PUSHBYTES_32 c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353 OP_EQUAL OP_BOOLAND OP_SWAP OP_PUSHBYTES_65 04d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4 OP_CHECKSIGVERIFY OP_SWAP OP_PUSHBYTES_65 047bafaf9f46bdbaa9caddc1071e6c0c438e691246b72b0eb87fde4e6c61634e963d2d513391593016339d649c1f1d44e92316dc72f64fa0d3785bd47f49a1b93c OP_CHECKSIG OP_BOOLOR

Spending Conditions

1. Puzzle Path:
   • Provide data B (20–23 bytes) such that SHA256(B) = c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353.
   • Provide a valid signature for pubkey1 (04d09be54f7e...).
   • scriptSig: [sig1, B]
2. Signature Path (used in fd9d8d...):
   • Provide valid signatures for pubkey1 and pubkey2 (047bafaf9f46...).
   • Use OP_0 to bypass the puzzle.
   • scriptSig: [sig1, sig2, OP_0]
3. Logical Structure: The script succeeds if either:
   • Size/hash conditions are met (OP_BOOLAND yields 1) and pubkey1 signature is valid.
   • pubkey2 signature is valid (OP_BOOLOR yields 1).

How It Was Spent

• Transaction: fd9d8d6156233ffc84c4c6c76b265ab1fd947bb4e99475a19d9d54da6d226556
• scriptSig: Provided two signatures and OP_0, bypassing the puzzle.
• Execution:
  • Size/hash checks failed (0 via OP_0), yielding 0 for OP_BOOLAND.
  • sig1 was valid for pubkey1 (OP_CHECKSIGVERIFY passed).
  • sig2 was valid for pubkey2 (OP_CHECKSIG yielded 1).
  • OP_BOOLOR (0 OR 1 = 1) allowed success.
• Implication: The spender, likely the puzzle creator, had both private keys, using the signature path to reclaim funds.

Balance Status

• Confirmed: The 0.00055 BTC (55,000 satoshis) from bc216d... was fully spent in fd9d8d... (45,000 satoshis output + 10,000 satoshis fee).
• Unverified Claim: A 2025 Blockchair file suggests 115,000 satoshis remain, but no supporting transaction was found. This is likely a data error or an unverified UTXO.
• Verification Steps:
  • Check Blockchair or BTCScan for unspent outputs.
  • Use a Bitcoin node: bitcoin-cli listunspent 0 9999999 '["s-18dbc79a30ec2dc88c2d87890de1b31e"]'.
  • Provide the transaction ID for the 115,000 satoshis claim to confirm.

Withdrawing Remaining Balance

If a 115,000 satoshis UTXO exists:

1. Verify UTXO: Confirm via explorers or a node.
2. Construct scriptSig:
   • Puzzle Path: Find B (20–23 bytes) matching the SHA256 hash, plus pubkey1 signature. (Infeasible without clues due to SHA256’s complexity.)
   • Signature Path: Provide signatures for pubkey1 and pubkey2. (Requires private keys, likely unavailable.)
3. Build Transaction:
   • Input: Reference the UTXO (txid, vout).
   • Output: Send funds (minus fees) to a controlled address.
   • Tools: bitcoin-cli, python-bitcoinlib.
   • Example:

     bitcoin-cli createrawtransaction '[{"txid":"UTXO_txid","vout":vout}]' '{"your_address":0.00115}'
     bitcoin-cli signrawtransactionwithkey <raw_tx> '["private_key1","private_key2"]'
     bitcoin-cli sendrawtransaction <signed_tx>

4. Challenges:
   • Lack of private keys makes the signature path infeasible.
   • Solving the puzzle requires brute-forcing SHA256, which is computationally impractical.
   • Fees (~2,000–10,000 satoshis for a 200-byte transaction) reduce the spendable amount.

Historical Context

• 2013 Era: Non-standard scripts were common in early Bitcoin for experiments and puzzles. This script aligns with challenges like the ~1000 BTC Challenge.
• Blockchair’s Role: The s- prefix is Blockchair-specific, representing non-standard scripts. The 16-byte hex identifier is a custom hash, requiring transaction data for analysis.
• Puzzle Design: The OP_BOOLOR suggests a backdoor, allowing the creator to spend funds without solving the puzzle, as seen in fd9d8d....

Practical Notes

• Verification: Cross-check balances with multiple explorers (Blockchair, BTCScan, Blockchain.com) or a node to resolve the 115,000 satoshis discrepancy.
• Tools:
  • bitcoin-cli: decoderawtransaction, decodescript, listunspent.
  • Python: python-bitcoinlib for script parsing and transaction creation.
• Explorer Limitations: Non-standard addresses may not display full transaction histories; raw transaction data is needed.
• Safety: Use Bitcoin Testnet for experiments to avoid losing funds.

Technical Summary

Attribute	Details
Address	s-18dbc79a30ec2dc88c2d87890de1b31e
Type	Non-standard script (Blockchair s- prefix)
Funding Tx	bc216d... (block 269597, 0.00055 BTC, 55,000 satoshis)
Spending Tx	fd9d8d... (block 269628, 0.00045 BTC output + 0.0001 BTC fee)
scriptPubKey	Size check (20–23 bytes), SHA256 hash, dual signatures, OP_BOOLOR
scriptSig (Spending)	[sig1, sig2, OP_0] (valid signatures for pubkey1, pubkey2)
Spending Conditions	1. Data B (20–23 bytes, SHA256 match) + pubkey1 sig 2. pubkey1 + pubkey2 sigs
Balance	0 satoshis (fully spent); 115,000 satoshis claimed but unverified
Puzzle	Likely a 2013 cryptographic challenge; OP_BOOLOR allowed signature bypass
Withdrawal	Requires private keys or puzzle solution; infeasible without keys or clues

References

• Bitcoin Script Wiki
• Bitcoins the Hard Way
• Blockchair
• BTCScan
• BTCScan
• Private Keys Directory

s-272edf45031dd498e7b3ae89e11ff21b.md

s-272edf45031dd498e7b3ae89e11ff21b

Overview

The custom Bitcoin address s-272edf45031dd498e7b3ae89e11ff21b is a non-standard output linked to a historical Mt. Gox error in October 2011, where 2,609 BTC were sent to unspendable addresses. This guide summarizes the technical details, the associated puzzle, the transaction, and why the output is permanently locked.

Background: Mt. Gox Incident

• Date: October 28, 2011
• Event: Mt. Gox, a major Bitcoin exchange, sent 2,609 BTC to invalid addresses due to a scripting error in their Bitcoin client.
• Impact: The lost bitcoins were worth ~$8,300 in 2011, escalating to ~$26 million by 2019.
• Block: The error occurred in block 150,951, containing multiple transactions totaling the lost amount.
• Source: Bitcoin History Part 17

Transaction Details

• Transaction ID: 81f591582b436c5b129f347fe7e681afd6811417973c4a4f83b18e92a9d130fd (one of several in block 150,951)
• Address: s-272edf45031dd498e7b3ae89e11ff21b (Blockchair-specific, non-standard output)
• ScriptPubKey: 76a90088ac (OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG)
• Verification: Use explorers like Blockchair or Blockchain.com.

The Puzzle

• Challenge: Spend the output by satisfying the scriptPubKey.
• Script Execution:
  • ScriptSig: <sig> <pubkey>
  • Steps:
    1. Push <sig> <pubkey>. Stack: [sig, pubkey]
    2. OP_DUP: Duplicates pubkey. Stack: [sig, pubkey, pubkey]
    3. OP_HASH160: Hashes top pubkey to 20-byte hash160(pubkey). Stack: [sig, pubkey, hash160(pubkey)]
    4. OP_0: Pushes empty array ([], 0 bytes). Stack: [sig, pubkey, hash160(pubkey), []]
    5. OP_EQUALVERIFY: Compares hash160(pubkey) (20 bytes) to [] (0 bytes). Fails, as they cannot match.
    6. OP_CHECKSIG: Not reached due to failure.
• Issue: The script requires hash160(pubkey) to equal an empty array, which is impossible since hash160 always outputs 20 bytes.

Validation of Forum Claim

• Quote by "etotheipi": “To spend these coins, you must furnish a public key that, when you apply ripemd160(sha256(pubKey)), equals ‘0x00’. Unfortunately, ripemd160 only produces 20-byte hashes.”
• Analysis: Mostly accurate. “0x00” likely refers to a 20-byte zero hash (0x000...000), not a single byte. The impossibility holds, as no public key can produce a hash160 matching an empty array or all zeros.

Why It’s Unspendable

• Core Problem: Hash160 outputs 20 bytes, but the script demands a 0-byte array, causing OP_EQUALVERIFY to fail.
• Explored Possibilities:
  • Special Public Key: No key can produce a 0-byte hash160.
  • Alternative ScriptSig: Adding data (e.g., <sig> <pubkey> []>) still results in a 20-byte hash.
  • Protocol Bugs: No known bugs allow mismatched array lengths to pass OP_EQUALVERIFY.
  • Stack Manipulation: Can’t align stack to compare two empty arrays in standard transactions.
  • Protocol Changes: Retroactive changes would break existing transactions, making this infeasible.
  • Cryptographic Breakthroughs: Breaking ECDSA or hash160 doesn’t help, as the failure occurs before OP_CHECKSIG.
  • Non-Standard Types: The script isn’t P2SH or SegWit, offering no flexibility.
• Conclusion: The output is mathematically impossible to spend under Bitcoin’s rules.

Technical Summary

Attribute	Details
Address	s-272edf45031dd498e7b3ae89e11ff21b (Blockchair non-standard)
Transaction ID	81f591582b436c5b129f347fe7e681afd6811417973c4a4f83b18e92a9d130fd
Block	150,951 (October 28, 2011)
ScriptPubKey	76a90088ac (OP_DUP OP_HASH160 OP_0 OP_EQUALVERIFY OP_CHECKSIG)
ScriptSig	None (unspent, unspendable)
Amount Lost	Part of 2,609 BTC
Spendability	Impossible due to mismatched hash lengths

Practical Notes

• Blockchair’s Role: The s- prefix is a Blockchair-specific identifier for non-standard scripts, likely using a 16-byte hash (e.g., MD5) of the script.
• Historical Context: Common in early Bitcoin (2009–2012) due to custom scripts. Modern Bitcoin favors standard addresses (P2PKH, P2SH, SegWit, Taproot).
• Verification: Cross-check with explorers (Blockchair, Blockstream.info) or Bitcoin nodes (e.g., bitcoin-cli getrawtransaction).

References

• Bitcoin History Part 17: That Time Mt. Gox Destroyed 2609 BTC
• Mt. Gox Wikipedia
• The Programming Error That Cost Mt. Gox 2609 Bitcoins
• Blockchair Block 150,951
• Blockchain.com Block 150,951
• Bitcoin Wiki: Script

Key Takeaway

The s-272edf45031dd498e7b3ae89e11ff21b puzzle is an artifact of a Mt. Gox error, locking bitcoins in an unspendable output due to an impossible script condition. It serves as a historical lesson on the importance of robust transaction validation in Bitcoin.

s-52eb7d0c79e5933a2e2b8b9fe130702e.md

s-52eb7d0c79e5933a2e2b8b9fe130702e

This page summarizes the logic, spending mechanism, and status of the non-standard Bitcoin script output identified as s-52eb7d0c79e5933a2e2b8b9fe130702e, associated with transaction bc216d5f3d330dcd73c41ef59e5ca42a2ef401fec8fca0209f753697ce591bab. The information is derived from the Bitcoin Script wiki, Bitcoin Addresses Summary, and transaction details from btcscan.org.

Overview

• Identifier: s-52eb7d0c79e5933a2e2b8b9fe130702e
• Type: Non-standard script output (Blockchair-specific prefix s-)
• Transaction: bc216d5f3d330dcd73c41ef59e5ca42a2ef401fec8fca0209f753697ce591bab
• Date: November 14, 2013
• Value: 0.2341 BTC (23,410,000 satoshis)
• Status: Fully spent in transaction dbbb181eb0a6271410b32f8c20abc8a6fc849bf8eeaae08db3d834dbd479d1dd (block #269628)
• Purpose: Likely an experimental script combining a cryptographic puzzle with signature-based spending, common in Bitcoin’s early years (2009–2013).

Technical Summary

ScriptPubKey

ASM:

OP_SIZE OP_PUSHBYTES_1 20 OP_PUSHBYTES_1 23 OP_WITHIN OP_SWAP OP_SHA256 OP_PUSHBYTES_32 c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353 OP_EQUAL OP_BOOLAND OP_SWAP OP_PUSHBYTES_65 04d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4 OP_CHECKSIGVERIFY OP_SWAP OP_PUSHBYTES_65 04b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209 OP_CHECKSIG OP_BOOLOR

Hex:

8201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c4104b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209ac9b

Logic

The script defines two spending paths:

1. Hash and Length Check Path:
   • Requirement: Provide <data> (32–34 bytes) where SHA256(data) == c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353 and a valid ECDSA signature for public key 04d09be54f....
   • Process:
     • OP_SIZE pushes the length of <data>.
     • OP_WITHIN verifies 32 <= length < 35.
     • OP_SHA256 and OP_EQUAL check if SHA256(data) matches the specified hash.
     • OP_CHECKSIGVERIFY verifies the signature for the first public key.
2. Signature-Only Path:
   • Requirement: Provide a valid ECDSA signature for public key 04b0b13673....
   • Process: OP_CHECKSIG verifies the signature, bypassing the hash and length checks.
   • The OP_BOOLOR allows the transaction to succeed if either path is valid.

This hybrid script combines a cryptographic puzzle (similar to a “transaction puzzle” from the Bitcoin Script wiki) with a fallback signature-based spending mechanism, resembling a Pay-to-PubKey (P2PK) structure.

Spending Details

• Spending Transaction: dbbb181eb0a6271410b32f8c20abc8a6fc849bf8eeaae08db3d834dbd479d1dd (input index 0, block #269628)
• scriptSig:
  • Hex: 483045022100a27c9532f4eb90240f598aa4c3ad43bc604fb4464688dad8113a943212d6638f022035ff6f215a4a432590d987f9c8ea839678506904a97643e8e99371b991b9438001493046022100b9d333b096a2a19bf6aa142aa429e7feb4d400b7af82bed4f5eca3ea7b7e83ec02210082d5be5da0a523c9c6e86ecf48f16cfbe3b32def49c92ce376cc87aa74676086010100
  • Decoded:
    • <sig2>: DER-encoded ECDSA signature for pubkey1 (04d09be54f...) with SIGHASH_ALL.
    • <sig1>: DER-encoded ECDSA signature for pubkey2 (04b0b13673...) with SIGHASH_ALL.
    • OP_0: Empty vector (false), indicating no <data> for the hash check.
• Spending Path: The output was spent via the Signature-Only Path, using a valid signature for pubkey2. The OP_0 indicates the hash and length check was bypassed, and the transaction succeeded due to OP_BOOLOR with a valid <sig1>.

Balance Status

• Initial Value: 0.2341 BTC
• Spent: Fully spent in dbbb181eb0a6271410b32f8c20abc8a6..., with 0.23399825 BTC sent to a P2PKH address (62a2486468040e8a1a1f91d8949ac4dc838a0ed2) after a 0.00010175 BTC fee.
• Subsequent Spending: The P2PKH output was spent in transaction 374db5c97ac66264214f0990d09e24d7ced61bc440e4245fe77cda4cefa3300e (block #269637).
• Current Balance: 0 BTC remains for s-52eb7d0c79e5933a2e2b8b9fe130702e.

Practical Notes

• Non-Standard Context: The s- prefix is a Blockchair-specific identifier for non-standard scripts, with the 16-byte hex likely an MD5 hash of the scriptPubKey. It does not map to a standard address (P2PKH, P2SH, etc.).
• Use Case: Likely an experimental script from 2013, combining a hash preimage challenge with a signature-based fallback, typical of early Bitcoin’s exploratory phase.
• Verification: Use bitcoin-cli to decode the transaction or script:

  bitcoin-cli getrawtransaction bc216d5f3d330dcd73c41ef59e5ca42a2ef401fec8fca0209f753697ce591bab 1
  bitcoin-cli decodescript 8201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c4104b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209ac9b

• Explorer Support: btcscan.org and Blockchair provide raw script details; cross-reference with Blockstream.info for accuracy.

References

• Bitcoin Wiki: Script
• Bitcoin Addresses Summary
• Transaction Details
• Spending Transaction

s-f3aa977840863c94a2dacf802e7f7d85.md

s-f3aa977840863c94a2dacf802e7f7d85

This page summarizes the non-standard Bitcoin output identified as s-f3aa977840863c94a2dacf802e7f7d85, associated with transactions a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b and 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. It explains the output’s nature, its role in a cryptographic puzzle, and how to analyze it, with a technical summary for reference.

Overview

The identifier s-f3aa977840863c94a2dacf802e7f7d85 is a Blockchair-specific label for a non-standard Bitcoin transaction output. It represents a scriptPubKey that doesn’t conform to standard address formats (e.g., P2PKH, P2SH). This output, created in the first transaction and spent in the second, is part of a puzzle requiring data that, when hashed twice with SHA-256, matches a specific hash.

Transaction Context

• First Transaction: a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b
  • Input: 1 BTC from P2PKH address 1FMb8Jnn1jSh7yjDFfonC8xCCH3ittoEzB.
  • Output: 1 BTC to s-f3aa977840863c94a2dacf802e7f7d85 (non-standard script).
  • Purpose: Locks funds with a puzzle requiring specific data to unlock.
• Second Transaction: 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1
  • Input: Spends the output from s-f3aa977840863c94a2dacf802e7f7d85.
  • Output: Sends funds to P2PKH address 1BzEggcAztt4C7rbgWWg1ENYy1Wx1oSHwL.
  • Purpose: Solves the puzzle, unlocking the funds.

What is s-f3aa977840863c94a2dacf802e7f7d85?

• Definition: A Blockchair-specific identifier for a non-standard output, likely an MD5 hash (16 bytes, 32 hex characters) of the scriptPubKey or related data.
• ScriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
  • Hex: a8206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000087.
  • Requires data such that SHA256(SHA256(data)) equals the 32-byte hash 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000.
• Solution: The second transaction’s scriptSig provides the Bitcoin Genesis block header (80 bytes), which satisfies the hash condition.

Puzzle Mechanics

• Locking Mechanism: The scriptPubKey sets a cryptographic challenge: provide data that, when double-hashed with SHA-256, matches the given hash.
• Unlocking: The scriptSig in the second transaction supplies the Genesis block header:
  • Hex: 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c.
  • Verification: SHA256(SHA256(header)) yields 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000.
• Security Note: This script lacks signatures, making it insecure—anyone with the solution can spend it. It’s a puzzle, not a practical lock.

Balance Status

• Initial Balance: 1 BTC (100,000,000 satoshis) in the first transaction’s output.
• Current Balance: 0 BTC, as the output was spent in the second transaction.
• Verification: Check via Blockchair by searching s-f3aa977840863c94a2dacf802e7f7d85 or the transaction IDs on explorers like Blockstream.info or Bitaps.com.

Technical Summary

• Identifier: s-f3aa977840863c94a2dacf802e7f7d85 (Blockchair-specific, likely MD5 of scriptPubKey).
• ScriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
  • Hex: a8206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d619000000000087.
  • Function: Requires data where SHA256(SHA256(data)) equals the given hash.
• ScriptSig (Spending): OP_PUSHDATA1[80] 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c
  • Data: Bitcoin Genesis block header (80 bytes).
  • Verification:

    import hashlib
    data = bytes.fromhex("0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c")
    hash1 = hashlib.sha256(data).digest()
    hash2 = hashlib.sha256(hash1).digest()
    # Output: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

• Execution Flow:
  1. Stack: <data> (Genesis header).
  2. OP_HASH256: Computes double SHA-256, pushes result.
  3. Stack: <computed_hash>.
  4. OP_PUSHBYTES[32]: Pushes given hash.
  5. Stack: <computed_hash> <given_hash>.
  6. OP_EQUAL: Checks equality, outputs true, allowing the spend.
• Spendability: Yes, by providing the correct preimage (Genesis header).
• Conversion: Not convertible to a standard address (e.g., P2PKH, P2SH), as it’s a custom script.
• Balance Check:
  • Explorers: Blockchair (search s-f3aa977840863c94a2dacf802e7f7d85 or txid), Blockstream.info, Bitaps.com (use txid).
  • Tools: bitcoin-cli (gettxout <txid> <vout>), python-bitcoinlib for script parsing.
• Current Status: Spent (0 BTC) in transaction 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1.

Analysis Tools

• Blockchair: Search s-f3aa977840863c94a2dacf802e7f7d85 or txid for transaction details.
• Blockstream.info/Bitaps.com: View raw scriptPubKey and spend status via txid.
• bitcoin-cli: decoderawtransaction <txid> or decodescript <script_hex>.
• Python: python-bitcoinlib to parse scripts and verify hashes.
• BitIDE: Web-based debugger for script analysis (link).

Key Takeaways

• s-f3aa977840863c94a2dacf802e7f7d85 is a non-standard output with a cryptographic puzzle.
• Solved by providing the Genesis block header, highlighting Bitcoin Script’s flexibility.
• Balance is 0 BTC (spent); use Blockchair or other explorers with the txid to confirm.
• Demonstrates a fun, insecure use of Bitcoin Script for puzzles, not practical for secure transactions.