Show HN: Bithoven – A high-level, imperative language for Bitcoin Smart Contract
Hacker News (score: 18)Description
The Goal:
Raw Bitcoin Script is notoriously difficult to reason about. Writing raw Bitcoin Script today feels like writing Assembly in the 1970s. You have to mentally juggle the stack (`OP_SWAP`, `OP_ROT`), manually manage distinct execution branches, and pray you didn't leave a stack item unconsumed (which crashes the script). My goal was to bridge the gap between complex contract logic and raw opcodes, allowing developers to write readable, compile-time-safe code.
Key Features:
- Imperative Syntax: Write logic using familiar if/else and return statements instead of mental stack juggling.
- Type Safety: First-class support for bool, signature, string, and number types to prevent runtime errors.
- Targeted Compilation: Support for Legacy, SegWit, and Taproot compilation targets.
- Native Primitives: Built-in keywords for timelocks (older, after) and cryptography (sha256, checksig).
You can try it in the browser here (runs via WASM): https://bithoven-lang.github.io/bithoven/ide/
Here is an example of a Hashed Time-Locked Contract (HTLC):
(condition: bool, sig_alice: signature)
(condition: bool, preimage: string, sig_bob: signature)
{
if condition {
// Relative locktime (Sequence)
older 1000;
return checksig (sig_alice, alice_pk);
} else {
// Hashlock verification
verify sha256 sha256 preimage == hash;
return checksig (sig_bob, bob_pk);
}
}
The project is free open source and the academic paper is currently under review. I’d love to hear any feedback. Thanks for checking it out!More from Hacker
Show HN: Tusk Drift – Turn production traffic into API tests
Show HN: Tusk Drift – Turn production traffic into API tests Hi HN! In the past few months my team and I have been working on Tusk Drift, a system that records real API traffic from your service, then replays those requests as deterministic tests. Outbound I/O (databases, HTTP calls, etc.) gets automatically mocked using the recorded data.<p>Problem we're trying to solve: Writing API tests is tedious, and hand-written mocks drift from reality. We wanted tests that stay realistic because they come from real traffic.<p>versus mocking libraries: Tools like VCR/Nock intercept HTTP within your tests. Tusk Drift records full request/response traces externally (HTTP, DB, Redis, etc.) and replays them against your running service, no test code or fixtures to write/maintain.<p>How it works:<p>1. Add a lightweight SDK (we currently support Python and Node.js)<p>2. Record traffic in any environment.<p>3. Run `tusk run`, the CLI sandboxes your service and serves mocks via Unix socket<p>We run this in CI on every PR. Also been using it as a test harness for AI coding agents, they can make changes, run `tusk run`, and get immediate feedback without needing live dependencies.<p>Source: <a href="https://github.com/Use-Tusk/tusk-drift-cli" rel="nofollow">https://github.com/Use-Tusk/tusk-drift-cli</a><p>Demo: <a href="https://github.com/Use-Tusk/drift-node-demo" rel="nofollow">https://github.com/Use-Tusk/drift-node-demo</a><p>Happy to answer questions!
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Sandbox: Run untrusted AI code safely, fast
Sandbox: Run untrusted AI code safely, fast
Show HN: LinkedQL – Live Queries over Postgres, MySQL, MariaDB
Show HN: LinkedQL – Live Queries over Postgres, MySQL, MariaDB LinkedQL is a new SQL client that supports live queries over any Postgres, MySQL, and MariaDB database. You get result sets that self-update differentially as rows change in your database – via inserts, updates, deletes. Works with no extra tooling/ORM layer or GraphQL servers. You opt into live mode simply with a flag: client.query('SELECT ...', { live: true }). More at: <a href="https://linked-ql.netlify.app/capabilities/live-queries" rel="nofollow">https://linked-ql.netlify.app/capabilities/live-queries</a><p>LinkedQL is written in JavaScript and runs in both client and server environments.<p>GitHub + docs: <a href="https://github.com/linked-db/linked-ql" rel="nofollow">https://github.com/linked-db/linked-ql</a><p>Demo examples included.<p>I’d love feedback: • Anything confusing? • Anything seems useful or dangerous? • Anything else that'd make you consider LinkedQL for production?<p>Thanks for taking a look — happy to answer any questions.
No other tools from this source yet.