Futures
Access hundreds of perpetual contracts
TradFi
Gold
One platform for global traditional assets
Options
Hot
Trade European-style vanilla options
Unified Account
Maximize your capital efficiency
Demo Trading
Introduction to Futures Trading
Learn the basics of futures trading
Futures Events
Join events to earn rewards
Demo Trading
Use virtual funds to practice risk-free trading
Launch
CandyDrop
Collect candies to earn airdrops
Launchpool
Quick staking, earn potential new tokens
HODLer Airdrop
Hold GT and get massive airdrops for free
Pre-IPOs
Unlock full access to global stock IPOs
Alpha Points
Trade on-chain assets and earn airdrops
Futures Points
Earn futures points and claim airdrop rewards
Promotions
AI
Gate AI
Your all-in-one conversational AI partner
Gate AI Bot
Use Gate AI directly in your social App
GateClaw
Gate Blue Lobster, ready to go
Gate for AI Agent
AI infrastructure, Gate MCP, Skills, and CLI
Gate Skills Hub
10K+ Skills
From office tasks to trading, the all-in-one skill hub makes AI even more useful.
GateRouter
Smartly choose from 30+ AI models, with 0% extra fees
Just came across some interesting news in the Bitcoin research space that's worth paying attention to. Robin Linus (the ZeroSync and BitVM guy) dropped a paper called 'Binohash: Transaction Introspection Without Softforks' back in February, and it's actually pretty clever.
So here's the core issue: Bitcoin Script is intentionally restricted. It can't natively read transaction details like inputs, outputs, amounts, or other tx fields. This limitation makes it nearly impossible to build advanced protocols that need to verify specific transaction properties directly on-chain. Think about BitVM bridges between Bitcoin and other chains — you need to prove that a peg-out happened to the right address with the right amount, but without transaction introspection, you're stuck relying on trusted oracles or light clients with security assumptions built in.
Binohash solves this by creating a collision-resistant hash of the transaction that can actually be computed and read inside Bitcoin Script itself. The hash commits to key transaction properties, so you can't game the system by swapping one transaction for another.
How does it work? It's a clever exploit of two old Bitcoin quirks. First, the OP_CHECKMULTISIG opcode has this 'FindAndDelete' behavior from the legacy days where it strips signatures from the scriptCode before verification. Robin uses this by embedding dummy signatures in the locking script, and the spender selects different subsets during spending. Each subset combination produces a different sighash, and the spender grinds through combinations until hitting a PoW-like puzzle target. The successful subset indices become the Binohash digest itself — and crucially, they're visible in the unlocking script for Script to read.
The name comes from the binomial coefficient (n choose t), which determines the nonce space size and entropy.
On the practical side: with parameters around 42 bits of work per component, you get roughly 84 bits of collision resistance — comparable to half of SHA-256, which is solid for most use cases. An honest user only needs about 44.6 bits of grinding work, costing under $50 on cloud GPUs. There's already a real transaction on Bitcoin mainnet demonstrating this.
The implications are significant. This enables trustless chain introspection for peg-based bridges — you can verify peg-ins and peg-outs without oracles or full light clients. For example, a bridge could validate that a specific amount was locked on Bitcoin and authorize a corresponding mint on another chain, all verified through the transaction hash itself. It's essentially bringing covenant-like functionality to Bitcoin using only existing opcodes, no softfork needed. Pretty interesting development for the bridge and interoperability space.